IM/F now properly handles the ability to alter CPU registers.

So, now, you can use M and : to "upload" a program into ForthBox memory, and R and : to set the program counter, then G to "go" to that code.

Still not ready for V1.0 yet; I need to finish implementing the trap handlers for native mode, and write all the emulation-mode logic still.

But, from the point of view of a program which lets you run other programs on the computer, IM/F is functionally complete.

Since I will be demo'ing this on Saturday for SVFIG, I suppose I should create a small program to demonstrate IM/F's current capabilities and generate the hex code for it. :)

#ForthBox #65816processor

IM/F alter-memory functionality has been implemented and now works nicely. I'm really beginning to enjoy using IM/F, and not just because I wrote it. :)

Next up will be the alter functionality for the CPU registers, and after that, implementing the CPU trap handlers needed to properly handle both native- and emulation-modes of operation.

#ForthBox #65816processor

OK, so, I'm thinking that the approach I'm taking towards my System Forth requirements IS entirely over-complicated.

Having a complicated software foundation that contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Tripos[1] is, while a technical achievement, nonetheless a red flag for complexity management.

The introduction of message passing as a system-level facility is a good indicator that that whole subsystem can and probably should be replaced with actual message passing. Like, sending messages over serial or parallel I/O buses of some sort.

I'm going to come up with a separate design spec with the intent of comparing the two approaches for feasibility.

#ForthBox #65816processor

________

1. I mean this literally; the design spec explicitly documents a single-tasking subset of just enough of Tripos to implement installable device drivers.

Spent yesterday evening trying to find a way to implement Tripos-style device drivers and interrupt handling on a #65816processor .

Getting the device driver interface working seems easy enough to do; the problem is in how Tripos interrupt handling works.

It can be made to work; but the use of Interrupt Transfer Blocks (ITBs) as documented in MetaComCo's documentation would literally take hundreds of clock cycles just to find out the interrupt wasn't of interest to your driver. Ouch!!

Now, the 68000 is significantly faster than the 65816 here, because it can properly handle indirect subroutine calls. The penalty on the 68000 might not be as bad; however, even on the 68000, this overhead adds up quickly. So, Tripos is definitely not nearly as real-time as AmigaOS, unless by "real-time" you are OK with interrupts potentially being handled in milliseconds instead of microseconds.

I will need to research an alternative approach here, I think. Perhaps Atari ST's XBRA-style of hooking 3rd party interrupt handlers is the right way to go here? Hard to say.

Once again, I find myself really wishing that the #65816processor had a JMP [$112233,X] instruction.

My machine-language monitor software for the ForthBox seems to be coming along nicely.

Console input isn't implemented yet, so that's as far as the monitor goes. The only thing it can do right now is dump the guest's registers to the screen. But, it's looking mighty nice so far.

#65816processor #ForthBox #

It's been a long time since I've written a thread-switch routine.

https://git.sr.ht/~vertigo/k1emu/tree/debug16/item/disk0/kernel.s#L138-214

#65816processor #6502processor

I think I just figured out how to implement demand-paging for the user stack on the #65816processor.

OK, it's not really demand-paging. It is, however, anticipatory paging. Yeah, let's call it that.

Like all PMMUs, a 65816-specific PMMU maintains a set of page-table entries (PTEs), each with a set of attributes. These attributes typically includes the following attributes:

1. Page type or permissions. This basically determines the R, W, and X bits of that specific page.
2. Accessed and Dirty flags. If a page was accessed since the last time it was checked (for any reason), this bit will be set. If the page was modified, then the Dirty flag will also be set. This is used to help a kernel implement least-recently-used page replacement algorithms.
3. Valid flag. If a PTE is invalid, all the other bits are meaningless to the PMMU; usually, they can be re-used by a kernel to refer to backing storage if it's been paged out to disk.

Unlike other PMMUs, though, we would need one additional attribute. Let's call it the Top flag (meaning, "top of stack"). If the Top flag is set, then the PMMU will generate a non-maskable interrupt (instead of an abort trap) if the bottom 32 bytes of the page is accessed. The idea is that if the stack pointer reaches that threshold, there's a high probability that it'll soon cross the page boundary at offset 0. This gives the kernel a chance to map another stack page before the processor runs out of stack while processing some other trap. When this happens, the old stack page's Top flag is turned off, and the newly mapped page's Top flag is set.

Why 32 bytes though? The entire state of the 65816 processor takes only 16 bytes: the one-byte registers E-flag, P, B, K, and the two-byte registers A, X, Y, S, PC, and D. When handling a trap, it's possible that pushing this state will cause S to fall below the top-of-stack threshold. This will trigger the NMI, which means we need to have enough space on the stack left over for the NMI handler. Hence, we need room for at least two contexts; ergo, 32 bytes.

This feels so wrong.

BRK, for all of my life, has been defined as opcode $00. That's it; just $00. That's all Apple and Commodore ever use it for; just a dumb, stupid breakpoint interrupt.

But, for as long as the #6502processor has existed, and as continued by the #65816processor , it is not, nor has it ever, nor will it ever be an 8-bit opcode.

It has always been a 16-bit opcode. Although the TIM monitor (the first ML monitor for the 6502 as far as I can tell) treats BRK as a 1-byte opcode, this is synthesized in its IRQ/BRK handler. The MOS documentation even mentions that BRK is a two-byte opcode.

As far as I know, my machine language monitor interface will be the first to recognize this formally, and to define interfaces based on these semantics.

I'm defining monitor APIs which use BRK as a kind of system call instruction. "Opcodes" like $FF00 and $FE00.

:blobhappy: Awwww, the 6502 has growed up!

Made some nice progress on the k1emu emulator for what will eventually become the virtual ForthBox machine. I cleaned up the repo a bit, and wrote some man pages for it.

Didn't get a chance to try running Shoehorn code on it though. I hope to do that tomorrow.

#Forth #65816processor

New release of lib65816 fixes an install bug which caused config.h to be overlooked.

#6502asm #6502processor #65816processor