Harmony as a CopyCart

[Omegamatrix]

Your dumps are looking good. Bump 'n' Jump, James Bond, and He-Man were all exact matches.

 

@Batari, why does FA always have $E9 at the hotspots and ram?

 

 

I see the E7 detection wasn't working for Bump 'n' Jump though. It was always detected as 3F. So this needs working on.

 

 

Mr. Do!'s Castle is showning the same bits different. I believe it is being dumped correctly by your dumper so 4 possibilities exist.

 

1) It is an alternate.

2) The rom out there is a bad dump, and this one is good.

3) Your cart is damaged, and that's why the dump is different.

4) Both yours and the dump out there are no good. Could you imagine? Very unlikely.

 

So I'll look this weekend at what's going on, unless someone else takes a peek in the meantime.

 

 

 

Burgertime is showing all $FF between $1000 and $1FFF. I wonder if this is correct? Here is what is puzzling. $0000-$0FFF is duplicate code at $1000-$1FFF in the rom out there. So was this done by M-network or someone piecing together the rom? It seems to me that your dump is good AJ. I don't see any reason why the dumper would wipe out this area, and the game seems to play okay (I only played it a little bit). So either this is yet another alternate, the true rom, or randomness of the Universe.

 

 

Now IIRC there was also a rumored alternate for Burgertime, however this wouldn't be it (I think, not 100% sure). The alternate was supposed to have different gameplay. If we get any more alternates I'm going to start watching X-Files reruns.

[Omegamatrix]

Just tried Mountain King, and it seems like FA is working again for auto-detection and forced dumping.

[A.J. Franzman]

You know that all three known E7 carts are configured differently, right? According to Kevin Horton's Sizes.txt, only He-Man uses the full 16K of ROM, and only BurgerTime uses extra RAM.

 

E7: Only M-Network used this scheme. This has to be the most complex method used in any cart! :-) It allows for the capability of 2K of RAM; although it doesn't have to be used (in fact, only one cart used it- Burgertime). This is similar to the 3F type with a few changes. There are now 8 2K banks, instead of 4. The last 2K in the cart always points to the last 2K of the ROM image, while the first 2K is selectable. You access 1FE0 to 1FE6 to select which 2K bank. Note that you cannot select the last 2K of the ROM image into the lower 2K of the cart! Accessing 1FE7 selects 1K of RAM at 1000-17FF instead of ROM! The 2K of RAM is broken up into two 1K sections. One 1K section is mapped in at 1000-17FF if 1FE7 has been accessed. 1000-13FF is the write port, while 1400-17FF is the read port. The second 1K of RAM appears at 1800-19FF. 1800-18FF is the write port while 1900-19FF is the read port. You select which 256 byte block appears here by accessing 1FF8 to 1FFB.

 

MOTU: Power of He-Man 16K E7

Burgertime 12K +RAM E7

Bump 'n Jump 8K E7

From your description, I would guess that the available binary has duplicated code in the RAM location.

 

Also, he mentions that E7 is similar to 3F, which I'm sure is why Fred's having difficulty getting the dumper to correctly distinguish BurgerTime as E7.

Edited October 27, 2010 by A.J. Franzman

[Omegamatrix]

From your description, I would guess that the available binary has duplicated code in the RAM location.

 

 

I don't know. The ram is only 2k, and this is 4k of data. I was reading Kevin Horton's description earlier. E7 is a little tricky to get a hold of, but I think there are 8 banks or slices available to the rom (max). $1EE7 is the hotspot to replace the last bank with ram (getting access to the ram).

 

 

I didn't know all the E7 carts were different, but I sort of remember CPUWIZ saying something about Burgertime being only 12k.

[A.J. Franzman]

Well, if it's a 12K cart with a 16K-capable banking scheme, it stands to reason that "something weird" (undefined) should happen if attempts are made to access the 4K that the cart isn't designed use.

[Omegamatrix]

Well, if it's a 12K cart with a 16K-capable banking scheme, it stands to reason that "something weird" (undefined) should happen if attempts are made to access the 4K that the cart isn't designed use.

 

I agree. I'd like to know what the inside of that Burgertime carts is doing (I'm not asking you to rip apart your cart here please don't do that!). You must have all 24 pins on the chip, but inside $1000-$1FFF might be wired for high impedance in the IC. Maybe sooner or later there was a different version of the IC that simply mirrored $0000-$0FFF in that space. I'm just taking a stab here. It would explain the 2 different roms though.

[+batari]

You know that all three known E7 carts are configured differently, right? According to Kevin Horton's Sizes.txt, only He-Man uses the full 16K of ROM, and only BurgerTime uses extra RAM.

 

E7: Only M-Network used this scheme. This has to be the most complex method used in any cart! :-) It allows for the capability of 2K of RAM; although it doesn't have to be used (in fact, only one cart used it- Burgertime). This is similar to the 3F type with a few changes. There are now 8 2K banks, instead of 4. The last 2K in the cart always points to the last 2K of the ROM image, while the first 2K is selectable. You access 1FE0 to 1FE6 to select which 2K bank. Note that you cannot select the last 2K of the ROM image into the lower 2K of the cart! Accessing 1FE7 selects 1K of RAM at 1000-17FF instead of ROM! The 2K of RAM is broken up into two 1K sections. One 1K section is mapped in at 1000-17FF if 1FE7 has been accessed. 1000-13FF is the write port, while 1400-17FF is the read port. The second 1K of RAM appears at 1800-19FF. 1800-18FF is the write port while 1900-19FF is the read port. You select which 256 byte block appears here by accessing 1FF8 to 1FFB.

 

MOTU: Power of He-Man 16K E7

Burgertime 12K +RAM E7

Bump 'n Jump 8K E7

From your description, I would guess that the available binary has duplicated code in the RAM location.

 

Also, he mentions that E7 is similar to 3F, which I'm sure is why Fred's having difficulty getting the dumper to correctly distinguish BurgerTime as E7.

I think it's simpler than that. My detection routine doesn't look at the entire binary, but just a few hotspots, and it happens I picked the first two (which Burgertime apparently doesn't use.) I have changed it to the last two ROM hotspots which should work with all E7 games.

 

As for the E9 data in FA carts, I have no explanation for that. I also can't explain why the latest version works while others do not (but if it works, why question it?)

 

Anyway, I'll go ahead and post this version and change the version number (just in case I broke something.)

Harmony_cart_dumper.zip

[A.J. Franzman]

Do you need some more dumps from me? E7? 3F? Anything else?

[+batari]

Do you need some more dumps from me? E7? 3F? Anything else?

I would like to know if E7 detection works for Burgertime (and other E7 games), and if FA is somehow broken again

[Omegamatrix]

I tested FA, all my E0's, 3F's, FE's, some 16k, 8k, 2k, and everything is working.

 

 

The only mysterious thing is $39 appearing at the hotspots and ram for FA. Otherwise it is firing on all cylinders.

[Omegamatrix]

I tried dumping some superchip games. I found that Jr. Pac-Man and Xenophobe gave perfect dumps.

 

 

Crystal Castles, Millipede, and Defender II all dumped with $40 in the ram. What was strange is the roms out there for these 3 carts all have $00 in the ram. I then dumped these 3 carts in my 7800 as a forced F6 (and F8 for Defender II) dumping to read the ram, and I got all $00. I'm not sure which version is correct.

 

 

An oddity with Xenophobe is the values in the ram aren't clean values like $FF or $00. Yet my dump matched the dump out there so they must be like that on every cart? Is this ram non-volatile?

 

 

 

Dig Dug gave me lots of problems. I couldn't get a good dump by auto-detection or forced on the Harmony copy cart, and I couldn't get a good dump with my 7800 either. Do any of you have this cart and give it a try? I'm wondering if this problem is just my cart or if it's common to Dig Dug's. It plays fine on real hardware.

[A.J. Franzman]

I dumped all of the following, each one once in auto-detect and once in forced mode:

 

Bump 'N' Jump (E7)

BurgerTime (E7)

MOTU: The Power of He-Man (E7)

Miner 2049er (3F)

Polaris (3F)

Mountain King (FA)

Tunnel Runner (FA)

 

There were no auto-aborts, and no incorrect bankswitch detections. Each dump pair was a match. Polaris is the only one that gave me any trouble: when attempting to dump the Polaris cart, connected before running dumper.bat, synchronizing never completes. Connecting it during the 10-second delay worked perfectly. I believe I had this same problem before but never reported it.

 

Of all these dumps, only Bump 'N' Jump, MOTU: The Power of He-Man and Polaris matched available binaries. I believe this is the first time dumping Polaris, that I have gotten a match to the known binary. The other four titles are already known as either slightly anomalous dumps (FA RAM/hotspot differences) or as suspected previously unknown alternate binary versions.

[A.J. Franzman]

Omega, my Dig Dug dumps do not match each other or the available binary either, though it auto-detects as F6 and dumps in auto or forced mode with no complaints from the software. LMK if you want me to post or send you the dump files.

[A.J. Franzman]

An oddity with Xenophobe is the values in the ram aren't clean values like $FF or $00. Yet my dump matched the dump out there so they must be like that on every cart? Is this ram non-volatile?

What RAM?

[Omegamatrix]

Thanks AJ. Why did I think Xenophobia was Superchip? I must be losing it.

 

 

Anyhow if you want to post or PM the Dig Dug that would be great. If you have any other Superchip games maybe try those too.

[Buzbard]

I have Dig Dug, I dumped it using auto & forced and they came out the same but they are different from the available version.

 

digdug.bin

 

It looks like certain bytes in the first 255 bytes of each 4k chunk has $40 added to them. (if that makes sense)

Edited October 28, 2010 by Buzbard

[+SpiceWare]

It looks like certain bytes in the first 255 bytes of each 4k chunk has $40 added to them. (if that makes sense)

Dig Dig is a Super Chip game - the first 256 bytes of each bank is where the 128 bytes of extra RAM is mapped (once for read-access and a second time for write-access thus 256 bytes total).

[A.J. Franzman]

Omega, I tried to PM you with my Dig Dug dumps but could not get the full version of the messenger to come up, so here they are.

 

Dig Dug Dumps.zip

[supercat]

Crystal Castles, Millipede, and Defender II all dumped with $40 in the ram. What was strange is the roms out there for these 3 carts all have $00 in the ram. I then dumped these 3 carts in my 7800 as a forced F6 (and F8 for Defender II) dumping to read the ram, and I got all $00. I'm not sure which version is correct.

 

Accessing $1000-$107F will store to RAM whatever happens to be sitting on the bus. Some EEPROM readers pull the data pins down weakly; Harmony has a weak pullup on D6. If one were to read $1080-$10FF before accessing $1000-$107F, one would probably get random data. In any case, the RAM values aren't important.

[A.J. Franzman]

But, for the sake of matching existing binaries, is it possible to modify the dumper software to pre-load the RAM locations with whatever the accepted value of RAM is? I assume this would be $00. Or perhaps if the dumper can determine what the RAM locations are, it could either disregard what it reads there, or not read it at all, and auto-fill it with the "blank" value. Another possibility would be to alter the order in which the data are read so that the "read" port is read before the "write" port.

Edited October 29, 2010 by A.J. Franzman

[Buzbard]

Crystal Castles, Millipede, and Defender II all dumped with $40 in the ram. What was strange is the roms out there for these 3 carts all have $00 in the ram. I then dumped these 3 carts in my 7800 as a forced F6 (and F8 for Defender II) dumping to read the ram, and I got all $00. I'm not sure which version is correct.

 

Accessing $1000-$107F will store to RAM whatever happens to be sitting on the bus. Some EEPROM readers pull the data pins down weakly; Harmony has a weak pullup on D6. If one were to read $1080-$10FF before accessing $1000-$107F, one would probably get random data. In any case, the RAM values aren't important.

 

I tried to run my dumps of Dig Dig and those of AJs and none of them will run in Stella as-is, but if I change (with a hex editor) the first 256 bytes of each 4k section to either all $00 of all $FF then Stella runs them without problems. I haven't tried to run those dumps from Harmony yet.

 

UPDATE: The dumps do not work on the Harmony, the Dig Dug logo is displayed without any animated characters, but when reset or the fire button is pressed the game screen is displayed but it's hozed, and the system hangs. They do work after I change all the RAM bytes to all $00 though.

Edited October 29, 2010 by Buzbard

[+batari]

Crystal Castles, Millipede, and Defender II all dumped with $40 in the ram. What was strange is the roms out there for these 3 carts all have $00 in the ram. I then dumped these 3 carts in my 7800 as a forced F6 (and F8 for Defender II) dumping to read the ram, and I got all $00. I'm not sure which version is correct.

 

Accessing $1000-$107F will store to RAM whatever happens to be sitting on the bus. Some EEPROM readers pull the data pins down weakly; Harmony has a weak pullup on D6. If one were to read $1080-$10FF before accessing $1000-$107F, one would probably get random data. In any case, the RAM values aren't important.

 

I tried to run my dumps of Dig Dig and those of AJs and none of them will run in Stella as-is, but if I change (with a hex editor) the first 256 bytes of each 4k section to either all $00 of all $FF then Stella runs them without problems. I haven't tried to run those dumps from Harmony yet.

 

UPDATE: The dumps do not work on the Harmony, the Dig Dug logo is displayed without any animated characters, but when reset or the fire button is pressed the game screen is displayed but it's hozed, and the system hangs. They do work after I change all the RAM bytes to all $00 though.

Harmony is detecting Dig Dug as a regular F6 game (no SARA RAM). If you change the bytes to $00 or $FF, it will detect as F6+SARA. The other alternative is change the extension to .f6s to force F6+SARA and it will work without changing bytes.

 

Anyway, I'm not sure I see much point in detecting SARA RAM and purposely sending zeros. The binaries are easy enough to fix after the fact.

[A.J. Franzman]

Probably both Stella and Harmony are failing to recognize the binaries as Superchip, and treating them as pure ROM.

 

EDIT: Fred beat me to it by a few seconds!

Edited October 29, 2010 by A.J. Franzman

[A.J. Franzman]

Crystal Castles, Millipede, and Defender II all dumped with $40 in the ram. What was strange is the roms out there for these 3 carts all have $00 in the ram. I then dumped these 3 carts in my 7800 as a forced F6 (and F8 for Defender II) dumping to read the ram, and I got all $00. I'm not sure which version is correct.

 

Accessing $1000-$107F will store to RAM whatever happens to be sitting on the bus. Some EEPROM readers pull the data pins down weakly; Harmony has a weak pullup on D6. If one were to read $1080-$10FF before accessing $1000-$107F, one would probably get random data. In any case, the RAM values aren't important.

 

I tried to run my dumps of Dig Dig and those of AJs and none of them will run in Stella as-is, but if I change (with a hex editor) the first 256 bytes of each 4k section to either all $00 of all $FF then Stella runs them without problems. I haven't tried to run those dumps from Harmony yet.

 

UPDATE: The dumps do not work on the Harmony, the Dig Dug logo is displayed without any animated characters, but when reset or the fire button is pressed the game screen is displayed but it's hozed, and the system hangs. They do work after I change all the RAM bytes to all $00 though.

Harmony is detecting Dig Dug as a regular F6 game (no SARA RAM). If you change the bytes to $00 or $FF, it will detect as F6+SARA. The other alternative is change the extension to .f6s to force F6+SARA and it will work without changing bytes.

 

Anyway, I'm not sure I see much point in detecting SARA RAM and purposely sending zeros. The binaries are easy enough to fix after the fact.

Well, which would be the bigger headache... finding a way to make the dumper produce "standard" binaries when there is on-cart RAM, or responding to all the complaints from the masses of dumped games not working (or claims of finding "new" alternate binaries that are in fact only different in RAM/hotspot locations)?

[A.J. Franzman]

Omega, here are my other SARA Superchip cart dumps:

 

v0.96 SC Dumps.zip