The Jupiter ACE FAQ

Last updated on 3rd November 1997

Maintained by Paul Robson (

Please send all corrections, ideas etc. to this address. This document is a very early version and no doubt contains a lot of errors. I would be grateful for any and all corrections, or further information.

1. What is a Jupiter Ace ?

A Jupiter Ace was a home micro produced at the peak of the home computer boom in the early eighties. It was unique in being the only home micro which used Forth as its standard programming language. The standard Jupiter Ace came with 3k of RAM, of which 1k was available for programs, and 8k of ROM. The keyboard was a springy rubber keyboard not dissimilar to the ZX Spectrum, but with smaller keys. The display was 32 x 24 monochrome, with 128 different characters allowed, both in normal and reverse. Sound was provided by an internal buzzer. There was a 300 baud / 1500 baud tape interface.

2. A brief history of the machine.

Jupiter Cantab was formed by two ex-Sinclair Research employees, Steven Vickers and Richard Altwasser. Following the development of the ZX81 they set up their own company (Cantab is short for Cantabridgian,e.g. of Cambridge) in 1981. Their first and only machine was the Jupiter Ace.

Whilst receiving initial plaudits for its unique use of Forth, and its economy with memory, and its speed, it was unsupported by Software houses and was only bought by a minority of hobbyists, who were largely Forth fans already (like me !)

The FORTH was quite powerful and fast, and had a then unique ability to edit Forth definitions in the dictionary on the fly, rather than using 'Screens' as most Forths of that era did, but many thought it was too complex for beginners to learn. Its main competitors , the Spectrum and C64 both had colour and more memory, and far more software.

A machine with a 16k RAM Pack built in was announced , but before it reached the market Jupiter Cantab went bust in 1984. The machine was then taken over by "Boldfield Computing Ltd" who produced some software for it. Little is known about its later history. (all contributions welcomed)

3. What add-ons were available ?

Several add ons were mooted, but it is not known if they ever came to fruition. However, amongst the less speculative ones were......

  • Fuller announced a replacement keyboard with a new case for the machine - the Ace was dissembled and placed in a new, stronger plastic case. Whilst adverts were placed for this, it was never supplied (despite a lot of nagging and I didn't get my money back - doh !)
  • A couple of 16k RAM Packs were announced. I purchased one from "Stonechip Electronics", and remember it being a pretty stable piece of hardware. The Ace could use 8k and 48k ZX81 RamPacks, apparently.
  • Jupiter Cantab designed a colour add-on, which was never supplied, in an attempt to rectify the one big deficiency of the machine. This , too, was never supplied. I have read that this was later published in an "Electronics Magazine". If anyone has more information on this, please let me know as I'd like to build it into the emulator.
  • There was a Joystick. Boldfield software has a joystick routine included, where appropriate. It is likely this was a similar design to the Spectrum Joystick, but which type I do not yet know.
  • The Boldfield Computing 'Utilities' tape has software to drive a Printer, an RS232 Interface and a Sound Box of some kind. I suspect these were ZX81 hardware add-ons (lets face it, it'd be the sane thing to do...)

4. What software was produced ?

There is a small software library available.

Thanks to Si Owen for reporting the existence of (i) a "Five Ace programs" tape and (ii) software distributed by "Boldfield Ltd", who apparently took over the Ace after Jupiter Cantab went broke.

The "Five Ace Programs" (Banner, StackDemo, Worms, Jupiter, Lunar) are now available.. Thanks to Si Owen for providing and translating them. Hopefully more programs will become available soon. The Jupiter Ace seems to have no 'auto run' facility, so it is necessary to do a vlist command to check what words will run the program.

Thanks to Tim Skinner, one of the original authors, there is now a small selection of "Boldfield Computing" software available to run , including versions of "Frogger" and "Atic Atac", and a text adventure. There is also a utilities tape, which has been split up in the library

There was not much commercial software for this machine. If you have some, let me know so I can add it to the FAQ. If you have it, I would like you to contact me so I can convert it for use by the emulator. Because of the strong similarity between the Spectrum and Ace, Spectrum conversion tools should work too. See section 11 for more information. If you have any software, please share it !

It is possible to convert Ace tapes yourself if you don't want to send them to me or Simon Owen. If you do so, please send me a copy of any images you get so I can keep the library up to date.

Any software on tape or paper gratefully received. If you have access to a scanner and OCR software, it should be possible to scan in and recognise magazine programs, and convert them to a text file. They can be read in using the spool facility in versions after 1.3 of the Ace32 emulator, which works properly in version 1.4 (sorry).

5. How do I get one now ?

Well, you can't buy a new one any more ! Your best bet would be old computer shops, retro stores, car boots , or advertising on comp.sys.sinclair and comp.lang.forth. The parts are standard TTL or LSI components, so repairing a faulty one should not be impossible. The ROM image is available as part of the emulator distribution.

If you are really desperate, it should be possible to build one from a schematic....

6. Are there any emulators available ?

Yes, there are - well is - one , to be precise, for DOS.

It's called Ace32 and it was written by me. It is at

The current version is 1.4 - it supports most of the Ace hardware, including the Tape I/O (.TAP files and Snapshots are used).

The distribution includes a copy of the Jupiter Ace ROM image. AFAIK there are no problems with this - I do not have a clue who bought the remnants of Boldfield Computing when they went broke. (I can't find any trace of their existence)

If anyone wishes to write an emulator there are sufficient details here to allow you to do so. Feel free to ask any questions. The emulator is freeware, and the source will be released, but it is all assembler so a port would be difficult. It is not publically released, but if you want to see it I can arrange it.

Modifying a Spectrum Emulator to emulate a Jupiter Ace would not be a very difficult task. (That's actually how ACE32 was written)

7. Hardware Information

The Central Processing Unit is a standard Z80A at 3.25 MHz. The machine was provided, by default with 3k RAM, of which 1k was available for programs, and 8k of ROM. Program memory could extend from 3C00-FFFF, giving a total of 49k max program memory. The most common configuration was 19k (addition of a 16k RAM Pack)

Most of the information in this section was mostly figured out while disassembling the ROM to write the emulator. I do know, for example, if the 3k of RAM between 2000 and 4000 is partially decoded to enable writing to Character Memory in Vblank (and HBlank) only, but I am not exactly sure how it works.

The 50Hz Vertical Sync signal is attached to the Z80's IRQ line, generating an Interrupt 50 times a second.

Memory Map


8k ACE O/S and Forth Interpreter/Compiler ROM




256 bytes used for Cassette Header Information


32 x 24 Display. Bit 7 indicates inverse (black text on white), Bits 6-0 indicate a character in the Character Definitions Table


Edit Buffer end ? Startup writes '0' here but little other obvious function.




128 x 8 byte character definitions, representing display characters 0..127.





I/O Ports

Port $FE is the tape and buzzer output port. The buzzer is triggered by outputting to port $FE - a bit does not have to be toggled as in the Spectrum Design.

Port $FE is also the Keyboard Input port. Similar to the Spectrum design, the High 8 bits of the address (e.g. for in a,(nn) its A and for in reg,(C) its B) is used to select the lines to be read. These are active low - the line being read needs to be set to zero.

Taking a line to zero makes all the bits in the corresponding line zero if the appropriate key is pressed. If more than one row is selected, it is the result of ANDing together the read bytes. The three lines that are not connected (bits 5-7) are all '1'. (can someone check this on a real Ace please ?)

e.g. Keyboard scanning code would look like the following.

ld bc,0FDFEh

; high address is $FD, port address is $FE

in a,(c)

; bits 0-4 of a contain zeros in bits 0-4 if , respectively, keys A S D F and G are pressed, one otherwise.

and a,01Fh

; not strictly requred, but I am not sure about bits 5-7 & its good programming practice anyway...

In the ACE Rom, the address popped off the data stack is 16 bit, so (with 16 BASE C!) 0FEFE IN . will display the key depressions.

Bit 0 is zero Bit 1 is zero Bit 2 is zero Bit 3 is zero Bit 4 is zero
Bit 0 (0xFE) Shift Symbol Shift Z X C
Bit 1 (0xFD) A S D F G
Bit 2 (0xFB) Q W E R T
Bit 3 (0xF7) 1 2 3 4 5
Bit 4 (0xEF) 0 9 8 7 6
Bit 5 (0xDF) P O I U Y
Bit 6 (0xBF) Enter L K J H
Bit 7 (0x7F) Space M N B V

8. ROM Information

Throughout the entire ROM IX points to the start of available memory at $3C00 and IY points to the execute next vector, $04C2. Almost all machine code words end in LD PC,IY. I am currently translating a German disassembly of the ACE Rom kindly provided by the ZXTEAM in Germany, which is far more comprehensive than what I have done below (basically I did enough for the emulation)

The 8 Z80 Restart Vectors are as follows :-

RST 0h

Restart the Jupiter ACE (Cold Start)

RST 8h

Print character in A on screen

RST 10h

Push Word DE on the Data Stack

RST 18h

Pop Word DE off the Data Stack

RST 20h

Stop execution with error A / Warm Start

RST 28h

Not available

RST 30h

Not available

RST 38h

Interrupt Routine

Memory Locations and Code whose function is known currently are listed below :-


Cold Boot - Check Memory Size


Initialise RAM Data 3C24-3C4F


Clear Screen and Edit Buffer


Define 64 x 48 pixel graphics characters


Copy Character Set from ROM to Memory


Enable Interrupt and goto QUIT


Interrupt Routine


Save CPU Registers


Short Delay , no idea why.


Increment Timer


Call Interrupt, Read Keys


Handle Caps/Graphic/Reverse modes


Edit processing (?)


Tidy up and Exit


Interrupt Routine - Keyboard Read


Call Keyboard Scanner




Return in A Current Key Pressed


Get Virtual Key Number to DE


Return zero if none pressed


Look up ASCII value


ASCII Lookup Table


For address words - pushes (*DE) [byte] + 3C00 on data stack


Clear Memory between DE and HL (set to 20 hex, space)


Make A Upper Case


Pop word from data stack to BC


End of code for RST 18h


Clear Screen code


Read in one data block or header.


Load / Bload code. Scans through tape for given file name


Physically loads an image into memory

Memory locations in RAM and the value they represent are listed here.


Top of Memory + 1 (word)


Screen write position (word)


Start of Editing position (word)


Status word, unknown function


Shift Status : Bit 0 = Edit allowed, Bit 1= Caps Lock, Bit 2 = Graphics, Bit 3 = Reverse


Clock (double word)


CURRENT (word)


CONTEXT (word)


HERE (word)


Data Stack Pointer (word)


Error Code (Byte)


Base (Byte)


FORTH word (first in memory,installed by ROM)


Start of user program memory

ROM Dictionary Layout

This describes the format of the dictionary for a word at address 'n'. The 'centre point' of the word header is based around the length byte. The last word in the ROM dictionary is at address 1D58.

NOTE : The dictionary format for RAM words is slightly different, having a further word between the name and the previous word link. I am not sure to what this refers.

n - 2 - Length

First letter of name

n - 3

Last letter of name (bit 7 set)

n - 2

Address of previous word in list (word)


Length (bits 0..5). Bit 6 set if word is compile-only.

n + 1,n + 2

Address to jump to to execute word

n + 3

Start of word code. In DE when jump through n+1,n+2 is done.

9. What do the error codes mean ?

The Ace returns error codes rather than text messages. This section explains what they mean.

Error 1

Out of Memory

Error 2

Stack Underflow

Error 3

Break from program (Shift+Space)

Error 4

Compile mode only.

Error 5

Structure Imbalance

Error 6

Name too long

Error 7

Illegal Pick Value

Error 8

Floating Point division by zero (no error for integers,returns -1)

Error 9

Erroneous 'AT' command

Error 10

Verify/Save failed

Error 11

Redefine/Forget word missing

Error 12

(not sure)

Error 13

Unknown word

Error 14

Word not listable

10. What do some of the Ace's FORTH words mean ?

Some of the Ace's Forth is not intuitively obvious, varying from the Forth-79 and Forth-83 specifications.


If a word has been edited there will be two copies of it in the dictionary. redefine <word> replaces the earlier word with the later one, and makes sure all references of the delete word refer to the replaced word. The sequence edit <word> redefine <word> can be used to change a word without wasting memory.


edit <word> allows a word definition to be edited, return ending the edit. However, another copy of the word is added to the dictionary, and any words referring to the edited word will refer to the original one. It is a good idea to redefine <word> afterwards.


list <word> lists one of the words in the dictionary, decoding it.




Base is the address of the current base (e.g. to work in hex do 16 base c!). However, this is only an 8 bit value. Doing 8 base ! may cause other problems.




vlist lists the words defined in the Forth dictionary.



Definer..... Does> ;

definer along with does> defines an immediate word used to create dictionary entries . The section between definer and does > is used to build the entry, the section after does> is done when the word is executed, assuming the address of the first data item is pushed on the stack.

example : constant

definer constant , does> @ ;

defines a word 'constant' which compiles the number on the top of the data stack into the word : when the word is run that word is read

4 constant x

define a word constant - the word will have the 4 compiled (via ,) and will read it when executed

x .

will print '4'.

11. Reading in Tape Files

Most of the work on this was done by Simon Owen..

The tape file format is almost identical to that of the Sinclair Spectrum. Tapes were initially read in using the registered version of the "Z80" Spectrum Emulator. These were then provided as data files, as "header" and "data" blocks.

A .TAP file consists of these header and data blocks concatenated together, each block seperated by a 2 byte word giving the size of the block. (Low,High order). This does not include the the size word itself - e.g. the next block size word is found at <address>+<size>+2.

A simple program to construct .TAP files from Header & Data blocks is available from the software library. Information on the snapshot format .ACE is also available from me.

From Si's mail on converting the "Five Ace Programs" ...

The tape wasn't in very good condition and I had to sample both sides at different volumes and frequencies (using the READSB utility that comes with Z80). I did 6 samples, converted the 8 headers and files to data blocks and compared them all to filter out ones that have errors.

The baud rate is compatible with standard Spectrum tapes so I wrote a small program on the Spectrum emulator to read each block into memory. The tape format is the same: 'tone leader, header data,tone leader, data block', but the second tone leader is too short to be caught by the standard ROM, which requires 256 'edges' before it will accept a block and also has a 1 second delay after it toggles the border from cyan to red between edges). I ended up patching the Spectrum ROM image to reduce the delay from 1 second to zero, and also reduced the required number of required 'edges' to be found from 256 to 100.

Another problem is that there is no gap between the header data and the second tone leader so I couldn't work out the length of the header data. Reading a bigger block resulted in the second tone leader being read as header data! It appears that headers are 26 bytes long (maybe 25).

The first byte in the header appears to be some sort of type byte or flag and is always zero. The next 10 bytes are the filename, padded out with spaces. The following 2 bytes appear to contain the length of the main data block, although for some reason I always seem to read 1 byte more! To read the data block I call the ROM routine with a big length and wait for it to get cut short by reaching the end of the data. I then subtract the starting address from the position reached (still in IX on return) to work out the length. Maybe this is what's causing the extra byte... the last byte might be junk.

Paul Robson ( has created a program 'TAPH' which converts a 22khz Mono Sample of a Ace program (such as produced by the Windows 95 'Sound Recorder' program) into a .TAP file, which was successfully used to read in the 'Boldfield Computing' programs. This program was based on the program of the same name by 'Technomancer' (but is a complete rewrite !)

12. How do I convert .TAP files for loading into a real Ace

There is no utility to do this. In theory, the Spectrum utilities should work, but I don't know if anyone's tried it. If anyone has successfully achieved this, please let me know. If there is sufficient demand, I will write a program to reconver .TAP files back.

Thanks to :-

  • Don Gaubatz
  • Adrian Godwin
  • David Hazelwood
  • Peter Liebert-Adel
  • Ron Kneusel
  • Simon Owen
  • Tim Skinner
  • (everybody who pointed out comp.sys.forth should be comp.lang.forth....)

Back to the top