ClausB

Thanks, Bob, for the explanation. Yes, I had intended for the multiple serial FRAM design to use them in parallel. That is, hook them all up to the same serial clock and the same select signal. Each FRAM's serial input would come from a different data bit (say D7 and D6 for a dual FRAM) and each serial output would be a different luma bit. Then they could be loaded by the CPU concurrently (2 bits at a time for a dual FRAM), using the SPI protocol.

Not to be greedy but... How much faster could it be made to go? Which component limits the design to 7 MHz (besides the clock)?

Cool! Can't wait to see the design.

I still don't get it. Maybe I'm too fixated on the present design, which connects to the cartridge port, not directly to ANTIC. But it does use DLIs to sync the enhanced video output with the ANTIC/GTIA video.

Specs are still in flux, but presently the horizontal resolutions are 640 monochrome pixels with 2 or 4 luma levels, or 160 pixels with 16 or 256 artifact colors. Write speed estimates are about 0.25 Mbps for the FRAM design vs. about 1.5 Mbps for a SRAM/PLD design.

Sorry, I can't quite unravel it. Please explain.

Expansion Port: Top Bottom ----------------------------------------------- +5V DC 1 36 +5V DC Audio Out (2 port) 2 35 Not connected Ground 3 34 Ground R/W Early 4 33 Not connected Enable E0-EF 5 32 D7 D6 6 31 D5 D4 7 30 D3 D2 8 29 D1 D0 9 28 Ground IRQ 10 27 A0 Ground 11 26 A1 Serial Data In 12 25 A2 Serial In Clock 13 24 A3 Serial Out Clock 14 23 A4 Serial Data Out 15 22 A5 Audio In 16 21 A6 A14 17 20 A7 System Clock 01 18 19 A11 Has anyone figured out what A14 is doing on that Expansion Port? You do need A11 and "Enable E0-EF" to select pages $E0 thru $E7, so as not to conflict with POKEY, and you need A0 thru A7 to address within those pages, but WTH is A14 for?

Does it have a different, faster CPU? How many details can you divulge within the contest bounds?

Unfortunately, there were some typos in the published article. I sent them a clean printout and a floppy disk with the proofread article in some Atari format. They said they could not convert the disk to their typesetter so they manually retyped it and filled it full of typos. When I sent a letter to the editor with corrections and updates, they edited out the corrections! The typos survive on the Web copies too. Here are some I noticed: "POKEY's registers are all addressed at page $EB in the 5200 as opposed to $D2 in the 400/800." That should be page $E8, but luckily any page from $E8 through $EF will address POKEY. "The even pots (POT0-POT6) give the horizontal positions of range from 1 to 228;" That seemingly poor English is really the start of one sentence grafted to the end of another. Between "of" and "range" should be something like "the joysticks and the odd pots give the vertical positions. The position values". In the cartridge pinout table, pin 9 should be "-Enable 80-BF", not "Enable 80-8F", and pin 10 should be "-Enable 40-7F". I recall their were more typos, but that's all I can find now. Has anyone else found others?

Would you happen to have the source code to Star Raiders to share? Well, I can dream, can't I?

25 years ago I dissected a friend's 5200 and noted how it differed from my Atari 400. I also disassembled the ROM and compared it to the 400/800 OS. I then used the info to convert the 5200 PacMan cart to run on the 400/800. From those notes I wrote this article for ANALOG magazine: http://www.atarimuseum.com/videogames/cons...nv_to_5200.html My question to all of you is this: Which game conversions were done using the info in that article?

Well, Atari made analog joysticks for the 5200, which itself was based on A8 hardware. The analog joysticks used POKEY's pot inputs, like the paddle controllers did. IIRC, the analog joysticks had poor or no self-centering and most people agreed that they sucked.

If someone can help with testing and debugging, we'll make it work. The development of this thing should be a group effort, using these forums, so as to satisfy the whole group.

No additional sprites but the Atari PMG would still function normally. Well, I hope to include some firmware in the disappearing ROM to support 80 columns (like ACE-80) and graphics primitives. The disappearing ROM would allow normal access to the 8K (either BASIC or RAM) under the cart, just like ACE-80.

I hope I don't appear possesive about this thing. I know that many of you have contributed great ideas toward it. And my ideas sprang from Bob's original posts and your discussions long before I ever chimed in. It's really been a group effort. And it should stay that way. I don't want to hold anyone else back from building something different. I doubt I'll have enough time before winter to do much more than the 1st experiment I outlined before. It has also become apparent from your comments that the FRAM design will be too limiting to support much exciting software development. As you mention, it might still be useful for proving the concepts. But let's keep discussing improvements. And Bob, maybe it's time for those CPLD tutorials?

Cool idea. Definitely CPLD or maybe even FPGA.

Claus can correct me if I'm wrong but I suspect this will update the screen too slowly for that. His proposed device ... will still be slow to update compared with the native hardware. I don't know Ultima, but BallBlazer would be too fast for the FRAM device. It could do something like the scrolling background in Blue Max, though. If we want dynamic hi-res screens, then we should build the CPLD-SRAM device instead. Even then, we're limited by the 6502's write bandwidth -- it just takes more time to write all that hi-res data to RAM.

Ouch....that was a low blow CB Sorry. Besides, my posting average is only 1.1 per day.

Maybe if I stay the hell off these forums, I'll have time for some experiments! Am I turning into another Carmel?

Can you post links to your demos? I'm too lazy to search. I have the Stella emulator but no hardware. I've been reading about 2600 programming on the web lately. As an old 400/800 programmer, I did not know before how it was done. It's pretty impressive how much the 2600 programmers squeezed out of the minimal hardware! Sorry it's off topic. Or is it? We 8-bit guys could learn a trick or two from Stella coders.

Not so. I plan to use a technique similar to what I did with ACE-80XL. The cart ROM would switch off when not in use, allowing normal access to the underlying RAM or BASIC ROM. When in use, the cart ROM would switch on only during OS calls and then switch off before returning to BASIC or other calling app. It will work seamlessly. If we do cart pass-thru, it will work the same way, allowing normal access to the other cart when this ROM is off.

In 1984 at PDI I did a serial cable from the Atari 800 SIO to the C64 and a one-way protocol, from Atari to C64 (because, well, nothing good could ever come the other way).

Let's do the math. Carmel has posted 5501 times over 1478 days. That averages 3.7 posts a day. Keep it up, Carmel!

Would you pay $50 to $75 (non-profit) for a cartridge that connects with the video DIN cable and adds high resolution graphics modes to the Atari? Up to 640 horizontal pixels with 4 gray levels, or 160 pixels with 256 colors, could be added on top of the existing ANTIC graphics modes. Firmware to support graphics and 80-column text would be included. For more information, see the thread that is developing the idea.

Thanks, Steve, for volunteering! I am planning a few experiments before drawing up a schematic: 1) Work out a good, small TTL-to-video summing circuit. I plan to start with the old OSS cart and connect one of the flip-flop outputs to the luma signal on the DIN connector, through a diode and resistor. Then write a little routine to turn the bit on and off in sync with the ANTIC display and see how the summed video looks. It will be very lo-res, about 8 horizontal pixels, but enough to prove the circuit. 2) Try a simple 14 MHz clock circuit that synchs to the 1.8 MHz clock on the cart connector. Then feed it through the video summer to check the summer's frequency response. I'll build it with DIPs on a perf board wired to the OSS cart. 3) Study the write cycle timing of the signals available at the cart connector. Once those parts are proven, I will try adding the FRAM. Just got the latest (thickest?) Mouser catalog and found the FRAM there for about $6. Not sure when I can get around to these experiments, but I am spending spare time thinking about them. Perhaps the production board could use SOICs instead of DIPs, since the FRAM is only available that way. Even the EPROM could be replaced by a SOIC EEPROM or maybe a parallel FRAM. Steve, can you do surface mount boards?