Commander X16

I'm actually watching this with some interest. After I'm done with my current HANGMAN project in BASIC. I've been meaning to start writing some Pas65 code. tinyPascal is also very interesting to me as one who learned my most advanced programming techniques in Turbo Pascal 6.0

ahenry3068 wrote: ↑Sat Oct 28, 2023 10:26 pm I'm actually watching this with some interest. After I'm done with my current HANGMAN project in BASIC. I've been meaning to start writing some Pas65 code. tinyPascal is also very interesting to me as one who learned my most advanced programming techniques in Turbo Pascal 6.0

I've a similar-ish start too.

I got my first computer, a Sinclair ZX81 when they first came out, a Christmas present from my parents. By this time I had been self-taught on my school's one and only computer, an Apple ][ with 48K of RAM, a green mono monitor and 2 disk drives. They had bought it in the summer of 1978 and I started there in the autumn of 1978. I had won a scholarship to that school - a private boarding school, so after school hours, and during breaks, I would join all the other nerds clustered around whoever was on the machine at the time, watching what they did and how they did it, or didn't!! You could sign up in 30 minute blocks, and I think only 2x times a day max.

It wasn't until almost 8 years later when I went to university to study electrical & electronic engineering that I got any formal teaching in programming a specific language - and that was Pascal. On a Bleasedale Unix box with BBC Computers, Model A, as the terminals to it. Our first main task was to simulate a small telephone branch switching network. Very interesting - I learned more about branch switching networks for telephones than Pascal, but it was all good!

Every other language I have coded in has been self-taught, like so many of my generation and older... C, Fortran IV and 77, Java, JavaScript, assembly language in 6502, 8080, all the PIC 8 & 16 bit microcontrollers, and some I'm sure I've forgotten along the way.

Oh yes - I just remembered a few more - Modula and Oberon, plus the various job control languages in the DEC VMS and PR1ME mainframe environments, and the various flavors of Visual Basic and other more structured BASICs... fun!

Very nerdy, but it didn't get in the way of me finding a girlfriend or getting married - my wife is very understanding and lets me geek with impunity - geeking is for my tech hobbies, hardware & software. Nerding is what my extended family use to refer to my other main hobby area, astrophotography.

For all its wrinkles, Pascal has a lot to offer, especially in having you think more deeply about what you're trying to do and the outcomes you want.

Python - yeah, I never quite warmed to it. Or FORTH. But never say never!!

A quick update - I'm a tad behind my self-imposed schedule - I ran in to some subtle errors that took me way too long to chase down.

The errors were made by me as I moved the original code I had from tokenized basic with line numbers to non tokenized, no line numbers, and to be compatible with BASLOAD.

Why did I make this move?

So I can further evolve Tiny Pascal in to not-quite-so-tiny Pascal, first by adding bytes, floats, strings and pointers to it. This requires some fairly deep under-the-hood changes as right now TP has just one data type - 16 bit signed integers and as a result of only having 1 data type it makes many assumptions that don't stand up to having more than 1 data type - doing this kept the code base for TP smaller and less complex/easier to test etc - a big deal back in the mid 70s!!

I do plan to release the current code that I have in the very very near future, along with a pCode interpreter for it. My planned 6502 code generator is some way off - I won't be bringing this one 'up' until I've got the additional data types working - I don't want to have to unpick the code generator as well as the compiler just now!!!

Once I get back to my home office/lab later today I'll get it up on my hardware (DEV #71) and share a video of it running!

Cheers

Martin

Sounds like you're on the path to self-compiling, though. Can't wait to see it working!

Looking forward to this as well. Yep, I never imagined using BASIC as a bootstrap into another compiler. And next, using tinyPascal to make a C compiler!

A "baseline" with just the single supported type might be interesting to compare against as a reference. I can't recall, was the original set up to support an array of those integer types?

Another thing to "choose early" might be whether to support the upper/lower case PETSCII mode, or ISO mode, and go ahead and tackle supporting mixed case declarations? But I'd be happy with just upper-case also.

And if there is a kind of "p-code spec", others might be willing to tackle the p-code to 6502 challenge.

I've found BASLOAD to be a real blessing - so we can focus on the creative/fun parts, and less micromanaging those line numbers and accidental large-range REN usage that wrecks all the line numbers.

voidstar wrote: ↑Sun Nov 05, 2023 6:32 am Looking forward to this as well. Yep, I never imagined using BASIC as a bootstrap into another compiler. And next, using tinyPascal to make a C compiler!

Ooh - interesting!

voidstar wrote: ↑Sun Nov 05, 2023 6:32 am A "baseline" with just the single supported type might be interesting to compare against as a reference. I can't recall, was the original set up to support an array of those integer types?

Yes - arrays of integers - single dimension, signed 16bit.

voidstar wrote: ↑Sun Nov 05, 2023 6:32 am Another thing to "choose early" might be whether to support the upper/lower case PETSCII mode, or ISO mode, and go ahead and tackle supporting mixed case declarations? But I'd be happy with just upper-case also.

Hmmm... say a bit more...
The original Pascal definition is case-agnostic.
I can make it case insensitive pretty easily... not sure about PETSCII - or that I quite understand what you're getting at.

voidstar wrote: ↑Sun Nov 05, 2023 6:32 am And if there is a kind of "p-code spec", others might be willing to tackle the p-code to 6502 challenge.

There is - I'll dig it out and post it here.

voidstar wrote: ↑Sun Nov 05, 2023 6:32 amI've found BASLOAD to be a real blessing - so we can focus on the creative/fun parts, and less micromanaging those line numbers and accidental large-range REN usage that wrecks all the line numbers.

Agreed!!!

I'm posting a link to where the BYTE magazine article is that describes the Tiny Pascal ('TP') system and specifically the p-Machine.

https://ia600301.us.archive.org/5/items ... e-1978-09/

P148 in the pdf file you find at the above link is where the description of the pMachine starts.

If any body is interested in crafting a pCode interpreter in native 6502 then this is where you'll find the necessary details on the pMachine workings, the pCode specifics and a pCode interpreter written in Tiny Pascal.

I'm currently porting my pCode interpreter written on TechBASIC on the iPAD to Basic V2 for the X16, in a format that is compatible with BASLOAD. I've some extensions planned for Tiny Pascal as detailed previously in this thread, so I don't have the capacity right now to build a pCode in 6502 assembler.

I do intend to build a code generator for TP once I've the other parts working - this will generate 6502 as well as 65C02 and support several memory models and, at some point, be ROMable...

Another quick update...

I have the pCode interpreter running successfully in X16 Basic under the emulator.

pCode is poked directly in to whichever is the current RAM BANK.

The Interpreter reads pCode directly from the current RAM BANK.

There are a few weird things happening, I think, when it comes to tracing the execution of the pCode - using the interpreter's built in trace facility.

The whole thing looks pretty ugly right now as it is spitting out a ton of messages I had included in the source as I debugged it.

So, let me get it tidied up, and able to make use of user-input RAM Bank, and to be able to BLOAD the pCode in to the required RAM BANK - which also means having the Tiny Pascal compiler support a user-input RAM Bank and also do a BSAVE of the pCode.

Progress is being made!!!

Martin Schmalenbach wrote: ↑Sun Nov 05, 2023 8:03 pm

voidstar wrote: ↑Sun Nov 05, 2023 6:32 am Another thing to "choose early" might be whether to support the upper/lower case PETSCII mode, or ISO mode, and go ahead and tackle supporting mixed case declarations? But I'd be happy with just upper-case also.

Hmmm... say a bit more...
The original Pascal definition is case-agnostic.
I can make it case insensitive pretty easily... not sure about PETSCII - or that I quite understand what you're getting at.

Well - hmm... I guess I mean from the on-system use-case/perspective... One can press SHIFT+LEFT ALT to toggle the character set, and they can also use CTRL+O to enter ISO mode.

From a "fresh start"/boot, I think the KERNAL defaults to the PETSCII "graphics" mode - meaning no lower case. If you type "abc" you get "ABC" and if you type SHIFT+"abc" you get graphic characters.

So from there you can press SHIFT+LEFT ALT to toggle into upper/lower case mode. Right away in that mode, typing "abc" gets you lower case "abc" and then SHIFT+"ABC" gets you the upper case version of that.

In either of the above modes, a=65 and A=193 (i.e. pressing lowering-case non-shifted 'a' gets you an upper case symbol of it)

But then users can do CTRL+O, in which case now pressing a=97 (normal ISO ASCII value for lower case a).

While we're hoping for an 'on system' experience here, I think "requiring" to be in ISO mode is a reasonable compromise- it's not a "secret mode" of the system, and don't think support for it will evaporate (if other future extensions eat up ROM space, I'm not sure what would be the first feature on the chopping block- don't think it would be ISO mode). One benefit is ISO mode gets you those {} braces.

In the mixed case upper/lower PETSCII mode, it's just dealing with handling 65 and 193 as the same value (a) or different? I think X16EDIT will support any of the modes - I'm not sure if on startup it defaults to the "current" mode or if you have CTRL+E into it.

So - I think that's how I meant: auto-detect and handle the case of being in the ISO mode? Is the upper/grx or upper/lower "mode" handled all the same? Require/startup in ISO mode? (I'm not sure if that influences file input mapping also??)

> I think the KERNAL defaults to the PETSCII "graphics" mode - meaning no lower case.

Correct.

> ...I'm not sure if on startup it defaults to the "current" mode or if you have CTRL+E into it.

Your in BASIC on startup.

Question I have is how do you get out of ISO mode?