Little home project: ROM dumper

[+SvOlli]

Hello everyone!

 

I was using the coronavirus lockdown time to code for a project, I'd had lying around for a couple of weeks. A simple and versatile ROM dumper that's rather easy to build.

 

It just consists of two parts: a Teensy++ 2.0 and a cartridge connector. It is arranged on a small through hole soldering board, and for better handling a 3D printed cartridge slot was added.

 

Right now the software written for Linux is working fine and can dump 2k/4k and F8/F6/F4 cartridges, but the software is written in a way that should make it rather easy to port the software to other platforms (just the function for setting the serial configuration is specific) and to add dumpers for other bankswitching types. To keep things simple, the code for the host side is written in C for a small command line tool, the microcontroller is a simple Arduino sketch.

 

I'm a bit undecided on where to go from here. Would it make sense to get set up a git repository with the build instructions and the code for the microcontroller and the frontend dumper? Or has any cartridge that's available already been dumped?

 

Here are some images.

The board without a cartridge:

 

The board with a cartridge:

 

The underside of the board:

 

Edit: the project is now published on github and my own git server.

Edited April 22, 2020 by SvOlli

[chewy]

nice

Edited April 19, 2020 by chewy

[chewy]

 

Edited April 19, 2020 by chewy

[JohnnyRockets]

Now you got me interested in the Teensy board!

 

JR

[+SvOlli]

17 hours ago, chewy said:

perfect for dumping M-Network games

Well, I've got to write the dumper first, but that was one thing I had in mind building the dumper.

[Yoruk]

Interesting project !

[chewy]

double sry

Edited April 20, 2020 by chewy
double- sry

[chewy]

2 hours ago, SvOlli said:

Well, I've got to write the dumper first, but that was one thing I had in mind building the dumper.

 

like super challenge football and star strike 

[+SvOlli]

Now I can use some help.

 

I've gone through my collection of games and found the following bank switching types: 2k, 4k, F8, F6SC, F4, and F4SC.

 

I'm looking for some games / cartridges which utilize some of the more exotic bank switching types. I know I could use the Harmony Cart to mimic everything available, but to have a small collection of "testcarts" would be nice. So I'm looking for suggestions for carts with the requirements in the following order:

- cheap (that includes shipping to Germany)

- fun

- PAL

And also for using the Harmony Cart, a list a reference carts for a bank switching type with one available ROM per type.

Also note, that only non Harmony specific types are wanted, so no DPC+ .

[JetSetIlly]

18 minutes ago, SvOlli said:

Now I can use some help.

 

I've gone through my collection of games and found the following bank switching types: 2k, 4k, F8, F6SC, F4, and F4SC.

 

I'm looking for some games / cartridges which utilize some of the more exotic bank switching types. I know I could use the Harmony Cart to mimic everything available, but to have a small collection of "testcarts" would be nice. So I'm looking for suggestions for carts with the requirements in the following order:

- cheap (that includes shipping to Germany)

- fun

- PAL

And also for using the Harmony Cart, a list a reference carts for a bank switching type with one available ROM per type.

Also note, that only non Harmony specific types are wanted, so no DPC+ .

 

I use this document as a reference for what switch method a cartridge uses:

 

http://www.classic-games.com/atari2600/bankswitch.html

 

(I'd love to know more about how Tigervision cartridges switch banks)

Edited April 21, 2020 by JetSetIlly

[+Andrew Davie]

AFAIK, 3F is Tigervision.

3E is a modification of that. I used 3F early on, and now 3E a lot.

3F:

Fixed bank 2K, switchable bank 2K.  

In 3F, you change the switchable bank by writing bank # to 3F.

Fixed bank mapped $F800-$FFFF

Switchable bank mapped $F000-$F7FF

So you get 256 * 2K switchable banks = 512K ROM size

 

 

 

In 3E, the above, PLUS...

write to 3E to switch a RAM bank to $F800

The RAM bank is just 1K.

Use addresses $F000-$F3FF to read the RAM

Use addresses $F400-$F7FF to write the *same* RAM

In theory, 512K ROM + 256K RAM

 

 

However, technically, 3E is limited to 32K RAM (by convention, not design).

Also, VERY technically, "lda (addr),y" cannot cross page boundaries in 3E.  But emulators do not implement this.

It's a historical "glitch" caused by Krokodile Cart implementation not having enough memory to handle the page crossing in implementation of 3E.

Even more technical stuff - the Cuttle Cart 2 does 3E, but is limited to 480K ROM and 32K RAM.

 

 

 

 

 

I believe the reset vectors in all of these are located in the last bank/bytes of the ROM.

 

Edited April 21, 2020 by Andrew Davie

[idolpx]

On 4/19/2020 at 9:18 AM, SvOlli said:

I'm a bit undecided on where to go from here. Would it make sense to get set up a git repository with the build instructions and the code for the microcontroller and the frontend dumper? Or has any cartridge that's available already been dumped?

Definitely post the project on github.  I'd star it!  :)

[+batari]

1 hour ago, Andrew Davie said:

Also, VERY technically, "lda (addr),y" cannot cross page boundaries in 3E.  But emulators do not implement this.

It's a historical "glitch" caused by Krokodile Cart implementation not having enough memory to handle the page crossing in implementation of 3E.

Even more technical stuff - the Cuttle Cart 2 does 3E, but is limited to 480K ROM and 32K RAM.

I wasn't aware of the page-boundary crossing limitation.  I think that purposely limiting 3E because of a Kroko cart glitch doesn't make much sense, though, when no other hardware platform is likely to have that same limitation.

 

[+batari]

If it would help with this at all, I can try to dig up the Harmony cart dumper source. I think it is on a portable drive somewhere in my stuff.

 

It supported 2k, 4k, F8, F6, F4 (with or without Superchip), FA, E0, E7, FE, 3F/3E, Megaboy (F0?), and could auto-detect any of those. It also had a custom setting that could dump yet-unknown types, which I used to dump a prototype game 10 years ago (that has recently been released.) I think it is written in C so it should be pretty easy to follow.

[+Andrew Davie]

22 minutes ago, batari said:

I wasn't aware of the page-boundary crossing limitation.  I think that purposely limiting 3E because of a Kroko cart glitch doesn't make much sense, though, when no other hardware platform is likely to have that same limitation.

 

I tend to agree, but it's not a "glitch" - 3E was originally designed on/by the KK.  My point is, this was a deliberate and known design decision, not an error. It came about because there was no space left on the KK to support page crossing in "lda (addr),y" addressing. As an aside, the whole of Boulder Dash was designed/written with this limitation in mind and it was a major major pain.

 

Well yes it's undesirable. But that's what 3E *was*.  If you redefine 3E as NOT having that limitation, then you invalidate earlier usage.

 

There is also a 32K RAM limitation due to KK but also due to CC2.  AND CC2 has a 480K ROM limitation on top of that.

I'm all for a scheme "3E-like" which as no lmitations. I'm just suggesting that keeping the original implementation as-is is my preference.

 

Also also, Stella and some other emulators don't correctly emulate the "glitch" anyway.  Fortunately, a "well written" 3E program will run on a "poorly implemented" 3E emulator implementation.

There is some discussion on this in the stella issues section on github.

Edit: there is apparently one demo out there using 3E which *relies* on 32K RAM bank numbers wrapping to 0.  So, Stella at least limits RAM to 32K both as part of the original 3E spec, but also because of this "in the wild" demo that relies on that, to work.

A new scheme, whatever it may be called, would I hope support 512K ROM and 256K RAM.

Edited April 21, 2020 by Andrew Davie

[JetSetIlly]

deleted

Edited April 22, 2020 by JetSetIlly
answered in another thread

[+batari]

35 minutes ago, Andrew Davie said:

I tend to agree, but it's not a "glitch" - 3E was originally designed on/by the KK.  My point is, this was a deliberate and known design decision, not an error. It came about because there was no space left on the KK to support page crossing in "lda (addr),y" addressing. As an aside, the whole of Boulder Dash was designed/written with this limitation in mind and it was a major major pain.

 

Well yes it's undesirable. But that's what 3E *was*.  If you redefine 3E as NOT having that limitation, then you invalidate earlier usage.

 

There is also a 32K RAM limitation due to KK but also due to CC2.  AND CC2 has a 480K ROM limitation on top of that.

I'm all for a scheme "3E-like" which as no lmitations. I'm just suggesting that keeping the original implementation as-is is my preference.

 

Also also, Stella and some other emulators don't correctly emulate the "glitch" anyway.  Fortunately, a "well written" 3E program will run on a "poorly implemented" 3E emulator implementation.

There is some discussion on this in the stella issues section on github.

Edit: there is apparently one demo out there using 3E which *relies* on 32K RAM bank numbers wrapping to 0.  So, Stella at least limits RAM to 32K both as part of the original 3E spec, but also because of this "in the wild" demo that relies on that, to work.

A new scheme, whatever it may be called, would I hope support 512K ROM and 256K RAM.

I see your point. But, it seems that a version of 3E with correct page-wrapping would be more of a superset of 3E, and that would work with any 3E program that did not exploit this limitation (and rightfully, none *should*). It kind of sucks that one demo does exploit it, because that in itself limits the flexibility in implementation.

 

What exactly does the Kroko cart do? If (addr),y wraps a page, does it return (addr)+y-$100, or something else entirely?

 

As I work on 3E for Harmony Encore, I now have a decision of whether to implement this limitation or implement a superset of 3E that works correctly with page wraps. I am inclined to not implement the limitation on page wraps because that would actually require quite a bit more effort and the end result is something considerably less useful. Depending on what the Kroko cart actually does, it might be pretty difficult to figure out how to not only detect a page-wrapping (addr),y but purposely send the wrong value from the Harmony's own RAM.

 

Just curious, can the firmware (or, more accurately, the CPLD's fusemap) of the Kroko cart be easily updated? If so, I wonder if there is the possibility that the issue could be fixed (perhaps, with a compromise somewhere else). Then, maybe the limitation wouldn't need to be a part of 3E anymore.

 

If you are looking at a new scheme, though, 3E isn't ideal. The benefits of 3E include the ability to address large amounts of ROM/RAM and a theoretical shot at implementation back in the day, but I think from a programming standpoint it could be much better. First step is to eliminate the fixed bank somehow.

[+Andrew Davie]

2 hours ago, batari said:

I see your point. But, it seems that a version of 3E with correct page-wrapping would be more of a superset of 3E, and that would work with any 3E program that did not exploit this limitation (and rightfully, none *should*). It kind of sucks that one demo does exploit it, because that in itself limits the flexibility in implementation.

I think you may be mixing two issues.

Firstly, the "lda (zp),y" is unable to increment zp+1, so it effectively wraps on a page level, yes.

There are no demos/binaries that exploit this AFAIK.  Boulder Dash was written to avoid this being a problem, but it does not rely on it happening.

Consequently, Boulder Dash will run on any 3E implementation which does NOT implement the wrap "correctly". It will work on both, in other words.

 

However, the other issue is RAM bank wrapping.  3E was defined as 32K maximum (due to KK limit, and also CC2 limit).  There is apparently one demo out there that relies on bank #32 in actual fact being bank #0.  In other words, that RAM wraps at 32K.

 

So, 

a). "lda (zp),y" not implemented correctly/fully

b). 32K bank limit in RAM

 

2 hours ago, batari said:

What exactly does the Kroko cart do? If (addr),y wraps a page, does it return (addr)+y-$100, or something else entirely?

 

The carry in the addition of y+addr does not affect the high byte.

addr --> (addr+y) & 0xFF

addr+1 --> unchanged

 

2 hours ago, batari said:

 

As I work on 3E for Harmony Encore, I now have a decision of whether to implement this limitation or implement a superset of 3E that works correctly with page wraps.

If you do NOT implement the limitation, all current binaries that I am aware of should run perfectly.

 

It is the 32K maximum limitation that will break that (one) demo.  AFAIK. I don't know which it is, only that it has been stated a demo relies on it.

 

2 hours ago, batari said:

Just curious, can the firmware (or, more accurately, the CPLD's fusemap) of the Kroko cart be easily updated? If so, I wonder if there is the possibility that the issue could be fixed (perhaps, with a compromise somewhere else). Then, maybe the limitation wouldn't need to be a part of 3E anymore.

 

Probably. Who uses a KK anymore, though. I don't know.

 

2 hours ago, batari said:

 

If you are looking at a new scheme, though, 3E isn't ideal. The benefits of 3E include the ability to address large amounts of ROM/RAM and a theoretical shot at implementation back in the day, but I think from a programming standpoint it could be much better. First step is to eliminate the fixed bank somehow.

Totally agree.

 

But this is a discussion about what is 3E. And I'm not trying to be difficult, I am just pointing out the actual technical specifics of what 3E "is", or at least what I understand it to be, and why that is so.  After all, the features it has, such as they are, were designed by Armin and myself. I asked for the page wrap to not be the way that it is, because it sucks, but Armin didn't have any space. So, it is what it is.

The only real issue for me is I don't want to be in a situation, down the track, where some 3E binaries work, and some don't, because different hardware or emulators have implemented the 3E differently. In particular, KK is a historical/old bit of kit now, and the origin of the 3E bankswitch method. It seems wrong to me, somehow, to retroactively break that when it would be simple-as to simply define a new scheme and all understand that there are differences.

 

[Thomas Jentzsch]

I have just added a new scheme 3EX to the "refactor-cart" branch of Stella. This one supports 256K RAM, else it is identical to 3E. However the fixed bank at the 2nd 2K segment and the segment size itself are severe limitations, which Andrew and I found out when implementing Boulder Dash.

 

After some experimenting I came up with 3E+, which is basically 3E with 1K segments. There are some other bells and whistles (e.g. last segment is not fixed), but these are no that important. The disadvantage of 3E+ is, that it only supports 64K ROM and 32K RAM. This seemed plenty back then, but today it may have become a bit too small.

 

BTW: Bad Apple is the demo which relies on 3E wrapping around RAM at 32K.

Edited April 22, 2020 by Thomas Jentzsch

[+SvOlli]

18 hours ago, idolpx said:

Definitely post the project on github.  I'd star it! 

Cleaning up the project took me the whole evening: https://github.com/SvOlli/retrocartdumper

[Dionoid]

I noticed that you added the SuperBanking bankswitching scheme. Cool ?

[+SvOlli]

It is yet untested, as the package arrived, when I was out for groceries. It I had known, I would have skipped the groceries.

Test will be conducted soon.

[Dionoid]

I think it should work. I've tried dumping the SuperBank cart using @Thomas Jentzsch's dump-to-savekey software, which worked fine (4 x 32k dumps to savekey).

[+SvOlli]

Yes, now it's tested, and I can tell which bytes differ between download and cartridge.

[Dionoid]

I just ordered a Teensy++ 2.0 from eBay to be able to build your dumper. Looking forward to it!