ClausB

Very nice. I notice, however, that if you move the wire at IC3-11 to IC6-26 and XOR IC2-4 with IC12-15 through an RC network with time constant 47 ns, then you can avoid the skew between ANTIC's phi2 falling edge and GTIA's color phase delay reference, providing a more stable horizontal sync signal for advanced interlaced or component video applications. See what I mean?

Well, so why am I wasting my time then?

Very nice. Doesn't ANTIC already have an 8x10 mode for extenders, which does not need 2 sets?

Thanks to all for laying out my options. There's a lot to consider and more to learn. Thanks for the offer! I might just take you up on it.

Nice work! That makes sense, since GTIA's ancestor, the 2600 TIA, generates HSYNCs on its own. The 2600 has nothing like ANTIC; the CPU handles the vertical structure of the display.

Cool. Pictures yet?

Progress! I took a 20ns 32KB SRAM from an old '486 and plugged it into an even older OSS cart, added a couple of gates for the write strobe, and tried it on my 800XL. It works! Using the 4-bit control register on the cart, I can switch between 4 banks of 8K. So now I have a small RAMcart, but I still have to add the video generator. I'd like to put it into a PAL but it might not fit. Can anyone suggest any free CPLD software and a cheap programmer?

Yes, you're right, that's done in the PAL in the XLs. However, in the 800, they are degated on the RAM boards and the cart selects are not degated at all.

Yes, that is a complication, but nothing a clever programmer can't handle. My main idea here is not to have any additional address generating hardware for the SRAM. Just depend on ANTIC to supply addresses.

Actually, 256 rows instead of 128 (low 8 bits instead of 7). But, as you pointed out, it's the upper bits that could be a problem here.

The DLI test? No. We don't need a DLI on every scan line. We only need one before the first scan line and another after the last scan line to enable and disable the mode.

Ouch, good point! I seem to recall that somebody experimented with refresh addresses and found the upper bits were zero. Wishful thinking? Maybe it was this: http://www.atariage.com/forums/index.php?s...t&p=1514042 What happened to the link to the pictures in that post?

The HALT signal is not available on the cart, so it has nothing to do with this design. It is up to the programmer to put only display data in the cart address space. Everything else - display list, PM data - should go elsewhere. He could put some CPU data there as well, but he should not read it while display is enabled, only during vertical blank.

True. Another variation on the design would give 640 pixels across, using 3 bytes per cycle.

I suppose I was not very clear. I too can not understand Jules Verne in the original French. My idea is that the hardware would respond to any read (from CPU or ANTIC) with several bytes in quick succession in one cycle, as long as that mode is enabled. The hardware would include a control bit to disable that mode. A DLI could enable that mode just above the first scan line and disable it after the last. The programmer would be careful not to read display RAM while that mode is enabled, otherwise there would be "sparkles" on the screen. But he could read during vertical blank. He could write to display RAM anytime - only reads are affected. I hope that explains it better, and I do welcome your questions.

I answered that yesterday in post #296. For the third time: PLEASE READ THE PREVIOUS POSTS. Proszę przeczytać poprzednie posty.

Well, OK then. Back to my question for the rest of you:

Yes, software would write one bit at a time. That's why it would be slow. Software would write command and address, one bit at a time, and then enable a 14 MHz clock to shift out video data. Not much hardware needed for that. See diagram in previous posts.

Yes. See earlier posts. One design was based on serial RAM, and the FRAM was the only serial RAM I could find then. We did not need the nonvolatility feature of FRAM, just the SPI feature.

That's exactly what I was thinking. In display mode, any read cycle, whether from the CPU or from ANTIC, would trigger the burst. The programmer could set up DLIs to enable and disable display mode and flag when it's safe to read the RAM.

Well, another Winter came and went and my Projects list is no shorter. I have been rethinking the design, however. From your previous comments it's obvious that the FRAM design would be too slow to interest the hot programmers around here. So I suggest we step back to the idea of SRAM addressed by ANTIC in parallel with main RAM. It should still be a plug-in cart though, a solderless accessory. How about this: Have a fast 32KB SRAM mapped into the 8K cart space with 4 banks. Bank 0 would be the default bank where ANTIC display data would go. Other banks would hold the enhanced luma data and the CPU would read and write them, 8 bits at a time, using normal bank selection techniques. During each ANTIC DMA cycle, the fast SRAM could spit out up to 4 bytes per cycle (kind of like Bob's accelerator), one from each bank. Shift registers would capture all bytes except the last one, which stays on the bus for ANTIC to read. Then the shift registers would serialize the luma data to make hi-res video to be summed with the GTIA luma. Several variations come to mind. Up to 6 bits per color clock are available. Horizontal resolutions up to 960 pixels are possible, or maybe 480 pixels with 4 luma levels. Or we could map a bigger SRAM over the full 16K cart space, giving enough display RAM for Rybags' interlaced mode plus hi-res. What do you all think?

In '82 I did some work for a company that put in hotel information systems (announcements, text ads, etc.) around Michigan and Wisconsin. They used Atari 800s plus RF modulators. Software was BASIC and mixed different text modes but each screen had to be custom programmed. Tedious. I remember adding color-changing DLIs and fine scrolling.

Well, I had to ask! I have a 128K Axlon RAMDISK clone I made from a 32K RAMCRAM. Back then I borrowed a real one and traced the circuit. You'll be sorry you asked. Nominally it's $CFFF but it's not fully decoded. They used a 13-input NAND (LS133) and whatever RAM Slot 2 signals they could to narrow it down to the ranges $0FC0-$0FFF and $CFC0-$CFFF (no A15 available so it could not distinguish between the two ranges). The first range is in RAM occupied by DOS code, IIRC, so it won't get written to after DOS loads. Yes. No reset in hardware, just a switch to disable banking and act like a regular 16K card. IIRC, their RAMdisk software had a homebank function. Yes, but any bank could be the "main" bank, depending on the software. Yes and yes.Good luck!

Abomination!

Hi, Randy! I'm bad with names but I might remember your face. Was Guy the founder and first president? I forgot his name too. Please say hello when you see them next. Maybe we should do a CHAOS reunion dinner. What do you think?