When the MCD-212 'VDSC' is in two-region mode - which allows more explicit control over windowing/mixing effects - it shouldn't process the region control registers if the first region control register for each plane (indices 0 and 4, respectively) have an operation code of 0.
By continuing to process further region control registers, it can lead to the weights for a given plane being changed partway through the line, when the plane weights should be held where they were at the start of the line. This could inadvertently cause a fully-visible scanline to abruptly become invisible, but in the case of The Apprentice, it led to the planes being turned back on, which was causing 16 lines of flickering garbage at the bottom of the screen.
With that out of the way, The Apprentice looks much better.
I'm still in the process of blowing the dust out of the MCD-212 device at the moment, so I haven't submitted a pull request yet, but it will be interesting to see if this has a positive effect on any other games.
Edit: Also, I'm aware the game should have audio prior to going in-game. I intend to look into it once I've finished cleaning up the MCD-212/VDSC.
Incidentally, the VDSC is used in nearly all late-model CD-i players. However, earlier models based on the "Mini-MMC" board (which include the 605, and 910 players) used 2x VSC/VDC. The latter chips are what Magic Card are based off of. The former (VDSC) more or less rolls the functionality of the latter (VSC/VDC) chips into one package, hence the name.
Seems like I've given these forums short shrift, but have a look at what I've been investigating over the past couple weeks while gradually chipping away at the stuff necessary to put together a belated 25th-Anniversary video:
For those who aren't familiar with the overall backstory, a bunch of really crazy, and really brilliant, people decided to go and come up with a way of preserving Laserdiscs in exactly the way that I envisioned happening like 15 years ago: Tap the laser pickup, capture a raw stream of the data, and then post-process it in software.
The initial point that I was blocked on was worrying about the fact that the chroma decoder would only handle active video lines, and the existing LD captures in MAME require raising the upper "bar" of decoded lines to include VBI data. Except about a week ago, after 5 minutes of investigation, it turned out that doing so is as easy as adjusting a few variables that define the active starting lines for both fields and frames.
Currently, the main blockers are that there are some audio decoding issues. Time Traveler in particular is hit pretty hard, as there's mysterious distortion that can't be ascribed to waveform clipping, and also doesn't seem to involve CX companding. So for now, things are at a standstill until the resident audio genius on the ld-decode project can nail down what's going on. After that, though, it's pretty turnkey to bring these captures into MAME.
ld-decode is a project that stands to have as much of an impact for A/V as the people working on magnetic-flux captures have had for disk media, yet it's always seemed to have a very small but hard core of developers. I'm hoping that by promoting it a bit more, there might be a few more folks who come on board to lend their skills.
But suffice it to say that what already exists is killer: There's even support for "disc stacking": It's known that at this point, it's pretty common for Laserdiscs to suffer from disc rot. But if you can stack multiple captures from multiple discs of the same production run, the toolchain supports a best-case voting process in order to completely eliminate dropouts that only occur in a minority of discs, since the dropout locations are fairly random.
This doesn't just benefit MAME, it benefits the Daphne and Singe projects as well. This rising tide raises all boats, and I couldn't be more excited about it.
TOC (Table of Contents) handling, CD-i Ready handling, and other things have been dramatically improved in a pull request that I just submitted.
Among other things, The Apprentice now plays CDDA as expected during all portions of the game. I haven't tested Dimo's Quest - it will need re-converting from the current redump.org image - but it should be equally improved once an improved CHD comes online.
[video:youtube][/video]
Additionally, I've put a considerable amount of effort into optimizing the video chip emulation, since that seems to be the perpetual hot spot. I was hoping to post a side-by-side video showing off how much faster the CD-i driver is after the latest round of optimizations, but I can't, because the inputs desync due to some of the other MCD-212 related changes. So, the general figure is that it should be about 1.5-3x faster than it was before.
For some perspective, a 120-second run of the intro of The Apprentice would run at around 600% unthrottled on my machine with 0.239, and it now hits around 1125% unthrottled on my machine with my current pull request.
Added a couple of useful modern'ish devices for the MTX machines.
Firstly, the MAGROM, a 512K cartridge system containing many games for quick loading. Various ROM images for the device have been softlisted.
Secondly, the CFX System, a Compact Flash storage device. Also softlisted bootable CF images for: CP/M Fuzix and we can finally run Hex-Train (contains over 200MB of pre-rendered graphics)
Turns out that some debug code from when I was first getting the span draw-er up and running, which was only accepting spans that didn't exceed the presumed clipping range of the framebuffer viewport, was biting me in the ass. This looks a lot more like Polygonet Commanders.
Still some DSP bugs lurking - those bent triangles on the front of the first-person tank are pretty suspicious - but if I can get Thursday off in addition to Friday this week, I'd say we have a damn good chance of getting this sucker finalized for 0.245.
This is pretty neat. Side-by-side comparison of the initial tank-in-a-crate scene between MAME and footage of real hardware captured by Uncle Phil. The very slightly visible inset in the top part of the door, and the way the point on the bottom part of the door aligns with the credits readout are great reference points.
The Falco 5220e is a newer terminal from Falco. It's part of the Falco 500 series of terminals, released after their TS and FAME series. I previously looked at the driver, but this time I got alot further, figuring out many of the ASIC functions powering it. Here's the setup screen:
RS232 fully works, so we can connect our Linux system:
It supports a few different video modes, so here's it's maximum resolution of 132x50 lines (showing htop):
It also has multiple window as well multiple host support. Thanks to MAME we can support this too:
Here is mc on Linux at the top connected to Port A and the pfsense firewall on FreeBSD connected to Port B at the bottom at the same time. You can switch between the two using the keyboard.
The terminal supports a mouse too, and this works as well (by connecting a serial mouse to one of its ports).
More NES and friends audio fun. cam900 added an implementation of the non-linear APU mixer which means the sound balance between the 5 audio channels should be different and have all the weird quirks of real hardware—triangle, noise, and DPCM can affect one another as can the two square channels. Unfortunately this change highlighted just how off our triangle channel is. It's a clicky bastard. I've added a small fix which improves most cases (knock on wood). Hopefully, the remaining popping can be debugged. For your listening pleasure here are three versions of just the triangle channel from the title (only briefly) and start screens of Mega Man 2 (US version).
I've been sent a ROM from the Psion MC400, and with just CPU, ROM, and RAM we have: It's waiting for keyboard/touchpad input, but unfortunately it uses a couple of custom ASICs that are not documented anywhere so may struggle to get any further.
The upcoming 0.240 has a fix for nespal DPCM sample playback. Sounds were being played lower than their intended frequency due to a missing table for PAL (really the APU is missing all PAL-specific details). Here's a particularly glaring example in the bass line of a Sunsoft game that I've uploaded to illustrate the fix. I guess nobody ever tests the PAL versions of games?
Fixed a PPU bug. Grayscale mode wasn't being universally applied to palette values. I'm not sure if I would have ever noticed this but I was playing around and hard-coded the grayscale flag for fun. Only thing is if you do that you immediately notice all sorts of background colors are still in color: Anyway, here's an example of something that is actually fixed by this from SMB3. After you defeat a castle boss and return to the map the game code uses 4 frames of grayscale mode on and off to flash the screen. Here are before and after stills of one of the "flash" frames: And (mock) flashing gifs:
Really! Nobody plays the PAL version of NES games?! This one isn't as cool as the brutally-off bass of Sunsoft, but the APU's noise channel was also missing a table to compensate for the PAL NES's lower CPU clock. Here's an old favorite from Quick Man's stage:
This game is called GUPPY. Something like pacman with each level having a different maze, and there's only one enemy. The keyboard is diabolical though, and I believe the original machine was like that.
Compugraphics Powerview MCS 10 post screen It's not rotated, it's actually 3:4. It does some weird 6845 abuse where it sets the horizontal display reg to 12 which means each "character" is 62 pixels wide. Now to figure out the nasty z80sio test.
I got the latter working thanks to Casio's old SW-10 softsynth for Windows - the sound bank it uses is apparently just the entire ROM from the GT913-based MIDI modules (GZ-30M and GZ-70SP) and the WG-130 daughterboard. I've also been able to use the softsynth as a reference for improved mixing and envelope behavior.
Tab Products E-22: Line drawing characters now work properly:
Unfortunately it still needs a hack to activate the RS-232 port. I haven't yet been able to find the issue because the code is very convoluted and uses jump tables all over the place. I did find the function that toggles the necessary bit and the jump table entry for it, but not where it's actually called.
On another note, this system is still completely invisible to the Internet - I only found reference to some earlier terminals from Tab, but not this one. Obviously it doesn't help that we don't even know if the system name is correct.
EDIT: Found some references on Google Books now, so the system name should be correct.
To test this yourself, the following steps are needed:
- Start MAME with the "null_modem" device attached to "porta" - Enter terminal SetUp, then Window settings - Create a new temporary window (settings don't matter) - Delete Window 1 - Create a new Window 1 with type FBG. The followings settings worked for me: 1 / 24 / 2 / 24 / 1 - Leave SetUp - You can now load PLT files with the MAME file manager. To clear the screen use the "Next Screen" key (default mapped to Page Up). If the status shows "HS" press Scroll Lock to continue.
It's fun to watch it draw. Even animations will work - I might create a video later to show this.
In Xavix2 news, sprite scaling was partially reverse-engineered for the purposes of ltv_naru's title screen. Monkey brain pattern recognition is gud :P
AFAICT, the last thing needed to perfect this title screen rendering is better CRTC emulation, and also pointer input.
Darksoft and Team Europe dumped a Sega medal machine called "Tinker Bell". It uses the System 24 video chain minus the sprite chip, and it's started to say it's unhappy.