OmniAtari

[applekevin]

OK Just wondering why isn't it possible to make an Atari Flashback 3 that would have a 2600/7800 and an Atari 8-Bit/5200 that would share all possible chips and have the different ports. I just don't see why that's so difficult! Maybe I'm an idiot but still who doensn't want that? I mean I'm willing to pay $60-80 for that. Or atleast make a 2600/5200/7800! Please explain

[jaybird3rd]

http://www.atariage.com/forums/index.php?s...t&p=1172508

 

http://www.atariage.com/forums/index.php?s...st&p=966620

[Uzumaki]

2600/7800 was possible because half of the hardware were the same. But 8 bit/5200 are quite different and it would be rather messy to try and integrate those.

 

It'd be easier to superglue a 7800 on top of the 5200 and tie together the power supply input and video output.

[Curt Vendel]

Look at the 2600 VCS adapter on the 5200... it was a full Atari 2600, you simply plugged it into the cartridge slot of the 5200 where it received power from the console and pushed its video/audio out through the cartridge connector and out of the 5200's RF lead, but essentially it and the 5200 had ZERO interaction, they were two completely separate entities.

 

 

So....

 

With that, you'd essentially have to the same thing, you'd have a combo 2600/7800 all in one chip and an Atari 8bit all in one chip both sharing the same video summation circuitry. With some glue logic you could then have a firmware program display a mode selection on the screen to choose which mode the system should be in and/or have a header inserted into each BIN that would designate 2678 or 5200 and the firmware/housekeeping software running with the glu logic would then determine the "type" of code to run and which "mode" the system should come up as. Then the system would put that particular chipset onto the bus and access the controller ports, memory and video/audio lines - boot up and you're ready to play...

 

 

Could be done, would be a little bit expensive - but definitely doable.

 

 

 

 

Curt

 

 

2600/7800 was possible because half of the hardware were the same. But 8 bit/5200 are quite different and it would be rather messy to try and integrate those.

 

It'd be easier to superglue a 7800 on top of the 5200 and tie together the power supply input and video output.

Edited December 22, 2006 by Curt Vendel

[applekevin]

Ok I see why. I was thrown off because someone told me that the 2600 and 5200 had the same chip. Oh well. However there is always emulation. Yes I know that the flashback 1 emulated and it was bad but wut if you used a remake of the atari st series. you could include all of the ports for joysticks and cartridges and simply emulate it. That way you could easily play 2600 5200 7800 A8 and ST games.

 

What do ya think? I love the ST games!

[jaybird3rd]

Ok I see why. I was thrown off because someone told me that the 2600 and 5200 had the same chip. Oh well. However there is always emulation. Yes I know that the flashback 1 emulated and it was bad but wut if you used a remake of the atari st series. you could include all of the ports for joysticks and cartridges and simply emulate it. That way you could easily play 2600 5200 7800 A8 and ST games.

 

What do ya think? I love the ST games!

The 2600 and 5200 used more or less the same CPU (the 6502, minus a few address lines on the 2600), but nothing else about them was the same. And even the fastest ST wasn't powerful enough to accurately emulate the 2600/7800 or the 5200, at least not at full speed, and it didn't have compatible cartridge slots. Edited December 23, 2006 by jaybird3rd

[applekevin]

I know that it didn't have those slots but you could add them in this hypothetical remake. Also you could just make it a little faster.

[ijor]

With that, you'd essentially have to the same thing, you'd have a combo 2600/7800 all in one chip and an Atari 8bit all in one chip both sharing the same video summation circuitry... Then the system would put that particular chipset onto the bus ...

Could be done, would be a little bit expensive - but definitely doable.

 

You actually don't need to have separate chips, just separate cores and reconfigure the FPGA on the fly. That wouldn't work of course for SOC/ASIC, but for an FPGA based design, the additional cost wouldn't be much more than some extra ROM.

 

And if you go that far, then you can add as much cores as you want, again just by increasing ROM size. Technically, you don't even need to restrict yourself to Atari, you could put a C64 core, a Spectrum core, or whatever. A multi-brand product would probably involve some legal challenges. But you can delegate this complication to the user, just provide whatever core(s) you can, and let the user add the rest.

 

The whole concept might not be the best commercial wise, but that's a different story.

Edited December 23, 2006 by ijor

[Retro Rogue]

Yes I know that the flashback 1 emulated and it was bad but wut if you used a remake of the atari st series.

 

Flashback 1 didn't emulate, it was based on a "NES on a chip" with the 2600 games ported over.

[Uzumaki]

Hmmm... a FPGA based flashback that can play actual C64, Vic 20, TI-99, Coco, PCjr, Adam, Atari 2600, 5200, 7900, 7800, XE, Intellivision, COlecovision, Odyssey^2, Miucrovision, Arcadia, Fairchild Channel F, Adventurevision, Apple II, and did I miss anything pre NES era consoles?

 

That would go a long way toward making lots of room in my room.

 

 

Yes I know I'd be asking for near impossible especially with a few listed consoles like Inty (GI ROMs) and Microvision (built in display)

[atwwong]

Hmmm... a FPGA based flashback that can play actual C64, Vic 20, TI-99, Coco, PCjr, Adam, Atari 2600, 5200, 7900, 7800, XE, Intellivision, COlecovision, Odyssey^2, Miucrovision, Arcadia, Fairchild Channel F, Adventurevision, Apple II, and did I miss anything pre NES era consoles?

Is the Vectrex considered a pre-NES era console? That may add a world of hurt to this already loaded omnisystem.

[ijor]

Hmmm... a FPGA based flashback that can play actual C64, Vic 20, TI-99, Coco, PCjr, Adam, Atari 2600, 5200, 7900, 7800, XE, Intellivision, COlecovision, Odyssey^2, Miucrovision, Arcadia, Fairchild Channel F, Adventurevision, Apple II, and did I miss anything pre NES era consoles?

 

It is likely that sooner or later something like that will eventually happen. Possibly not as a commertial product. May be not all of them, may be also with some 16-bit consoles/computers cores. But I don't see any reason why this won't, eventually, happen.

[Uzumaki]

Or a modern PC with software emulation, multiple IO cards for cart connectors and controller connectors, etc.

 

Yes not the same thing but it's still hard to properly clone 20 years old hardware like the TIA and Maria chips, the Intellivision GI ROM, Vectrex's vector display, etc.

[mos6507]

A cart connector is a direct wiring between the native CPU and the media. The program runs out of ROM. An emulated system can not offer true cartridge support because the native CPU of an emulator would not match the signal and timing characteristics of a cartridge. Any attempt to overcome this mismatch isn't worth the effort vs. just running ROM images. So if something like that had a cart slot, it would probably just be a cart dumper.

[mos6507]

You actually don't need to have separate chips, just separate cores and reconfigure the FPGA on the fly.

And if you go that far, then you can add as much cores as you want, again just by increasing ROM size.

 

There are significant up-front R&D costs in making these cores. If you attempt to skirt around this by making the platform "open" then look at the history of the Commodore 1. The variety of cores for that is extremely disappointing. Part of that has to do with the cost of that board. FPGAs don't have the setup costs of ASICs, but when averaged over the total units made, I think FPGAs would be cost-prohibitive for FB.

 

I think programmable logic is extremely exciting, but probably best reserved for small-gate-count hobby devices (like multicarts) where they reach a sweet-spot in value.

[nathanallan]

Yep. I was pretty disappointed with the C1. I was actually hoping to see it on the market and being bought. I kept in touch with Jens and Jeri for a long time and stayed on the mailing list but it's now a hobby item only, seems like.

[+karri]

Yep. I was pretty disappointed with the C1. I was actually hoping to see it on the market and being bought. I kept in touch with Jens and Jeri for a long time and stayed on the mailing list but it's now a hobby item only, seems like.

 

In my opinion emulation is the way to go for running lots of different CPU's on one host. My personal favourite is the Sony PSP when it is enabled to run homebrew. It emulates the Atari Lynx better than any Windows machine due to the fact that the sound engine on Windows sucks.

 

The problem with emulation is that when you emulate chips you have to output the waveforms on the fly. Windows is optimized to stream out music that is created in advance. The Sony PSP is better in this aspect.

 

From a programmers point of view it would be great to have asic-hardware that can do sound and graphics on the screen in real time with no delays. If OmniAtari is created at some point in time it should support Lua, play out midi files and perhaps be compatible with numerous toolkits that make porting games to it easy.

 

Personally I am also very fond of the cc65.org linker that understands bank switching. It allows you to segment the program you want to run into small pieces. In this way you can run a 256k program in 64k of memory without much problems.

 

--

Karri

[ijor]

Software emulation is great, and I love it. But it is not the same as the real thing. At least is is not for many people (otherwise we wouldn't be talking about FB3, would we?).

 

It probably won't ever be as the real thing. There are issues that are (almost) impossible to solve with software emulation. A hardware clone might not be exactly like the real thing, but it is (or at least, it could be) much closer.

 

The problem with emulation is that when you emulate chips you have to output the waveforms on the fly. Windows is optimized to stream out music that is created in advance. The Sony PSP is better in this aspect.

 

This is indeed a problem on the later versions of Windows. Now everything goes through a software mixer, and then DirectSound is not really Direct anymore as it used to be. But you can bypass the mixer if you want using a technique called Kernel Streaming. And then you get very low lattency. But this has several complications and is not portable across all versions of Windows (I understand it doesn't work on Vista).

 

Yes not the same thing but it's still hard to properly clone 20 years old hardware like the TIA and Maria chips, the Intellivision GI ROM, Vectrex's vector display, etc.

 

It is of course not easy. But why you think it is harder than implementing software emulation? It is not.

 

You actually don't need to have separate chips, just separate cores and reconfigure the FPGA on the fly. And if you go that far, then you can add as much cores as you want, again just by increasing ROM size.

 

There are significant up-front R&D costs in making these cores.

 

I don't think so. Implementing software emulation from scratch would require much more R&D costs than developing a chipset clone. And the up-front R&D costs are almost the same for one fixed core than for multiple ones. You don't need to develop all the cores in advance. You can release a product based in one or two cores (which you need to develop anyway), and you can upgrade/add cores later anytime you want.

 

If you attempt to skirt around this by making the platform "open" then look at the history of the Commodore 1. The variety of cores for that is extremely disappointing.

 

They might be poor implementations right now. This doesn't mean they will always be like that. These cores are just not mature enough. If you would use now the first generation software emulators you would be even more disappointed. It took quite some time until software emulation reached the accuracy we have now.

 

The cost of that board might be significant. But I don't think this is because it is open or FPGA based.

 

FPGAs don't have the setup costs of ASICs, but when averaged over the total units made, I think FPGAs would be cost-prohibitive for FB.

 

I think programmable logic is extremely exciting, but probably best reserved for small-gate-count hobby devices (like multicarts) where they reach a sweet-spot in value.

 

There are tons of commertial products based on FPGAs. The difference in production cost is not that big. Of course, if you are making a product such as a PCI modem, then every cent you save in production is significant.

 

Actually, I understand that FB3 is(was) supposed to be based on an FPGA. Are the FB1/2 ASIC based?

[mos6507]

In my opinion emulation is the way to go for running lots of different CPU's on one host. My personal favourite is the Sony PSP when it is enabled to run homebrew. It emulates the Atari Lynx better than any Windows machine due to the fact that the sound engine on Windows sucks.

 

The problem with emulation is that when you emulate chips you have to output the waveforms on the fly. Windows is optimized to stream out music that is created in advance. The Sony PSP is better in this aspect.

 

 

I can attest to that. I am disappointed in the crackling sound that seems to always afflict emulators on Windows.

[mos6507]

It is of course not easy. But why you think it is harder than implementing software emulation? It is not.

 

You must have never burned out a programmable logic chip before.

 

I don't think so. Implementing software emulation from scratch would require much more R&D costs than developing a chipset clone.

 

I think there are more software guys out there who can write emulators than circuit designers who can recreate a chipset from schematics.

 

They might be poor implementations right now. This doesn't mean they will always be like that. These cores are just not mature enough. If you would use now the first generation software emulators you would be even more disappointed. It took quite some time until software emulation reached the accuracy we have now.

 

Just because you can post core patches after the fact doesn't mean you should rely on it by releasing a poorly tested, half-baked product.

 

 

There are tons of commertial products based on FPGAs.

 

Could you cite some? We're talking about FPGAs with a gate count sufficient to do this job in which the retail price of the finished product itself isn't more than $30.

[ijor]

You must have never burned out a programmable logic chip before.

 

I did. Although I do admit I don't have as much experience developing on PL than on system software. It is still quite obvious to me that it is harder to develop software emulation than hardware cloning.

 

Let's take the case of emulating/cloning the sound and timers of Pokey. It is rather simple to clone by hardware. I am not saying it is trivial or that I could do it in a matter of minutes, but it is not a huge task. OTOH, it took many years for software emulators to reach a high level of accuracy, and even now it is still not perfect and some features are not actually implemented.

 

Or let's talk about emulating the whole A8 hardware. Do you realize how many human hours took to make Atari800 what it is now (and again, it is still not 100% accurate)? For sure it wouldn't take the same time for developing a hardware clone like the FB3, because otherwise it wouldn't be a viable commercial project at all!

 

I think there are more software guys out there who can write emulators than circuit designers who can recreate a chipset from schematics.

 

This is very true. It changed a lot lately with the advent of low cost FPGA dev kits, cheaper logic analyzer, etc. But what you say it is still very true.

 

This doesn't change the fact that (IMHO) it takes much more R&D time in developing software emulation than a hardware clone. It does mean that hiring software programmers might be cheaper. But I doubt this could offset the much higher number of human hours that it would involve (again, if you start from scratch).

 

Could you cite some? We're talking about FPGAs with a gate count sufficient to do this job in which the retail price of the finished product itself isn't more than $30.

 

I don't think you could reach such a low retail price for an omni-Atari (let alone, a multi-brand clone) product in anycase, disregarding if you would use ASIC or FPGA. Nobody said this is a viable commertial idea.

[+karri]

Could you cite some? We're talking about FPGAs with a gate count sufficient to do this job in which the retail price of the finished product itself isn't more than $30.

 

I don't think you could reach such a low retail price for an omni-Atari (let alone, a multi-brand clone) product in anycase, disregarding if you would use ASIC or FPGA. Nobody said this is a viable commertial idea.

 

The way to make FB3 both a commercial success and be interested for fpga gurus is to leave it open. I don't exactly know how. But there should be some way to create an add-on module to it that could benefit from the display/sound/controllers hardware. Perhaps it is possible to provide a high-speed serial interface through which your custom fpga device could access the frame buffer, sound and joypads. In this way Atari could make the 5200/A8 FB3 in millions using cheap asic technology. And the hobby-scene could manufacture a generic FPGA+RAM+flash card for running DOOM on some obscure CPU-core on it. Perhaps a high-speed USB port is all we need plus some software on the FB3 for listening to the USB.

 

What about an Atari Lynx USB-on-the-go-stick containing a 6502 core, Suzy and Mikey sprites and sound + 64k RAM and 512k flash for the cart image. This could be plugged into FB3 USB-port making the Atari LynxTV adapter reality.

 

And on the other end on the stick you would have a ComLynx port for allowing connections to other FB3 Lynxes, real Lynxes, Jaguars and Windows PC's.

 

I would be more than happy to donate the sources of my Lynx flash utilities and PC ComLynx connectivity for this cause.

--

Karri

Edited December 28, 2006 by karri

[jbanes]

Perhaps it is possible to provide a high-speed serial interface through which your custom fpga device could access the frame buffer

There's no framebuffer. The A800 has a GTIA chip which renders the screen based on a list of commands.

 

sound and joypads.

It would probably be easier to have a generic serial port that the CPU can communicate with rather than running POKEY lines out. An interesting thought for you is that there's a parallel port right on the front of the unit just begging to be used for serial communications. All you need to do is load custom code into memory. With the FB2, this could be done via an add-on cartridge port. I see no reason why the same couldn't be done with the FB3.

 

In this way Atari could make the 5200/A8 FB3 in millions using cheap asic technology. And the hobby-scene could manufacture a generic FPGA+RAM+flash card for running DOOM on some obscure CPU-core on it.

*raises hand*

 

Serious question here: What would be the point? I mean, if you're going to replace the CPU core anyway, why not splurg on the extra dollar or two it would cost to add your own framebuffer and sound support? Better yet, why don't you focus on a fun homebrew project like the XGameStation Pico? Or join the FPGA Games project to build your own mutli-system?

 

You've got some ideas for a lot of "fun" projects there, but none of them really align with the FB3. You'll probably be more productive and happier by doing them as a completely separate electronics project.

[mos6507]

The homebrew market is a combination of end-users and programmers. The problem with things like XGameStation is that they are only bare developer kits so they really only appeal to programmers.

[jbanes]

I just want to throw up a thought balloon about this. I've been thinking about the differences between the 2600/5200/7800 and the possible options for making a single system that operated as all three. My initial reaction was that it wasn't very feasible, but now I'm starting to wonder.

 

If my head is on straight, all three systems use memory-mapped I/O to control all the devices on the system. This includes the TIA, the RIOT, the POKEY, the GTIA, the ANTIC, and the MARIA. Both the 5200 and the 7800 used the 6502C Sally chip at 1.79 MHz with DMA bus support. The exception was that the 7800 dropped its clock rate to 1.19MHz when accessing the TIA and RIOT chips.

 

 

The Chokepoints

 

The chokepoint appears to be the memory mapping circuitry. If the circuitry could reroute the memory map into three different configurations depending on the software loaded, then the GTIA/ANTIC/POKEY/TIA/MARIA could all be addressed in their respective modes. In fact, the 7800 BIOS had control over the 2600 mode. So all that would be necessary would be a 5200 mode and a 7800 mode with control over which clock gets used.

 

A single bit register could hold the 5200/7800 mode, which would control the MUXes that hold the memory map routing for the 5200 or 7800 address lines. Presumably, there would be a MUX between the 1.79 and 1.19 oscillators that the 7800 is able to control. (Is that how it originally worked? Or was there some other magic?)

 

The system would operate like this:

 

- Boot into 5200 mode, using the host operating system. (Gizmo?)

- The host OS allows game selection from flash OR load from cartridge.

- Once the game has been selected, the host OS ensures the default states and sets the 5200 or 7800 mode.

 

5200 Mode

 

- The host OS jumps to the 5200 BIOS routines.

- The 5200 BIOS sets all the interrupt vectors and initializes the graphics modes.

- The game runs.

 

7800 Mode

 

- The address decoder circuitry reorganizes the memory map to the 7800's configuration.

- The POKEY mapping is enabled if the ROM contains a flag stating that it will use it.

- The host OS jumps to the 7800 BIOS routines.

- The 7800 BIOS checks the ROM signature to see if the system should be downgraded to 1.19MHz 2600 mode.

- The 7800 BIOS sets all the interrupt vectors and initializes the graphics modes.

- The game runs

 

 

POKEY

 

The POKEY Chip would need to be mapped to $E000 in 5200 mode, but $4000 in 7800 mode. The 7800 version would have to be enabled during the ROM load. Also, the joystick inputs would need to be muxed to the POKEY or TIA depending on the mode.

 

 

Input/Output

 

The Video Out and Controller In lines would need to be MUXed to get information to and from the right chip. The TIA/MARIA would be connected to the Video Out in 2600/7800 mode, while the GTIA/ANTIC would be connected in 5200 mode. The controller ports would be connected to the RIOT in 7800 mode, while those same ports would be connected to the POKEY in 5200 mode.

 

 

Schematic

 

Here's an uber-simple schematic that attempts to show what I am proposing. The input ports, RIOT, and POKEY are missing due to space constraints, but hopefully the basic idea gets across. I'm pretty sure that I have the 7800 clock changing oversimplified (least the unsynchronized clocks cause meta-stability problems when switched) but it should be sufficient to get the point across. Hopefully, this will be condusive to open discussion.

 

(Click for Full Size)

 

 

Silicon

 

Could this all fit on a single ASIC? Or are some of these ICs too large to simply mux into two modes? If it would fit in a single, inexpensive ASIC, then the design would be fairly straightforward. (Minus the fact that there are about a dozen ICs to contend with.)

 

If it's too expensive, then here are a few other ideas on the implementation:

• If the extra ICs were externalized, could they fit on a few PLDs? I haven't dealt with PLDs myself, but if it is possible for them to be runtime reconfigured like an FPGA, the chips could be configured for the 5200 architecture or 7800 architecture.
  
• Have you considered talking with Xilinx about your needs? They may be able to provide a product that meets your needs. For example, they might consider creating an FPGA part with a "hard" 6502 circuit onboard. This would reduce the necessary fabric for reconfiguration.
  
• There's also the option of using real instances of the original ICs, then having a custom PAL used as the memory mapper/address decoder. This poses some problems, however, as (if I understand correctly) the existing 6502s do not actually use a memory controller.
  

Let me stress that I'm just throwing ideas around. I'm sure there are tons of holes here, and I'd like to hear about them. But don't make the mistake of thinking that I'm dead-set on having "solved the problem". This may or may not be feasible. I don't know.

 

It's something to potentially chew on, anyway.

Edited December 29, 2006 by jbanes