Using 27C512 EPROM in place of 28C256 EEPROM

Home Forums Z80 Playground Early-Adopters Using 27C512 EPROM in place of 28C256 EEPROM

  • This topic has 2 replies, 2 voices, and was last updated 6 months ago by teg.
Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
  • #1000

    Just in case this is of interest to others, it is possible to use the 27C512 64k EPROM instead of the 28C256 32k EEPROM without hardware modifications. I have quite a few of these so was keen to put them to some use.

    The nearest logical equivalent EPROM (27C256) has pinout differences that would require some wire strapping. The Z80 Playground EEPROM socket pins 1 (A14) and 27 (nWE – tied high) would map to Vpp and A14 on the 27C256 EPROM.

    However, on the 27C512 EPROM, the mapping is:
    Z80 Playground A14 -> EPROM A15
    Z80 Playground nWE(5V) -> EPROM A14

    Since A14 will be permanently high, only half the EPROM will be available, and since A14->A15, the Z80 will access the 2nd and 4th quarters of the 64k EPROM when addressing the 1st and 2nd 16k blocks of the 32k EEPROM.

    Therefore, a 27C512 can be used if the 32k of ROM data is mapped as follows:

    28C256         27C512
    32k EEPROM     64k EPROM
    **********     *********
    4000-7FFF  ->  C000-FFFF
                   8000-BFFF (area unused)
    0000-3FFF  ->  4000-7FFF
                   0000-3FFF (area unused)

    I wrote a small python app to convert a 32k binary image into a 64k binary with the above mapping.

    import sys
    if len(sys.argv) != 3:
        sys.exit('Usage: in_filename.bin out_filename.bin')
    binary_file = open(sys.argv[1], "rb")
    data =
    out_file = open(sys.argv[2], "wb")
    out_file.write(b'\xFF' * 16384)
    out_file.write(b'\xFF' * 16384)

    David Tegerdine

    • This topic was modified 6 months ago by teg.

    That’s a good tip, thanks!
    One thing I thought of was to make the eeprom WR line be connected to something that the CPU has control of, such as one of the 16C550 user outputs. That way the Z80 Playground could itself be an eeprom programmer. I’m still considering it for a future release of the PCB. What do you think to that idea?


    I think that would be useful, although I suppose there would be a small danger of runaway code accidentally corrupting the EEPROM. The Software Data Protection mode could be enabled (i.e. writes need a special sequence) to mitigate this.

    If used with the 64k EPROM as I described, it would also allow two different 32k ROM images to be mapped in under software control.

Viewing 3 posts - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.