Atarivox EEPROM question/comments

[supercat]

To what extent are people using what features of the Atarivox EEPROM, and what has been decided about 7800 vs. 2600?

 

What I'd like to see, if it wouldn't cause problems with anything already written, would be to implement the following simple rules for the second 16K:

 

-1- Every program that uses data in the second 16K of EEPROM must have an entry (most likely at least two) in the first 8K "fixed allocation" area.

 

-2- The first byte of any 64-byte page in that second 16K area must correspond to the address (/64) of the program's entry in the fixed-allocation area.

 

-3- The page pointed to by that byte must contain, from address 52 to 63, the name of the generating application in ASCII (codes 32-127; pad with zeros).

 

-4- All of the other data in the second 16K area would be freely usable by applications in whatever manner they see fit. If they wish to allow multiple game saves and/or game saves that are larger than 63 bytes each, they may use whatever method they wish to keep track of their own data (filenames, game-save numbers, etc.). Applications should not particularly expect to find consecutive free blocks available.

 

-5- Applications are not allowed to relocate or disturb other applications' data.

 

-6- Any application which can store store 1K or more in the 16K general-allocation area must provide a facility to delete it.

 

-7- Any application which stores anything in the Jetspeak EEPROM should store $FF in address $0FFF before doing so, and their own ID (address of their fixed-allocation area, /64) after doing so; applications which see their own ID there on powerup may assume their desired data is already in in the Jetspeak EEPROM.

 

Do those rules seem reasonable? Providing the name of the application in the fixed-allocation area would mean that applications could show what other applications were using data (and how much). My expectation would be that a 'file manager' utility would be written that could easily be included in carts that use the 16K extended area; unless such a cart is either below 4K or nearly 32K, such a feature could be included for no extra manufacturing cost.

[Richard H.]

This is Alex Herbert's proposal, but as no program currently uses this area, it's not yet 'set in stone' -

 

64-byte pages are paired to form 128-byte Blocks.

Each block starts with an 8 character ASCII filename (7-bit character codes) and the remaining 120 bytes are free for data.

Bit 7 of the first character is used to determine if the block is allocated or available.  0 indicates the block is in use, a 1 means it is free.

 

Even implementing something as simple as this gets quite fiddly on the 2600.  The time taken to search for a file/free block is variable and may take several TV frames to complete and care must be taken to ensure that VSYNC still happens at the right time.  Also, any software that uses the File Area should provide the user with some way to delete files as well as create them.  This will possibly involve text routines, a character set, etc., all adding further bulk to the program.

 

I'm no coder, but surely this wouldn't be such a problem on the 7800 ?

[supercat]

This is Alex Herbert's proposal, but as no program currently uses this area, it's not yet 'set in stone' -

 

I've seen that proposal. My concern is that since it says nothing about file naming, there's nothing to prevent conflicts between different applications that happen to choose the same name.

 

My thinking is that every application is going to have a unique identifier (the address of the 'lower' EEPROM area it uses), so if the first byte of each block (whatever size a block is) indicates which application owns it then there's no risk of applications stomping over each others' data (assuming applications lave alone any blocks labeled with anything other than 00, FF, or their own ID).

 

I'm no coder, but surely this wouldn't be such a problem on the 7800 ?

952883[/snapback]

 

Well, the 7800 could probably handle things faster, but searching would still take some time. I did have some ideas for some refinements to the above proposal to help minimize fragmentation and such, but I think it's probably best to just let applications do what they want subject to the constraint that they label their own data as their own.

[Richard H.]

Perhaps they'd be a better response on the Stella list, as this is where the scheme for the lower 16K was worked out.