Last updated on 3rd November 1997
Maintained by Paul Robson (autismuk@aol.com)
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.
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.
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)
Several add ons were mooted, but it is not known if they ever came to fruition. However, amongst the less speculative ones were......
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).
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....
Yes, there are - well is - one , to be precise, for DOS.
It's called Ace32 and it was written by me. It is at http://users.aol.com/autismuk/ace/index.htm.
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)
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.
0000-1FFF |
8k ACE O/S and Forth Interpreter/Compiler ROM |
2000-22FF |
(Unused) |
2300-23FF |
256 bytes used for Cassette Header Information |
2400-26FF |
32 x 24 Display. Bit 7 indicates inverse (black text on white), Bits 6-0 indicate a character in the Character Definitions Table |
2700-27FF |
Edit Buffer end ? Startup writes '0' here but little other obvious function. |
2800-2BFF |
(Unused) |
2C00-2FFF |
128 x 8 byte character definitions, representing display characters 0..127. |
3000-3BFF |
(Unused) |
3C00-FFFF |
Program |
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 |
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 :-
0028-002B |
Cold Boot - Check Memory Size |
0033-0041 |
Initialise RAM Data 3C24-3C4F |
004B-0052 |
Clear Screen and Edit Buffer |
0052-006D |
Define 64 x 48 pixel graphics characters |
006E-008D |
Copy Character Set from ROM to Memory |
008E |
Enable Interrupt and goto QUIT |
013A |
Interrupt Routine |
013A-013F |
Save CPU Registers |
0140-0144 |
Short Delay , no idea why. |
0144-014A |
Increment Timer |
014B |
Call Interrupt, Read Keys |
014E-016D |
Handle Caps/Graphic/Reverse modes |
016E-0175 |
Edit processing (?) |
0176-017D |
Tidy up and Exit |
0310 |
Interrupt Routine - Keyboard Read |
0310 |
Call Keyboard Scanner |
0310-0335 |
(?) |
0336 |
Return in A Current Key Pressed |
0336-036C |
Get Virtual Key Number to DE |
036D-036F |
Return zero if none pressed |
0370-0375 |
Look up ASCII value |
0376-039D |
ASCII Lookup Table |
044D-0457 |
For address words - pushes (*DE) [byte] + 3C00 on data stack |
07FA-0806 |
Clear Memory between DE and HL (set to 20 hex, space) |
0808-0810 |
Make A Upper Case |
084E-0858 |
Pop word from data stack to BC |
0859-085E |
End of code for RST 18h |
0A24-0A42 |
Clear Screen code |
18A7-192C |
Read in one data block or header. |
1A75-1AB6 |
Load / Bload code. Scans through tape for given file name |
1AB9-1AF2 |
Physically loads an image into memory |
Memory locations in RAM and the value they represent are listed here.
3C18 |
Top of Memory + 1 (word) |
3C1C |
Screen write position (word) |
3C24 |
Start of Editing position (word) |
3C26 |
Status word, unknown function |
3C28 |
Shift Status : Bit 0 = Edit allowed, Bit 1= Caps Lock, Bit 2 = Graphics, Bit 3 = Reverse |
3C2B |
Clock (double word) |
3C31 |
CURRENT (word) |
3C33 |
CONTEXT (word) |
3C37 |
HERE (word) |
3C3B |
Data Stack Pointer (word) |
3C3D |
Error Code (Byte) |
3C3F |
Base (Byte) |
3C40 |
FORTH word (first in memory,installed by ROM) |
3C51 |
Start of user program memory |
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) |
n |
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. |
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 |
Some of the Ace's Forth is not intuitively obvious, varying from the Forth-79 and Forth-83 specifications.
Redefine
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
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
list <word> lists one of the words in the dictionary, decoding it.
Definitions
(unknown)
Base
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.
Vocabulary
(unknown)
Vlist
vlist lists the words defined in the Forth dictionary.
Runs>
(unknown)
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'.
Most of the work on this was done by Simon Owen.. si@obobo.demon.co.uk
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 (autismuk@aol.com) 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 !)
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 :-