Home Page Forums MAME MAME AT&T UNIX PC, 68010 Custom MMU

Hi all. I've been working on the driver for the AT&T UNIX PC, a 68010 based UNIX machine with a custom MMU released in 1985 made by Convergent Technologies. I've been hooked on this machine (it was the first UNIX machine I ever used back in the early 90s) so wanted to see if we can get it supported in MAME. I'm new to the MAME codebase so it's been a bit of a learning curve.

I've been spending a lot of time on this driver and made it through a number of hurdles. I'm finally at a point where the kernel is attempting to page fault and read new pages in from disk. However it looks like the current 68k code doesn't handle the case properly for a 68010.

I can trigger:
m_maincpu->set_input_line(M68K_LINE_BUSERROR, ASSERT_LINE);
which calls m68k_cause_bus_error() which does:
m68ki_init_exception()
m68ki_stack_frame_1000() // 68010 specific
m68ki_jump_vector(EXCEPTION_BUS_ERROR)

This is all fine and good. But I believe I need the DA registers saved and restored when a bus error occurs so the original instruction is run again after the page is brought into RAM.

execute_run() in m68kcpu.cpp covers this situation for m_pmmu_enabled, but not for the 68010.

Anyone able to help with the 68k code to support this 68010 with custom MMU scenario? Or is there something I'm overlooking?

Thanks so much, looking forward to making some further progress on this.

Jesse

have you looked at how this is handled in the sun2 driver?

The sun2 driver doesn't implement page faults, so this isn't an issue there currently.

For the case where you need to restart instructions from an external MMU, m68k execute_run() needs a separate flag m_has_instruction_restart which all of the MMU configurations set and which is also settable externally so it can be enabled for 68010 systems with external MMUs.

The MMU is pretty good described in this document 999-300-1891S_UNIX_PC_Reference_Manual_1986.pdf on Bitsavers. It is discrete/PAL based circuit so you could write a custom MAME MMU device that interacts with the 68010, place it under src/mame/machine/, at least one custom MMU is there, or keep it in the driver if no other driver needs it. Others might know a better place in the source tree. The firmware package at Bitsavers (http://www.bitsavers.org/pdf/att/3b1/firmware/) does not include a PAL dump itself as you might know but maybe it is not needed as the description is quite detailed.

Edstrom: that's not what the OP's asking. He has the MMU implemented but the 68010 doesn't do the instruction restart hack (which has been effective far beyond my imagining, I will say) on bus errors since it doesn't have an internal MMU.

Ahh, ok, so it is all there except that the 68000 core implementation expects an internal MMU, what about 68450/451, guess this inhibits these devices to be written too? Quite some interesting reading about 68451 on Wikipedia: https://en.wikipedia.org/wiki/Motorola_68451

Once his problem is fixed, the 68450/451 would be possible. Do you have a dump from a board that needs them?

Yes, the vme_fcscsi.cpp has a 68450 but I haven't started with the device yet and why I was interested in this

Yes, this sounds just like what is needed. And then presumably the equivalent of m_mmu_tmp_buserror_occurred from m68k execute_run() being set in m68k_cause_bus_error().

I assume that was a typo, 68450 is a dma controller.

I don't know of any 010 systems that used a 451, maybe one of the Moto VME 010 boards?.
There are a bunch of examples of Unisoft 68K ports that use 000 and 451 and handle non-recoverable instructions by trying really hard for them never to happen
I assume the Wicat with a 000 does this as well.

010 systems with variations on ram segment/page MMUs were pretty common and have common ancestors with the SUN cpu board


and there is an existing 7300 emulator here
https://www.philpem.me.uk/code/3b1emu