Starduino Port WIP

[rv6502]

Got it into the good-enough zone for the emulator to accept the picture.



But I broke the sound a while back... about a year ago.
And I don't remember what I did exactly... (I do have the git history but it was a huge refactor so it doesn't narrow it down much.)

Aaaaaanyway, getting close.
I think it's the last thing left to fix other than maybe tweaking the video timing a little bit more.

The emulator is still looking at me with a frown over that video timing

Screenshot_2021-06-26_00-52-38.jpeg (116.14 KiB) Viewed 6317 times

[CunningFellow]

noice

[rv6502]

But I broke the sound a while back... about a year ago.
And I don't remember what I did exactly... (I do have the git history but it was a huge refactor so it doesn't narrow it down much.)

Okay, that was a silly bunch of hours spent looking for the problem

Code: Select all

#if ARDUBOY_ENABLE_MUSIC || ARDUBOY_ENABLE_SOUND
#include "audio_data.h"
#else
void *instrument_table[] = {};
#endif

I just needed to define ARDUBOY_ENABLE_SOUND

Now I gotta find out what part of the sound code makes the video signal glitch. Already ruled out interrupts being disabled.
Got a long Canada-day weekend coming up, should leave me some time to investigate the issue.

I think that's the last little bit left to fix.

I keep thinking, "Hey I should add some SD card FMV, that'd be neat" then I remember:

Screenshot_2021-06-29_11-46-36.jpg (15.45 KiB) Viewed 6283 times

NOOOOOOPE!

That green dot is the stack-vs-heap smash sentinel.

Hitting the point of trying to get blood out of a stone
Gonna finish this port and move on to a clean new project.
Something more adapted to the Uzebox strengths.

[rv6502]

Man, do I feel silly

I was starting to go nuts trying to figure out why the nested interrupts were seemingly not working while the audio code was enabled.

pic_4_1.jpg (125.81 KiB) Viewed 6262 times

I forgot there was another audio mixer call in the vblank handler and I missed removing it during the refactoring a year back and that part didn't have nested interrupts enabled.
And it wasn't even supposed to be called from there anymore.

Screenshot_2021-07-01_17-05-21.jpg (11.21 KiB) Viewed 6262 times

Finally time to package a release.
Wheeeeeeeeee!

[D3thAdd3r]

I'm excited to see this

[danboid]

This looks amazing for the spec of the UB / Arduino.

https://www.youtube.com/watch?v=ES3fGLuse4s

It looks like it never got a Uzebox release tho? Say it ain't so!

[rv6502]

Since my last update we've moved to a new house this past September and I'm still organising the chaos that is this new domicile.

Because what better idea than moving to a house that needs a ton of (very minor, just a lot of past-due) maintenance fixes during a crazy seller's housing market pandemic lockdowns inflation global shortage mild-apocalypse

It has put a major dent in my free time but I haven't given up

[uze6666]

Yeah I can relate about that free time bit! Things are finally settling down so have more time for projects again. Happy to see you back, that's a cool project I would love to see more of.

[Artcfox]

Wow! That looks pretty awesome. I hope to try it sometime.

[rv6502]

Soon, I promise.

I think I'm going to release a beta early just because I most likely won't be able to find the time to finish deep-investigating the (emulator?) issue this summer.

There's various glitches & crashes happening on Arduboy emulators too (but not on real hardware, neither real Uzebox nor real Arduboy) so either there's something really wonky with my code, or the emulators have ALU issues.

There's quite a bit of hand-written assembly so I suspect I'm using ALU flags in a way or sequence that gcc never uses/generates and the emulator cores have bugs that don't get triggered by gcc.

There's a few places where I interleave calculations using instructions that leave (some or all) flags intact before doing a conditional branch (saves duplicate opcodes) and it's possible the emulators mistakenly trash some flags.