A New Tiny Basic for the 6502...

[drogon]

This is a copy of the post I've just made to my own website - copied here for your interest:

Original post:

https://projects.drogon.net/gibl/

Get the code, etc.:

https://project-downloads.drogon.net/gibl/

It's not Open Source, but Source Available, so make of that what you may.

===============
It's fairly well featured for a Tiny Basic. (Which is why I picked this one to base my efforts on - also I have a sort of soft-spot for the INS8060 and I own a MK14). It supports the usual 26 variables, A-Z, GOTO/GOSUB and FOR/NEXT and DO/UNTIL.
Numbers are signed 16-bits. Overflow is checked. It has a cheap PRNG that can be seeded too.

There is also byte and word indirection aka. peek/poke to manipulate and corrupt memory with and poke hardware VIAs, etc.

You can store strings and print them and do weird stuff with them if you know how to peek/poke their bytes.
There is a byte-out thing - a bit like PRINT CHR$(x) in other BASICS (It's VDU x - like the Acorn/BBC Micro one).
Also GET for single character input (non-stopping inkey, anyone?)
Memory management is left as an exercise to the user, but there is a system variable TOP that will tell you the address of the first byte of free RAM. See the sieve.tb program for an example of it being used.

It supports Hex. numbers using the Acorn standard ampersand prefix: &CAFE and they can be printed using the ~ as in:

PRINT ~A
to print in hex. There is a call but not USR function (yet? anyone want it?) so CALL -151 or CALL &FF69 would work.

Enough for now:

Here is the blog post I made
=====================================

Who would have thought that in 2023 some idiot would write another Tiny Basic for the 6502…

Well, I was that idiot… Because: Why Not!

It all started as something else… Over the summer just past I wrote a new programming language called APRICOT with the intention of making it a tiny but usable thing on the 6502. That hasn’t happened… yet.

But in looking to make a 6502 version or APRICOT, I had a look at all the variants of Tiny Basic there are out there with the view of using one to act as a platform to help me port APRICOT… What happened instead is that I found one on an old platform I have a touch of fondness for so set about re-writing that for the 6502 instead.

That platform was the INS8060 CPU, commonly known as the SC/MP. The name of the implementation was NIBL Short for National (As in National Semiconductor) Industrial BASIC Language.

Coming in at just under 4KB of SC/MP code it was a slightly longer version of most Tiny Basics which tried to get under 2KB wherever possible… However it did have some nice features that I was interested in – namely FOR/NEXT and DO/UNTIL loops.

And given the name NIBL, I felt I had to call it something similar, so GIBL for Gordons Interactive Basic Language) was coined.

As I was rewriting it, I actually thought that the old SC/MP was going to be much more code dense that the 6502 – turns out they’re about the same, although some operations seems easier on the SC/MP due to it having 16-bit pointer registers with a variety of auto increment/decrement modes. However, the 6502 version is currently at just under 3700 bytes of code and runs much faster than the SC/MP version (for many reasons, not just that the SC/MP has a bit-serial ALU)

Download

So want to get the code? Click here … https://project-downloads.drogon.net/gibl/

But beware – it won’t run on any system other than my own Ruby board, but it might just run as a ROM in a BBC Micro – starting it will require a magic *FX command or unplug BASIC… Or Go into MODE 7, assemble it to run at &4000 load it there and off you go…
And port…

For other systems… You will need to read and edit the system.s file to work out what to you. Possibly also the data.s file too. You’ll need to provide your own routines for a number of calls to handle character IO from a terminal. However it should be no worse than porting e.g. EhBASIC for your system, so if you can get that running, then you can get GIBL running.

There are a few demo programs for it including my new Mandelbrot implementation, but be aware – Tiny Basics are not known for their speed. They do not tokenise the input like MS and newer Basics so there is a lot of string compares going on for every line of code executed.

Cheers,

-Gordon

[BigEd]

Nice, and comfortably under 4k too!

[drogon]

BigEd wrote:

Nice, and comfortably under 4k too!

I think that even without some sort of existing monitor or OS adding in some simple serial port handling including read a line would still keep it under 4K and if struggling just remove the banner for another 200 bytes...

I'm almost tempted to build a system just to test it - not sure where I'll get 4K ROM and RAM chips from though!

Cheers,

-Gordon

[barrym95838]

drogon wrote:

... and if struggling just remove the banner for another 200 bytes...

That's an outrageously luxurious banner in any language.

Quote:

I'm almost tempted to build a system just to test it - not sure where I'll get 4K ROM and RAM chips from though!

I'm not a hardware guy, but even I know that they are super easy to synthesize from plentiful higher capacity devices.

P.S. would it be out of line to request a .zip version for those of us without a lazy way to extract your .tgz? Thanks.

[drogon]

barrym95838 wrote:

drogon wrote:

... and if struggling just remove the banner for another 200 bytes...

That's an outrageosly luxurious banner in any language.

Well, indeed, yes.

But some some time I've had a sort of "memory is cheap" mindset, however this project has made me think otherwise. I can, for example, save some 68 bytes in one place by replacing some macros by JSRs but the slow-down is noticable in my 16Mhz system, I think it would be very noticable on an old 1Mhz system...

Quote:

Quote:

I'm almost tempted to build a system just to test it - not sure where I'll get 4K ROM and RAM chips from though!

I'm not a hardware guy, but even I know that they are super easy to synthesize from plentiful higher capacity devices.

Oh sure - I can use current 32K chips, but ...

Quote:

P.S. would it be out of line to request a .zip version for those of us without a lazy way to extract your .tgz? Thanks.

I've put one up alongside the .tgz but I'm no zip expert, so let me know if it's broken..

Cheers,

-Gordon

[Michael]

I like your choice of NIBL BASIC as a starting point. I really like the NIBL implementation I have running on an updated version of Karen Orten's PICL 4-MHz SC/MP emulator (PIC) project.

[gfoot]

I had a go with this - it was pretty easy to set up, aside from the fact that, with this being my first foray into the cc65 compiler, there was a lot of head-scratching over addresses and where to configure them! But it works now:

Code: Select all

gfoot@box:~/6502/fastpdip6502/server$ python serialserver.py
Initialising link
Waiting for client
Connected at 250000 baud

Choose code to run:
0 boottestcode
1 osapp
2 dormann
3 memtest
4 sdtest
5 viatest
6 cpuspeed
7 gibl
?7
Reading file '../bin/apps/gibl.bin'
Loading data to address 7000
Go to 7000

--- Serial console, ^C to quit ---


  ____ ___ ____  _
 / ___|_ _| __ )| |
| |  _ | ||  _ \| |
| |_| || || |_) | |___
 \____|___|____/|_____|

Gordons Interactive Basic Language

>
>
>ok great

SNTX ERROR
>10 FOR I_=0 TO 10
>20 PRINT @
>20 PRINT "Hello Gordon"
>30 NEXT
>run

SNTX ERROR
>LIST
   10  FOR I_=0 TO 10
   20  PRINT "Hello Gordon"
   30  NEXT

>10 FOR I=0 TO 10
>RUN
Hello Gordon

SNTX ERROR AT 30
>30 NEXT I
>RUN
Hello Gordon
Hello Gordon
Hello Gordon
Hello Gordon
Hello Gordon
Hello Gordon
Hello Gordon
Hello Gordon
Hello Gordon
Hello Gordon
Hello Gordon

>

There's no real OS here, my serial bootstrapper is just loading the code into RAM and executing it there. I think the total loaded code size was about 3.5K, and I made it load at $7000 in a 32K system. I backtracked from moving the other things around, so the line buffer is still at $300, gibl's non-zeropage data is at $400, and the program start address is hardcoded to $E00.

[drogon]

gfoot wrote:

There's no real OS here, my serial bootstrapper is just loading the code into RAM and executing it there. I think the total loaded code size was about 3.5K, and I made it load at $7000 in a 32K system. I backtracked from moving the other things around, so the line buffer is still at $300, gibl's non-zeropage data is at $400, and the program start address is hardcoded to $E00.

Well done and thanks for testing!

And yes, Tiny Basic is quite fussy and restricted in syntax.. what I've been doing is editing files off-line and using the terminal to squirt them into the system or using my OSs "*exec" command which reads text out of a disc file and sends it to keyboard input. (Those with BBC Micro or Apple II experience will know this).

Cheers,

-Gordon

[drogon]

Michael wrote:

I like your choice of NIBL BASIC as a starting point. I really like the NIBL implementation I have running on an updated version of Karen Orten's PICL 4-MHz SC/MP emulator (PIC) project.

It was one of the few where original source code was still available and it had all the features I wanted. I was originally going to replicate the STAT command too, (to some fixed IO ports in a VIA) but with so many different 6502 hardware combinations felt it would have been less than useful.

I have a Mk14 so am familiar with that CPU too, but I never got round to making one of Karens emulator systems.

Restoring the Mk14 is 2nd top of my to-do list though, so maybe one of the 3rd party memory expansion boards might happen...

Cheers,

-Gordon

[barnacle]

I too have an MK14 - my first computer - but sadly at some time in the past my late father appears to have connected the power supply the wrong way around. At least the two proms are partially dead; I don't know what else didn't survive. Also, it no longer has a keypad.

Neil

[jgharston]

You initialise the stack to &F0. What's &01F1-&01FF used for that you don't put the stack at &FF ?

I'd recommend putting all the platform-dependant code in a single file rather than having bits of dependent code mixed in with bits of generic code. For instance, a platform-specific system.s that does just the platform-specific stuff, and then hands over to 'main' in a non-platform-specific file. And have it do for example:
putchar: equ osWrch
getchar: equ osRdch
newline: equ osNewl
etc.

Then a C64 target sysc64.s would do something like:
word cold
word warm
byte "CBM80"
byte "TinyBasic"
byte 0
etc...
newline: lda #10
jsr $FFD2
lda #13
putchar: equ $FFD2
getchar: jsr $FFCF
cmp #1
bcc getchar
rts
etc.

[J64C]

Oh wow, what timing! I'm starting to look at getting BASIC working on my little 6502 computer also.

[drogon]

jgharston wrote:

You initialise the stack to &F0. What's &01F1-&01FF used for that you don't put the stack at &FF ?

It seemed like a nice number at the time.

Really, no reason. Normally I'd not even bother to set the stack as the underlying OS takes care of it, but I had a debug issue with some of the internal function calls, so I wanted to fix it at something.

Quote:

I'd recommend putting all the platform-dependant code in a single file

I'm fairly sure it is all in a single file - system.s - but I'm currently going through it to make sure and make it easier to port.

Quote:

rather than having bits of dependent code mixed in with bits of generic code. For instance, a platform-specific system.s that does just the platform-specific stuff, and then hands over to 'main' in a non-platform-specific file. And have it do for example:
putchar: equ osWrch
getchar: equ osRdch
newline: equ osNewl
etc.

I have encountered systems where they have weird variants - so if you have a platform that already runs ehbasic then the getchar returns instantly (or is expected to) so simple labels might not work and you might have to write little wrappers to make them work.

Quote:

Then a C64 target sysc64.s would do something like:

Not ever having touched a C64 let alone used one, then that's not my problem..

Due to health issues in the past trying to support open source software, this is all provided on a less than reasonable efforts basis, but thanks for having a look.

Cheers,

-Gordon

[drogon]

I've put up a new release of GIBL for anyone interested - it should be easier/clearer to port and I included a sample getLine routine that's fairly basic but does work, so ought to be easy to adapt or expand if needed.

It's also a slightly faster and a shade smaller too.

https://project-downloads.drogon.net/gibl/


Enjoy,

-Gordon

[drogon]

drogon wrote:

I've put up a new release of GIBL for anyone interested - it should be easier/clearer to port and I included a sample getLine routine that's fairly basic but does work, so ought to be easy to adapt or expand if needed.

It's also a slightly faster and a shade smaller too.

https://project-downloads.drogon.net/gibl/

Another update - basically the same as above - a bit smaller, a bit faster and hopefully even easier to port with all the good stuff in one file and I've supplied two routines as standard - the string print and the getline code - You save even more space by chopping out the startup code and taking out a lot of the RubyOS calls but right now it's at 3482 bytes.

It won't get much smaller unless you consider culling things like FOR/NEXT, DO/UNTIL but I do feel these are worth the extra bytes.

Enjoy,

-Gordon