Commander X16

For the x16 I would like to be able to include inline code.

greeting

hello, good day.

is the forth no longer being developed?

thanks.
greetings

Well, RL intervened, as it often happens. But I am getting back to the project now.

Currently working on fixing the I/O to work on C64 as well - there seems to be a number of differences. The final goal there is to get an 8K cartridge image for C64. For the X16 the idea is to move it to one of the high memory blocks. Once that is done, I will start working on the tools and utilities disk.

As for your question about the inline assembly, this would probably come as part of the tools disk - there is simply no space left in 8K. I would not go inventing my own, rather adapt the one from Dr. Dobb's Toolbook of Forth. It is not that difficult to write, Forth allows creating in-line assemblers easily, but this particular one is quite known, and it created certain syntax and conventions that were used in many places.

In case if you don't know about Dr. Dobb's Toolbook of Forth, there are two volumes filled with articles from the magazine and some extra stuff. Probably the most useful books on Forth out there. A bit difficult to find in paper form these days, but there are PDFs out there.

So, the project continues, and there should be some news soon.

Hello thanks for Info.

greeting.

New version is up. Massive rewrite of file I/O - most of the issues were caused by my lack of knowledge of actual C64, a couple of evenings with 1541 User's Guide fixed that. I think it is about as correct as it can be given the platform limitations. Most importantly, the code works identically on both X16 and C64 now! You can run the entire test suite on C64, it may take a long time, but finishes without errors.
Fixes in file system took some memory, so I had to do another round of size optimizations. That was successful as well, the binary size is still under 8K - more than that, there are about 25 bytes left for cartridge entry code. Pretty sure I can find a few more tricks if I need more byte.
So, the core is quite solid now. I will continue testing it, fixing whatever I find. Beside that the plans are:

• Prepare a cartridge version for C64.

• Figure out the best memory config for X16.

• Start working on the tools disk.

• Write some documentation, write better comments, and other housekeeping.

I have X16 hardware on pre-order, so should be able to test my stuff on it in a few months. I also got all parts for simple C64 carts, so planning to do real metal test there as well.

Updated - a few more touch ups and the process to build a C64 cartridge. The last part may be of less interest to the Commander X16 community, but it is still very cool. This version is very solid, everything I wanted to implement is there, so now it's time for cleanups, documentation, tools, and the rest of housekeeping. Ordered the hardware as well, so might be able to test it on the real thing in a few weeks.

Small fix for a bug discovered during the cartridge testing - the program would just hang if drive was not connected as device 8. Fixing it was actually trickier that it should have been due to peculiarities of Kernal I/O error reporting - apparently, if you do OPEN 15,8,15 without device 8 it will succeed, READST will return 0, but any attempt to read chars from #15 will just sit there. The way to detect this condition is do OPEN 1,8,1:CLOSE 1 and then READST will properly return 80h. Weird and poorly documented.
Anyway, it was somewhat a distraction for the project - it was supposed to be about Commander X16, not C64, but it was such a cool opportunity. Pretty sure some parts of the interpreter can be somewhat optimized for X16, but for now I should focus on the utility disk, finally.

Hey guys,

I had all but forgotten about the X16 until the last 8-Bit Guy video, and remembered how awesome it was (lol). Anyway, a long time ago I was talking with someone on here about Forth. Someone was building another one, and (I have my own 8-bit Forth going|https://codeberg.org/TheGeekOnSkates/Sk ... branch/1.0). Up till now I've been targeting the VIC-20, but the goal was always something portable across Commodore systems. Obviously, I want an X16 port too. It probably won't have half the features of yours, at least not out of the box. I would kinda like to see what you got going on; maybe contribute (I don't have a ton of time, but the idea is nice, lol). I bet some my code would be helpful to you and vice-versa.

So if you don't mind, I would like to know...
* How are you doing ":"? My little Forth, "SkateForth", has a a couple dozen native words, and looking at it now I realize a lot of them probably could/should be done in Forth (maybe). And it's tokenized, and subroutine-threaded (a huge performance boost compared with the one I was talking about on here before). But without ":" and ";" it's still pretty limited (so much so that I got distracted with other fun-projects and forgot all about it). I mean shoot, without the ability to create your own words, is it even a Forth?
* Have you cracked "if"? I have built several attempts at a Forth interpreter, not all of them 8-bit and most of them total garbage... but in all of them if/else/then seems less like code and more like something miraculous (_especially_ if your Forth supports nested if's). If you have... how? I've read something about a third stack, a mysterious "flow stack" or something like that........ no idea.
* And finally, what about accessing "high RAM"? The X16 start screen said it has 512K now... I just can't imagine being able to just do "123 12345678 !" and have it work. I expect this has less to do with Forth and more to do with my limited understanding of the whole VERA thing...

Anyway, thanks in advance for any info you may have on the subject.

Ah, VIC-20, that's a good one! Unfortunately, really starved on RAM in the base config - with the amount it has it is going to be a real challenge to get a working Forth core, even with compactness of the language. There may be a way around it if you build it for cartridge. In fact, it is possible that my version can be patched to run on VIC-20: you would need to look for CART symbol in code and touch up the start address, RAM start, and the RAM top. Cartridge prolog is also quite different on VIC-20. I don't know much about VIC-20, not sure if all Kernal calls are sufficiently compatible, but it might actually work. It would make sense to adjust some other build parameters, like number of buffers or extra token tables to save some RAM. I highly doubt that it will be able to run the test suite anyway, but it would be an interesting experiment.
I've checked your implementation - you've started with C, so it almost looks like the word set has to be static. Almost, but not quite, you still can build a hybrid implementation where a core subset goes to C and new words can be data driven. Some of the constructs may be pain to implement though. As for the question "is this Forth?" my rule of thumb is "if it can run all examples from Starting Forth then it is."
Regarding colon (:) and semicolon (;) words, the right approach is to add the concept of STATE. The STATE is either interpreting where whatever is read gets executed immediately, or compiling where everything read is converted to tokens that get added to currently constructed word. Colon would have to create a word header or token mapping. Another important notion there is IMMEDIATE as semicolon has to have that flag, meaning that it will execute even in compiling mode.
There are multiple ways to implement IF and other control structures. I've used the approach from some older implementations that does not require any extra stacks. If you search in my code for ">MARK" you will find four peculiar non-standard words not exposed in the vocabulary. All control words can be built on top of these. They are basically allowing to do jumps forward or back within the same word. The implementation is not actually using them at the moment, I just forgot to remove that block of code, but they are useful to explain how this works. So here's what should happen for IF-THEN. You need a word "(IF)" that takes the next token after it and interprets it as the address of a token to conditionally jump to. Compiling IF will actually compile (IF) and execute >MARK effectively putting the current address on the data stack and reserving one token (as zero in code). THEN actually does not compile anything but executes >RESOLVE thus poking the current address to the address found on top of the data stack. It's a little bit tricky to explain in words, if you can track down a copy of Threaded Interpretive Languages, it has nice pictures and more detailed explanations. Note that all control words should be IMMEDIATE.
Finally, about the high RAM - I don't actually know yet. I was considering sneaking the interpreter there, but now I don't think this is a good idea, it would waste a lot of cycles switching during execution. Instead, those should be used as memory. How exactly, haven't decided. My implementation supports double numbers, so I can create something with large addresses, but I am not sure if it will look natural. So, work in progress.

Thanks for the very complete reply. Sorry for the slow respons.

> Ah, VIC-20, that's a good one! Unfortunately, really starved on RAM...
Yeah, I'm targeting the 16K expansion config. A Forth - or really any language - just wouldn't fit in 3K. Not unless it's like a crazy simple Assembly monitor or something

> In fact, it is possible that my version can be patched to run on VIC-20... it would be an interesting experiment.
I'm sure it would! But just in reading your comments, I can tell your knowledge runs far deeper than mine. See below.

> ...you've started with C, so it almost looks like the word set has to be static. Almost, but not quite, you still can build a hybrid implementation where a core subset goes to C and new words can be data driven. Some of the constructs may be pain to implement though.
Funny to hear you say that. I know enough 6502 Assembly to code with it - I know most of the instructions and I've played with DASM and ca65 and all that - but to me, Assembly is bar far the bigger pain. Working with bits and bytes and memory addresses is pretty easy in C, and the bigger issue is not so much the language as my understanding of how Forth interpreters work "under the hood". I wonder if "Starting FORTH" covers what I need to learn. I've read like halfway to 3/4 of the way thru, maybe I gotta finish that.

> As for the question "is this Forth?" my rule of thumb is "if it can run all examples from Starting Forth then it is."
I like that. That's a much more reasonable goal to shoot for than the "standard" some people seem to want (which is HUGE).

> Regarding colon (:) and semicolon (;) words, the right approach is to add the concept of STATE. The STATE is either interpreting where whatever is read gets executed immediately, or compiling where everything read is converted to tokens that get added to currently constructed word. Colon would have to create a word header or token mapping. Another important notion there is IMMEDIATE as semicolon has to have that flag, meaning that it will execute even in compiling mode.
See, this is the kind of stuff I wish I understood better. Before I can try to get my head around IF, I need to get this. Do you know of any places I can go to learn how all that works? I'm guessing "Starting FORTH" is the answer again.

> Finally, about the high RAM - I don't actually know yet.
Yeah, you're getting deep into territory I have not explored yet. I am so impressed by the things you've accomplished already. If you were using C, I would suggest something like strtoull (in your string-parsing code)... but in Assembly I have no idea how that would work. But hang in there - I'm sure you'll figure it out.

Anyway, thanks for inviting me to check out your code. I may not be able to do a port to VIC-20 like you said, but if nothing else I could learn how you made a Forth work in Assembly. That is super cool. B-)