As promised, here is the #jupiterace #forth interpreter and compiler:
https://codeberg.org/pgimeno/JAForth
All thoroughly tested and working like a charm.
I've also expanded the ROM disassembly present at the Jupiter ACE Archive with loads of new information, and in a format that allows collaboration easily:
https://codeberg.org/pgimeno/JupiterROMDisassembly
Next in the plans: a Forth TAP decompiler/lister in Python.
This is frustrating.
As I announced, I've worked for several days in a #jupiterace #forth interpreter, only pending some unit testing to ensure correctness. I wanted to compare the results against a real Juppy, but typing on the Jupiter is cumbersome and checking with the screen is prone to errors.
So I though, "I know, I'll write a headless JA emulator that takes input and writes output from/to file". That took me about an hour.
Now, that one does all the interpreter does and more!
Forgot to say, the port of Mazogs to the Jupiter ACE is now complete. Check it out at https://codeberg.org/pgimeno/Mazogs/releases
My Forth compiler for the Jupiter ACE in Python was too limited, so I've written a full-fledged interpreter for proper compilation. All words are implemented except:
LOAD BVERIFY VERIFY BLOAD BSAVE LIST EDIT FORGET REDEFINE INKEY BEEP PLOT AT CLS
Now COMPILER, DEFINER, LITERAL etc. work as expected, unlike the previous one. What it doesn't do is run Z80 code, of course.
Now working on unit tests. Stay tuned for more info. This one will be in its own repository.
My Z80 half-cycle-stepped emulator will have to wait for now. I've been working for a while on a Jupiter ACE port of the popular ZX81 Mazogs game.
As part of that effort, I've written a Jupiter ACE Forth compiler in Python, that I guess will also be useful for others who want to develop for this machine in its native language.
The compiler and all the info can be found here:
https://codeberg.org/pgimeno/Mazogs/src/branch/jupiter_ace/JACompiler
Working on a circuit-accurate Jupiter ACE software emulator, but I'm running into some difficulties. The #z80 emulation module I'm using is @floooh's cycle-stepped one, but it doesn't properly implement /WAIT, which the JA employs as the VRAM contention resolution mechanism. Therefore I've started working on a new, half-cycle stepped Z80 emulator as well, which is Mcycle and Tcycle-aware, in order to sample /WAIT and /BUSRQ at the right times.
Z80 Bug? Transistor-level simulation bug?
While investigating the Z80 behaviour using "Visual Z80 Remix", I discovered something that looked like a CPU bug: if NMI is activated while EI is executing, IFF2 was cleared. Turns out someone else already dug into this: https://github.com/hoglet67/Z80Decoder/wiki/NMI-during-EI-Anomaly
I created a testing hardware to find out which one is correct, and here are the results: https://codeberg.org/pgimeno/Gists/src/branch/z80-asm--z80-nmi-during-ei-test
Spoiler: the transistor-level simulation is buggy, but for a good reason.
#z80 #bugs #hardware
No lo entiendo. Cuantos más productos light tomo, más engordo.
