In article <4bG_AnC00Vp707JLEC@andrew.cmu.edu> bm21+@andrew.cmu.edu (Bret Jonathon Musser) writes: |Does anyone else remember the Elf II??? I'm sure many of you know Tiny Basic. Well, I remember the Elf II, but I remember the Super Elf better. These machines both used the RCA 1802, and were based on a cheap computer design called the `Elf' that appeared in POPULAR ELECTRONICS. The basic `Elf' had 256 bytes of RAM, and I/O was via 8 toggle switches and some LED displays. My father, however, had a Super Elf, an `expanded' model with 4.25K of RAM (32 1Kx1 2102's and 2 256x4 2101's), a hex keypad, and a video display as well as the LED's (more on the video below.) The Super Elf came in a kit. I can't remember if the Elf II came preassembled or not. RCA also had its own hobbyist 1802-based machine, the `VIP'. The 1802 was an interesting processor because it had built-in DMA. This enabled you to have a very cheap video display: RCA came up with another chip (the 1861) which triggered DMA to suck bytes out of the processor's memory, and then assembled them into scan lines and put them on the screen. There was exactly one resolution supported: 64x128 B&W pixels. Hence, a frame buffer was 1K long. This was a problem for people using basic Elfs with only 256 bytes of memory. The solution was to wait for a vertical retrace interrupt, and then to time things cleverly so as to reset the DMA pointer just before each horizontal scan line. RCA provided code to do this and replicate each horizontal scan line 4 times, thus cutting down the frame buffer size to 256 bytes. If you only had 256 bytes of memory, though, you were still stuck with seeing your code on screen as well as your data. If you wanted to avoid this you had to cut the resolution still further. When we ordered Tiny Basic, it came on a paper tape. Unfortunately, we didn't have a paper tape reader (only a cassette interface.) This problem was solved by reading the tape with an ASR-33, printing it out on paper, and entering it by hand. Another problem was that Tiny Basic needed ASCII input/output routines. The output problem was solved by using some character generator routines called DOTS, from Tom Pittman, perhaps? (I can't remember where we got these from.) These used a variable-width character set. Some letters, like `M', got 5x5 pixels; `I' only got 3x5 pixels. The display was set up to replicate every horizontal scan line 3 times or so (no-one used the 64x128 display at its full capacity because then it had a horrible pixel aspect ratio, 1:4 or something.) The input problem was solved by typing in ASCII codes on the hex keypad. The final result did not work terribly well. One of the problems was that Tiny Basic took up 2K, and DOTS took up another ~1K, leaving little room for programming. Another problem was that Tiny Basic was a *two-level* interpreter, meaning that it was terribly slow (but small!) Video synchronization was another difficulty. Most instructions on the 1802 executed in 16 clock cycles. However, long jumps needed 24 clock cycles. Tiny Basic made heavy use of the 24-cycle instructions. This confused the 1861 and made it display hash while a Tiny Basic program was running (un