Nearly 4 years ago, three of our well respected forum members sat down one evening over a curry and came up with the One Page Computing OPC Challenge.

viewtopic.php?f=3&t=372#p2400

I realise that in these strange times, sitting down for a curry with friends might seem an ancient memory, but as we have some spare time on our hands, and to help maintain our sanity, I would like to propose a follow up challenge - the 1 K computing challenge: OK Challenge

Twitter hashtag: #weareOK

The rules are simple and trivial:

1. You may choose any cpu of your choice, or create your own

2. You have a strict ROM budget of 1K 16-bit words (or 2048 bytes)

3. Create something awesome using 1 and 2 above.

4. Assume that you have 64K bytes of RAM available

5. You must be able to print "OK" to a serial terminal.

The aim of this challenge is to be fun and educational. Its the online equivalent of a high school "show and tell".

It is also designed to get people thinking about how to do more with less.

I encourage the formation of "teams" to get together on Zoom or whatever, and submit a team entry.

I also suggest that interested parties regulary post their ideas and progress to encourage others to participate. You can talk about your choice of processor, your motivation and anything else that you think is relevant.

This is intended as a fun, educational project to get us through the next 3 months, to boost discussion, debate and idea sharing.

It builds upon the original OPC Challenge and stimulates new thinking about alternative cpus using limited resources.

Home Schooling for Nerds?

The three original OPC gurus will be invited back to comment and judge the competition.

Finally for inspiration and motivation - I dig up an ancient language that ran on a 6800 in just 768 bytes. VTL-2 "Very Tiny Language"

http://www.altair680kit.com/manuals/Alt ... chable.pdf


PS. The challenge has been designed for efficiency of code and ingenuity. You could use an 8-bit 6502, Z80, AVR, or an 8086 or MSP430.

Alternatively you could create your own byte-code interpreter. The choice is yours.

As Dr. Dobbs used to say in 1976, 45 years ago: " Running Light Without Overbyte "

An excellent idea!

To be fair to RISC cpu's, say 2KB for 16 bit RISC's and 4KB for 32 bit RISC's compared 1KB for 8 BIT CPU's.

Ben,

The purpose of this challenge is to do more with less.

You can easily define a virtual cpu in 2K bytes and then you have a full 64K of RAM to execute code on it.

I'm not excluding 32-bit cpus, but the ROM limit will remain at 2048 bytes.

It's an interesting metric on code density and the expressive power of an ISA: to what degree do 1k 16 bit words give you as much scope as 2k 8 bit bytes.

I think this is one of the reasons that Wozniak's SWEET16 retained an 8-bit instruction size. If a 16-bit literal or jump address was needed, it followed in the consecutive 2 bytes.

It also built on the 6502s existing byte addressing, for the instructions, rather than create a more complex word addressing scheme.

When I experimented with a simulated cpu, with a 16-bit wide instruction, I found that I often had difficulty filling the lower byte, so that it was left as zero, and effectively "wasted".

To partially compensate for this I added some extra instructions that allowed for 8-bit literals, immediate operations, and indexed addressing - but I still had a lot of empty lower bytes.

Wozniak's SWEET16 instruction set has some deficiencies, when compared to a more general purpose cpu of mid-1970s era.

Having a logical AND and possibly XOR would allow masking of data within the 16-bit register, and some 8-bit literal instructions would assist when dealing with byte or character data.

There are 3 spare slots in his instruction table - which could be used to some advantage.

SWEET16 currently runs to 371 bytes of 6502 code. Add a few extra instructions and you would have a compact 16-bit interpreter running within an 8-bit environment. So for the OK Challenge, your interpreter is say 512 bytes, leaving another 1.5K bytes for perhaps a tinyForth-like language?

Whilst the SWEET16 interpreter runs at about 1/10th the instruction rate of the native 6502 code, this might not be such an issue as CMOS 65C02 will clock at around 14MHz.

The other approach is to use a 16-bit instruction with fields that directly control the hardware without further decoding. The PDP-8 did this with its IOT and OPR instructions, as does James Bowman's J1 Forth processor, which uses most of the lower 12 bits of the instruction for stack pointer manipulation and stack to stack moves.

Another source of inspiration for the OK Challenge, could well be the CHIP-8 interpreted language and virtual machine. Originally implemented on an experimental TTL processor by Joseph Weisbecker, it was adopted by RCA and implemented on the 1801 and subsequently the 1802.

The interpreter resided in the first 512 bytes of the RCA 1802 address space and provided a group of general purpose registers and some fairly useful instructions for writing simple game applications.

https://en.wikipedia.org/wiki/CHIP-8

In complete converse to SWEET16, CHIP-8 used a 16-bit long instruction and implemented 16, 8-bit registers.

The 35 instructions include AND, OR, XOR, ADD, SUB, SHL and SHR. ADD and SUB operations provided a carry, so could be extended to multi-byte math operations.

Originally CHIP-8 was intended to interface to a hex-keypad and drive a 64 x 32 pixel monochrome TV display.

With such a small display area, any characters had to use a very small font.

This link is for a 3x5 font which is coded to fit into only 2 bytes per character.

https://hackaday.io/project/6309-vga-gr ... icense-mit

This is probably worth a new thread...

Thoughts about a high-density ISA