jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) (01/04/89)
To all Mac Hardware Gurus:
I am planning to build a hardware monitor for a Mac SE. The monitor will
be constructed on an expansion card and will record all CPU instruction
fetches. That is, it will record what instruction was fetched (including all
extension words) and at what address the instruction was fetched.
The monitor will have a small (approx. 16K) amount of static RAM which will
be used as a buffer. The monitor will also have its own serial port which will
be connected to a 2nd Mac's built-in serial port. When the monitor's
static RAM buffer fills, the buffer's contents will be sent through the
monitor's on-board serial port to the 2nd Mac, using a standard serial
communications protocol. The 2nd Mac will save the data it receives to disk
for later analysis.
And now the questions:
1) When the static RAM buffer fills, the Mac being monitored must be stopped
while the buffer's data is sent to the 2nd Mac. The Mac must be
stopped because the time needed to send 16K of data over a serial line
is MUCH longer than the time it takes for the Mac to execute an
instruction. (In fact, several thousand instuctions could be executed.)
I plan to stop the Mac by asserting the BR pin (Bus Request), thus
gaining control of the bus and preventing further instruction execution.
When the serial tranfer is complete the monitor will release control
of the bus and allow the Mac to resume instuction execution.
Will such a strategy cause any problems? In particular, what if the
Mac is in the middle of a disk access when the monitor asserts the BR
line?
2) Could someone recommend a TTL-compatible chip that would handle the
serial interface between the monitor and the 2nd Mac with a minimum of
hassle?
Please E-Mail me your comments. I appreciate any and all help.
Thanks.
-- Jeff Kuskin
EMAIL: jskuskin@eleazar.Dartmouth.Edu
.jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) (01/30/89)
A question for Mac hardware types: I am designing a hardware monitor for a Mac SE. It will be constructed on an expansion card and will record (in onboard SRAM) all CPU instruction fetches. That is, it will record the address from which the instruction was fetched as well as the instruction itself. To determine the address of the fetch I simply have to store the data on the address bus when /AS (Address Strobe) falls. (I also have to examine the FC2-0 lines to determine if the 68k is making an instruction fetch in the first place, of course.) The instruction itself will appear sometime later on the data bus. The problem: What signal can be used to latch the instruction off the data bus? My initial thought was /DTACK, but the "Designing Cards and Drivers for the Mac II and SE" book says that /DTACK is generated by the BBU well before the data bus is valid. (Specifically, the BBU generates /DTACK in bus cycle state S4 while the data bus is not valid until 15ns into state S7.) Furthermore, the book says that the data bus must remain valid only until /AS or /CAS rises, whichever occurs first. But the timing diagram in the book (Fig. 13-2) shows /AS rising in state S7, therefore seeming to imply that /AS could rise before the data bus was ever valid (and you thought the Mac didn't have DMA...) So, the question remains: What signal can be used to latch valid data off the data bus during a RAM read cycle? Will /PMCYC going high in state S0 do the trick? Thanks for any insight. Please e-mail your comments to: jskuskin@Eleazar.Dartmouth.EDU -- Jeff Kuskin, Dartmouth College