Home Page Forums MAME MAME VME boards

All cards so far has used the address space of the CPU board with no VME bus signaling involved and I am trying to create a bus address space to accommodate many to many relations, eg if you have two CPU cards that wants a single I/O board or in some rare cases a single CPU board do single write to multiple boards etc.

Let's review the best approach, I don't think there is much to break yet but we'll see.

Yeah, I don’t have bus arbitration yet but I have /DTACK and a couple other signals. The ‘320 and ‘120 are both capable of bus mastering under my vme.cpp. A card can assert a signal line which gets distributed to all attached cards on the backplane as a callback for them to override (or ignore if they don’t care).

The way I have it set up is using install_device to insert handlers into the VME A24 address space, then having a memory handler on each card to perform read/write operations to A24 when they call out to VME. I don’t have all the signal logic going yet for that but it works well enough to let 120bug interact with the 320 via its standard monitor commands and for the 120 to detect the 050 during boot. Being able to overlay memory regions and handlers is very helpful.

The 120 does fail its self test and I’m not sure why, it seems to be something with the 68000 core I haven’t worked out. I added a two-byte ROM hack to the driver to get it to pass where it locks up so I can at least get to a console.

Cool, I think the challenge with DTACK is how to suspend the CPU board until you'll get the DTACK in a good way, especially as the M68000 core didn't have DTACK support last time I checked at least, so emulate that by eating cycles. Also it is a good thing to put common stuff in the VME device and just parameterize it. Often DTACK has different timing for each device on a board so the DTACK value should really be property on the memory map but I am unsure if any VME boards had split DTACK values or just had one for its entire VME window.


As long as it is possible to use either the maincpu address map or the VME bus device address map through the use_owner_spaces() I am good with that as it ensures simpler driver code for the SBC case, without a "physical" VME chassi, or just one slot, mainly supplying DC power and GND, I have done something similar but if you have wrapped your head around a good way to do it I can adapt.


Sounds useful, will read up on that.


Many MAME systems do have problems with self tests and it can be for various reasons but timing is a difficult one when not having proper DTACK support in the CPU core. ROM hacks are not ok to submit I believe unless you do it live, that is having a proper ROM and patch it during startup, many systems seems to do that.

Right, the way I have it set up is that the 120 will halt waiting for DTACK until it either times out (the board will pulse BERR if the bus cycle isn't complete after 220ns) or it's asserted on the bus. There's a bunch of logic on the 120 to figure out which DTACK we're waiting for but at the moment it only cares about the one from the bus. I have the halt set up using a timer/spin_until_trigger combo.


Right, it patches live during startup to bypass one specific test (replacing a branch with a NOP like all good hacks).

I figured out that emulating the ‘320 properly has to be so low level that the whole emulator is slowed down unacceptably, so I’m working on an HLE version based on the hardware instead. I can’t seem to figure out the new floppy subsystem though. What device should I look at for a good example of reading an MFM image? I’ve been copying from one of the other Motorola controller drivers but can’t work out how the PLL stuff works.

Specifically, here's the live_run function that I don't know how to set up. It looks like all the data is shifted by one bit, (instead of $FF followed by six bytes of $00 as a sync gap in the sector, I get $F8 $07 $00 $00 $00 $00 $00...) so I'm not synced properly? How do I adjust that to the image's clock?

Maybe emulate it properly anyway, and then profile to see if there's perf wins you can pick up? In the long run you're always ahead to emulate things correctly up front.

I'll need to know how to sync the PLL either way!

When I started, I didn't realize the board did things like stretch the clock phases to match the processor speed with the floppy data rate. I reverse-engineered parts of the firmware and made the 8X305 core subcycle-accurate to get it this far, but this is far, far above my experience level. I'm a programmer, not an analog hardware guru.

I don't want to leave it as-is but I haven't been able to make substantial progress on emulating the PLL and the other microcoded subsystem clocked by it that actually interact with the floppy drive.

This has happened to me many times too, it has been either that emulation is not as far advanced in MAME yet or simply that it has been too slow for mainstream PC:s. I used to get very frustrated over this but has came to conclusion it is much better to document what has been done and either go HLE for that part or wait for MAME and/or PC:s to catch up.

Storage media has always been problematic and no one ever loved magnetic media so I think the general conclusion is that it is ok to convert to a generic formats using external tools and load it on a (slightly) higher level to avoid the PLL level, if it is possible. Eventually someone rewrites/improves MAME:s scheduler or whatever is causing the problem and it will be possible to do the LLE.

You can absolutely do cycle-accurate full system emulation in MAME now, but you need to start from a cycle-by-cycle capable CPU core (one that can run only one cycle of an instruction rather than always running at least 1 instruction).