ClausB

All I found was this 1980 ad:

Anybody seen @Keatah? He hasn't been here since June. He hasn't been on Applefritter in over a year. Today is the 20th anniversary of his joining AtariAge.

Got pics? What CPU? What drives? What OS?

From Goldberg & Vendel, 'Business Is Fun':

Any update?

Well, MAP-1 above refers to an 8K Byte Saver board, which was S-100: https://en.m.wikipedia.org/wiki/Cromemco_Bytesaver

I'm not sure whether or not this Colleen Development System was itself an S-100 machine. Anyone know?

https://archive.org/details/LNBUG2 Interesting Colleen prototype memory maps on pages 16 and 20. CTIA, ANTIC, POKEY, PIA addresses line up with those in this thread's first post.

Wow, I missed this when you posted. Interesting Colleen prototype memory maps on pages 16 and 20.

E80 and ACE80 do it.

Ah, thanks for the hint. Long time since I've seen the movie. Looks like 64x20 characters. Didn't someone do a 64-column driver for Ataris?

Looks a bit like the old Star Trek text game, no?

I modified my original animation to run in 40K using fast line draw routines from SubLogic: TRON2.XEX

Maybe they're just Commodescending.

True enough, but BASIC came with nearly every computer, and so became the default language, even for professional programmers who marketed their application software to home computer owners, many of whom did not learn to program at all. And BASIC served them all until the end of the 8-bit era (present company excepted).

Yes but there was another reason for the design change, this from the electronics side: In 1978 the price of 16K RAM chips fell by nearly a factor of four, while the 4K chips' price stagnated.. Even cheaper were 8K chips, identical to the 16Ks but with defects in one half or the other. So Atari redesigned their 400/800 RAM board to accommodate the newer chips and abandoned the 4K design. See: and:

Is there an option to turn off refresh cycles, for those systems with SRAM only? That would add 0.14 MHz more CPU speed.

Have you tried it on hardware? Do you see any flaws, like flashes of black lines, or uneven frame rate? Thanks.

Thanks for testing! Yes, well, it could have been red originally. In 1983 I made it from memory (I didn't have YouTube then, not even VHS) so the shape isn't quite right either. I was lucky it was even orange, since I did it on a B&W TV!

Had some trouble after sync'ing to VCOUNT to wait for the display list to finish before clearing the bitmap for the next frame. Discovered that some frames take a bit too long for 15 fps. Was getting 14.5 on average. Had to resort to a look-up table for the *40 routine (instead of the optimizations credited above). Also had to disable the deferred VBIR with a SEI. Now it averages 15 fps, though a few frames are long and a few are short. Tested in emulation only. Please test on real hardware and report back. Runs in 40K RAM: TRON2.XEX Edit: Don't forget to press START after it loads and the screen goes black.

I meant the ST. 😛 Very hard to see.

Ah, yes, the famous wood varnish model.

Hmmm, I struggle to see the usefulness of 1 millibit. Did you mean 1 MB?

Working on my TRON Recognizer animation from 1983. Originally (below) it rendered 72 frames of GR.22 bitmaps, 2K each, and played them back at 15 fps on an 800 equipped with the Axlon 128K RAMdisk. Using my ported SubLogic FS1 line plot routines, now it can draw and erase each GR.23 frame in less than 1/15 second, so no need for so much RAM. The raw speed is measured at 1152 lines per second! Of course, most are short lines, and a few of the 59 lines per frame are clipped away, and the CPU runs faster in GR.23 than in GR.24. The original BASIC program rendered the animation over an hour or so and saved 144K of bitmaps to 2 SD floppies. An assembly program played it back on the Axlon at 15 fps with sound effects. I modified the BASIC program to save and clip line endpoint coordinates instead, only 17K. An assembly program feeds those coordinates to the FS1 plotter. A side-effect of using GR.23 is more colors, so I took advantage (above). Some work remains, such as double-buffering and sound. Thanks to @tebe and @Rybags for inspiring some optimizations.