(re)build a *NEW* Atari Computer?

[opcode]

How about a new system with a 65816, 4MB of RAM (expansible till 12MB), 2MB of Flash memory (for the OSes), 16 bits expansion slots and real-time clock. The system would have 3 buses: a fast bus (14MHz) for the CPU, 4MB memory, Flash memory, SIMM slots and 16-bit expansion slots. Second bus at 1.79Mhz, with the real-time clock, cartridge slot, pokey, PIA, GTIA and Antic. This bus would be mapped at bank C0h, and shadowed to bank 00h by setting a bus controller register (only memory areas D000h-D7FFh and 8000h-9FFFh/A000h-BFFFh, if cartridge is present). Then the third bus would run at 3.58MHz/1.79MHz and have the Antic and VRAM. VRAM is 128KB and is the system memory when running in compatibility mode. The VRAM is mapped to bank D0h-D1h, and can be shadowed to 00h-01h.

In compatibility mode, both C0h and D0h are shadowed to 00h. OS is loaded to C000h-FFFFh during boot. When accessing C0h shadowed areas (D000h-D7FFh and 8000h-9FFFh/A000h-BFFFh, if cartridge is present), CPU is slowed down to 1.79MHz. When D0h is shadowed to 00h, Antic steal CPU cycles.

In native mode no shadowing is done. I/O is done accessing bank C0h, so the CPU is just slowed down when acessing that bank. Access to VRAM is done accessing banks D0h-D1h, so the Antic only steal CPU cycles when the CPU access those banks. So in native mode the CPU runs at 14MHz most of the time. In addition to that, the Antic has now complete control of the VRAM bus most of the time, allowing a future Antic version to run at much higher clocks and use a larger number of cycles per frame.

Everything inside a PC desktop case, with a PS2 keyboard, VGA/S-video/etc outputs. Cartridge slot, joystick ports and SIO would be placed on a front panel using a drive bay. PBI and 16-bits slots would be all internal.

Sounds good? Any major flaw?

 

Eduardo

[peteym5]

That is a very interesting way of doing this with the old chipset. One of the major limitation with the Atari Video chip set is that it has to be shared the bus with the main CPU. This has always been an opsical for programmers and software designers. These is something a few of us had discussed on here is that how fast can you update the GTIA registers for like a Display List Interrupt? Something a few of us were looking at is a way to rapidly change the registers to get more colors and sprites on the screen. Is it possible to update the registers once per clock cycle with a 16bit cpu? Looks like you might be designing a new motherboard for this computer and is something I suggested many times because adding many upgrades to an existing computer will end up being wired up like a plate of spaghetti or an Borg assimilation.

[opcode]

These is something a few of us had discussed on here is that how fast can you update the GTIA registers for like a Display List Interrupt? Something a few of us were looking at is a way to rapidly change the registers to get more colors and sprites on the screen. Is it possible to update the registers once per clock cycle with a 16bit cpu? Looks like you might be designing a new motherboard for this computer and is something I suggested many times because adding many upgrades to an existing computer will end up being wired up like a plate of spaghetti or an Borg assimilation.

 

In order to keep compatibility, all accesses to GTIA/Antic registers should be done at 1.79MHz. However, with the 3 buses, the Antic wouldn't be stealing CPU cycles anymore, as long as the CPU doesn't access the VRAM banks or bank D0h shadowing is not enabled. This way cycle counting would be possible, and the CPU could still go 14MHz while not updating the GTIA...

About a new motherboard, I agree with you. Furthermore, IMHO the Atari 8-bit line never got any really relevant updates, unlike other 8-bit lines, like Apple II and MSX. So producing a new motherboard would be a good opportunity to remedy it.

 

Eduardo

[Bryan]

I've drawn up several enhanced A8 machines (and built a couple Frankensteins), but I keep coming back the realization that they'd be expensive to produce (because you'd never be able to build in quantity), that they would draw people away from developing for the real A8 hardware, and if the specs are any good it wouldn't represent what might have actually been released back it the '80s.

 

So, I end up being really conflicted over the whole upgrade thing because I enjoy seeing things like Crownland and Yoomp! that really stretch the stock hardware.

 

Nonetheless, Opcode's design is very ambitious and would be cool to see in operation. If it doesn't fit in the machine, I would suggest a MicroATX form factor so cases are easy to find.

Edited December 24, 2007 by Bryan

[Bryan]

That is a very interesting way of doing this with the old chipset. One of the major limitation with the Atari Video chip set is that it has to be shared the bus with the main CPU. This has always been an opsical for programmers and software designers. These is something a few of us had discussed on here is that how fast can you update the GTIA registers for like a Display List Interrupt? Something a few of us were looking at is a way to rapidly change the registers to get more colors and sprites on the screen. Is it possible to update the registers once per clock cycle with a 16bit cpu? Looks like you might be designing a new motherboard for this computer and is something I suggested many times because adding many upgrades to an existing computer will end up being wired up like a plate of spaghetti or an Borg assimilation.

 

I envisioned a simple color enhancement that I called "Stuffer." What it would do is take over the GTIA bus lines when started by the CPU. It would then follow a simple SRAM list and cram a GTIA register every 2 clocks (like a 6502 that could write on every cycle). When the list ended, the bus would be free again (any CPU access to GTIA during stuffing would result in invalid data). The CPU could access the SRAM list (in GTIA's register page) while the device was idle. Anyway, this would be a simple way to get a lot of color on the screen.

 

Edit: I looked at my notes for the device:

 

I had a 1-byte instruction:

 

b0,b1,b2 <- Register to stuff. There are 8 Stuffer registers that can be preloaded with a register number (R0-R7).

 

b3,b4,b5,b6 <- Data to stuff. There are 16 Stuffer registers that can be preloaded with data (D0-D15).

 

b7 <- Stuff (1) or other operation (0)

 

Other instructions:

 

00000000 <- Stop

 

01000000 <- Set registered mode

01nnnnnn <- Set string mode. String mode stuffs raw data 'nx2' times, then returns to registered/command mode. (up to 128 stuffs)

 

00100000 <- Wait until end of line

001nnnnn <- Wait 'n' cycles (up to 32)

 

0001nnnn <- Wait 'n' lines (up to 16)

 

The SRAM bank would appear in the top half of the D000 page (D080-D0FF), while the Stuffer control registers would appear at D040-D07F. For compatibility, nothing would appear until a magic value was written. I figure it would have a 32K SRAM and a small FPGA.

 

-Bry

Edited December 24, 2007 by Bryan

[peteym5]

I envisioned a simple color enhancement that I called "Stuffer." What it would do is take over the GTIA bus lines when started by the CPU. It would then follow a simple SRAM list and cram a GTIA register every 2 clocks (like a 6502 that could write on every cycle). When the list ended, the bus would be free again (any CPU access to GTIA during stuffing would result in invalid data). The CPU could access the SRAM list (in GTIA's register page) while the device was idle. Anyway, this would be a simple way to get a lot of color on the screen.

 

Edit: I looked at my notes for the device:

 

I had a 1-byte instruction:

 

b0,b1,b2 <- Register to stuff. There are 8 Stuffer registers that can be preloaded with a register number (R0-R7).

 

b3,b4,b5,b6 <- Data to stuff. There are 16 Stuffer registers that can be preloaded with data (D0-D15).

 

b7 <- Stuff (1) or other operation (0)

 

Other instructions:

 

00000000 <- Stop

 

01000000 <- Set registered mode

01nnnnnn <- Set string mode. String mode stuffs raw data 'nx2' times, then returns to registered/command mode. (up to 128 stuffs)

 

00100000 <- Wait until end of line

001nnnnn <- Wait 'n' cycles (up to 32)

 

0001nnnn <- Wait 'n' lines (up to 16)

 

The SRAM bank would appear in the top half of the D000 page (D080-D0FF), while the Stuffer control registers would appear at D040-D07F. For compatibility, nothing would appear until a magic value was written. I figure it would have a 32K SRAM and a small FPGA.

 

-Bry

 

I can see where you are going with this. I thought about a device that is a simple list of register updates on every scan line. Similar to activating the Player/Missile DMA, but this has pages for all the registers in the GTIA. Sounds very interested and wonder if you plan on developing such a device. Such a device not only change colors, it could change Player/Missile positions, widths, and shapes. It can probably update registers mid line to get more pm graphics. Are you planning on such a device to operate independent from the main bus? It is a very simple device.

[Bryan]

I can see where you are going with this. I thought about a device that is a simple list of register updates on every scan line. Similar to activating the Player/Missile DMA, but this has pages for all the registers in the GTIA. Sounds very interested and wonder if you plan on developing such a device. Such a device not only change colors, it could change Player/Missile positions, widths, and shapes. It can probably update registers mid line to get more pm graphics. Are you planning on such a device to operate independent from the main bus? It is a very simple device.

 

The device would sit between the GTIA and the bus and would be invisible most of the time. When it was activated, it would simply prevent access to GTIA (and possibly the SRAM) while it wrote on every CPU cycle. The Stuffer registers would be available at any time. It would have no other effect on the main bus. Any GTIA register could be stuffed, and the CPU can monitor progress or stop it early by reading/writing the device's registers.

 

You could reposition a player every 2 pixels.

You could reposition a player and change its data every 4 pixels.

You could reposition a player and change its data and color every 6 pixels.

(pixel = 160 pixel mode)

 

You could easily display all colors on a scan line.

[mos6507]

I can see where you are going with this. I thought about a device that is a simple list of register updates on every scan line. Similar to activating the Player/Missile DMA, but this has pages for all the registers in the GTIA. Sounds very interested and wonder if you plan on developing such a device. Such a device not only change colors, it could change Player/Missile positions, widths, and shapes. It can probably update registers mid line to get more pm graphics. Are you planning on such a device to operate independent from the main bus? It is a very simple device.

 

The device would sit between the GTIA and the bus and would be invisible most of the time. When it was activated, it would simply prevent access to GTIA (and possibly the SRAM) while it wrote on every CPU cycle. The Stuffer registers would be available at any time. It would have no other effect on the main bus. Any GTIA register could be stuffed, and the CPU can monitor progress or stop it early by reading/writing the device's registers.

 

You could reposition a player every 2 pixels.

You could reposition a player and change its data every 4 pixels.

You could reposition a player and change its data and color every 6 pixels.

(pixel = 160 pixel mode)

 

You could easily display all colors on a scan line.

 

This sounds really cool, and it fits into the hardware elegantly. I'd love to see if it were really possible.

[timofonic]

About the design, why not using a Terasic DE1 board?

 

http://de1.terasic.com

 

An expansion board could be used for add the (still) not implemented chips on FPGA.

 

This board is quite interesting as is powerful and cheap compared to other solutions. It will be used for other projects like Minimig (Amiga500 core) and a CPC core from Tobias (tobiflex, the maker of SymbOS and Symbiface).

[peteym5]

This will certainly bring player/missile multiplexing to a new level. It may be possible to create a character color map like we've seen on Commodore systems. Questions would be are how much would such a device cost to build? How long will it take to develop? Would there have to be versions for NTSC and PAL? I see this is something that is being developed on the English speaking side so we won't run into issues of trying to figure out whats going on, or if the project has died. There have been a few Polish, German, and others developing components like Video Board XE, but waiting we've been waiting a long time for any new information.

Edited December 24, 2007 by peteym5

[Bryan]

Well, the most affordable FPGA I know of is the Lattice MachXO. It doesn't handle 5V directly, though. Once you get the parts and make the board, they'd probably be $30-50 each.

[mos6507]

Well, the most affordable FPGA I know of is the Lattice MachXO. It doesn't handle 5V directly, though. Once you get the parts and make the board, they'd probably be $30-50 each.

 

Wouldn't there be any way to fit this into a PIC or a CPLD?

[Bryan]

Well, the most affordable FPGA I know of is the Lattice MachXO. It doesn't handle 5V directly, though. Once you get the parts and make the board, they'd probably be $30-50 each.

 

Wouldn't there be any way to fit this into a PIC or a CPLD?

 

A PIC is a processor. It can't keep up with real-time bus activity. A CPLD could implement a simple version of this, but for all the features I want an FPGA makes more sense. The MachXO is sort of a CPLD hybrid.

[opcode]

Just curious: how you guys see "alien" video solutions, like the V9990? It has nothing to do with Atari, but is quite powerful. And last time I checked, it was still easy to find. Some of the V9990 characteristics are:

 

- Game modes: 2 independent planes, character based, thousands of tiles, 128 sprites on screen, sprites are 16x16, 16 colors per character or sprite. Basically it's Sega Genesis class video.

 

- AV modes: linear frame buffered, resolutions from 256x212 till 768x424 (interlaced), up to 32K colors on screen (for resolution above 512x212, max of 16 colors). Lightning fast blitter.

 

- OV modes: linear frame buffered 640x480 (non-interlaced), but requires monitor. 16 colors max (undocumented 1024x424 mode)

512KB of dedicated dual ported VRAM.

 

Better of all, it is easy to implement and even easier to program. No need to open your Atari (as long as it has a PBI or ECI port). I use a V9990 with my MSX computer.

So my question is how Atari users see alien solutions like this (the V9990 IC was created by Yamaha)

 

You can see a little demo using the V9990 here:

I don't know why but there is a lot of jerkiness in the video. I can assure that the real thing runs absolutely smooth.

 

BTW, the demo was created using a MSX (8-bit computer) with a V9990 and OPL4 for sound (another Yamaha IC)

 

Eduardo

[mos6507]

A PIC is a processor. It can't keep up with real-time bus activity. A CPLD could implement a simple version of this, but for all the features I want an FPGA makes more sense. The MachXO is sort of a CPLD hybrid.

 

If the bus is slow enough and the processor is fast enough, it can. That's how Chimera works. The CPLD watches the bus and raises interrupts on the ARM. The ARM can perform some small amount of work fast enough that the 6507 doesn't even know anything has been done.

[Bryan]

A PIC is a processor. It can't keep up with real-time bus activity. A CPLD could implement a simple version of this, but for all the features I want an FPGA makes more sense. The MachXO is sort of a CPLD hybrid.

 

If the bus is slow enough and the processor is fast enough, it can. That's how Chimera works. The CPLD watches the bus and raises interrupts on the ARM. The ARM can perform some small amount of work fast enough that the 6507 doesn't even know anything has been done.

 

Ah, how fast is the ARM?

 

Something like an Atmel AVR can run at 20MHz and runs most instructions in 1 cycle, but I don't think I could manage the SRAM address bus, reading in instructions and do everything else and stay within 6502 timing limits.

 

This is a pretty straightforward FPGA task. I need enough registers for all internal functions. I need a 15-bit loadable address counter for the RAM, a bunch of storage registers for the R and D registers, a 6-bit loadable counter for the wait functions, some instruction decode logic, and some interface logic. The thing that sucks about FPGA's is that they're hard to shop for in regular distribution. You usually have to get a custom quote because they're always advertised at some outrageous price even though the press release will say they're $1.50 in 10K quantity (so they should be $5-10 each, but look at FPGA prices in DigiKey!). I guess the vendors don't like people just buying them off the shelf.

 

-Bry

[mos6507]

Ah, how fast is the ARM?

 

72mhz. It also has very inexpensive variants, the main limitation being how much onboard RAM there is. An ARM/CPLD combo is still a lot cheaper than a single FPGA no matter what, and has other side benefits due to the plethora of IO on the ARM.

 

I don't know enough about what is involved to know whether it might be possible for this task, but it's sounds similar enough to Chimera that it is probably worth investigating further.

 

 

This is a pretty straightforward FPGA task.

 

Since this sort of thing is not a true processor upgrade, and wouldn't have any software to run on it out of the box, I don't think people would be willing to spend a fortune on it. I think final retail cost probably shouldn't exceed $50. That would be a tall order with a FPGA.

[Bryan]

72mhz. It also has very inexpensive variants, the main limitation being how much onboard RAM there is.

 

Wow... doesn't it seem like a shame to have a 72MHz processor that you're not actually using as the processor.

[mos6507]

Wow... doesn't it seem like a shame to have a 72MHz processor that you're not actually using as the processor.

 

Not really, considering that they are all well under $10 a pop. Same deal with storage. We are using microSD for Chimera. 512mb cards are <$10. That's already more than you'd need to store the entire 2600 catalog plus probably every Chimera native game ever to be written. If you aren't paying a premium for it, you may as well use it whether it's overkill or not.

[Bryan]

Wow... doesn't it seem like a shame to have a 72MHz processor that you're not actually using as the processor.

 

Not really, considering that they are all well under $10 a pop. Same deal with storage. We are using microSD for Chimera. 512mb cards are <$10. That's already more than you'd need to store the entire 2600 catalog plus probably every Chimera native game ever to be written. If you aren't paying a premium for it, you may as well use it whether it's overkill or not.

 

It's interesting that you've written an ANSI terminal server for Chimera. I did the exact same thing for a project at work. I'm using the Atmel AVR in a device that we come along and plug a laptop into to set it up and monitor it. We're building a new one with a larger AVR so I'll be going back and improving all the menus.

[peteym5]

I have seen the Chimea Arm thing for the 2600 and wondering what can it do for the 8-bit. Could we create the proposed register stuffer with it? That is rapidly updating the registers on the GTIA chip every 2 clock cycles. Since a few had stated duplicating the functions Antic and GTIA chip and enhancing, it probably be better to build upgrades or something that can add to those chips.

 

Has anyone seen the thread that has popped up about Covox sound chip? That plays wave sounds. In order to have it play wave sounds, you have to tie up the main CPU most of the time, and capable of going up to 4 Khz. That makes it useless for anything for games or using it with graphics. A ARM, FPGA device, or other co-processor is something that would make it more useful. I think I made a similar reply on that thread.

 

We have a few upgrades being proposed to be made. Just have to see if these projects can be completed. The register stuffer ideal seems like the easiest to do. The Chimera Arm processor has been going on for the 2600 and seems fairly cheap to create something on the 8-bit. What is the better direction to go?

Edited December 27, 2007 by peteym5

[mos6507]

I have seen the Chimea Arm thing for the 2600 and wondering what can it do for the 8-bit. Could we create the proposed register stuffer with it? That is rapidly updating the registers on the GTIA chip every 2 clock cycles. Since a few had stated duplicating the functions Antic and GTIA chip and enhancing, it probably be better to build upgrades or something that can add to those chips.

 

If you have to reimplement GTIA or ANTIC and tack stuff onto them, then it may be more expensive than wedging something between them.

 

The DPC-like effects of Chimera might yield some improvements in DLIs on the A8. How much, I don't know. You could save a cycle per load vs. using RAM.

 

The A8 is in most respects the 2600 hardware with most of the bottlenecks removed, and Chimera (in so far as it apes the DPC) works kind of like a generic ANTIC in layering a second dimension onto a scanline-level video processor. So it just seems like there are fewer areas in the A8 architecture that are as ripe for enhancement. The trick is to find some nook somewhere where you can wedge in a $5 chip and open up a ton of stuff.

[frogstar_robot]

If you have to reimplement GTIA or ANTIC and tack stuff onto them, then it may be more expensive than wedging something between them.

 

The DPC-like effects of Chimera might yield some improvements in DLIs on the A8. How much, I don't know. You could save a cycle per load vs. using RAM.

 

The best idea may be a compact logic board design that accepts existing A8 chips using a form factor like mini-ITX. It should probably accept power from mini-ITX compliant supplies as well. As for the enhancements, make this thing as open ended as possible but don't get ambitious about what you add. Basically, shoot for standard A8 capabilities out of the box but easily modded. My best idea for that is to have every internal chip bus masterable on an extended PBI interface (assuming it isn't crazy to engineer). It sounds like Chimera could be a possible super-Antic; for that matter it could replace the 6502c as well and just drive POKEY and GTIA directly.

 

So fine, make it easy to interface such things without feature creeping the core design. In time we may have hot-rodded FPGA versions of the A8 chipset but I wonder what we could build today "off the shelf". Quite a lot could be done more elegantly than frankensteining vintage A8s. There's no reason not to have every OS and 576KB RAM built in say. Interfaces for IDE flash drives exist so that can be built in as well.

 

It also occurs to me that in all this thread, no one has thought about the keyboard and function keys. It is probably a necessary evil to kludge up some sort of interface for an AT or USB keyboard. At it's simplest, a "new A8" would just be a board that could be etched and populated by a chipset but the keyboard could be a real hassle unless a modern electronically compatible keyboard is designed as well. The XEGS detachable keyboard would have be re-implemented at the least.

Edited December 28, 2007 by frogstar_robot

[peteym5]

The best idea may be a compact logic board design that accepts existing A8 chips using a form factor like mini-ITX. It should probably accept power from mini-ITX compliant supplies as well. As for the enhancements, make this thing as open ended as possible but don't get ambitious about what you add. Basically, shoot for standard A8 capabilities out of the box but easily modded. My best idea for that is to have every internal chip bus masterable on an extended PBI interface (assuming it isn't crazy to engineer). It sounds like Chimera could be a possible super-Antic; for that matter it could replace the 6502c as well and just drive POKEY and GTIA directly.

 

To be honest I am not totally sure where very fast processor like ARM can be attached to the A8 bus. Maybe it can stuff the GTIA, Antic, and Pokey registers directly and do the same functions as a DLI, but will be able to change more registers without slowing down the main CPU. Not sure replacing the 6502c is a wise ideal because you will lose all your software compatibility.

 

So fine, make it easy to interface such things without feature creeping the core design. In time we may have hot-rodded FPGA versions of the A8 chipset but I wonder what we could build today "off the shelf". Quite a lot could be done more elegantly than frankensteining vintage A8s. There's no reason not to have every OS and 576KB RAM built in say. Interfaces for IDE flash drives exist so that can be built in as well.

 

I agree obtaining 576k is fairly easy, some say 1088k is possible, but they are never clear about the Antic access comptibility. However I do not thing there are too many applications that can take advantage of that much memory, unless we start doing our proposed massive video things. Some of those proposed video enhancers will most likely have a seperate memory.

 

It also occurs to me that in all this thread, no one has thought about the keyboard and function keys. It is probably a necessary evil to kludge up some sort of interface for an AT or USB keyboard. At it's simplest, a "new A8" would just be a board that could be etched and populated by a chipset but the keyboard could be a real hassle unless a modern electronically compatible keyboard is designed as well. The XEGS detachable keyboard would have be re-implemented at the least.

 

http://members.aol.com/MacFalkner/atari/aki/index_e.htm

 

Ssomeone has done the PS/2 or AT keyboard thing on the Atari 8-bit, has a seperate board and chip and links up to POKEY. Some of the function keys are mapped to HELP, Start, Selct, Option, and Reset. This would solve the keyboard issue.

Edited December 28, 2007 by peteym5

[mos6507]

I agree obtaining 576k is fairly easy, some say 1088k is possible, but they are never clear about the Antic access comptibility.

 

As long as people only use the extra memory for ramdisks, it's kind of pointless these days to go over 128K.

 

If you want to set some kind of >128K banking standard for game applications then maintaining ANTIC banking is important. I would say leave the base 128K and beyond that, use a 2nd PIA to add more banks, all with full ANTIC banking options.