When I run under Ersatz-11, John Wilson allows
INSTALL EMEM.DLL
(this was under V3.1 of E11 and hopefully soon with EMEM32.DLL
under V5.1 of E11) to access many MegaBytes of PC memory via an
IOPAGE register.
For example:
BaseReg = 177100
BaseRe2 = BaseReg+2
BaseRe4 = BaseReg+4
BaseRe6 = BaseReg+6
Mov @#BaseReg,R0 ;Get the current value from PC memory
Mov R0,@#BaseReg ;Put the current value into PC memory
BaseRe4 / BaseRe6 are used as a 32 bit address into the PC memory allocated
during the INSTALL process.
Under RT-11, direct access to the IOPAGE (address above 160000) is
allowed even using VBGEXE by a reference to PREVIOUS DATA
space. I have written FORTRAN IV/77 interface subroutines to allow
a user to easily access that memory rather than use VIRTUAL arrays
which are much slower and have much less capacity.
I doubt that RSX-11 or RSTS/E allow a user access to the IOPAGE
even via PREVIOUS DATA space. Can anyone confirm this assumption?
Is there any fast method (only a few extra instructions) that would allow
a user to reference a specific IOPAGE register from a user program? Are
VIRTUAL arrays allowed in FORTRAN under RSX-11? If so, how
is access to the MMU registers controlled and allowed?
Johnny has helped with such RSX-11 questions in the past and the answers
were appreciated very much!
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
I've found the Torch XXX hardware docs, which cover that little Trinitron
monitor I mentioend
It's quite small, probably a 12" CRT. Inside are the following PCBs :
FA (PSU), with a control daughterboard. This gives 120V DC from the mains
(SMPSU), all other voltages come from the flyback transformer
DA (Scan) with a convergence daughterboard.
CRT base (icnludes video output stages)
BA (Video)
H (rear panel controls)
Input socket (not Sony, this is a Torch PCB)
The input socket PCB connects to the video PCB by a 10 wire jumper. 4 of
the wires are grounds, the 6 siganls are R, G, B, Y(== I on a CGA
interface), HSynch and Vsync. The Torch socket PCB doesn't connect to the
Y signal at all, but then Torch machines had analgue RGB outputs and the
BBC micro had 3-bit TTL video, so this would be no problem for the
intented applications.
Tehre's a 3 position slide swtich on the back to select the input mode.
The possiblities are analogue RGB, 3-bit TTL RGB (8 colours) and 4-bit
TTL RBGI (CGA compatile, it does get the brown colour right). It's
strictly TV-rates only (not EGA or VGA), but it does work with both US
and European rates.
-tony
> VAXmate was a 286 clone, I forget if it was 100% pc or off by a little
> from the PC AT.
I used to have a VAXmate when it was actually in production, but it was
just our home computer. It was 100% AT compatible, and ran just about
everything fine
DEC did skimp, however, on the graphics. It did not fully implement CGA.
I beleive it would only display 8 monochrome shades, while CGA implemented
a full 16 shades. While it was compatible with all CGA software, the
display sometimes left something to be desired.
The ridiculous form factor left something to be desired as well. I've
never liked all-in-one designs. And the VAXmate's plastics and
construction could best be described as "cheap." I think the idiotic door
hiding the disk drive broke off after about a month of use.
jba at sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
>
>Subject: Re: *updating* 8088's
> From: Jim Leonard <trixter at oldskool.org>
> Date: Tue, 20 Nov 2007 19:35:14 -0600
> To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>
>Chris M wrote:
>> --- Alexis <thrashbarg at kaput.homeunix.org> wrote:
>>
>>> You might run into an issue of minimum clock speed
>>> too. I don't know what
>>> the minimum for the 386/486 is. I know RISC
>>> microcontrollers can go down to
>>> DC, but the 8386/486 might not.
Correct they are dynamic internally. The minimum clock is
far slower than most would tolerate (under 1mhz).
>> Presumably the boards these things come with have
>> their own crystals. I would not expect a '486 upgrade
>> for a '286 to run at 8mhz or anything comparable (but
>> Tony could tell us).
>
>They did indeed. Which brings us to why these were stopgaps at best:
>The processing may have been faster, but the memory/bus interface was
>the same, so you were not truly getting the overall performance of the
>real machine (that's why the advertised benchmarks were careful to
>demonstrate how much faster the upgraded machine was compared to how it
>was before, and NOT to a "real" 386).
Some resorted to PLL chips top multiply the existing clock to
something fast.
Allison
>--
>Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
>Help our electronic games project: http://www.mobygames.com/
>Or check out some trippy MindCandy at http://www.mindcandydvd.com/
>A child borne of the home computer wars: http://trixter.wordpress.com/
>
>Subject: Re: *updating* 8088's
> From: "Ensor" <classiccmp at memory-alpha.org.uk>
> Date: Wed, 21 Nov 2007 00:49:26 +0000
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>Hi,
>
> >....but the 8088/86 was available as high as 20mhz IIRC,
> >or possibly even a bit higher....
>
>Hmm, I don't ever recall seeing an XT running at anything like that sort of
>speed.
The higest teh 8088 got in PC or clone was 12mhz. The faster parts appeared
later and for the embedded cpu market.
>Most "Turbo XT" motherboards which I saw topped out at 10MHz, though I have
>a vague recollection of hearing about a manufacturer which produced a 14MHz
>(or possibly even 16MHz) board and then had to quickly withdraw it due to
>MAJOR instability problems.
the biggest problem with XT and fast was teh ISA-8 bus was 8Mhz max and
many older cards would get unhappy at another over that. So you set the
bios for lots of waits slowing the system.
>If you wanted anything faster you generally had to go to a '286 or better.
more or less th case.
Allison
>
> TTFN - Pete.
>
>Subject: Re: *updating* 8088's
> From: Chris M <chrism3667 at yahoo.com>
> Date: Tue, 20 Nov 2007 14:41:39 -0800 (PST)
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>"I ran a Leading Edge model D (PC XT clone) with an
>Intel Inboard-386.
>It gave me 2MB ram and a 16mhz CPU (beats 4.77!) and a
>bottleneck of
>the 8bit ISA. However it ran winders3.1 and was a
>whole lot faster
>than the 4.77mhz V20. At the time it was far cheaper
>than a real 386
>and much better than the 8088."
>
> 3.1 needed at least a 386, no?
Actualy no. However it was so crippled in that mode
it was near useless. It was really 386 minimum.
There was Win3.0
>(prolly same requirements) and Windows/286. This
>wouldn't get you the ability to run any of the above,
>but the 8088/86 was available as high as 20mhz IIRC,
>or possibly even a bit higher. I don't know what the
>'186 capped off at (40mhz at least).
> I thought you didn't like throwaway PCs Allison. What
>did you finally do with that box? Let me guess, you
>threw it away LOL LOL LOL LOL LOL LOL LOL LOL LOL
As a matter of fact I kept the Inboard and tossed the D.
Allison
>
> ____________________________________________________________________________________
>Get easy, one-click access to your favorites.
>Make Yahoo! your homepage.
>http://www.yahoo.com/r/hs
I've just gotten my hands on a working AT&T Sceptre system, which is a
1983 Videotex terminal that implements the NAPLPS standard for vector
graphics transmission (the same sort of graphics that was used by the
Prodigy online service, if you remember that). It powers up fine and
generates the welcome screen, which includes a "Press [Data] to login"
message. Once you press [Data], the screen blanks, and I presume that
it's trying to establish some sort of connection over the RS-232 port.
I've just started poking at the thing and haven't gotten far, as I
need to grab a null modem from elsewhere, but I thought there might be
a chance that somebody out there has the documentation for one of
these things. Through searching about, I'm fairly certain that it's
hardwired to speak 1200/7E1 on the serial port, but what it's
expecting to hear is the question. Just a stream of NAPLPS-encoded
data? Or is there more negotiation to be done?
I have at least found an online source for the NAPLPS encoding itself:
http://netghost.narod.ru/gff/vendspec/naplps/naplps.txt
"Jerome H. Fine" <jhfinedp3k at compsys.to> skrev:
> When I run under Ersatz-11, John Wilson allows
> INSTALL EMEM.DLL
> (this was under V3.1 of E11 and hopefully soon with EMEM32.DLL
> under V5.1 of E11) to access many MegaBytes of PC memory via an
> IOPAGE register.
>
> For example:
>
> BaseReg = 177100
> BaseRe2 = BaseReg+2
> BaseRe4 = BaseReg+4
> BaseRe6 = BaseReg+6
> Mov @#BaseReg,R0 ;Get the current value from PC memory
> Mov R0,@#BaseReg ;Put the current value into PC memory
>
> BaseRe4 / BaseRe6 are used as a 32 bit address into the PC memory allocated
> during the INSTALL process.
>
> Under RT-11, direct access to the IOPAGE (address above 160000) is
> allowed even using VBGEXE by a reference to PREVIOUS DATA
> space. I have written FORTRAN IV/77 interface subroutines to allow
> a user to easily access that memory rather than use VIRTUAL arrays
> which are much slower and have much less capacity.
>
> I doubt that RSX-11 or RSTS/E allow a user access to the IOPAGE
> even via PREVIOUS DATA space. Can anyone confirm this assumption?
> Is there any fast method (only a few extra instructions) that would allow
> a user to reference a specific IOPAGE register from a user program? Are
> VIRTUAL arrays allowed in FORTRAN under RSX-11? If so, how
> is access to the MMU registers controlled and allowed?
>
> Johnny has helped with such RSX-11 questions in the past and the answers
> were appreciated very much!
You assume correctly, in that normal, unprivileged programs cannot normally
access the I/O page on a mapped RSX system.
There are some different answers to how to do this in RSX. I'll try to keep it
short.
First of all, we have unmapped and mapped RSX systems. Unmapped systems don't
use the MMU, so obviously you can access the I/O page on those systems.
When we get to mapped systems, it gets trickier.
First of all, privileged programs normally do have access to the I/O page. It's
mapped in at APR 7 in D-space, unless you explicitly don't want it (that's
something you specify when you do the task build (linking in RT-11)).
Second, RSX manages memory in the form of partitions. Programs can map in memory
regions which are located in partitions, as long as they have the right access
privileges (they are protected by a normal protection mask, just as files). The
system manager can create a special partition, which maps onto the I/O page, and
then user programs can map in that region anywhere in their programs, and thus
have access to the I/O page that way, if they want to.
Virtual arrays in FORTRAN is mapped to a file unless I remember wrong, which
means they don't have anything to do with the MMU.
However, in RSX you can manipulate and remap your address space from a program
if you want to. There are services in RSX to do that in a controlled way. You
attach to a memory region, and then you map whatever part of that region to
whatever part of your virtual address space you want to.
But as I said before, in order to get access to the I/O page in this case, the
system manager must have created a region which is located in the I/O page, and
which users are allowed access to.
With all this said and done, the "normal" way in RSX is to have a privileged
program. After all, fooling around in the I/O page is likely something that
"normal" programs shouldn't do, and for which privileges are a sensible way of
distinguishing if a program may.
I can't really say for sure about RSTS/E, but I think it's atleast somewhat
similar to RSX.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
-------------Original Message(s):
Date: Tue, 20 Nov 2007 17:05:46 -0800
From: "Eric J Korpela" <korpela at ssl.berkeley.edu>
Subject: Re: *updating* 8088's
On Nov 20, 2007 5:34 AM, Cameron Kaiser <spectre at floodgap.com> wrote:
> > > On the other hand, the 386SX could execute 32-bit code. That is, if
> > > you had any to run in 1989.
> >
> > There was plenty of 32-bit code being written in 1989... just not for MS-DOS.
>
> What about games, DOS/4GW, ... ?
I got my 386DX in 89. Very few, if any, MS-DOS games relied on 32bit
extenders at that point. It cut out too much of the market that still
had 16bit processors. It would have been nice not to push so hard to
have 635k low memory free in order to run the latest game.
The most used feature of the 386 was V86 mode, and it was mostly used
to free up memory for 16bit MS-DOS programs.
Eric
---------------Reply:
And then there were the MMUs that gave your PC/XT/AT almost the entire 1MB
for DOS, and up to 10MB or so of extended memory for running Unix, PC-MOS386
and the like on your XT (if you really wanted to)...
m
m
I have seven 5.25" floppies labeled as RX33K which contain:
VAXmate MS-Windows v1.03 (two disks)
VAXmate Info System v1.1
VT240 Emulator Update
VAXmate S/A Install v1.1
VAXmate MS-DOS v3.10
All of these are labeled "For VAXmate operating environment v1.1".
I don't remember where it came from, but there's been some recent talk
about VAXen. Who wants these?
--
David Griffith
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
