Choosing MP/M and CP/M disk sizes, vs. remaining RAM

[durgadas311]

Let me try to explain once more. Here are the cycles being executed:

   ----- Z80 -----   ASIC  Printer-ROM  DRAM
1. M1 MREQ RD   AF   D=AF
2. M1 MREQ RD   D3   D=D3
3.    MREQ RD   F0   D=F0

4. M1 MREQ RD   11   D=11
5.    MREQ RD   02   D=02
6.    MREQ RD   00   D=00

// repeats 256 times...
7. M1 MREQ RD   ED   D=ED
8. M1 MREQ RD   A0   D=A0
9.    MREQ RD                D=(ROM++)
10.   MREQ WR                           (ADR)=D

11.M1 MREQ RD   C3   D=C3
12.   MREQ RD   00   D=00
13.   MREQ RD   00   D=00

14.M1 MREQ RD   D3   D=D3
15.   MREQ RD   F8   D=F8

16.M1 MREQ RD   XX                      D=(ADR)
... bootstrap ...

The issue is that the ASIC only sees the Z80 cycles and it must decide what to assert on the data bus during the reads. Cycle 9 is the key one, where it looks the same as cycles 3, 5, 6, 12, 13, and 15 but it must do something different: get the next byte from ROM instead of insert the byte stream for boot. In order to do that, it must be "aware" of the fact that it is doing an LDI vs. the other instructions and arrange for the correct thing to appear on the data bus ("D").

 

[JohnElliott]

The issue is that the ASIC only sees the Z80 cycles and it must decide what to assert on the data bus during the reads. Cycle 9 is the key one, where it looks the same as cycles 3, 5, 6, 12, 13, and 15 but it must do something different: get the next byte from ROM instead of insert the byte stream for boot. In order to do that, it must be "aware" of the fact that it is doing an LDI vs. the other instructions and arrange for the correct thing to appear on the data bus ("D").

But as far as the ASIC is concerned, "get the next byte from ROM" and "insert the byte stream for boot" are the same thing. It's only the microprogram in the printer controller that needs to distinguish them.

 

[durgadas311]

But as far as the ASIC is concerned, "get the next byte from ROM" and "insert the byte stream for boot" are the same thing. It's only the microprogram in the printer controller that needs to distinguish them.

Are you saying that both the byte-stream and the ROM come from the same place (the printer controller)? So the printer controller must be keeping track of what is to be returned for each read, switching between byte stream or ROM (different segments of ROM) depending on whether it is doing the LDI or not. Does the ROM dump you obtained have both code streams in it?

 

[durgadas311]

Oh, I see your microcontroller disassembly from the comp.sys.amstrad conversation. The byte stream is essentially hard-coded and when it sends the ED A0 it then follows that with the next byte from the boot ROM code. So, this microcontroller implicitly knows when it is doing the LDI and assumes the next read is for the ROM data. The ASIC is only passing reads in "boot mode" to the micocontroller, and the microcontroller knows the state of the stream so it can insert ROM data at the appropriate points. Same thing going on, but a simpler implementation since it is just microcontroller code (software) and not ASIC logic (hardware).