vCPU Questions and Necessary Details
Posted: 29 Sep 2022, 22:52
I don't know if I will make anything, but even if I don't, the information added here could help anyone who does. I've been considering making a machine that uses vCPU without the Gigatron. Using something such as the Propeller 2 microcontroller might be good since one has enough bandwidth and cores to create an entire system using mostly just 2 chips. Obviously, one would need to do the other things the Gigatron does by other means. One would need to test/locate the memory (if external memory is added), set up the memory map, provide a menu (though it would be nice to have a cartridge mode that skips the menu), have a loader, accept hotkeys, and maybe monitor the vCPU core. Plus other things would need to be done such as handling I/O, producing sound, and displaying video. So here are the questions.
1. What is the entry point of vCPU? When you select loader, where does vCPU start executing?
2. Where can we find the complete list of vCPU instructions and system calls?
3. Are there any vCPU opcodes and syscall numbers unlikely to ever be used on a Gigatron? I can see uses for having spinlock instructions for a future vCPU program type, since if all the processes have their own threads/cogs/cores/circuitry, it would be nice to have instructions to sync things. Obviously, for .GT1 compatibility, this can be done in more of a "hardware" sort of way, where 1-4 scanlines can pause the vCPU that would otherwise run all the time (and let the hotkey system handle that). However, to make such a custom machine shine, coders can better determine when the vCPU code and the video/sound need to be synced/gated. So it can be allowed to run at maximum speed unless screen/sound updates can happen too fast for the sound/video hardware (or cogs/cores) can handle.
4. How does the software query the ROM version?
5. What are the proposed opcodes/calls for changing memory banks or changing a third index register?
6. How does a vCPU program ask for file IO? I need as much info here. I don't plan on emulating the native-side mechanism for doing this. The P2 has inherent 8-channel concurrent DMA. So there can be a cog used just for file I/O and no exception handling or weird RAM instructions would be needed.
7. What file-handling support do Pluggy and Pluggy Reloaded have? I mean, what commands can it accept?
8. How do vCPU programs access the keyboard/game port? Is there a memory location for this? And how does the memory location act? Does it simply correspond to keyboard activity or does it hold it or clear it based on program activity?
9. How does the vCPU interact with the sound? For instance, how does the port know how long to hold each note? Is there a duration parameter, or does the vCPU software have to calculate how long to hold each note/tone? Would keeping the pixel rate at 6.25 Mhz and generating sound at that rate but letting the CPU run faster or during scanlines affect this?
10. How do random numbers work on the vCPU side I know there is a memory location for those, but how often are they updated? There is no syscall for this, is there? Are they only updated once per scanline or what? I ask in part because if the CPU portion is more uncoupled from the I/O, it is possible that software may ask for random numbers more often in that time. I might want to be on the safe side and allocate another cog for this or let one of the helper cogs update them more often. Generating them would be no problem since there is a unique PRNG per cog and pin that is seeded from a true source on boot.
11. Is it safe to use actual registers for the vCPU registers? Or would any software have any valid reason to read/manipulate them with Peek/Poke/Deek/Doke? I ask because I'd prefer to use cog memory rather than hub memory for this since you can do things in 2 P2 cycles from cog memory, but up to 14-15 cycles from the hub, and it varies based on when and how it is used.
12. Where is the link to the vCPU memory map? I know I can search for it, and I've seen it before.
13. How much of the memory map needs to be filled before vCPU programs load?
14. Does any software rely on the row and column data?
15. How could someone decoupling vCPU from the I/O prevent races or buffer overruns? If nothing else, one could provide halt/ready line functionality (even if it isn't a line) and let the H-Sync gate it, thus emulating current behavior. That's why I asked about spinlock instructions above since coders would know when they don't want the screen to get overwritten too fast. But without that, maybe using H-sync to gate execution would be about the best unless one wanted to get more exotic and count I/O accesses, not allowing more than 40 per scanline or more than 20K per frame.
16. Are there any other details someone would need to know to make a machine that can run GT1 files without using a Gigatron?
1. What is the entry point of vCPU? When you select loader, where does vCPU start executing?
2. Where can we find the complete list of vCPU instructions and system calls?
3. Are there any vCPU opcodes and syscall numbers unlikely to ever be used on a Gigatron? I can see uses for having spinlock instructions for a future vCPU program type, since if all the processes have their own threads/cogs/cores/circuitry, it would be nice to have instructions to sync things. Obviously, for .GT1 compatibility, this can be done in more of a "hardware" sort of way, where 1-4 scanlines can pause the vCPU that would otherwise run all the time (and let the hotkey system handle that). However, to make such a custom machine shine, coders can better determine when the vCPU code and the video/sound need to be synced/gated. So it can be allowed to run at maximum speed unless screen/sound updates can happen too fast for the sound/video hardware (or cogs/cores) can handle.
4. How does the software query the ROM version?
5. What are the proposed opcodes/calls for changing memory banks or changing a third index register?
6. How does a vCPU program ask for file IO? I need as much info here. I don't plan on emulating the native-side mechanism for doing this. The P2 has inherent 8-channel concurrent DMA. So there can be a cog used just for file I/O and no exception handling or weird RAM instructions would be needed.
7. What file-handling support do Pluggy and Pluggy Reloaded have? I mean, what commands can it accept?
8. How do vCPU programs access the keyboard/game port? Is there a memory location for this? And how does the memory location act? Does it simply correspond to keyboard activity or does it hold it or clear it based on program activity?
9. How does the vCPU interact with the sound? For instance, how does the port know how long to hold each note? Is there a duration parameter, or does the vCPU software have to calculate how long to hold each note/tone? Would keeping the pixel rate at 6.25 Mhz and generating sound at that rate but letting the CPU run faster or during scanlines affect this?
10. How do random numbers work on the vCPU side I know there is a memory location for those, but how often are they updated? There is no syscall for this, is there? Are they only updated once per scanline or what? I ask in part because if the CPU portion is more uncoupled from the I/O, it is possible that software may ask for random numbers more often in that time. I might want to be on the safe side and allocate another cog for this or let one of the helper cogs update them more often. Generating them would be no problem since there is a unique PRNG per cog and pin that is seeded from a true source on boot.
11. Is it safe to use actual registers for the vCPU registers? Or would any software have any valid reason to read/manipulate them with Peek/Poke/Deek/Doke? I ask because I'd prefer to use cog memory rather than hub memory for this since you can do things in 2 P2 cycles from cog memory, but up to 14-15 cycles from the hub, and it varies based on when and how it is used.
12. Where is the link to the vCPU memory map? I know I can search for it, and I've seen it before.
13. How much of the memory map needs to be filled before vCPU programs load?
14. Does any software rely on the row and column data?
15. How could someone decoupling vCPU from the I/O prevent races or buffer overruns? If nothing else, one could provide halt/ready line functionality (even if it isn't a line) and let the H-Sync gate it, thus emulating current behavior. That's why I asked about spinlock instructions above since coders would know when they don't want the screen to get overwritten too fast. But without that, maybe using H-sync to gate execution would be about the best unless one wanted to get more exotic and count I/O accesses, not allowing more than 40 per scanline or more than 20K per frame.
16. Are there any other details someone would need to know to make a machine that can run GT1 files without using a Gigatron?