Please see comments embedded below.
Dick
-----Original Message-----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Saturday, July 03, 1999 6:55 PM
Subject: Re: OT: A call to arms (sort of)
>
> With the ISA, it depends on the TYPE of DMA you use. If you use one of
the
channels on
the motherboard, there sould be no problem. It's only a bit
shaky if you try to run it from the bus itself. That's because of
Sure. But the Unibus/VME/etc way where the _peripheral card_ generates
the addresses for DMA (rather than there being a central DMA controller)
is a lot cleaner IMHO
Yes, it is, and with the PC motherboard gone, there's nothing to prevent one
from using that method.
> motherboard features. Since there's to be no motherboard, i.e. only a
> passive ISA backplane, that shouldn't be a limitation. It's not
necessary,
Eh? If you're going to have an ISA bus (meaning a bus where you can stick
standard PC expansion cards) you _have_ to have the DMA controller. Even
an FDC card really needs it. You can't start suddenly redefining odd
signals and call the result ISA.
Leaving off the motherboard doesn't change the BUS to something else. There
have been systems with multiple processors on passive backplanes for the ISA
for years. You don't have to change one signal. Of course, if you leave
off the motherboard, i.e. the circuitry that makes it a PC, then you don't
have to use the otherwise useless 4x-color-burst crystal oscillator either,
and you don't have to generated that inane 18... Hz interrupt and can use
something sensible instead, and you don't have to generate refresh addresses
with one DMA channel, and you don't have to use DMA for the floppy which
will work fine without it, and . . .
Of course you can have a similar bus with mostly the same signals, but
with bus request/grant signals and an arbitration scheme like
Unibus/VME/etc. But most ISA cards would _not_ work on thse bus.
in general, to have DMA, first because the
processors used on PC
motherboards have block transfer operations which operate at the bus
bandwidth.
Why do you assume that ISA -> Intel processor? It may be something
totally different, something that doesn't have efficient block transfer
instructions.
Now you're confusing me . . . you just got through saying that the PC has to
be there, Intel and all, or it's not an ISA bus. Perhaps you spoke (sic)
too soon? I made no such assertion! There are lots of processors which
have block transfer instructions which operate at the bus bandwidth. Even
the Z80 did that.
>
> The only things which would be inherited from the adoption of ISA as an
open
> bus would be the connector and the signal
definitions. I see nothing
wrong
> with those. One could even punt the 14.318 MHz
(4x color-burst)
oscillator
I see a _lot_ wrong with the ISA signal definitions. For one thing the
IRQs are edge triggered, active high, when any sane designer would make
them level triggered active low (had IBM done this it would have cost
them an extra couple of TTL chips on the PC motherboard. It would also
have allowed the sharing of interrupts). For another thing there's no
proper bus request/grant (multiple masters are almost essential IMHO).
You're certainly right about that! All that would have been needed is that
they swallow their pride and use a sensible interrupt handler instead of
their silly 8259. In fact, they should have left all their LSI's off the
MB. The way their counters work, or don't, and the fact they're slow, and
they're ripple counters so you have to read half of them twice . . . don't
get me started . . .
Of course if you're going to "fix" the mistakes, then maybe a few changes
are warranted, including a provision for multiple masters. I find multiple
masters on a single backplane of limited value. It's easy enough just to
have a drawer for each processor and let them talk to one another on a
high-speed LAN. Now that multi-Gb LANs are becoming more visible, no pun
intended, those'll be the next great leap. Changing the way the signals
work is not such a sin, since you still use the same bus definitions. A
little improvement on the ISA could go a long way.
in favor of a more useful one, or perhaps none at
all.
That clock (which, BTW is not synchronised to anything else necessarily)
is the least of the problems.
well, if you use a color board, or a frame grabber which assumes NTSC
timing, it may want that to be there.
>
> The types of boards useful in development don't need a lot of
documentation
> to be used outside the MSDOS/PC world. The base
locations of the 8250's
on
As I understand it, the aim is to make a PC (meaning something that runs
a useful open OS like linux or *BSD) and which has 'modern' features like
a good video card. Not to make the equivalent on an S100 system
> I/O boards is know, the base of the printer port (twisted though it is)
is
The base address of the printer port is no more twisted than that of the
serial ports. I've read the ROM source code, and the routines that set up
the address table are _very_ similar.
That was an error, i.e. i had an indefinite antecedent for the pronout
"it"
in that I meant that the way the parallel port works, with some of its
signals inverted, etc, was twisted. An address is just an address.
Basically, the ROM looks for printer ports at 0x3bc, 0x378, 0x278 in
order. It assigns each one it finds to the next available 'LPT number'.
What this means is :
If you have a single parallel port at _any_ of those addresses, it will
be LPT1.
If you have 3 ports they will be LPT1 (0x3bc), LPT2 (0x378), LPT3 (0x278).
If you have 2 ports, the one at the 'first' address in the table will be
LPT1, the one at the later address will be LPT2.
Serial ports are similar. It looks for 8250s at 0x3F8 amd 0x2F8. It
assigns the first one it finds to COM1, the second one to COM2. In other
words, if you have a single RS232 port at 0x2F8, it will be COM1.
> known, and one doesn't need a video board right off the top. The
WD1003-WAH
board is well
uderstood and the EIDE interface emulates that pretty well.
Sure. Now where do you propose getting schematics for this I/O card, and
where are you going to get a data sheet on the ASIC that almost certainly
appears on it. This is supposed to be _open_ hardware. This implies full
schematics, not undocumented PCBs.
No ASIC, just the WD 1010 which is thoroughly characterized in the old
databooks and datasheets. maybe a few other garden variety LSI's of the
early '80's. I probably have it somewhere, but there was a time when I had
the 1010 and 2010 pretty well memorized. The BMAC is an 8042 with some code
and a peek at the application notes for the 1010 will tell you what's in the
1100. Since MFM is pretty much history, or, more correctly, the drives
which used it, I'd say that's a non-issue. You don't need the schematic,
though,since the board you'll be using will be an IDE interface with onboard
FDC. Those (FDC's) are well characterized and all you need to know about
the 1003-WAH is the command set, since IDE still uses it.
The little IDE interface boards with 5 TTL's on them are easy enough to buzz
out and understand. Data on the LSI's is easy enough to get, though you
shouldn't need it if you read the data on the WD 1003 controller board.
-tony