ClausB

Yes, cute. See if I understand: So, RAM banks appear at $1E00-$1EFF (not -$1FFF as you posted, because $1FFF equals $7FFF on a 6507), right? There must also be a kernal routine to move data from RAM banks to player registers, right? Using venetian blinds-ish technique, right? 96 pixels horizontal, right? So, 12 columns, right? What 2600 games use this method?

Yes, it is interesting, isn't it? Just wish I could find more early development documents and prototypes online. I've heard that someone in this forum has other prototypes, but when I asked for photos I got nothing. What could be done with the photos and info posted above to make them more presentable or accessible?

Well, Wozniak demonstrated the formula (RAM down low, ROM on top, I/O high middle) in 1976 with the Apple I, long before the Atari 800 or C64. It follows logically from the 6502 architecture. The Colleen prototypes had 4K for I/O (see here). Be glad they cut it down to 2K.

Theoretically, I would say 256 bytes - one page - because 6502 software already has to deal with addresses in 8-bit units, so a one-page bank can be addressed with index registers, without shifting and masking. There's also a hardware reason: There are several holes in the Atari memory map that are exactly 256 bytes wide, like pages $D1, $D5, $D6 and $D7. Also, for a RAMdisk, 256 bytes is the size of a DD sector. So, 256 bytes is the most logical bank size. The point is a bit moot, though, because 16K has become the standard. IIRC, Axlon started it with its RAMDISK. They chose the middle 16K of 48K because OS interrupt routines made frequent use of lower RAM and ANTIC used upper RAM for the display. I tried, in my BYTE article, to use 32K banks, but Atari finally set the standard to 16K with the 130XE.

Looking at the Atari 800 OS Manual and Listing, I noticed that the routine that figures out total RAM size does so by testing memory in 4K blocks. Shades of the prototype hardware? The OS Listing shows evidence of the old prototype's memory map. There are these strange comments on page 78: ; "A" CART. ADDR'S ARE A000-BFFF (36K CONFIG. ONLY) ; ; "A" CART. ADDR'S ARE B000-BFFF (48K CONFIG. ONLY) ; The first one gives the correct address range for the "A" (left) cart but refers to the old prototype 36K RAM size. The second one refers to the production 48K RAM size but give the wrong address range. In the 1st post, notice that the prototype left cart range was $B000-$CFFF. Maybe these comment lines were hastily edited when the memory map changed?

Atari 800 Engineering Serial 26 prototype - with original 36K RAM but modified by Atari to reflect production memory map, OS, and BASIC. See this thread. Atari 400 plus Axlon RAM-CRAM - self-modified for 48K RAM. Atari 800 - self-modified for 64K RAM, plus AXLON RAM-CRAM self-modified to 128K RAMDISK, plus self-made SoftCart, plus self-made EPROM burner. See here. Atari 800XL - self-modified for "Quarter Meg" RAM, plus partial Supervideo mod. See this one.

Thanks. I just found the paragraph in the Hardware Manual that says that.

Nice chart but here's a question: In those lo-res bitmap modes with pixels more than 1 scan line high, does ANTIC fetch the same data every scan line or does it only fetch them for the 1st line and store them in the shift register for following lines?

You consider that a worst buy? That was a steal. Yes, they did steal his $5 for a POS C128.

A hand-wired circuit might barely fit into the old OSS cart case. If this thing works and if there's enough interest and if someone with PCB layout ability volunteers, then we could make a version with SOICs that would fit into a cart case.

Maybe so, but I suspect it was because so many Atari users (like me) were buying Commodore monitors, which supported separate luma and chroma.

Is there an ATR of this so one can run it on an Atari?

I don't know anything about XEP-80 or the R: and X: devices, but when I wrote ACE-80, I hooked it into the OS's S: and E: devices. That is how I plan to support 80-column text with the LEM. Is there anything wrong with that?

The cart will let the OS boot normally and the enhanced video will not be active. The disappearing ROM in the cart will hold the graphics support routines that will activate the enhanced video. A la ACE-80, the ROM will not displace your top 8K of RAM. Rather, it will load a small kernal into RAM that enables and calls the ROM when needed.

Very nice. Thanks for posting. Was this once a program for the 800?

The FRAM is about $5. LSTTL chips, about $5. EPROM, maybe $2. Video connectors, maybe $5. PCB, maybe $20. Assembly and testing time, maybe 2 hours. Rough total, at least $50. Probably more than your Atari is worth on eBay.

Yes. No, keep the GTIA luma too. Yes, we would probably want the enhanced luma to be about equal to the existing luma value of 8. Then you could program GTIA to add smaller luma values (like 4 and 2) to get several gray levels, no? AFAIK they are available components - tiny 8-pin SOICs. I have found one on-line source (see previous posts) but have not bought any yet. Guess I'm waiting to hear from you all how much interest there is. Maybe Bob is already experimenting?

The nice thing about this FRAM is that it can clock out its data serially all by itself. With normal RAM (SRAM or DRAM) the video circuit must constantly supply sequential addresses to read out the video data. If you use a CPLD or FPGA, then it's no big deal to put in an 18-bit counter to supply the addresses, but if you want to use just a few TTL chips, then you need a serial RAM of some kind with its own address counter. The only large serial RAM I could find online was this FRAM. Its serial output is fast enough for 640-pixel-wide video, but its serial input is limiting. A simple circuit that writes 1 bit at a time would be fairly slow (see previous posts). A faster circuit with a shift register and timing logic would again require too many TTL chips or a CPLD or FPGA. But once you commit to a CPLD or FPGA, you might as well use a standard SRAM. So, I think that the FRAM is most useful for the case of the small TTL circuit. Only if you also double the output clock rate.

I don't intend to build a PBI version just yet, but others might. As I have posted, I would like to build an experimental version from an old OSS cart I have lying around. If we do eventually make a PBI version, then any advice on compatibility with other devices would be very welcome. Never say "can't" but it would be difficult to modify the Atari sync signals to increase the vertical resolution. The simplicity of this design comes from the fact that we are just summing the enhanced video with the standard Atari video signal which contains sync and timing for only about 200 visible scan lines. Bob posted an idea a while ago about generating new sync signals with another FRAM, and that could provide more vertical pixels.

The one I'm proposing will be cart-based and the FRAM will be in the cart. Alternatively it could connect to the PBI. We kicked around the idea of interlacing or generating component video at higher vertical resolution but then it can't overlay the standard Atari video. Any volunteers?

I'm thinking about building it this winter, but Bob has been pretty quiet lately - I suspect he's already working on something better. BTW, the design I posted above is easily expandable by adding FRAMs in parallel to increase bit depth. 2 FRAMs would give 640 pixels of 4 gray levels, or 160 pixels of 256 colors. 4 FRAMs would give 640 by 16 grays or 160 by 65,536 colors!

Please explain.

It just occurred to me that the hi-res, monochrome, 640-horizontal-pixel mode could also become a new color mode through artifacting. We all know that the 320-pixel mode creates artifact color in the composite video signal: 2 bits per color clock gives you 4 possible colors: black, white, red, and blue. With 4 bits per color clock, we can get 16 possible colors: black, 2 grays, white, and 12 various colors. In fact we get the same 16 colors that the Apple II had on its lo-res 40x48 graphics mode, because it generated colors in exactly the same way. Only we can do it at much higher resolution, 160x192. The only change to the LEM circuit would be an option to feed our enhanced video signal into the composite chroma and composite video channels, in addition to composite luma. As before, this could all be overlaid onto any Atari graphics mode, providing up to 64 colors at 160x192. Would that be useful?

Here's a block diagram of what I plan. The gate symbols represent discrete logic. The OSS cart already has the register, EPROM, and RAM/ROM switch logic. I would add the FRAM, oscillator, and video amp, plus some firmware. Thanks to Rybags for the name!

In the simple circuit I plan, the FRAM will be write-only with respect to the CPU. It will run in read mode only during video generation, independent of ANTIC. Others may wish to implement more sophisticated circuitry which might also provide CPU read access to the FRAM. Then one could even take advantage of the non-volatile feature of the FRAM. I plan to overlay the FRAM video onto the ANTIC/GTIA video, providing many possible combination graphics modes, up to 640 pixels horizontal.