pce-devel / mednafenpcedev Goto Github PK

Memory Base 128 does not seem to be supported (tested on previous version - to be confirmed on this version).

This is supported by 23 games, and is required for several of them, in particular game by KOEI in the historical strategy genre.

Currently the PCE Module doesn't allow you to see all of the scanlines.

When running with the following flags to attempt to view all of the available scanlines: mednafen -pce.slstart 0 -pce.slend 239 it will look as follows,

Note the Bottom scanline number starting at 3 pixels before the line at the bottom becomes visible.

The desired behavior is as follows:

I never know how to compile the package, and always felt that the included instructions weren't clear enough.

Now that this repo can be update by us, let's have some kind of top-level README instructions for compiling.
As a start, I found this page which actually gave me everything I needed to compile on linux:
http://jeremywininger.blogspot.com/2013/08/hey-lets-compile-mednafen-emulator.html

All I need to do was test and update settings.
(in particular, "sound.device" as per information here: https://mednafen.github.io/documentation/#Section_troubleshooting_nosoundlinux and here: https://mednafen.github.io/documentation/#sound.device )

In the same way that various memory editors display memory values in byte/int16/int32/etc. forms, it would be nice to be able to see 8-byte groups of data which are Sprite Attribute Table data, as human-readable X/Y/pattern/attributes data.

In particular, I don't find the byte/int16/int32 representations useful; this could either be displayed alongside it, or it could be displayed in place of it (and as part of a selection "carousel" of different decodes, if there are other important ones).

In the same way that background layer and sprite layer can be turned on or off, it would be nice to be able to display the "bounding box" of sprites.

To a lesser degree, a "character grid" might also be useful.

This is believed to be a result of:

  - at the second rcr, sprites and bg are both disabled,
    forcibly blanking the remainder of the screen.
mednafen does not like having the lower bound of the crop set higher than
0xF2. this will result in the lower-bound crop triggering after the vsync
handler, which ends up disable bg for the entire screen.
this appears to just be an emulation bug, though.
using a lower value like 0xF0 instead will fix it regardless.

VRAM video display should display/edit 16-bit words, not bytes.

This is especially problematic when using the address at the beginning of the line to understand the VRAM address.
Even if the memory display itself can't be altered to display/edit words, the addresses should reflect VRAM addresses rather than some some fictitious byte-based number.

The master clock counter is valuable to track how long between events, but not very easy to understand in real terms.
Adding a field counter (plus cycles since start of field) would be helpful.
Perhaps even a way to set a breakpoint on number of fields or offset within a field (whether cycles or scnalines).

Debugger opacity can be adjusted from within the debugger, using the '-' and '=' keys, but it is initially set to a fixed opacity which may be slightly too translucent for some users (like myself). This should be something which doesn't need to be adjusted each time it is run.

Several games require the implementation of variable head seek delays. In particular, the following games are known to have issues if the delay is too short (Mednafen's current delay may or may not be sufficient in each case below):

Brandish - ADPCM noise roughly 2.5 minutes into the initial cinema (when the sorceress is making a fireball)
Double Dragon II The Revenge - when you hit 'run', a voice should completely utter "Double Dragon" (but it is cut short)
Downtown Nekketsu Monogatari - when the speed is set to 'fast', and you leave the bookstore in the first town after exiting immediately, ADPCM continues speaking too many phrases (ADPCM end pointer not set properly)
F1 Team Simulation Project F - at startup, ADPCM noise shoartly after the horn honks

Many other games - significant desunchronization between the actual sound and the action (such as lip movement) . One of the more significant is "Mugen Senshi Valis"

Using Mednafen 1.27.1, Bonk's Adventure (3aa21326050c489ea867de05dd6cb7e5 Bonk's Adventure (USA).pce), quickly flashes the title card logo for 1 frame when launching the game. This doesn't happen on real hardware.

Memdebugger.cpp is a challenge, but it would be nice - one day, after 'word' visualization exists - to create a 'PCE palette' visualizer.

Today, the 'palette' memory screen displays a series of hexadecimal bytes on the left, and their ASCII representations on the right. Unused bits (above the 9-bits used for color) are ignored as inputs, and displayed as thought they were zero values.

In the immediate future, the hexadecimal display will be 16-bit words, but this still falls short of being easily-usable.

A more usable representation would be to change this to 3-digit octal - representing the 8 possible values for each of R,G,B - and simply not to display or input the unused bits. The R,G, and B values should be colored to indicate which value corresponds to R, G, and B respectively. On the right side, instead of an ASCII representation, there should be a simple square in the color represented by the RGB value.

This will be a fairly major change to the memdebugger.cpp file.

I've found that jbrandwood's "happyeyes" doesn't apply in disassembler window on Linux. I use Debian 9.9.0

Mednafen Linux build from github repository:

Mednafen 1.29.0.pceDev-1.0-win64-release

Mednafen is only returning 2-bytes for a type "0" read-toc, and 3-bytes for a type "1" read-toc.

Real PCE hardware returns 4-bytes for these commands, which is what the System Card requests.

The fix is simple. Line 219 in file "scsicd-pce-commands.inc" should be ...

case 0x0:
data_in[0] = U8_to_BCD(toc.first_track);
data_in[1] = U8_to_BCD(toc.last_track);
data_in[2] = 0;
data_in[3] = 0;

data_in_size = 4;
break;

case 0x1:
{
uint8 m, s, f;

LBA_to_AMSF(toc.tracks[100].lba, &m, &s, &f);

data_in[0] = U8_to_BCD(m);
data_in[1] = U8_to_BCD(s);
data_in[2] = U8_to_BCD(f);
data_in[3] = 0;

data_in_size = 4;

}

Initial settings which should have different values include:
;Enable (bi)linear interpolation.
pce.videoip 1

-> This should be 0 as a default/initialization value (it looks smeared when expanded on modern screens)

CPUTest here: https://www.chrismcovell.com/CPUTest/index.html

Shows the vertical line under the left edge of the "D" on real hardware, but 3 BAT blocks (~24 pix) later on Mednafen.
Need to check the code to determine whether this means that RCR triggers/raised too late, or whether it's a fixed number of opcodes after VBLANK... meaning that VBLANKS is raised too late.

Need to improve the debug screen; this is already done, but needs to be applied to the current version of mednafen

See test ROM here:
https://github.com/rgalland/PCEngine_TestRoms

When debugging, there is little-to-no visibility as to how the render of a frame of video is progressing, beyond register values. Actual frame render appears to only take place all at once, after a full frame is calculated.

Without changing the overall approach of rendering during a non-debug play session, it would be better to see the partially-rendered screen to be updated at each debug halt, ideally with an indicator of where the raster is at that point in the process (perhaps a dot which oscillates in color or something).

Currently the -qtrecord functionality has some areas for potential improvement.

The following items could allow for easier use of the resulting Quicktime media:

• Switch -qtrecord to use the png codec as a default, allowing for direct support in 99% of NLE's without having to do any transcoding

• Allow for user defined resolutions or 1:1 support. Currently the resolution is defined as follows, per the original authors intent:

"Conceptually, the video recording is done via the "ideal" video output from the emulation module, before any driver/frontend-side filters or scaling are applied.

The width is the least common multiple of the different possible horizontal resolutions on the emulated system, taking up the same physical space. For PCE, they are (nominally) 256, 341.33333..., and 512.

256 * 4 = 1024
341.33333.... * 3 = 1024
512 * 2 = 1024

The same idea is in place for PSX, though I admit 2720 is a bit...obscene. Wink

The height is treated similarly. PSX can be progressive/noninterlaced(Xx240), or interlaced(Xx480), so the least common multiple of the two is used, which
is 480.

It's done this way so as to not unnecessarily degrade video data(that and I'm not sure how to do a multiple-resolution video stream in QuickTime, and if it is possible, many video editing tools might not even accept it...).

The qtrecord.h_double_threshold and qtrecord.w_double_threshold settings control the dimensions below which the width and/or height are doubled; this doubling is why PCE is 1024x464 instead of 1024x232. It's more of a convenience feature, so that if you use an external video encoder to encode to a different format without fancy rescaling, the result won't be a blurry mess on playback. Beyond these settings, it's not possible to control the resolution of the outputted video recording via settings."

Currently the Metadata of the resulting Quicktime Recording doesn't fully list the Mednafen version we use in the encoder metadata tag:

Currently it is:
encoder : Mednafen 1.29.0.pceDev-1.0 (17b

Ideally it would be:
encoder : Mednafen 1.29.0.pceDev-1.0 (xxxxxxx) built on Xxx Xxx XX XX:xx:xx XXX XXXX

Currently the codec default when recording the output of Mednafen with the QtRecord functionality is set to cscd, the CamStudio Screen Codec.

Switching the default codec to use PNG instead of cscd will allow for almost universal player support of the resulting Quicktime media as-is, without the need for any further transcoding to use the recorded QuickTime media for whatever intended purpose.

In simple testing, switching to using PNG has also resulted in a smaller file-size compared to the current cscd default codec. A timed 1 minute attract sequence of "Street Fighter II' Champion Edition" comes in at around 27MB with the current default cscd codec, and at only 7MB or so with the proposed PNG codec default.

We have discussed that 800x600 is not the ideal size for debug screens.

One of the results of that discussion was that they should perhaps be something more like 1024x768 in order to fit reasonably into a window on a 1920x1080 screen, or to be doubled on a 4K monitor.

The other is that we should be questioning whether the current approach to scaling the debug screen is "optimal" or not. Currently, debug scaling is determined by:

1. Canvas size = (emulated picture dimensions) times (x- and y- scale factors from mednafen.cfg)
2. Then, each possible debug panel (graphics, disassemble, memory, etc.) is scaled by the largest integer that will still fit inside of the canvas size.

So, for 320x240 screen, with x- and y- scale factors of 4, the total canvas size is 1280x960 ... and the 800x600 debug screen remains a 1x scale factor, with a huge border around it.

This is done because floating-point scaling factors would cause blurring of the text which is on these screens... but there is a middle-ground which might be more helpful: to be able to scale by halves as well as full integers (selectable of course). In this case, the debug screen would be able to be expanded by 1.5x scale, to 1200x600 within the 1280x960 canvas.

This half-integer scale may not always be desirable, but there should be an option.

In 16-bit word edit mode, if you start editing words in hex, then flip to ASCII, then edit only 1 character on the ASCII side, then flip back to the hex side, the cursor disappears and there can be some confusion over where the edit is taking place.

Need to validate whether palette entries' unused bits are:
a) low, as mednafen shows
b) high, as develo seems to indeicate, or
c) actually retained but unused

While editing of data may be easier if the unused bits are represented as zeroes, Mednafen should reproduce whatever is on real hardware for any programmatic reads (if it doesn't already do so ).

@jbrandwood ran some tests on CDROM transfer rate, and determined that real hardware transfers at 150KB/s.

This has an impact on several things:

1. HuVideo (and Sherlock Holmes) actually experiences a larger delay between fetches than is currently indicated by the seektime.c function(s). HuVideo provides enough buffering to make this invisible to the user.

2. Current transfer rate (roughly 125KB/s) was apparently set due to the buffering system of Sherlock Holmes. In this case, the program seems to consume a sector once every 1/60th of a second, whereas they are supplied once every 1/75th of a second. We believe that a "sector buffer full" condition arises, requiring the CD to make a full revolution in order to pick up the overflow sector again, with the buffer having been emptied (or mostly emptied) in the meantime. However, the exact size of this buffer, and the timing of the rotation are not currently clearly-understood.

3. Existing seektimes are set in some cases in order to avoid issues - particularly ADPCM overwrite issues. In some cases, the critical period consists of several { seek, read } tuplets, for an aggregate timing. Readjusting transfer rate to 150KB/s would reduce these periods to a degree that some of the issues might reappear, so testing and possible rebalance of seek times may be required.

I noticed that an item was overlooked while implementing the FX Backup memory changes.
In pcfx.cpp roughly line 625, there is a line to allocate/link the external backup memory using the "ASpace_Add" function, and one parameter is number of bits - it was originally 15, and was not updated to 17 at the time of update.

I will correct this once the 'happyeyes' code pull requests have been digested.

Add 16-bit view mode for VDC memory (VDC-A and VDC-B)
Add SATB memory viewer for both VDC-A and VDC-B
Add SAT view interpretations for at least VDC A&B VRAM and SATB viewers

Per all of the amazing work done here by everyone involved, we should add the final pce.pal from that work to this repo with clear instructions on what it is/is not and how to use it with Mednafen.

When CPU accesses VCE palette entries during active display, last known value in latch should be reused.

Example: Dracula X has a "shimmer" effect on the water at the beginning of stage 5.
see this issue reported for MiSTer:
MiSTer-devel/TurboGrafx16_MiSTer#165

Comparing the output of MDFourier in the latest 240PTestSuite from @artemio he noticed that the Right Audio channel is starting 0.000625 miliseconds later. This is happening in both our builds and the baseline vanilla Mednafen

At the very least for debug reasons, there are times when every pixel which the machine is capable of rendering should be shown - even if traditional display would obscure them to varying degrees.

The implementation until now has been to create "visible portion" definitions, and simply not display anything which lies outside of that definition. This feature request is to make the entire normal hardware output to be visible, but to display a "bounding box" marking around the area defined to be visible. This way, it is more obvious what is clearly visible, partially obscured, and off-screen for a given viewing aperture.

Backup memory unlock bit (0x1807 bit 7) is set to unlock BRAM (i.e. set 0x1807 = 0x80).
Normally, BRAM is re-locked by reading 0x1803, but can also be locked by resetting bit of 0x1807 (i.e. same as above but the bit is reset).

External memory is configured and addressed as a "minimum viable solution", which does not match the actual hardware available.

Actual external FX-BMP cards hold 128KB of memory, but apparently the console can address substantially more (on a logical basis; the cartridge port is not yet understood understood well enough to make a cart beyond 128KB).

Mednafen should support greater than 32KB of external backup memory.

In step mode (Alt+A), the graphics viewer (Alt+2) is not available. It would be nice to see what happens to sprites and tiles when step mode is active.

There are wait states unaccounted for, in the CPU->VRAM interface.
Wonder Momo is a particular example of this; the same interrupt is used for both the raster interrupt and VBLANK; it assumes that is it on one or the other, based on the sequence, after initiated. The large block transfer into VRAM is one of few transactions which take place before the interrupt is set, so the result is that the wrong-sequenced interrupt is actually in place.

For proper wait-states, consult the implementation used in MiSTer (primarily VHDL):
https://github.com/MiSTer-devel/TurboGrafx16_MiSTer

An odd error message can arise under certain circumstances, seeming to indicate that a game's expected 2KB '.sav' file could not be loaded because it was found to be 2KB and not 128KB (which seems like nonsense).

It happens under the following conditions (and is due to residual code form a copy-paste):

• If the MB128 files has been created, and
• if MB128 is enabled, and
• if a non-MB128-using game has created a game-specific '.sav' file

Enable/disable of a sound channel is requested for PSG channels in PCE
Will need to research key combinations which make sense, as there will need to be at least 6.

During active display portion, behaviour should be as follows:

• If both Sprite display and background display bits are off at the latch point near beginning of screen display, then "burst mode" is set.
• During burst mode, Sprite color 0 is shown for the whole screen
• However, if sprite display is on and BG is off, then the active display portion of the screen should show BG color 0, and overscan should show sprite color 0. Medanfen gets this wrong and displays sprite color 0 in this case for both active display and overscan.

The attached test sets Sprite color 0 to green and background color to black.
LEFT / RIGHT sets/resets the sprite control bit, and up/down sets/resets the background bit.

PCE_bg_test.zip

CPUTest here: https://www.chrismcovell.com/CPUTest/index.html

This appears to be related to the Wonder Momo issue.

On the "X-Cycle Instructions" area of CPUTest, all of the TAI/TIA accesses to/from VRAM run too fast on Mednafen.
Example: "TAI<VRAM # 32 F3" appears to be roughly 2 or 3 pixels short of a full scanline on real hardware; on Medafen, it oscillates between 22 and 38 pixels short of a full scanline.

Various freezes throughout the game in released version of Mednafen, particularly related to cutscenes.
Use the attached save file, go to the room above, step through the conversation, freeze will happen when Motoko faints.

Private_Eye_dol_Japan.zip

Test program attached

tst_ad_len_ctr.zip

There is a bit on VCE which controls artifact visibility - one value reduces them for text legibility, and the other value enhances them for artistic presentation.

This flag modifies whether the VCE produces 262 or 263 lines per field, which in turn affects refresh frequency. While I am not aware of any games which rely on this behavior, it does affect things such as the MDFourier suite timing.

In PCE debugger, when running a HuCard image, the memory viewer "BRAM" panel does NOT show the same information as the "Physical Memory" area 1EE000 does.

This seems to be because there are two different ways of dealing with backup memory in Mednafen - one for CDROMs, and one for HuCards.

Currently when doing Qt Recording none of the shader, scanline, palette or other display functionality is accounted for. Fix it so that these options are used as defined on the command line or as a part of the mednafen.cfg file.

It would be nice to add a view of data on the stack:

That is to say, a view into the $2100-$21FF area in the vicinity of the stack pointer value, giving +/- 4 bytes of view or so.