a mostly straight port of Charles MacDonald’s SMS Plus 1.3. sorry, only a teaser yet :]
running on pico2 @ 210mhz (need to downclock screen PIO to clock CPU any higher), but it shouldn’t be using any more RAM than the pico1 has, still need to try on that
sound is a bit choppy but works, will experiment with ways to make it smoother. ROM is baked into firmware for now, but i plan on using PSRAM to load from SD card
UPDATE: much improved since this post, pico 2 recommended but should be playable on a pico 1, download here
arm-none-eabi/bin/ld: region 'RAM' overflowed by 540 bytes
i may have to abandon support for RP2040
it works with a baked ROM, but performance isn’t fantastic even with 250mhz overclock and frameskip 4. as soon as i tried to make it load from SD (not loading the whole ROM into RAM, of course) i’m already 540 bytes in debt not counting the dynamic allocations throughout, even removing unnecessary code like the FM emulator (would love to get that working in 2350 if possible, so i just wrapped it in ifdefs)
I know some people may have trouble purchasing a Pico 2, but honestly I cannot understand why people don’t upgrade. I mean, if someone was offering a 35% speed upgrade and more RAM for their laptop for $5, people would be beating down the door.
at the moment, i have SD card loading working only for ROMs up to 32k, i’m not sure what i’m doing wrong in intercepting the mapper for larger ROMs, in fact setting a breakpoint in the mapper call never actually breaks, so i’m not sure what’s going on: picocalc-smsplus/smsplus/sms.c at main · Lana-chan/picocalc-smsplus · GitHub .
this is a very quick and dirty release, there are tons and tons of polish i still want to do, most importantly a battery meter, so don’t worry about that! i just wanted to get this out ASAP! go and play sega games!
Nice to see the PicoCalc (with a Pico2) is capable of running this so well. Nicely done!
I know it’s still early days, but I tried with the uf2loader and while the rom selection menu shows up, it just goes to a black screen when I launch any game (sms, gg, or sg).
Also, I didn’t see it mentioned in the docs, but is the “bios.sms” supported? Would it get picked up and used if it’s in the sms directory? It’s apparently optional for this emulator anyway, and I’m not sure if there are any games that require the original for compatibility, or if there’s any benefit to using the original bios at all.
i haven’t tried it with uf2loader, i’d like @pelrun’s expertise on not mangling the flash because i’m probably doing something wrong :] i tried looking up and down for information about how exactly i’m supposed to find a safe spot to use and the best i found was here which is how i tried to aim at the end of flash, for reference: picocalc-smsplus/smsplus/loadrom.c at main · Lana-chan/picocalc-smsplus · GitHub
as for using a bios, i didn’t see anything that suggested this emulator supports that? sms plus gx might, but this is the original (not gx) from 2007. as far as i know, in these emulators a (master system) BIOS does nothing more than provide a boot up animation
thanks for trying it out!
EDIT: i think i just figured something out, but right after i shut down my computer.. tomorrow morning i’ll poke at it and report back
The readme for uf2loader goes into explicit detail in the “Technical Implementation Notes” section.
Aiming at the end of flash on the RP2040 is going to cause you trouble, because that’s where uf2loader and the PicoW wifi configuration live. But if you start 16k below the end of flash, you’ll be fine.
On the Pico2, if you use the new flash API then you won’t even be able to see the bootloader let alone overwrite it.
thanks! i went looking in the code and missed that bit in the readme entirely. it does help but i think i’m still confused as to what’s “end of flash”, what’s “top of flash” or “below it” and which direction goes what, and that’s what i couldn’t find any consensus on. so by “below end of flash” if i need 512k, i should set my address to simply bl_proginfo_flash_size() - 512 * 1024 (give or take 4K alignment), or is there more to the equation? (judging by uf2loader/common/bootloader/proginfo.c at main · pelrun/uf2loader · GitHub)
i wanted to use safe flash operations (which rom_flash_op calls upon) but my problem is how i’m using the multicore FIFO for I/O (naughty, i know, but a queue doesn’t beat the speed) so i need to work around that first. i have an idea how, but one of the wires on my debugger snapped so i’m spinning my wheels until i can get to fix it
well, no matter how i slice it, or try to disable and remove IRQ handlers, i cannot get safe flash operations to work. but unsafe flash_range_* works fine anywhere but in UF2 loader.
i’m not obliterating the bootloader because that still works, and i don’t think i’m obliterating any of my program. both without UF2 loader and with, the emulator starts. the difference is that with UF2 loader after a supposed successful erase and flash, the cartridge data isn’t where i’m looking for it, so the emulator has nothing (or garbage) to run. i’m writing at flash_cart_addr and reading at XIP_BASE + flash_cart_addr, for reference (and i don’t know how to debug a UF2 flashed through UF2Loader rather than the debug probe, so it’s hard to see what’s actually there, or where there actually is). (this was a false flag, the program part was probably not running correctly under uf2loader, but flash_range_program doesn’t throw errors)
throwing in the towel for now, works without UF2 loader, PRs welcome
addendum: i tried a number of things, including moving everything other than the emulator past-load_rom back to core0 and running a dummy core which at least finally got rid of the hard assert panics. the best i can do now is that it erases the flash and then crashes when trying to program because of a save_and_disable_interrupts hardfaulting inside spin_lock_blocking inside a lengthy stack deep inside rom_flash_op that does god knows what to protect who from where. none of it asserted that something else was out of place before it went ahead with the flash operation, so i cannot for the life of me figure out what else i’m doing wrong. frankly the whole pursuit has been really frustrating, and i’m only having this problem because PSRAM turned out not to be fast enough for caching the ROM. here’s the commit in a branch with me throwing things at the wall: move to core0 for flashing · Lana-chan/picocalc-smsplus@2047b67 · GitHub
¯\_(ツ)_/¯
play without uf2loader or bake your ROMs into the firmware until someone else can look at it, i guess.
I say this because I’ve been burnt myself. Only run application code on core 1 and do not touch hardware. Use core 0 for all hardware interactions. (I lie but you really need to know the subtle details to make your code work reliably)
Also, from the SDK docs:
Care should be taken with calling C library functions from both cores simultaneously as they are generally not designed to be thread safe. You can use the mutex_ API provided by the SDK in the pico_sync library (mutex) from within your own code.
well, the only thing hardware related that was in core1 until now was the flashing process. moving it to core0 hasn’t changed how it works though (still works just like before, as long as without the bootloader). the emulator has always worked as an application on core1 making all hardware calls dispatched to core0
(and the flashing just started on core1 because that’s where the rom loading code was and my code iteration process is haphazard)
the current hardfault trying to use the newer flashing API instead of flash_range is happening somewhere deep in SDK code, while core1 isn’t even running anything (it’s only initialized with flash_safe_execute_core_init and immediately goes to tight_loop_contents to satisfy this issue) so it can’t possibly be caused by a threading issue. that’s what makes it all the more hair-pulling.
