Open
Conversation
This fixes a minor oversight which would've been a bug, but `LoopId` is not actually used anywhere except for tracking purposes, so this had no negative effects in v.2.0.
… input checks to a separate module. This commit also adds a ton of code style and stability improvements, including: - Allocate all 127 samples for `SampleTable` to better estimate memory requirements; - Document Z80 naming conventions (e.g. _DI, _EXX and newly introduced _NR label suffixes); - Introduce `process-command.asm` module, replace all duplicate driver input checks at the end of VBlank in playback loops with calls to `rst ProcessCommandInput`; - Introduce `FLAGS_PRIORITY` to mark sample as having highest priority; - Other minor improvements.
This commit implements a much better sample priority system for 2.1 and prepares the ground for further additions (e.g. loop points). - Added sample priority bits to `sSampleInput.flags`; - Rearranged all bits of `sSampleInput.flags` field, include sample type into flags; - Reduced Z80 sample record size from 9 to 8 bytes; - Significantly optimized sample pointer calculation (by aligning sample table at 256-byte boundary and reducing record size to 8 bytes); - Update 68K and test API to work with updated Z80 sample record format; - Many code style improvements.
… record format. Fixes TYPE_NONE breaking all samples after it in the table.
…g of (CommandInput). Not relying on IX saves 7 cycles and fixes issues with requesting new samples while DPCM loop is active (because it replaces IX). Also fixed a silly bug of incorrect source-dest operand order when resetting `(CommandInput)`.
It's already debugged, let's focus on logs elsewhere.
This should save some space and make room for new features.
This commit prepares for DPCM-HQ version 1.
…pport JSON output for analysis.
…LoadActiveSampleData`. "Remaining length in ROM bank" counter was split into 8-bit registers, LOW and HIGH bytes decremented separately. Since 8-bit `dec` didn't set Carry flag, both bytes were pre-incremented by one, so 00->FF decrement becomes 01->00 and Zero flag can be used instead of Carry to catch it. However, since common sample init code was moved to `LoadActiveSampleData` routine, this trick was accidentally omitted, since it wasn't used for PCM at all. This commit restores the trick, albeit in a slightly different way: only LOW byte is pre-incremented and HIGH byte is tested for Sign flag instead, so 00->FF counter transition is caught just like with Carry flag, which works because HIGH byte can never exceed 7Fh.
This commit implements new DPCM Turbo loop with 25.8 kHz fixed playback rate.
…readahead position and length. This commit finalizes and corrects some fixes started in 8ad6062. "Read ahead" pointer was always one sample behind due to DPCM decoder optimization (it pointed to the last sample instead of the next one), so playback ended 1 sample too early. "VBlank" and "Drain" phases now temporary correct this pointer to avoid this. Remaining length in ROM bank calculation was also incorrect and wasn't fully fixed in DPCM Loop in 8ad6062. This commit also applies DPCM loop fixes to DPCM Turbo loop.
This dumps all current Z80 registers to help with test debugging.
This commit also adds generic format support (currently just DPCM) in MegaPCM playback emulator.
This commit also does small re-organization and moves `LoadDPCMTable_DI` to a separate file.
This better indicates the purpose of having different entry points to DPCM loop in the first place. Previous `DPCMLoop` and `DPCMHQLoop` naming was misleading. Also, properly export newly created DPCM type equates.
Per tests, this reliably happened in DPCM Turbo loop when entering "drain phase" when read ahead buffer was full. Non-turbo DPCM loop could theoretically suffer from the same bug, although wasn't confirmed, fix was propagated there as well. After decoding the last pair of DPCM samples, the "normal phase" loop exits into "drain phase" to play the remaining samples in the buffer. However, due to erroneous check, "drain phase" assumed sample buffer was empty (instead of full) and immediately terminated playback, leaving last 256 samples unplayed. The bug has been tied to a data race on "read ahead" and "playback" pointers. Due to optimization, "read ahead" pointer deliberately lags 1 sample behind (to re-fetch the last sample for DPCM decoding). When "read ahead" is exhausted, last 2 samples are pushed to the buffer by "normal phase", then "drain phase" is immediately entered, which checks "read ahead pointer" != "playback pointer" to keep playing. However, the maintained "safe space" between the two pointers used to be 3 samples, and since "read ahead" was advanced by 2, but lagged by 1 sample, pointers magically intersected when "read ahead" buffer was full. The fix involved two main changes: first, the allowed "safe space" between pointers was increased from 3 to 5 samples (4 would be enough, but reallocating things is a huge pain now that the Z80 RAM is almost full), then "read ahead" checks where altered in both DPCM loops to account for 1-sample pointer lag.
…e existing files for sample table.
Header's format is altered once more, now containing stream size. Special alignment of table index allows Z80 side to read it upon starting playback.
… phase. This improvement is based on logged elapsed cycles between flushing samples by `sample-buffer-playback` test.
…ave space. Alignment broke after the last commit as we ran out of space in lower 256-byte code blocks. Returning error codes if `VoidInterrupt` is reached doesn't make much sense: it's already tested by `TraceException` (will be reached by MegaPCM Viz and test suite), and once VBlank pointer is set by any loop, it's never reset back to `VoidInterrupt`. We'd rather check correlation between `LoopId` and respective VBlank routine pointer instead.
…nt DPCM-HQ format finalization. Old names were no longer accurate. These constants are exclusive to testing suite anyways, as M68K side has its own constants.
…mentation to a dedicated directory.
Replaces slow reference Python implementation, which will no longer be tested and maintained.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note
Mega PCM 2.1 is currently in beta state. Documentation update and DPCM-HQ-Conv tool tests are pending.
This PR is created to track final stages of Mega PCM 2.1 development, soon to be released publicly.
Major features