Spectra IV Program Code Information Memory Mappings $000 .. $027 display digits (player 4 comes first) $040 .. $06F lamps $070 .. $07F solenoids $180 .. $19F switches and sounds (through a 6532 RIOT chip) $080 .. $0FF non-volatile RAM (battery-backed) $100 .. $17F 6532 RIOT RAM $400 .. $7FF U5 ROM $800 .. $BFF U4 ROM $C00 .. $FFF U3 ROM Notes on how the indirect codes jump are used in this program. Originally thought to be in error - see 'Faulty Code' notes below. Interesting code bit here: 0A24: BD F6 0C lda $0CF6,x 0A27: 85 31 sta $31 0A29: BD DB 0C lda $0CDB,x 0A2C: 85 32 sta $32 0A2E: 6C 31 00 jmp ($0031) This will load the address to be executed after closing switch #x into two RAM bytes ($031 and $032), then takes an indirect jump there! The tables are here: sw #: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 -------------------------------------------------------------------------------------- 0CDC: 0F 04 04 04 04 04 04 05 05 05 04 04 04 04 04 05 05 05 05 05 05 06 06 06 06 06 0F OCF7: E6 20 39 56 8A 8A 8A F1 F1 D2 AD AD F5 F2 F5 34 46 68 72 88 A8 00 00 00 00 00 F2 So switch #1 (outhole) will jump to $FE6, switch #2 will jump to $420, and so on! Looking at the code jumped to by switches #22 to #26: 0600: BD 46 0B lda $0B46,x We know the X register is used to store the switch number, so they just corrected down the load offset by $16 (first possible switch) to load in the correct value corresponding to the switch that was made: $B46 + $16 = $B5C And really we find the correct values here: 0B5C: 25 26 22 28 2A Regular code starts right behind those 5 data bytes. Original email notes about possible faulty coding: It seems that the code we have now contains a few flaws, only not caused by a bad dump, but by actual *programming bugs* on Spectra's side! Attached find the disassembled code of the game, as well as a list of commands perfoming indirect loading from various parts of ROM space. The good thing is, all the jump references are valid, meaning there is no jump target outside the code area. This is usually a sign for clean dumps, so that's good! The bad thing is, some of the indirect addresses would result in reading data from ROM areas that are, in fact, executable code - which is pretty much impossible; of course it's *theoretically* feasible to re-use code as indirect data but it's not done that way - by nobody on earth! The bad references are marked by "!!!" on each line. The lines just marked by "?" refer to the byte immediately *before* the start of a data block, which is fine I guess, if you increment the counter before reading out the data. These here are the two most notable odd accesses: 0DDA: B9 EB 0E lda $0EEB,y !!! 0DE0: B9 F2 0E lda $0EF2,y !!! They point right in the middle of executable code (see files). I tried to change the addresses to redirect them to the block starting a few bytes later ($0EFB and beyond), but that didn't change the faulty behaviour... :/ Chip connection to board: I have also been spending some time sorting out the ROM. After looking at the board really closely, at one time, it had all three ROMS on it. It looks like the original batteries leaked and the three ROMS were replaced with either one or two ROMS and the socket for the middle ROM was removed. It was not a factory mod because there are still traces of the original ROM socket (or ROM) legs in the holes in the traces for the middle ROM. If I get some time this weekend, I will remove all three sockets, clean the traces and trace them with the conductive pen where needed and put new sockets in. The guys that replaced the ROMs for you, replaced the 82s181 ROMs with a fast 2732A ROM. The original ROMs had an access speed of 80nS. The fast 2732A has an access speed of 100nS or so. I don’t know if this will cause a problem, but I am going to check with a friend that can burn just about any ROM in existence and see if he can get a set of three compatible ROMs burned from the image in the single ROM. I don’t know if that is the problem, but if we can get it back to the original 3 ROMs, we can check that off the list of issues. It has taken some time to figure out what they did to make a 2732 ROM function, and the hack is really pretty clever. The original ROMs use a unique method for determining if the CPU is trying to read from each ROM. Most modern ROMs have a single pin (normally called CE for Chip Enable) and there is some logic to turn that pin on when that address range is requested by the CPU. The 82s181 ROM chips use 4 lines to determine if they are being accessed (!CE1, !CE2, CE3 and CE4. The exclamation mark is read as NOT in Boolean logic.). The three chips use address lines A10 & A11 to determine which chip is being accessed. This is the function of the little block of jumper wires (J13-J16) next to ROM 3 (U3). On ROM 1 (U5): - !CE1 is tied to ground (turning it ON) - !CE2 is tied to A11 - CE3 is tied to +5V (turning it ON) - CE4 is tied to A10 So that when an address in the range 0x0400 to 0x7FF is requested line A11 is OFF (turning !CE2 ON) and A10 is ON (turning CE4 ON). This makes all 4 Chip Enables ON and the data is read from ROM 1. On ROM 2 (U4): - !CE1 is tied to ground (turning it ON) - !CE2 is tied to A10 - CE3 is tied to +5V (turning it ON) - CE4 is tied to A11 So that when an address in the range 0x0800 to 0xBFF is requested line A10 is OFF (turning !CE2 ON) and A11 is ON (turning CE4 ON). This makes all 4 Chip Enables ON and the data is read from ROM 2. On ROM 3 (U3): - !CE1 is tied to ground (turning it ON) - !CE2 is tied to ground (turning it ON) - CE3 is tied to A11 - CE4 is tied to A10 So that when an address in the range 0x0C00 to 0xFFF is requested line A10 is ON (turning CE4 ON) and A11 is ON (turning CE3 ON). This makes all 4 Chip Enables ON and the data is read from ROM 3. Because the 2732 is a larger capacity chip, it has a larger address range and it contains A10 and A11 addressing lines built in. So those lines just need to be mapped to the correct pins. (Please see Chip-Board-Map.jpg for image) I don’t have the board right in front of me, but IIRC the jumpers may need to be reconfigured. I’ll take a look at it again tonight. I will also dump the ROM and see where they burned the code image. It is possible that they burned the code in the wrong ¾ of the ROM. It needs to be burned from the high memory end with the last 1K blank.