Atari 2600 questions

[i_r_on]

I was busy with my c64 cartridge project IRQHack64 lately so I haven't got the chance to contribute to the forum.

I started fresh with a new cartridge project for Atari 2600. I intend to create a cartridge that plays games from a sd card. I'm using a STM32 arm chip.

This is just an introduction but I have 6502 questions related to the atari 2600 hardware.

Atari 2600 have a 6507 chip which mainly has reduced address space and doesn't have interrupts.

As seen from the schematics the console doesn't even have a reset hardware, all that there is just a parallel capacitor with a resistor.

First question : How come this thing got a reset on cpu?

My challenge is : Boot code by emulating an eprom by a stm microprocessor. If that micro boots after 6507 has been reset than there is no means to reset the cpu by the cartridge port. Cartridge port only have address lines (A0..A12) and databus (D0..D7) brought. A12 is used to tell cpu need to access rom on the cartridge. No R/W lines.

Second question : Cartridge port doesn't have a R/W signal. Some cartridges have extra memory on them which are accessed through read and write ports which I guess the original equipment used address decoding to produce the R/W signal. Now the actual question is : With a pure rom cartridge, wouldn't a write access from cpu fight the bus with the rom (eprom or whatever) trying to drive the bus with the contents of the memory? Isn't that a problem?

[BigEd]

As it happens, we just discussed multi-bank ROMs over on Stardot. It turns out that the bank-switching port, in at least one case, is a read port. It's enough to read a special address to trigger a bank switch, if you have as many special addresses as you have banks. No need to write, and so no difficulty with having two drivers on the bus. (I think it should be possible, with a suitable arrangement on the cartridge, to have some write-only addresses. What's not so easy is to have addresses which can both read and write.)

(As a copy-protection tactic, the special bank-switching read ports can also act as normal ROM data and code.)

[KC9UDX]

I know very little about the VCS, but I don't think a ROM cartridge will have code to write to the cartridge. It's probably just that simple. There probably aren't cartridges with bugs except the ones that have bugs.

As far as reset, it was common for consumer electronics at that time to be reset by cycling the power. This can be seen famously on the Commodore 64.

[i_r_on]

Of course original hardware should be examined but another question arises about bankswitching. Is it happening at the same cycle with the read access to the determined address?

Say a LDA $1FF8 switches banks... do A register contain the rom value at $1FF8 at the end of the operation or is it just undetermined. I guess there would be no intention to read for such a case. Still it's not clear from the docs I read so far.

About the reset... no C64 had a proper reset circuit with a 555 timer ic.

About the no write to rom address space by software : I for one wouldn't rely on software to behave if indeed bus driven by two sources could do any harm.

[richardc64]

Without a hardware mod of installing a push button to short pin 2 of the 555 to ground, the only other way to hard reset the C64 once it was up and running was to cycle power.

it was possible to program a key combination to soft reset the C64, but that's not the same thing.

[KC9UDX]

i_r_on wrote:

About the no write to rom address space by software : I for one wouldn't rely on software to behave if indeed bus driven by two sources could do any harm.

You have two options here.

You can assume that none of the software behaves incorrectly (really, it probably doesn't, but you can't guarantee anything with all the new homebrew titles).

Or, you can design your hardware so that it isn't damaged by bus contention. You cannot redesign the VCS, so if it can be damaged this way (unlikely), there's nothing you can do about it anyway. Unless every title uses the same RAM access scheme (they probably don't!), you'll have to go this route anyway, or avoid titles that use a RAM access scheme incompatible with your hardware.

[i_r_on]

@richardc64 : Actually I was talking about the hardware part, of course there is no reset functionality provided to the end user on c64.

I examined the 2600 circuit again. It seems I misinterpreted the reset part. Pin pulled high with a resistor, also it's tied to GND with a capacitor. This setup generates the needed pulse on the Reset pin.

Here are the reset circuits of both systems. (2600 up, down is C64)

[KC9UDX]

Either way, the only way a reset happens is by cycling the power. There's nothing you can do about that without modifying the hardware, unfortunately. There may be a way to send the uP to the reset vector by telling it to JMP there from the cartridge port.

[i_r_on]

The quick and dirty solution to the startup problem would be to use some kind of startup rom or similar thing that keeps the cpu in a predefined state. Even a controllable free running mode would do. (tieing the databus to EA)

[hoglet]

There's probably more than you ever wanted to know about Atari 2600 bank switching here:
http://stella.sourceforge.net/bankswitching-methods.pdf

This document also describes how some cartridges include RAM, even though there is no R/W signal present.

You might also want to look at Retromaster's A2601 (Atari 2600 on FPGA) project:
https://retromaster.wordpress.com/a2601/

I've used a Papilio port of this called Papilio Arcade:
https://github.com/GadgetFactory/Papilio-Arcade

It implements various bank switching methods here:
https://github.com/GadgetFactory/Papili ... oFlash.vhd

Dave

[GARTHWILSON]

I made an I/O expansion board for the C64 when one of our sons was using the C64 a lot. Because of the lack of a reset button, I added that function on the board. This was a plug-in board, not a modification of the C64 itself. You can see it (including a poor scan of the pencil-drawn circuit) at http://6502.org/users/garth/projects.php?project=7 . It also times the reset pulse so it only stays down for about 20ms, regardless of how long you hold the button, because of the heating problem some NMOS 6502's had when the RST\ was held low too long.

[i_r_on]

By the way, searching the web I saw overdriving the databus is used safely as a hack to increase the TIA's resolution.
http://atariage.com/forums/topic/183085 ... -graduate/

It's still safe for one side (6507) though I don't know if STM32 would like it.

@hoglet : Thanks for the links. I had read the bankswitching as described by Kevin Horton here previously : http://kevtris.org/files/sizes.txt

I'll study the bank switching stuff in Retromaster's A2601 project if I can't implement it in software. Actually I got the sources for that project 4-5 months ago. The person behind it happened to be a fellow member in a local commodore related forum who I realized that I knew from his previous projects.

@GARTHWILSON : Interesting stuff really. Do you remember how much current drawn by the cartridge? Before changing paths in my C64 cartridge design I had once considered filling an sram with several tristate buffers by an arduino and then dropped that idea just because overall power consumption exceeded the supplied 350ma on expansion port from C64.

[BigEd]

i_r_on wrote:

By the way, searching the web I saw overdriving the databus is used safely as a hack to increase the TIA's resolution.
http://atariage.com/forums/topic/183085 ... -graduate/

Fascinating, and naughty. I reckon some people here will love it and some hate it. It would be even more controversial with a CMOS part, and maybe beyond unwise it wouldn't even work. We can think of it as a fast DMA channel for NMOS 6502. (As an aside, if anyone can resurrect the images meant to illustrate the hidden DMA channel as discussed here, that would be great.)

[GARTHWILSON]

i_r_on wrote:

@GARTHWILSON : Interesting stuff really. Do you remember how much current drawn by the cartridge? Before changing paths in my C64 cartridge design I had once considered filling an sram with several tristate buffers by an arduino and then dropped that idea just because overall power consumption exceeded the supplied 350ma on expansion port from C64.

I never measured it, but from the max specified for the ICs, it should be under 5mA with no loads. Each VIA I/O pin could conceivably add several mA under normal loads.

[KC9UDX]

The Commodore REU required a replacement power supply with higher output be attached to the C64. The C128 power supply was larger to alleviate this.

If you bought an REU for the '64, it came with the larger power supply.

There shouldn't be any reason one couldn't add an additional external supply for anything on the expansion port, if need be.