toddpw@tybalt.caltech.edu (Todd P. Whitesel) (05/15/89)
after re-reading the following post I realize that much of it borders on 2nd
degree flaming so I should put a pre-disclaimer here.
I've been hacking the venerable old //+ for years, and am starting to build
a //e-compatible motherboard with an IOU and MMU and a timing PAL of my own
design. After looking into the //gs hardware documentation and playing with
my roommate's //gs, I have some rather harsh opinions on the design of the gs.
I am sure that if I had watched them designing it I would have agreed with
almost everything (except the lack of a fast bus) because I believe the design
team had other considerations which I am not aware of when they committed to
certain aspects of the //gs. Please take the following with a grain of salt,
but don't dismiss it either. I feel I have some legitimate goals for the //.
(Now if I can just get a job at Apple for long enough to do any of this...)
---------------------------------------------------------------------------
why does the //gs bend over backwards to support the original bus? It could
have supported say four slots and used the extra board space for a "fast bus"
for extra memory expansion cards (or extra video or coprocessor/acceleration
boards) rather than forcing all the expansion in the machine to be bottlenecked
through either the old bus or the ONE memory expansion slot (the RamKeeper and
other schemes which hang all kinds of stuff).
even with the slow bus why isn't bank addressing by muxing with the data bus
(a la 65816) supported for DMA? the DMA register is a horrid kludge that could
have been avoided (IMHO). also, i can think of a quickie circuit that takes
phantom slot cards and makes them work. (all you do is ground A15 unless an I/O
access is being performed. Doing this with bank 0 rom addresses would allow INH
cards to operate correctly if there was a bit to slow those rom accesses (bank
0 only) so that INH cards would see either a valid address and 1 mhz access or
an internal RAM access which they don't touch anyway. To this date I know of no
cards that INH anything other than the BSR/ROM area, D000-FFFF.)
also, why isn't Western Design working on a 6516 (full 16 bit data bus) or
6532 (eventually)? They will certainly be able to sell the 65832 to (a)
//gs owners who want a hardware-back-compatible chip with more power, or (b)
the microcontroller market (need 32 bit math but only want an 8 bit data bus?
no problem!) but for much else they have got to be kidding. Not to knock it,
I have a 65802 in my //+. But I for one would like to see either a faster chip
(AE's Transwarp gs is nice but looks to be a bit kludgy) or a wider data bus.
We thought up a "mini-cache" system that would work with the '816 but was just
a bunch of latches, buffers, and some glue PALs, and was simple enough that it
could be done on chip. Sadly, i have not the resources to back my words, but
we do have a VLSI lab here at Caltech. I wonder. Anyway, back to the griping:
One of the things that many people with other computers (the IBMers and Amiga
people are the most obnoxious, and i've caught a few mac owners with the same
opinion) snicker about when faced with the Apple // is that the machine has no
serious balls. (With the exception of the ADB microcontroller, which could have
been implemented with a Rockwell R6500/02 and some buffers. (not sure of the
part number, the microcontroller should have 128 ram, 4k rom, and a 6522
essentially on chip) but bravo, the gs can use more processors to share the
work, especially since they are now cheap).
The early macs had lots of fun dealing with appletalk packets coming in
(interrupts every 95 usec with 3 bytes to queue each time) and the //gs (i may
be wrong here, someone correct me) does even worse, because even in fast mode
it has only 260 cycles to deal with those packets, and the interrupt processing
must have been designed with this in mind. (Love that state register, because
interrupt overhead in the enhanced //e is nasty even with a 9600 baud serial
card, where a BSR-based dedicated interrupt handler has no problems.)
Another annoying feature is that the video ram was forced to be 1 MHZ write.
This is another thing that couldn't have been fixed until after the gs came out
because the 32K by 8 SRAMs weren't available. 4 of these in surface mount and
the processor and video accesses could easily be interleaved because the access
times buyable (120 ns) are just fast enough to run them on 7M, the 65816
could be run at 3.58M with the FPI synchronizing it so that phase 1 occurs on
video access, still a speed improvement.
also, where is the hardware DMA support for the 65xx family? The '816 block
move instructions take seven cycles to execute when the theoretical minimum is
two. Granted it would take extra chip real estate for post-incrementing X and Y
registers (which would be nice to have anyways) instead of a tad of extra
microcode, or state entries, or however it keeps track of where in an
instruction it is. I've often considered buying a DMA chip and rigging up a
card to do .5 Mbyte/s Block moves (still a bit faster than MVP in fast mode).
However, the ones that do the job right (Z80-DMA, intel 8237--I think) insist
on that needlessly complex & overkill bus structure which one of my friends has
pronounced brain-dead on many occasions. The 6844 is easy to interface to the
Apple (6800 and 6500 being similar in the bus department except all the 68xx
chips need chip select a bit too early for one to use DEVSEL or I/OSEL on them
--the 6522 and 6551 also, it seems, sigh...) but its interface logic is a minor
pain. in order to get around such inconveniences as the "dead" cycles between
bus ownership changes and the blind block transfer once started, enough glue
has to be added that one wonders why no one thought of designing a chip just
for the apple's DMA conditions. I could do it with a bunch of PALs programmed
as tri-state counters, but then you need a five-or-so chip set for each channel
and while you can get away with two (1 read, 1 write for block xfers) for most
needs ("port" ramcards like the memory expansion card or RamFactor and block
transfers being foremost, printer buffers and graphics cards also I suppose).
A buffered controller for the disk ][ and the dumb 3 1/2's would also be nice
(make interrupts easier to deal with and easy to interface to ProDOS). A scheme
like the Workstation card could be used, with the hardware and a 6502 with some
static ram, an IWM, and some form of control connection (not sure what.) Here
is where DMA would be nice, but putting all the support on the one card would
get rough unless Apple's custom chip department saves the day.
I'm running out of steam about here (amazing) but I think the real problem is
that the Apple // has long since been passed up in the realm of current
technology, partly from sparse support for the 65xx, but just because its raw
cpu power is wimpy by most people's standards (just take a look in comp.arch
sometime--sheesh), it is not necessarily dead. The Apple // could become a
distributed processing machine, with the main cpu running applications and
controlling everything else like video, disk, appletalk, each of which would
have specialized coprocessors or old 6502s which is the processor of choice
for the disk ][ and appletalk because it's cheap, easy to support in hardware,
and easy to develop for. Now I don't expect any of this to materialize out of
thin air, but I often begin to wonder if Apple could use some "Hardware
Evangelists" for the //.
Todd P Whitesel
toddpw @ caltech.bitnet
toddpw @ romeo.caltech.edu