AGEMAME HQ

Have fun, I’ll look into the PIA situation when I get time.

Owing to a ridiculous number of other projects suddenly presenting themselves, I’ll be lucky to devote any time to anything for a while. Expect me to just keep this up to date, and little else for the intervening period.

…without doing anything fun.

The 6840 emulator seems to work with everything I’ve thrown at it, but when there is a need for an extra timer to run the external clock source, things tend to slow down quite a bit. Still, better that than it not actually working, and I may be able to squeeze a little more performance out if I really had to.

To try to make my life easier later, I’ve put together a rather quick and dirty skeleton structure for triac banks (connectors for external circuitry or solenoids), so each driver can now drive 32 (4×8 banks). This is just so that different games can configure them to their own ends (payslides or hoppers), rather than having to have different PIA handlers. My next trick will be to try to probe why the serial link is still stuck in a loop, and to attempt to add the discrete sound circuit (help!). Admittedly this will be yet another CPU hit, but seeing as it only triggers when something’s wrong, it shouldn’t be all that bad. If inspiration strikes me, than the lamping will be fixed up too, but I do think that I have the inputs sorted.

After a few hours of choice rewriting, I now have a timer core that works accurately to ~0.1% of the real chip (even if it’s a little more CPU intensive than before).

The new version currently has no space for the external clock frequencies that used to be included in the interface, largely because that’s not how the chip worked - there was an enable clock that had to be connected, but external lines were meant to just be fed by whatever was necessary. If you want a consistant external clock source now, you have to set a timer in the driver to call the external clock function, which will then be processed in the same manner as the real deal. (In theory, the real chip should use the enable clock to clock in this change, but since the consequence of this is offsetting the output by three enable clocks each time, then compensating internally, you’ll forgive me if I don’t bother emulating that just yet, if at all*).

The upshot of all this is that the unit test now complains about PIA IC3, which is exactly the same problem as the only other emulator of this hardware I know (the apparently discontinued MFME). At least, I think that’s the problem, the alpha emulation in that throws a fit when adding ‘.’ characters to certain spaces, so I get a weird symbol instead.

*If someone can find an application where this behaviour matters and produces a discernible effect, I’ll do it on presentation of proof. Since nothing that uses a 6840 in MAME does, I think I’m fairly safe.

Hopefully this should all still work, I’ve not added any of my 6840 changes just yet, but put a testing infrastructure in place.

All the 6821 changes were actually internal, so I didn’t have to do anything at all.

Well, that’s certainly given me an excuse to do some proper cleanup.

The recent trifecta of 6821,6845,and 74123 changes has allowed far better documentation in a large number of AGEMAME’s drivers, and so I’m going to take the time out to rig them up properly, rather than my usual patch and test system.

The 6821 probably won’t require a lot of work, but hooking up the 6845 and 74123 ‘properly’ might.

Just screwing with the permalinks now, and defying anybody to work that one out.

But enough of waging war with the readers, on with the main feature.

After yet more timer tinkering, I’m convinced that what I have is right, but it hangs MAME. My belief is that the generating of interrupts is causing some sort of internal logjam, and MAME isn’t coping with the volume of IRQ requests. I have witnessed this before with this driver, usually when looking into the PIAs setting IRQs at strange moments, but we’ll see the culprit soon enough.

After remaking the driver, I found that the result was accurate, but slowed the system down to a crawl, as it was dealing with multiple timers being reset on the MHz timeframe.

As a consequence, I’m unsure as to how to proceed and still make this behave sensibly - I feel my initial approach would have worked, but it’s how to get out the bottlenecks.

Expect more once I get my head around it, or persuade someone else to do it.

Or time hole, if you prefer.

These MPU4 test ROMs have highlighted a major weakness in how the 6840ptm driver operates.

Rather than keeping a strict counter and subtracting values on every cycle, the driver converts the counter into an output frequency, and uses that for timing. Fine, unless you need to use the external clock pins. There’s currently code in place that makes the driver work by pausing the timer, and then just letting it run while the pin is activated. Up until now, that’s been fine, but is not the way it should behave.

Over the next few cycles, I’m going to look into ways of making this behaviour more accurate, while preserving as much of the existing interface as I can. You may notice problems developing in AGEMAME, as I’ll be running the new code in u builds until ready to sign off on it and submit it to MAME. MAME will retain the original version until completion.

It’s been painful trying to keep the IMPACT stuff secret, but here it is, in all its TMS chip abusing glory.

Support for the MPU4 unit test ROMs has been formalised, but they won’t work until the 6840 timer code is rebuilt.

And I mean rebuilt, the external clock handling is a joke at the moment, compared with what it needs to be.