Fantasy Consoles
Fantasy Consoles look and feel like retro computer systems while using modern technology.
Most popular is PICO-8 which is a sandboxed LUA virtual machine combined with an API for making games and has the look and feel of a game boy. It is sometimes called a game engine. A result of this is that it can only be used to write games in the LUA language and and the game boy screen resolution feels limited compared to the C64 screen and other non handheld 1980's systems. The same company also has the Picotron Fantasy Workstation and the Voxatron fantasy voxel console.
Fantasy Computer
The extension of the concept Fantasy to mimic retro computers. Where fantasy consoles are almost exclusively made for games, a fantasy computer also covers applications. To enable using the same programming languages that were used for classic computers emulating existing CPU:s are preferred over over something like a LUA virtual machine. To maximize performance an extensive API replaces emulation of legacy hardware making the VM fast, targetable and portable. The CPU emulation could be held intentionally slower than on classic hardware so that usage of API functionality are used to boost performance.
8-bit fantasy computer
Using processors like 6502 and Z80 tooling and skills used to program retro computers can be reused. By providing an extensive API common tasks can be handled by fast native code (Even C# code heavily outperforms running anything inside the 8 bit CPU emulator). With 6502 the BRK instruction can be used as a syscall instruction. There are of course 8-bit CPU:s with actual syscall instructions but those are rare.
This is features that would contribute to make such a software package successful
A nice goal to have is that with a Raspberry Pi (zero to five) this should be at least functionally equivalent to using a C64 for business or pleasure providing the public with a low cost personal computer in the spirit of the C64. The competition here is actual C64 emulators however those often struggle with performance on low end devices do to full cycle correct hardware emulation. The fantasy computer moves a lot of that to native ARM or DotNet binaries that run with greater speed.
It is expected that a Fantasy Computer like this can run a game like DOOM while using a lot less clock cycles than running it in a full emulator, no matter what emulator it is compared with. C64/Amiga/DOSEMU all has to work a lot harder to render the same graphics. When porting such a game to this VM the idea is to identify parts that puts to heavy load on the 6502 VCPU and extend the API to offload the work. This kind of optimization can make DOOM as fast as running it native and minimize the storage space needed for the binaries that will compile once and run anywhere.
16 bit Fantasy computer
The 65C816 were used in the Apple IIGS, SNES and the C64 SuperCPU. With 24 bit memory addressing it supports 16 MB of RAM. It also has instructions that are suitable for syscalls, wait for interrupt and stop the clock that allows for power optimization where the VCPU can be put to sleep while waiting for a wakeup condition. This would of course increase hardware requirement. The RPi Pico for example has memory enough to run an implementation of the 8-bit fantasy computer but to use 16 MB RAM an external memory has to be added. Therefore a more dynamic model that allows running on hardware with less than 16 MB of available ram would be preferred. With the RPi Zero additional memory can be added using SPI which is rather fast but using it implies implementing a virtual memory subsystem that use the processors SRAM as a cache.
Here are some potential features of such a VM
Feel free to add other interesting features here. This is not all of my ideas. However while it could be interesting to step things up to a 32 bit CPU architecture and various other features time will tell us if there is any need for that. A core idea here is to impose constraint on application and game developers and force the use of API:s. Many features that came with 32 bit system may not need a 32 bit CPU if the features can be covered by the API. In fact I am not sure that more than 64k of per application memory is needed. Also a core idea here is to begin with the 8 bit machine and get a minimum viable product as soon as possible.
Fantasy Consoles
Fantasy Consoles look and feel like retro computer systems while using modern technology.
Most popular is PICO-8 which is a sandboxed LUA virtual machine combined with an API for making games and has the look and feel of a game boy. It is sometimes called a game engine. A result of this is that it can only be used to write games in the LUA language and and the game boy screen resolution feels limited compared to the C64 screen and other non handheld 1980's systems. The same company also has the Picotron Fantasy Workstation and the Voxatron fantasy voxel console.
Fantasy Computer
The extension of the concept Fantasy to mimic retro computers. Where fantasy consoles are almost exclusively made for games, a fantasy computer also covers applications. To enable using the same programming languages that were used for classic computers emulating existing CPU:s are preferred over over something like a LUA virtual machine. To maximize performance an extensive API replaces emulation of legacy hardware making the VM fast, targetable and portable. The CPU emulation could be held intentionally slower than on classic hardware so that usage of API functionality are used to boost performance.
8-bit fantasy computer
Using processors like 6502 and Z80 tooling and skills used to program retro computers can be reused. By providing an extensive API common tasks can be handled by fast native code (Even C# code heavily outperforms running anything inside the 8 bit CPU emulator). With 6502 the BRK instruction can be used as a syscall instruction. There are of course 8-bit CPU:s with actual syscall instructions but those are rare.
This is features that would contribute to make such a software package successful
A nice goal to have is that with a Raspberry Pi (zero to five) this should be at least functionally equivalent to using a C64 for business or pleasure providing the public with a low cost personal computer in the spirit of the C64. The competition here is actual C64 emulators however those often struggle with performance on low end devices do to full cycle correct hardware emulation. The fantasy computer moves a lot of that to native ARM or DotNet binaries that run with greater speed.
It is expected that a Fantasy Computer like this can run a game like DOOM while using a lot less clock cycles than running it in a full emulator, no matter what emulator it is compared with. C64/Amiga/DOSEMU all has to work a lot harder to render the same graphics. When porting such a game to this VM the idea is to identify parts that puts to heavy load on the 6502 VCPU and extend the API to offload the work. This kind of optimization can make DOOM as fast as running it native and minimize the storage space needed for the binaries that will compile once and run anywhere.
16 bit Fantasy computer
The 65C816 were used in the Apple IIGS, SNES and the C64 SuperCPU. With 24 bit memory addressing it supports 16 MB of RAM. It also has instructions that are suitable for syscalls, wait for interrupt and stop the clock that allows for power optimization where the VCPU can be put to sleep while waiting for a wakeup condition. This would of course increase hardware requirement. The RPi Pico for example has memory enough to run an implementation of the 8-bit fantasy computer but to use 16 MB RAM an external memory has to be added. Therefore a more dynamic model that allows running on hardware with less than 16 MB of available ram would be preferred. With the RPi Zero additional memory can be added using SPI which is rather fast but using it implies implementing a virtual memory subsystem that use the processors SRAM as a cache.
Here are some potential features of such a VM
Feel free to add other interesting features here. This is not all of my ideas. However while it could be interesting to step things up to a 32 bit CPU architecture and various other features time will tell us if there is any need for that. A core idea here is to impose constraint on application and game developers and force the use of API:s. Many features that came with 32 bit system may not need a 32 bit CPU if the features can be covered by the API. In fact I am not sure that more than 64k of per application memory is needed. Also a core idea here is to begin with the 8 bit machine and get a minimum viable product as soon as possible.