13 replies to this topic

[Bruce Tomlin]

It was about time someone wrote a 7800 digital signature generator that didn't need some monster crypto library to make it work. The other day, I dug out my start at hand-decompiling the old Atari ST utility and got back to work on it.

Well, after a bit of heavy debugging to find some minor errors, I got it to work. So here it is. Just plain C, should compile for anything.

The debugging took a bit of work. I had three off-by-one errors in my conversion, and I ended up having to run the old code under a 68000 emulator to compare intermediate steps. It took me a day and a half to debug the encryption code, which was not helped by the emulated encryption taking over 15 minutes to run one attempt, nor was it helped by the first 68000 emulator I tried being unfinished and buggy. (Kudos to the folks who wrote the Castaway emulator. I was able to get it to run an arbitrary code image file relatively quickly, and once I stopped it from insisting on compiling for little-endian, it was rock solid.)

Attached Files

•  sign7800.zip   7.77K   209 downloads

[Tom]

now *that's* nice. great work.

[Bruce Tomlin]

A few notes on this:

First, I just noticed that in my determination of the signature area of a cart being "empty", I really should have checked for all FF's as well as all 00's. I've already made this fix and it will get included if I release another revision. Since this is just a "nice thing to have" feature, there's no urgency to release a fix any time soon.

Hand-decompiling the code was made much easier because there was a symbol table in the Atari ST binary, with almost all of the important subroutines and globals identified. As it turned out, very little of the code was important, because so much of it was junk (including an entire floating point library) linked in due to the use of printf, or other C library stuff. Right away I could throw away most of the code.

The main program was a lot easier to decompile, since it was clearly compiler-generated code. I was amused to find a few places where the newbie C programmer blunder of 'if (c == "I")' was made. These blunders were all in code related to Intel Hex support, so the original 7800 programmers apparently always used Motorola S9 files.

The important code was done as plain 68000 assembler. Since it took so long to run (probably on the order of what my emulated runs took), I'm sure they needed to do this just for speed alone. This was a bit tougher to translate, but was still doable, and much easier than translating the 6502 code was. And after all, they had already done the hard part, which was to get the heavy math to work in the first place.

[Tom]

now if one added support for creating a78 headers, then there would be one tool that:

- compiles out of the box, just about ony any machine where a c compiler is available, and without the insane crypto library.
- can sign rom images
- optionally adds a78 headers in case you want to test on mess

[Bruce Tomlin]

The problem with that is the important parts of the A78 header (such as bank switching info) are info that can not be automatically determined from the contents of the cartridge itself. Or there wouldn't be a need for the A78 header in the first place. So you're going to have to specify half a dozen parameters on the command line to make it useful.

We already have .A78 files for all the dumped cartridges. Let's have enough people writing new games before we worry so much about .A78 files. Besides, .A78 files are for running under an emulator anyhow. I don't see why an emulator should even have to care about what's in the encryption, much less what's in the boot ROM. (since all the ROM does anyhow is determine whether it's a 7800 or 2600 cart and if the encryption is valid)

I don't see why .A78 headers should be handled by a utility that also does encryption. Make it a separate utility and avoid the damn mission creep. In fact, why hasn't someone written it already? It's not like you needed to wait for someone to write encryption code.

[Tom]

Bruce Tomlin said:

...I don't see why an emulator should even have to care about what's in the encryption, much less what's in the boot ROM

well, the emulator doesn't care about the encryption itself, but the 7800 bios you're using with the emulator does...

anyway, that was just a suggestion, and i'm fine with using two different tools, one for signing and one for creating the header.

Bruce Tomlin said:

Make it a separate utility and avoid the damn mission creep. In fact, why hasn't someone written it already? It's not like you needed to wait for someone to write encryption code.

oh, it's not like people waited with writing header tools
there exists dan boris' 78hdr, and i'm using an own tool:
ftp://ftp.profzone.ch/vantage/members/kil.../mka78-0.99.zip

[Bruce Tomlin]

Tom said:

Bruce Tomlin said:

...I don't see why an emulator should even have to care about what's in the encryption, much less what's in the boot ROM

well, the emulator doesn't care about the encryption itself, but the 7800 bios you're using with the emulator does...

My point was that it's completely useless for an emulator to even bother with the ROM, since it does nothing other than 1) see if it's really a 7800 game, 2) put up the Atari title screen and 3) verify the encryption. Number 1 isn't important, since you already know you're running a 7800 game. Number 3 isn't something you should want to emulate. Number 2 is nifty, but still useless.

It's not like in a real console where you can't just pull out the ROM. With an emulator you have a choice not to use it. And it does nothing essential to the running of a cartridge which is already known to be for the 7800. It's just DRM. So why do the emulator people even bother?

[voy]

And now... Amiga port of sign7800 has been realeased! This port requires a MC68000+ processor and ixemul.library to work... I'm thinking about compiling this cool prog for MorphOS and WarpOS.

Attached Files

•  sign7800.zip   17.1K   65 downloads

[debugger]

MorphOS would be interesting

[EricBall]

First, great work Bruce! I know there have been requests for this in the past by people who couldn't use a78sign. Question - is the signature generated by your utility 100% the same as that generated by the original Atari utility & a78sign?

Also, how does your utility determine how much of the bin to use for the signature (for future bankswitched carts)?

Regarding the a78 header - I, for one, simply add the required info to the ASM to automatically generate the a78 header.

And although the header & signature may not be required to execute the game via an emulator (or CC2), the signature will be required if/when physical cartridges are manufactured. The a78 header also provides an elegant method to provide meta information about the game to the emulator.

[Bruce Tomlin]

Quote

First, great work Bruce! I know there have been requests for this in the past by people who couldn't use a78sign. Question - is the signature generated by your utility 100% the same as that generated by the original Atari utility & a78sign?

It's a direct translation of the 68000 code into C. The only way in which the signature is different is in the choosing of the "wildcard" byte to find a valid solution. The original utility added together a bunch of assorted numbers to determine its starting point, when it really didn't matter. If one in four solutions work, there could be over sixty valid signatures. I could theoretically make the code take five minutes finding every one of them, and let you choose the most asthetically pleasing combination of hexadecimal numbers, but that would be silly.

Quote

Also, how does your utility determine how much of the bin to use for the signature (for future bankswitched carts)?

It's in the documentation. It looks at $FFF9.

Quote

Regarding the a78 header - I, for one, simply add the required info to the ASM to automatically generate the a78 header.

And although the header & signature may not be required to execute the game via an emulator (or CC2), the signature will be required if/when physical cartridges are manufactured. The a78 header also provides an elegant method to provide meta information about the game to the emulator.

Which doesn't help much at all when using the real hardware all the time. I use a hacked 7800 which ignores the result of the decryption. And I now have a clamp-on LCD screen.

I'm not entirely impressed with emulators anyhow. I just tried my current project with MESS 0.70 (the current Mac OS X version), and it completely duffed the emulation of 320B video mode. There's no way could I have gotten as far as I have by relying on an emulator. :-)

Edited by Bruce Tomlin, Fri Apr 21, 2006 7:23 PM.

[EricBall]

Quote

I'm not entirely impressed with emulators anyhow. I just tried my current project with MESS 0.70 (the current Mac OS X version), and it completely duffed the emulation of 320B video mode. There's no way could I have gotten as far as I have by relying on an emulator. :-)

Yup, there were some major bugs in many of the video modes in pre 0.79 versions of MESS (which I helped fix). Unfortunately, it doesn't appear that there is a current version of MacMESS available. That's not to say that MESS is perfect. It doesn't emulate the MARIA robbing blind the 6502 of cycles during active video.

I'd love to hear about any 7800 projects and would encourage you to subscribe to atari7800@freelists.org (very low traffic at the moment).

[Knarfian]

Bruce,

Thanks for doing this. When I wrote a78sign, I was interested in understanding the crypto techniques that were used. That's why I started from scratch with a crypto library, and attempted to document the algorithm in the code, rather than blindly converting the 68K program.

I had partially converted a78sign to vanilla python a while back, but never finished the file parsing part (the crypto works though). If someone wants the code I can dig it up.

At any rate, you can build a78sign for Linux and Mac, although no-one ever bothered too. If there is still a demand I can build it for Linux.

Thanks,
Frank

[Bruce Tomlin]

And I was glad that someone else had gotten a program working to generate 7800 signatures, so I could take my time on it. The past five years or so, I haven't really been able to do much recreational programming (moving from San Antonio to Austin to get a job, then having to get another job, then buying a house and getting the rest of my crap slowly moved up the highway during weekend trips, all while my main hobby at the time was anime fandom), or I would have done this long ago.