[stella] EEPROM support for Z26

[stella at casperkitty.com]

>>
Cool. When you've cleaned up things a bit, it would be nice, if I
could have a look at it to see how it works.
<<

Naturally.  There are three global variables jpee_mclk, jpee_mdat, and
jpee_sdat to indicate the state of the master clock, and master and slave
clock data (the state of the data pin will be the AND of jpee_mdat and
jpee_sdat).  There are three routines jpee_data_start (falling edge of data
with clock high), jpee_data_stop (rising edge of data with clock low), and
jpee_clock_fall (falling edge of clock).

There are macros jpee_clock(val) and jpee_data(val) which it is expected
programs will use; these will call the appropriate routines and update the
variables appropriately.  Note that calling jpee_clock_fall when the clock
is already low will mess things up; it's expected that the calling program
will avoid that (the jpee_clock() macro takes care of that)

There's also a jp_init() routine that initializes the state of the EEPROM
and initializes some variables that can be used to control EEPROM behavior,
shown with defaults:

jpee_sizemask (32767) -- Size of eeprom, minus one
jpee_pagemask (63) -- Size of an EEPROM page, minus one
jpee_smallmode (0) -- Indicates whether EEPROM includes part of address
within first byte (as on 24LC16).

There are two routines my EEPROM code expects to have defined elsewhere:

int jpee_logproc(char const *st) -- Should output string to a log.  Return
value is ignored.

int jpee_timecheck(int mode) -- Is invoked with an argument of 1 when an
EEPROM write is initiated; is invoked with a value of zero every time an
I2C_START is attempted.  If invokved with a value of zero, it should
indicate whether the EEPROM write type (typically 5ms) has elapsed since
the last call to jpee_timecheck.

>>
Yes there is: Star Raiders. The game uses a joystick and a keypad.
For reading the keypad you need to enable the row of keys you want to
access by writing to SWCHA. For some reason Star Raiders sets all
bits in SWACNT to output and never resets them back to input.
<<

Ah.  I'd thought the reason for restricting SWCHA writes to output bits
only was that DDR_A wasn't being masked out on reads.  But from what you
describe that's not the reason.  I wonder what is?

>>
That might break the handlers for keypad, CompuMate and MindLink,
since IOPort_A might not be in a proper state when the write to
DDR_A happens. It would be better, if you could write your own
ControlSWACNTWrite() function and call that instead.
<<

Okay, that sounds like a good idea.

>>
Loading the binary is handled in cli.c. The filename including the
.bin extension and the path (if one was specified) is stored in a
variable called FileName[]. Once the ROM is loaded this variable
isn't used until a new binary is loaded, so you could replace the
extension with .eep or something. Not everyone calles their binaries
.bin though. And for AtariVox support it might be better to have
only one common EEPROM image.
<<

For some applications, having a shared EEPROM image is fine.  For others
(especially games using built-in EEPROMs such as 4A50 or the simple design
I'm doing for Albert) it would be bad.  For now maybe I'll just require
people to specify a name on the command line.

>>
BTW, if you have questions about the z26 code, it might be better
to email me directly instead of asking here on the Stella list.
<<

I figured others on the list might be interested, especially since there
will probably be a desire to incorporate this sort of functionality into
Stella.

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .