[cprhodin]

I thought some of you might find these useful. I've recorded and converted to vcd the waveforms of an LA3 and PE EEC-IV coming out of reset. You can download a free viewer from http://gtkwave.sourceforge.net/.

You can discover a lot of information about the memory bus by examining these files. Some interesting observations:

1) The bus does support byte reads from odd addresses.
2) There's no easy way to tell whether the second byte of a read is being latched and used by the CPU.


Chris

[cprhodin]

In the LA3 file You can see an interrupt being taken at 17689 us. The vector fetched is at 0x201A and the ISR address is 0x3733. The first byte fetched from the ISR is at 17693 us.

There's an MULU instruction from 17760 us to 17767 us or 7 us with the LA3 12 MHz clock. The multiply and divide instructions are the longest idle bus periods you'll see.

At 3059 us you can see a byte being fetched from an even address (0x760C). You can see the data read is 0x9F and that the data bus then changes to 0x4C. At 3063 us you can see a byte fetched from the next address (0x760D). In this case the data read is 0x4C and that the data bus then changes to 0x9F. I see this as proof the DAR simply flips the LSb after ever strobe.

Chris

[cgrey8]

...I see this as proof the DAR simply flips the LSb after ever strobe...

I'm not getting that. Your use of a little b in LSb suggested initially you meant bit, not byte. Is that a typo? If so, are you saying that when odd addresses are requested, it returns the word in opposite byte order?

If that's the case, then that's interesting info as it would make sense for the bus to return the byte the EEC is most interested in. In the case of an odd-byte request, it would certainly speed things up to send the odd byte 1st and just to fill the window send the even byte following particularly if the EEC was just going to ignore the even byte in the 1st place. That would free the internal processor to go ahead and start using the byte despite the memory controller still having to deal with the strobe out of the 2nd byte.

[cprhodin]

I was referring to the least significant bit of the data address register. This is the only bit that changes when strobed, unlike the slave program counter that counts up. The ROM adapter designs I've seen assume this to be the case and the waveforms show the assumption to be true.


Chris

[cgrey8]

I'm still not getting it. If you are seeing a transition from 0x9F to 0x4C, that's not a change of only the LSB. 0x9E and 0x9F would be a change of the LSB. Like I said, I'm not getting what it is you are trying to say.

[EFI-Unlimited]

I'm still not getting it. If you are seeing a transition from 0x9F to 0x4C, that's not a change of only the LSB. 0x9E and 0x9F would be a change of the LSB. Like I said, I'm not getting what it is you are trying to say.

9f and 4c are the presented data, not the DAR tArget address. What he is saying, is if you load the DAR with 0x760C, and then infinitaly toggle the strobe line, with each toggle, the presented data will switch between 0x9F and 0x4C, which is the data located at addresses 0x760C and 0x760D.

This is how I have always understood it to work.

Brian
EFI-Unlimited

[cgrey8]

...9f and 4c are the presented data, not the DAR tArget address. What he is saying, is if you load the DAR with 0x760C, and then infinitaly toggle the strobe line, with each toggle, the presented data will switch between 0x9F and 0x4C, which is the data located at addresses 0x760C and 0x760D...

Ok, to expound on this, if you make a call for 0x760D, does this mean that 0x4C (what's in 0x760D) is given 1st, followed by 0x9f (what's in 0x760C)? So I can make byte-size requests of RAM and I don't have to suffer through receiving the even byte I didn't ask for or want? If so, I can see how that is a time-saver and info I wasn't aware of.

[EFI-Unlimited]

...9f and 4c are the presented data, not the DAR tArget address. What he is saying, is if you load the DAR with 0x760C, and then infinitaly toggle the strobe line, with each toggle, the presented data will switch between 0x9F and 0x4C, which is the data located at addresses 0x760C and 0x760D...

Ok, to expound on this, if you make a call for 0x760D, does this mean that 0x4C (what's in 0x760D) is given 1st, followed by 0x9f (what's in 0x760C)? So I can make byte-size requests of RAM and I don't have to suffer through receiving the even byte I didn't ask for or want? If so, I can see how that is a time-saver and info I wasn't aware of.

Not sure if the CPU supports that, but the memory logic appears to.

Brian
EFI-Unlimited

[ender11]

250ns & 400ns STB period. interesting. different freq of cpu?

[cprhodin]

Right, the PE computer has a 7.5 MHz crystal and the LA3 has a 12 MHz. At 3 clocks per bus cycle that's:

1 / (7.5 MHz / 3) = 400 ns
1 / (12 MHz / 3) = 250 ns

Chris