May 16, 2022, 2:10:40 PMMay 16
to PAL 6502 computer
Liu is right, it is an interesting (to me anyway) story. :-)
This has to do with where the ROM ended up in the memory map.
A 16K EPROM has 14 address pins (A0 through A13). We use the two "upper" address bits to feed the chip select logic. If we had a ROM from $C000 through $FFFF, the upper two bits would always be 1 (i.e., the binary address would always be something like %11xx xxxx xxxx xxxx). Also, everything is nice and sequential--1K into the EPROM memory space would match with being 1K into the EPROM's memory map location; 2K in also matched up; so does 3K in and so forth.
The problem comes when we shift the EPROM down to $A000 through $DFFF. This was easy to do with the way the KIM originally broke memory into 8 section of 8K each. Instead of needing a lot of decoding logic, we just take the lines that go high for two of those 8K blocks ($A000-$BFFF and $C000-$DFFF) and feed them into an OR gate. This drives the chip select for the EPROM.
Now our EPROM gets selected when we read in that address range. But... The problem is with A13. If we look at the first nibble (first four bits of the address) in binary, it goes something like:
%1010 (for $Axxx)
%1011 (for $Bxxx)
%1100 (for $Cxxx)
%1100 (for $Dxxx)
Those are A15, A14, A13, and A12. If you just look at A13, it is 1 for the lower half of the ROM and 0 for the upper half. That is backwards from the way we would "count" (with 0 first for lower numbers and the incrementing to 1 for higher numbers).
Without the tweak of A13, instead of just copying $A000 through $CFFF to the EPROM's $0000 through $3FFF (assuming the programmer has a base address of $0000), we would have to copy $A000 through $BFFF to the EPROM at $2000 through $3FFF and then $C000 through $DFFF to the EPROM at $0000 through $1FFF.
Or, put another way, the lower half of the KIM's address space for the ROM is mapped to the upper half of the ROM and visa versa.
You could save a chip by getting rid of the address tweaks and handling it "with software" when you program the EPROM. The problem would be that people wanting to make their own EPROMs would need a greater awareness of the hardware.
(There is also the nuance of the bank select capability. Instead of one 16K EPROM, we use half of a 32K EPROM at any given time. But that's another topic and doesn't really change things much.)
When I first started working on the EPROM firmware, I didn't have an EPROM, but did have a 32K RAM chip. I didn't realize there would be an issue until later in the process. That was because the computer was writing things I wanted to test into RAM and it just handled the fact that A13 was 1 for lower addresses and 0 for higher ones. Only when I threw the EPROM programmer into the mix did it become an issue.
In fact, the 32K RAM board has the exact same issue--A13 is "high" for lower memory locations and "low" for higher memory locations. But since nothing but the KIM ever writes to RAM, as long as it is consistent things will work fine. (On the EPROM, we have an EPROM programmer writing the ROM and the KIM reading it--so two devices. That drives the need to do something.)
If you disable the tweak of A13, you will find the problem exactly the way I did. (You won't break anything by doing it so long as you power off first, but the ROM programs won't work.) If you look at $A000 for a few bytes, you will see what is supposed to be up at $C000. If you look at $C000, you will see what is supposed to be down at $A000. I'll admit that puzzled me when I first tried to understand why my "tested" EPROM image didn't work when I replaced the RAM chip with an EPROM. Put the tweak back to invert the A13 line and things are back where you expect.
I left it up to Liu whether to invert A13 because I could change the ROM image to match things either way. I do think that having the tweak on A13 will make it easier for anyone who wants to write their own ROM code.
In the old days, there were actually devices that changed the address and/or pins around on PROMs to "encrypt" them. You could swap D1 and D4, A4 and A8, along with a few others. The traces on the circuit board took this into account in connecting things. On the PROM programmer, there was typically an "adapter" fixture that would swap the same lines in the same way. There was actually an early solid-state electric meter that did this. Think of it like a file cabinet--as long as you know that you put everything starting with a B in the drawer labeled P and visa versa, things are "wrong" and a bit obscure, but it is pretty painless for you to know to look in the P drawer for the folder labeled BANK ACCOUNT. The problem was you could pretty easily trace out the address and data lines. Once you did that and unscrambled things, it turned out that there was a hard coded master password stored in the PROM in plain text.