- Fixes missing sleep during ss_cont() syscall
- On a real machine, about 7 sectors before the first IRQ is received after seek,
DBUF[15] is reset. This is not consistent however and this is only an approximation.
Changes since 20250626:
- Unstable DVC now integrated into a stable release
- DVC implementation equals CDi_cdmountreset.rbf + GOP fix for Addams Family Disc 2
- CDIC: Added CD sector cache
- Catches problems caused by short HPS stalls
- CDIC: Fixed reading offset of ADPCM sound parameters
- Fixes menu sound effect of "Golf Tips"
- MCD212: Fixed switch from CLUT to DYUV without VSR reload
- Fixes graphical corruption during fade transition in "Lost Eden"
- MCD212: Fixes OFF coding
- Fixes graphical corruption in "David and Goliath"
- SERVO: Fixed disc type according to actual hardware (210/05)
- Required for the vcd module to even attempt detecting a VCD medium
- Remount is allowed without reset, when the CD wasn't read yet during power cycle
- Allows changing a disc with multi disc titles after application induced eject
- Added debug option to allow replacing the image during operation
- Also fixed tray close on image mount
- Decoupled SEQ event from GOP event.
Now behaves like real VMPEG hardware
- Fixes Lost Ride gameplay after vehicle charge intro
- Fixes timing accuracy of temp ref and time code
Measurable with mv_status()
- Fixes MPEG buffer underflow with certain titles
like "Mad Dog McCree"
- Measured on real hardware with 30 and 25 FPS MPEG stream.
Display rate seems irrelevant
- Replaced stub with actual data from stream
- Fixes value of MAS_Head as returned by ma_status()
- Stereo and Mono are correctly detected by VCD bridge
- Workaround for the pop at the end of the railroad ambience loop
in "The Lost Ride"
This is probably not the correct fix, since it seems
that the real VMPEG continues to do a subband synthesis to fade
out the playback. I don't even know how that works and
how I need to change pl_mpeg to do that.
- Fixes graphical issues with "AIUEO (Japan)", caused by perpetually
running region slots that all have the left edge as X position
In case of AIUEO, it will run through all 8 slots, resulting into RF0
having the wrong state when it matters, causing a transparency effect to fail
- Was slightly slower than real hardware. Now slightly faster than real hardware.
- Fixes black flicker during the intro of "The Ultimate Noah’s Ark", when
running in 60 Hz mode
This title is on the edge when it comes to using DC_PWrLCT just a few lines
before it is too late. This resulted into wrong mixing weights for single frames
Since no commercial software seems to use this effect,
a custom test application was written for CLUT7 and CLUT4
video modes to compare against real hardware.
- Added slow motion mode
- Added support for single step
- Fixes playback control problems with "Imagination in Motion - A New Era in 3D Chill Out Video"
This commit introduces technical debt
- The stepping mechanism is not fully understood
- Slow motion seems to desync audio and video when resuming normal playback
With the current state, the playback speed is still dictated
by the MPEG decoder. It might be possible, that this is wrong.
- Fixes data corruption when output
buffer is full with 26 frames
I was able to prove that 30 framebuffers
are not enough when allowing 26 of them
to be queued for viewing.
There is a certain distance between
allocation and actually offering the framebuffer
to the queue of ready frames.
It can reach up to 5 frames, it seems.
This is probably the result of B and P frames?
- Fixes overflow of MPEG stream data, when
pausing the playback via mv_pause()
and causing a flood of data with mv_continue()
- Fixes pausing with
"Imagination in Motion - A New Era in 3D Chill Out Video"
This doesn't fix scanning through this title.
Previously, there was an assumption that
MPEG data will never be shoveled in, faster than
the CD speed allows. This assumption is wrong
when the functions mv_pause() and mv_continue()
are involved. The FMV driver will not stop
uploading PCL data into the FMV buffer, because
the FIFO full flag was not yet implemented.
The FIFO level had to be moved around, because
it needs to be able to store at least 2324 byte
when not full.
- Optional, must be enabled in Hardware Config
The typical use case of a CD-i, based on
the Mono-I architecture, is the connection
of a pointing device to the front port or
the usage of an Ir Controller.
Both are handled by the SLAVE and usually
combined as the first pointing device.
The back port is available as a serial port.
For 2 players, the first pointing device
is connected to the back port.
During bootup, the operating system decides to
disable the serial port in favor of having
the first pointing device on the back.
The SLAVE doesn't know about this and
all input devices handled by it,
will be perceived as the second pointing device.
- Fixes long videos with even smaller frame size
- Fixes even more videos in "Les Guignols de l’Info"
This is the change of b8e3bac amplified.
The failing video this time is at seek position 0xB278800.
The previous one failing was 208x128, this one is
even smaller with 160x112.
It reaches a FIFO level of 21 until playback is started
even on real hardware.
- Instead of going for full 352 pixels, we adapt the behavior
according to real hardware, as it turns out that the software
adapts to the misbehavior of it.
- Based on analysis of the Robocop VCD, this is required
to go full screen
Since the visual quality is subpar due to the clock stretching approach,
the core shall have an option to restore the previous behavior until
that problem is solved.
It was squeezed but pixel perfect and therefore might look better
for some users
- Fixes long videos with small frame size
- Fixes videos in "Les Guignols de l’Info"
A user has mentioned that "Les Guignols de l’Info" sometimes has problems with videos.
After analysis of "/cd/rtf/application.rtf" from said disc,
starting at byte position 0x11DEA000, it turns out that the
pictures in FIFO (0x0E040A4) can go up to 17 even on real hardware.
This has never happened before and I've assumed that 8 is the maximum.
This is an issue because DecodTS of fdrvs1 calculates the DTS of the next picture with
the formula GEN_DEC_TIM1 (0x0E040A0) - GEN_PINF (0x0E040A4) * GEN_PICT_RATE (0x0E040A8).
This means that GEN_DEC_TIM1 is constantly increasing but GEN_PINF was limited to 8
before. This resulted in having the next picture to show getting more and more out of reach
of V_SCR.
On real hardware, the FIFO reaches 14 until playback starts.
- The lower 12 bits are "don't care" and the vcd module accidentally
writes twice to this space. We only care for the second write because
of the big endian nature of the long word access
- Added DSP registers for storing the derived volume
from the attenuation value
- Since the official LUT of the VMPEG is not known, a custom
one is derived, based on measurements from the real machine
- Should make "Lost Eden" more pleasant, since this game attenuates
the music during spoken dialog.
Compared to a real CD-i, I've decided to recycle the dual AD7528
of the base case to control the volume.
So, it is no longer a dual but a quadro configuration.
- Fixes soft lock of "Brain Dead 13" after company logo
Also decoupled frame display from FIFO consumption as the real hardware
will probably also do. I don't recall why I even made that change.
Partially reverts ca4216f95
I've noticed that the README is constantly updated by the MiSTer downloader, even so
no new rbf file is provided.
I would like to avoid this, considering how often I update the Quartus statistics and TODOs.
- Fixes width of VCDs according to the White book
- Current implementation uses next neighbor approach
as a first test. Linear filtering might be a better option.
This change is not 100% accurate to hardware. I can measure,
that at least my VMPEG DVC cuts off 1 pixel on the left
and 5 pixels on the right. I ignore this phenomenom for now
and show all 352 pixels, a VCD is delivering.
- VCUP and DCL IRQs should now behave like real hardware
- "FMV Moving Test" is now behaving as expected
DCL is not documented in any way. It's just that it seems
to occur at the same time as VCUP and a compare behaves differently
because of that
- This behavior is noticable on real hardware as well
If the MPEG header has no DTS, the PTS can be read
from 0x00E040A0 instead
I thought, this is essential for playback of very short
MPEG files but seems, it isn't? Having at least
one frame in the FIFO is more important, I guess
This library is not suited for playback of short MPEG files and
pauses in stream delivery at the same time.
If the stream has not enough data, frame generation is aborted.
So one would assume to just always wait until enough data
is there to decode. But that is trap, because short MPEG files
are never decoded on time.
This fix does 2 things
- If enough data for one frame to decode is available, communicate
at least 1 frame in the FIFO to the driver even so it is not yet
fully commited by pl_mpeg.
- Don't wait for data as soon as the driver has
instructed VMPEG to decode and play. I would guess that the buffer is
filled enough at that point to not underflow.
- Since my guess was wrong as underflows can still occur,
to abort the wait, the output buffer must be empty too.
There is also another fix here. The worker descriptor must now
be manually committed to increment the command counter.
Since waiting for data can now be aborted, it is possible
that a requested buffer for a worker descriptor needs to be thrown away,
which resulted into a wrong increment and an assertion failure ont the worker side.
