Just4FunForth
Thanks to Bill Westfield now we have a new language for the Z80-MBC, the fig-FORTH v1.3 (here the link to the Bill GitHub repository with the source he adapted for the TASM assembler with the needed modifications for the Z80-MBC).
The acronym "fig" stands for "Forth Interest Group", that was a world-wide non-profit organization (now dissolved) for the promotion of the Forth computer language.
I've just started to play with this thing, and I must say that it is not the most friendly language I've seen... anyway it is an interesting different approach.
To enable Forth just upload the new IOS release
S221116_R120217_Z80.ino in the Files section, and select the Forth language from the new multi-boot menu (see next paragraph).
Here it is a "blink" demo program:
( **************************** ( ( Blink test - Forth - Z80-MBC ( ( **************************** : ledon 1 0 P! ; : ledoff 0 0 P! ; : delay 4000 0 DO NOOP LOOP ; : blink CR ." Blinking..." CR BEGIN ledon delay ledoff delay 0 UNTIL ;
To execute give the command "blink":
If you are using Tera Term to send a text file to load a forth source, remember to set up a delay of 1ms for each character (serial port managed by the Arduino bootlader doesn't have any handshaking, so for now this is required to handle the serial stream without errors when sending a text file using a terminal emulator):
New multi-boot selection
Now pressing the User key after a reset brings to a new menu to chose the preferred boot mode. During this phase the LED-D0 will blink until you choose the boot mode:
New name
As you can see from the previous photos, from this release the MBC acronym changes to "Multi Boot Computer"...
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Suggestion: some sort of "interrupt" character that the AVR traps and uses to print the current status, instead of passing on to the Z80.
Are you sure? yes | no
Hi, what kind of "AVR status" are you thinking at...?
Are you sure? yes | no
Cool!
I've been experimenting with speeding up the AVR code for the BIOS stuff. DigitalRead and DigitalWrite are about 60x slower than they "need" to be if the arguments are constants, and it's pretty easy to replace them with smarter functions. It almost works (BASIC works, but the loader behaves strangely and doesn't load things.) Still looking at it.
There may be some "bug" WRT interrupt requests and serial traffic. If you generate serial data on your host but the Z80 isn't reading it, the Arduino Event stuff will start setting INTRQ every loop (even if it's already been set.) And the Z80 might respond or might not, but won't clear the source unless it reads the serial port...
Are you sure? yes | no
Yep... DigitalXxxxx are very slow... I think this is the price of "portability"... (and I must say that any HAL brings similar inefficiencies...). So let me know...
About interrupt, the actual AVR implementation leaves the Z80 the "choice" to use it or not. I mean that in any case when at least a char is present in the AVR input buffer the INT signal is activated. If a char is read by the Z80 through the I/O port, the INT is reset, but is set again after the I/O read if an other char is in the AVR buffer.
So if IM1 is set and the Z80 interrupt is enabled, every char in the buffer can be read using the 38H ISR trap (this is the way the chars are read in the uBIOS used for Basic). If Z80 interrupt is not enabled, the INT signal is simply ignored and input chars must be polled (this is the way used by crt0.rel actual implementation for the SDDC compiler).
This should explain the behavior you experienced.
BTW: I've ordered a couple of 24AA1025 (plus others things) from Conrad using a special S. Valentine free shipping offer, so I haven't to wait "some" weeks for the 24C1024s from China... They should arrive next days. In the meanwhile I've started to play with a 24C32 and to struggle with the "undocumented" 32 bytes buffer limit of the WIRE library ... :(
Are you sure? yes | no