Use right-shift to toggle mouse, enter to click, space for precise mouse movement. Ctrl-Alt-F1 reboots in bootsel mode.
There are two resolutions you can pick from: the picocalc-native 320x320 but a lot of software is not made for this resolution, and the original 512x342 which requires scrolling the virtual screen.
SD card is unsupported and there is probably a ton of bugs.
Have fun
– edit –
One bug is the key ‘a’ does not work. There is a hack in the original project I need to look at.
I’m going to trump quicker posters and say double yay. Well done.
The itch for a PicoCalc delivery is getting unbearable. As for now, I’m off to AliExpress to look for 512x342 LCD panels. Ok, one more yay for a total of three.
Here is a new release with SD card support. HFS disk images (often .img, .dsk) can be copied at the root of the SDcard under the name umac0.img (only a single disk). If one is found, it will be loaded instead of the default disk. Disk images placed on the SD card are writable! I also changed the virutal screen scrolling to better follow the pointer.
I tried a bunch of games from https://www.macintoshrepository.org and Epyx Rogue worked on the pico2 for example. When downloading, make sure that the software is for macos 3.x, for the 68k CPU and that it does not require much memory. Let me know what you are able to make work.
There are uf2 for pico2 and pico (untested) here:
Remember, right shift toggles mouse movement, click with return. ctrl-alt-del reboots, ctrl-alt-F1 to bootsel.
This looks pretty cool. It looks like you always blast an entire line of the frame buffer at a time, so you might see better performance by placing the LCD into a 2 pixel per byte mode instead of the 2 bytes per pixel mode you’re using now.
You’d leave the SPI in 8 bit mode (instead of having to switch it out to 16 bit and back to 8 every scan line) and the code in video.c would need to be something like
for (int i = 0; i < 8; i+=2) {
*fb_out++ = ((plo & (0x80 >> i)) ? 0 : 7) | ((plo & (0x40 >> i)? 0 : 56))
}
for (int i = 0; i < 8; I+=2) {
*fb_out++ = ((phi & (0x80 >> i)) ? 0 : 7) | ((phi & (0x40 >> i)? 0 : 56))
}
```
(you might need to swap the 7 and 56, I don't know the pixel order offhand)
and instead of writing 0x55 to the LCD pixel format, you'd write 0x01.
Trying to build this myself; I did the recursive submodule fetch but I’m still missing a directory:
CMake Error at CMakeLists.txt:84 (add_subdirectory):
add_subdirectory given source “external/pico_fatfs” which is not an
existing directory.
Strangely, I do see pico_fatfs in .gitmodules but it’s refusing to grab it.
EDiT - managed to git clone it manually under external to get past that.
It’s also complaining that I don’t have TinyUSB. That’s intentional on my part; is it necessary to build this emulator?
EDIT 2- Figured out I needed to jump back to the top of the docs and did the pico-specific stuff. The test build of the emulator seemed to work, and I generated the two incbin headers, and ran the cmake setup step. When I run make to build, it does… something… but doesn’t actually produce any reasonable outputs.
EDIT 3 - did a submodule init under pico-sdk/lib and that fixed the tinyusb issue, and the rest of it built.
EDIT 4 - Tried implementing what I suggested above with using 0x01 instead of 0x55, but it doesn’t work correctly for some reason. Seems to hang pretty quickly with crap all over the screen (I disabled lcd_fill since it still used the wrong color mode, figured it wouldn’t be necessary since the entire screen is overwritten every update)
