Micro Craft Dimension 68K, currently with a hack because they're doing something we don't support with the disks (double-stepping assuming a double-density disk in a high-density drive):
I haven't looked at MAME in quite a while, but I have to say I'm thrilled to see that improvements to support for ridiculously obscure hardware continue to appear.
And we got a proper dump of the sound program. It's weird - I don't know if it was made with some kind of compiler or they gave it to the intern, but the code's very strange.
This is the Kyber Minus from Kyber Calcolatori, it's a CP/M clone thing.
The owner has provided a boot floppy image for it but am having trouble getting it to even attempt to boot, a ready signal from the floppy drive should generate an interrupt to trigger the boot process. I have a schematic so may submit as is in case anyone else can make more sense of it.
BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
I've been in contact with Steve Hunt, who dumped the m3 ROMs and wrote the replacement monitor ROM. He gave me his custom CP/M floppy images, so that I've been able to hook up floppy support:
Still no official software, but at least the machine is usable now.
I also have a new version of the monitor ROM that supports booting from IDE.
Having researched Sun Electronics/Sunsoft for five years, I am really happy to finally see that G.T. Block Challenger have been dumped. I made that Fandom wiki page. The text is not very correct. I am almost finished with my first magazine about Sunsoft, where I cover their old games. So, I will be really happy to make changes to the text so it no longer says it is lost. And some screenshots will be great too.
The Regnecentralen RC759 can now boot one of the floppies:
Keyboard works, and the 82730 was much improved too.
There are random floppy I/O errors though and other disks don't even get that far. I'll probably take a break now, the 186 isn't really my favorite CPU.
I took a look at a random skeleton driver and fleshed it out:
It's a "Bingo Pinball". It partially works, but of course it's a bit pointless without ball physics simulation. The service mode is interesting though, it allows you to read and write all locations in memory.
The terminal for Sega's "Bingo Circus" was dumped last year. I've made it mostly work:
You can see the attract mode and use the service mode. However when you insert coins it tells you to wait for the game to start - here it wants to communicate with the host. In reality there are 8 terminals attached to the host system. Not an issue for MAME of course:
The machine info looks cool with 17 Z80 CPUs and more :P
Here's a picture of the full unit: https://segaretro.org/File:BingoCircus_Arcade_Cabinet.jpg
I'd love to see one of these server+terminals games actually fully working, so this is cool progress. Looks like the server is System 16-ish, and the terminals are upgraded Master Systems, so it oughta be possible to get it running.
the problem is a lot of the time there are more boards than just server / terminal, at least with the EM ones, but yes, it would be good if one day we can just type "mame bingoc" and have it fire up a server and all the terminals
Reached an initial milestone for the extremely rare NS32016-based Tektronix 6130 Intelligent Graphic Workstation. It was supposed to be part of a family of 6100 systems, but it never gained much traction. There's a slightly younger 4132 model which is very similar, mainly exchanging the MFM hard disk controller for SCSI, so hopefully that will be fairly straightforward to emulate as soon as firmware shows up.
It's starting up and passing a number of diagnostics before failing to boot and reverting to a strange monitor on the second serial port. The Am9516 DMA controller used by the floppy controller isn't implemented yet (also needed elsewhere, like Sun 3), and it doesn't like something about the i82586, but otherwise looking pretty good. Now we just need the 6100 version of UTek installation media or a hard disk image and we should be able to claim another unique Unix workstation emulation for MAME.
With this and the Acorn 32016 second processor now running the Panos operating system successfully, it seems like most of the bugs in the NS32000 CPU core are sorted out; the major remaining task is to implement the 32082 MMU. Fortunately given the abysmal performance of this CPU, emulating at full speed via interpreter is no problem.
it's noted in the software list (that note should be updated now it's fixed) so I can't take credit for the observation, I just mentioned it in passing conversation because I'm trying to put together some driving games to play on stream, and noticed both this and overtake had problems, with this one being mentioned, but no note at all for overtake (so I don't know if I'm doing something wrong there, but I can't get that one to recognize disk changes)
Overtake is a bit weird with how it handles the disks. You need to:
- Boot with the system disk on drive 1 and data disk A on drive 2 - Select "game" from the first menu - Wait a long time until it requests disk B - At this point the machine should have ejected the system disk from drive 1 (the X68k has a Mac-like software-controlled ejection mechanism). Insert data disk B in its place. - It will continue loading and eventually show another menu where you can actually start the game
It seems to have a lot of graphical glitches, though.
Yeah, the x68k emulation still has it's fair share of issues; seems to handle most of the shooters I've tried, but results with other types of game have been mixed, although I'm not always sure if that's user error or not (being a full-blown computer, there's plenty of room for user error, even if it's just using the wrong amount of RAM, or not understanding a disk prompt change, or not understanding a game needs HDD install, or some extra peripheral)
https://github.com/mamedev/mame/commit/c89891e4aa3746da8d3f325a6e4db5bd1468e1c8 fixes the overtake flickering. The pcm audio doesn't work though (the fm music does work if it's enabled in the menu). The walls beside the track which don't appear in XM6 seem to be in real hardware videos so AFAICT they aren't a graphic error.
nice, definitely looks more like it'll be worth showing now.
is the cause of the PCM issue obvious? could it be lack of RAM, or the game needing to be HDD installed?
slightly off-topic, but does anybody know how to get Runner's High on the PC98 machines to run (which machines, which options etc.?) I can't tell from the notes if that will be worth showing, but they indicate it should be doing more than I could ever get it to do.
As far as I can tell it's an emulation issue, the game requires 2 MB (the MAME default is 4) and it should be playing ADPCM sounds even with that.
Runner's High supports the PC-9801-86 sound card, so you probably want to use it. Also, I'd recommend using a 486-based machine like the Ce2 for the best speed.
The "right" way to run it would be using the DiscStation 10 CD, but there's also a "fake" floppy version in the softlist that was ripped from the CD, and it's easier to use. You could use this command line:
Since we're on an "old Japanese computers" theme now, my fix for the FM Towns audio balance just went in, so anything that uses FM+PCM or FM+CDDA (which means, of course, a lot of eroge, but also some "clean" stuff like Asuka 120%, Emit or Genocide Square) should sound a lot better.
I think the Asuka fix has broken some other things... I haven't tested too many, but Shadow of the Beast and Galaxy Force 2 hang when you are about to start playing, for example.
When I was investigating other things I found out that some games are very sensitive to the timing of the sprite flag, so maybe it's related to that.
https://github.com/mamedev/mame/commit/c89891e4aa3746da8d3f325a6e4db5bd1468e1c8 fixes the overtake flickering. The pcm audio doesn't work though (the fm music does work if it's enabled in the menu). The walls beside the track which don't appear in XM6 seem to be in real hardware videos so AFAICT they aren't a graphic error.
You can turn the walls on / off in the config menu before you start the game, it calls them Polywall
The game seems to work pretty well, although the tunnels on the Monaco track look like the raster isn't quite working as it should, I suspect it should repeat a blank line, instead it repeats the top of the road?
doesn't impact playability, but thought it was worth pointing out.
Rather than a off by one, the partial updates were including the current line which was drawing it before the irq handler could update the scroll register. The line of bad pixel at the bottom is a harmless hack to make sure a raster irq at the last line would arrive before vblank (which broke akumajo), the correct solution would be to make 256 modes be 512 pixel high and double scan every line.
Ah, makes sense, and overtake looks great now. With terradrive working too I'll be sure to include both in the upcoming stream, as something a bit different
While still on the subject of x68k racing games, super hangon for the x68k seems to have a different issue, one with background colours often being rendered as black rather than as they should be. This means the music select screen has a black background, when it should be orange, and parts of the sky are black too. Had that one just been the sky, I would have guessed raster split too, but because an entire screen has the wrong background colour, I'm not so certain
(also does anybody know how to accelerate in groupx, also on the x68k, I can find the gear shift keys, I can see the mouse does some kind of steering thing at the top, but nothing seems to be move me forward)
I got curious about Group X... it's pretty hard to guess the controls without a manual, but I think I figured it out.
First you have to map something to the HELP key on the keyboard and push it once, that's the car ignition. Then you shift gears with S and D, and push space to accelerate. You can steer the car by moving the mouse while holding down a button (I think it doesn't matter which one).
While still on the subject of x68k racing games, super hangon for the x68k seems to have a different issue, one with background colours often being rendered as black rather than as they should be. This means the music select screen has a black background, when it should be orange, and parts of the sky are black too. Had that one just been the sky, I would have guessed raster split too, but because an entire screen has the wrong background colour, I'm not so certain
This part is caused by apparently the hardware selects the lowest priority tile layer pixel to draw if all layers are transparent.
This one by the 0 color index being treated as transparent which as I recall I assumed was true based on other behavior but nothing expects it (at least nothing I know of... ).
While still on the subject of x68k racing games, super hangon for the x68k seems to have a different issue, one with background colours often being rendered as black rather than as they should be. This means the music select screen has a black background, when it should be orange, and parts of the sky are black too. Had that one just been the sky, I would have guessed raster split too, but because an entire screen has the wrong background colour, I'm not so certain
This part is caused by apparently the hardware selects the lowest priority tile layer pixel to draw if all layers are transparent.
This one by the 0 color index being treated as transparent which as I recall I assumed was true based on other behavior but nothing expects it (at least nothing I know of... ).
very nice, I'll be sure to give this one a spin in an upcoming stream :-)
Just added a fancy internal layout for the TX81Z, which is sounding quite reasonable now. (Sadly, missed the 0.232 cutoff, so you'll need top of tree.)
Also a 16:9-friendly view because the full one is hard to read unless you've got a 4k display:
(And yes, crt-geom-deluxe seems to be applying to the LCD display -- probably shouldn't)
Keys are hooked up (thanks to RB for already figuring out that part), but the copious buttons and LEDs will require emulating the little driver multiplexer chip. Shouldn't be too hard, I think.
The goal is to be able to switch instruments so I can see how the OPQ is handling things other than "organ", which seems to be the default.
Fixed the visible area so Cotton is correctly stretched. The score bar is correctly opaque, at least in videos from unknown sources, too but the part above should either be black or in the overscan area. It's a bit neat to see the keyboard lights which seem to act as some kind of music visualization.
Fixed the Mid-garts opening sequence. As part of that fix most games have 512 lines now.
Edit: Fixed crash due to unimplemented dmac transfer array chaining. To run the actual game you have to boot the machine from disk 2 as disk 1 only contains the intro.
another one I'll have to have a look at one stream
I've been testing a few more, and noticed that "ilmlaser Illumination Laser Rebuild" runs the menus in super slow-motion with the regular x68000 driver, but the menus are ok with the 16mhz 'x68kxvi' driver. Is that the same in other emulators? (if you manage to start the game it's fine in both drivers, it's just the menu where it's trying to do some raster effect that's painfully slow on the regular x68k)
there also seem to be quite a few games I can find videos of that aren't softlisted, so I guess some games need locating and documenting, unless they only exist in unsuitable formats.
Edit: Fixed, timings for the opening are very tight and refresh for the mode it uses were too fast. It uses hsync irq for the title effect and before when they were suppressed during vsync it had extra time to work with. Further testing shows that change to fix terra drive is correct and the slower refresh is also right.
Yes I saw that and the audio in XM6 does freak out there. It's loading the adpcm dma channel with bad data which seems to halt the cpu with a bus error. Maybe the dmac isn't supposed to cause bus errors? BTW, I did find a cheat 0x3ed1e is the lives counter.
hmm I wonder if ADPCM is just meant to read blank data rather than causing a bus error in that case then (I guess XM6 doesn't generate the bus error, but does feed it garbage?)
was there an older non-gold Mid Garts release? maybe they cut a sound but forgot to remove the trigger? (or could it be a bad dump? failing to load a sound it needs?)
Mid Garts was for PC98 (and MSX, etc): [video:youtube][/video]. Mid Garts Gold is a modified version (shooter instead of adventure hybrid) that came out later the same year on the x68000.
ah interesting, didn't know that, explains why it is so story heavy anyway. I'm curious to know if there are any original hardware videos for the x68k version to know if there's meant to be a sound effect at the point it crashes which isn't just garbage however (and if the dumped disk has ever been tested on hardware)
(this original release looks like a much better game too, although I guess it relies on more Japanese knowledge)
There's this group: https://mijet.eludevisibility.org/Preservation/. I can't find a match for the opening disk 1, but the other 3 disks match MAME's software list (after format conversion). Notably they have marked the game disk 2 as [f], that is "fixed". Maybe it's related to whatever the presumable copy protection fix was? Also note they keep track of the non-fixed file in the separate "pristine" files list. I don't have that one either.
hmm I wonder if ADPCM is just meant to read blank data rather than causing a bus error in that case then (I guess XM6 doesn't generate the bus error, but does feed it garbage?)
It's using link-chain mode so it ends up bouncing around reading semi-random locations in ram.
Originally Posted by kmg
The possible offending sound effect is at 10:45ish. Looks like it's the screech of the fiery griffins.
given the 'fixed' image, I guess there is either some bug in the game here (or the image we have is from the same source as the non-fixed one listed?)
the question is does it crash on real hardware without the fix, is it protection, is the non-fixed one actually a bad / corrupt disk that's been dumped by multiple people...
I tried the NeoKobe image and that crashed in the same way, but for all I know they could have been converted from the same source too.
Also the magic selection does work on stage 2, but always defaults back to showing 'attitude' even when you have a different powerup selected (you can tell if you have argentina selected because you're slower but more powerful) that seems odd and doesn't match videos I can see?
given the 'fixed' image, I guess there is either some bug in the game here (or the image we have is from the same source as the non-fixed one listed?)
the question is does it crash on real hardware without the fix, is it protection, is the non-fixed one actually a bad / corrupt disk that's been dumped by multiple people...
What AJR posted in the shoutbox suggests that the dmac is supposed to receive the bus error and end the transfer and the cpu bus error input is gated off.
The game plays the sound then ignores the bus error when the dma goes off the rails. It's possible the developers made this mistake but didn't notice becuase the bus error ends the erroneous transfer.
Originally Posted by Haze
Also the magic selection does work on stage 2, but always defaults back to showing 'attitude' even when you have a different powerup selected (you can tell if you have argentina selected because you're slower but more powerful) that seems odd and doesn't match videos I can see?
Pressing space selects the magic. I misread this, selecting the weapon works on stage 3 for all except argentina which, as you noted, always shows attitude. The nicovideo also shows that happen at 7:30.
I misread this, selecting the weapon works on stage 3 for all except argentina which, as you noted, always shows attitude. The nicovideo also shows that happen at 7:30.
Ah, what a strange bug to have in the game, but yeah you're right, I saw it had changed to some of the other ones on a later level, but didn't notice it can never change to argentina even when you're using it.
I'm not even sure how you manage to program something that badly to be honest, it's the type of case where I'd start to suspect protection, but I don't think there's any indication these disks were protected?
For the sound, I wonder what the odds are on it trying to play valid, but wrong addresses? or is it hardcoded to an address that will always 'fail' and stop the dma?
For the sound, I wonder what the odds are on it trying to play valid, but wrong addresses? or is it hardcoded to an address that will always 'fail' and stop the dma?
In the nicovideo video on stage 3 when the birds are shot sometimes they scream and sometimes they don't. This is the behavior I see with the bus errors working. When the bus errors are off like XM6 sometimes they scream and sometimes the audio freaks out for ~10sec. I guess to to be sure if the dump is bad we'd need to know whether the video is using original disks or not.
I should have some nice video / stability fixes to submit for it too if I get my act together, they've been sitting here for a few months now, based on hardware research done a couple of years back (before the guy doing the research gave up because his unit broke, and he decided they were too fragile to risk another, even a donated one, due to the cost)
Can't that unit be revived? I don't see why risking a donated unit would be a problem though
Yeah this stuff is getting insanely expensive these days, I bought Formosa Duel maybe 2 or 3 years back for like €200 iirc today it would be way more expensive than that (if we can even find one for sale that is). Rebel Star is still undumped and the only hope to get it preserved is to hopefully find a collector willing to get it dumped it.
Either way, you should definitely submit those fixes I know the driver still has quite some issues, but I definitely wasn't expecting to see sound working out of the blue like that.
Can't that unit be revived? I don't see why risking a donated unit would be a problem though
best he could tell one of the customs blew, so no
and yes, he was finding people wanting $1000 for a system / game, even the more common ones, and that was 2 years ago.
the strange thing is the tests he did manage to do confirmed MAME's sprite size behavior, which the Speedy D pre-title attract demo disagrees with. I do wonder if there might be some bad bits in ROM.
Currently waiting to hopefully make some other improvements before submitting a pull request, but DMA-driven samples are now working, albeit in a hacky way. This fixes voice samples and certain sound effects in both Sango Fighter and Monopoly, possibly others as well:
Some additional 680x0 FPU fixes allow us to load and view wireframes in Strata StudioPro, a popular early 3D modeling program for the Mac. (Strata was used to render the graphics in Myst).
Here's a mildly amusing case of a NES bootleg. As you may recall the original Japanese Super Mario Bros 2 was only released in Japan on the Famicom Disk System. It was, however, heavily bootlegged on cartridge and on multicarts. One such bootleg can be seen running on hardware here: SMB2 (LE10). You'll observe something strange right away: the status bar at the top scrolls with the game! Additionally if you make it to the end of the video you'll see the game apparently freeze on a black screen.
Now, this title has run in various emulators for years (in MAME sadly it's always been just a grey screen) and none of them AFAIK exhibit the real hardware bugs; the status bar stays nicely fixed, and players talented enough to make it to World 4-4 are pleasantly greeted by World 5-1 after finding out their princess is in another castle. Why? Because, not knowing how the cart actually behaves, clever folks deduced that the number of CPU cycles between VBLANK and the end of the status bar was about 5750. At least that got the game running smoothly so all was good.
Your humble narrator comes into the story at this point. In an attempt to get this game running in MAME I *also* mucked around with values around 5750 and had it running smoothly. I almost submitted a patch with a nice formula: PPU cycles * (# of lines after VBLANK + status bar height) per 3 CPU cycles etc etc. It occurred to me though, all the other bootlegs of this game have 12-bit IRQ counters. It further occurred to me that bootleggers like to borrow the work of other bootleggers. It further further occurred to me that bootleggers don't typically take pride in polishing up their handiwork and may not even had somebody around who was good enough at this tough little game to play test to the end of 4-4, even with warps!
It may not be the final word on this bootleg, maybe krzysiobal over at NesDev will give us a nice schematic someday soon, but in the meantime—with any luck and the blessing of the MAME devs—enjoy a nice SMB2 bootleg, 12-bit IRQ counter, broken status bar, and crashing at the end of 4-4 like the bootleggers...intended?
Just submitted a couple of N64 fixes via pull request.
8bpp mode for framebuffers was completely nonexistent. After some back-and-forth with some N64 test programs courtesy of krom and my 64drive, it matches a real N64's output almost exactly:
There's some difference in gamma, but beyond that, it seems to work. Bit interesting in that the VI still scans the framebuffer out as 16bpp 5:5:5:1 pixels, but the neighboring 8-bit values that exist in the framebuffer effectively get paired together. I suspect if the test drew fill-rects with an odd number of pixels rather than even, we'd see a fringe of "wrong" colors on one or the other side of each column.
It also turns out that the "Magic Matrix" used for some dither operations was transposed along its axis. Fixing that fixes the dither patterns used in krom's AlphaCompare test:
Support for SPI SD cards was recently added by R. Belmont and used for an Apple II SD card device. The "BennVenn SD Loader" for the VZ-300/VZ-200 appreciates it:
That's great! I was hoping that implementation would work for other hosts as well, but I'm really happy that it worked without any changes to the SDCard device.
Ok. I'll hook up CMD16 anyway, since it'll then make us SD 2.0 compliant (A2SD prefers SDHC which has a fixed 512 byte block size, but can fall back to plain SD 2.0 and even the ancient MMC standard).
"Well if it ain't Skinny Mule!" The novelty/party/drinking game Super Russian Roulette for NES is coming soon to a MAME release near you! Even if you don't have a zapper and friends to play with it's worth a gander and a listen—8 megabytes of glorious 7-bit audio, much of it the amusing recorded speech of Cowboy Rob:
That's great! I was hoping that implementation would work for other hosts as well, but I'm really happy that it worked without any changes to the SDCard device.
I'm also looking at some devices that can use it, but need CMD10 implementing. The device is using SEND_CID to check the CRC to determine whether the card has been changed.
BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
I did some research on that board a while back. It's an Insight Enterprises EQ-4, from about 1983-1984. Apparently it was released, as an Argentinean wrote into Byte magazine in August 1985 asking for "[a]n Insight Enterprises EQ-4 single-board computer user to solve a problem."
I'm also looking at some devices that can use it, but need CMD10 implementing. The device is using SEND_CID to check the CRC to determine whether the card has been changed.
I can do a blind implementation from the spec, but more info helps of course. Is this an open-source thing where I can see the firmware code to make sure I'm giving it what it expects?
I'm also looking at some devices that can use it, but need CMD10 implementing. The device is using SEND_CID to check the CRC to determine whether the card has been changed.
I can do a blind implementation from the spec, but more info helps of course. Is this an open-source thing where I can see the firmware code to make sure I'm giving it what it expects?
Thanks Pernod. That code isn't quite doing what they seem to think. CMD10 returns a CRC7 at the end, not a CRC16, so they're actually going by the CRC in 1 byte and the month and low 4 bits of the year the card was manufactured. (The CRC7 includes the manufacturing date, so it's a little redundant, but I can't imagine people are swapping cards that much).
I'll probably use the file date on the image file as the manufacture date and calculate the correct CRC7.
...And I've now discovered that I misunderstood what the SD Association specs were trying to say in my previous post. CMD10's response is handled as a data transfer, like CMD17, so there is a CRC16 at the end.
The latest committed version of spi_sdcard should have an MMFS-compliant CMD10 response.
NES roundup—because it's not all multicarts! (Ok, it's mostly multicarts.)
With a code freeze on the horizon I thought I'd share a small selection of things from the past month. Probably of most interest to people would be a couple small bug fixes for Japanese Konami games. One improves the IRQ emulation for a number of games, so you'll not be seeing shaky things like this or this anymore. Things aren't perfect however; there are still the occasional 1-line glitches here and there.
For the diehard collectors of schlock a bunch of unlicensed and pirate fighting games have coincidentally come together this month as well. We have the polished yet poorly playing Street Heroes by Sachen, the reasonably-okay-by-8-bit-NES-fighting-game-standards World Hero, an alright attempt at Samurai Spirits (8 character version) by Rex Soft, the hilariously bad, but must-play Kart Fighter starring big, goofy, poorly-drawn Mario characters, and finally the absurdly bad AV Bishoujo Senshi Girl Fighting—for all your *ahem* AV needs.
These last two games are by everybody's favorite masters of schlock, Hummer Team, and so it's probably worth mentioning that the original Somari cartridge is also now playable in MAME along with those fighting games. Again coincidentally, work on some multicart stuff led to the addition of yet another Hummer game which I'll leave as my parting gifts: intro 1 and intro 2.
the hilariously bad, but must-play Kart Fighter starring big, goofy, poorly-drawn Mario characters
The funny thing is, this game is almost like a precursor to Super Smash Bros. It showed that there was a market for a fighting game featuring Mario characters, it had Kinopio (or Toad) depicted as a bare-knuckle brawler long before that became a Mii costume for purchase, and it introduces Yoshi’s tail attack that’s become his trademark smash.
Kmg. Thanks for all your hard work on these mappers. I enjoyed trying out some of the multigames this past weekend and see the huge improvements you’ve made.
Just a question (no request to fix): There are games, such as Star Force, that have scrolling issues. In Star Force it appears that the screen is drawing the bottom 8 lines at the top of the screen. The whole playfield seems to be shifted downwards about 8 lines. This happened in the multicart as well as in the original cart. Just curious what would cause this and if it’s mapping related?
that's just how a lot of NES games look, the tilemap is the same size as the screen, so if you scroll vertically you're likely to get glitches at the edges.
Yeah, the NES is 1982 technology, it wasn't really designed to scroll the way later hardware was. On TVs at the time the overscan hid most of the shenanigans, but on emulation you see it all.
No, because what amount of overscan works varies from game to game. What hides glitches on one game may hide important gameplay information on another. Why? No idea.
So maybe a secondary screen layout that someone can turn on to reduce the window by 16 pixels? I agree that the default should be full screen with overscan.
Here is an official background planning sheet. Note the + marks on the grid. So the tile-safe distance for big N was the even more conservative 24 pixels at the top and bottom.
You can simulate TV overscan by going to the Tab menu in MAME, then Slider Controls, and adjusting the Screen Horiz Stretch and Screen Vert Stretch settings.
You can simulate TV overscan by going to the Tab menu in MAME, then Slider Controls, and adjusting the Screen Horiz Stretch and Screen Vert Stretch settings.
Some additional 680x0 FPU fixes allow us to load and view wireframes in Strata StudioPro, a popular early 3D modeling program for the Mac. (Strata was used to render the graphics in Myst).
Incredible memories . Will be other 3D programs added too? i.e. Electric Image or Sculpt? AFAIK many 3D programs where dongle-protected, what are the options for such cases? I think i still have at least one dongle for Electric Image. If it is needed, i would donate that, would be awesome to see that 3D program in MAME. At that time, it was the fastest Phong-Renderer of the world and could eat millions of polygons easily.
A minor milestone: I believe Minna no Taabou no Nakayoshi Daisakusen was the last officially licensed standard NES/Famicom cartridge to not make it past a grey screen in MAME. Now, there are plenty of licensed games that still don't work or have major issues, but they at least put something on screen other than grey. Well, here you have it, a cute little tile matching/maze game aimed at a younger crowd. Silly that reliance on uninitialized RAM should have kept it from running in MAME all these years. [img]https://imgur.com/A7se4h6[/img] [img]https://imgur.com/fkIeYxc[/img]
Rob Justice sent me support for a card called the "Grafex-32", which was originally a project published in Radio-Electronics magazine in the early 1980s. It gave the Apple II the then-popular NEC uPD7220 graphics processor and dedicated video RAM so you could do fast graphics. Rob has actually constructed the card for real as well, but as often happens with some of the more obscure cards, the original software for it can't be found. So Rob wrote his own software to exercise the card, and it works 100% on the real hardware. In MAME there's a bit of an issue as-is: our uPD7220 emulation has a hack to make some PC-98 games work correctly which causes issues with the Compis machines and this card. Commenting out the hack got me these working screenshots.
I started writing code for SNES joypad emulation within NES. As the real SNES pad is a slight extension of the NES one, it could have been done with a few lines of code extending the existing joypad. But with a tiny bit more elbow work setting up the connection I was able to just reuse the existing SNES joypad device by emulating an adapter that connects the relevant pins—just like a real adapter. And now the real payoff: I don't have to write SNES mouse emulation! God, I love MAME.
Edit: Nice. It turns out the NesDev competition compilation carts have mouse games/demos if anybody wants to try it out. In the NES software list set a53vol1 has a game called Thwaite (like Missile Command), and a53vol2 has the game Sliding Blaster and a Theremin demo (for annoying your coworkers).
An external contributor who contacted me and is waiting for Richard to approve him to join us here has been working with the unixpc.cpp driver, and he's now gotten it this far:
It's missing some kind of synchronization between the Z80DMA and the SCN2674, so the video looks a bit weird. Hard to figure out what exaclty it needs without schematics or being able to trace some lines.
Bonus screenshot:
RS232 works, most keyboard keys work, so it's kind of usable.
Quizard 1, 2, 3 and 4 now fully working, although you have to wait about 25 seconds after starting up the machine before clicking 'Play' (the external MCU is supposed to force that input, but it's not wired up):
Additionally, Mega Maze no longer hangs when going in-game, and Santa Claus's Mice no longer issues a "disc dirty" error when pausing mid-story. Probably more things fixed associated with the CDIC, but I don't know about them.
Next stop is to figure out what's up with the MCD212 chipset.
I'm taking a look at the Philips VideoWriter stuff that was submitted: I've had to create a preliminary NCR7250 device for the video, which needs more work as I see more features being used.
BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
I've managed to obtain copies of original LSI-M3 system diskettes. All were 8" single sided format, but still worked in my restored M3, which has 8" double sided drives. I discovered the boot sector of these disks contains a single flag byte that informs the bootloader process (and CP/M OS) what disks the system should have. So I now have the same disks in 8" double sided format, and with partial support for either a 5 MB or a 10 MB "Winchester" drive. I say partial support, because the IDE hard disk driver code in my monitor prom doesn't work correctly with the original LSI version of CP/M. However, I am re-writing the hard disk driver code to emulate a Xebec S1410 disc controller as would have been fitted to a hard disk drive model M3.