Commander X16

While you can get into ISO mode through just typing Ctrl-O, to get out, you have to PRINT CHR$(143);

Thanks folks for those thoughts on character sets.

I guess I can auto detect because I can implement part of the pascal standard currently not in Tiny Pascal, which is to have the keyword PROGRAM be the first non white space, non comment character token.

Then all I need do is see what the character code is of the P and go from there…

If it’s 80 or 112 then it is standard ascii.

If it is 208 then it is petscii.

This is not fool-proof so I can continue to check each token or reserved word for character codes above 127 for characters that are known to be alphabetic if a certain keyword token is being processed.

Another fix for this is to introduce compiler directives - probably something I may need to do anyway. This wouldn’t be hard to do either.

kelli217 wrote: ↑Thu Nov 09, 2023 2:25 am While you can get into ISO mode through just typing Ctrl-O, to get out, you have to PRINT CHR$(143);

Well that's non-intuitive.

or press CTRL+R

you might have to type OLD directly afterwards to get your program back

mortarm wrote: ↑Wed Nov 08, 2023 3:43 pm
> ...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.

I meant when you run the ROM version of X16EDIT by typing EDIT. Does it "inherit" your current mode.

So I'll try it on R45 emu...

CTRL+O, and type "edit".. and... "syntax error"
haha, because in ISO mode I gotta do upper case myself. Ok, try again: "EDIT"
And... Yep, X16EDIT is started in ISO mode, I can type braces.

Reboot (exit ISO mode). "EDIT" and I can't type braces since I'm in the system default of upper/grx mode.

Thanks folks- that's actually good to know!

As I write this I'm sat in a delightful French-themed cafe near Phoenix working on getting the pCode interpreter running in BASIC, and in a BASLOAD form as I need to add to this to handle the additional data types, and what of necessity will be a variable width instruction set. The original Tiny Pascal had a 4-byte long pCode. Mine will need to be handle 8-byte long byte codes as well as the original 4-byte long pCodes.

I like this cafe - I seem to get a lot done here!

And in this cafe environment I seem to suffer scope creep!!

I'm finding a growing need to have some kind of debugger for the Tiny Pascal code once compiled - perhaps a debugger version of the interpreter?

In order to communicate with the routine, you can pre-load the CPU registers by using POKE to write to the following memory locations:

$030C: Accumulator
$030D: X Register
$030E: Y Register
$030F: Status Register/Flags

function name screen_set_charset

POKE $030C (1 - 6)
SYS $FF62 (Set Charset)

Description: A call to this routine uploads a character set to the video hardware and activates it. The value of .A decides what charset to upload:

Value Description
0 use pointer in .X/.Y
1 ISO
2 PET upper/graph
3 PET upper/lower
4 PET upper/graph (thin)
5 PET upper/lower (thin)
6 ISO (thin)




Function Name: screen_mode
Mode Number is same as the argument to BASIC SCREEN

Set Mode
POKE $030F, 0 (Clear Carry)
POKE $030C, ModeNumber
SYS $FF5F

Get Mode
POKE $030F,1
SYS $FF5F
M = PEEK($030C)

Martin Schmalenbach wrote: ↑Sat Nov 11, 2023 10:39 pm As I write this I'm sat in a delightful French-themed cafe near Phoenix working on getting the pCode interpreter running in BASIC...I like this cafe - I seem to get a lot done here!

Love the Phoenix area. In Old Scottsdale there's a neat little sidewalk cafe that had the best corn beef sandwitches. I forget the street name, but it's right by the large fountain in the center of town.

IT. IS. WORKING!!!!

OK - it's working.

I had written a post here to describe in detail where I'm at and what's next - and for some reason it didn't post and I've lost that text.

So I'm not minded just yet to write all that out again!

Suffice to say that I now have the compiler and pCode interpreter working as intended based on the relatively simple & small set of test programs I have.

Next steps are to more fully and thoroughly test this with a variety of different programs, with a focus on peek/poke functionality and making use of integer arrays.

Once I'm happy with this I'll feel much more comfortable moving to the next phase - implementing all those loverly X16 specific capabilities, support for the PETSCII graphics, color and cursor controls and core VERA functionality, including sound.

Oh yes, and also string handling.

Floats and file handling will come after that.

I'm looking forward now to when BLITZ can correctly handle file access and then I can BLITZ the compiler and pCode interpreter and speed things up - it's a bit slow when you have a BASIC interpreter running an interpreter written in basic to interpret pCode and run it on an emulated virtual machine!!!

I do intend to generate 65C02 code at some point, probably first by compiling the pCode from the compiler in to a series of calls to a ML run time library. Later I would like to generate 65C02 code directly from the compiler, making use of Abstract Syntax Trees and implementing the various compiler optimizations that will afford me - but that's a pretty major rewrite for the compiler...

Right, I'm off for a cuppa - I may be living in the US but I'm a British implant and after any major success or failure, we mark time by having a strong, hot cup of tea or 'cuppa'... then I'll run the compiler and pCode interpreter on my X16 DEV #0071 hardware and grab video of that to show it here for your delectation!