old microcode listings
|
Prev: Software vs Hardware
Next: Searching for the PDP-3
From: "Peter "Firefly" Lund" on 5 Jan 2007 10:23 On Fri, 5 Jan 2007, drhowarddrfine wrote: > I've threatened to do something similar for many years. Cool. Good luck to > you. Thank you :) What does your microarchitecture look like? -Peter
From: Eric P. on 5 Jan 2007 11:26 Peter \"Firefly\" Lund wrote: > > On Thu, 4 Jan 2007, Eric P. wrote: > > > Now it has been 30 years, but as far as I remember all microprocessor > > bus protocols had some form of NOT_READY signal to handle slow devices. > > If you know the device is fast enough you just ground the signal. > > How is this different? > > Please google. I did. The first few paragraphs of the newsletter you suggested say http://linux.monroeccc.edu/~paulrsm/dg/dg01.htm "The 68000, when writing data, places the data on the bus and waits for an acknowledgement that the data has been received. This is accomplished by placing a low logic level on pin 10, DTACK (DaTa ACKnowledged). A read is performed by requesting data from a device and waiting until a low logic level is placed on pin 10 which acknowledges that the data is now available on the bus." The remainder goes on about BERR (bus error) signal, which is a different issue than DTACK and the 'asynchronous protocol'. (while these may interact, that is a different issue as address or data parity errors can also trigger BERR if desired). As far as I can see, this 'asynchronous protocol' (their words) is the same handshake as all other bus protocols. (I used the quotes because usually the DTACK or NOT_READY or whatever signal is sampled by the cpu on each clock edge after the transaction is begun. So strictly speaking it is not 'asynchronous'). Eric
From: =?iso-8859-1?q?Torben_=C6gidius_Mogensen?= on 5 Jan 2007 11:30 "Peter \"Firefly\" Lund" <firefly(a)diku.dk> writes: > 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". > > You could consider the partitioning of registers into address > registers and data registers a mistake (I won't but some do). I won't either. There are several advantages in splitting the register file: - You can have twice as many registers with the same number of instruction bits, as which set you use will be implicitly given by the opcode. This is somewhat offset by the need to duplicate some instructions for both types of registers, though. - Without multi-porting the register file(s), you can read/write two registers at the same time (as long as they are of different kinds). Torben
From: Eric P. on 5 Jan 2007 12:00 "Eric P." wrote: > > Peter \"Firefly\" Lund wrote: > > > > On Thu, 4 Jan 2007, Eric P. wrote: > > > > > Now it has been 30 years, but as far as I remember all microprocessor > > > bus protocols had some form of NOT_READY signal to handle slow devices. > > > If you know the device is fast enough you just ground the signal. > > > How is this different? > > > > Please google. > > I did. The first few paragraphs of the newsletter you suggested say > http://linux.monroeccc.edu/~paulrsm/dg/dg01.htm > "The 68000, when writing data, places the data on the bus and > waits for an acknowledgement that the data has been received. > This is accomplished by placing a low logic level on pin 10, > DTACK (DaTa ACKnowledged). A read is performed by requesting data > from a device and waiting until a low logic level is placed on > pin 10 which acknowledges that the data is now available on the bus." > > The remainder goes on about BERR (bus error) signal, which is > a different issue than DTACK and the 'asynchronous protocol'. > (while these may interact, that is a different issue as address > or data parity errors can also trigger BERR if desired). > > As far as I can see, this 'asynchronous protocol' (their words) > is the same handshake as all other bus protocols. > > (I used the quotes because usually the DTACK or NOT_READY or whatever > signal is sampled by the cpu on each clock edge after the transaction > is begun. So strictly speaking it is not 'asynchronous'). > > Eric 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
From: drhowarddrfine on 5 Jan 2007 12:05
Peter "Firefly" Lund wrote: > On Fri, 5 Jan 2007, drhowarddrfine wrote: > >> I've threatened to do something similar for many years. Cool. Good >> luck to you. > > Thank you :) > > What does your microarchitecture look like? > > -Peter I never carried it through. I was putting together a bit-slice system using ttl and, later, 2901s. I did a lot of work with the 68000 with some computers I designed from scratch for work, back in the day when PLAs were fairly new. |