Looks interesting; I may have to try it on my 8080 simulator, which works by executing on a Logisim Evolution chip-level design. Very very slowly... in my copious free time, of course!

Neil

Goodness, that's both a hint and a challenge...

The snag was, every time I changed the design both to follow the original design philosophy (e.g. sixteen bit registers operated as pairs rather than individually, and a bit-sliced ALU rather than discrete blocks) and to use 'fabricated' TTL parts, it got slower...

Takes maybe five minutes from starting with PATB to 'OK'...

Neil

Maybe it depends on the functionality. Although I am impressed it has FOR/NEXT - some TBs just don't have that. I've only glanced at the code (40+ years sine I did 8080 and that was with a Z80 assembler!) however the 2 examples are interesting. LET appears to be mandatory, spaces abound (which would make detecting a keyword much easier) but that might be bogus.

IO is handled by the emulator rather than calls to some OS/Monitor routine. You can't overwrite a line, need to delete it first, then enter a new one. But these are just nits to be picked at - it's very impressive!

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

From my own design, I can see how mandatory LET could simplify the code, since it reduces the things you need to recognise at the start of a statement - you're always looking for a keyword, which is in the keyword table, and if it's LET or FOR then the next token is a variable name. Without mandatory LET, you separately have to consider whether the first token is a variable name and the second token is an =.

C takes the opposite approach: everything is an expression, including assignments, unless it's a keyword which is recognisable when trying to parse a variable name. It's possible to take this approach even further, with even loops and conditionals being special forms of expression that return a value. Having a separate lexer phase simplifies the parsing, but the lexer itself is extra code.

I don't immediately plan to read any 8080 code - x86 already gives me enough of a headache - but I've been considering whether to add FOR-NEXT loops and how to keep the code size under control in that case.

I have had a chance to study Will's 8080 tiny BASIC a bit more, and I'm impressed by his skill in making the most of the 8080's 16-bit repertoire. It's not all roses, though ...

Most of us can appreciate the trading of cycles for bytes. For example, if we already have an a=a+b and a b=-b, then we can save a few bytes by using a=a+(-b) instead of creating a fresh a=a-b.

But, what about all of the relational operations? If we have a cheap swap (8080 definitely does) and we have implemented a<b, then we can replace a>b with b<a just fine. Similarly, a>=b can be implemented with b<=a, but Will takes it a step too far by replacing a<=b with (a-1)<b (maybe not exactly, but you get the idea). With 16-bit 2's complement integers, this can fail in the case of a=-32768. I have a feeling that I'll encounter similar situations elsewhere.

Moral of the story: Enjoy and appreciate Will's implementation, but don't use it for pacemakers or rocket guidance systems.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Hmm, that's kind of an interesting tradeoff, looked at from an appropriate angle: it pretty much works for almost all inputs. It's not quite completely correct. Of course it might be that the extreme cases won't in practice be rare cases, and that would make it a bad tradeoff.

One might take the 'standards' view that -32768 isn't actually a valid 16-bit signed integer, since it can't be converted to its positive equivalent by complementing and adding one...

Neil

True, Ed. Edge case inputs can put a strain on any system that strives to be 100% correct. Another example: how to handle ABS(-32768) and a-(-32768). It seems that WozBASIC demotes -32768 to a "second-class" citizen to partially mitigate the issue. VTL-2 handles all of this by ignoring overflows, truncating inputs and results to 16-bit unsigned integers, and quietly treating > as an abbreviation for >= (these are documented "features" however, so not real defects).

[Edit: Neil beat me to the point regarding -32768 by a couple of minutes. Thanks!]

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Hence my slightly more robust option of replacing a <= b with NOT(a > b).

I can't help but notice that Will's tinyBASIC, Ken's MINT, and my VTL02 live in parallel but similar 16-bit ~1KB interpreter universes. I am going to tuck all three of them into my Kowalski folder right next to each other and see if I can coax them into cross pollenating the best ideas from each, with the goal of making them all better, by my private definition of "better". I have no estimates on how long this will take, but I'll report on tinyBASIC here, VTL02 in my original thread, and MINT in a fresh thread when and if I reach any significant milestones.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I’m glad that my implementation of Tiny BASIC is of interest. Thanks for pointing out the problem with edge cases of > and <. I’ll try to fix that if possible.

It’s still a work in progress and not yet ready to release. It wouldn’t surprise me if there are still some major errors. I’ll make a release in GitHub when I think it’s okay. Currently trying to get it to run on Dick Whipple’s Front Panel 8080 simulator.

I haven’t yet compared it to other Tiny BASIC versions to understand why it’s small. I didn’t honestly think it would be possible to fit it all into 1K. I’m wondering whether tokenisation has helped to make it smaller. I don’t need to use many system variables (just RNG state, pointer to end of program, pointer to end of parse area), whereas if it had to parse and then execute everything at run-time there would probably have been more shuffling of pointers between memory and 8080 registers. Not 100% sure that’s the whole explanation though.

Once it’s released I want to do a Z80 version, which will be a few dozen bytes smaller because unlike the 8080, the Z80 has relative jump instructions. Doing a 6502 version is also of interest to me.

Working on this has made me curious about the architecture of 1970s and 1980s microcomputer BASICs and whether anybody has written a book about them - it would make a good computer history project.

Will

Thanks for joining in, Will. It seems like you have a talent for getting the most bang for the byte out of the 8080. I started a Comparisons and contrasts thread a few years back that you may find interesting. Any contributions you may have to that thread would be warmly welcome.

How did you come across this thread, if you don't mind me asking?

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Every so often I search for any new activity related to Tiny BASIC, and this thread came up in the search a few days ago. Sometime I want to do a high-level psuedo-code description of 1K Tiny BASIC, which I hope will help with porting it to other microprocessors. I haven’t done any 6502 programming, but quite interested in trying it out of curiosity.

I’ve had a go at starting to write a pseudo-code description of the code that turns input characters into tokens without using a separate input buffer. It was the most difficult part of 1K Tiny BASIC to write. It’s still not completely correct (doesn’t handle unterminated strings, accepts tokens with excess characters at the end - the pseudo-code version handles those things, the 8080 implementation doesn’t). I hope this isn’t off-topic because it’s an 8080 implementation. I think that the principles could be applied to a 6502 version. https://github.com/WillStevens/basic1K/blob/main/docs/parser.txt

Also, I fixed the problem with some comparison operators not handling edge cases (and also another problem that I encountered when fixing this).