Jump to content
IGNORED

Harmony as a CopyCart


batari

Recommended Posts

BTW, what would be the most effortless way to split the overdumped 2K binaries? Preferrably, this would either include checking that both halves match, or at least saving both halves separately so that they can be compared by another means.

I don't know of a good way in Win98, unless you want to roll your own file splitter or grab a freeware one. If you have access to a Unix-based OS, you can use dd. Or, you could wait for me to fix the dumper to output 2k. I plan to do that along with fixing E0 and E7 to output correct binaries.

 

On another topic, I didn't think anyone was still using Win98 when I used the Win2k+ only commands in the batch file. If you want, I have a Win2k CMD.EXE that is hacked to run under Win98. I don't know where I got it (and I'd have to look around for it) but that would allow you to use Win98 without messing with the batch.

 

The latest version of the dumper (if you select "auto") will validate the dump by reading it several times and comparing parts of the data for consistency. If subsequent reads don't match, it will abort with a failure message. That can help you debug connection issues.

  • Like 1
Link to comment
Share on other sites

BTW, what would be the most effortless way to split the overdumped 2K binaries? Preferrably, this would either include checking that both halves match, or at least saving both halves separately so that they can be compared by another means.

 

I know Nukey still uses Win 98, so here is a post with the file splitter he uses:

 

http://www.atariage.com/forums/topic/47548-best-way-to-get-source/page__view__findpost__p__575151

 

 

And another on the command line prompt to compare them:

 

http://www.atariage.com/forums/topic/103737-2600-rom-comparisions-and-dumps/page__view__findpost__p__1602928

 

 

When/if you ever upgrade you might try HOM3. I use it to split files or compare them (among other things). HOM3 has many uses.

Link to comment
Share on other sites

BTW, what would be the most effortless way to split the overdumped 2K binaries? Preferrably, this would either include checking that both halves match, or at least saving both halves separately so that they can be compared by another means.
I don't know of a good way in Win98, unless you want to roll your own file splitter or grab a freeware one. If you have access to a Unix-based OS, you can use dd. Or, you could wait for me to fix the dumper to output 2k. I plan to do that along with fixing E0 and E7 to output correct binaries.

Here's program I wrote a while back, it should run in Windows'95 and above, it was written using Visual Basic 6.

 

ROM Splitter.zip

I know Nukey still uses Win 98, so here is a post with the file splitter he uses:

 

http://www.atariage.com/forums/topic/47548-best-way-to-get-source/page__view__findpost__p__575151

 

And another on the command line prompt to compare them:

 

http://www.atariage.com/forums/topic/103737-2600-rom-comparisions-and-dumps/page__view__findpost__p__1602928

Thanks for those files and links. I already know about fc (I'm using it in my version of dumper.bat as part of the input routine).

 

 

On another topic, I didn't think anyone was still using Win98 when I used the Win2k+ only commands in the batch file. If you want, I have a Win2k CMD.EXE that is hacked to run under Win98. I don't know where I got it (and I'd have to look around for it) but that would allow you to use Win98 without messing with the batch.

 

The latest version of the dumper (if you select "auto") will validate the dump by reading it several times and comparing parts of the data for consistency. If subsequent reads don't match, it will abort with a failure message. That can help you debug connection issues.

No need for the hacked CMD.EXE now (though it might come in handy for something else later on); I got my dumper.bat working just fine now.

 

I'll have to try the latest dumper, because I've come to an odd conclusion: Cleaning the carts and connectors helped some carts but not others. Examples: Atlantis and Chopper Command dumped correctly three times in a row each after cleaning. The one copy of Enduro that I'm using dumps right about half of the time now. But the two copies of Frostbite, which I have dumped seven times each, have never dumped the same way twice (and never matched any of my downloaded binaries of the game).

Edited by A.J. Franzman
Link to comment
Share on other sites

The one copy of Enduro that I'm using dumps right about half of the time now.

I'm using dumper v0.7 now, and it looks like my earlier guesstimate was a little off; this Enduro cart dumps correctly about 1/5 of the time (5 correct dumps in 25 attempts). The contacts are now gleaming, so it must be something else. Perhaps a borderline voltage or current condition?

Edited by A.J. Franzman
Link to comment
Share on other sites

The one copy of Enduro that I'm using dumps right about half of the time now.

I'm using dumper v0.7 now, and it looks like my earlier guesstimate was a little off; this Enduro cart dumps correctly about 1/3 of the time. I suppose it could still be faulty contact. I'll try something a little stronger and see how it goes.

 

Activision carts are notorious for playing perfect on some consoles and being garbage on the next. I believe Activision made there PCB's slightly thinner then Atari's. So it might be a problem of the cart simply not making good contact, and not because of dirty contacts either.

 

 

Alternatively I wonder if the single power supply is causing problems? Do you have a switch on the supply to your dumper cart, and if so is the switch SPST or DPST?

Link to comment
Share on other sites

The one copy of Enduro that I'm using dumps right about half of the time now.

I'm using dumper v0.7 now, and it looks like my earlier guesstimate was a little off; this Enduro cart dumps correctly about 1/3 of the time. I suppose it could still be faulty contact. I'll try something a little stronger and see how it goes.

 

Activision carts are notorious for playing perfect on some consoles and being garbage on the next. I believe Activision made there PCB's slightly thinner then Atari's. So it might be a problem of the cart simply not making good contact, and not because of dirty contacts either.

 

 

Alternatively I wonder if the single power supply is causing problems? Do you have a switch on the supply to your dumper cart, and if so is the switch SPST or DPST?

Yes, this could be a brownout condition. The USB chip on Harmony asks the bus for 100ma so you won't be able to use more than that on the single USB cable unless you are using a powered hub or reflash the USB chip to ask for more (up to 500ma) instead. If you want to do the latter, I can explain how via PM.
  • Like 1
Link to comment
Share on other sites

I wonder if the single power supply is causing problems? Do you have a switch on the supply to your dumper cart, and if so is the switch SPST or DPST?

No switch. I made my dumper exactly as I described in an earlier post; the dump cart gets its power from the same USB cable that the Harmony is communicating and powered through. The dump cart is only plugged in during the 10 second countdown (usually at about 2-3 seconds in, so the chip(s) in the cart should have plenty of time to power up and stabilize). An interesting phenomenon that I've noticed on occasion, is that the cursor on the screen often changes to the "wait" hourglass for a split second, right when I plug in the dump cart. So apparently the Harmony is either immediately detecting the cart, or is briefly losing power, and communicating a state change or two to Windows.

Edited by A.J. Franzman
Link to comment
Share on other sites

Omega's question and the lockup problem that batari had to work around with the 10-second delay got me to thinking, why should the delay or a power switch separate from the cartridge connector be needed? If all of the Harmony's address lines are low and its data lines are in an open drain or tristate hi-z mode at the time of connection, and Harmony isn't actively trying to read in any data, the only line that should be high on my dumper at the time of connection is the +5V, Vcc (pin 23 according to Atari or pin 11 according to the Harmony crew). So there shouldn't be any reason for the dump cart to glitch. Now, depending on what data are on the dump cart, some of the data lines would go high and others would go low very soon after connection is made.

 

So this leads to the question, just what states are the Harmony's cart connector pins in, once it's connected to USB?

 

If my thinking above is wrong, of course I am prepared to add a power switch to my dumper so that the connection can be made with Vcc open or even low.

Edited by A.J. Franzman
Link to comment
Share on other sites

Omega's question and the lockup problem that batari had to work around with the 10-second delay got me to thinking, why should the delay or a power switch separate from the cartridge connector be needed? If all of the Harmony's address lines are low and its data lines are in an open drain or tristate hi-z mode at the time of connection, and Harmony isn't actively trying to read in any data, the only line that should be high on my dumper at the time of connection is the +5V, Vcc (pin 23 according to Atari or pin 11 according to the Harmony crew). So there shouldn't be any reason for the dump cart to glitch. Now, depending on what data are on the dump cart, some of the data lines would go high and others would go low very soon after connection is made.

 

So this leads to the question, just what states are the Harmony's cart connector pins in, once it's connected to USB?

 

If my thinking above is wrong, of course I am prepared to add a power switch to my dumper so that the connection can be made with Vcc open or even low.

Harmony boots up with all address and data lines floating, however, I believe the dump cart must be driving the data bus. Floating address lines is undefined behavior, which means we can't expect the data bus to float.) A non-floating data bus may interfere with the programming software's attempt to reboot the cart (without getting into a full technical explanation, the Harmony's MCU has multiple functions for each pin and some are required for programming, and happen to overlap the data bus.)
  • Like 1
Link to comment
Share on other sites

Here is a new version that attempts to detect the cart. It is a WIP version that doesn't add anything except this detection, so only use it if you wish to help me test the detection.

 

I only have 2k, 4k, F8 and F6 carts and it seems to detect them fine. I added detection attempts for E0, E7, F4, FA (CBS), 3F, MB (Megaboy), and FE but do not own any of these carts to test. If anyone has these carts and wishes to help me test the detection, let me know if it worked. If detection works, it should dump the game correctly, but E0 and E7 will not dump the proper data (yet.)

I don't have a Megaboy or a Fatal Run (F4) but I should be able to test most of the others later today.

OK, I finally got around to testing a handful of carts with exotic bankswitching (all in Auto-Detect mode), and here are the results--

Decathlon (FE): in many attempts, "Error: Cart unsupported or unreadable - DUMP ABORTED" was usually reported, but a few times cart came up as *4K*

Tunnel Runner (FA): in 4 attempts, always dumped as *4K*, all different

MOTU: Power of He-Man (E7, 16K): in 4 attempts, always dumped as *3F*, all the same @ 8KB

SW: ROTJ: Death Star Battle (E0): in 4 attempts, always dumped as E0, all the same @ 96 KB (!)

Polaris (3F): dumped 4 times as 3F, all the same @ 8 KB but not matching downloaded Polaris binaries. Game shows title screen with scrolling text in Stella 2.3.5 but does not play. Goes into "screensaver" color change mode if left alone for a while.

Miner 2049'er (3F): dumped 4 times as 3F, all the same @ 8 KB but not matching downloaded Miner 2049'er binaries. Game comes up as a frozen, corrupted, flickering screen in Stella 2.3.5.

Edited by A.J. Franzman
Link to comment
Share on other sites

Omega's question and the lockup problem that batari had to work around with the 10-second delay got me to thinking, why should the delay or a power switch separate from the cartridge connector be needed? If all of the Harmony's address lines are low and its data lines are in an open drain or tristate hi-z mode at the time of connection, and Harmony isn't actively trying to read in any data, the only line that should be high on my dumper at the time of connection is the +5V, Vcc (pin 23 according to Atari or pin 11 according to the Harmony crew). So there shouldn't be any reason for the dump cart to glitch. Now, depending on what data are on the dump cart, some of the data lines would go high and others would go low very soon after connection is made.

 

So this leads to the question, just what states are the Harmony's cart connector pins in, once it's connected to USB?

 

If my thinking above is wrong, of course I am prepared to add a power switch to my dumper so that the connection can be made with Vcc open or even low.

Harmony boots up with all address and data lines floating, however, I believe the dump cart must be driving the data bus. Floating address lines is undefined behavior, which means we can't expect the data bus to float.) A non-floating data bus may interfere with the programming software's attempt to reboot the cart (without getting into a full technical explanation, the Harmony's MCU has multiple functions for each pin and some are required for programming, and happen to overlap the data bus.)

If Harmony drives the chip select (A12) line (pin 18 according to Atari or pin 6 according to the Harmony crew) low, the dump cartridge should not care what state the other address lines are in, and should let the data bus float. I'm not sure if the same is true of 2K carts, as they may use A11 as CS instead of A12. You may have noticed that the early reverse-engineered cartridge pinouts floating around in internet land have A11 and A12 swapped.

Edited by A.J. Franzman
Link to comment
Share on other sites

Omega's question and the lockup problem that batari had to work around with the 10-second delay got me to thinking, why should the delay or a power switch separate from the cartridge connector be needed? If all of the Harmony's address lines are low and its data lines are in an open drain or tristate hi-z mode at the time of connection, and Harmony isn't actively trying to read in any data, the only line that should be high on my dumper at the time of connection is the +5V, Vcc (pin 23 according to Atari or pin 11 according to the Harmony crew). So there shouldn't be any reason for the dump cart to glitch. Now, depending on what data are on the dump cart, some of the data lines would go high and others would go low very soon after connection is made.

 

So this leads to the question, just what states are the Harmony's cart connector pins in, once it's connected to USB?

 

If my thinking above is wrong, of course I am prepared to add a power switch to my dumper so that the connection can be made with Vcc open or even low.

Harmony boots up with all address and data lines floating, however, I believe the dump cart must be driving the data bus. Floating address lines is undefined behavior, which means we can't expect the data bus to float.) A non-floating data bus may interfere with the programming software's attempt to reboot the cart (without getting into a full technical explanation, the Harmony's MCU has multiple functions for each pin and some are required for programming, and happen to overlap the data bus.)

If Harmony drives the chip select (A12) line (pin 18 according to Atari or pin 6 according to the Harmony crew) low, the dump cartridge should not care what state the other address lines are in, and should let the data bus float. I'm not sure if the same is true of 2K carts, as they may use A11 as CS instead of A12. You may have noticed that the early reverse-engineered cartridge pinouts floating around in internet land have A11 and A12 swapped.

Harmony can only do that while executing the dumper code. When in programming mode, user code has no control over the bus (it will be in programming mode before the dumper starts.) The data bus may also prevent the cart from switching between programming mode and user code. It might be better to just slap a pulldown on A12 - it doesn't have to be strong - 10k is probably more than enough. If you try a pulldown, let me know if it allows dump carts to remain plugged in.

  • Like 1
Link to comment
Share on other sites

Here is a new version that attempts to detect the cart. It is a WIP version that doesn't add anything except this detection, so only use it if you wish to help me test the detection.

 

I only have 2k, 4k, F8 and F6 carts and it seems to detect them fine. I added detection attempts for E0, E7, F4, FA (CBS), 3F, MB (Megaboy), and FE but do not own any of these carts to test. If anyone has these carts and wishes to help me test the detection, let me know if it worked. If detection works, it should dump the game correctly, but E0 and E7 will not dump the proper data (yet.)

I don't have a Megaboy or a Fatal Run (F4) but I should be able to test most of the others later today.

OK, I finally got around to testing a handful of carts with exotic bankswitching (all in Auto-Detect mode), and here are the results--

Decathlon (FE): in many attempts, "Error: Cart unsupported or unreadable - DUMP ABORTED" was usually reported, but a few times cart came up as *4K*

Tunnel Runner (FA): in 4 attempts, always dumped as *4K*, all different

MOTU: Power of He-Man (E7, 16K): in 4 attempts, always dumped as *3F*, all the same @ 8KB

SW: ROTJ: Death Star Battle (E0): in 4 attempts, always dumped as E0, all the same @ 96 KB (!)

Polaris (3F): dumped 4 times as 3F, all the same @ 8 KB but not matching downloaded Polaris binaries. Game shows title screen with scrolling text in Stella 2.3.5 but does not play. Goes into "screensaver" color change mode if left alone for a while.

Miner 2049'er (3F): dumped 4 times as 3F, all the same @ 8 KB but not matching downloaded Miner 2049'er binaries. Game comes up as a frozen, corrupted, flickering screen in Stella 2.3.5.

Here is a new version that corrects the length issue with E0, will no longer overdump 2k, and a bug has been fixed with E7 detection. I've also tried holding the bus longer with FE and 3F so hopefully this will fix them - if not, there's something else I can try. I have no idea what's wrong with FA detection, but if it doesn't auto-detect, try the menu option to see if it at least dumps correctly.

 

Also, more menu items are included - one for each supported BS method, and the program uses different input arguments (the previously unused control byte is now used.)

Harmony_cart_dumper.zip

  • Like 1
Link to comment
Share on other sites

I'm using HOM3 hex values here for addresses just so you know.

 

FE

Robot Tank and Decathalon (fixed version)

- All auto-detections were 4k.

- In forced FE mode the carts were 4k overdumps, in other words bank 0 was copied twice. So the bankswitch is not being preformed.

 

FA

Mountain King

- All auto-detections were 4K.

- In forced FA mode bank 0 was copied 3 times with the exception of the ram location and mirrors. Specifically $0000-$0100 was different from $1000-$1100, and both were again different from $2000-$2100. Again in this case the bankswitch is not being preformed.

 

3F

Miner 2049er (PAL)

 

- Auto-detected as 3F, but dumps were incorrect. Specifically:

Slice 0 ($0000-$07FF) of the good rom matched slice 0 of the bad rom 100%

Slice 1 ($0800-$0FFF) of the good rom matched slice 2 of the bad rom 100%

Slice 3 ($1800-$1FFF) of the good rom matched slices 1 and 3 of the bad rom 100%

 

 

- Forced mode for 3F was also incorrect, and different from the auto-detected dumps. Specifically:

Slice 0 ($0000-$07FF) of the good rom matched slices 0 and 2 of the bad rom 100%

Slice 3 ($1800-$1FFF) of the good rom matched slices 1 and 3 of the bad rom 100%

 

 

 

I'll try some more carts probably tomorrow.

Link to comment
Share on other sites

I made the A12 pulldown mod suggested, and the dumper appears to no longer hang during synchronizing while a cart is plugged in, even with 2K carts.

 

I'm using dumper v0.8 now, and it seems to be mostly working with carts that worked before, but I'm not sure -- perhaps my dump sample size was too small before. I dumped a Combat three times each using auto-detect and manual 2K settings, unplugging and reconnecting the cart between dumps (but not while the dumper suite was running). All of the auto dumps are good but only one of the manual dumps is good.

 

Using the same procedure, I dumped Atlantis, Chopper Command, Trick Shot and Demon Attack. Atlantis, Chopper Command and Trick Shot were each 6 for 6 good dumps. One auto-detect dump of Demon Attack detected as 3F and dumped @ 8KB.

Edited by A.J. Franzman
Link to comment
Share on other sites

Still using v0.8, here are some results--

 

Space Shuttle (FE or F8): auto-detect reads my cart (of unknown bankswitching type) as 4K. Manually setting to FE or F8 produces the same file, which does not match either known binary version.

 

Tunnel Runner (FA): auto-detected as 4K. Manually setting to FA produced three dumps matching each other but not the available binary when plugged in during the 10-second countdown, and three non-matching dumps if plugged in before running dumper.bat. This may just be coincidence and what I'm really getting is generally inconsistent ability to read the cart. Will test further if requested.

 

MOTU: Power of He-Man (E7, 16K): auto-detected as E7. Dumped correctly in auto-detect, but incorrectly when manually setting E7.

 

SW: ROTJ: Death Star Battle (E0): auto-detect always comes up with "Error: Cart unsupported or unreadable - DUMP ABORTED". Manually setting E0 produced dumps that did not match each other or the available binary regardless of whether the cart was plugged in before running dumper.bat or during the 10-second countdown.

Edited by A.J. Franzman
Link to comment
Share on other sites

Okay, using the latest V0.9:

 

 

3F

Polaris

- 2x dumps auto-detected as 2k, and 1x more was aborted

- 3x manual dumps, all slices in the dump were copies of slice 3 (the last slice)

 

Miner 2049er (PAL)

- 3x dumps auto-detected as 4k

- 3x manual dumps, slices 0-2 of the dump matched slice 0 of the good rom, slice 3 of the dump matched slice 3 of the good rom

 

Miner 2049er (NTSC)

- 2x dumps auto-detected as 2k, and 1x more was aborted

- 3x manual dumps, all slices in the dump were copies of slice 3 (the last slice), but there were also some differences between the good rom and the dump as shown below:

 

post-7074-128788052745_thumb.jpg

 

 

 

FA

Mountain King

- 3x dumps correctly auto-detected as FA

- 3x more dumps were done manually

- all six dumps matched each other 100%. When compared to the good rom differences were only at the hotspots ($xFF8, $xFF9, $xFFA), and in the ram locations. So all six were good dumps.

 

 

 

FE

Auto-dumps

All auto-dumps were correctly detected as FE, but the banks were reveresed in the dump. So if you split the file in half and rejoined it in the opposite order you would have a perfect dump.

 

Manual dumps

Decathalon (fixed, NTSC)

- 3x manual dumps, here bank 0 was doubled up.

 

Robot Tank

- 2x manual dumps, here bank 0 was doubled up.

- another 1x manual dump, here bank 1 was doubled up

 

 

 

E0

Montezuma'a Revenge, Frogger II, Qbert Qubes, Tooth Protectors, Star Wars Death Star Battle

 

Auto-dumps

All auto dumps detected E0 (3x for each cart), and the cart dumped perfectly. The only exception was an abort on the first try of Frogger II. My experience with the 7800 dumper has taught me that sometimes carts need to ran (energized) before they will be properly detected, and I believe that was the case for this abort too.

 

Manual

- 3x dumps for each and every cart was bad. Each slice of the dumps matched each other, but didn't match any on the original rom at all...

Link to comment
Share on other sites

Using V0.91 now:

 

 

FE

- auto-detecting is now dumping correctly. I tried Decathalon (fixed, NTSC) 3 times, and Robot Tank 3 times.

- manual dumps are still broken. Bank 0 is still being copied twice. I took screen shots because where it says "bank start" it is different between the auto-dump and manual. I don't know if that is significant or not.

 

Auto:

post-7074-128789757099_thumb.jpg

 

Manual:

post-7074-128789759337_thumb.jpg

 

E0

I tried 1 auto-dump and 1 manual dump for Qubes and Death Star. The auto dumps were good, but the manual dumps are broken. They are not matching any slice at all. Here are some screen shots:

 

Auto:

post-7074-128789762718_thumb.jpg

 

Manual:

post-7074-12878976663_thumb.jpg

 

 

I'll try 3F in a little bit.

Link to comment
Share on other sites

3F is being auto-detected now, but both the manual and auto dumps are bad. This is a cleaned up output from Clonespy. Items that are grouped together are exactly the same. The extension number is the slice number.

 

MinerPAL\autodump.2
MinerPAL\autodump.1
MinerPAL\autodump.0
MinerPAL\miner 2049er - starring bounty bob (1982) (tigervision, bill hogue - teldec) (7-008 - 3.60006 vg) (pal).1

MinerPAL\manual.3
MinerPAL\manual.2
MinerPAL\manual.1
MinerPAL\manual.0
MinerPAL\autodump.3
MinerPAL\miner 2049er - starring bounty bob (1982) (tigervision, bill hogue - teldec) (7-008 - 3.60006 vg) (pal).3

;--------------------------------------------------------------------------------------------------

Miner\autodump.1
Miner\autodump.2
Miner\autodump.0
Miner\miner 2049er - starring bounty bob (1982) (tigervision, bill hogue) (7-008) ~.1

Miner\autodump.3
Miner\manual.0
Miner\manual.1
Miner\manual.3
Miner\manual.2

;--------------------------------------------------------------------------------------------------

Polaris\autodump.2
Polaris\autodump.1
Polaris\autodump.0
Polaris\polaris (1983) (tigervision, robert h. o'neil) (7-007) ~.1

Polaris\polaris (1983) (tigervision, robert h. o'neil) (7-007) ~.3
Polaris\autodump.3
Polaris\manual.0
Polaris\manual.1
Polaris\manual.3
Polaris\manual.2

 

I did 6 dumps for each cart (3 auto, 3 manual).

Link to comment
Share on other sites

OK, I think I see the final bugs now, hopefully this is it.

 

Still seeing the problem with E0 and FE. Auto-dumps are fine, manual dumps don't work. It's almost as if the list number doesn't match the actual bankswitch type.

 

I tried a Miner PAL and it was bad for auto and manual, but it detected 3F just fine.

 

Also the latest version was numbered v0.91 just like the last. I think it is new though after looking at the mod date.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...