old microcode listings
|
Prev: Software vs Hardware
Next: Searching for the PDP-3
From: "Peter "Firefly" Lund" on 5 Jan 2007 12:26 On Fri, 5 Jan 2007, drhowarddrfine wrote: > I never carried it through. I was putting together a bit-slice system using > ttl and, later, 2901s. But what was your planned VAX microarchitecture going to look like? My intention is to prove that the VAX could be pipelined and could be made fast -- and maybe try out a few microarchitectural tricks along the way. My thesis is that the VAX could have been made fast relatively easily and that the Alpha, however much we loved it, was a mistake. A secondary point is that the VAX family could have been more "self-compatible", i.e. that it wasn't necessary to remove instructions to the degree it was done. I am not so sure about this point, though. -Peter
From: Eric P. on 5 Jan 2007 12:34 "Eric P." wrote: > > Ok I see what they are griping about. It has to do with > non-existent devices and the signal sense. > > If the addressed device/ram is missing, a protocol that requires > an ack to proceed (DTACK) will hang the bus whereas a protocol that > requires an ack to hold (NOT_READY) will not hang. > The former case _must_ be dealt with in every design, > the later case you read junk data but the cpu doesn't hang. > > Eric Hmmm... I looked at some of the above page again, and after a bit more thought this this looks like just a marketing burb to sell their brand of 68000 board and a red herring issue. My statement about which case must be dealt with was in error. In both cases you must ensure the signal is proper in a proper state when a non-existent device is addressed and not allowed to float tri-state to arbitrary logic levels. IIRC the solution was to tie the line to either +5 (DTACK) or ground (NOT_READY) through a 100K resistor. No timers were required to prevent cpu hanging, only if you wanted a trap generated for bad addresses. Eric
From: drhowarddrfine on 5 Jan 2007 12:39 Peter "Firefly" Lund wrote: > On Fri, 5 Jan 2007, drhowarddrfine wrote: > >> I never carried it through. I was putting together a bit-slice system >> using ttl and, later, 2901s. > > But what was your planned VAX microarchitecture going to look like? > > My intention is to prove that the VAX could be pipelined and could be > made fast -- and maybe try out a few microarchitectural tricks along the > way. > > My thesis is that the VAX could have been made fast relatively easily > and that the Alpha, however much we loved it, was a mistake. > > A secondary point is that the VAX family could have been more > "self-compatible", i.e. that it wasn't necessary to remove instructions > to the degree it was done. I am not so sure about this point, though. > > -Peter I'm sorry I confused you. I did not try and recreate the VAX but was doing an architecture of my own specific to an application.
From: drhowarddrfine on 5 Jan 2007 12:43 Eric P. wrote: > "Eric P." wrote: >> Ok I see what they are griping about. It has to do with >> non-existent devices and the signal sense. >> >> If the addressed device/ram is missing, a protocol that requires >> an ack to proceed (DTACK) will hang the bus whereas a protocol that >> requires an ack to hold (NOT_READY) will not hang. >> The former case _must_ be dealt with in every design, >> the later case you read junk data but the cpu doesn't hang. >> >> Eric > > Hmmm... I looked at some of the above page again, and after a bit > more thought this this looks like just a marketing burb to sell > their brand of 68000 board and a red herring issue. > > My statement about which case must be dealt with was in error. > In both cases you must ensure the signal is proper in a proper > state when a non-existent device is addressed and not allowed to > float tri-state to arbitrary logic levels. IIRC the solution was > to tie the line to either +5 (DTACK) or ground (NOT_READY) > through a 100K resistor. No timers were required to prevent cpu > hanging, only if you wanted a trap generated for bad addresses. > > Eric > Yes, that is correct. We would have pullups/downs because tri-state was not allowed. The value depended on the length of the bus and impedance. I want to say the value was more like 1Meg but 100K sounds right, too. I just don't remember. iirc, I had to incorporate an outboard timer to timeout invalid accesses.
From: ChrisQuayle on 5 Jan 2007 13:08
Peter "Firefly" Lund wrote: > > Sure. First of all, they weren't /really/ in same time frame. > The 8086/8088 got there years before the 68K. > > That tends to matter. I wasn't quite sure about some of the dates, so google for a timeline gets: 8080 and 6800 : 1974 6502: 1975 8086: 1978 68k: 1979 So not much time slip between them. > > Secondly, the 8088 could easily use existing peripheral chips designed > for the 8080/8085/Z80. So could the 68k, having 3 pins, enable, vma and vpa pin dedicated to legacy 6800 series peripheral control. > As far as I can tell, the 8086/8088 was also easier to interface with > than the 68000/68008. I'm referring both to how you hook up memory and > I/O devices, how interrupts are handled, and how the initial bootup is > handled. > > That also tends to matter ;) -- but since I'm not nearly as sure about > this point I won't belabor it. I might be wrong here. I guess it depends on how much work you have done with a given cpu, as there is always a learning curve. My x86 hw design is limited, but around '83 I designed memory cards using the then new 64k x 1 bit devices. A 128k card for the 6502 Apple II and a 384k card for the 8086 Sirius (II ?). Still have the Intel iAPX86 users manual somewhere, but remember it being hard work to build any simple mental model for what was required for the design. There were pages that seemed to contradict themselves in terms of timing or other info and if not impenetrable, was quite dense. Bought a 68k eval board later and it seemed like orders of magnitude improvement over anything seen previously. Generous register set and addressing modes, 24 bit flat address space, asynchronous bus to allow a mixture of memory and peripheral access times, multimode, fully vectored interrupts, the list goes on and on. At the time, the architecture was like a wish list in silicon and if not perfect, quite revolutionary. I think what i'm trying to say is that the 68k was one of the first micros to break the old mold mini model of accumulator + index register architecture that was so pervasive in early micro designs. > > As for the programming model, I much prefer the 68000 over the > 8086/8088, if we ignore compatibility issues (which tend to matter). > Even if the 68000 had those annoying alignment issues (which tend to > matter). > > Notice I wrote "68000" and "8086/8088". > Agreed, a delight to program at assembler level. > Some of the 68K models used different exception stack frame formats than > others, without having a compatibility flag. But that doesn't matter, as 68k exceptions are fully vectored, so you always know what generated the interrupt and shouldn't need to poll registers or poke around in the entrails. Or am I missing something ?. Ok, perhaps for debugging. Last time I looked, even the arm cores, current darlings of the embedded telephony and handheld device market, only had a basic 2 level interrupt structure. Should imagine quite helpfull for real time multi interrupting device work ^)... Chris |