this is a great process (for a great result). How much time does it take to port a game like this? How are you handling the custom chip read/writes? And how can you do widescreen when the scrolling of those games is super-optimized not to have a lot of data on screen? I suppose you have to throw all the code away except for the high-level logic, which takes a lot of RE time.
Custom chip operations are rewritten by purpose. Copper lists, hardware sprites and colour-register writes are SDL texture draws and GPU effects so old calls are basically triggers of intent like „fade this screen to black in 50 ticks”. Paula channel writes become mixer commands (like music fade). CIA/beam-position reads used for timing become a fixed 50 Hz game tick to maintain correct game speed, joystick reads become normal input etc.
For widescreen, Original Superfrog maintains a small scrolling buffer and draws only newly exposed rows or columns. This version keeps the whole decoded level map available in memory, so a wider viewport can simply look up and draw every tile it covers. Coordinates, collision and integer movement remain unchanged. Objects also remain active in the wider view but behaviours based on the original screen distance still use an invisible rectangle that has size of original playfield and act as a proximity trigger. Like in Ruff n Tumble where enemies don’t chase me from across the super ultra wide screen.
I won't tell how long it took to ship Frog as it would raise many eyebrows (and probably make some people upset)
I don't see why it would make people upset. Personally I re-made a few titles on SDL or Java like Supercars 2, Gods, Bagman, and attempted Magic Pockets but stopped as it was too much work without using the original source. If you publish a PC version of Magic Pockets in 1 week I'd be very happy (I even have designed extra levels). It wouldn't shock me the least. (as maybe you know) I do amiga ports of arcade games, and without A.I. (only with scripting) sometimes I can convert a game in 1 week (using more or less the same method as you but more low-level, with transcoding and MAME-like appoach for graphics), and people are also surprised by the speed. But why spending 3 years re-doing/porting something that already exists? Keep it coming. What I'd love to see is the Bitmap Bros games done. Not sure Mike Montgommery would like it though, as Gods & Chaos Engine ports exist and sell on steam (it's a scam: no extra levels, same exact graphics, except for Gods where you can choose shitty unity crap graphics instead of original). Also Cadaver, but with A.I. enhanced graphics (more colors).
About the shitty graphics, the best part is that with how I handle data means all assets can be replaced with nicer ones. Basically adfs are all read at once and all assets are decoded and "cooked" to SDL digestible forms like in memory file store, so all tiles, sprites are at game init built to modern textures, all quirks like sprites originally made from few separate parts are on the fly cooked to full modern, assembled sprite atlas etc. And there is pak file that is layout wise like a pre-cooked version of adf-based in memory storefile where all decoding happened offline, currently i cook this pak file with no original assets because of copyright reasons but if I put all assets there, game would work with no ADF bacause it seeks assets in pak and if missing, fallback to adf so if i created like remastered hero.png file with all the frog anim frames and put it in pak file, game would use it and just ignore ADF. Basically game seeks all assets from pak and reads from adf only when pak doesnt have equivalent. The same with music where game can use original player or play OGG files with metadata for where to loop.