Anything to do with MK5-specific stuff (notably the "DRAM Emulator" in machine/archimds.cpp) should probably be moved to the aristmk5 driver (if possible) rather than in the AA-specific section. Going by the source comments the DRAM Emulator uses the U36 GAL from the (NSW aka "World" version) MK5 board. USA platform doesn't use it, instead it has an additional 25 MHz XTAL just to be different. Would be nice if someone could fix the interlace(?) bug to make the MK5 games run at the right speed instead of skipping every second frame.

Linux/m68k loads from floppy and starts doing its thing, but I have no idea how timer interrupt should be working, so it's stuck:

I'm in need of some assistance with a device I'm working on ...

It's the Hybrid Music 5000 Synthesiser, schematic at https://www.retro-kit.co.uk/user/cu...chnologyHTMusicSynthesiser-Schematic.pdf

My initial implementation was a port from another emulator, and worked well, and in stereo. I'm now updating it to make use of the DAC76 device (Am6070 on schematic), but the current DAC76 only supports a single output channel whereas the Music 5000 uses both decode and encode outputs switched by the EnD input line.

So the DAC76 device requires another input line ed_w, no problem. I'm not sure how sound_stream_update should be changed to output to both channels though, depending on state of the EnD line. My limited knowledge of the sound system suggests the device can only output to either decode or encode at any time, but wouldn't sound_stream_update need to update both channels? Anyone suggest how this should be implemented?

I'm pretty sure they are not.

I've been the (unofficial) maintainer for them since SDLMame has been merged into the main tree, but I've given up at some point because it was too much a waste of time to dig into the code each time to look for changes to switches.

I've considered using some tool to build them from docs source files, but this looks no trivial task as well.

Syncing them one-off would take time, again wasted as I guess the proper way to keep them in sync would be to consider them part of the documentation itself, i.e. creating kind of a "docs team" working side by side with the developers to update the documentation _before_ each new release and structuring docs source files in a way that turns them into useful man sources too (my 2-cents).

Sure, I'd love to see a redump of:

prom1.e1
prom3.k5
prom2.8r

There's no need for a thread on those machines being broken, it's known and intentional (we're moving towards true ADB emulation where we run the microcontroller in the keyboard and mouse, much like what Vas did for the original Macs' keyboards here). You can continue to use an earlier version if you need to.

Added netlist audio implementation to Fire One by Ryan Holtz

In the past days:
Added mw8080bw Gun Fight netlist sound by Colin Douglas Howell
Added Star Cruiser netlist sound by Ryan Holtz apart from "using HLE noise due to abusing a 2N4124 in breakdown as a noise source"



A question to mamedevs: can other games in Dice Emulator be moved to the MAME framework? If so, is it very difficult to accomplish? Will they be too slow? Thank you..

The Busicom 141-PF is a major highlight for my not-all-that-inner nerd, but the netlist audio is probably the most obvious and awesome change.

Just for fun, I thought I'd play with svgedit and inkscape to see if I could make something that looks like the control panel.

Given that the BACTA standard did surprisingly well in terms of UK takeup, it wouldn't surprise me to see something similar elsewhere, but my knowledge of such things is very limited. I know of some of the setup in The Netherlands and Germany, purely because a lot of it used the UK techs under license. They never really weaned of serial communications though, so I would guess that it would be vaguely close.

R. Belmont: Very sure it's either "present" or "read allow" (more towards the latter if crazyc is right), because it's entirely consistent with how the system works. If this was an "accessed" bit, there would still have to be another present/read allow bit somewhere for the MMU to really make sense.

Just Desserts/crazyc: Possible, but I didn't actually spot any page getting (intentionally) written when the bit wasn't set, at least once the MMU was enabled. Very possible that I missed something. If so, "read allow" seems to be the simplest interpretation (I assume that even then the pages were not intentionally read before the bit was set.)

Remember this, from back at the end of May? Turns out the problem was that I had missed a diode in the internal netlist for the MC3340. Or rather, noted it and deliberately omitted it, thinking that it didn't make any difference in the sound. Well, that turned out to be very wrong. The engine sound is now much more "growly", sounding quite close to real machines.

Motorola's MC3340 chip schematics, while certainly helpful (without them full 280-ZZZAP sound would be nearly impossible to figure out) have also been sources of confusion. Late ones (1990s) have resistor values, early ones (1970s) don't. Late ones miss an internal connection that early ones include: a crossover gets a dot in the early ones and no dot in the late ones. And late ones have one internal diode while early ones have three. It turns out those two extra diodes matter. (It would have been less confusing if Motorola had left all diodes off the late schematics—at least you could say, "oh, they just left out their diodes". Leaving out some diodes and not others makes you think the omitted diodes are supposed to be irrelevant or something.)

Anyway, the fix has been made and incorporated in master.

We now have Apple IIe RGB card support, which adds a handful of interesting video enhancements that had surprising amounts of software support. See more here: https://rbelmont.mameworld.info/?p=1389

I'm working on the systems in 197? 198? I have found some manuals for At&t 3B2/310, 3B2/400, 3B2/600 dated 1990, a separate Manual for 3B2/400 dated 1985. A possibility I might do 200? will look for flyers for these systems, if possible.

Oh ok. I think a book would be better than this. Get a new one every year, lol

Bowling and hedge maze simulators on rt1715w -- these might be original, but I didn't look very hard in the CP/M game archives:

https://youtu.be/fT1aDc82-kU

Nice!

The mask rom in your picture is a 613128 instead of the 613256 on my board, which makes sense.

Can the driver be made to accept both configurations?

Thanks a lot!

hi, i just created a pull request that adds audio input support. seems to work well with coreaudio, but other platforms still need work.
let me know if you are on mac and need it right away.

cool work with the fairlight btw!

Well it writes to the MIDI register which we don't handle at all currently. It might wait for an interrupt from it.

Just submitted a PR for my Gun Fight improvements. Took me bloody long enough.

In retrospect, I spent too much time and effort going down the avenue described above. I've pretty much punted the issue, other than explaining it in source comments. What's there already works pretty well. The issue may be worth revisiting later if more detailed info becomes available on Gun Fight's noise generator voltage and how its power amplifiers, speakers, and cabinet behave, together with an infrastructure better able to use such info. But for now, this is good enough.

couriersud's points are valid, but I really didn't intend to get into details of modeling speaker, cabinet, and microphone acoustics. Mostly I was looking for a sanity check on my thoughts.

Also, one needs to be careful modeling circuits in LTspice. Turns out my noise generation was a bit off: it was using a uniform distribution instead of a normal one.