41 replies to this topic

[batari]

Here's a quick write-up of the instructions needed to dump the games from your FB2, plus the utilities you need to help you.

What you need:

An FB2 with a cart mod
Some sort of 4k programmable cart that works with the FB2, such as a 4k board from AA and an EPROM burner. I don't think a Cuttle cart or Supercharger will work, but a Krokodile Cart burned with a single image (i.e. not as a multicart) might.
an old DB9 male/female cable or some other way to connect two pins from the joystick port on the FB2 to the serial port on a PC
a PC with a serial port, with some sort of terminal software that can capture a text file, such as Hyperterminal

DISCLAIMER! There is always a chance that you will fry your FB2 by following this procedure. I take no responsibility for any damage to your FB2, your programmable cart or anything else, including yourself.

First, you should see if your programmable cart will your on your FB2. Burn a cart with the attached 4k binary image to see if it runs on your FB2. The dump cart copies a short routine to the 2600's 128 bytes of RAM and jumps there so you can remove the cart to dump FB2 games.

If it is working properly, you'll see a screen that looks something like this:



Next, create a cable to connect the right joystick port of the FB2 to a PC's serial port.

The connections are:

FB2        PC
_________________
Pin 1       Pin 2
Pin 8       Pin 5

You only need two connections, so you might wish to do it like I did if you can find connectors to connect to a single pin (I don't know where to buy them though - Mine were obtained by cutting up a surplus cable from a logic analyzer.) Otherwise you need to cut up and modify a male to female DB9 cable.

Here's pix of my connections:

FB2 right joystick port connection:


PC serial port connection


Once you make the cable, you should test the connection. You need to test it to see if you connected it right, and because it will not work on all PC serial ports. (WHY? see Appendix A.)

Once you have the FB2 connected to the PC, run a terminal program, such as hyperterminal for Windows. Set it up for your serial port at 38400 bps, no parity, 8 data bits, 1 stop bit, and no flow control.

Now boot up the FB2 with the dump cart in there, and press reset. The TV will display a blank colored screen while it dumps the contents of the dump cart. You should see hexadecimal values filling your terminal screen, which are the contents of the dump cart itself... but if you see these, this means it's working.

If your connection doesn't work, you may have an incompatible serial port (see Appendix A for a possible remedy.)

If everything works so far, you are ready to dump a FB2 game.

Procedure:

1. Remove the dump cart if installed, and set the switches for normal FB2 mode.

2. Boot up the FB2 and go through the menus and launch the game you want to dump.

3. insert your dump cart and then quickly flip the switch to disable FB2 mode. You need to do both in quick succession or the FB2 will almost always crash.

4. At this point, you will either see the colorful dump cart "ready" screen... if not, the FB2 has crashed and you need to repeat the dump procedure from step 1 until you get the ready screen. It usually does just crash for me, but about 1 out of 10 times I do get the ready screen.

5. Carefully remove the dump cart, and then flip the switch back to FB2 mode. This will make the last FB2 ROM image accessible. Make sure the dump cart screen is still active - it should be since it runs totally in the 2600's 128 bytes of RAM. If not the FB2 has crashed and you need to go back to step 1 (The FB2 has yet to crash on me during this step, but it may happen to you )

6. On your PC, set up your terminal program to begin capturing a text file. If you are using Hyperterminal, go to Transfer->Capture text, and select a filename (a new file - if you pick an existing filename, I think it will append to it, which you don't want.)

7. Press reset on the FB2. The screen should now be a single color and your PC's screen will fill up with hexadecimal digits.

8. Once done, the FB2 will execute a BRK which will usually start up the game (not always, though.) At this point, stop the text file capture. In hyperterminal, the Transfer pull down menu will now have a "stop" option in it.

9. Check the size of the file. It should be 32770 bytes or thereabout (32k of hex digits plus a LF/CR at the end, usually.)

10. If the file is considerably smaller, your serial port probably lost the connection along the way (this happened a lot on an old laptop I have, but my desktop PC always worked.)

11. If the file is larger, you have have some extraneous characters in your file. It may still convert properly, however.

12. If your capture file is the right size, you are now ready to convert it to a binary. The attached utility (hex2bin.exe) will take the captured text file and output a 4k, 8k or 16k binary. To use the utility, run it in the directory containing the captured text file and you'll be prompted for the name of this file, the size of the output file (4k, 8k or 16k) and the name of the binary file to output.

13. Of course there's no way to know ahead of time how big the binary is supposed to be, so try 4k, 8k, then 16k and run each binary in your favorite emulator until it works. If the game uses Superchip RAM (such as Yars' Return) the game will not work right unless you enable it (in z26, use -g2 or -g6, or in Stella, create a stella.pro entry.)

If you are successful dumping any games, please post and let everyone know!






Appendix: Serial port compatibility and other notes

With your cable, you are actually connecting TTL (which outputs 0v as a "zero" and 5v as a "one") to serial (expects 3v to 25v as a "zero" and -25v to -3v as a "one.")

Therefore, the 5v is OK but the 0v is out of spec for a serial port. But so far most of the PC serial ports I've tried don't seem to mind the 0v and interpret it as a "one."

If your connection doesn't work, make sure the connections are correct. If they are, you either need to use a different PC with a compatible serial port or use something called a TTL level converter to convert the 0-5v to +/- 3-25v serial port signals. If you need to do this, you will also need to recompile the cart dumper from source with the TTL option enabled.

Other reasons you might want to recompile the cart dumper from source are if you want to try a baud rate other than 38400 bps or you want the dumper to produce 4k or 8k dumps instead of 16k every time.

EDIT: D'Oh! Error in hex2bin.exe... just fixed it.

Attached Files

•  dump_utilities.zip   41.8K   253 downloads

Edited by batari, Sat Oct 22, 2005 1:15 AM.

[supercat]

That's a pretty slick approach. Any particular reason for using a BRK instead of a JMP ($FFFC)? Or were you totally out of RAM?

[supercat]

Compatibility suggestion: if you can have the code output opposite-polarity signals on two of the joyport pins, then connecting one of the to PC ground and the other to PC data would result in the PC seeing +/- 5 volt signals. This should make even PC's with annoying serial ports happy.

[batari]

supercat, on Sat Oct 22, 2005 1:55 PM, said:

That's a pretty slick approach.  Any particular reason for using a BRK instead of a JMP ($FFFC)?  Or were you totally out of RAM?

Space was the concern. Although the 38400 bps version has about 12 bytes free, if the asm is compiled for other baud rates, there is less space. I don't recall how much offhand, but I think that 1200 and 2400 bps were really tight. I suppose that conditional compilation flags could be put in for the baud rates that have the space.

Either way the BRK usually works to run the game so you are sure that the utility tried to send the correct data. It didn't work in Yar's Return, but the game still dumped properly.

Supercat said:

Compatibility suggestion: if you can have the code output opposite-polarity signals on two of the joyport pins, then connecting one of the to PC ground and the other to PC data would result in the PC seeing +/- 5 volt signals. This should make even PC's with annoying serial ports happy.

I think I see what you're saying. I'll look into how much extra code space it may require and give it a try. So far my laptop doesn't like 0v very well - it works for the first few kilobytes and loses the connection, or sometimes receives a screen full of garbage.

[supercat]

batari, on Sat Oct 22, 2005 5:18 PM, said:

Space was the concern.  Although the 38400 bps version has about 12 bytes free, if the asm is compiled for other baud rates, there is less space.  I don't recall how much offhand, but I think that 1200 and 2400 bps were really tight.  I suppose that conditional compilation flags could be put in for the baud rates that have the space.

Can't think why those would be particularly problematical. To kill time, just load X, do a DEX/BNE, and maybe stick in one or two "nop" or "nop 0" instructions.

BTW, there are some obvious code savings available to you if you strip out the stuff to handle 'formatting' the data into nice neat lines.

And I'm not positive, but I think the following will do a nice binary->hex conversion if the D flag is set (you can set it before entering your program):

       ; Binary -> HEX
        clc            ; 00-09 0A-0F
        adc #$90       ; 90-99 00-05
        adc #$40       ; 30-39 41-45

I hope I got that right. The comments show what happens to passed-in values of 0-9 and 10-15. Cute, eh?

Quote

I think I see what you're saying.  I'll look into how much extra code space it may require and give it a try.  So far my laptop doesn't like 0v very well - it works for the first few kilobytes and loses the connection, or sometimes receives a screen full of garbage.

Here's a simple tx routine for 38,400.

txchar:
        sta     DBUFF
        ldx     #9
        sec
txlp:
        lda     #0
        adc     #1
        sta     SWCHA
        lsr     DBUFF
      ; Zonk for some cycles here [31-17 for 38,400]
        ldy     #1
zz:
        dey
        bpl     zz
        nop     0
      ; end zonk
        dex
        bne     txlp

2+2+3+5+2+3  17 cycles (baseline)
zonk is 6, plus five per loop

Note that 57,600 might be possible if the loop is unrolled 3x (to nicely handle the fractional bit time). Any slower baud rates can be handled just by changing the "Y" value in the loop above (for added precision, replacing the "nop 0" with two nops for 19,200.

Edited by supercat, Sat Oct 22, 2005 5:53 PM.

[batari]

supercat, on Sat Oct 22, 2005 6:47 PM, said:

batari, on Sat Oct 22, 2005 5:18 PM, said:

Space was the concern.  Although the 38400 bps version has about 12 bytes free, if the asm is compiled for other baud rates, there is less space.  I don't recall how much offhand, but I think that 1200 and 2400 bps were really tight.  I suppose that conditional compilation flags could be put in for the baud rates that have the space.

Can't think why those would be particularly problematical. To kill time, just load X, do a DEX/BNE, and maybe stick in one or two "nop" or "nop 0" instructions.

Actually, I'm remembering now ... the 2400 bps needed a delay of 496 cycles between each bit sent, but 496 cycles is roughly equal to 6.5 scanlines, so I used WSYNCs to delay 6 between one bit and 7 between the next to get the average, which added code space that in retrospect isn't needed. But come to think of it, a DEY/BNE loop without WSYNCs could pretty easily produce that many cycles or close to that.

Regardless, I am hopeful that the default 38400 bps is reliable enough so nobody will need to try one of the slower baud rates.

Quote

BTW, there are some obvious code savings available to you if you strip out the stuff to handle 'formatting' the data into nice neat lines.

I commented the formatting out, actually... I originally sent 16 hex digits then a CR, but I figured that it wasn't necessary and I needed the space to get the bankswitching support in there.

Quote

And I'm not positive, but I think the following will do a nice binary->hex conversion if the D flag is set (you can set it before entering your program):

      ; Binary -> HEX
        clc           ; 00-09 0A-0F
        adc #$90      ; 90-99 00-05
        adc #$40      ; 30-39 41-45

I hope I got that right.  The comments show what happens to passed-in values of 0-9 and 10-15.  Cute, eh?

Interesting... I don't generally think in decimal. It seems like it would work though.

Quote

Here's a simple tx routine for 38,400.

txchar:
        sta     DBUFF
        ldx     #9
        sec
txlp:
        lda     #0
        adc     #1
        sta     SWCHA
        lsr     DBUFF
     ; Zonk for some cycles here [31-17 for 38,400]
        ldy     #1
zz:
        dey
        bpl     zz
        nop     0
     ; end zonk
        dex
        bne     txlp

2+2+3+5+2+3  17 cycles (baseline)
zonk is 6, plus five per loop

I was thinking about your suggestion for +/- 5v, and I realized that my code carried the byte to send in the accumulator and was ROR'ed is so bit 0 of SWCHA always got next bit to send serially. So doing so with my routine would take quite a bit of extra code space to work (if it did at all.)

I'm a little fuzzy tonight, but wouldn't bit 1 in your routine always contain inverted bit 0, so we could get +/-5v from yours? (Or was that your intent all along and I didn't notice it until now?)

[supercat]

batari, on Sun Oct 23, 2005 12:28 AM, said:

But come to think of it, a DEY/BNE loop without WSYNCs could pretty easily produce that many cycles or close to that.

Sure. Why bother with WSYNC?

Quote

Quote

BTW, there are some obvious code savings available to you if you strip out the stuff to handle 'formatting' the data into nice neat lines.

I commented the formatting out, actually... I originally sent 16 hex digits then a CR, but I figured that it wasn't necessary and I needed the space to get the bankswitching support in there.

You left in an "AND" and "BNE" instruction.

Quote

Interesting... I don't generally think in decimal.  It seems like it would work though.

Saves three bytes I think.

Quote

I'm a little fuzzy tonight, but wouldn't bit 1 in your routine always contain inverted bit 0, so we could get +/-5v from yours?  (Or was that your intent all along and I didn't notice it until now?)

Uh yeah, that was sorta the idea.

[batari]

supercat, on Sun Oct 23, 2005 12:42 AM, said:

Sure.  Why bother with WSYNC?

No good reason... I was just thinking in terms of scanlines with those long delays... Clearly a simple delay loop would still work just file here without any need for WSYNCs.

Quote

Quote

I commented the formatting out, actually... I originally sent 16 hex digits then a CR, but I figured that it wasn't necessary and I needed the space to get the bankswitching support in there.

You left in an "AND" and "BNE" instruction.

Oops. Well, fortunately this extra code didn't do anything that would break the utility. But yeah, we could save 4 bytes here.

Quote

Quote

I'm a little fuzzy tonight, but wouldn't bit 1 in your routine always contain inverted bit 0, so we could get +/-5v from yours?  (Or was that your intent all along and I didn't notice it until now?)

Uh yeah, that was sorta the idea.

I will try this tonight and see how it works on my flaky laptop. Although most of the serial ports seem to tolerate that out-of-spec 0v thing, I would rather do something that works on all of them Especially since I've only dumped a few of the games so far, and it's much more convenient to use my laptop. It takes quite a bit of time to dump 40 games!

Oh, and I didn't mention this before, but this utility can also be used to dump carts on a regular 2600 as well. Though I am not sure of the real value of this, since nearly all 2600 carts have already been dumped.

[stephena]

batari, on Sat Oct 22, 2005 2:40 AM, said:

13. Of course there's no way to know ahead of time how big the binary is supposed to be, so try 4k, 8k, then 16k and run each binary in your favorite emulator until it works.  If the game uses Superchip RAM (such as Yars' Return) the game will not work right unless you enable it (in z26, use -g2 or -g6, or in Stella, create a stella.pro entry.)

Just an FYI that a new stella.pro entry wouldn't be required for Stella 2.0. As of version 2.0, there now exists commandline arguments to set/override each property entry. So to use a different cartridge type, just do 'stella -type XXX romname'. The various cartridge types are documented in the manual, some of which would be 2K, 4K, FASC, etc.

Also, since there's now a built-in GUI, you can edit the properties from directly within Stella. So you could load the ROM, select the cartridge type from a drop-down menu, and click 'OK'. Then do a ROM reload (either by pressing Ctrl-r or exiting and restarting), and it will pick up the new properties settings.

I don't mean to be nitpicking, but many people complained that having to create a new .pro entry was a major reason for not doing development in Stella. That's no longer true, so it would be better to not tell prospective programmers this any longer. Of course, one can still create a new .pro entry if they want, and do 'stella -pro PROP_FILE romname'. That would still work, but under no circumstances does one have to create a .pro entry manually. We took great pains to add this functionality, and would like as many people as possible to know about it.

[batari]

stephena, on Sun Oct 23, 2005 12:17 PM, said:

batari, on Sat Oct 22, 2005 2:40 AM, said:

13. Of course there's no way to know ahead of time how big the binary is supposed to be, so try 4k, 8k, then 16k and run each binary in your favorite emulator until it works.  If the game uses Superchip RAM (such as Yars' Return) the game will not work right unless you enable it (in z26, use -g2 or -g6, or in Stella, create a stella.pro entry.)

Just an FYI that a new stella.pro entry wouldn't be required for Stella 2.0. As of version 2.0, there now exists commandline arguments to set/override each property entry. So to use a different cartridge type, just do 'stella -type XXX romname'. The various cartridge types are documented in the manual, some of which would be 2K, 4K, FASC, etc.

Also, since there's now a built-in GUI, you can edit the properties from directly within Stella. So you could load the ROM, select the cartridge type from a drop-down menu, and click 'OK'. Then do a ROM reload (either by pressing Ctrl-r or exiting and restarting), and it will pick up the new properties settings.

I don't mean to be nitpicking, but many people complained that having to create a new .pro entry was a major reason for not doing development in Stella. That's no longer true, so it would be better to not tell prospective programmers this any longer. Of course, one can still create a new .pro entry if they want, and do 'stella -pro PROP_FILE romname'. That would still work, but under no circumstances does one have to create a .pro entry manually. We took great pains to add this functionality, and would like as many people as possible to know about it.

Yes, last night I found the feature in the GUI that allows you to set the bankswitching preferences. It is much easier than creating a stella.pro entry. Actually, the only games I've found so far that may need this treatment are Yars' Return and Lunar Lander, which are Superchip games, the first being 8k and the second 16k.

Well, maybe not even then, since the dump utility seems to be dumping $FF for the Superchip RAM area anyway, which I've heard that Stella may look for to determine bankswitch type.

[batari]

batari, on Sun Oct 23, 2005 1:19 AM, said:

I will try this tonight and see how it works on my flaky laptop.  Although most of the serial ports seem to tolerate that out-of-spec 0v thing, I would rather do something that works on all of them   Especially since I've only dumped a few of the games so far, and it's much more convenient to use my laptop.  It takes quite a bit of time to dump 40 games!

Oh, and I didn't mention this before, but this utility can also be used to dump carts on a regular 2600 as well.  Though I am not sure of the real value of this, since nearly all 2600 carts have already been dumped.

I tried it, and was unsuccessful. Are you sending a start bit, 8 data bits, then a stop bit? If not, that may be the problem.

[supercat]

batari, on Sun Oct 23, 2005 6:34 PM, said:

I tried it, and was unsuccessful.  Are you sending a start bit, 8 data bits, then a stop bit?  If not, that may be the problem.

Should be, except I forgot something. Because of how LSR works, the data byte passed in needs to be inverted, and the outgoing data will then also be inverted. My bad.

[Waggie]

Well I finally gave this a try and everything worked except my capture file ends up being 41,656 bytes and it won't transform into a working bin file. Any suggestions for someone who has very limited knowledge of how this works?

I tried to dump two different games with the same results.

[keilbaca]

Can you do this with regular carts as well?

and has anyone tried it with a supercharger? I don't see why it wouldn't work, when you switch it, you just see load tape, then play the image using wplaybin. It loads then proceed.

Anyone wanna try this?

[Waggie]

Waggie, on Tue Nov 22, 2005 9:32 PM, said:

Well I finally gave this a try and everything worked except my capture file ends up being 41,656 bytes and it won't transform into a working bin file.  Any suggestions for someone who has very limited knowledge of how this works?

I tried to dump two different games with the same results.

Just a quick follow up to clarify my setup:

I am doing this on a regular six switch with the dump bin loaded on an A26 Maxicart. I downloaded a free terminal program called realterm and set the parameters as specified above (there were a lot of other options I left on the default settings). I made a cable by cutting the end off a db9 one and hooking up the pins on the Atari side with a female crimp style plug picked up from Radio Shack (you have to go to the non-mall locations). I had to use an Ohm meter and a paper clip to identify the correct wires to hookup.

[batari]

Waggie, on Wed Nov 23, 2005 9:28 AM, said:

Waggie, on Tue Nov 22, 2005 9:32 PM, said:

Well I finally gave this a try and everything worked except my capture file ends up being 41,656 bytes and it won't transform into a working bin file.  Any suggestions for someone who has very limited knowledge of how this works?

I tried to dump two different games with the same results.

Just a quick follow up to clarify my setup:

I am doing this on a regular six switch with the dump bin loaded on an A26 Maxicart. I downloaded a free terminal program called realterm and set the parameters as specified above (there were a lot of other options I left on the default settings). I made a cable by cutting the end off a db9 one and hooking up the pins on the Atari side with a female crimp style plug picked up from Radio Shack (you have to go to the non-mall locations). I had to use an Ohm meter and a paper clip to identify the correct wires to hookup.

Can you post a sample of the dumped file? It should be around 32,768 bytes and consist of nothing but 0-9 and A-F. If not, there could be a problem with the terminal program, connection settings, or serial port.

If you are running Windows 95 or later, you should have Hyperterminal (or if not, it's on the install disks and you can get it there.) The utilities are known to work with Hyperterminal.

[Waggie]

Thanks batari, switching to hyperterminal worked! I successfully dumped Power Off! and QB Holiday Edition. Now I need to find the parts for modding a FB2.

[yuppicide]

I got lost in the beginning it says:

"First, you should see if your programmable cart will your on your FB2." -- don't you mean run on your FB2?!

[Moondoggie1968]

can I use the dump utility on a regular 2600?

[jaybird3rd]

Moondoggie1968, on Thu Jan 19, 2006 8:39 AM, said:

can I use the dump utility on a regular 2600?

I suspect not. An Atari 7800 with a DevOS ROM installed is a much better choice for 2600 dumping.

[Mitch]

Moondoggie1968, on Thu Jan 19, 2006 5:39 AM, said:

can I use the dump utility on a regular 2600?

Yes, but you will be pulling out and putting in carts with the power on. If that bothers you.

Mitch

[Moondoggie1968]

Mitch, on Thu Jan 19, 2006 4:55 PM, said:

Moondoggie1968, on Thu Jan 19, 2006 5:39 AM, said:

can I use the dump utility on a regular 2600?

Yes, but you will be pulling out and putting in carts with the power on. If that bothers you.

Mitch

Not now, and not even 24 years ago after I did it a couple of times and realized that was a myth concocted by the atari engineers.

[PacManPlus]

It's not a myth - I actually ruined a 7800 by accidentaly removing a cart with the power on.

[batari]

jaybird3rd, on Thu Jan 19, 2006 9:57 AM, said:

Moondoggie1968, on Thu Jan 19, 2006 8:39 AM, said:

can I use the dump utility on a regular 2600?

I suspect not.

Actually, yes, you can.

Quote

An Atari 7800 with a DevOS ROM installed is a much better choice for 2600 dumping.

But you need a 7800. This will work on a 2600.

[Moondoggie1968]

batari, on Sat Jan 21, 2006 5:50 AM, said:

jaybird3rd, on Thu Jan 19, 2006 9:57 AM, said:

Moondoggie1968, on Thu Jan 19, 2006 8:39 AM, said:

can I use the dump utility on a regular 2600?

I suspect not.

Actually, yes, you can.

Quote

An Atari 7800 with a DevOS ROM installed is a much better choice for 2600 dumping.

But you need a 7800. This will work on a 2600.

would it be possible to make a card adapter for my eprom burner and read it in there?