Resetting a Atari 2600 console from a cart

[wilco2009]

Hi!

I'm trying to design my own sd cartridge for the Atari 2600 console, but to read the rom from the sd card take some time, and while it is happening console is running random values in the memory, and when the memory is ready console is already hung.

Anybody knows how is possible to generate a reset in the console from the cartridge?

thanks in advance

[Kroko]

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.

Edited July 1, 2020 by Kroko
typo

[wilco2009]

On 7/1/2020 at 11:02 PM, Kroko said:

 

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.

Thank you very much for your explanation.

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.

[+batari]

Another option is to write a short wait routine that runs in the console RAM until the data from the SD card is loaded. This is how the Harmony Cart handles it. With only 128 bytes you can't do much, but with creative programming you can actually display something on the screen in this little of space.

[wilco2009]

38 minutes ago, batari said:

Another option is to write a short wait routine that runs in the console RAM until the data from the SD card is loaded. This is how the Harmony Cart handles it. With only 128 bytes you can't do much, but with creative programming you can actually display something on the screen in this little of space.

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

[Kroko]

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.

[+batari]

2 hours ago, wilco2009 said:

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

I might have misunderstood your design a bit. I thought you were asking how to keep the console busy while loading from SD. But, it sounds like you are talking about how to keep a console busy all throughout the boot process until you are ready to present data to it. Maybe you are saying you want to design a cart with just SRAM chips and a logic chip to handle reading from SD, including reading the menu.

 

Well, there are some options, as you do have some time before the console fully boots. I estimated around 20 ms, but it depends on the console and it could be less, like 10 ms or so on some consoles. If your logic can bring something up that quickly you might be OK. Maybe, if not a file on SD, perhaps a small EEPROM with a basic bootloader would be enough.

[+batari]

I thought I might add that there *might* be a very simple, if somewhat unorthodox method that could keep the console busy without crashing.

 

Atari themselves designed hardware that overrode the data bus, and in doing so, maybe you could keep things running just long enough to boot your hardware. Atari did this with their Graduate add on, which they called bus stuffing, and also there is a cart out there that predates this called the Signal Tracing Cartridge which basically just throws an $EA on the data bus through a series of pullup and pulldown resistors, overriding anything that the 6507, TIA or ROIT attempts to put on the bus.

 

Thinking about this, though, you are asking how to reset the console from the cart port: well, you can't, but the only reason you would need to reset is if the 2600 hits a JAM instruction, which are basically the only instructions you can't recover from. These instructions have a pattern of D1=1. So technically, all you might have to do is drive D1=0 until you have some valid data to present, then issue a BRK and you could probably reliably boot the console.

 

[wilco2009]

8 hours ago, batari said:

I thought I might add that there *might* be a very simple, if somewhat unorthodox method that could keep the console busy without crashing.

 

Atari themselves designed hardware that overrode the data bus, and in doing so, maybe you could keep things running just long enough to boot your hardware. Atari did this with their Graduate add on, which they called bus stuffing, and also there is a cart out there that predates this called the Signal Tracing Cartridge which basically just throws an $EA on the data bus through a series of pullup and pulldown resistors, overriding anything that the 6507, TIA or ROIT attempts to put on the bus.

 

Thinking about this, though, you are asking how to reset the console from the cart port: well, you can't, but the only reason you would need to reset is if the 2600 hits a JAM instruction, which are basically the only instructions you can't recover from. These instructions have a pattern of D1=1. So technically, all you might have to do is drive D1=0 until you have some valid data to present, then issue a BRK and you could probably reliably boot the console.

 

Mmmmm, very interesting, seems to be easy to do. ?

 

Thanks very much. 

[Kroko]

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 ?

 

[+DrVenkman]

1 hour ago, Kroko said:

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 ?

 

Isn’t that basically bus-stuffing as referred to above? “The Graduate” computer was intended to use it, and a few years ago there were some bus-stuffing demos posted by (I think?) @SpiceWare as tests, but these proved unstable on some console variants. That’s probably why “The Graduate” was shelved and never actually released. 

 

I might be mis-remembering this, however. 

[wilco2009]

2 hours ago, Kroko said:

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 ?

 

It could be a problem in a CMOS CPU, because it uses strong "1's". In this case if you force 0V while the data line is at 0V the power will be dreaned in the data pin generating a high current with possible damages in the data pin of the processor.

The 6507 Atari's procesor uses NMOS technology. NMOS technology has strong 0's but weak 1's, then it is not dangerous to force a data pin to zero.

[+SpiceWare]

3 hours ago, Kroko said:

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 ?

 

@batari did some research in the topic "Bus stuffing" like The Graduate and determined it was safe, which lead us to create a Bus Stuffing driver for the Harmony/Melody.  I posted a number of demos which a lot of people tried.

 

 

 

 

 

However, the results from stuffing didn't always work as expected:

 

 

 

Sometimes cleaning the contacts on the cartridge and cartridge port would fix the problem, but not always.  So I posted A call for testing (Harmony Cart required) to get a handle on how widespread the issue was. Results were 4 out of 15 Juniors and 1 out of 14 7800s didn't work as expected with it.

 

If the issue had only been with the 7800 we would have proceeded to use it, but since Juniors were the main culprit we decided to take what we learned from creating BUS, and what we've learned from using DPC+ over a number of years, and created CDF.  My Draconian and @johnnywc's Super Cobra Arcade were the first games to utilize CDF.  CDF has been enhanced since then and is now called CDFJ (which stands for Chris, Darrell, Fred, and John). If you'd like to know more about CDFJ check the Harmony/Melody Club.

 

 

[Kroko]

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" ?

[+-^CrossBow^-]

13 hours ago, SpiceWare said:

 

@batari did some research in the topic "Bus stuffing" like The Graduate and determined it was safe, which lead us to create a Bus Stuffing driver for the Harmony/Melody.  I posted a number of demos which a lot of people tried.

 

 

 

 

 

However, the results from stuffing didn't always work as expected:

 

 

 

Sometimes cleaning the contacts on the cartridge and cartridge port would fix the problem, but not always.  So I posted A call for testing (Harmony Cart required) to get a handle on how widespread the issue was. Results were 4 out of 15 Juniors and 1 out of 14 7800s didn't work as expected with it.

 

If the issue had only been with the 7800 we would have proceeded to use it, but since Juniors were the main culprit we decided to take what we learned from creating BUS, and what we've learned from using DPC+ over a number of years, and created CDF.  My Draconian and @johnnywc's Super Cobra Arcade were the first games to utilize CDF.  CDF has been enhanced since then and is now called CDFJ (which stands for Chris, Darrell, Fred, and John). If you'd like to know more about CDFJ check the Harmony/Melody Club.

 

 

I use your Bus Stuffing demos for testing 7800s. I've found that it is effected by the extra timing circuit and that by disabling this (removing C64 from circuit), that your demos then work 7800s without issue. The Parrot one is the best to use and is the one I use the most.

 

[+SpiceWare]

17 hours ago, Kroko said:

Thanks for the links. Very interesting to read ?

 

Gern geschehen!

 

17 hours ago, Kroko said:

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" ?

 

Sure don't, I'm not a hardware guy. Best bet would be to get some input from @ZackAttack

[+SpiceWare]

11 hours ago, -^CrossBow^- said:

I use your Bus Stuffing demos for testing 7800s. I've found that it is effected by the extra timing circuit and that by disabling this (removing C64 from circuit), that your demos then work 7800s without issue. The Parrot one is the best to use and is the one I use the most.

 

 

That's interesting, thanks for the info!

[ZackAttack]

On 7/4/2020 at 6:57 PM, Kroko said:

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" ?

It's been a while since I've played with that, but if I recall correctly. There were two types of failures with the early bus stuffing attempts. The first type was when the cart failed to stuff its value onto the bus. The other type was timing related. Some systems, mine in particular, have some unusual address bus activity in the transition time between valid bus signals. The timings are compliant with the 6502 datasheet as far as I can tell. The problem is that the carts don't have access to any clock signals and have to poll the address bus to determine which rom location to emulate or which address location its stuffing a value into. If a transient value is identified as the next location, the cart will produce the wrong value and probably spend too much time doing so to catch the actual value that follows.

 

I completely bypass this problem in the strong-arm framework by keeping track of where 6502 will be reading next, precalculating the corresponding value, polling for the specific address value, and posting the data onto the bus as soon as the expected address is present on the bus. This has the bonus side effect of leaving more time to do useful work on the ARM core between 6502 bus servicing.

[Kroko]

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 ?

[+batari]

The contacts on the cartridge should be clean for bus stuffing to work right, but clean contacts are important in general so I wouldn't call that a limitation.

 

I think what is happening with timing, is that the earlier you get the value stuffed onto the bus, the more time it has to stabilize and overpower it. Some consoles would benefit from more time as the overriding doesn't necessarily happen instantly. I think it rises or falls like an RC circuit. Current is more important than voltage here if you are wanting to stuff a value in a short amount of time, provided voltages are enough. Higher voltage would help, provided you can sink or source the same amount of current.

 

I don't think there is any danger of driving the Atari on a flashcart powered by the Atari, but it sounds like you are working on a device that gets power externally? If so I would probably avoid applying power to data lines if you can. I think the possibility of damage is mostly theoretical, though, and the Atari will be fine.

[Kroko]

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).

 

[Danjovic]

On 8/17/2020 at 12:36 PM, Kroko said:

somebody decides to have big capacitors on his cart...

I was going to suggest that or a button battery for the RAM chip.

[wilco2009]

1 hour ago, Danjovic said:

I was going to suggest that or a button battery for the RAM chip.

Yes, this is the solution I think.