hperaza / rsx280 Goto Github PK

What would be involved in porting this to run on the original CPU280?

I'v been looking at the canonical "idle hack" so on emulated z280's the host process can not burn 100% CPU. It looks like at the tail of the dsp[123] sequence in tskmgr.mac, one could di and check again, and if still idle do an ei followed by, dunno, I/O port in to tell the outside emulation to idle the emulator until a new event. This makes it much easier to keep a virtual z280 host up and running 24/7. (This technique is very common in the emulated PDP-11 world.)

In sysfunc.hlp, .GTCMD says the first word of the buffer has the count. In fact, it's the first byte?

In my environment (Debian Buster), invoking @echo in a Makefile action line appears to invoke a builtin of the make utility itself. This builtin doesn't know about "echo -e", and thus puts the "-e" into the generated command file, failing the tkb invocation. I modified it to explicitly use /bin/echo, which does indeed have proper -e support. The obvious patch is included; I'm not sure if this is a happy fix for all the build environments you want to support.
echo.txt

The previous changeset to drop into ei/halt doesn't reach this code path as much as it should. The test for checkpoint jumps back to the top of the loop when idle, rather than flowing down into the ei/halt path. This patch does the direct jump back unless the idle halt option is present.
idle2.txt

I want to start exploring self hosted system builds, so it would be convenient to bulk import an entire source dir. I've added this to vol180 (when you just do "import

I'll submit a PR, but... do you want to continue working on this here? Otherwise I can fork.

Thanks for an awesome bit of work!

As I ramp up to look at a simulator-friendly idle mode for RSX280, I'm encountering some lack of clarity. Maybe this calls for actual fixes, maybe just some documentation notes?

I see an rsx280.sys referenced in the sysvmr rule, but that files appears to only be created in the target disk image; it's a copy of system.sys? I also see it going into [master]system.sys. So this is sort of a mirror image of how I think the copy-system rule works?

I also wanted to get some more insight by looking at the native build script, sysgen command file, but it's not in the source tree? It also works WRT a [build] which is not in the distribution. I can guess the point of syssrc and drvsrc, but those should also be officially noted, say in a script to place sources into a disk image for purposes of native kernel development?

Thanks!