I tried your latest 15 Mar 2024 version, and it works. I was able to successfully type in your LIFE program and run it using the https://st.sdf-eu.org/i8080/index.html emulator. :-) Two peculiarities, though:

1. The "-" key does not work, but the keypad "-" key does work.

2. LIFE displays a glider the first time it's run, which marches across the screen. The second time it's run, it starts with a different pattern that dies off after one generation. The third time, the glider re-appears and it runs the same as the first time.

3. I can't find a way to break out of the emulator. What is the "control-full-stop" command you mentioned in an earlier comment to get back to the command mode (to enter a BASIC program as a HEX file)?

I found the same issue with the ‘-‘ key. I wasn’t able to reproduce the issue you found with ‘life’ - I can run it okay 3 times in succession. But I loaded it as a hex file rather than type it in, so I’ll try typing it in when time permits. The key combination to get back to command mode is CTRL-. (I.e. hold down control key and press full-stop/period key). After loading life_0x0400.hex, type “g 00de” to get back to BASIC.

I tried typing in life.bas but couldn’t replicate the error you found - after typing it in it ran 3 times in succession with no problems.

Looks great! May it work on more than 1K RAM? What is theoretical size limit for the program?

The RAM size has been set to 1K during development only because I have a lot of old 2K RAM chips and it is nice to be able to have the BASIC interpreter and any of the example programs all fit under 2K. 

RAM_BASE and RAM_TOP can be set to anything up to 63K. Maximum BASIC program size is RAM size minus 64 bytes for variables, minus 8 bytes for a small buffer used by the INPUT statement, minus stack space used by the interpreter and by FOR/NEXT and GOSUB/RETURN, minus a few bytes needed to be able to run direct mode commands without colliding with the stack. So on  1K RAM system this is about 900 bytes and with 63K about 62.9K.

(I wasn’t quite sure if you were asking about size limit for the BASIC program or BASIC interpreter - the interpreter probably can’t be made much less than 1K. Although I am still finding code size savings of 1 or 2 bytes, these are increasingly hard to achieve. It’s possible that a rewrite from scratch might be able to do better than 1K, since the current implementation was developed a feature at a time, rather than being planned. Also, I am planning to make a Z80 version once this version is finished, which should be a few dozen bytes shorter than 1K due to the slightly higher code density of the Z80 compared to the 8080.)

Thanks! Yes, I meant RAM for program and data

I tried the 6 Mar 2024 build in Stefan Tramm's 8080 emulator. I can load and run Tiny just fine! It certainly is BASIC. :-)

I tried running your LIFE program, but get an E170 error. It appears the array doesn't work. For example, LET @(53)=1, then PRINT @(53) prints 0 (not 1).

Re your 5 Mar 2024 comment on ExpEvaluate at RST 7: My Altaid 8800 calls RST 7 if there's a hardware interrupt (serial input or timer). It would seem I just have to replace your CALL ExpEvaluateNub at 0038 with a JMP to my interrupt handler. It would check for an interrupt, process it if found, restore registers, and jump back to 003B to resume BASIC. Or is there something tricky in your code that I'm missing?

E170 means that it was expecting to  find a variable name but found something else. I haven’t been able to try long programs on Stefan Tramm’s emulator - haven’t been able to work out how to automatically enter a program from a file so can’t easily try to replicate the error.

The array begins at the first byte of free memory after the last thing parsed, so when in direct mode where the array starts depends on the last thing entered. If you try LET @(10)=1234 PRINT @(10) all on one line with no newline between the statements that should work (that is how multi-statement lines are entered in 1K BASIC - no separator between statements). I don’t think that your suggestion regarding the interrupt handler would work because every time there was an interrupt it would try to evaluate an expression. I would like to make the changes that you need for it to work on the Altaid 8800 - it might take me a few days to do. I’ll make a new branch in GitHub. To summarise what I think is needed: lower 4K of memory space is ROM, above that is RAM. Leave three bytes free at address 0038h for jump to Interrupt Service Routine. BASIC will occupy lower 1K plus about 20 bytes after making the changes to accommodate the ISR.

Yes, I had to start your 1k BASIC, and then type your LIFE program into Stefan Tramm's emulator by hand. Tedious. I couldn't load it as a HEX file, nor cut-and-paste it in.

The E170 error occurred when LIFE tried to execute line 30 LET @(53)=K (or any line with @(number). I didn't realize how immediate mode worked with @ (nor that you could have multiple statements on a line -- clever!)

Regarding interrupts on RST 7: Ah, I see your point. I thought the interrupt handler would read the input port to find the source of the interrupt, service it accordingly, and then return *without* executing BASIC's CALL ExpEvaluateNum and CNC Error instructions. But if *no* interrupt source bit was set, then BASIC must have executed an RST 7, so it would execute BASIC's ExpEvaluateNum and CNC Error instructions before returning.

But, it's possible that BASIC calls RST 7, and *then* an interrupt occurs. So the interrupt handler can't tell whether to execute them or not. More thinking (and testing) is needed.

I’ve made a hex file life_0x1000.hex corresponding to life.bas. I loaded it into Stefan Tramm’s emulator by first of all loading and running basic8080.hex, then when the basic prompt appears press “control full stop” to get back to the emulator command line, then loading life_0x1000.hex then typing “g 00DD” to restart basic from “Ready”. It ran okay when I did that.

I converted your ASM for the A85 assembler (since I use it for my other projects). I removed the RST macros, changed Labels&0ffh to LOW Labels, fixed commands in leftmost column, and inconsistent upper/lower case labels. Your 2/28/2024 version assembles without errors, but is 1 byte over 1k.

I look forward to seeing your LST and HEX files, so I can compare them to mine for errors. My goal is to get this working in my Altaid 8800 with a 2k ROM (the other half being the monitor and front panel software).

The version from 28th Feb had a few problems. I’ve fixed them and made a Version0.9 branch which contains a LST and HEX file. This version runs all the example and test programs okay. The remaining issue that I need to fix is making * and / equal precedence.

Thanks! I updated my A85 version to match your 3 Mar 2024 version. It assembles and produces an identical HEX file. :-)

The monitor for my Altaid 8800 is about 3k, so there is room for it and your BASIC in a 4k EPROM. I'm working to move the Monitor up to free the lower 1k for your BASIC (as it looks difficult to re-assemble it to run at a higher address).

 Are there any problems re-assembling your BASIC to use a higher RAM starting address?

Another challenge is that my hardware uses interrupts, which has its vector at 0038h. I'll have to move ExpEvaluate somewhere else. Luckily, it's not essential that your BASIC fits in *exactly* 1k. The same tricks you used will certainly reduce the size of my monitor!

I don’t seem able to post a reply to your most recent reply, so I’m replying to the previous one. I’ve just committed a version with RAM starting at 4K and that seems fine. I made a change to where EndProgram is located so that the high byte of the start of RAM no longer gets treated as an opcode when EndProgram is called. Replacing RST_ExpEvaluate with CALL ExpEvaluate will add about 16 bytes + however many bytes you need for your interrupt routine. Because this will move DivSub up to an address higher than 02FF, something will needed to be moved out of the way. Try turning ‘Error:’ into a subroutine above 1K (and replacing it with ‘CALL Error’ so that the fall throughs still work). The single POP D will need to be replaced with two POP Ds so that Error still works. This will make 7 bytes of space, so DivSub won’t move too much. (but check that LineNumSub is >= 0223). I’m happy to help with making and testing any changes because I’d like to know that it runs on a real 8080!

When thinking more about replacing RST_ExpEvaluate with CALL ExpEvaluate, there are a couple of problematic instances near labels GosubSub and ForWithStep where the straightforward replacement won’t work. I’ll look for an alternative for these two instances.

BASIC in 1K is an impressive feat!  The only smaller "high" level language I've run across is VTL (Very Tiny Language), which is around 768 bytes.

I'm having trouble figuring out your source. Do you have a LST file, so I can tell what code your macros actually assemble into?

I offer an 8080 kit (google "Altaid 8800"). It would be fun to put your BASIC in its ROM. :-)

Thanks. It’s currently undergoing a few changes (to reclaim a few bytes in order to fix the few remaining issues). When it’s next in a working state I’ll put the LST and HEX file into GitHub. There are probably one or two places where the tricks needed to squeeze it into 1K need attention if burning it into a 2K ROM (one that springs to mind is that the opcode corresponding to the hi byte of address of start of BASIC program must be a single byte instruction that has no harmful side effects - currently this is 04 but 08 should work just as well). The two most complex macros use RSTs like multi-byte instructions. They are RST_JZPage (same page JZ to single-byte address following the RST call) and RST_CompareJump (compare A with byte immediately following RST call and same page jump to single-byte address if equal). Altaid 8800 looks really neat.

Very interesting. I am exploring writing or adapting some version of Basic for my custom CPU, currently I am leaning towards http://www.ittybittycomputers.com/IttyBitty/TinyBasic/ which has a "TBIL" - Intermediate Language (sort of p-code but for Basic) with the idea to write interpreter for the TBIL for my processor while keeping the actual TBIL code the same. But here I like the generic parser driven by sort of "regex lite" syntax. If such generic parser could be extended to include pointers to routines that execute and additional data (such as operation priority, availability in program or command mode etc.) it could be even more powerful. A single data table + generic parser / execution engine could be used to implement variety of Basic "dialects".

 https://hackaday.io/project/173996-sifp-single-instruction-format-processor

Thanks. It is interesting that it has ended up smaller than non-tokenised Tiny BASICs. I suspect that tokenisation has actually made it smaller (and faster) than non-tokenised Tiny BASICs, because it only needs to do one task at a time and each task can be done without much register swapping, and without needing RAM-based variables (apart from storing the location of the BASIC program and the RNG state). Whereas non-tokenised Tiny BASICs need to switch between parsing the program and running it.

Check out vintage computer federation forum. They have tons of guys running 8080 systems who I am sure would love to try,

Debating whether to incorporate this with an ongoing project of mine, a Z80-display-kbd with an  ESP32 front end.  Now most of the way thru converting the GitHub .asm to Z80.

I used this online 8080 assembler, if useful: https://www.asm80.com/onepage/asm8080.html

That's helpful.  I'm converting to Z80 by hand because I can't find a decent 8080 to Z80 converter.

This brings back a lot of good memories when I had a IMSAI 8080. I wish I still had that good old workhorse and give your BASIC a run.

I’ve begun to appreciate the 8080 CPU a lot as a result of doing this project. I wonder how many working systems using an 8080 CPU exist now?

It should run on an 8085 which has the same instruction set and which remedies another 8080 failing, the need for 3 voltage rails. Plenty of 8085s ended up in embedded systems.