Harmony as a CopyCart

[+batari]

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)?

I can easily add manual options for SARA games, but detection is difficult. The only way to reliably detect them would be to attempt to write to the cart, but if the cart is not a SARA RAM cart, you are creating bus contention that could potentially damage the cart, Harmony, or both.

[A.J. Franzman]

I know what bus contention is, but I don't know how writing to a SARA cart is done and how that technique could lead to contention with a non-SARA cart, so I'll take your word for it.

[Omegamatrix]

Both AJ's and Buzbards Dig Dug dumps were good, but the values in the ram locations were well, random. I was experiencing the same thing. When I looked at the available rom it had the same thing too. For whatever reason, Dig Dug in particular is cart that will give you values all over the place in the ram.

 

 

Most of AJ's dumps were good except for Millipede. None of those were good. Jr. Pac-man also had problems where 2 of the dumps were bad. FD1 was a good dump of Jr. Pac-man though. At least now I now $40 is appearing in the ram of other peoples dumps too.

 

 

 

@Batari a forced option for SC games would be useful just to eliminate more bad dumps in the future. I imagine you would read $0080-$00FF first, and then copy it into each bank?

 

Edit:

I see AJ was suggesting the same thing too. Read the read section first, before reading the write addresses.

[supercat]

I can easily add manual options for SARA games, but detection is difficult. The only way to reliably detect them would be to attempt to write to the cart, but if the cart is not a SARA RAM cart, you are creating bus contention that could potentially damage the cart, Harmony, or both.

 

Magic writes won't work with D6, since that has a pull-up, but couldn't you try magic writes for the remaining seven bits? Put $40 on the data bus and $0000 on the address bus, then float the data bus and put $1000 on the address bus for 700ns and back to $0000. Then read $1080, $1100, and $1400 (looking for 128b, 256b, or 1K of RAM). Then repeat the procedure starting with $FF on the data bus. I think you should clearly see whether there's RAM there or not.

Edited October 30, 2010 by supercat

[Schizophretard]

Would a Rom Scanner work and would it need modified like a Video Game Brain?

[Pioneer4x4]

OK, I been cleaning up my Atari stash, and came across my Video Game Brain (I guess, it doesn't say it on it) Model RGA-1360.

Since there is many pages of info, is there a "sum it up in one post" to use the Harmony as a dumper with the Video Game Brain. If I recall I need to modify it first.

And has anything new happened with the Harmony as a dumper?

What CANNOT be dumped with it? I assume not Boulder Dash... :-(

I also want to use it as a dumper to read back the carts I make myself, like a final verification that they are good.

[+Andrew Davie]

What CANNOT be dumped with it? I assume not Boulder Dash... :-(

 

Now why would anyone want to do that, when it's still available in the store!

[Pioneer4x4]

What CANNOT be dumped with it? I assume not Boulder Dash... :-(

 

Now why would anyone want to do that, when it's still available in the store!

Obvioulsy to test hardware ... And if you are dumping it, you already have it! (Which I do)

Edited August 20, 2012 by Pioneer4x4

[alex_79]

Would a Rom Scanner work and would it need modified like a Video Game Brain?

Since there is many pages of info, is there a "sum it up in one post" to use the Harmony as a dumper with the Video Game Brain. If I recall I need to modify it first.

While the first proof of concept of the dumper (the copycart posted at the beginning of this topic) used a console and a cart selector (like the game brain or the romscanner), the final version uses a custom adapter to connect the harmony to the dump cart without a console. You can hack a cart selector quite easily to build the adapter, but the mod will be a bit more complicated if you want to mantain its original functionality.

 

 

Instructions to build the adapter are on post #13, and you may want to add a pulldown resistor as suggested on post #88. The latest version of the software is on post #132.

 

 

I finally built mine and it works very well. I modified the custom cart selector I posted here, and initially I got some problems with it: while the dumps were mostly correct, sometimes the autodetection failed and I coudn't get a correct dump from two of my carts.

 

"Space Invaders" cart (4K): the bin was filled with "FF" whatever bankwswitch I selected.

 

"Space Shuttle" cart (FE): autodetection always failed and dumps (by manually selecting "FE" bankswitch) always contained one or two incorrect bytes in random locations.

 

I then rewired the adapter from scratch, eliminating the connector that once connected to the console and using a much shorter ribbon cable to connect the two cart ports. I then tried again with several carts and now autodetection works perfectly and the dumps are correct. So I think that the wires were too long and caused interferences.

 

Here is a picture of the adapter.

The cart dumper is powered by an external AC adapter which plugs in the jack on the side (I use the power adapter from a 2600 console). A 7805 regulator step down the voltage to the 5V required by the cart. I also put a power switch and a led.

 

Here is a schematic a did which may come in handy in wiring the adapter. It includes the pulldown resistor on A12. Although not shown in the schematic, I also connected the "GND" pin to ground on the dump cart side, while only the "sGND" pin is connected on the Harmony side. (while most carts have the two pins connected internally, there are some exceptions, so I thought it would be better in this way).

 

 

I use linux on my PC, so I had to convert the batch file into a bash script. Here it is in case someone else wants to try the dumper on linux.

dumper.tar.gz

You need to install the linux versions of lpc21isp and uudecode which you can find online (uudecode is in the "shareutils" package in my distribution). You also need the file "dump.arm" and the utility "hackdump" which are in the zip file posted by Batari (He included the source of hackdump so you can compile it). The bash script assumes that hackdump, uudecode and lpc21isp executables can be found from the PATH variable.

 

some screenshots of the dumper in action:

Edited August 25, 2012 by alex_79

[Pioneer4x4]

THANKS!!!

That is exactly what I was looking for.

I'll re-read those posts.

Nice enclosure BTW!

[freewheel]

As they used to say... looong time listener, first time caller here. I finally ordered a Harmony cart recently and had a blast with it. Then, I discovered this thread. I have a few unusual PAL carts that I'm not sure if they've ever been dumped - atarimania says no, but I'm not sure. Things like the Quelle Phantom-Panzer, etc. So, I decided to build myself a dumper based on what you guys have been talking about here.

 

And it worked pretty damned good! I dumped quite a few of my own games, with nothing more than a floppy cable and a Harmony cart. Was quite a lot of fun after all these years of using other people's work. I learned first hand what an overdump was, and how to make a bad dump, and how to make things work better. I also discovered HOM3 which is basically the ROM data compare/gfx editor I tried to write in Java in about 2002 or so, and gave up on. This thread and all of you guys' help was the most Atari fun I've had in years, so thanks to everyone!

 

Unfortunately - I think I may have fried my Harmony in the process. At one point it was giving me consistently strange dumps, so I figured ok, enough playing around, maybe I'll come back to this when I get proper cart connectors - floppy cable connections are tricky with most carts. Re-flashing the BIOS works, but when I plug it into a console, I get nothing - either a black screen or lots of random colour and noise. I've tried re-flashing with copycart.bin, and it takes it - but in the console, I don't get the nice rainbow lines that it should give. So, I guess my question is - is it possible that I've permanently fried my Harmony? How is it possible that it can take a firmware image, but still not work in a 2600 console? Might I be doing something wrong? Is there anything I can do to rectify this?

[cd-w]

It sounds possibly like a problem with the edge connector on the Harmony cart. Has the edge connector got scratched or dirty from the floppy cable? I'd try carefully cleaning the edge connector and cartridge port on the Atari. Also the circuit board in the Harmony cart can become unseated - make sure that it is straight and making good contact with the Atari cartridge port.

 

Chris

[freewheel]

Well, I did the unthinkable (nothing to lose, right?) and took my Harmony apart. The contacts actually did release a little bit of gunk, probably from various consoles I've tested with - just a tiny bit weird for a brand new circuit board but hey, helps clean my consoles right?

 

Having the bare board in the consoles - nada. Still can't get anything happening. I don't quite know how these things are built but it's weird - it'll take a firmware image just fine, no complaints, but said image just never boots up in the 2600 itself. Almost as if one side of the interface is fine but the other is shot (ie: if it's being transferred between 2 EEPROMS or something). I may play around with directly connecting to various pins to see what I can make happen, because at this point she's dead in the water.

 

Fortunately it appears as though a next-gen Harmony is on its way, so I might just be getting that anyway. The concept is a lot of fun, if you don't break yours by playing around as much as I did.

[alex_79]

Do you have another console to test it with?

 

I had a few problems in the past with my harmony cart when using it on my 7800. On a few occasions, I couldn't complete the bios upgrade (I don't remember if I just got a blank screen or the "yin yang" animation). I reflashed the firmware quite some times using that console and this issue just happened 2 or 3 times in total. The only way I could fix it was booting up the harmony in another console to complete the bios update. After that I was able to use it normally also in the 7800.

I think that was due to some component aging in that specific 7800 console, and it may not be your case, but it is worth checking if you have another 2600 or compatible console to test.

[freewheel]

Yeah, I've tried in a few - my composite Vader, my light 6, and a 7800. I'll keep poking at it as I've got a few others to test with - plus I should try with copycart.bin just to see if I get *anything*.

 

Appreciate the ideas and tips, folks. Some of the more obvious stuff I didn't even think to try... probably because it's so obvious. I'd really be slapping myself if it was just dirty contacts or a weird connection issue that I should have figured out within seconds. With any other cart, I'd be doing it. I guess I just don't think straight with new stuff.

 

Oh, not that I think anyone should do this just to see it, but - I love the slick AtariAge logo silkscreened onto the Harmony board. Nice touch that almost no one will ever see.

[+batari]

Hello,

 

Sorry you are having trouble with your cart after playing with the dump utility! Although I (think I) put in a disclaimer somewhere, I don't want to discourage people from experimenting like you've done, so if we can't find a solution, you can send your cartridge back for repair.

 

Aside from contact cleaning, you might try reflashing the BIOS again. I've noticed that the utility sometimes fails, and when it does, the error is not obvious (if it fails, it may show "CRC error" on the bottom of the screen for a few seconds, and it is easy to miss this message.) Sometimes it may even appear to go to 100% and still give the CRC error. So I'd try to update again, the CRC error is fleeting and trying again usually works. Make sure the progress bar goes to 100% and the message on the bottom of the screen says "download completed" or similar.

 

If this fails, you may have blown something in the cart (probably the common-cathode dual-diode, for isolating USB and console power, would be my guess.) I can easily replace that part or bypass it (if you are doing a lot of dumping, I can also just bypass the diode so you can power the Harmony and the dump cart, all from USB.)

[freewheel]

Oh hey, thanks for the response Batari. You certainly did put a disclaimer... somewhere. And I knew I was taking my life into my own hands with this one It was certainly worth the experience if nothing else - I've been into the whole ROM/emulation scene for close to 20 years now and finally doing it to my own games was mesmerizing.

 

I'll keep poking with the flasher. Done it probably 100 times now so I'm pretty familiar with it. It's never actually failed on me - I always get "download finished" with an elapsed time. To be fair, I only tried the copycart.bin and have never actually flashed back to the normal BIOS, but still... it seems pretty simple enough.

 

I'm pretty sure you're right in that I've blown something. This all actually started when I had to.. shall we say modify my dumping cable a bit. The floppy connectors don't quite work on certain carts - the kinds that don't have a dust cover, but do have the plastic tabs to push open the cover on the 2600 itself. I had debated cutting the carts, but figured I might at well do some trim on the floppy cable instead. So I wouldn't be at all surprised if I shorted something somewhere. I wasn't expecting it to affect the Harmony as *that* end was never touched (in fact I never unplugged it once I got it working) but... without doing a full pin trace over what I might have done, anything's possible.

The diode you mention - you say it's there to isolate console and USB power... it could make sense that I accidentally sent +5v over pins I shouldn't have if I really crushed things. Out of curiosity, what's the danger in removing it in general? That someone might hook up USB while it's powered by the console? Would the Harmony work in a console with it removed? With everything being surface mount I doubt I could easily remove it myself - my skills are limited to things the scale of the original 2600s and that's about it - but I must admit you have me curious.

 

I'll PM you if I wanna get you involved in a physical sense. I don't really wanna bug you, as I know I brought this upon myself but if it could help you with other problems, then I'm game. I'm almost certainly going to order the next-gen Harmony anyway, so I may send this back and order that at the same time, cut down on shipping hassles.

[Thomas Jentzsch]

Reviving this old thread...  

 

I am currently wondering about the correct implementation of FA bankswitching. See the Stella issue here.

 

Since you got $E9 for all bankswitching hotspots, this might support the theory that D0 is taken from the hotspot peeks. Does anybody have an idea how to verify this? Or is even able to do so?

Edited January 27 by Thomas Jentzsch

[+batari]

9 hours ago, Thomas Jentzsch said:

Reviving this old thread...  

 

I am currently wondering about the correct implementation of FA bankswitching. See the Stella issue here.

 

Since you got $E9 for all bankswitching hotspots, this might support the theory that D0 is taken from the hotspot peeks. Does anybody have an idea how to verify this? Or is even able to do so?

I can't remember my Github credentials and can't be bothered to fix that right now so I will comment here.

 

After reading the comments there, my theory is that FA hardware will only bankswitch on xFF8-xFFA on the rising edge of D0. For this to work, the peek at $5FF8 has to contain D0=0, then the write on the next cycle will have D0=1, but on hardware, this change will occur later in the cycle, so that the address is valid and the hotspot (based on address) may be latched without a delay circuit (that we normally use for standard bank switching - and in some cases has been the source of problems.)

 

Honestly, if this is right, it's a genius idea. The LDA #1 would be necessary for it to work.

 

Unfortunately, this does not explain the $E9 on the bus.

[Thomas Jentzsch]

41 minutes ago, batari said:

I can't remember my Github credentials and can't be bothered to fix that right now so I will comment here.

 

After reading the comments there, my theory is that FA hardware will only bankswitch on xFF8-xFFA on the rising edge of D0. For this to work, the peek at $5FF8 has to contain D0=0, then the write on the next cycle will have D0=1

But there are four peeks for e.g. STA $3FF8,Y (three for STA $3FF8). And only then follows the poke. So maybe it's the poke which has to contain bit 0 = 1?

41 minutes ago, batari said:

but on hardware, this change will occur later in the cycle, so that the address is valid and the hotspot (based on address) may be latched without a delay circuit (that we normally use for standard bank switching - and in some cases has been the source of problems.)

 

Honestly, if this is right, it's a genius idea. The LDA #1 would be necessary for it to work.

Not sure if I got you right here. Is it the poke, which is causing the change?

41 minutes ago, batari said:

Unfortunately, this does not explain the $E9 on the bus.

If the LDA #1 is relevant, it doesn't matter for me.  

[+batari]

3 hours ago, Thomas Jentzsch said:

But there are four peeks for e.g. STA $3FF8,Y (three for STA $3FF8). And only then follows the poke. So maybe it's the poke which has to contain bit 0 = 1?

Not sure if I got you right here. Is it the poke, which is causing the change?

If the LDA #1 is relevant, it doesn't matter for me.  

Yes, the only peek that matters is the hotspot read (with D0=0) followed by D0=1 for the poke. This is only possible if A&1=1.

 

Basically, nothing happens unless the hotspots are active (the address is xFF8-xFFA) so the preceding peeks do not matter. While in a hotspot (as you will be for two cycles, first a peek then a poke), lower address lines A0 and A1 are latched on the rising edge of D0.

[Thomas Jentzsch]

Hm, that means the hotspot peeks do not return the ROM value, but something else. Or is that only your dumper which returns $E9 here?