AGEMAME HQ

Unfortunately, I will be unable to bring updates for the next few weeks, due to circumstances beyond my control.

There is one fix needed to age.mak to enable compilation.

Add the line $(DRIVERS)/galaxi.o: $(LAYOUT)/galaxi.lh

in the layout dependencies section.

So, a start to clickable elements - there are probably a few bugs still left with this (namely, if you have your mouse set up as an input device, it probably won’t work).

The replacement LAY file is at http://www.mameworld.net/agemame/files/artwork/bfmdrwho.lay

(This has been deliberately left unlinked, as copying and pasting into your browser seems to work better).

Sorry I haven’t kept up the Monday release schedule, but I’m trying to get the clickable artwork elements system operating correctly for all games that AGEMAME could conceivably use it in. Basically, this requires rewriting the LAY files, and locking down all the input information. Once a release is ready, new LAY files will be made available.

Not much this time, just a compile fix.

Well, now that I’ve got this stepper driver together, it should be a lot easier to start adding AWP technology support. Expect a lot of skeleton drivers to spring up, and existing ones to be cleaned up ASAP.

So, what is it that is so important to AGEMAME that it’s been in the works for months. Actually, it won’t seem like a lot at all, but it ought to make a lot of difference with respect to adding further drivers and such. Up until now, the stepper motor code has remained largely unchanged since the days of MAGE, largely being hard-coded to assume every reel-based system operated in exactly the same way. While it has been possible to add support for other wiring patterns, the actual optic systems used to read the positions had several major flaws. Firstly, setting them required the use of external functions which broke save state support and secondly, the code that sent the signal to the CPU had a very nasty bug in it when a tab was added to the ‘end’ of the reel.

To explain most of this in simpler terms, as the reel is basically a solid unit, there needs to be a way that the machine can somehow determine what face is showing at a given point. This is usually done by using a small photosensor, with a tab that breaks the beam - everything else relies on the precision of the motors. In the past, if that tab was placed at the end of the reel so that it would affect the start of the reel loop, all of the section after the end would have no effect.

Now, everything’s in a good, old-fashioned interface, with the reel type, the start point of the tab, the end point of the tab, and a ‘checking’ coil pattern if needed. Cleaner and simpler, just took a long time to plan out.

Better put a stable version out, as I have a big structural change planned which might break things.

For now, there’s little different to 125u6, but the whatsnew is availabke as normal.

More compulsory tagging, and a bit of Maygay code backporting.

To be honest, I really need to get some stuff into the MAME core before any of the AWP drivers will improve, so don’t expect miracles.

Added preliminary support for Maygay MV1 technology (better known as Screen Play), it needs some additions to one of the sound cores to work though.

After updating all the ROM regions, I must say that I eagerly await the next part of the MAME core to have tags permanently built into it ;)

The AGEMAME development PC has developed a fault, and one of the hard drives is currently inaccessible. While this is not expected to impact heavily on the development schedule, until I get it fixed I won’t be able to update the resources repository.

On the plus side, without the distraction of that, I can work on all the little core pieces I’ve been ignoring for too long (proper dot matrix support, anyone?).