Driver for 24AAXXX EEPPROM mounted on karri's carts

[42bs]

31 minutes ago, LX.NET said:

Who is the owner of newcc65? It would be good to also have that in a public place (as stated in the dev-containers thread as well). Is that yours, @42bs and would you be willing to host it in your GitHub repo?

I think there is no "owner". My understandig is, that @karri took the one from my page and fixed/improved it. I did not even try to compile it for years.

[Nop90]

I reopen this old thread to inform the other developers that Dragonbox decided to produce, and soon also to sell, carts with a 24AA256 chip onboard (32KBytes of memory).

 

These cart will be used for the phisical release of Starblader. I got the news only today and now I'm changing the code of the game to support this chip.

 

This is an opportunity to start developing games that saves more data, I think that a new RPG game could benefit from this, but also other project, e.g. @LX.NET  could be interested to these carts to save more custom levels of Circuit Dude.

 

 

Edited March 26 by Nop90

[Nop90]

There Is a problem with Dragonbox carts, they decided to use A18 for the SCL line instead of A1 or A0.

 

Weird decision because this requires a more complex handling of IODIR and IODAT to drive the I2C line.

 

Does someone want to help me to customize the driver to support this configuration?

[42bs]

14 minutes ago, Nop90 said:

There Is a problem with Dragonbox carts, they decided to use A18 for the SCL line instead of A1 or A0.

 

Weird decision because this requires a more complex handling of IODIR and IODAT to drive the I2C line.

Do they use 2k blocks then? You need to select block 128 for SCL high and any < 128 for SCL low.

Block select routine is in the ROM, so should be easy do do.

 

[Nop90]

9 minutes ago, 42bs said:

Do they use 2k blocks then? You need to select block 128 for SCL high and any < 128 for SCL low.

Block select routine is in the ROM, so should be easy do do.

 

This is slow, i would initialize the higher 8 bits of the high part of the cart address with 01010101 then at every clock strobe I would shift in a 0 and then a 1.

This should be a better driving of the SCL line.

 

Ps: for me A18 is the highest address line, since Epyx jumped a number in the official documents, it's called A19 sometimes

 

[Brek Martin]

Are you guys aware that if a new Lynx programmer comes by and follows what looks like a current tutorial to install CC65 and set up a dev environment,

then these EEPROM functions such as " (char)lynx_eeread_BV(i16);" are exactly as useful as calls to read the joystick or instantiate defining sprites?

 

Surely there's code out there just for this that could be added to a project?

 

It happens though, that my PicKitII programmer can read 93C46 directly.

A game that arrives on a cart here, that can't be loaded to flash cart, is a game that won't be played after a week.

I assume that some value is on EEPROM that has to be read by the software on the cart at run time, in order for the game to play,

and therefore must be read to properly dump the cart,

and it would be easiest to do this by overwriting the flash with a new program that dumps EEPROM content to the display.

It's a shame I disposed of my Lynx ROM addressing circuit. it could have performed half of the flash dump process.

 

Looking at this thread, the physical cart layout could interface with EEPROM, or address the highest ROM bit in a number of ways,

so that a gamedrive/elcheaposd won't run it anyway. I'll find that out even at the cost of the cart.

 

 

 

 

 

Edited May 14 by Brek Martin

[Nop90]

3 hours ago, Brek Martin said:

I assume that some value is on EEPROM that has to be read by the software on the cart at run time, in order for the game to play,

and therefore must be read to properly dump the cart,

This is possible, but like most of the other Lynx developer here on the forum I preferer to design my games to be able to run without the eeprom, and use it only for keeping highscores or game saves. My games usually cleans the eeprom content when running for the first time and I also use to add a key combo to reset the content of the eeprom, so there is no need to dump  the eeprom content if you don't want to backup game saves. 

 

3 hours ago, Brek Martin said:

Surely there's code out there just for this that could be added to a project?

There is a game template with everything you need. It has the the code to use the smaller 128 bytes eeprom, but modifying it to use the 64KB eeprom should be easy. 

 

3 hours ago, Brek Martin said:

Looking at this thread, the physical cart layout could interface with EEPROM, or address the highest ROM bit in a number of ways,

so that a gamedrive/elcheaposd won't run it anyway.

Elchapo cart doesn't handle any type of eeprom, but the RetroHQ Lynx Gamedrive supports the 128 Bytes epprom emulation and could support this larger type with a firmware update. Since no one ever used this eeprom format yet, there is no interest on updating the firmware, but things could change for the end of the year.

[Brek Martin]

If you're talking about game template handed around for codejam? Then I'd have it.

 

I have ElCheapoSD, and it has supported game saves the whole time I've owned it.

Indeed, there's a save folder, and some homebrew has created entries in there just from booting it.

Are you saying support is still lacking? Or not aware of this update? because I don't think it did support saves originally.

 

It's true I'm only assuming a game sold now does this. It's just how I thought when I wondered how I'd try to protect a game I was selling.

Setting a unique number that the game looks for on EEPROM would also identify who leaked it if it was leaked.

 

[42bs]

2 minutes ago, Brek Martin said:

Setting a unique number that the game looks for on EEPROM would also identify who leaked it if it was leaked.

You rather want this:

 

https://www.microchip.com/en-us/product/AT24CS01

 

[Nop90]

6 minutes ago, Brek Martin said:

It's true I'm only assuming a game sold now does this. It's just how I thought when I wondered how I'd try to protect a game I was selling.

Setting a unique number that the game looks for on EEPROM would also identify who leaked it if it was leaked.

 

You can't effectively protext a Lynx game, it's so easy to decompile the code and patch it 😅

[42bs]

13 minutes ago, Nop90 said:

 

You can't effectively protext a Lynx game, it's so easy to decompile the code and patch it 😅

Unless you invest some money by adding a chip on th card which runs some code. Like a TPM chip. But that'll make the game so expensive no one would buy it (unless it is the _mega_ killer supa dupa game).

[Brek Martin]

 

.

Edited May 14 by Brek Martin

[Brek Martin]

13 hours ago, 42bs said:

Unless you invest some money by adding a chip on th card which runs some code. Like a TPM chip. But that'll make the game so expensive no one would buy it (unless it is the _mega_ killer supa dupa game).

 

 

 

Edited May 14 by Brek Martin

[42bs]

4 minutes ago, Brek Martin said:

42bs, It's not me who wants to protect the game  More to unprotect one, assuming it somehow is.

The author has every right to try to, just as I also have every right to try to copy it.

Every right to copy it? Well, damn, no!

[42bs]

7 hours ago, Brek Martin said:

A game that arrives on a cart here, that can't be loaded to flash cart, is a game that won't be played after a week.

So you want to copy games? Ok, one reason more not to write anymore games for the Lynx if this habit starts to spread.

[Brek Martin]

 

.

Edited May 14 by Brek Martin

[42bs]

3 minutes ago, Brek Martin said:

Actually for my replay above, you could simply read the data on the side of the controller that the Lynx does

 

yes, copy, backup. In Australia there's no software, video, data, or music product that we can't copy.

 

Backup ? *lol* Of a Lynx card with an Flash? *rotfl* That argument was maybe true in the 90s with 3.5" disks.

[Brek Martin]

I didn't make any argument. I know my rights.

I stated above that a game on a cart (rather than on elcheapo) is a game I don't play after a week,

and I'd choose to move it to that (even if reading the EEPROM is destructive to the cart because I have to remove it).

 

Anything else I do that's within my rights, that you have some misplaced, and manufactured moral problem with,

you can choose not to answer me, because any problem with it must involve imaginings and assumptions about what I do with resulting files,

and you'll get no more of me validating my intentions for you.

 

 

[Nop90]

24 minutes ago, Brek Martin said:

Nop90, I only just realise you are the author of IM, the twitch stream I watched.

But I still don't know if that's free or a game you're selling, or how to get it, or if it's finished.

The particular game doesn't tickle my nostalgia bone, and wouldn't have the appeal to me it would for others,

but I was watching wanting to see what a developed homebrew looked like.

 

If this is a free game then your talk of what you do with EEPROM isn't really relevant.

If it's a game for sale on cart, I'd anticipate at least the effort that I mentioned,

even if it only puts off those who aren't deeply interested.

 

 Impossible mission port is completed, but I could add some things in the future. It's not released at the moment for copyright reasons.

 

I would like to sell a small batch of carts for collectors, and with no profit for me, I will only cover the cost of the production and of the License if I have to pay it. 

 

Probably I'm going to release the digital rom fo free in the future (one or two years after the phisical release). 

 

I spent 5 month coding Impossible mission because in the beginning I though it was an hard task and no one did it before. Now I know it can be done and doing it I learned something new on the Lynx.  That's enough for me.

 

33 minutes ago, Brek Martin said:

42bs, It's not me who wants to protect the game  More to unprotect one, assuming it somehow is.

The author has every right to try to, just as I also have every right to try to copy it.

Anyone can do whatever he wants, what one does defines who (or what) he/she is. This is a golden rule.

 

It's not a matter of rights, rights don't exist. They are an human invention needed as the base of the human society, as soon as the society is not stable the rights disapper. This is what one should think before saying or doing something.

 

Apart from this, what is the fun of copying games of a 35 yo system. Almost every programmer in this community can do it. Better trying to do with HW or SW something the no one did before. 

 

 

 

[Brek Martin]

At the end of the day, it occurs to me that any offence taken about copying a game, or anything else for that matter,

must have built in assumptions about doing something malicious with what was read, or there couldn't be a problem.

Just being a member of this forum leads me to believe nobody is stupid enough to take offence to copying something in and of itself.

 

So that sort of talk has built in accusation as far as I'm concerned, and I don't care whom it is that thinks they require explanation as to why.

I can also post silly emoticons in response to what I find a silly post too.

 

If you were selling this game on a cart, and I wanted to buy it, I'd openly state my intention to copy it to ElCheapo too,

and I wouldn't expect a childish reaction to such a statement without my mention of explicit intention to do something untoward with that data.

 

I have dumped a game with hardware never done before. It isn't interesting. I actually just want a game to run from ElCheapoSD.

 

 

Edited May 14 by Brek Martin

[Nop90]

8 minutes ago, Brek Martin said:

If you were selling this game on a cart, and I wanted to buy it, I'd openly state my intention to copy it to ElCheapo too,

I do the same sometimes, I think that not sharing the dumpèd roms should be enough to not offend anyone 😅

[Igor]

19 hours ago, Nop90 said:

Elchapo cart doesn't handle any type of eeprom, but the RetroHQ Lynx Gamedrive supports the 128 Bytes epprom emulation and could support this larger type with a firmware update. Since no one ever used this eeprom format yet, there is no interest on updating the firmware, but things could change for the end of the year.

This is NOT TRUE, ElCheapoSD does and always has supported 128b 93C46 EEPROMs, because it physically has one on the PCB. It also supports saves of EEPROM content to SAV files, and restore as well.

[Nop90]

5 hours ago, Igor said:

This is NOT TRUE, ElCheapoSD does and always has supported 128b 93C46 EEPROMs, because it physically has one on the PCB. It also supports saves of EEPROM content to SAV files, and restore as well.

My fault. Sorry.

[Igor]

Just now, Nop90 said:

My fault. Sorry.

All good, BennVenn has also been looking at whether it would be possible to shut off the onboard physical EEPROM but looks like that's not doable in the current design of the cart