Chimera Hybrid Game System

[shadow460]

What we really need is a multicart that is available on a continuous basis. When developing a game, it is necessary to test the game on real hardware to know if it works or not. Bugs do not always show up in an emulator. A supercharger is not the handiest device for doing this. The .bin file would have to somehow be converted into a sound file and then it would have to somehow be transferred to the supercharger. This would require more hardware and expertise than I currently have. My Krokodile cart works great, but what if it dies? There are no more available. I was hoping to pick up a Chimera cart as a backup for my Krok cart. I'm not interested in extra ram, I just want to be able to test .bin files on actual hardware. In my opinion, a standard multicart would be a great benefit to the Atari community for 2600 development.

 

wplaybin plays back .bin files as audio. All you do is hook up the Supercharger and double click the .bin.

 

Still, you're limited to 6K, which means unless you're programming the game your practical limit is actually 4K. Someone posted that it could be increased to 8K. I'd really like to know how that's done.

[mos6507]

There seems to be plenty of support out here in the community for the Chimera project, maybe there's someone willing/able to provide some support beyond just the moral support that I can offer.

 

The way the evolution of the cart has gone has followed this path:

 

Board Design > CPLD code > ARM firmware

 

The problem is all the dependencies. Changing the board causes a ripple effect downstream. We have to build the whole "stack" up before we can really validate the architecture as a whole. Along the way new ARM chips have come out and that's why we had to (or were enabled to) increase the bus size between the ARM and the CPLD, enabling a faster response time for queues. That in turn made the difference between being able to read the queues one after the other or throwing in mandatory NOPs inbetween. The way the CPLD talks to the ARM also makes a big difference. You have x amount of pins to work with, but beyond that, a lot of latitude in designing the bus. But just to try stuff out you need to redo the CPLD and the ARM. Lastly, the ARM code has to respond fast enough without hanging, etc... So Delicon has had to keep this balancing act between changing the board layout, changing the CPLD, and changing the ARM code. Eventually each revision came closer and closer to delivering the goods before hitting some final dead end so we knew we were moving in the right direction. The last one only needs some pin reassignments to enable reliable paddle reads. The core circuit layout should be good to go. The CPLD layout should be pretty close to done, and it's mostly ARM firmware at this point. But that's not to say it's easy, because we were still battling some queue glitches. I just wanted to emphasize the positive on my blog site but we were not free and clear yet.

 

What I'm trying to say here is that as far as an engineering task, Chimera is probably not that different from the task of making an entire new videogame console from the ground up. It has its own CPU. It has memory. It has firmware. It has peripherals. It has a way to load games (no cart slot per se). It is intended to provide video and audio features, although they have to be served up through the host VCS code reading out the queues. It could even run the main game logic from RAM, although in practice this probably wouldn't happen being things like the system menu.

 

If someone just wanted a way to load games for testing, Delicon has a simplified board design that he's given to AtariAge that might work for that. That board design is intended to be a single universal way to preload homebrew games for the store during packaging. That was also the purpose of Chimera, but Chimera was intended to facilitate much more expansive games, not simple 4-16K banked ROMs. In the stripped down architecture there is no CPLD. The ARM runs a software simulation of the various banking schemes, therefore it is completely busy 100% doing that. That approach never appealed to me because it makes it impossible to do modular games, in-game peripherals, queues, or other coprocessor functions, however, it's a simpler, cheaper design using a cheaper ARM variant. I just don't know how convenient that would be use in an iterative development cycle. I think it does everything up to supercharger single loads. But it's not a multicart. It would only hold one game at a time, kind of like a stripped down Cuttle Cart 1 that holds onto the code you load into it.

Edited January 3, 2009 by mos6507

[accousticguitar]

If someone just wanted a way to load games for testing, Delicon has a simplified board design that he's given to AtariAge that might work for that. That board design is intended to be a single universal way to preload homebrew games for the store during packaging. That was also the purpose of Chimera, but Chimera was intended to facilitate much more expansive games, not simple 4-16K banked ROMs. In the stripped down architecture there is no CPLD. The ARM runs a software simulation of the various banking schemes, therefore it is completely busy 100% doing that. That approach never appealed to me because it makes it impossible to do modular games, in-game peripherals, queues, or other coprocessor functions, however, it's a simpler, cheaper design using a cheaper ARM variant. I just don't know how convenient that would be use in an iterative development cycle. I think it does everything up to supercharger single loads. But it's not a multicart. It would only hold one game at a time, kind of like a stripped down Cuttle Cart 1 that holds onto the code you load into it.

If it could load any binary from 2k-16k that would be great from a development standpoint (if it wasn't too hard to load, like say a krok cart). And it's already done, wow! How much would that cost to produce? The only problem I could see with it is how many people would want it since it isn't a multicart. On the other hand, there really isn't any alternative available since krok carts and Cuttle carts are no longer being produced. My guess is that it would sell because of that lack of an alternative, especially if the selling price were under $50.

[+selgus]

If someone just wanted a way to load games for testing, Delicon has a simplified board design that he's given to AtariAge that might work for that. That board design is intended to be a single universal way to preload homebrew games for the store during packaging. That was also the purpose of Chimera, but Chimera was intended to facilitate much more expansive games, not simple 4-16K banked ROMs. In the stripped down architecture there is no CPLD. The ARM runs a software simulation of the various banking schemes, therefore it is completely busy 100% doing that. That approach never appealed to me because it makes it impossible to do modular games, in-game peripherals, queues, or other coprocessor functions, however, it's a simpler, cheaper design using a cheaper ARM variant. I just don't know how convenient that would be use in an iterative development cycle. I think it does everything up to supercharger single loads. But it's not a multicart. It would only hold one game at a time, kind of like a stripped down Cuttle Cart 1 that holds onto the code you load into it.

 

Can you give any additional information about this simplified board? It sounds like he has already produced it and was in use. This sounds like it could be a useful board in it's own right.

--Selgus

[+batari]

The simplified board will be released. Delicon did the board layout and built our current prototype, and I wrote the firmware. There will be two versions - one with minimal hardware for AA to release homebrews, and one with a few extra components for developers. The working name of the new cart is the Harmony cart.

 

It will support up to 32k, and supports any RAM scheme up to about 6k. This means that you can release things like Superchip, E7, CBS, 3E and even Supercharger games, with or without multiloads, all on a cart.

 

The developer board will plug into a USB slot and use programming software (written by me) to program the board. You can leave the board plugged into a 2600 during development, and we (Supercat and I) are working out a way to auto-reboot the device when a new binary is loaded.

 

I have had to take over layout of the latest prototype as Delicon is currently on hiatus, but I'm just expanding on his original work so it's not too difficult so far. If the latest prototype works, it should be ready for production.

 

Note that this board is currently NOT a multicart, so you currently need to load a single game at a time, like the original CC. Well, I should mention that we have added a serial EEPROM footprint to the board. Although the EEPROM was more intended for single homebrews, for things like large Supercharger multiloads, it may allow some multicart capabilities, if nothing else, a bunch of 4k games. But whether this will actually work is unknown at this point, and I can't make any promises.

[accousticguitar]

Cool!

[+selgus]

The simplified board will be released.

This seem to be exactly what I was thinking about. I am sure there are a few developers that would be very interested in this board. Looking forward to picking one of these up.

--Selgus

[Foster]

This is good to hear Batari!!

[+Random Terrain]

The Chimera cart has features I want that this new thing doesn't have, but this new thing seems like it will be faster and easier to use than the Krok cart for testing games, so I'll probably buy one.

[Mirage]

The Chimera cart has features I want that this new thing doesn't have, but this new thing seems like it will be faster and easier to use than the Krok cart for testing games, so I'll probably buy one.

 

I keep hearing people say things like this. I've been using my Krok cart for years. I just can't imagine it being much simpler.

[mimo]

I was just looking forward to a multicart for my 2600s

[+Random Terrain]

The Chimera cart has features I want that this new thing doesn't have, but this new thing seems like it will be faster and easier to use than the Krok cart for testing games, so I'll probably buy one.

I keep hearing people say things like this. I've been using my Krok cart for years. I just can't imagine it being much simpler.

It should be glaringly obvious how other products could be easier to use, but I'll try to explain for the imagination impaired.

 

1. A Chimera cartridge and a miniSD card would be great for those who can't have an Atari 2600 near their computer. That's not the only great thing about the Chimera cartridge, but it's one of the great things if you want to test your own games far away from your computer or if you want to have others test your games in another room on a different Atari 2600. If you have a few Atari 2600s and a few Chimera cartridges to go with them, others can be testing your games or playing your finished games. Since the Chimera cartridge was supposed to be affordable and there were going to be more than enough for everyone, it's a better deal than the Krok cart. Just put your game or games on a miniSD card and take it to a Chimera cartridge sitting in an Atari 2600 and you're ready to go. No unplugging a Krok cart and hooking it up to cables.
   _
   
2. If you have the space to have an Atari 2600 and a small TV hooked up near your computer, you cannot leave the Krok cart and cables plugged in. You're supposed to take the Krok cart out of the Atari 2600 to avoid damaging the Atari. If you can afford to buy a new Atari 2600 any time you want, it may not be a big deal if you fry an Atari 2600 or two, but many of us have to be more careful. If I read the post correctly, the product that batari mentioned will be able to stay plugged in. So if you have room for a TV and an Atari 2600 near your computer, the product that batari mentioned should be easier to use than a Krok cart.
   

 

From miniSD cards to never having to plug and unplug carts and cables, it should now be clear how these other products would be easier to use than a Krok cart.

[Kroko]

I keep hearing people say things like this. I've been using my Krok cart for years. I just can't imagine it being much simpler.

I have designed the Krokodile as a developer cart and I wanted to be able to do the following:

 

1. Start the compile script (which also starts the downloading to the cart)

2. Cycle the power switch on the 2600

=> Done.

 

With a card based solution I would have had to do the following:

 

1. Unplug the card from the cartridge (which may or may not be easy depending on the connector)

2. Plug it into the card reader

3. Compile and transfer to the card (a script can also do that in 1 step)

4. Unplug the card from the reader

5. Plug it into the cart

6. Power cycle the 2600.

 

The cable based solution has also some disadvantages. E.g. you need to have the cable connected

and a PC next to the 2600. In addition there is a 0.001% risk to damage the 2600.

 

Well I had no doubt which way to go. Do both of the above steps 50 times and then decide.

Of course the best solution is to have both available like CC2 and Chimera.

 

I hope Vern will be back at work soon

[+Nathan Strum]

I've been perfectly happy with my Krok Cart. I've done a lot of testing of games with it and it's never once killed me having it in a different room than where my computer is. Now that it's out of production though, an alternative will be nice to have.

[BigO]

I keep hearing people say things like this. I've been using my Krok cart for years. I just can't imagine it being much simpler.

I have designed the Krokodile as a developer cart and I wanted to be able to do the following:

 

1. Start the compile script (which also starts the downloading to the cart)

2. Cycle the power switch on the 2600

=> Done.

 

With a card based solution I would have had to do the following:

 

1. Unplug the card from the cartridge (which may or may not be easy depending on the connector)

2. Plug it into the card reader

3. Compile and transfer to the card (a script can also do that in 1 step)

4. Unplug the card from the reader

5. Plug it into the cart

6. Power cycle the 2600.

 

The cable based solution has also some disadvantages. E.g. you need to have the cable connected

and a PC next to the 2600. In addition there is a 0.001% risk to damage the 2600.

 

Well I had no doubt which way to go. Do both of the above steps 50 times and then decide.

Of course the best solution is to have both available like CC2 and Chimera.

 

I hope Vern will be back at work soon

 

For Krok 2, Chimera or any other such intelligent development device that requires a power cycle: include a relay or power transistor under control of the CPU in the cartridge and pass the power through the cart so it can "reboot" the 2600 if a hard power cycle really is necessary? As master of the power source, tt could sustain power to its own circuitry as needed.

 

Would it be possible to have a small "boot" program that could be executed to clear the RAM and registers in the 2600 then pass control back to wherever (beginning of the ROM image)? Clear (more likely random bits) RAM, and defaulted registers and PC is theoretically all the power cycle on a 2600 achieves, there not being any system BIOS to execute.

[+batari]

I keep hearing people say things like this. I've been using my Krok cart for years. I just can't imagine it being much simpler.

I have designed the Krokodile as a developer cart and I wanted to be able to do the following:

 

1. Start the compile script (which also starts the downloading to the cart)

2. Cycle the power switch on the 2600

=> Done.

 

With a card based solution I would have had to do the following:

 

1. Unplug the card from the cartridge (which may or may not be easy depending on the connector)

2. Plug it into the card reader

3. Compile and transfer to the card (a script can also do that in 1 step)

4. Unplug the card from the reader

5. Plug it into the cart

6. Power cycle the 2600.

 

The cable based solution has also some disadvantages. E.g. you need to have the cable connected

and a PC next to the 2600. In addition there is a 0.001% risk to damage the 2600.

 

Well I had no doubt which way to go. Do both of the above steps 50 times and then decide.

Of course the best solution is to have both available like CC2 and Chimera.

 

I hope Vern will be back at work soon

 

For Krok 2, Chimera or any other such intelligent development device that requires a power cycle: include a relay or power transistor under control of the CPU in the cartridge and pass the power through the cart so it can "reboot" the 2600 if a hard power cycle really is necessary? As master of the power source, tt could sustain power to its own circuitry as needed.

 

Would it be possible to have a small "boot" program that could be executed to clear the RAM and registers in the 2600 then pass control back to wherever (beginning of the ROM image)? Clear (more likely random bits) RAM, and defaulted registers and PC is theoretically all the power cycle on a 2600 achieves, there not being any system BIOS to execute.

The Chimera can support either a cable connection or SD card. If doing a cable connection, it would not require a power cycle - just step 1 of Kroko's procedure is needed. We are trying to do the same with the Harmony cart. I think it will work.

 

The Harmony cart also has a SD-card interface. It's not clear if we'll be able to make it work acceptably well, however, as so don't get your hopes up.

[+selgus]

The Harmony cart also has a SD-card interface. It's not clear if we'll be able to make it work acceptably well, however, as so don't get your hopes up.

Do you guys have any estimated timeframe for the Harmony cart? I was under the impression this cart was already in use by some people?

--Selgus

[+Random Terrain]

The Harmony cart also has a SD-card interface. It's not clear if we'll be able to make it work acceptably well, however, as so don't get your hopes up.

Whether you want our hopes up, down, or sideways, it's still nice to know that it might be possible.

[+batari]

The Harmony cart also has a SD-card interface. It's not clear if we'll be able to make it work acceptably well, however, as so don't get your hopes up.

Do you guys have any estimated timeframe for the Harmony cart? I was under the impression this cart was already in use by some people?

--Selgus

This is a very early version:

This is the first prototype:

This is a mockup of the current board (optional stuff unpopulated:)

This is a teaser to be sure, and I'm only posting this to encourage myself to work on it some more

[roland p]

The Harmony cart also has a SD-card interface. It's not clear if we'll be able to make it work acceptably well, however, as so don't get your hopes up.

Do you guys have any estimated timeframe for the Harmony cart? I was under the impression this cart was already in use by some people?

--Selgus

This is a very early version:

This is the first prototype:

This is a mockup of the current board (optional stuff unpopulated:)

This is a teaser to be sure, and I'm only posting this to encourage myself to work on it some more

Nice! Looks like the holy grail for homebrews!

Is the microcontroller is a self-programming one?

[+selgus]

This is a teaser to be sure, and I'm only posting this to encourage myself to work on it some more

Well I do hope this one makes it out in the wild one day soon...

--Selgus

[+batari]

Nice! Looks like the holy grail for homebrews!

Is the microcontroller is a self-programming one?

Yes, the microcontroller can program its own flash through user code.

 

In theory, one could burn multicart code to the flash, and the cart would boot to a selection screen which would read a file list from a SD card. Once a game was selected, it would then proceed to read that self-program the unused portion of the flash.

 

The multicart code would probably not support some bankswitching methods, because some code would need to permanently reside on the flash, and space may get tight on the flash because it also holds the bankswitch code and 2600 binary. If using cable programming, you would not need the multicart code so that wouldn't be an issue.

 

The flash has a guaranteed lifetime of 100,000 cycles, so you could play 100,000 games on a multicart version before it might fail. That's 10 different games a day for 27 years, so it's unlikely you'd run into that.

 

This is all a programming exercise at this point. In theory, it should work, but we'll see.

[yuppicide]

Sexy, bAtari. Damn sexy. Not you, the cartridge teaser.

[roland p]

The multicart code would probably not support some bankswitching methods, because some code would need to permanently reside on the flash, and space may get tight on the flash because it also holds the bankswitch code and 2600 binary. If using cable programming, you would not need the multicart code so that wouldn't be an issue.

Well, nice work.

The microcontroller will be very busy... I guess: detecting address changes> check for bankswitching address> address flash rom> put data on the data bus. All within the time the vcs expects new data...

Have you got a working prototype of this?

[+batari]

The multicart code would probably not support some bankswitching methods, because some code would need to permanently reside on the flash, and space may get tight on the flash because it also holds the bankswitch code and 2600 binary. If using cable programming, you would not need the multicart code so that wouldn't be an issue.

Well, nice work.

The microcontroller will be very busy... I guess: detecting address changes> check for bankswitching address> address flash rom> put data on the data bus. All within the time the vcs expects new data...

Have you got a working prototype of this?

Yes, the microcontroller is doing a lot of work in between cycles. It took me a long time to get it working, but it does work. However, the 6507 is fairly forgiving and flexible about timing. The microcontroller runs at 70 Mhz, so you have about 58 cycles of microcontroller code per 2600 cycle. This of course means that you must write 100% assembly code for the microcontroller and write it efficiently.