Determine EEPROM Writing Solution

[cspang1]

This is looking somewhat further down the proverbial development road.

I will be using a 1Mbit SPI EEPROM for static game resource storage (tile map, tile/sprite pixel palettes, tile/sprite color palettes), which would allow for ~50 full tile maps worth of canvas. This data will be loaded into a 1Mbit SPI SRAM at system instantiation.

The question is: what's a reasonable way to load 128K worth of data into the EEPROM, when the Propeller can only handle 32K at programming time. Should an in-circuit programmer be used? Should some shenanigans be implemented to load the data piecemeal via the Propeller? Should the data be sent serially to the Prop via the Prop Plug and stored one at a time?

I'm certain there is a best practice well accepted solution to this, but nothing is really popping out in my searches.

Ideally the solution would be one-click, as during game development the graphics resources would be constantly updated and tested, so if there's a solution that wouldn't require overwriting the boot EEPROM of the Propeller (so as not to overwrite the CPU code itself, necessitating a re-load) or even better wouldn't require the Prop at all, it would be ideal.

[cspang1]

Looks like Macca was investigating this exact same problem, but doesn't seem to really elaborate on his solution - plus it looks like he's using a C compiled solution.

[konimaru]

There is the Hydra-Asset-Manager (HAM). It needs some tweaking (the back end on the P1) but worked fine for me in the past. I believe up to 128MB was possible (in fact GUI allows for 512MB).

HAM_1_09.zip

[cspang1]

Outstanding - any elaboration for "tweaks on the back end"?

[konimaru]

The original backend used the TV driver + the Graphics object. I commented that out (there was some kind of progress bar). I believe you have the tweaked version already in that archive.

[cspang1]

Oh nice. I'm thinking though... the Propeller's boot EEPROM is I2C, but the ones I'm attempting to write to are SPI - so I'll certainly have to replace the I2C logic with SPI logic, as well as change the GPIO ports used.

[konimaru]

Ah, yes. I forgot. But it shouldn't be too much effort.

[cspang1]

Nah, especially with a great deal of SPI logic already available in the Propeller library.

[cspang1]

Will be satisfied w/ HAM.