Success w/ 8080 CPU Board EEPROM Adapter...

[Joe Travis N6YPC]

Yesterday, Rick Davis and I celebrated the success of booting the Dual CF Board from EEPROM using the H8 front panel!  Rick was able to "shoehorn" in his DCFBOOT code into unoccupied ROM space between XCON8 and H17 ROMs which were otherwise unmodified.  Congratulations Rick!

The adapter board uses a 28 pin, 32K EEPROM which replaces the 24 pin PAM8/XCON8 ROM on the 8080 CPU board.  Jumpers on the CPU board are set to allow for 8K of ROM to be addressed.  The CPU board settings are:

Jumper P1 - P2

Jumper R1,R2,R3 N/C (not connected)

Jumper S2 - A12

Jumper T2 - A11

Jumper X1 - X2

Jumper Z1 - Z2

IC207 bend out pins 2 & 3 and reinsert into socket

Notes on EEPROM Adapter board assembly:

- You will have to trim the pins which are underneath the EEPROM socket to allow the socket to sit (near) flush on the board.

- Install jumpers A13 - GND and A14 - GND for normal use (you can use these to select up to 4, 8K pages if desired).

- I'd recommend using right angle pins for A13 and A14 if you plan to implement switches for page select.

Regards,

Joe Travis n6ypc

[Douglas Miller]

Very nice, neat and tidy.

Does that EEPROM adapter/mod eliminate the RAM ("Floppy RAM") between monitor ROM and Floppy(H17) ROM (1000H-17FFH)? Or are you just using the remaining space of the 4K range not used by smaller monitor ROMs (0800H-0FFFH)?

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/06083f6c-9a9c-4a00-a941-6720d1726e5en%40googlegroups.com.

[Joseph Travis]

The DCFBOOT code resides at 1000H while the H17ROM is at 1800H, each occupying 2K of that upper 4K segment.  The H17ROM had to be included as we need to reenable the EEPROM in order to run the DCFBOOT code.  This method didn't require any changes to XCON8 or H17ROM both of which continue to operate normally.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/eda9ba66-131b-70ea-dd09-6881acba8d3c%40gmail.com.

[Douglas Miller]

OK, so the DCFBOOT ROM code replaces the RAM at 1000H. The only code I've seen that uses that RAM is a routine in the H17 Floppy ROM, but I've never found anything that calls it. Still, there may be something out there that depends on that RAM, but I'm not aware of anything. Since the H8 only presented RAM at 1000H if the H17 board was installed (the RAM and floppy ROM actually resided on the H17 board), it seems likely that the only potential users would be related to the H17. The H89 was a different story, the RAM and floppy ROM were on the motherboard and always present regardless of the H17.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBAawUJPbM06mkPxoEv7ec_LrBOdMswsXXCrg3UJjobKOw%40mail.gmail.com.

[Joseph Travis]

The RAM space is still there during normal operation. XCON8 copies itself and the H17ROM code into RAM, then disables the ROM. Nothing has changed there.

When using the DCFBOOT, you first reenable the EEPROM (ROM) with the following sequence: MEM 000 362 OUT. To execute the DCFBOOT code, enter: REG PC ALTER 020 000 ALTER GO.  That will display dCF 1-2 on the H8 front panel prompting the user to select which CF channel to boot from. It goes on from there and will boot HDOS or CP/M (very quickly I might add).

More info is forthcoming when I finish updating the documentation.

You received this message because you are subscribed to a topic in the Google Groups "SEBHC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sebhc/Kz9go81SlUQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/02ad63b1-537c-b05b-81eb-55d597612015%40gmail.com.

[norberto.collado koyado.com]

We will need to review the ROM address decoder as it should copy the area between 1000H and 1800H. On the Z80 the HW will protect such area, so it doesn’t get copied, as shown below. This is to avoid using re-enabling the ROM with the following sequence: MEM 000 362 OUT.

 

Great job in getting this to work on such board.

 

Thanks to both for all the help in getting this working,

 

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBB4NJszuHMCoqssQAXCWSpj37qO1Tpb5eTO2%2BVZoNayqQ%40mail.gmail.com.

[glenn.f...@gmail.com]

Nice work! 

--

[Douglas Miller]

Yeah, I did not fully go through the 8080A and H17 boards to see whether this mod would create bus contention. I believe the H17 ROM/RAM is not contending for the data bus at the CPU input, but I'm not sure whether the H8 bus is being driven by two different sources. Probably more of an academic discussion as two sources driving the H8 bus for a microsecond here and there (when no one is looking) probably causes no harm. Still, might be worth checking just to be sure there's no problem waiting to happen.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB38558A2B379052A2295C22D6F7079%40SN6PR01MB3855.prod.exchangelabs.com.

[Joseph Travis]

I considered that possibility and had looked at it.  The H17 ROM is disabled, a mod that occurred when upgrading from PAM8(2K) to XCON8(4k). I see no conflicts on the 8080 CPU board.

Joe

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/4d9a9dfa-1e00-c1d3-c8fc-d25fa53db658%40gmail.com.

[Douglas Miller]

That still sounds suspect to me, as the H17 ROM is mapped at 6K (RAM at 4K), so changing to a 4K XCON8 at 0000H would not automatically/implicitly disable H17 ROM or RAM. Unless you are saying that you intentionally/explicitly disabled the H17 ROM/RAM as part of XCON8, even though the H17 ROM may still be needed in that case.

It looks to me as though the 8080A CPU board will be driving the H8 data bus during on-board ROM reads, and at the same time the H17 board will be driving the H8 data base for (reading of) addresses 1000H-1FFFH - regardless of whether the H17 ROM/RAM chips are installed in their sockets.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBCmSacm7EKasKOea5jBLdmVrS4Gd6nM1BOota3qf9zELw%40mail.gmail.com.

[Joseph Travis]

The mod is done on the H17 board by removing a resistor and capacitor in the upper right corner, then installing a jumper where the capacitor used to be.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/caac1dcf-54c4-e763-7d08-fc0bc09b285d%40gmail.com.

[Douglas Miller]

It looks like the new Z80 V4 CPU board also does the same thing. I guess it's really a problem to be fixed in the H17 board, but at least the original does not have any neat jumpers to change the address decoding that enables the data bus driver.

[Douglas Miller]

I see, forcing MEMR low (off) to disable all/any memory chips resident on the H17. And also preventing the bus driver from being enabled.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBAYo2tjSWZWLBs%3DK20JncQuNogD2ZKExc3vQ6zP5xzXhg%40mail.gmail.com.