Hello everyone!

I've built my own very affordable little open source 65C02 based computer by just using a Raspberry Pi Pico as the chipset: https://xayax.net/sorbus/.

As I've got a bare minimum kernel running by now, I want to look into additional environments to include. A BASIC interpreter comes to mind at first (and will be done in the future), but I also would like to include at least one not so obvious choice. Having read about the RSC Forth included into the R65F-line of CPUs by Rockwell, I thought that this might a an interesting choice.

However, never having used Forth, I'd like to get the opinions of some more experienced persons on this. Here's what my system looks like:

• 65C02, running at ~1MHz
• Offers serial console via Pico's USB UART
• using flash to simulate a hard drive
  • 4MB
    
  • with DMA transfer
    
  • CP/M based filesystem
    
  • kernel provides load, save, etc using software interrupts
    
• memory map
  • $0000-$0003: I/O
    
  • $0004-$000F: reserved for kernel
    
  • $0010-$00FF: user zeropage
    
  • $0100-$01FF: stack
    
  • $0200-$03FF: reserved for kernel
    
  • $0400-$CFFF: user memory
    
  • $D000-$DEFF: I/O for expansion cards
    
  • $DF00-$DFFF: internal I/O (like UART, internal drive)
    
  • $E000-$FFFF: ROM space (banked: bank 0 = RAM, bank 1 = kernel, bank 2 = Forth?)
    
  • $FF00-$FFFF: Bankswitching code, handler for software interrupts, etc.
    
• Capable of running CP/M 65: https://github.com/davidgiven/cpm65
• build price: <$15

My idea was to throw the available binary of the ROM dumps through the da65 disassembler, moving the code from $F400-$FFFF to $E400-$EFFF during re-assembly and also adjust I/O (UART, etc). This worked for me rather well with porting over the monitor of the TIM chip (6530-004), even though I assume the RSC Forth kernel will be more complex or time consuming. The development ROM contents will be loaded from internal drive upon startup.

But there are a couple of questions I'd like to have asked before spending time on it:

• Is it a good idea to start with RSC Forth, or is it just totally outdated?
• If it's usable, should I go for the "small" or "large"?
• Is there already a disassembly that I can use as a starting point?
• If it's not usable, what else can I use with my memory map?
• Will there be anyone else but myself using this?

Any hints will be appreciated.

Forth on a 1 MHz 65c02? In 2024? Totally outdated? Say it isn't so!
All kidding aside, you're going to want some type of BASIC if you want the widest audience. FORTH, VTLC02, FOCAL-65, PLASMA, PASCAL, LOGO, PILOT, COWGOL ... all great choices, but a bit eccentric. BTW, I like eccentric, so consider yourself welcome, and please keep us posted on your progress.

_________________
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)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I see you use $D000.DFFF for I/O. The Apple II uses $C000.CFFF for expansion cards and softswitches. But it also has separate memory ($400 bytes) for a text page and ($2000 bytes) set aside for a graphics page. Are these pages expected to be handled by an expansion card plugged in, and if so, how would $2000 bytes, or more, get into the expansion card for graphics support?

The thing about RSC Forth is that it is based on fig Forth, but gains efficiency by using a hardware extension to the 6502 processor that speeds up the indirect threaded execution VM that fig Forth is based on.

Using a more recent forth like Volksforth (just as an example) with either a direct threaded or subroutine threaded execution VM (called "inner interpreter" in Forth circles) would probably get a more responsive system. A Forth-83 or ANS Forth (aka Forth-94) would also be more familiar to more Forth users outside of the retro 6602 universe

For the graphics card I've got a completely different architecture in mind, mostly to save GPIO pins on the RP2040 implementing and displaying graphics. The idea is instead of having registers, you have a data-stream that describes everything that needs to be done. This data-stream will be written to $00. (Something similar was done in the SNES.) Reading from $00 will give you replies like keystrokes from a USB keyboard connected to RP2040 of the graphics card. To reduce the data required to be transmitted there is the intend to implement a tile-engine a bit similar to what's in the NES.

The 65C02 command set supersedes the one of the R65F-series, so the speed up should be there also.

Taking a short look at Volksforth, I noticed that it's 13k-16k in size, depending on the platform. What intrigued me about the RSC Forth of the R65F-series was, that it's separated in a kernel (that could be run from ROM) and a development library (that could be loaded into RAM). So, there was a clean split, that I could replicate into my architecture with ease, since the RSC Forth kernel is way below the 8k available. Taking a quick look at the source code, I don't think it's easy to implement at Volksforth split there.

However, since Forth-Gesellschaft e.V. is located in Germany, as I am, it might be a good idea to contact them directly. Thanks for that hint.

I was mis-remembering there, confusing the R65F11 family with a different Forth chip ... the key thing about the R65F11 and family was the inclusion of a Forth kernel and a micro-monitor in a ROM built into the chip. Without a dictionary on the in-chip ROM, the micro-monitor worked by treating a number preceded by "N" as a number and one preceded by "W" as the Code Field Address of a word to be executed.



The key is allowing for a separated dictionary for word definitions pulled out into the Kernel system.

I don't recall the dictionary model that Volksforth uses, but even with a mingled Dictionary / Definition system, if the Kernel is fixed, this can be done by treating any Name Field Address below a certain value as a separated header word with the dictionary entry followed by the code field address in the Kernel and handling that as a special case in the dictionary look-up words.

Then you pull out as many core language code definitions as you have space in the Kernel space in the ROM.



... or find someone who is an expert in the system to help you out doing something along those lines.

Are you looking for something that fits in your ROM space, or would you consider something that would be loaded into RAM (perhaps from file using CP/M)? Tali Forth 2 should be able to be assembled for your memory map to load into RAM, but it's a bit of a heavyweight at 24K. I can help you create a platform file (which contains all of the starting/ending addresses for the various components) to make sure it avoids your reserved sections, if you are interested. Tali Forth 2 is an ANS 2012 Forth, so it's a bit more modern than FIG (for both better and worse). It will probably give you a better experience than trying to get RSC Forth running, and you can try before you buy by running it in the py65mon simulator, and the remaining RAM is plenty to write serious Forth programs in.

Google doesn't seem to realize yet that I've taken over the project for Scot Stevenson, the original author, so here is a direct link to the github repo if you'd like to take a look and see if you are interested or not.
https://github.com/SamCoVT/TaliForth2/t ... ter-64tass

The documentation is in the docs folder (look for manual.pdf) and that describes how to get started.

I'm interested in your progress regardless of which Forth you choose, so keep us posted if you get something working or get stuck trying to get something working.

Given that the RCS-Forth that is referred to with a ROM part and a RAM part was originally an on-chip ROM portion and an external ROM portion, I'd speculate that if a ~7,936 kernel could be split out of Tali Forth to be put into a Forth ROM bank, that would pull the loadable part down toward 16KB and leave more room for user codespace & data space ... plus also allow other code to call into the Forth ROM bank to make use of some of the ROM Kernel words.

Thanks for all the suggestions. It really kept me thinking.

If I'd implement it right now, I'd go for a two way approach. First I'd try to port the original RSC Forth of the Rockwell Chips, to have something period accurate. That's because the firmware I've ported so far has a vibe of late '70s / early '80s: WozMon is available as is the monitor of the TIM chip (6530-004), both are from 1976. Yesterday, I managed to get a port of Grant Searle's version of MS OSI BASIC running, so the original RSC Forth just "feels" more fitting, also from the perspective of the ROM / RAM combination.

However, I also started working on a program loader, so non-CP/M software can be run easily from a menu. The first real program I'd like to load with this menu would be the port of Tali Forth 2. Taking a look at the steckschwein implementation file, I think a port should be doable on a rainy afternoon. So, SamCoVT, expect a PM at some time in the future.

But there was the "If I'd implement it right now,..." at the beginning. So I'm decided to postpone my efforts for a few weeks (like in 2-6). This will also give the people of Forth-Gesellschaft e.V. (Volksforth) a better chance to reply and add more complexity to my train of thought.

Also I've had a breakthrough adding BASIC. The Microsoft OSI BASIC as used by Grant Searle is already running on my system, but it still needs quite some adjustments to get to a "product state". But that's something for a different category in this forum.

And I want to add some code handling VT100 escape sequences, so I've got something as a base for a UI for loading Tali.

One issue you will face with RSC-Forth is that it is targeted to microcontrollers that have the hardware stack moved to page 0. In my testing it doesn't run when the stack is in page one, but I haven't had a chance to see how extensive the modifications are required. I don't think it would be much because most of the code is in Forth rather than machine instructions.

RSC-Forth is based on FIG-Forth, and it may be easier to start with the FIG-Forth source itself. Rockwell added some extensions, the most extensive being an additional pointer called the PFAPTR in a word definition. This is what allows the split between the kernel and the development ROM. The kernel has limited functionality on it's own, it can be used as a boot loader (for the Rockwell disk configuration) or else the micro-monitor, which allows the execution of forth words but requires entering their address rather than name. The PFAPTR is also used to generate headerless code for programming in to a ROM, and there are Forth words to do this, but the programming word does require the Rockwell chip.

The development ROM also includes an assembler, but this is for the Rockwell instructions, so may. or may not be useful.

A disassembly would not be all that useful as most of the code is in the form of forth words. These are not that hard to disassemble, but a standard disassembler would not do it. I have however just completed a disassembly of the kernel and development ROM and it assembles and runs successfully on a simulator (with the stack moved as above). It's for my own assembler and hasn't been tidied up yet. It would be some work to convert to another assembler as I'm making use of some assembler specific features. My plan is to make this available at some stage, but I wanted to tidy it up a bit more first and I was also going to make some changes for my own use. My source version uses F000-FFFF for the kernel and C000-DFFF for the development ROM. The development ROM needs to know addresses in the kernel ROM, so any changes to the kernel would need a rebuild of the development ROM. There is however free space in the kernel from F000-F400 that I was planning on using for I/O code.

I did some hacking on RSC-Forth, tried disassembling it, and failed at a very early stage, for all the reasons you (jds) have mentioned. Mostly because I need to move the code, which seems to be way too hard to try for someone who has not done any Forth so far. I've got a KIM-1 clone (the PAL-1) that has FIG Forth in an extra ROM. So just for running some kind of Forth I've got something.

However, I still want to have Forth on my Sorbus Computer, right now the way I want to go is to port Tali Forth 2, also because the Steckschwein has it, which won't be the only thing both machines will then have in common... So the next thing to build will be a program loader / browser.

I'll keep you updated.

Ah, if you want period accurate, you could start from the Forth-79 that Dr. C. H. Ting developed for the Apple II. 79 Forth ROM for Apple II (pdf)

I used RSC-Forth back in the 80's on Rockwell R6511AQ chips in commercial EPOS terminals very successfully. I very much doubt it could have been done in any of these other languages that were mentioned in your eccentric bundle since Forth sets itself apart as a very efficient development, debugging, and serious turnkey runtime system for embedded hardware. I can swear by it and systems have been and are running 24/7 for decades (just waiting for the EPROM/Flash memory to fade ).

I also used Forth and more conventional 65C02s in other commercial systems such as industrial controls, vending machines etc and even a large graphic lift display network over many lifts and levels (dual graphic EL panels per display).