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.
I spent the majority of this weekend refactoring the MC68328 device so that I can derive an MC68EZ328 device which uses common functionality between the two chips.
There's still a bunch to be done, but the Palm IIIc - the first color PDA made by Palm, Inc. - now shows its boot screen, and can even be taken through its initial setup.
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)
Time to clean out all of the commented-out code, tighten up some of the functions, optimize it, pull-request it, flip it and reverse it. [video:youtube][/video]
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.
I've worked a bit on the Casio RZ-1 emulation and added support for both data tapes and audio tapes. I had issues with this previously, but I think one of hap's upd7810 improved this.
Here's a video loading a data tape with 80s drum samples:
And here's a video showcasing sampling from a .wav file:
A software list was also added that includes the official Casio RZ-1 Sound Collection with various samples announced by an English speaking Japanese
Fun fact: The RZ-1 uses the same tape format as the TRS-80 Model 3.
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.
In a first for Mega Drive emulation, MAME now supports the Dempa Micom Soft “horseshoe crab” XE-1AP analog gamepad. It effectively repackages the desktop XE-1AJ “cyber stick” in hand-held form for couch gaming. Released in 1989, this was the first gamepad with shoulder buttons, the first gamepad with analog thumb sticks, and the first gamepad with four analog axes, although these features were only later popularised globally by the Super NES gamepad (1990), Nintendo 64 gamepad (1996), and PlayStation Dual Analog controller (1997), respectively.
It’s supported by several Mega Drive, Mega CD and 32X games, notably After Burner II and Galaxy Force II. As it was only sold in Japan, support for the XE-1AP was not mentioned in the manuals for the export versions of the games, although support wasn’t removed in most cases (the main exception is After Burner III, where export versions dropped analog pad support and added 6-button pad support instead). Unfortunately, the games don’t even come close to taking full advantage of all the features – After Burner II only uses three of ten buttons and three of four axes.
You’ll definitely need to reassign inputs to make the most of this pad, but fortunately MAME no longer forgets your input assignments for slot devices you aren’t using. Here’s a setup for and Xbox controller that more-or-less mimics the original layout: It’s definitely not perfect – E1 and E2 should be above your left thumb (you could assign them to the D-pad I guess), and the Z/RZ axes aren’t auto-centring on the original pad.
You’ll just have to take my word that the games are more fun with analog control – there are no visual differences to show in screenshots. But here are a couple of games showing that they recognise the controller:
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'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.
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.
I pushed my latest WIP here: https://github.com/cuavas/mame/tree/gbcart Note that various things still don’t work, and the commit message there neglects to mention the camera cartridge.
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.
Flak
Green Beret
Attack of the Mutant Camels (Europe) (*)
Hardball (**)
(*) 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.
Part of the reason why I did a ton of refactoring to the MC68328 core to support the MC68EZ328 variant is because a few years ago, this one person submitted an absolutely terrible .diff regarding the VTech "IQ Unlimited" craptop. There was pretty much nothing salvageable, but with the work to get the 'EZ up and running for use in the Palm driver, I decided to apply the 5-10 lines of usable changes to iqunlim.cpp.
The changes were never enough to get it working even back then, but it at least now displays its boot screen:
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.
The display is now correct, but still missing lots of features (cursor, character attributes etc.). The RS232 port is also hooked up, so various test programs can now be used to fix issues.
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.
Atari 8-bit misc fixes: - atari/antic.cpp: VBL status is always held no matter enable irq reg, fixes a800 anteater hangs - atari/gtia.cpp: fix player/missile width rendering, fixes jmpmanjr at very least Note: last fix may have fixed other stuff too, I'm unaware of any place where they chain double or quadruple missile widths for instance (old code wasn't setting that up properly)
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.
I made a small PPU improvement a week ago to fix a minor issue with a demo called high hopes. Often times small fixes are the best—here's 8 titles that previously either completely crashed or lacked visible sprites. More to come...
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.
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.
Did you know that the original Famicom Dragon Quest, the very first version of the game that started that immensely popular franchise, is not playable in MAME? In a follow up to the Jesus WIP post above, here's a list of some more NES titles that crash and/or lack sound that should hopefully be playable in MAME and ringing in the New Year.
softlist sets: ajyureir, doordoor, dquest, dquest2, guardlgnu*, mjtaikai, portopia, qix, timelordu* (* a bit of a mess but playable)
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.
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:
Added SIC! (Super Inexpensive Cartridge!) support to Atari 8-bit, which is yet another flash ROM cart with capability of accessing rd4, flash write protect and a few other DIY options.
I made a small PPU improvement a week ago to fix a minor issue with a demo called high hopes. Often times small fixes are the best—here's 8 titles that previously either completely crashed or lacked visible sprites. More to come...
Unexpected or surprising fixes are the best fixes.