My 4A50: opinions wanted (EEPROM anyone?)

[supercat]

Well, I've reworked a few things and ended up with a whopping four macrocells left. Since there's no reason not to use everything I've got, the question becomes what to do with them.

 

Options:

 

-1- Add a software-controlled LED at a cost of one macrocell, or two for a cost of two.

 

-2- Extend the range of flash accessible by the upper and/or middle banks (one macrocell each)

 

-3- Add logic so the BIT instruction will never trigger an accidental bankswitch (two or three macrocells depending upon whether I handle the case of "$2C $Fx $n0 where x>= 4 and n is an even number; that case is far less likely than $2C $xx $nn where nn is $64..$6F or $7F)

 

-4- Make an accesses to $1Fxx that immediately follows an access to $1Exx use the upper memory bank instead of the fixed area (probably two macrocells, if doable).

 

-5- Eliminate some resistors (up to three, one per macrocell)

 

My inclination would be to start with #4, but I wonder which things programmers would most like to see? The current document at http://www.casperkitty.com/stella/cartfmt.htm is a bit different from some earlier versions--the new zero-page bankswitching hotspots should be really neat. I'd appreciate any feedback from any 2600 programmers who've looked at the spec as to which of the these things they'd most like to see.

Edited October 6, 2005 by supercat

[+batari]

Well, I've reworked a few things and ended up with a whopping four macrocells left.  Since there's no reason not to use everything I've got, the question becomes what to do with them.

 

Options:

 

-1- Add a software-controlled LED at a cost of one macrocell, or two for a cost of two.

 

-2- Extend the range of flash accessible by the upper and/or middle banks (one macrocell each)

 

-3- Add logic so the BIT instruction will never trigger an accidental bankswitch (two or three macrocells depending upon whether I handle the case of "$2C $Fx $n0 where x>= 4 and n is an even number; that case is far less likely than $2C $xx $nn where nn is $64..$6F or $7F)

 

-4- Make an accesses to $1Fxx that immediately follows an access to $1Exx use the upper memory bank instead of the fixed area (probably two macrocells, if doable).

 

-5- Eliminate some resistors (up to three, one per macrocell)

 

My inclination would be to start with #4, but I wonder which things programmers would most like to see?  The current document at http://www.casperkitty.com/stella/cartfmt.htm is a bit different from some earlier versions--the new zero-page bankswitching hotspots should be really neat.  I'd appreciate any feedback from any 2600 programmers who've looked at the spec as to which of the these things they'd most like to see.

940848[/snapback]

#2 sounds good to me, and #1 would be useful for debugging. But with #3, it seems to be that the only utility for BIT Absolute you are referring to would be to skip a two-byte instruction. it seems extremely unlikely to me that you are ever going to need to skip a two-byte instruction with $F4-$FF as the opcode. There's actually only 4 possible candidates:

 

F4: NOP* Zeropage,x

F5: SBC Zeropage,x

F6: INC Zeropage,x

F7: ISB* Zeropage,x

 

all of which are seldom-used, especially for skipping.

[supercat]

-1- Add a software-controlled LED at a cost of one macrocell, or two for a cost of two.

 

-3- Add logic so the BIT instruction will never trigger an accidental bankswitch (two or three macrocells depending upon whether I handle the case of "$2C $Fx $n0 where x>= 4 and n is an even number; that case is far less likely than $2C $xx $nn where nn is $64..$6F or $7F)

 

940848[/snapback]

#2 sounds good to me, and #1 would be useful for debugging. But with #3, it seems to be that the only utility for BIT Absolute you are referring to would be to skip a two-byte instruction. it seems extremely unlikely to me that you are ever going to need to skip a two-byte instruction with $F4-$FF as the opcode. There's actually only 4 possible candidates:

 

F4: NOP* Zeropage,x

F5: SBC Zeropage,x

F6: INC Zeropage,x

F7: ISB* Zeropage,x

 

all of which are seldom-used, especially for skipping.

940858[/snapback]

As I noted, the "$2C $Fx $n0" case seemed far less likely than the other one (which could be hit by trying to skip any two-byte instruction whose operand was $64-$7F).

 

As for the LED, I wasn't so much thinking of it for debugging as for use with nifty carts in clear plastic cases. Your space ship gets destroyed and your cart starts flashing.

[+batari]

As I noted, the "$2C $Fx $n0" case seemed far less likely than the other one (which could be hit by trying to skip any two-byte instruction whose operand was $64-$7F).

 

As for the LED, I wasn't so much thinking of it for debugging as for use with nifty carts in clear plastic cases.  Your space ship gets destroyed and your cart starts flashing.

940864[/snapback]

Actually, I think that an operand of $64-$7F is unlikely on a 2600. I mean, this area is just a mirror of TIA regs, and except for 3F bankswitching games, they are basically never used. There's no real reason to do zero-page loads or stores there, and exactly zero utility for indirect indexed addressing (or indexed indirect.) There may be a very small chance that someone may use $64-$7F for zeropage,x but I'd still consider this uncommon enough to disregard. The only discrenible possibility is an immediate load/compare/logical operation, and one could just be mindful of the limitation.

 

As for the LED, I'd use it for debugging, personally. Especially when I'm trying to learn a new bankswitching scheme, programs might be a little hard to follow. At the very least, in the case of a crash, we could put in an LED blink routine as a test to see if parts of code are actually running.

Edited October 1, 2005 by batari

[supercat]

Actually, I think that an operand of $64-$7F is unlikely on a 2600.

940867[/snapback]

 

That's why I chose that address range, but immediate mode operands could use such values.

[+batari]

Actually, I think that an operand of $64-$7F is unlikely on a 2600.

940867[/snapback]

 

That's why I chose that address range, but immediate mode operands could use such values.

940880[/snapback]

Immediates could use that range of values, yes.

 

I guess the point I want to make here is that BIT Abs. to skip instructions is not a novice technique. Therefore programmers who understand how to use Bit Abs. to skip will also understand to avoid skipping instrctions with a certain range of operands.

 

Basically, I see this "feature" as macrocells wasted - it serves no function other than to protect us from ourselves. I'd rather see the macrocells used in other ways.

[supercat]

Basically, I see this "feature" as macrocells wasted - it serves no function other than to protect us from ourselves.  I'd rather see the macrocells used in other ways.

940894[/snapback]

 

I think the design decision to use one macrocell to restrict bank-switching hotspots to addresses $6xxx or $7xxx was a good one. But I would agree that choice of address ranges does enough to prevent stray accesses that further protection probably isn't needed.

 

The one bit of code I'd worry about would be something like:

show_shape1:
 lda #<shape1
 byte $2C
show_shape2:
 lda #<shape2
 ...

Here, code changes that cause the address of shape2 to move may break things for no obvious reason. A programmer may be mindful of the dangers of BIT when writing this part of code, but changes elsewhere may cause this code to go from being safe to being dangerous. An unlikely scenario, but not out of the question.

 

Still, what should I do with those macrocells? Adding the address MSB to flash accesses in the lower and middle banks would seem a possibility, but it would add a couple of product terms to an already-overburdened WEA15 pin and I might need to waste a macrocell on buffering to make it work.

 

Also, I should ask another question: as a programmer, would you prefer to have the bank-switching objects to select consecutive blocks of flash into $1000-$17FF be at $6800, $6801, $6802, etc. (as they are now) or at $6800, $6808, $6810, etc.? Arranging them spaced out by 8's would make it easier to convert page addresses to banking addresses, but could be confusing. I'm thinking I should space them out so as to allow some degree of 'pointer arithmetic' to be done with them. What do you think?

 

A similar question exists with zero-page hotspots. Being able to convert page numbers into block numbers without shifts is nice, but being able to increment block numbers would also be nice. Any thoughts?

 

Do you agree with my arrangement of RAM hotspots, or is there anything you'd like to see differently? Do you think it would be useful to have the registers shadowed in the $74-$7F range [so one could store to them without overwriting any of the hotspot RAM]?

Edited October 1, 2005 by supercat

[+batari]

Basically, I see this "feature" as macrocells wasted - it serves no function other than to protect us from ourselves.  I'd rather see the macrocells used in other ways.

940894[/snapback]

Still, what should I do with those macrocells? Adding the address MSB to flash accesses in the lower and middle banks would seem a possibility, but it would add a couple of product terms to an already-overburdened WEA15 pin and I might need to waste a macrocell on buffering to make it work.

Maybe a good solution would be to use the 4 remaining macrocells as memory-mapped user I/O. We could put LED's in there if we want, but if not, we could use the I/O to drive devices of our own choosing. Who knows, maybe we could operate robots, turn on/off lights, serial EEPROMS, put "rumble packs" in the joysticks... ideas anyone?

 

Other than that, I think that extending the functionality of the cart (as with #2) is good. I guess I don't really see the utility of #4 - I mean, there are only 256 bytes that are fixed, which isn't a big deal. It's not like the M-network scheme where a whole 2k is fixed.

Also, I should ask another question: as a programmer, would you prefer to have the bank-switching objects to select consecutive blocks of flash into $1000-$17FF be at $6800, $6801, $6802, etc. (as they are now) or at $6800, $6808, $6810, etc.?  Arranging them spaced out by 8's would make it easier to convert page addresses to banking addresses, but could be confusing.  I'm thinking I should space them out so as to allow some degree of 'pointer arithmetic' to be done with them.  What do you think?

I'd prefer $6800,$6801... I don't think it's too hard to do a little pointer math, and keeping things in order will allow for indexing banks.

A similar question exists with zero-page hotspots.  Being able to convert page numbers into block numbers without shifts is nice, but being able to increment block numbers would also be nice.  Any thoughts?

I don't think shifts are a big deal. The programmers who would be using these boards also probably won't mind shifting bits around here and there, but I can't speak for everyone.

Do you agree with my arrangement of RAM hotspots, or is there anything you'd like to see differently?  Do you think it would be useful to have the registers shadowed in the $74-$7F range [so one could store to them without overwriting any of the hotspot RAM]?

940899[/snapback]

Thinking about this, it would be a good idea to allow writing to $74-$7F because then you could use the stack with SP=$F4-$FF and still allow bankswitching at the same time. You'd have to check if A8=1, and if it is, disable the hotspots since the processor is reading/writing to the stack. But if A8=0, you know that we are reading/writing to/from a hotspot.

 

The only exception is if we wish to increment banks, we would know that we need to forgo the use of the stack here.

[supercat]

(see also my edit to previous post)

Maybe a good solution would be to use the 4 remaining macrocells as memory-mapped user I/O.  We could put LED's in there if we want, but if not, we could use the I/O to drive devices of our own choosing.  Who knows, maybe we could operate robots, turn on/off lights, serial EEPROMS, put "rumble packs" in the joysticks... ideas anyone?

 

I only have one spare pin. The other macrocells are 'buried' behind pins I'm using for input. So I could drive one or two leds (if I don't have both LEDs on at once) but I don't really have I/O beyond that.

 

Other than that, I think that extending the functionality of the cart (as with #2) is good.  I guess I don't really see the utility of #4 - I mean, there are only 256 bytes that are fixed, which isn't a big deal.  It's not like the M-network scheme where a whole 2k is fixed.

 

The idea with #4 is that it allows 'circular' addressing. For my current 4A50 demo program, it would let me reduce the code space required for some of my tables. The program, in essense, runs the following loop:

 for(i=numpts; --i; )
   plotpixel(lookuptable[(points[i]+phi1) & 255],lookuptable[(points[i]+phi2) & 255]);

Presently, I have two copies of each 256-byte table, the second of which is identical to the first. The addition between the points[] value and phi* is done 'for free' using an indexed load operation. If I added the 'wrap' function to the $1E00 page, then I could do such modulo-256 lookups on that page, rather than having to put the data into another bank and have two copies of it.

I'd prefer $6800,$6801... I don't think it's too hard to do a little pointer math, and keeping things in order will allow for indexing banks.

 

Perhaps, and that's how things are now, but I'm really favoring the other approach. From a code-legibility standpoint, selecting addresses $3000-$37FF to appear in the $1000-$17FF region using BANKLOWRAM+$30 doesn't seem any less sensible than BANKLOWRAM+6 [since it's bank 6]. More significantly, if $FF holds a pointer to the first page in a block of RAM and I want to select that block into a the bottom memory bank, I could use:

 LDX $FF  ; Use $1FF if it's important not to switch banks in $1E00 range
 LDA $804,X ; The +4 is because it's RAM instead of flash

Such techniques only work if the pages are spaced identically in all the banks.

 

I don't think shifts are a big deal.  The programmers who would be using these boards also probably won't mind shifting bits around here and there, but I can't speak for everyone.

 

Sure, but the shifting would add at least eight cycles to the cost of doing certain bank switches and kill a register as well.

 

Thinking about this, it would be a good idea to allow writing to $74-$7F because then you could use the stack with SP=$F4-$FF and still allow bankswitching at the same time.  You'd have to check if A8=1, and if it is, disable the hotspots since the processor is reading/writing to the stack.  But if A8=0, you know that we are reading/writing to/from a hotspot.

 

The stack needs to be parked below any RAM hotspots you actually use. The only benefit to allowing a mirror at $74-$7F would be that it would allow one to switch to a bank held in a register without trashing any of the existing presets (something like the way you can tune a car radio without trashing a preset there).

 

There is, however, another way I could allow some $7x addresses. It may cost a extra macrocell, but what I might do would be to make $74-$77 and $7C-$7F mirror the $Fx counterparts, but make $78-$7B derive the bank selection and RAM/ROM selection from the two LSB's of the address rather than the data (the three LSB's of the data would be ignored). I may do that, expecially if I can do so without losing a macrocell.

 

The only exception is if we wish to increment banks, we would know that we need to forgo the use of the stack here.

 

The presets are useful in many more circumstances than just incrementing banks.

[+batari]

The one bit of code I'd worry about would be something like:

show_shape1:
 lda #<shape1
 byte $2C
show_shape2:
 lda #<shape2
 ...

Here, code changes that cause the address of shape2 to move may break things for no obvious reason.  A programmer may be mindful of the dangers of BIT when writing this part of code, but changes elsewhere may cause this code to go from being safe to being dangerous.  An unlikely scenario, but not out of the question.

940899[/snapback]

In this case, I'd just whip out a simple program to seach for byte patterns 2C xx nn where nn is $68-$7F or whatever it was. Would be a piece of cake to write, and would just issue a warning if potentially bad bytes were found.

 

For that matter, maybe a special version of DASM could do the same , then relay back more useful information about this?

 

I am still of the opinion that a the hardware can be worked around by good programming or good software tools that warn us.

[+batari]

The idea with #4 is that it allows 'circular' addressing.  For my current 4A50 demo program, it would let me reduce the code space required for some of my tables.  The program, in essense, runs the following loop:

 for(i=numpts; --i; )
   plotpixel(lookuptable[(points[i]+phi1) & 255],lookuptable[(points[i]+phi2) & 255]);

Presently, I have two copies of each 256-byte table, the second of which is identical to the first.  The addition between the points[] value and phi* is done 'for free' using an indexed load operation.  If I added the 'wrap' function to the $1E00 page, then I could do such modulo-256 lookups on that page, rather than having to put the data into another bank and have two copies of it.

I see. Personally, I haven't found any reason to do modulo-256 lookups, but maybe there's a utility I'm not seeing. What did you have in mind, specifically?

 

Perhaps, and that's how things are now, but I'm really favoring the other approach.  From a code-legibility standpoint, selecting addresses $3000-$37FF to appear in the $1000-$17FF region using BANKLOWRAM+$30 doesn't seem any less sensible than BANKLOWRAM+6 [since it's bank 6].  More significantly, if $FF holds a pointer to the first page in a block of RAM and I want to select that block into a the bottom memory bank, I could use:

 LDX $FF ; Use $1FF if it's important not to switch banks in $1E00 range
 LDA $804,X; The +4 is because it's RAM instead of flash

Such techniques only work if the pages are spaced identically in all the banks.

So you're talking about a mapping of the physical address in the flash itself to a bank by selecting the high byte of the address instead of the bank number. But I'm not sure if the physical address in flash really matters. Or at least I don't think of bankswitching that way. But if it makes it easier to design the logic this way, it's not a big deal.

I don't think shifts are a big deal.  The programmers who would be using these boards also probably won't mind shifting bits around here and there, but I can't speak for everyone.

 

Sure, but the shifting would add at least eight cycles to the cost of doing certain bank switches and kill a register as well.

Eight cycles and a register only really matter in a kernel. Were you thinking that people would switch banks in the middle of the kernel?

[supercat]

I see.  Personally, I haven't found any reason to do modulo-256 lookups, but maybe there's a utility I'm not seeing.  What did you have in mind, specifically?

 

Well, I don't know if you've seen my E7-spin demo (I'm pretty sure I posted it somewhere around here) but that uses modulo-256 lookups. Thouh as noted I simply used two copies of the data tables to allow a clean 'wrap'.

 

Eight cycles and a register only really matter in a kernel.  Were you thinking that people would switch banks in the middle of the kernel?

940920[/snapback]

 

Yes, actually. One of the useful things about having lots of RAM is being able to show lots of stuff in a kernel. But bankswitching mid-frame may become necessary. Fortunately, it need not be expensive. Indeed, toggling bit A11 or A12 of either of the lower two bank addresses can be done at a cost of only one cycle (replace a zero-page write to a TIA address with an absolute write of $7nq0+that TIA address [n==4 for lower bank or 5 for upper bank; q=0 to toggle bit A11 and 4 to toggle bit A12].

[+batari]

Well, I don't know if you've seen my E7-spin demo (I'm pretty sure I posted it somewhere around here) but that uses modulo-256 lookups.  Thouh as noted I simply used two copies of the data tables to allow a clean 'wrap'.

I saw it and it was really cool.

 

Though I'd try to get more opinions on this one to see if anyone else would use it.

 

I haven't fully analyzed the 4A50 spec yet, but I did spot an error. You indicated that the last two bytes of a cart should be 4A50 because that's the NMI vector. Actually, the IRQ vector lives there, and the NMI vector lives at FFFA-FFFB.

[supercat]

I haven't fully analyzed the 4A50 spec yet, but I did spot an error.  You indicated that the last two bytes of a cart should be 4A50 because that's the NMI vector.  Actually, the IRQ vector lives there, and the NMI vector lives at FFFA-FFFB.

940927[/snapback]

 

Oops. And I don't want to make the IRQ vector useless. So I guess I'd better fix that. I'm also thinking I should move a few of the other hotspots around so that the "Stella Helper" functions (toggle a banking bit while performing a Stella access for a cost of only one added cycle) could also be used when accessing RIOT RAM. Still, are you thinking this looks pretty cool?

[supercat]

I haven't fully analyzed the 4A50 spec yet, but I did spot an error.

940927[/snapback]

 

Can you look over the new revised edition? I put in the LEDs and still have a little room.

[+batari]

I haven't fully analyzed the 4A50 spec yet, but I did spot an error.

940927[/snapback]

 

Can you look over the new revised edition? I put in the LEDs and still have a little room.

941225[/snapback]

I'll take a look tonight. I usually have to read through specs a few times before I understand them, so if I don't understand them tonight, I'll look tomorrow night too.

 

One thought did occur to me, though. Would it be possible to use any remaining space to implement some Pitfall-II-like features, such as circular queues?

[supercat]

One thought did occur to me, though.  Would it be possible to use any remaining space to implement some Pitfall-II-like features, such as circular queues?

941238[/snapback]

 

Heh--nice theory, but that would definitely require a bigger chip than what I'm using. My board allows the CPLD to control A7-A15 of the flash/SRAM. A0-A6 of those devices is hardwared to A0-A6 of the 2600. Even if I had the wiring available, circular queues would require a minimum of eight macrocells each. It just isn't practical.

 

If I wanted to do something like that, it would be possible to add a PIC 16F877 to the board and let that do some really neat stuff. That would add about $7 to the cost of the thing, though, and would go far outside the real scope of the project which is to (1) design the cheapest board that can do Superchip or better, and (2) do as much as possible with the board without significantly increasing the cost.

 

SRAMs smaller than 32K or flash devices smaller than 64K seem hard to find (and will probably get harder), so there's no reason to go with anything smaller than those. The Xilinx XC9536XL is as cheap a CPLD as one can get and still be able to generate the timings needed for a Superchip-style RAM.

[mos6507]

One thought did occur to me, though.  Would it be possible to use any remaining space to implement some Pitfall-II-like features, such as circular queues?

941238[/snapback]

 

You should be able to get that pretty soon from a different project in the oven.

 

No promises yet, though.

[potatohead]

One thought did occur to me, though.  Would it be possible to use any remaining space to implement some Pitfall-II-like features, such as circular queues?

941238[/snapback]

 

You should be able to get that pretty soon from a different project in the oven.

 

No promises yet, though.

941654[/snapback]

 

All this hardware talk is pretty interesting! Looks like good times ahead.

[+batari]

I'm still digesting the spec...

 

Anyway, I was just curious as to what HDL you are using?

[supercat]

Anyway, I was just curious as to what HDL you are using?

942158[/snapback]

 

The thing's currently done in ABEL. The CC2 version (not working yet) is being done in VHDL. I'm currently laying out rev 2 of the board. Hopefully that will be off to sparkfun in a few days and I'll get those back in a few weeks.

 

I'm including spots for a couple of throughhole LEDs. Would right near the center-post be a good spot, or where would be the best place to put them? Any ideas?

[+Andrew Davie]

Eight cycles and a register only really matter in a kernel.  Were you thinking that people would switch banks in the middle of the kernel?

940920[/snapback]

 

Yes, actually. One of the useful things about having lots of RAM is being able to show lots of stuff in a kernel. But bankswitching mid-frame may become necessary. Fortunately, it need not be expensive. Indeed, toggling bit A11 or A12 of either of the lower two bank addresses can be done at a cost of only one cycle (replace a zero-page write to a TIA address with an absolute write of $7nq0+that TIA address [n==4 for lower bank or 5 for upper bank; q=0 to toggle bit A11 and 4 to toggle bit A12].

940925[/snapback]

 

 

BoulderDash uses in-kernel bankswitching extensively. It has just 3 cycles available for the bankswitch, and uses a lot of RAM-based self-modifying code. Each 'character line' (18 scanlines) lives in a single bank, along with the code that draws that character line. Bankswitching to the next line occurrs inside the code living in the switchable bank! That is, the code switches itself out, but the bank it switches in just happens to have appropriate code where the next instruction executes, in that just-switched-in bank. I use this method to remove the need for line-comparision counters in the kernel; the last bank contains a 'rts' as the next instruction, so it 'automatically' terminates the draw at the end of the screen without a line counter comparison/branch.

[supercat]

BoulderDash uses in-kernel bankswitching extensively.  It has just 3 cycles available for the bankswitch, and uses a lot of RAM-based self-modifying code.  Each 'character line' (18 scanlines) lives in a single bank, along with the code that draws that character line.  Bankswitching to the next line occurrs inside the code living in the switchable bank!  That is, the code switches itself out, but the bank it switches in just happens to have appropriate code where the next instruction executes, in that just-switched-in bank.  I use this method to remove the need for line-comparision counters in the kernel;  the last bank contains a 'rts' as the next instruction, so it 'automatically' terminates the draw at the end of the screen without a line counter comparison/branch.

 

If you like, you can do a zero-page store to switch banks. If I recall the bit of the BD kernel you showed me, it actually takes five cycles to switch banks (since X has to be given the correct value before the store); an absolute read can do a bank switch in four cycles without having to load anything else. A zero-page read to one of four special locations can switch the bottom bankable area to any one of four freely-selectable pages. These, combined with the single-cycle-cost bank toggling option, should take care of all the bank switching needs even if you couldn't afford to load the register before storing it.

[supercat]

It seems I can't have two LEDs and extend the middle and lower bank addressing by a bit; the write-enable logic gets too complicated. So would people rather have two LEDs with banking as documented, or one LED with the extra bit (so the middle and lower banks could access all of flash instead of just half each)?

 

Another possibility, if I go with a single LED, would be to add a serial EEPROM. It would be impossible to access it without the LED (if present) flashing, and there would be some other weird restrictions as well. During an EEPROM transaction (between the I2C start and stop conditions) code would not be allowed to access RAM from $4000-$7FFF nor flash from $4000-$7FFF or $C000-$FFFF except for reads to addresses $FFFE and $FFFF (which would act as I2C hotspots).

 

Would anyone be interested in EEPROM, even given those restrictions?

[+batari]

It seems I can't have two LEDs and extend the middle and lower bank addressing by a bit; the write-enable logic gets too complicated.  So would people rather have two LEDs with banking as documented, or one LED with the extra bit (so the middle and lower banks could access all of flash instead of just half each)?

 

Another possibility, if I go with a single LED, would be to add a serial EEPROM.  It would be impossible to access it without the LED (if present) flashing, and there would be some other weird restrictions as well.  During an EEPROM transaction (between the I2C start and stop conditions) code would not be allowed to access RAM from $4000-$7FFF nor flash from $4000-$7FFF or $C000-$FFFF except for reads to addresses $FFFE and $FFFF (which would act as I2C hotspots).

 

Would anyone be interested in EEPROM, even given those restrictions?

943225[/snapback]

I'd say it depends on how you access the chip. I've heard about very slow I2C access in the AtariVOX, but the problem here is likely that the 2600 has to do all of the bit-banging itself. If your cart does the bit-banging instead while freeing up the 2600 for other activities until the data is available, then I would be all for it.