How to MAKE a "XX in 1" 8K games Atari 2600 Cart

[How to MAKE a "XX in 1" 8K games Atari 2600 Cart]

Can you find out (maybe with a multimeter) if the counter output is counting up on each power cycle ? I mean what the higher bits of the counter are doing ? ... do they count up or are they getting reset ?

Or maybe you have the time to reverse engineer the schematic for us

[How to MAKE a "XX in 1" 8K games Atari 2600 Cart]

39 minutes ago, pcrock said:

If I change the chip with more roms inside, it will works???

Without looking at the circuit, I doubt that it will work. What the circuit has to do is to select the highest address line on the EEPROM to select one of two 8K areas inside your 16K chip.

If you want more than 16K to have more than two 8K games, you will need
 

* a larger chip which may have a different pinout => you may need some kind of adapter
* need a strategy to control the higher address lines because most likely your device is not doing this (you could use simple switches for that to set the high address lines to 0 or 1)

Then by cycling the power you would select between two 8K roms. By the switches you could switch in two different ROMs.

[Resetting a Atari 2600 console from a cart]

20 hours ago, batari said:

it sounds like you are working on a device that gets power externally?

I am not working on anything at the moment ... I just remembered the discussion that I had a long time ago. The question was if it is save to drive the cartridge pins while the console is switched off.
And I remember somebody was worried about driving current into a switched off console.

 

If this is more a theoretical problem, then it is not necessary to think about cartridge behaviour during console power down. But if it is not only theoretical and somebody decides to have big capacitors on his cart, it may be alive significantly longer than the console.

On the other hand, if this was a problem...we may have heard of it before (because it is not limited to bus stuffing devices).

 

[Resetting a Atari 2600 console from a cart]

23 minutes ago, ZackAttack said:

The first type was when the cart failed to stuff its value onto the bus

Does this mean the driver circuit in the cart can not electrically override the value on the bus, because the internal driver is stronger, or there are unpredictable resistances on the pins like dirt at the connector ?
Would these kind of problems be possible to solve with a stronger driver that is really operating with 5V instead of 3.3V with more maximum current ?
 

27 minutes ago, ZackAttack said:

to poll the address bus to determine which rom location to emulate

I understand that part ... I guess it is tricky to get the timing correct if you don't have a dedicated circuit or logic that can generate an "adress stable" signal.

 

Somebody told me some time back (I don't remember who it was), that it is a very bad idea to stuff value into the 2600 circuits in case the 2600 is switched off. I know there have been lots of tests of this bus stuffing

when the 2600 is powered normally. But do you know more about what happens if you continue to stuff when VCS power is off ? Should I be worried to inject voltages to the pins of the console if the console is not powered ?

[Resetting a Atari 2600 console from a cart]

Thanks for the links. Very interesting to read 👍

Did you ever understand what exactly caused the issue on the Juniors ? On the other thread I only found this:

"ZackAttack has determined the problem with the Juniors is most likely an electrical issue that, if a solution can to be found, would require hardware modifications"

Do you remember what kind of "electrical issue" ?

[Resetting a Atari 2600 console from a cart]

2 hours ago, wilco2009 said:

So technically, all you might have to do is drive D1=0 until you have some valid data to present

If you have two different drivers on the databus, are you sure that the console will not get damaged ? What happens if both drivers

set different values ? Are 2600 databus drivers protected against such situations, where they have to drive the bus "against" a second

driver ?

 

[Resetting a Atari 2600 console from a cart]

10 hours ago, wilco2009 said:

Then seems the best solution is to add a little EROM chip to the circuit to take the control until the cartridge tranfer the program to the RAM chip.

Another posibility is to send bytes to the bus from the CPLD without any kind of ROM in the cart. The main issue is the sincronization when the change to the RAM is made.

It depends on how your hardware is designed. It is not very popular now to use a CPLD, because everything you need can be done by one little microcontroller. There were times,

when these controllers were too slow to do the databus handling ... so a CPLD was doing that part of the job. But now they are (or can be) fast enough.

Less chips .. less trouble .. less cost .. less board space .. less power consumption. etc..  (If your device needs too much power, you will need an external power supply...which you don't want)

I would certainly not use a CPLD for any new design. Not only because you need VHDL or VERILOG and the complete toolchain for programming them. You also need to write the complete

bankswitching logic in VHDL ...which you also don't want to do
 

Startup of the microcontroller should be fast enough to establish a routine that can scan the address bus and output bytes on the databus, if cartridge rom is addressed by the console.

You just need a contoller with enough pins and a smart routine for the handling of output to the databus.

I think batari knows it very well, since I guess he is using such a microcontroller solution.

You could use a parallel EEPROM, but that will need additional board space, makes routing the board more difficult, consumes power, costs extra money ...etc ...
There should be enough memory inside the microcontroller to not need any additional chip for RAM or ROM.
 

32 minutes ago, wilco2009 said:

But how do you prevent the console from hanging until you copy these 128 bytes into RAM?

It is the same principle. You present some code to the console that writes a program to console RAM and then jumps to this code. After you have done that, you don't need to worry about

the adress bus anymore, because code is now taken from RAM rather than ROM. This solution has the advantage that you are free to do whatever you want while the code is executing in

RAM and don't need to worry about sending bytes on the databus from your cartridge.

 

Also for this solution, your hardware needs to be "instant on" to a minimum degree. Otherwise the console will crash. There is nothing you can do to prevent this. If the console wants to

read the reset vector from cartridge ROM, you need to be ready to provide the vector or the console will get some random value which will lead to a crash in most cases.

[Resetting a Atari 2600 console from a cart]

9 hours ago, wilco2009 said:

and while it is happening console is running random values in the memory, and when the memory is ready console is already hung

 

You can not let your cartridge provide random values on the databus, you need to make sure that you keep control over what is going on.

If the console shows some address on the bus, which is located in you cartridge, then you need to output something that makes sense.

 

You need to construct your cartridge such, that some initial ROM is presented to the console.

This can be a very simple ROM (only a few bytes). Or a very complicated one. Some cartridges provide a "menu system" ROM to the cartridge until they
finished loading the real roms. Or they let you select one of several different ROMs that the cartridge can provide. After finishing the loading or selection they

all have the same problem: to do a clean start of the ROM they loaded. This can be done by presenting a JMP ($FFFC) instruction to the console.

Starting from that moment, the real ROM must be provided at the databus and the initial ROM is switched off.

 

An example of a very easy initial ROM would be a reset and IRQ vector pointing to $1000. And a BRK instruction at $1000. This will result in an endless

try of the console to jump to $1000. I think these are only 5 bytes you need to provide to the console while you are waiting for your SD content to load.

 

After you loaded, you wait until the cartride provides $1000 at the adress bus and you provide the JMP ($FFFC) instruction instead of the BRK. Then you switch
in the real ROM. I did not try this, but maybe somebody else wrote code like this before. You can also make some endless Loop ...important is only you have

control over what the console is doing, while you are waiting.

[Failing at 3F BankSwitching]

$3F is a little bit difficult, because the last 2K chunk in the rom file plays a special role. It needs to be placed at the fixed bank. So you could be tempted to open the file and read the last 2K to place it in the fixed bank.
If you do it like that, then it is almost sure you will not produce a working ROM if the last chunk is not exactly 2K.

In my opinion, a 3F ROM that does not have a file size that is some multiple of 2K is broken.
 

[Failing at 3F BankSwitching]

As far as I know, the last two bytes are the IRQ/BRK vector. If this vector is unused and can contain random data, I see no reason why a ROM should fail on "real hardware".
In case of Harmony I guess there is also some strategy to fill internal memory from a binary file. And here there could be a problem if the size is incorrect. The
ROM content may be written to the wrong memory location, but that depends on how Harmony maps the file to its memory ...

So there is no answer for "real hardware". You could only tell it for some specific device ...
 

[Failing at 3F BankSwitching]

4 hours ago, stephena said:

"The last 2K segment always points to the last 2K of the ROM image"

I guess nobody really thought of ROM files with a wrong size. This sentence just means that the last 2K block found in the ROM will be the fixed block. You should start counting blocks from the beginning of the file and put the last 2K block to the fixed bank, no matter if the last block is really 2K or not. This is also what would happen if you flash the ROM to some real memory. You would not flash it "backward" but from start of file until end of file, which leaves the last two bytes undefined or empty.

[No-Frills Bankswitching]

Sure you are right:  it is 130 MB of level definitions for Sokoboo

 

 

 

[No-Frills Bankswitching]

I doubt that anybody would ever need more than 512 MB on a 2600, but ...

 

How about a 16-bit bank number ? 256 * 256 banks (2K per bank) => About 130 GB of ROM space ...

3F write bank-number lo-byte
XX write bank-number hi-byte

XX may be another unused hotspot from TIA space

 

[Jentzsch/Davie '2600 tile/character graphics engine]

4 hours ago, Andrew Davie said:

So, 3E isn't the best. Also, it does have that quirk of being unable to do (zp),y across page boundaries.  If you didn't know that, you should! It was a limitation of the Krokodile cart limitations.  if $80/$81 points to a table at (say) $F9F0, you CANNOT get the 17th byte (at $FA01) by using . ldy #17 / lda ($80),y.  In that case it will actually retrieve the byte at $F901. Very non-standard and the cause for much heartache. All of Boulder Dash (and hence the tile engine) was very carefully written to avoid this situation.

Hi Andrew, I am not sure if you would only have this problem for 3E. I think it is a general problem of the 6507 crossing page boundaries. For the write instructions STA, STX, STY, SHA, SHX, SHY the 6507 is doing the following:
 

In  cycle #4  a wrong address appears on the bus. In cycle #5 the address is fixed, but then it is too late. The bankswitching hardware always monitors the bus and if you have a wrong address on the bus, then the hardware is reacting to it.

So if you were using such an instruction on the write port of the RAM area, you would first put the wrong address to the bus in case you were crossing a page boundary.

In case you want to construct a bankswitching method that does not have this problem, you need to find a way to detect, the wrong dummy address from cycle #4 (which may be difficult).
Or you could think of a different mechanism to read/write to the RAM (not using the Superchip approach).

 

        #   address  R/W description
       --- --------- --- ------------------------------------------
        1     PC      R  fetch opcode, increment PC
        2     PC      R  fetch low byte of address, increment PC
        3     PC      R  fetch high byte of address,
                         add index register to low address byte,
                         increment PC
        4  address+I* R  read from effective address,
                         fix the high byte of effective address
        5  address+I  W  write to effective address

 

       Notes: I denotes either index register (X or Y).

 

              * The high byte of the effective address may be invalid
                at this time, i.e. it may be smaller by $100. Because
                the processor cannot undo a write to an invalid
                address, it always reads from the address first.

 

[Tigervision banking and low-memory reads]

I have implemented 3F bankswitching for any access to bus location $003F, no matter if it is read or write.
As you wrote, there is no way on real hardware to detect if somebody is doing a read or write to that location.

Maybe it works on real hardware, because I am only using $3F, not the locations below $3F. Could be that
the cartridges that make trouble with read access do the same thing. They would have trouble with reads from

addresses below $3F as well. They may only work because these addresses are ignored...

Do you have an example of how a 3F cartridge fails because of a read access to $3F (not below $3F) ?

I have started to reinvestigate a loose end that came up during 6502.ts development and still am stumped, so here it goes...

 

According to the documentation I could find on tigervision banking, it switches banks on writes to low memory positions starting with 3F. As the cartridge bus does not expose R/W select, I originally implemented my code to trigger on both writes AND reads. To my utter surprise, including reads breaks several historic cartridges badly (e.g. Miner 2049er). If I disable switch-on-read, everything is back to normal, so that's what's implemented right now. I cross-checked Stella, and it's the same there: switches happen only on write.

 

However, this cannot be the real deal as real cartridges don't have any way to tell a read from a write. So, does anyone know what is going on here in real hardware? Some of these games read only from 0x00 and 0x01, and, as nothing else drives the data bus, this should also be the value read, so it can't be connected to the handling of invalid bank values. Is the documented address range for bankswitching wrong? Is the cartridge watching for specific instructions? Is there some peculiarity in the cartridge circuit that modifies the behavor of undefined reads?

[Timing for ROM access]

Do you think it is possible to run some assembly kernel on one core and run Linux on the rest of the cores ?

[Timing for ROM access]

Kroko, did you ever consider using arduino instead ?

I needed at least 24 free GPIO pins. Lots of people have Raspberry Pi at home, so all that is needed is a cheap adaptor to turn it into a 2600 cartridge.

 

How popular is Arduino compared to Raspberry Pi ? Do people have these at home, too ?

 

Now that the Pi Zero is 5$ it might be hard to find something comparable in the arduino world.

[Timing for ROM access]

Actually I have been working on a Rasperry Pi cartridge based on the B+. I had to install my own operating system on the Pi ... Linux is not fast enough. But I was finally able to use the Raspberry Pi B+ as a Pac-Man cartridge (shame on me for choosing Pac-Man).

 

So yes, the Pi is fast enough to do this, but you need a very much optimized assembly kernel for that and there is VERY little time left for anything else but watching the bus and setting the data lines. Doing a lot of things in the background is at least difficult.

There are other difficulties: The noise level you induce into the 2600 by using a Pi is significant. I was not able to receive power from the console and have a nice picture at the same time. Even not after using resistors on the dataline between the level shifters and the 2600. Only when using an external power supply for the Pi, the picture quality was acceptable.

 

Actually I already bought a Pi Zero to see if it is possible to replace the B+ by Pi Zero. Unfortunately I had to wait a long time for the Zero and now I have no more time to work on the project ...

I never ordered a PCB, but I think the Pi zero could be squeezed into a 2600 cart ...

[Designing a cartridge that supports 100% C/C++ game development]

The picture is pretty noisy, but that's expected considering my complete disregard for proper RF shielding and what not.

 

The noise might be a critical issue in the end. For the "nomal" flash cartridge that operates with a fast clock it is sufficient to put ~1KOhm resistors between the cartridge connector and the databus [D0-D7]. This removes most of the noise. But I am a bit uncertain, about your setup. You might also have to put resistors between A0-A12 and cart connector. Most likely your noise is not because of RF shielding. It is induced by the A and D bus. Try to isolate all signals you inject into the 2600 from the power supply of your FPGA board as much as you can without breaking your design. Maybe there is a better way than resistors ... I just didn't find it, yet.

 

[8kb to 16kb homebrew boards?]

If you have the possibility to program 20V8 PLDs, all you need is here:
http://www.grandideastudio.com/portfolio/pixels-past/

[8kb to 16kb homebrew boards?]

If 8K works OK, then I guess the logic chip is programmed with F8 bankswitching. I don't think that the logic chip can do F8, F6 and F4 bankswitching at the same time. So for 16K you need a logic chip for F6 and for 32K you need a chip with F4 bankswitching.

[Atari 2600 home made cartridge: dont works]

Your connector looks fine. The blue jumper ? what does it do ? As it is installed in the picture to me it looks as if it pulls down your PGM pin to ground. But it is hard to see. Please confirm you are not pulling this pin down to ground by the jumper! It needs to be on 5V. Can you check that none of your inverter outputs is connected to ground. Your setup doesn't look very clean

[Atari 2600 home made cartridge: dont works]

I wanted you to connect the inverted Atari2600 A12 to /OE instead of /CS. A12 of your EEPROM should still be controlled by your switches.

/CS is the chip select.
/OE is output enable.

In principle both do the same thing, but for some chips the timing is different. I have seen /OE being faster than the /CS. But I doubt that this is your issue... I was just running out of ideas ...

You can also check the CS and OE timing in your chip's datasheet

 

>> Using A12 as /CS? I dont understand. If we stuck /CS to ground, the eprom will be always enabled.
>> A12 (in the eprom)is for selecting the 4K page, and in the console, inverted is for emprom's /CS.
>> Can you explain a little more what you want to do?

[Atari 2600 home made cartridge: dont works]

Did you verify the eprom content after burning ? Have you tried to double up the rom until the complete chip is full ? For example if you have some 4K rom, make an image which has the same 4K 8 times such that you have the complete 32K filled with data. That way you can exclude problems with bank selection.

 

How difficult would it be to try connecting NCE to ground and let A12 select output enable instead ?

 

Another thing to check: When you plug in your PCB, are you sure the row with D3,D4,D5 is pointing to the monitor and the row with D2, D1, D0 etc is pointing towards you ? If the cart PCB is not mounted in some cartridge case, you may simply plug it in in the wrong direction ...

[Atari 2600 home made cartridge: dont works]

Are you 100% sure you got the address and data lines connected correctly ? The distribution of the address and data line on the cart connector is a bit strange. If you use an old cartridge PCB, then be careful, because not all ROMs have the same pinout as your EEPROM.