Cubicolor is a 2k game

[+Omegamatrix]

I was reading about Cubicolor here in a Rob Fulop interview. He says it "fit comfortably in 2K of ROM". Eh? What's this? I thought Cubicolor was a 4K game, and if it wasn't someone would have noticed by now. To test it out I took the rom and split it into two 2K halves. Sure enough it worked:

 

Cubicolor_2K.bin

Very impressive that it could all be crammed into a 2K game, Rob!!

 

Now another interesting part. Only one 2K half worked. The other half jammed my emulator real badly and I had to use cntrl - alt - dlt to escape. Intruigued by my discovery, I took the two halves and compared them in HOM3. They weren't even close to being the same. I have learned by now that a 2K game is duplicated in a 4K rom to fill up the space. I contacted Rob and asked if he knew why the 2 halves were different, but he said he didn't know why. I was now really wondering what this code was for.

 

 

Jump ahead a little bit and I was going through Thomas Jentzsch's Listspy when I say a comparision with Cubicolor.

(1/4)															   0  1  2  3
0 Cubo Magico (CCE)··············································   · 98 40  -
1 Cubicolor (Rob Fulop)··········································   =  · 40  -
2 Shootin' Gallery (1982) (Imagic)·······························   =  =  · 22
3 Sky Patrol (Imagic) (Prototype)································   -  - 45  ·

Unique files:	1
Total files :	4

As far as I can read this list Cubo Magico and Cubicolor share 98% the same code. No surprise there as pirate companies usually just change the screen logo. What is interesting is that this comparision is saying that Cubicolor shares some code with Shooting Gallery, and Shooting Gallery shares some code with Sky Patrol. I decided to split all three games (Cubicolor, Shootin' Gallery, and Sky Patrol) into 2K segments and compare them all again to see exactly what parts are sharing the code.

 

(1/1)
  Cubicolor ($0800-$0FFF) 2K (working half)

(2/3)																	  0  1
0 Shootin' Gallery ($0000-$07FF) 2K····································   · 69
1 Cubicolor ($0000-$07FF) 2K···········································   =  ·

(3/5)																	  0  1
0 Sky Patrol ($0800-$0FFF) 2K··········································   · 59
1 Shootin' Gallery ($0800-$0FFF) 2K····································  70  ·

(4/6)
  Sky Patrol ($0000-$07FF) 2K

(5/7)
  Sky Patrol ($1000-$17FF) 2K

(6/8)
  Sky Patrol ($1800-$1FFF) 2K

Unique files:	6
Total files :	8

Now we are talking. This clearly shows that Cubicolor is an unique file. The 2K half that doesn't work in the emulator has a lot of shared code with Shootin' Gallery. What is important here is that both roms only share code between the same addresses ($0000-$07FF). To top it off we also can see that Shootin' Gallery also shares code with Sky Patrol at between addresses $0800-$0FFF in both games.

 

So how did this all happen? My theory is that Cubicolor was burned over an existing WIP of Shootin' Gallery. That's it. Only the code between $0800-$0FFF has anything to do with Cubicolor. I've also seen this happen before in Sea Monster. If you look inside the rom with Bithacker you will see that it was burned over Pac-Man. Sea Monster only takes up 3K, and the last 1K is 100% the Pac-Man rom except for $0FFF (No shit you can see the ghost sprites and Atari copyright in there, hilarious). I once deleted the 1K Pac-Man part in Sea Monster, and it still worked just fine in the emulator.

 

Anyhow the Shootin' Gallery code that is shared is a little bit different from the finished rom. It has a high probabilty of being part of an earlier WIP. A comparision with HOM3 shows 1,982 differences, but this is misleading as it is doing a line by line comparision for each address.

 

file 1: Cubicolor ($0000-$07FF) 2K.bin
file 2: Shootin' Gallery ($0000-$07FF) 2K.bin
0045	01	AD
0046	AD	82
0047	82	02
0048	02	66
0049	66	A9
004A	A8	B0
004B	B0	04
004C	04	4A
004D	4A	B0
004E	B0	2F
004F	2F	2A
0050	2A	4A
0051	4A	26
0052	26	A9
0053	A8	4A

 

 

Here we can see parts of the rom are identical, and just the address is offset. In the above example when it does change it is by one byte (and actually one bit as A stays the same). Other places it changes more, but since large parts are the same it leads me to believe an a partial earlier WIP of Shootin' Gallery is hidden in the Cubicolor 4K rom.

[Rom Hunter]

Interesting.

 

Thanks for sharing, Omega.

 

Just like the Condor Attack - Pac-Man case.

 

BTW: what about Frisco - Pac-Man?

 

Is this a similar case or was there actually code stolen?

 

Edited March 1, 2008 by Rom Hunter

[+Omegamatrix]

Interesting.

 

Thanks for sharing, Omega.

 

What about Frisco - Pac-Man?

 

Is this a similar case or was there actually code stolen?

 

Which Frisco rom?

[Rom Hunter]

The one called Brick Kick, I believe.

 

[+Omegamatrix]

The one called Brick Kick, I believe.

 

I took a look at Brick Kick and the rom in your list 100% matches the rom for Frisco (Home Vision) which is what I used. Frisco is definitely a 4K game as when I chop it into 2K neither halve works.

 

This time I compared Frisco, Pac-Man, and Pac-Man (PAL) all as 1K chunks.

 

(1/1)
  frisco (home vision) ($0000-$03FF) 1k

(2/4)																  0  1  2
0 pac-man (pal) ($0400-$07FF) 1k····································   · 90 38
1 pac-man ($0400-$07FF) 1k··········································   =  · 44
2 frisco (home vision) ($0400-$07FF) 1k·····························   =  =  ·

(3/7)																  0  1  2
0 pac-man (pal) ($0800-$0BFF) 1k····································   · 82 40
1 pac-man ($0800-$0BFF) 1k··········································   =  · 43
2 frisco (home vision) ($0800-$0BFF) 1k·····························   =  =  ·

(4/10)																 0  1  2
0 pac-man (pal) ($0C00-$0FFF) 1k····································   · 88 40
1 pac-man ($0C00-$0FFF) 1k··········································   =  · 45
2 frisco (home vision) ($0C00-$0FFF) 1k·····························   =  =  ·

(5/12)																	0  1
0 pac-man ($0000-$03FF) 1k·············································   · 95
1 pac-man (pal) ($0000-$03FF) 1k·······································   =  ·

Unique files:	5
Total files :   12

 

From looking at this I would say this it is not the same case as Cubicolor. I would say this game was actually hacked out of Pac-Man, but I'm not sure. Perhaps a programmer could take a look? Anyhow three of the four 1K chunks have shared code, and in all three 1K chunks more code is shared with NTSC Pac-Man then the PAL Pac-Man. Do you find that interesting, Rom?

Edited March 1, 2008 by Omegamatrix

[Rom Hunter]

Yes.

 

Thanks!

 

[supercat]

My theory is that Cubicolor was burned over an existing WIP of Shootin' Gallery.

 

I don't think "burned over" is accurate terminology. I would guess it more likely that Cubicolor was loaded into the EPROM burner without erasing the buffer, after the burner had previously been used for something else. If a programmer wrote something like:

  org $1500
 ... 192 bytes of stuff
 org $1600
 ... more stuff

then the 64 bytes from $15C0-$15FF would not be loaded with anything; they would contain whatever was in the programmer before.

 

I wouldn't say those files were "burned over" the old image, since the assemblage is performed in the programmer's RAM. I find it somewhat curious that programmers wouldn't have routinely fill the buffer prior with FF to a load, since doing so would make programming go faster (filling 1K with F's would probably cut programming time by 5-10 seconds when using older chips). There may be some interesting archeology possible by examining such unused areas of game carts, but I would expect that most of what is found would be too fragmented to be useful.

[Thomas Jentzsch]

Very good analysis.

 

And yes, Brick Kick is a hack of Pac-Man (NTSC).

[Thomas Jentzsch]

There may be some interesting archeology possible by examining such unused areas of game carts, but I would expect that most of what is found would be too fragmented to be useful.

Indeed.

 

E.g. there is a lot of unsused "garbage" in Asteroids, but it doesn't contain anything which matches to something I know.

 

Maybe the same EPROM burner was also used for burning ROMs for other systems?

[supercat]

E.g. there is a lot of unsused "garbage" in Asteroids, but it doesn't contain anything which matches to something I know.

 

I wonder whether the master data for making the ROM was submitted on an EPROM. Nowadays one would generally ship a data file (often sending it via email) but given that floppy disk formats weren't standardized, and mailed disks might not be reliable anyway, many companies expected to receive the data in the form of EPROMs. I wasn't in the industry back then, but I remember seeing an order form that asked customers to submit three matching EPROMs. If they didn't all match, the order would be rejected; if they matched and were not blank, they would be assumed correct. Even if the EPROMs were left in a hot mail truck all day and suffered from bit rot, it would be unlikely that anything short of total erasure would cause them to lose the same bits.

[Thomas Jentzsch]

I wasn't in the industry back then, but I remember seeing an order form that asked customers to submit three matching EPROMs. If they didn't all match, the order would be rejected; if they matched and were not blank, they would be assumed correct. Even if the EPROMs were left in a hot mail truck all day and suffered from bit rot, it would be unlikely that anything short of total erasure would cause them to lose the same bits.

Hmm, probably they used three EPROMs to allow instant error correction. Else two of them (or a checksum) would have done too. Just like those tripple redundancies in airplanes and spaceships.

[supercat]

Hmm, probably they used three EPROMs to allow instant error correction. Else two of them (or a checksum) would have done too. Just like those tripple redundancies in airplanes and spaceships.

 

I don't think the requirement of using three was to allow "voting" to figure out the correct state of any mismatched bits. It would, however, essentially eliminate the possibility of undetected bit-rot.

 

Incidentally, while a CRC is better than a checksum in many applications, a checksum which is wide enough not to "wrap" is better than a CRC when verifying the contents of many semiconductor memories. If the right eight bits in a device(*) change from a "0" to a "1", the CRC-32 will be unaffected. By contrast, any bit changing from "0" to "1" will always cause the checksum to increase. If the checksum doesn't wrap, there's no way that changing any non-null combination of bits from "0" to "1" would leave the checksum unaffected.

 

BTW, I vaguely recall that the chip manufacturer would send back a copy of the received code on two non-erasable PROMs, one of which was the complement of the other, along with a printout. If the manufacturer used some sort of hard-to-counterfeit seal to mark the chips, it would be essentially impossible for a customer who discovered a mistake after signing the "proceed" order to undetectably alter their contents to what he would have wanted.

[+Omegamatrix]

I took a look at Sea Monster. There are five roms that I know of:

 

Sea Monster (PAL, Bitcorp)

Sea Monster (PAL, Goliath)

Sea Monster (PAL, unknown)

Sea Monster (NTSC, Puzzy)

Sea Monster (NTSC, CCE)

 

This is another case of there being extra code in the rom that has nothing to do with the game. To prove it I completely erased the each rom from $0C00 - $0FFF, with the exception of leaving $F0 at $0FFD and $0FFF as that was common in all the roms. I ran all five roms in emulation and on the Krok. They all worked flawlessly.

 

I first compared the hacked roms:

(1/5)															0  1  2  3  4
0 Sea Monster (PAL, Bit Corp) hacked··························   · 99 96 89 89
1 Sea Monster (PAL, Unknown) hacked···························   =  · 97 90 90
2 Sea Monster (PAL, Goliath) hacked···························   =  =  · 91 90
3 Sea Monster (NTSC, Puzzy) hacked····························   =  =  =  · 98
4 Sea Monster (NTSC, CCE) hacked······························   =  =  =  =  ·

Unique files:	1
Total files :	5

 

No surprises there. The Goliath rom is a little bit more different then the other two PAL roms, or it might be better to say the Bit Corp and unknown PAL rom are a little more common with each other then the Goliath rom. Lets look at extra code as a new 1k rom and compare it. I'm going back to the original rom and splitting it here.

 

(1/4)															   0  1  2  3
0 Sea Monster (NTSC, Puzzy) ($0C00-$0FFF) 1k·····················   ·100 99 88
1 Sea Monster (NTSC, CCE) ($0C00-$0FFF) 1k·······················   =  · 99 88
2 Pac-Man ($0C00-$0FFF) 1k·······································   =  =  · 91
3 Pac-Man (pal) ($0C00-$0FFF) 1k·································   =  =  =  ·

Unique files:	1
Total files :	4

 

Yeah, it's NTSC Pac-Man that must have been still buffered in the eprom burner (thanks Supercat) when Sea Monster was loaded. I compared the Puzzy 1k and CCE 1k chunks and they matched each other 100%. Surely CCE dumped the Puzzy cart and hacked it, and the NTSC cart at that. This is because the PAL carts don't have Pac-Man in the extra space.

 

(1/1)
  Sea Monster (PAL, Bit Corp) ($0800-$0BFF) 1k

(2/4)																  0  1  2
0 Sea Monster (PAL, Unknown) ($0C00-$0FFF) 1k·······················   ·100 70
1 Sea Monster (PAL, Bit Corp) ($0C00-$0FFF) 1k······················   =  · 70
2 Sea Monster (PAL, Goliath) ($0C00-$0FFF) 1k·······················  51 51  ·

(3/5)
  Space Tunnel (PAL, Bit Corp) ($0C00-$0FFF) 1k

Unique files:	3
Total files :	5

 

Again the Bit Corp and unknown PAL rom match each other more. By looking inside the rom I noticed earlier data including the Sea Monster sprites repeated themselves in $0D00 - $0DFF of the Bit Corp and unknown rom. I don't know if Bit Corp was the original company or they were pirating these, but the buffer wasn't erased and the graphics and some data appear here again. The Goliath rom however had graphics from Space Tunnel. It looks to me like Goliath was pirating these two titles at the same time, one after the other, lol.

 

It was the human eye that saw these differences. I'm thinking this Clonespy is only set up to display differences above a certain % ? How does it work, Thomas? It didn't match any percentage of the Space Tunnel ($0C00-$0FFF) and Sea Monster ($0800-$0BFF) rom to anything, but believe me there are graphics common in both to Sea Monster either from Goliath or Bit Corp there.

[Thomas Jentzsch]

It was the human eye that saw these differences. I'm thinking this Clonespy is only set up to display differences above a certain % ? How does it work, Thomas? It didn't match any percentage of the Space Tunnel ($0C00-$0FFF) and Sea Monster ($0800-$0BFF) rom to anything, but believe me there are graphics common in both to Sea Monster either from Goliath or Bit Corp there.

CloneSpy uses a default threshold of 33%. Try reducing that by using the -t param.

[+Omegamatrix]

There we go.

 

(1/5)															0  1  2  3  4
0 Sea Monster (PAL, Bit Corp) ($0800-$0BFF) 1k················   · 28 28  6 23
1 Sea Monster (PAL, Unknown) ($0C00-$0FFF) 1k·················   =  ·100 70  5
2 Sea Monster (PAL, Bit Corp) ($0C00-$0FFF) 1k················   =  =  · 70  5
3 Sea Monster (PAL, Goliath) ($0C00-$0FFF) 1k·················   4 51 51  · 35
4 Space Tunnel (PAL, Bit Corp) ($0C00-$0FFF) 1k···············  15  3  3 29  ·

Unique files:	1
Total files :	5

[Thomas Jentzsch]

Interesting.

 

A few bytes always match even when the games a completely different, so anything below ~10, 15% is usually just noise.

[+Omegamatrix]

Interesting.

 

A few bytes always match even when the games a completely different, so anything below ~10, 15% is usually just noise.

Yeah, I have no idea. I'll PM you those 1k chunks I used. Perhaps it is just because they are only 25% of the rom or the location.

[Thomas Jentzsch]

Yeah, I have no idea. I'll PM you those 1k chunks I used. Perhaps it is just because they are only 25% of the rom or the location.

Actually, you understand a lot.

 

All those values above 20% indicate identical data or code.