EEPROM Functions in C

[Brek Martin]

Hi

I was going to share the perfected, minimised functions,

but am instead going to share the first working, most verbose and inflexible code.

 

These are new functions to use EEPROM directly within C.

 

First, the Lynx will display "11 11" when the EEPROM Write Enable instruction was sent.

It doesn't mean success, just that it didn't freeze.

Next "22 22" will display when an EEPROM Write Data instruction has occurred.

It doesn't mean success, just that it didn't freeze.

Next "33 33" will display when an EEPROM Write Protect instruction was sent.

It doesn't mean success, just that it didn't freeze.

Next, "DE AD" will display when an EEPROM Read Data instruction occurred.

It doesn't mean.. oh hang on. This time it means some success!

The Write Enable instruction was successful.

The Write Data instruction was successful.

The Read Data instruction was successful.

Because 0xDEAD was the data written and verified, and really means Alive!!!

 

Thanks to Bastian for clarifying how to use Lynx ROM bus pins to do addressing.

Thanks to Ben Eater YouTube video for the refresher of how to check in bits in C.

 

There is vast room for improvement.

One file is the output from Felix emulator.

Enjoy!

 

Art_EEPROM.lnx Art_EEPROM.c Art_EEPROM.lnx.e2p

Edited June 29 by Brek Martin

[42bs]

The cc65 library has EEPROM functions that can be used from C.

So what you do is, re-writing them in C. For what purpose? Learning?

[Brek Martin]

5 minutes ago, 42bs said:

The cc65 library has EEPROM functions that can be used from C.

So what you do is, re-writing them in C. For what purpose? Learning?

Isn't it why we do this? For maximum control and least unknown about a system?

Through doing it I learned half of what it takes to load new data from a ROM cart too.

 

But why in the first place.... I guess I'm also motivated to be able to say all original code in my games, even if I got help.

Also I guess easier to write tis and sample playback than figuring out C make files

 

 

[+karri]

On 6/29/2024 at 6:09 PM, Brek Martin said:

Through doing it I learned half of what it takes to load new data from a ROM cart too.

Most games have some structure like a directory, files and so on. The cc65 directory was just written to let you use seek, read, write as in C libraries usually. But there is nothing that restricts you from ditching the entire filesystem and just design what you want in the rom. The only thing you need is an encrypted loader that decrypts and starts the game. The real Lynx ROM knows nothing about directory entries or start images. These are defined in the encrypted loader.

[Brek Martin]

6 hours ago, karri said:

Most games have some structure like a directory, files and so on. The cc65 directory was just written to let you use seek, read, write as in C libraries usually. But there is nothing that restricts you from ditching the entire filesystem and just design what you want in the rom. The only thing you need is an encrypted loader that decrypts and starts the game. The real Lynx ROM knows nothing about directory entries or start images. These are defined in the encrypted loader.

I assume, and could very well be wrongly, that once my program is loaded, it can look at ROM content directly.

I know only roughly about Lynx game encryption, and why we can hex edit our own binaries, but seemly not Atari's.

 

It has only come to mind so far to make RAM games, but one reason I might want to load data is for audio samples.

Speaking of hex editing binaries, I also assume it doesn't matter how the data got into the game ROM,

so long as it's there when the program goes looking for it.

 

[+karri]

The Lynx uses a RSA key for decryption. The encrypted part is a multiple of 51 bytes. Most implementations use a single 51 byte loader that has a small cart loader and requires a single directory entry.

[42bs]

Original ROMs make a checksum on the ROM contents. The checksum routine is part of the encrypted header. 
Gauntlet has a bug, it calcs the sum only of half of the block sizes 

Edited July 1 by 42bs

[laoo]

It could be an interesting story how this bug has been found.

[42bs]

On 7/1/2024 at 3:07 PM, laoo said:

It could be an interesting story how this bug has been found.

We modified Gauntlet ROM and found that it still started when certain addresses were changed.

Then we did insert some code until we saw it was executed. We already knew some addresses, so a

inc $fda0
bra *-2

served as detection.

Next was to find the "screen" memory and once we got it, we could dump the ROM (as binary !).

Our first code was split into the "unchecked" parts of the blocks until I managed to write the troian horse to hijack the boot header.

 

So we were lucky because AFAIK, no other game has these two bugs.

 

Edited July 6 by 42bs

[Brek Martin]

I'm still confused. I understood there was game encryption early on to prevent unlisenced games rather than copying,

and assumed the cc65 compiler must have done something to take advantage of an exploit to run homebrew.

 

However, once a game is loaded, the joypad input works, so how can reading from a ROM require further decryption from the same port as joypad input?

Of course I could go ahead and fill the remaining 256kB of file with a known value and read it,

but I did say this exercise only taught me half of it. I haven't used the shift register yet.

 

Edited July 6 by Brek Martin

[42bs]

No "game" encryption. Only the boot sector was encrypted. But it calculates a checksum on the complete ROM.

But yes, it was meant to prevent unlicensed games. Copying a game card in 1993 was not an easy task to do. Esp. if you wanted to make real fakes not just green PCBs (No 3D printing!)

And cc65 is just a C compiler.

Before the encryption was cracked the BLL's troian horse was added to a ROM: The Gauntlet bootsector plus an modified title-image (the troian horse).

Nowadays one can make his/her own boot sector with the encryption tool (see the bunch of bootSector intros I did 🙂 )

 

This has nothing to do with the buttons. In general the the resistors prevent that the buttons can have an impact on the data read on from ROM.

Edited July 6 by 42bs

[Brek Martin]

55 minutes ago, 42bs said:

 

 

This has nothing to do with the buttons. In general the the resistors prevent that the buttons can have an impact on the data read on from ROM.

Ok, I'm aware of this. That was just to say Suzy can't be encrypting all data coming in on the port or the joypad input would also be encrypted (and of course it isn't).

 

I have hex edited homebrew, so the checksum somehow did not apply to that.

The boot menu of the ElCheapo flash cartridge. Because I couldn't build the source without it's special libraries,

so I changed it's colours to higher contrast by editing it's palette table, and changed joystick behaviour by editing code.

 

I am most interested now in music, so I'll pick this all up later I guess.

 

 

 

[42bs]

Of course the data on the cart (the boot sector to be precise) is encrypted. Suzy has nothing at all to do with this. The boot ROM decrypts it.

 

32 minutes ago, Brek Martin said:

I have hex edited homebrew,

T-Tris and SIMIS, both checksum the ROM. A single bit changed and they stop booting.

[+karri]

If you are interested in Lynx music perhaps we could team up on a new compressed Furnace Tracker romdump.

 

Furnace Tracker is the best tool for Mikey music imho. Basically the idea is to store register changes as runlenght compressed streams and use huffman to further compress it. Then you just fetch a byte at a time at every interrupt. The romout technique will also maintain the structure of the tune like repeating sections, shared instruments etc 

[42bs]

I just checked one of the demo songs, with LZ4 it compresses from 74K down to 10k.

[Brek Martin]

1 hour ago, karri said:

If you are interested in Lynx music perhaps we could team up on a new compressed Furnace Tracker romdump.

 

If you're talking to me, you're talking to someone who can't figure out how to include or compile abc music,

and also would write EEPROM functions sooner than figuring out how to use the existing ones.

I could still not use Bastian's EEPROM functions if I wanted to.

This is also why I have my own audio sample code.. although that's much simpler.

 

But I do understand the audio registers, and my next course of action was to simply

cycle through all pitches (which I already have a program doing), and try to come up with a table of matching notes.

I assume this is how abc music was made. I also do have an understanding of the bits that alter apparent "instruments" and volume.

 

Furnace Tracker is a new name for me though... Sounds interesting. I'll look it up.

 

 

[+karri]

Oops. Well in that case I can post a link when I have finished the Mikey export from Furnace Tracker.

 

If you just want to play around with abcmusic there is a pure C version in my bitbucket repository. https://bitbucket.org/atarilynx/lynx/src/master/contrib/abcmusic/cversion/ 

 

The C-version requires nothing to install. Just compile and use it.

[laoo]

@karri Can you elaborate about this Mikey export?

You are working on equivalent of my VGM export but with compression? RLE+Huffman?

I was planning to do LZSS stream, but there is always something with higher priority.

 

[42bs]

I wonder, does it make sense to add a packer to the VGM export? There are plenty of packers arround and if the VGM file is already packed somehow, there is no chance to pack it again.

The above mentioned VGM is packed down to 3.5K with UPKR.

[+karri]

I am using LZ for every register and huffmunch for getting a byte at a time on Atari 7800 using the SN chip. But this was based on VGM. The problem is that VGM does not preserve the structure of the music so it wastes space.

 

Currently I am using an extension that allows me to dump the music directly from Fusion Tracker by a shell command:

 

./fusion -romout dest_directory music.fur

 

The structure it exports has all the structures like song, patterns, waveforms. This means that you do not have to repeat any data in the stream.

 

@Dave C will probably shortly do the pull request with the LZ + Huffmunch compression in place. I hope to extend on that code to make it work on Mikey as well.

 

So I want to ditch VGM exports completely.

 

The output creates a hello world kind of source that you can compile to a cart. The songs are exported as a single file with several tables that work with the driver code.

 

Edit: another feature I am using in my 7800 code is subsongs. You can create any number of subsongs and just switch the song from the main program when you want. So you will get all the songe by a single export. Most games have a need for multiple tunes.

 

Edit2: I have a working TIA furnace with romout. At karrika/furnace at Mikey-rom-export (github.com)

 

This still lacks compressions but works ok.

[42bs]

1 hour ago, karri said:

I am using LZ for every register and huffmunch for getting a byte at a time on Atari 7800 using the SN chip. But this was based on VGM. The problem is that VGM does not preserve the structure of the music so it wastes space.

 

Currently I am using an extension that allows me to dump the music directly from Fusion Tracker by a shell command:

 

./fusion -romout dest_directory music.fur

 

The structure it exports has all the structures like song, patterns, waveforms. This means that you do not have to repeat any data in the stream.

 

@Dave C will probably shortly do the pull request with the LZ + Huffmunch compression in place. I hope to extend on that code to make it work on Mikey as well.

 

So I want to ditch VGM exports completely.

 

The output creates a hello world kind of source that you can compile to a cart. The songs are exported as a single file with several tables that work with the driver code.

 

Edit: another feature I am using in my 7800 code is subsongs. You can create any number of subsongs and just switch the song from the main program when you want. So you will get all the songe by a single export. Most games have a need for multiple tunes.

 

Edit2: I have a working TIA furnace with romout. At karrika/furnace at Mikey-rom-export (github.com)

 

This still lacks compressions but works ok.

=>

 

Edited July 6 by 42bs

[Brek Martin]

9 hours ago, karri said:

Oops. Well in that case I can post a link when I have finished the Mikey export from Furnace Tracker.

 

If you just want to play around with abcmusic there is a pure C version in my bitbucket repository. https://bitbucket.org/atarilynx/lynx/src/master/contrib/abcmusic/cversion/ 

 

The C-version requires nothing to install. Just compile and use it.

I'll certainly try it, but yes I have been to that very page, and investigated it before.

To be clear, this is my own failing.

I have a good grip on C. Pointers, the lot... except the rest of the dev environment sometimes, and particularly concerning make files.

 

Mind you, the invitation to team up with something is flattering that you'd think that way,

but I think you'd be inviting punishment on yourself!  

Edited July 7 by Brek Martin

[Nop90]

@Brek Martin

For another example of including the abc music driver and using it take a look here: https://github.com/nop90-atari-lynx/Santafactory

 

 

 

[Brek Martin]

4 hours ago, Nop90 said:

@Brek Martin

For another example of including the abc music driver and using it take a look here: https://github.com/nop90-atari-lynx/Santafactory

 

 

 

I will, thanks  There could be some satisfaction derived from starting from scratch though.

 

Thinking of Bastian's question, I did it for control. So that less was happening without my knowledge.

 

There are other benefits. There would be C people who could read this, but not make sense of asm doing the same thing.

My reasons are selfish though, at least until they are in a free game