Not very far away, and not very long ago, @monsonite has issued a roll-your-own challenge, for anyone to cook up an interesting program using only 1k words, or 2k bytes of ROM (and up to 64k of RAM):
One K Computing - Roll Your own Challenge
Personally I rather like word-addressed computing…
(The idea of a roll-your-own-challenge is that there is no rules lawyering - just take the general idea and have fun. Share your work. No prizes.)
Ed,
Thanks for the shout out, here on Retrocomputing.
The aim of this challenge is to encourage ingenuity under adversity.
Choose any microcontroller or cpu - or even invent one for yourself.
For inspiration I can offer Wozmon and Sweet16 for the 6502, VTL2 for the 6800, Tiny BASIC and Mouse.
Create something that does something awesome using just 2Kbytes of ROM, and 64Kbytes of RAM.
How about a retro-programming system that receives 960 bytes over a Teletext or Prestel interface and produces a 6 colour text display?
Just imagine it’s 1975 again and every Kbyte costs you $20.
I am sure 4K x 1 DRAM was $20 each back then, but I never saw 4Kx1 dram
for sale in the magizines of the time. At least 1 (kindle) book has FORTH in 2K rom.
I just need 2KB of ram just to boot from a sd card. for my 1975 era 32 bit computer
so good luck with the Challange.
1K ROM seems a lot of program space. I have designed a few RAM-only retro computers except a small boot ROM in small CPLD like ATF1504. 64 byte ROM seems a reasonable size because it does not take up too much logic fabric. With 64-byte ROM, it is enough to have dual bootstrap function booting either from the serial port or from the CF disk. In serial boot mode, a 256-byte program like an Intel Hex file loader is loaded which can load and run bigger program. I read in 6502.org discussion about bootstrap ROM under 30 bytes and we all know WOZMON is only 256 bytes. So 1K seems a luxury.
Life on Z80ALL 64x48 - YouTube is a simplistic Conway’s Game of Life for Z80 in lesser than 512 bytes. It doesn’t use much memory because the data array resided on the 4K video RAM itself
The 2 K bytes of ROM is intended to be permanent storage under the usual definition of ROM. It also includes any other permanent storage medium including paper tape, punched card disk or magnetic tape.
The 64K bytes of RAM can be assumed to be nonvolatile, and lose all information when the power is lost.
That’s what I thought… an appliance, or a simple computer: Forth, maybe a tiny Basic, or Chess, or an RPN calculator… an alarm clock, perhaps.
It might be worth looking at the CHIP-8 games too. They were based on an interpreted language, and used several techniques to minimise ROM usage, such as reduced character set fonts, and a small screen size, originally just 64 x 32 .
The interpreter occupied the first 512 bytes of ROM.
Compressed fonts are one possibility - such as a 7 segment format, which themselves offer some scope for further compression.
Alternatively, with a high baudrate serial (1M baud) a terminal screen can be refreshed very quickly, and the character generation overhead is delegated to the terminal.
TinyBASIC will fit into 2K - I used to have a TinyBASIC ROM for my MicroProfessor Z80 trainer, which scanned the keyboad and updated a 6 character display.
Other interpreted languages, such as a subset of Forth might also make good candidates.
I listed some small languages on my blog a few years back:
Maybe a machine code monitor: disassembler is nice, but an assembler is a Programming Language!
Some ideas perhaps in the link Ben shared: Software that goes bump on the screen
When I say alarm clock, I include stopwatch and noodle timer. Maybe too much to report time of sunrise and sunset (serious trigonometry needed.)
Certainly for the 6502, WozMon fitted into 256 bytes, but had access to the Apple 1 character printing and keyscanning routines. Once you take these dependencies into account the total will be somewhat higher.
Some form of VHF modulated or composite video output might be possible, as has been demonstrated on an ATtiny85. In this case it is written in C and has a full character set - so some code reductions might be possible.
Compared to the classic micros of the mid-1970s (6502, Z80) etc - we now have the advantage of speed.
An AVR can be overclocked to about 30MHz and most of it’s instructions are only 1 clock cycle long. Potentially this means that a 30 fold speed improvement over the fastest of the Z80 instructions.
If you remember that the Sinclair ZX80 started life with a 4K BASIC ROM. This contained an integer BASIC interpreter, monochrome 64 character tables, keyscanning and cassette interface.
Li-Chen Wang’s Palo Alto Tiny BASIC fits into as little as 1.77k bytes and was written for the 8080. As it used a serial terminal for communication - there was no need for keyscanning, character tables or video generation code.
Compressed fonts based on a 4x6 pixel character are available.
This Hackaday project further compresses them in to 3x5 which is encoded into just 2 bytes per character. So a full ascii implementation of 96 characters would be 192 bytes.
It seems to be quite readable, but I’m slightly troubled that ^ and ~ have identical patterns.
The Commodore 1520 plotter encoded an entire vector font in only 661 bytes of ROM. Whether a useful decoder could be written in the rest of the 1K is left as an exercise (which really means, I dunno). The entire plotter driver ROM was 2 KB. Code is here: reloaded/1520 at master · Project-64/reloaded · GitHub
The font’s encoded one line/move instruction per byte, using 3 bits for each of the X & Y coordinates:
; %EXXXYYYP
; E - last command in list (1)
; X - x coordinate (0-7)
; Y - y coordinate (0-7)
; P - use pen (1), or just move (0)
Not the prettiest font, but legible and scalable. I keep meaning to implement it for tiny screen displays in MicroPython.
Interesting, this shows that vector fonts can be encoded fairly efficiently, at least as efficiently as some very small character fonts - such as 4x6, which are at the limit of readability.
The original OK (One K) challenge was aimed to ensure a degree of fairness between 8-bit and 16-bit systems, by suggesting 1K words or 2K bytes.
This gives you almost 1400 bytes to write some sort of interpreted language or font decoder.
As an aside - the early graphic terminals were based on vector graphics with high-persistence CRT displays with digital to analogue converters to provide the X and Y deflections.
This not only gave the possibility of fairly high (monochrome) resolutions, but dispensed with very costly memory otherwise needed for display buffers.
The “Vectrex” was an early 1980s home games console based on vector graphics. It provided a similar playing experience to arcade games such as Asteroids, also based on a vector display.