* Init didn't configure z80 ports appropriately [1] so NMI were not
received by the sound driver, and no sound was emitted on Mame.
This is likely the same issue on real hardware.
* Sound commands 01/03 didn't mute the ADPCMa channel correcly, this
one is fixed. More improvement will follow in another commit to mute
all channels (SSG, ADPCMa/b, FM).
* The write to YM2610 was unecessarily waiting for YM2610 status.
This is now changed in favour of busy waiting on Z80 to allow the
YM2610 to settle between writes. This follows the information from
neogeodev wiki [1], but could not be tested on real hardware. This is
working on Mame and GnGeo.
Nightly CI deprecated mingw64 packages in favour of ucrt64
package. Update the source build steps and documentation to
drop mingw support and only provide msys2/ucrt64 support.
fd2f5fa...
by
Kaito Sinclaire <email address hidden>
Be more neat & tidy with the .data section
f03250f...
by
Kaito Sinclaire <email address hidden>
Optimize C runtime initialization
Instead of clearing or overwriting memory one byte at a time, take
advantage of the fact that #__bss_start_in_ram and #__data_start_in_ram
are already guaranteed to be long-aligned, reserve d1-d7 and a0, and
movem from them directly into the correct locations.
This speeds up the initialization sequence for larger programs by
a couple orders of magnitude.
Because this code works in blocks of 32 bytes only, some chaff is left
over at the end of user memory (from 1 to 32 bytes worth). I don't
consider this an issue, because:
- That area is the heap, used for dynamic allocation, and using it
without clearing it out yourself is _already_ undefined behavior, and
- The previous code also left a byte of chaff in the same location
due to an off-by-one mistake.
The BSS segment is also initialized before the data segment, to avoid
a bug that the original code could occasionally encounter: Because it
was off by one in its calculations, clearing out the BSS segment could
result in clobbering the first byte of the data segment, if there was
no padding between the end of the BSS segment and the start of the data
segment (aka: if the length of the BSS segment was a multiple of 4).
In addition, the watchdog is only kicked once at the end of each loop,
because they now are fast enough that the watchdog resetting the system
is no longer a concern in even the worst cases, and it confers yet
another speedup.
Follow-up fix of linkscript after [1]. The linkscript
incorrectly relies on lazy evaluation to computes the
start of the .bss segment in RAM, leaving all linked
symbols incorrectly shifted in memory.
Re-work the backup RAM definition in the linkscript
with a proper MEMORY command, and expose macros in
the ngdevkit API to override the start and length of
the backup RAM at link-time.
After the linkscript update to support large P-ROMs [1,2],
the ordering of the bss and backup RAM segments has changed,
and this broke the logic used to compute the start of the .bss
segment in RAM. Fix accordingly.
After #78 and #81, the .bss segment is now linked prior to the
.data segment. The crt0 still assumes the opposite, so the
memory is incorrectly initialized.
Since the linker now exposes symbol __bss_start_in_ram, the crt0
no longer needs to assume any ordering. Fix it accordingly.
