dac_color_use_set was called with addr values outside the range
of the pixel buffer, and corrupted the linked list "root" pointers
Fixes the flashes of wrong color on some games.
Big Picture:
https://gist.github.com/ErnWong/7db67164224aaa3be5f6fcc2a6f5dd21Fixes#26, and fixes#179.
Implements:
- mode 4/5, x, and everything in between
- page flipping, panning, split screen
- transitions and animations that depend on changing dac_map and
vga256_palette.
- a linked list to keep track of what pixels have what color, so in
theory it doesn't need to redraw the entire buffer every time the
palettes are modified. Currently slow and incorrect.
- improved display-disable signal timing (port 3DA)
Changes:
- Add layering concept to ScreenAdapter. The idea is that using the
built-in drawImageData to handle the split screens, panning, and page
flipping would be more efficient than writing a loop to recopy pixels
one by one.
- All video modes are now handled by the same generalized pipeline, so
non-standard video modes and configurations such as Mode X will work.
- Video size and buffer size are now determined from register values.
- The code for converting the plane write data into pixel colors (also
known as the "shifting" or the "serializing" step) is deferred until the
next fill-buffer event. This appears to make programs (esp. games) run
smoother. See vga_replot
- Separate VGA redraw from SVGA 8 bpp redraw
Firefox 57 and Edge 41 do not emit keyup event for the alt key when the
alt key is pressed with other keys -- occurs on Windows 10. Firefox
appears to emit the event in Ubuntu though.
This patch is tested on Firefox (Ubuntu Xenial and Windows 10) and
Chrome.
First attempt: when pausing, clear the output buffers once using .fill(0)
during the onaudioprocess event, and set a flag so that it doesn't
have to continuously .fill(0) the buffers when paused.
Problem with first attempt: It appears that performing .fill(0) once does
not guarantee clearing all the buffer that is given to the onaudioprocess
event, probably because the output buffers given are a subarray of a larger
buffer.
In this second attempt, we simply disconnect the processor node from the
destination node, and reconnect them when unpaused.
Problem: transferring ownership of the audio Float32Array buffers from
the speaker adapter to sb16 does not appear to work.
Demo: https://jsbin.com/vilafof/edit?html,js,output
This is probably because:
> the returned AudioBuffer is only valid in the scope of the
> onaudioprocess function.
(https://developer.mozilla.org/en-US/docs/Web/API/AudioProcessingEvent)
and probably because transferring ownership will make the buffer
unreadable in the non-worker thread.
Solution: send data through to the speaker adapter directly using the
bus. The sb16.dac_buffers has been modified to allow shifting out a chunk of
consequtive elements more efficiently.
Previously, when the cpu is paused, sb16 continues to perform dma
transfers and the speaker continues to play the audio stored in the
buffer (looping), which is not what we want.
More importantly, when we pause the cpu to save the machine state,
because sb16 was continuing with its dma transfers, the machine might
restore back into a confused and muddled state.
Instead of registering an on_unmask listener every time we want a
transfer, and unregistering the listener every time we're done with it,
SB16 now registers a handler during init, and keeps this handler
registered throughout the session. The handler function is moved to SB16's
prototype.
The dma_waiting_transfer flag indicates whether the handler should
actually carry out the transfer.
- Constant variable names to uppercase.
- Consistent use of spacing and semicolons.
- Avoid recursion.
- Prefer bitwise operators.
- Place operators before line continuation (to disambiguate problems
associated with automatic semicolon insertion).
Not just working, but super smooth and crisp with no distortion.
Well, except for the wrong pitch due to a very cheap method of sampling
rate conversion. However, that's an aesthetic problem for the future.
🎉 Celebrate? 🎉
After "fixing" the dma address incrementation, the sounds are now
highly distorted with seemingly garbage signal. The dma block size is
increased to investigate this newly formed bug.