nullsound is now a z80 library that can be linked by users. The
sound commands are now implemented by the user, which just calls
a series of functions from the nullsound library.
nullsound internally is now much simpler. It provides simple actions
for trigerring immediate sounds; it manages a state tracker for every
part of the YM2610.
This rebuild prepares nullsound for managing interrupts and playback
of simple sound fx or music via VDM.
Fix .data2 LMA section overlapping with linkscript
The current linkscript doesn't specify LMA for sections as
they are not considered when an ELF is processed by objcopy.
However this might confuse ld when the objects are compiled
by a more recent compiler than gcc 5.5.
Fix LMA assignment by making .data, .data2 and .text consecutive.
* 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.
