Would emulating vCPU on a Propeller 2 be feasible?

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
Posts: 79
Joined: 30 Sep 2020, 22:19

Re: Would emulating vCPU on a Propeller 2 be feasible?

Post by Sugarplum »

Apparently, the P2 has bytecode interpreter functions. So here is likely how a proposed architecture might look.

1. There should be a setup/supervisor cog. That can test/locate the memory, set up the memory map, display a menu, start the opening sound, provide a loader, and monitor the other cogs. For instance, it could look for things such as a hung vCPU program and provide a means to look for hotkeys. It might even be able to check for a terminated program, display a prompt, and then reset the vCPU core and restart itself.

2. There should be a vCPU cog. In my proposal, it should have a /halt line (really closer to /Rdy of the 6502) or other means for pausing the vCPU (such as opcodes, and that will need discussion maybe in another thread). That can be a memory location outside of what would be included in the map. Or it could be an interrupt to a spinlock. The reason for a /Hlt or /Rdy line is for syncing things with the video and for things such as waiting on external RAM (particularly serial RAM). There can be some optimizations such as page 0 being in the CPU core's cog RAM.

3. There will need to be at least 1 general I/O core. Perhaps it can handle the video, sound, and maybe the keyboard and random numbers. If I am not mistaken, there is a memory location for random numbers. But if that cannot be handled in the general I/O core, maybe it could be handled in an auxiliary I/O core. Of course, a more optimal solution would be if the vCPU had an opcode for random and bounded random numbers. However, adding such won't help existing programs. Now, the reason for adding a halt mechanism would be to help gate the program speed and also in case the vCPU cog can get ahead of the video. I imagine vCPU would be faster than in the version that emulates the native Gigatron.

4. There will likely need to be a storage I/O core (and maybe other peripherals).

5. Pluggy and similar could be included either as its own cog or as part of another.

6. External RAM could be added. Of course, a choice would need to be made here. Serial RAM would use fewer pins, but parallel SRAM would be faster to access (and likely faster than accessing hub RAM and more predictable) and take more pins. Of course, things could be done such as using the /CS line and thus freeing up those lines, and an inverter on the /CS could let other devices know they can use the lines (or omit the inverter if the select pin usage rules are already opposite for the other device).
Post Reply