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.
> 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.
this is where you'll need to be able to properly convert the CDi-Ready disc. The image in MAME is a bad, hacked dump, it will behave the same on hardware as it does in MAME in terms of music as all the tracks have been shifted due to MAME only loading the image if Track 1 is presented as a regular data track.
CDi-Ready has 100% audio tracks, the game data is in pregap (data before the first index) of the first track, which is recognized as an audio track.
Proper dumps can be found, but last time I checked CHDMAN could not convert them, as it made a mess of the pregap (didn't even match when converted back) I'm not sure if this has changed.
CATALOG 0000000000000 FILE "Apprentice, The (Europe) (Track 01).bin" BINARY TRACK 01 AUDIO INDEX 00 00:00:00 INDEX 01 15:22:00 FILE "Apprentice, The (Europe) (Track 02).bin" BINARY TRACK 02 AUDIO INDEX 00 00:00:00 INDEX 01 00:02:00
This is the original cuesheet, note INDEX 01 15:22:00 on the first track, the game data is stored before that.
Some music CDs use the same technique to put a hidden song before the first track too (if you 'rewind' a CD-i ready CD in a CD player to 'negative' seconds to play the pregap as you'd do with such an audio CD you'll get the data noise)
Last edited by R. Belmont; 01/06/2209:19 PM. Reason: Trimmed cue sheet so only the important part is there
yeah, just be careful not to outright treat the pregap as data, because as I mentioned some audio CDs rely on the same technique, so you'd break those. I'm not actually sure what the *correct* solution is, I think it's one of those cases that comes down to the TOC data being an approximation, and a real drive not giving a damn if something is 'audio' or 'data'
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.
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.
Just submitted (and had approved) a pull request with a minor tweak so that CDDA byteswapping is a bit smarter, so no more ear-blasting on games like Alien Gate.
I also have an outstanding PR that I just submitted to fix a region-flag issue on the title screen in Dimo's Quest. Quick before and after:
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).
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.
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:
I submitted a PR for fixing the zapper on NES and relatives. If it gets pulled check out this cool little test program: https://github.com/mamedev/mame/files/8022389/ruder.zip. It let's you use the zapper as a pointing device à la the Wii Remote—no trigger necessary. You can even play a game of pong with two people, two zappers, just by waving them up and down. Should work in MAME in the near future. Or if you're a more traditional type, kill a few ducks and gangsters on the Vs System without them being mysteriously immune to your bullets at random moments.
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).
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.
This has fascinated me since I first heard of the domesday project.
Glad to see it finally being realized!
One of the things I heard was that the storage required for these files was going to be a fair bit larger than just storing an encoded video, "CUE/BIN" or an "ISO" style file.
Is this true?
What size files will this archival project be projected to be?
Since I've made a few posts about NES APU bug fixes recently in this thread I thought I might add there was one more fix that's in the soon-to-be-released 0.242. Like the triangle channel, DPCM samples were also being played back with a heck of a lot of popping/clicking. Hopefully most of it is gone now. As an example, here's a recent recording bobz posted that is before the fix: [video:youtube][/video]. Popping sounds are all related to the drum samples. Compare with mame nes boynblobu in top of tree or with the upcoming release.
Very cool laserdisc work! Working from raw captures is super impressive.
I couldn't help but notice some strong dot crawl artifacts, e.g. on horizontal and vertical lines in the SEGA logo at 1:36. It's a bit surprising given that this is a near-static image and ld-decode has a 3d comb filter.
Very cool laserdisc work! Working from raw captures is super impressive.
I couldn't help but notice some strong dot crawl artifacts, e.g. on horizontal and vertical lines in the SEGA logo at 1:36. It's a bit surprising given that this is a near-static image and ld-decode has a 3d comb filter.
It has one, but it defaults to a 2D comb filter by default for NTSC sources.
However, the --decoder option defaulting to "automatic" is no longer accurate (judging from the source, it defaults to ntsc2d for NTSC sources). There are also now parameters for modifying the padding amount (it defaults to 8), and adjusting the first and last active frame and field lines, in order to output the VBI-containing lines as well.
Two additional Time Traveler captures from the same mastering run surfaced this past weekend, which is the minimum needed for median stacking, so at some point in the near future I'm going to have to run them through the pipeline. It would be good to have the ideal settings nailed down for when I get around to that, just so that the update to the CHD can be one-and-done, rather than having people perpetually redownloading a 15GB CHD with each incremental improvement.
The ld-decode project has a Discord server, it would be great if you'd join so that we can confer on the best possible settings.
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.
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.
Good stuff. Seems like the old adage is true, to focus on things that are within your reach. It's nice to see someone giving some love to these TV plug-and-play games.
ETA: last pic is a false positive, it actually don't kernel panic (was me messing with debugger too much) but seemingly stalls after sis900.c check:
Bonus 1: Not sure why EISA boards gets detected as "@@@0000", I'm gonna assume it needs to be floating high from the legacy ports if no board is there?
Thanks to Darksoft for tracing out the CPS-2 TOURNAMENT PCB, you’ll soon be able to run the kind of flawed Super Street Fighter II Tournament Battle setup:
It wasn’t a great implementation – it required everyone to change seats between rounds, the winner needed to return to their original seat to enter their name for the high scores, but they needed to move to their final position to claim their free games. Communication is simulated at a high level to avoid even trying to make MAME synchronise with the wall clock more frequently or anything like that.