Implemented GET-ORDER, SET-ORDER, FIND-NAME, FIND-NAME-IN, and a small handful of utilities. The #Forth outer interpreter is very close to being operational.

#ForthBox

Maybe a quick jump in the shower will help me figure out this ?DO and DO implementation strategy. This is, perhaps, the one time that using subroutine-threading might not be the best fit for Forth. (Everything else so far has been a gloriously wonderful fit.)

#ForthBox

Trying to implement ?do and do now. Who knew these would be some of the hardest control flows to build? #ForthBox

So while I'm stuck here at the car dealership, I think I've completed the Forth word search-wordlist. With luck, it'll work well enough that I can just use the implementation of find right of the Forth standards website. #ForthBox

Worked a bit more on #SystemForth for #ForthBox tonight. Implemented the COMPARE word to compare two strings.

I'm still trying to wrap my brain around how to perform a dictionary search using "standard" words.

I'm beginning to think it is physically impossible to do and still retain a degree of elegance.

Moore was right -- ANSI Forth was a disaster. It's perhaps best to think of ANSI Forth, and its progeny including the living standard at forth-standard.org, a museum for historical Forth dependencies.

Forgot to annotate the transcript above: it is the result of invoking TRAVERSE-CHAIN on a single vocabulary hash chain with a handler that does nothing more than print out the word's name. #ForthBox #SystemForth #WIP

System Forth for #ForthBox has an OK prompt now.

Commands don't yet exist though. Whatever you type in just gets echoed back to the user.

I'll try working on the outer interpreter in the coming weeks.

The more I think about it, the more I think that the System Forth software on #ForthBox should be (cooperatively, at least) multi-threading.

But, this opens up a can of worms of its own. If I execute a MARKER word, and there are background threads running, do I just crash? Obviously, I don't want to just crash. But, MARKER would need to record which threads are running at the time it was executed so it knows which threads to kill. And that's just plain not ideal, much less elegant. That's brute force.

@jollyrogue @jasonnab @ajroach42 F2FS doesn't seem to be well documented, which is a real shame. (At least, nothing stood out to me as a usable specification while looking over the wiki.) F2FS seems like it'd be ideal for my #ForthBox project, since I'm basically dependent on using flash-based devices.

But, there's no way I'm going to port raw C code in Linux to Forth.

Damn it.

The more I look at the direction the #ForthBox is heading in, the more concerned I get over how complex it is becoming.

@freakazoid @ajroach42 @keith For the #ForthBox, I'm planning on using the 65SIB bus. It's built on top of SPI, but can support up to 7 devices on a single channel. The channel has seven select lines on it.

I helped create this standard back around 2009 or so with Garth, and later on, Garth wrote it up in a more formal way.

Reading up on the troubles that harddrives have with shingled media recording (SMR) technology, and how the different command-sets are used to deal with it.

Brings immediately to mind how Commodore DOS preferred heavily to work with sequential media and you had to work extra to get random access.

Also reminds me, I should think about using raw block storage for System Forth in my #ForthBox project. Perhaps now is a good time to re-think how to manage raw storage. Random access might not be the best approach given today's SD card and harddrive technologies.

The #ForthBox currently uses a 65816 processor, and will run System Forth (its Forth-based OS, if you will) natively. It pretty much has to, since the overhead of interpreting another instruction set architecture (even something as simple as #uxn) will be prohibitively expensive otherwise, considering the CPU will only run at 4MHz.

However, once I complete System Forth, implementing an RV32 user-mode emulator seems like a good idea going forward, especially knowing that I can create RV32 binaries using #Rust.

It'd literally be almost as easy to implement support for RV64 as well. While RV64 and RV32 are not binary compatible with each other, they share the vast majority of the instruction set mappings, which allows a lot of code reuse between the two emulators.

This now begs the question: considering my recent posts about how we should ideally be programming for a low-level VM of some sort, I wonder if RV32/RV64 can legitimately be that VM?

There is some prior art along these lines; early RISC-V development implemented a Linux user-space environment, and used messaging to an external processor to implement "supervisor" level functionality. There was no concept of "privilege levels" in these early prototypes. And, emulation is (at least, was) listed as one of the target applications of the RISC-V Non-Privileged Instruction Set specifications.

🤔​

@thomasfuchs Stuff like this is exactly why for #ForthBox I insist on going back to the 60s and adopting some IBM #mainframe terminology.

Storage devices are either direct-access storage devices (DASD; because solid state and flash devices are not disks!) or sequential access storage devices (SASD; e.g., tape backup).

Disks just happen to be a kind of DASD, but not every DASD is a disk.

@renewedrebecca @mos_8502@tech.lgbt Nice! Are you planning on using a standard expansion bus of some kind, or will it be a single-board computer?

I was thinking of making #ForthBox a SBC that plugs into a standardized backplane, as after I'm done with this design, I'm thinking of returning to the RISC-V ecosystem. I don't want to have to throw away my hard work just to play with bigger toys.

@renewedrebecca @mos_8502@tech.lgbt In 2004, I made a homebrew 65816-based single-board computer built on Radio Shack breadboards. This was the original Kestrel computer (before it got the -1 suffix, and long before I started on its Kestrel-2 successor). Back then, it also went by a different name: ForthBox, because just like the Jupiter ACE, I wanted it to boot into Forth right from the get-go.

I never finished the complete vision, but I did get working hardware. I've long since lost the photos of the computer, but I was able to transcribe the schematics for it into a modern form and archived it onto Source Hut. See https://git.sr.ht/~vertigo/kestrel-1/tree/main/item/k1-schematics.pdf

Well, 2024 is coming up[1], and I thought it would be nice to finally work to complete the project vision. I've learned a lot since 2004, though, so I'm also updating the design somewhat.

Basically, the #ForthBox is a spin-off of the #KestrelComputerProject , going back to my roots and working to complete what I'd originally set out to make in 2004. A 20th anniversary refresh of the original design, so to speak.

It was to be another SBC which has a 4MHz 65816 (like the original[2]), a VDC-II video controller, and a standard interconnects for keyboard, mouse, and storage devices (think Commodore IEC bus, but both faster and more powerful, as it passes traffic using 9P messages).

________

1. Much too fast for my liking, honestly.

2. Mostly determined by physical timing issues at the PCB level.

@BalooUriza @thegibson I'm currently (read: should be) working on a homebrew computer design (called #ForthBox) and trying to bring up its first System Forth image.

Work takes up a lot of my bandwidth, though; enough that I don't spend much time programming for myself anymore. Even on good days at work.

So when my boss tells me to go write some Forth, he's literally telling me to stop what I'm doing, and go spend time on my own project for a change. :)

For the first time in over a month, I've finally invested coding time into the #ForthBox. Ported the "actor"[1] code from GForth into Shoehorn and, I'm happy to report, that the effort was relatively painless.

I'm hoping that if I can get the time today or tomorrow[2], I can complete the message sending primitives needed to realize async I/O in a single-tasking environment.

________

1. My actors are not the same kind of actors more universally known. They are message queues with a pair of notification handlers, designed to emulate their eponymously named concepts in a single-tasking environment.

2. I'm probably jinxing myself. In fact, I'm almost sure of it.

Yeah, you know those plans I made for this weekend to work on my #ForthBox project?

Nope. Not going to happen.

Sigh.

I will try to spend some time working on #ForthBox stuff this weekend. I'm very behind in my schedule.

Thank goodness I only answer to myself on this project! :dragonpats:​

Hoping to complete message passing and supporting FIFO-related code this weekend. Should have been done two weeks ago, but, ..., well, work sapped me of all my energy.