my 2600 playground

[TomSon]

So..

I’ve spent quite a bit of time with my Atari during the last winter and finished my project a while back but never

actually posted anything about it so I wanted to put something down here at least.

So, what is this project (btw, name is 'Tiara' for now) - I would explain it as a VecFever for the 2600 but since you do not know what

my VecFever is: it’s a versatile hardware that for one thing loads binaries off of a disk, analyzes them and creates the hw environment the

loaded bin needs to run in a 2600; it stores the state immediately before starting any game selected in the file browser

and upon power-cycling comes up just as it was pre-start. More crucially, since I build this as a development system, it let’s

you upload a new cartridge to try out immediately via USB, if it’s in development mode. This is simply enabled by flipping a switch on

the console at any time in the menu - e.g. one of the ‚difficulty‘ switches, if enabled by a menu option. Exactly the same setup that I like to

use for developing my Vectrex games: a ramdisk appears via usb on my dev. machine where I can upload anything; so fast turnaround times.

Probably the first thing someone will ask is which 2600 hw is supported so here’s the current list:

. 2K/F4/F6/F6SC/F8/F8SC (Atari 2K-32K ROMs with or w/o Superchip)

. 3E (128K ROM/32K RAM in the moment)

. 3F

. AR (Supercharger)

. DPC (Pitfall 2!)

. E0 (Parker Brothers)

. E7 (16K M-Network)

. EFSC

. F0

. FA (e.g. Omega Race)

. FA2 (e.g. Star Castle)

. FE (e.g. Activision Decathlon)

. UA

special case is DPC+: the 2600-side has been implemented (e.g. more and fractional fetchers,

'fast fetch') but cartridges using the Harmony processor directly will not work.

but since the firmware can be upgraded at any time simply by starting an update file using the file browser this can be expanded easily.

In the moment I don’t have any bins here that do not work, except for certain Harmony-ARM-binaries.

However, while developing this I came across a few home-brews I’ve analyzed that do assume a specific hw. behavior the Harmony cart.

seems to have - but not the Tiara - that can be problematic, mostly surrounding the bank registers. Since only the Harmony cart. existed

so far and all those things are easily fixed on the fly I’ve added patches for everything I’ve encountered. These were just a handful of games

anyways (5 or six if I remember correctly).

The menus also can be selected and changed on the fly since the 2600 is just used as a bitmap-terminal by the firmware. Same with color palettes, frequency

or other options. Are there any bugs I know of ? Maybe one: I am not happy with the sound output from DPC cartridges at the moment but not having any reference

to check against (the Pitfall 2 cartridges I've bought all arrived dead) I’ve got nothing to compare it with. Sound is ok(-ish) but not as good as I hoped for. Because of this

I haven’t added sound support to dpc+, either, yet.

So, where to go from here ?

The obvious next step now would be 7800 support: first a 7800 menu for a VCS Tiara that will use a higher resolution menu and then

start a selected 2600 cart (if that’s possible). Then a dedicated 7800 Tiara that would allow to run 7800 cartridges, too, while also

be able to run the 2600 ones. However I only investigated this for a weekend when getting a 7800 and realized that programming a 7800 menu

would take quite some time for me - mostly learning the hw. and setting up another dev. system. And the 7800 I got is really terrible - it was

enough to check that I could detect a 7800 by the initial checksum test and verify that the Tiara works there, too, but I was tempted to throw

it away almost all the time while doing so (sound has problems, colors are seriously off and the controller only works sometimes).

So my first and only impression of the 7800 was terrible and mostly due to this I haven’t spent any time on this anymore.

Still, I intend to maintain this project for quite some time - it shares code with the VecFever which makes it easy - and I still wonder about

7800 support so if someone out there thinks this is worthwhile (and convinces me) I might develop this further, either on my own or with someone helping with

the 7800 menu-side.

The hardware itself is (almost) finished - the current pcb dimension already fits perfectly into Atari cases but a capacitor needs to be moved a bit for the earliest cases or

it might get dislodged there by the sliding plastic cover that ‚protects‘ the pcb when not in the console. The 'younger' cases (e.g. w/o sliding plastic or the ones with two larger springs)

work fine. Next iteration will fix this, of course.

What else..: at this point I have no intention to make the Tiara available to anyone (except .maybe. to other developers, who want to take a look at this).

I’ve developed this mainly to learn about the 2600 and ‚since I could‘.

And I really do have fond memories of my Atari VCS, so I enjoy having my own hardware feeding it with data,

Thomas

p.s.

and I finally ‚beat‘ H.E.R.O., 3 decades late but still that was one of my goals

[Thomas Jentzsch]

Very cool menu, how did you do that one?

[ZackAttack]

Very cool project. Could you share more details about the hardware? I assume you've got a MCU on there, which one is it?

[DirtyHairy]

A very nice project. Can you share some more detail about the hardware involved?

 

However, while developing this I came across a few home-brews I’ve analyzed that do assume a specific hw. behavior the Harmony cart.

seems to have - but not the Tiara - that can be problematic, mostly surrounding the bank registers. Since only the Harmony cart. existed

so far and all those things are easily fixed on the fly I’ve added patches for everything I’ve encountered. These were just a handful of games

anyways (5 or six if I remember correctly).

 

That's interesting. Can you elaborate a bit? Such idiosyncrasies of the harmony cart regarding affect bank switching might also be relevant for emulation

[TomSon]

Concerning menus - I use a 4k menu bank (times eight - literally just draws a bitmap and changes the bg color once per scanline, using a few flags for necessary,

other stuff (e.g. length of frame for 60Hz/50Hz etc.). Every frame the menu hands over the input bits and the firmware draws/sets up whatever is needed.

So everything is drawn by the firmware using automatically generated offset lists per menu to directly poke in new values.

 

The hardware is an ARM stm32f4 processor, I've used two different versions and the one here uses the f405 plus an additional 16MB flash for the usb disk.

Switching to a bigger one (for more RAM) would be easy but I've got no bin remotely using the 160k I currently have for the VCS already so don't see a need yet.

There is otherwise no fixed circuit hw between the cart. slot and the ARM - everything is done in sw. on a per cycle basis and the ARM is manually init. fast

enough to supply the 6507 with the reset vector.

 

behavior:

Almost all cartridges out there do a 'do not care for value' read of those registers. Some a write, just as a trigger. Some mix both. A few ones do need to

read an actual byte value, I think one even expects to read a byte from a specific bank (it's a coin toss if the expected data would be from the current bank or the one

switched to or valid at all on actual, 'simple' hw). Frequently this is done by putting code directly in the bank registers and pointing the reset vector to it or jumping

to it (e.g. Man Goes Down or Ms.Hack).

 

Writing is a problem for the Tiara since a 6507 write together with the uProc putting data on the bus does lead to problems - bus stuffing does not work with

this uProc (or at least I couldn't get the expected result). It reliably crashes the bus emulation.

I'm seeing similar behavior with the 6809 where I tried this, too, trying to overwrite one specific bit in the Vectrex ROM code for a test.

And I can't imagine 'real' hw to be magnanimous about this, either, depending on actual setup.

So a game mixing reads with expected return values and writes to bank regs. won't work w/o needing some hand-holding (again: Ms.Hack).

 

At the start I randomized the start bank of hw where I believe it isn't fixed at startup but quite a few home-brews had problems - but not the old games - that I stopped this

right away. This is weird because most of those home-brews actually do have code behavior to init. themselves to a bank.

(just to name one: 'Stay Frosty' dies starting in bank 3, works in other banks (is X==bank guaranteed on harmony, maybe ?!).

 

The harmony, when starting an ARM routine, seems to still return the last byte over and over (or zero, can't remember, but it was fixed based on expected return values) while being busy.

The Tiara doesn't - bus values are floating/semi-random. So something like Star Castles (bit 1ff4, bvc xxx) check when storing hiscores doesn't work (which is why I haven't

added storage functions so far) - it would need a presence check before.

Edited June 2, 2017 by TomSon

[Thomas Jentzsch]

So something like Star Castles (bit 1ff4, bvc xxx) check when storing hiscores doesn't work (which is why I haven't

added storage functions so far) - it would need a presence check before.

The Yin-Yang display while loading does exactly the same.

[RevEng]

Impressive work, and wow, what an amazing menu!

[+SpiceWare]

just to name one: 'Stay Frosty' dies starting in bank 3, works in other banks (is X==bank guaranteed on harmony, maybe ?!).

 

Bankswitching schemes BUS, CDF, and DPC+ are all guaranteed to start in the very last bank of ROM. This is due to the prior banks potentially having ARM code in them, which precludes 6502 code (and thus valid vectors) in those banks. I'm not familiar with how the other bankswitching schemes start up on the Harmony, though I suspect they're not random.

 

Stay Frosty is a 12K game that was designed as part Stella's Stocking, a 64K game. I don't recall the specifics for that scheme, though I did make it so I could build a 16K version for testing (though it's still a 12K game with the last bank unused). It's possible I messed up, or even forgot to set, the vectors in the unused bank and just never encountered a problem when testing in Stella or on hardware.

 

Stay Frosty was written in 2007, which predates the Harmony cart. So I would have been using my Krokodile Kart to test on my 2600. Likewise, I suspect it doesn't start up in a random bank.

 

If I remember correctly, the Harmony came to be due to the desire to create flashable carts for games in the AtariAge store after Al was overwhelmed with the holiday 2007 sales. The flashable cart ended up becoming the Melody board. The Harmony is the Melody board plus a daughterboard which contains, amongst other things, the SD card slot and USB port.

[Thomas Jentzsch]

The last bank of the Stay Frosty ROM I have looks fine (startup vector and bank switching to bank 0).

[TomSon]

The last bank of the Stay Frosty ROM I have looks fine (startup vector and bank switching to bank 0).

 

Hmm, the one I just looked at again is 16K - the reset vectors are ffe8 in all banks and the opcode there is a nop FFF9 in banks 0-2

but in bank 3 it's a nop FFF6,X. So if you start in bank 3 and the instruction is loaded from this bank it'll likely not end up accessing ffe9

(depending on reset X value) but more likely stay in ffea due to the last adr. fetch. Bank 3 is actually almost empty otherwise -FFs-,

just 0x87 bytes or so at the start of the bank are used (looks like init. code, too).

 

So I probably have got a weird binary here..

 

Oh: and I want to apologize for singling out (by mentioning it) 'Stay Frosty' - I just remembered this for some reason first. I should have

dug up the above reset code w/o actually naming it but I was almost out of the door for a day trip (beautiful weather here in the moment)

Edited June 2, 2017 by TomSon

[Thomas Jentzsch]

Mine does NOP $FFF6,X too (sorry, looked at an old document which describes $1C wrong).

 

Nevertheless, within Stella the game always starts correctly, even with randomized registers. But it seems that Stella always chooses bank 0.

Edited June 2, 2017 by Thomas Jentzsch

[TomSon]

The Yin-Yang display while loading does exactly the same.

I know . nice display, btw

Are there other examples of storing data ? I might add this still since it's reasonably easy to do (in principle) and I myself

like to play for highscores. Ideally I like to have a unique identifier for a file so that I know which dataset belongs

to which cartridge but this doesn't seem to exist here and I would have to use, say, a checksum of the binary as a substitute.

Not ideal, especially when developing since it changes all the time. Any ideas ?

[TomSon]

Mine does NOP $FFF6,X too (sorry, looked at an old document which describes $1C wrong).

 

Nevertheless, within Stella the game always starts correctly, even with randomized registers. But it seems that Stella always chooses bank 0.

yes, Stella always starts at bank 0, too, it'll crash here if I manually switch to bank 3 right after a manual reset.

 

Actually: I wondered before why 'randomized registers' existed but not a randomized bank option - except that randomizing banks would need

a list of cart. hw where this could/should be tested - not only the harmony ones but also 'FE' for example comes up in a defined bank, anyways, so

randomizing this would be wrong again..

[+SpiceWare]

Oh: and I want to apologize for singling out (by mentioning it) 'Stay Frosty' - I just remembered this for some reason first.

No need to apologize, I have no problems with anybody finding and reporting on bugs in my programs

 

 

Not sure why I have NOP ,x in there, that's not a version of NOP I'd ever consider using

 

 

Aha - looks like I copied the code from supercat's post about Menu Integration. I would have copied the second bit of code into the last bank because it's the "dummy menu" when building a 16K version of the game:

Each bank other than the start bank should have its reset vector point to $FFE8, which should contain the code:

  NOP bankswitchToMenu
  JMP GameStartPoint
  NOP bankswitchToMenu
  JMP GameInfoPoint

---

 

The start bank will contain:

  NOP bankswitch,x
  JMP MenuMainStart
  NOP bankswitch,x
  JMP MenuReStart

 

[Thomas Jentzsch]

Actually: I wondered before why 'randomized registers' existed but not a randomized bank option - except that randomizing banks would need

a list of cart. hw where this could/should be tested - not only the harmony ones but also 'FE' for example comes up in a defined bank, anyways, so

randomizing this would be wrong again..

Funny, I had the same thought and just opened an issue for this.

 

Where is the FE behavior you describe documented?

[TomSon]

Funny, I had the same thought and just opened an issue for this.

 

Where is the FE behavior you describe documented?

 

hehe, I'd actually have to quote us both (from: http://atariage.com/forums/topic/261488-reset-sp/)

 

it's a feature of the 650x reset behavior and can be beautifully watched being init'ed on

http://visual6502.org/JSSim/

[Mr SQL]

Awesome work!

 

Is CBS RAM (Tunnel Runner) supported?

[Shawn]

Impressive.

[DirtyHairy]

At the start I randomized the start bank of hw where I believe it isn't fixed at startup but quite a few home-brews had problems - but not the old games - that I stopped this

right away. This is weird because most of those home-brews actually do have code behavior to init. themselves to a bank.

(just to name one: 'Stay Frosty' dies starting in bank 3, works in other banks (is X==bank guaranteed on harmony, maybe ?!).

 

Actuall, I am pretty sure that I have encountered historic ROMs that exhibit the same behavior during 6502.ts development, but I fail to remember any specific sample from the top of my head.

 

The harmony, when starting an ARM routine, seems to still return the last byte over and over (or zero, can't remember, but it was fixed based on expected return values) while being busy.

The Tiara doesn't - bus values are floating/semi-random. So something like Star Castles (bit 1ff4, bvc xxx) check when storing hiscores doesn't work (which is why I haven't

added storage functions so far) - it would need a presence check before.

 

The same holds true for DPC+ ARM callouts: it puts NOP on the bus while the ARM executes (although neither Stella or 6502.ts emulate this). However, I don't see how this should cause bus contention as long as the PC does not wrap around at 0xFFFF as there are no reads from the TIA or RIOT involved. Once it wraps and the 6507 starts reading TIA registers, it will crash the Tiara (if I get you correctly), but that wouldn't work on harmony either

[DirtyHairy]

Funny, I had the same thought and just opened an issue for this.

 

Where is the FE behavior you describe documented?

 

 

 

hehe, I'd actually have to quote us both (from: http://atariage.com/forums/topic/261488-reset-sp/)

 

it's a feature of the 650x reset behavior and can be beautifully watched being init'ed on

http://visual6502.org/JSSim/

 

Now you have lost me: I thought Thomas was referring to the initial state of FE banking

[TomSon]

more specific then: when reset the 650x starts with specific cycles, amongst others documented here:

 

http://www.pagetable.com/?p=410

 

so there are always accesses to (1)ff, (1)fe before accessing fffc when the 650x comes up triggering the FE bank switch hw.

[DirtyHairy]

more specific then: when reset the 650x starts with specific cycles, amongst others documented here:

 

http://www.pagetable.com/?p=410

 

so there are always accesses to (1)ff, (1)fe before accessing fffc when the 650x comes up triggering the FE bank switch hw.

 

Now I see the connection --- very interesting. However, I don't yet understand how this leads to defined startup behavior? Afaik (according to Kevin Horton's canonical document), the mapper watches the bus for a JSR or RTS, then observers the activity on the bus and finally, after the proper number of transitions, determines the bank from bit 5 of the fetched value (which is bit 13 of the new address). However, there is neither a JSR or a RTS on the bus on reset, and the values read from the stack should be random.

Edited June 3, 2017 by DirtyHairy

[alex_79]

According to the original patent by David Crane, the bankswitching (which was designed to have up to 8 banks) is triggered by monitoring the address bus for address $01fe.

 

[...] The twelve line address bus is connected

to a plurality of 4K by eight bit memories.

[...]

The eight line data bus is connected to each of the

banks of memory, also. An address comparator is

connected to the bus for detecting the presence of

the 01FE address. Actually, the comparator will detect

only the lowest 12 bits of 1FE, because of the twelve

bit limitation of the address bus. Upon detection of

the 01FE address, a one cycle delay is activated

which then actuates latch connected to the data bus.

The three most significant bits on the data bus

are latched and provide the address bits A13, A14, and

A15 which are then applied to a 3 to 8 de-multiplexer

The 3 bits A13-A15 define a code for selecting one

of the eight banks of memory which is used to enable one

of the banks of memory by applying a control signal to

the enable, EN, terminal thereof. Accordingly, memory

bank selection is accomplished from address codes on the

data bus following a particular program instruction,

such as a jump to subroutine.

[...]

activision_FE_bankswitch.pdf

[TomSon]

Awesome work!

 

Is CBS RAM (Tunnel Runner) supported?

 

yes, that is the 'FA' hardware base, just started it and tried to play

(no idea what I need to do running around in that 3D maze) but looks as expected (w/ funky colors; ntsc on my pal vcs..)

 

Reminded me of adding a picture of the info page that I forgot to mention - 'game select' in the menu brings up this page

showing what the Tiara will use for the selected binary as cartridge hardware, either determined automatically or via file ending.

I've also added and display the same checksum code as Stella uses both for a quick sanity check and to look up and display more

metadata - just filling the flash of the chip, really.

[DirtyHairy]

According to the original patent by David Crane, the bankswitching (which was designed to have up to 8 banks) is triggered by monitoring the address bus for address $01fe.

 

 

activision_FE_bankswitch.pdf

 

Thanks alot, I was not aware of the patent. The document I was referring to was Kevin Horton's bankswitching guide http://blog.kevtris.org/blogfiles/Atari%202600%20Mappers.txt , and the description there is what I quoted above. I just change the implementation inf 6502.ts to match the description in the patent, and it works fine. Makes me wonder about the accuracy of Kevin Horton's description of the other BS schemes, in particular Tigervision (see my other thread ).

Edited June 3, 2017 by DirtyHairy