My 4A50: opinions wanted (EEPROM anyone?)

[supercat]

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.

943261[/snapback]

 

No, the cart wouldn't do any bit banging. And it'd probably be worse than Atarivox.

 

To toggle the clock line high then low, read $7FFF.

 

To toggle the clock line high, then toggle the data line, and then put the clock line low, read $7FFE.

 

To set the data line high without affecting the clock line, read $73 to set it high or $72 to set it low.

 

To read the state of the data line, set the upper memory bank to something recognizable, then read $71. If the data line is low, bit A8 of the upper memory bank will be toggled.

 

A little goofy, but should not be impossible to work with. Note that the I2C clock line is shared with A14--hence the addressing restrictions mentioned earlier.

[vdub_bobby]

Even given goofy restrictions, and as slow or slower than the AVox, I would be all for it.

[cd-w]

Even given goofy restrictions, and as slow or slower than the AVox, I would be all for it. 

943566[/snapback]

 

I agree with you - it would be a great facility to have even if it was a bit difficult to use.

 

Chris

[+batari]

Even given goofy restrictions, and as slow or slower than the AVox, I would be all for it. 

943566[/snapback]

 

I agree with you - it would be a great facility to have even if it was a bit difficult to use.

 

Chris

943794[/snapback]

I suppose I agree - the functionality would be nice to have, slow or not. But I wonder how much cost it will add?

 

Anyway, I've been reading up on 4A50, and something is bugging me. Most carts have a read port and a write port at different addresses but yours does not. How does your cart determine whether a read or a write is taking place?

[supercat]

I suppose I agree - the functionality would be nice to have, slow or not.  But I wonder how much cost it will add?

 

An Atmel 8Kx8 serial EEPROM is just under $0.50 in quantity 100. Probably worth that to stick it on all the boards (since it's easier to stick it on all than just some). If I do a proto with it and then decide not to include it in production, it costs nothing to leave the space.

 

Anyway, I've been reading up on 4A50, and something is bugging me.  Most carts have a read port and a write port at different addresses but yours does not.  How does your cart determine whether a read or a write is taking place?

945112[/snapback]

 

Most excellent question. During the first quarter of a machine cycle, I perform a RAM read whether the 6507 is going to do a read or a write. I then use the "bus keeper" function of the Xilinx XC9536XL chip to weakly hold the contents of the data bus while I start a memory write cycle. Three quarters of the way through the machine cycle, I finish the memory write. If the 6507 wanted to write anything, it would have (quite easily) overpowered the bus keeper circuit and so the data written would come from the CPU. Otherwise, the data written will simply be the data that was just read.

 

The bus keeper circuit has no trouble holding the bus state on a Heavy Sixer or a 2600jr. On a 7800, the signal levels are a little marginal. It works quite consistently on my 7800, but I can't guarantee that it would work on all of them. On the other hand, since many 7800's have trouble with other RAM carts I'm not too terribly worried about that. Experiments with reading TIA addresses suggest that the bus keeper circuit will hold the bus for almost a full clock cycle on the 7800 (sometimes the bus state holds, and sometimes it doesn't). On the 2600, it can hold the bus for several cycles (tested IIRC via LDA ($25,X) with X=0; the read data consistently comes back $25 despite the bus floating for the reads of $25, $25, $26, and $2525).

[+batari]

I suppose I agree - the functionality would be nice to Anyway, I've been reading up on 4A50, and something is bugging me.  Most carts have a read port and a write port at different addresses but yours does not.  How does your cart determine whether a read or a write is taking place?

945112[/snapback]

 

Most excellent question. During the first quarter of a machine cycle, I perform a RAM read whether the 6507 is going to do a read or a write. I then use the "bus keeper" function of the Xilinx XC9536XL chip to weakly hold the contents of the data bus while I start a memory write cycle. Three quarters of the way through the machine cycle, I finish the memory write. If the 6507 wanted to write anything, it would have (quite easily) overpowered the bus keeper circuit and so the data written would come from the CPU. Otherwise, the data written will simply be the data that was just read.

 

The bus keeper circuit has no trouble holding the bus state on a Heavy Sixer or a 2600jr. On a 7800, the signal levels are a little marginal. It works quite consistently on my 7800, but I can't guarantee that it would work on all of them. On the other hand, since many 7800's have trouble with other RAM carts I'm not too terribly worried about that. Experiments with reading TIA addresses suggest that the bus keeper circuit will hold the bus for almost a full clock cycle on the 7800 (sometimes the bus state holds, and sometimes it doesn't). On the 2600, it can hold the bus for several cycles (tested IIRC via LDA ($25,X) with X=0; the read data consistently comes back $25 despite the bus floating for the reads of $25, $25, $26, and $2525).

945402[/snapback]

Interesting. I would have never thought of that.

 

Does it also handle read-modify-write instructions?

[supercat]

Interesting.  I would have never thought of that.

 

Does it also handle read-modify-write instructions?

945425[/snapback]

 

Yup.

 

Incidentally, my earlier plan for the 4A50 bank-switching scheme, before I discovered that the bus-keeper approach could work, would have also allowed the use of an address range for both reading and writing, but would require that an address range be write-protected before it could be used to run code. The plan was to watch the byte that was fetched immediately before an access to a memory range, and then watch for single-, double-, or triple accesses. I forget the exact details, but it was rather tricky and complicated. Doing things this way is much simpler in both hardware and software.

[cd-w]

Is there any more news on the 4A50 cart project - it sounded like it was nearly complete around a month ago, but things have gone quiet since then? I am still eagerly awaiting a 2600 cart with a decent quantity of RAM!

 

Chris

Edited November 29, 2005 by cd-w

[potatohead]

Is there any more news on the 4A50 cart project - it sounded like it was nearly complete around a month ago, but things have gone quiet since then?  I am still eagerly awaiting a 2600 cart with a decent quantity of RAM!

 

Chris

973749[/snapback]

 

 

Same here. For what it's worth, I think I'll buy two of the first batch. Pester, pester, pester....

 

[supercat]

Same here.  For what it's worth, I think I'll buy two of the first batch.  Pester, pester, pester....

976679[/snapback]

 

Prototype #1 exists and works great. Someone offered to do some boards for the next few to save me the expense; I'll have to see where they are.

 

It looks as though the cost may be higher than I'd like for production units. Also, PAL machines will need a different cart from NTSC machines (the oscillator frequency on the cart must be 4x the machine's, +/- about 0.1% to allow for correct operation if code running from RAM performs a 75-cycle STA WSYNC instruction.