Chimera Hybrid Game System

[+batari]

Not to worry, we are working on this project daily.

 

Right now, the Harmony is supporting 2k, 4k, F4/F6/F8 with or without Superchip RAM, FA (CBS RAM+), 3F, FE, E0, E7, DPC (Pitfall II), Commavid, UA, 0840, and 3E (up to 32k ROM/8k RAM). That is, all legacy bankswitching schemes up to 32k.

 

We also have the SD card driver up, and it's reading files from a normal FAT-formatted SD card, so you can drop the files on a card with a PC. Any quality SD and SDHC card should work, and it was tested with a wide variety of them. MMC cards will not be supported, however.

[brojamfootball]

Ooh! Daddy like!

[CPUWIZ]

Not to worry, we are working on this project daily.

 

Right now, the Harmony is supporting 2k, 4k, F4/F6/F8 with or without Superchip RAM, FA (CBS RAM+), 3F, FE, E0, E7, DPC (Pitfall II), Commavid, UA, 0840, and 3E (up to 32k ROM/8k RAM). That is, all legacy bankswitching schemes up to 32k.

 

We also have the SD card driver up, and it's reading files from a normal FAT-formatted SD card, so you can drop the files on a card with a PC. Any quality SD and SDHC card should work, and it was tested with a wide variety of them. MMC cards will not be supported, however.

 

This is the end, my only friend, the end.

 

Say goodbye to Atari cart collecting, if you are in it for the money! And say hello to major forgeries in your future.

[Wickeycolumbus]

Right now, the Harmony is supporting 2k, 4k, F4/F6/F8 with or without Superchip RAM, FA (CBS RAM+), 3F, FE, E0, E7, DPC (Pitfall II), Commavid, UA, 0840, and 3E (up to 32k ROM/8k RAM). That is, all legacy bankswitching schemes up to 32k.

 

I can't wait!

[+Random Terrain]

Not to worry, we are working on this project daily.

 

Right now, the Harmony is supporting 2k, 4k, F4/F6/F8 with or without Superchip RAM, FA (CBS RAM+), 3F, FE, E0, E7, DPC (Pitfall II), Commavid, UA, 0840, and 3E (up to 32k ROM/8k RAM). That is, all legacy bankswitching schemes up to 32k.

 

We also have the SD card driver up, and it's reading files from a normal FAT-formatted SD card, so you can drop the files on a card with a PC. Any quality SD and SDHC card should work, and it was tested with a wide variety of them. MMC cards will not be supported, however.

That's good news. I love how easy SD cards are to use. It's just like using a folder on your computer. I'll buy a new SD card just for the Harmony.

 

Please check your PMs. Don't get excited CPUWIZ. I said PMs, not BMs.

[dabluesman]

Not to worry, we are working on this project daily.

 

Right now, the Harmony is supporting 2k, 4k, F4/F6/F8 with or without Superchip RAM, FA (CBS RAM+), 3F, FE, E0, E7, DPC (Pitfall II), Commavid, UA, 0840, and 3E (up to 32k ROM/8k RAM). That is, all legacy bankswitching schemes up to 32k.

 

We also have the SD card driver up, and it's reading files from a normal FAT-formatted SD card, so you can drop the files on a card with a PC. Any quality SD and SDHC card should work, and it was tested with a wide variety of them. MMC cards will not be supported, however.

 

 

When it is ready for sale, will we be notified here on this thread, or somewhere else? I want to make sure I get my order in and not miss out. If possible, I want 4 (1 for me, 1 for my son, 1 for my best friend & Atari collector, and 1 for another really good friend & Atari collector). I only ordered 1 MaxiCart way back when, and I've been kicking myself ever since - I was hoping to get more for Christmas presents for my friends. I don't want to make that mistake again.

 

Thanks,

John

[mos6507]

We also have the SD card driver up, and it's reading files from a normal FAT-formatted SD card, so you can drop the files on a card with a PC. Any quality SD and SDHC card should work, and it was tested with a wide variety of them. MMC cards will not be supported, however.

 

So does that mean this is going to work like a multicart with a menu engine?

Edited May 1, 2009 by mos6507

[cd-w]

We also have the SD card driver up, and it's reading files from a normal FAT-formatted SD card, so you can drop the files on a card with a PC. Any quality SD and SDHC card should work, and it was tested with a wide variety of them. MMC cards will not be supported, however.

So does that mean this is going to work like a multicart with a menu engine?

 

Yes - the SD card menu will look something like this:

 

 

Chris

[+selgus]

We also have the SD card driver up, and it's reading files from a normal FAT-formatted SD card, so you can drop the files on a card with a PC. Any quality SD and SDHC card should work, and it was tested with a wide variety of them. MMC cards will not be supported, however.

So does that mean this is going to work like a multicart with a menu engine?

 

Yes - the SD card menu will look something like this:

 

 

Chris

That's a pretty sweet kernel for drawing text.

--Selgus

[cd-w]

That's a pretty sweet kernel for drawing text.

--Selgus

 

Unfortunately it's not entirely flicker-free, but it looks close enough on a real TV.

 

Chris

[brojamfootball]

Looks pretty sweet to me!

[Wickeycolumbus]

Stella's Stocking? Isn't that 64K?

[MausGames]

Any chance that it will skip the menu and autostart if the SD contains only one ROM?

[+batari]

Any chance that it will skip the menu and autostart if the SD contains only one ROM?

That can be done.

Stella's Stocking? Isn't that 64K?

Yes. Although the Harmony will only support 32k of conventional space, you can use the EEPROM to load code/data if you don't mind a slight delay. A game like SS that is really a bunch of smaller games could theoretically fit this way.

Edited May 5, 2009 by batari

[MausGames]

Will bB be able to directly access and load from sd? It would be great to be able to retrieve data from the sd slot in a bB project, I can think of some uses, even if the space that could be accessed were extremely limited. Is it even possible to read from seperate files loaded onto the eeprom from within a bin? Also, will bB support 64k games now?

Edited May 12, 2009 by MausGames

[Mark Wolfe]

Not to worry, we are working on this project daily.

 

Right now, the Harmony is supporting 2k, 4k, F4/F6/F8 with or without Superchip RAM, FA (CBS RAM+), 3F, FE, E0, E7, DPC (Pitfall II), Commavid, UA, 0840, and 3E (up to 32k ROM/8k RAM). That is, all legacy bankswitching schemes up to 32k.

 

We also have the SD card driver up, and it's reading files from a normal FAT-formatted SD card, so you can drop the files on a card with a PC. Any quality SD and SDHC card should work, and it was tested with a wide variety of them. MMC cards will not be supported, however.

 

This is the end, my only friend, the end.

 

Say goodbye to Atari cart collecting, if you are in it for the money! And say hello to major forgeries in your future.

 

 

say wuh? How do you figure this? That is like saying the invention of the scanner and color printer makes collecting art obsolete because anyone can print out a masterpiece and hang it on their wall.... complete nonsense.

 

major forgeries? of what? atari carts? How exactly would this precipitate forgeries any more than we have already? seems to me they'd be much easier to detect.

Edited May 12, 2009 by Mark_Wolfe

[mos6507]

Will bB be able to directly access and load from sd? It would be great to be able to retrieve data from the sd slot in a bB project, I can think of some uses, even if the space that could be accessed were extremely limited. Is it even possible to read from seperate files loaded onto the eeprom from within a bin? Also, will bB support 64k games now?

 

The big difference between Chimera and Harmony is that in Chimera the banking formats were handled by a CPLD. The CPLD also created what we called the "super wide bus" which was the way that the ARM saw the 2600 and the shared static RAM. In Harmony, as far as I know, the ARM is still directly connected to the 2600. No CPLD or SRAM. Any 2600 game code is actually getting fed to the 2600 cycle by cycle via the ARM. This leaves the ARM with limited processor availability. Even though the ARM is many times faster than the 2600, if it attempts to do too much in the time gaps between its ROM emulation, then it will surely crash the 2600.

 

One of the features of Chimera was it being able to reprogram the CPLD on the fly. Doing this while the 2600 runs would be equivalent to unplugging or jiggling a cart. Not good. To do this, the 2600 would jump to RAM for a fixed amount of time, and then jump back out again. While it's in RAM it's not looking at the bus so whatever is going on there is irrelevant. The same sort of thing could surely be done with Harmony. Of course there isn't very much you can do in 128 bytes besides very simple kernels while you wait for the ARM to finish its task. However, if the ARM were fast enough you might be able to run subroutines during VBLANK or right after a WSYNC and before the next line starts. So there might be some potential still to utilize the ARM for new games.

 

That's something I'm pretty keen on now that Chimera is all but dead.

[+batari]

Will bB be able to directly access and load from sd? It would be great to be able to retrieve data from the sd slot in a bB project, I can think of some uses, even if the space that could be accessed were extremely limited. Is it even possible to read from seperate files loaded onto the eeprom from within a bin? Also, will bB support 64k games now?

It should be theoretically possible for 2600 games (bB included) to read a file from the SD card and use it.

 

For practicality, load size should be limited to 2k at a time so data can be loaded into the SRAM, which can be rewritten infinitely. You could in theory load onto flash for more than 2k but that's not advisable unless it's done occasionally.

 

Loading from an SD card will take a few frames so the 2600 will need to be stalled. It should only be done for loading a new level, for instance.

 

Alternatively, it might be possible to load a game onto the onboard EEPROM, which could load larger files and do it more quickly.

The big difference between Chimera and Harmony is that in Chimera the banking formats were handled by a CPLD. The CPLD also created what we called the "super wide bus" which was the way that the ARM saw the 2600 and the shared static RAM. In Harmony, as far as I know, the ARM is still directly connected to the 2600. No CPLD or SRAM. Any 2600 game code is actually getting fed to the 2600 cycle by cycle via the ARM. This leaves the ARM with limited processor availability. Even though the ARM is many times faster than the 2600, if it attempts to do too much in the time gaps between its ROM emulation, then it will surely crash the 2600.

 

One of the features of Chimera was it being able to reprogram the CPLD on the fly. Doing this while the 2600 runs would be equivalent to unplugging or jiggling a cart. Not good. To do this, the 2600 would jump to RAM for a fixed amount of time, and then jump back out again. While it's in RAM it's not looking at the bus so whatever is going on there is irrelevant. The same sort of thing could surely be done with Harmony. Of course there isn't very much you can do in 128 bytes besides very simple kernels while you wait for the ARM to finish its task. However, if the ARM were fast enough you might be able to run subroutines during VBLANK or right after a WSYNC and before the next line starts. So there might be some potential still to utilize the ARM for new games.

 

That's something I'm pretty keen on now that Chimera is all but dead.

It has been demonstrated that the ARM can stall the 2600 using a variety of methods. For example, a Supercharger multiload (provided multiloads are in internal flash and just need to be copied to internal SRAM) works by JMPing to $F000 and placing a NOP instruction on the 2600's data bus, which will keep it busy for up to 6.8 ms, which is about how long it takes the 2600 to execute until $FFFF. The multiload completes well before that, however - by my estimate it takes less than 2 ms. It should also be possible to store a multiload game on the onboard EEPROM, and multiloads could be accessed from there. It's not clear yet if these loads could be completed in 6 ms, but this stalling can be "refreshed" by inserting JMP $F000 as long as it's done about every 6 ms.

 

For stalling longer than about 6 ms where it can't be refreshed, the ARM must feed instructions to fill the 2600's RIOT RAM with a short routine, and jump there. This is how SD card access is handled. For loading the menu, the stall time is on the order of 100 ms, so it's just a brief flash on the screen (though we do have a mini-kernel that displays a spinner on the screen.) It may be longer when there are a lot of files on the card, but it probably won't be excessive. The Harmony will have a bootloader that contains this stall code, and so it will always be available.

 

As for coprocessing, that may be accomplished using a NOP-feeding method. VBLANK time is far less than 6 ms, so no refreshing of the stall will be needed.

Edited May 12, 2009 by batari

[mos6507]

Just to get this out of the way. We may want to start a new thread for Harmony. There is something a little depressing about using this thread for it. Edited May 15, 2009 by mos6507

[Wickeycolumbus]

Just to get this out of the way. We may want to start a new thread for Harmony. There is something a little depressing about using this thread for it.

 

 

I was looking forward to both the Chimera and Harmony. I hope all is well with Delicon, and he comes back some day!

[ovalbugmann]

Just to get this out of the way. We may want to start a new thread for Harmony. There is something a little depressing about using this thread for it.

 

I read your last blog entry mos and I am sad that the Chimera project is dead and that delicon, who was vital to the project is quite unreachable.

 

Well, I will be looking forward to the Harmony cart then, I'm sure it will suffice as all I have is a SC.

 

Thanks for what you did with the project.