Please see comments embedded below.
Dick
-----Original Message-----
From: Tony Duell <ard_at_p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp_at_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
>
Received on Sat Jul 03 1999 - 20:59:25 BST