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.
Finally making some solid progress on the Whitechapel Computer Works MG-1. This rather unusual system is based on the NS32K family, and fortunately its extensive use of many of the MMU's features has allowed me to track down and fix a number of serious bugs. Getting to this point also required supporting the Am9516 DMA controller and adding at least a high-level emulation of the μPD7261A hard disk controller, both used by a number of other similar-vintage systems.
Apart from cleaning up and merging all of the work to date, the main remaining elements for this emulation are the floppy, keyboard, mouse and cursor (the latter may be a bit tricky). Hopefully a firmware dump for the keyboard will show up soon, but I'm about to begin working on an HLE until it does.
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.
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.
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.
First it shows playback of a pattern using the built-in instruments. You can see the instruments played on the virtual MIDI keyboard. The volume in MAME is then muted, and the virtual keyboard is setup to playback the notes using the Microsoft GS Wavetable Synth.
MIDI input from outside to the emulated RZ-1 is then shown. Keys pressed on the virtual keyboard are played back in MAME.
Unfortunately the volume in the video is a bit low.
Not yet submitted, and won't be for a while yet, but things are moving steadily forward with emulating the DPB-7001. Here it is after HLE-ing the tablet (the inductor-based system for pen proximity and location was too much for me to work out), fixing some drawing bugs, and getting further with how Store 1 and Store 2 get combined.
Top-left: Combined output Top-right: Console output Bottom-left: Store 1, raw (will be removed in the submitted version of the driver) Bottom-right: Store 2, raw (ibid)
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.
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).
I started working on turning the PS/2 skeleton driver into something more fleshed out. Modified AT_MB to be a PS2_MB, turned the DMA controller into a PS/2 DMA controller device, hooked up the keyboard controller and planar VGA, got a skeleton MCA bus going, and a day and a half later it gets more than halfway through POST (checkpoint $4C of $6E) before the BIOS gives up, beeps, and throws up a timer error.
Chipping away at the PS/2 hardware still. I'm targeting the Model 80 planar because that's what I have here next to me. I'm working on getting the planar devices working before I tackle MCA in full. So far I've added a generic PS/2 PIT (the chipset features a fourth timer channel that triggers an NMI if IRQ0 isn't being serviced), the extended NVRAM, and started working on the PS/2 DMA controller. They're implemented on a ps2_mb_device like the AT motherboard. It now gets into BASIC from a hard reset with no tests bypassed or anything, but throws up a ton of POST errors.
Still working on Game Boy cartridges, filling in missing functionality and fixing issues.
This time, we’re using the picture image device that AbBee uses with his Apple II ComputerEyes/2 gizmo to do something ArBee absolutely hates – commit a “fat Chun Li” offence! I couldn’t be bothered cropping random images to match the 128×123 resolution of the M64282FP CMOS image sensor, so I let it distort them. Like the ComputerEyes/2, I’m just doing point sampling to scale the image to the target resolution. The various processing effects of the M64282FP are not emulated yet.
WIP Atari 8-bit cart refactoring, starting off with Williams and children (Express,Turbo, Diamond et al.). This allows almost every mega*, prisma* and turbo** game entries to actually boot instead of just going black screen or hardlock MAME.
Attack of the Mutant Camels (Europe) (*)
(*) not to be confused with the US release otherwise known as Matrix 2: Gridrunner (**) only working in a800xlp, and I think all these bootleg carts are from Chile -> NTSC?
The cmmb.cpp "Multipede" driver has been a major pain for a long time. I decided to bang my head into it again and while I still don't exactly understand the hardware, I've gotten it to boot into Millipede and run the attract mode approximately correctly.
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 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.
Building MAME on macOS 10.14 or later now gives you full adaptive dark mode support in the debugger. Everything changes immediately if you change modes while MAME is open and the relevant colors respond to system customization in the macOS Control Panel.
I finally found out why the Cuda ADB microcontroller program in later 68K Macs (and all pre-USB PowerMacs) wasn't reading the keyboard and mouse. I don't know how to fix it correctly yet, but a one-byte patch to the program results in correct operation, and makes the Mac Color Classic and Mac LC 520 fully working.
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:
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.
More progress on the Psion MC400, the machine is running and has working keyboard.
The System folder is empty as I now need to emulate another ASIC that communicates with the Solid State Disks. I have an image of the System Disk containing the apps, just need to work out how it's accessed.
More WIP in my Quantel DPB-7001 branch: Hard disk support.
This will make it easier to move forward: - The system no longer takes an eternity to start up. - There's no longer a long pause when interacting with the menu or palette, as the system no longer needs to spool brushes off of the Brush Master floppy every time. - It should now be possible to install typeface disks.
I've made some forward movement on getting font stamping up and running in MAME's DPB-7001 driver.
It's still not quite correct, and I'm going to have to do a pass on the alphanumeric keyboard to get the key mapping a bit less wonky, but it's starting to come together.
Funny enough, one of the biggest issues was just that the fonts were being installed onto the hard disk incorrectly. It's apparently possible to write a track out to the disk with the Disk Data Buffer Card's address set to something other than 0, and it'll happily write out a partial track with the data being sourced from that address.
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.
Interestingly, if you implement more of the CRTC, it’s less likely to hang.
The vertical smearing is a feature – the so-called 1:2:1 convolution. In reality, it reduces interlace flicker. It’s only used for indexed colour modes (bandwidth between RAMDAC and VRAM is too low to support it in direct colour mode), and it’s only used when 1MB VRAM is installed (there doesn’t appear to be a technical reason for this, just to “encourage” you to buy the card with more VRAM).
Drawing in interlaced modes still isn’t quite right, most noticeably with the vertical offset. But this is all derived directly from parameters sent to the framebuffer controller, CRTC and RAMDAC – no magic numbers.
Using CCIR 601 luminance formula to convert the colour image to monochrome, with edge enhancement implemented, and exposure adjustment implemented, we can actually see the clouds behind the Android 18/Cell chimera: