Megabus dimensions

[Badwolf]

This is what I've come up with for prototyping what I call the 'Megabusmaster'.

It's got a small CPLD to help me figure out the logic and then a slew of uncommitted GAL footprints with breakout headers to see if I can distil whatever I come up with into cheaper and easier to source/solder GALs.

Obviously, that would only come into play if I can get bus mastery working.

Standard 6 pin power connector on the right. Two pin IPL1..2 connector on the left. These two signals will have to be somehow tapped from the onboard 68k or the little U39 next to it.

Sending off the order now. Hopefully can start work proper in a couple of weeks.

BW

Screenshot 2026-09-10 at 21.20.48.png (281.96 KiB) Viewed 132 times

!Message from: Moderator

@Badwolf, we have placed your attachments in-line so they display correctly in your post. Here's the how-to guide.

[mrbombermillzy]

Good work!

[Badwolf]

The Megbusmaster development has started in earnest.

It is a no-mods-required installation and if using the two little clips going to the onboard 68000, it is in theory, solder-free too.

IMG_0283.jpeg (279.54 KiB) Viewed 78 times

Unfortunately it's proven a bit of a pain to bring up so far.

The blitter seems *ludicrously* sensitive to anything loading the BR line. I have to both read from it (to pass it through to the external 68000 slot) and write to it when negotiating so it's declared an inout in my verilog and spends most of its time high-z.

However that's enough to stop the blitter working properly. Either freezing up on access (it'll boot to desktop and then accessing the menus locks up), or causing continuous arbitration cycles and thus seeing the blitter run in slow motion.

Setting all the CPLD lines to high-z and running the onboard CPU is still enough to cause the issue. Doing the same but disconnecting BR from the CPLD via the jumper bank there resolves it. So it's simply the connection that's enough to cause it.

So far I've tried adding another 10k pull up to the line -- no obvious effect -- and I'm thinking about trying a set up where I use two pins for BR. One to assert it (isolated via a diode) and one only to listen on it, mediated by perhaps a 1k resistor or something.

Otherwise, I'm not sure what to do? An external buffer before the CPLD? A much stronger pull up?

I'm tempted to remove the blitter and try to get everything else working first (the ACSI isn't happy yet either), but that seems just like putting it off.

Any thoughts electronisits?

BW.

[PhilC]

Have you got a different Blitter to try?

[Badwolf]

Have you got a different Blitter to try?

Ah, no.

BW

[Badwolf]

Progress!

Embarrassingly, I had soldered my pull-up to the wrong line, so that's why that wasn't working. An additional 10k pulling up BR (and removing the cheap logic analyser which does add considerable load to the lines) has allowed a plain 68k to work in the port as an external CPU.

IMG_0288.jpeg (228.01 KiB) Viewed 55 times

So phase one (demonstrate the theory) is ticked off.

Of course, because there is an additional need for arbitration at every DMA access, there is a slight performance hit to running an external CPU.

IMG_0290.jpeg (211.3 KiB) Viewed 55 times

It's marginal but clearly this isn't going to be great for running demos.

That's not really the aim of this, of course. I'd like to plug in DSTB1 or PiStorm so cycle accuracy is not really the target.

IMG_0289.jpeg (309.27 KiB) Viewed 55 times

Phase two (get it to work with DSTB1) is, unfortunately, not yet proven. I can boot to the desktop but there's a lot of memory corruption and blitter access is a reset.

But I'd say that's good news on the whole.

BW

[mrbombermillzy]

I'd say that's good news on the whole.

I would go much further and say that is amazing progress so far.

Well done!

[Badwolf]

I didn't have time for much work on this last night other than to get out the sillyscope and check a couple of obvious things.

The symptoms:-

* Vanilla 68000 in the (let's call it) 'expansion slot' working well, booting to desktop, DMA happy.
* DSTB1 8MHz in the expansion slot is unstable at desktop. Artefacting on the screen. Crashes. Jumpy mouse pointer. Quite impressive memory errors.
* DSTB1 8MHz as above but with CPLD buffered clock: similar instability.
* DSTB1 8MHz with buffered and inverted clock from the CPLD: perfect! Desktop and DMA working well. Keyboard and mouse fine. Blitter stable. WTF?
* DSTB1 buffered and inverted clock switched to 16MHz from AUTO or Desktop: crash.
* DSTB1 using system clock switched to 16MHz from AUTO or Desktop: crash.
* DSTB1 using system clock at 8MHz booting to diagnostic cart: passes all tests
* DSTB1 using system clock booting to diagnostic cart then switched to 16MHz from within the card: passes all tests!

What's going on here?

The two most obvious differences between diag cart and desktop to me are 1) interrupts and 2) DMA.

Whilst DMA is the obvious candiate (after all the whole point of this enterprise is messing around with bus arbitration) and there are continual little background pulses of DMA when the OS is running the stuttery mouse pointer does have me thinking about interrupts initially. I *think* from memory that the keyboard is polled in the diag card rather than driven by interrupts and the diag cart passes the long blit test happily.

With the scope I can't see anything wrong with the IPL lines (which are external on megabusmaster), nor FWIW, the bus arb lines and the the system clock is strong and with good duty cycle even driving DSBT1.

But I can't directly tie in interrupts to clock edges in my mind. And I'm thinking clock edges must be important as the inversion works so well yet when switching to 16MHz crashycrashy again. 16MHz mode on an inverted clock will bring an edge back into alignment with the system clock.

As a bit of a throw-away I will try changing the clock edge my bus arbitration works from (positive to negative), but I still can't take my mind off interrupts yet. What do we think? Red herring?

BW

[exxos]

Have you tried just tying BR high and see if it gets to the desktop that way? The floppy drive won't obviously work but if it gets to the desktop reliably it can be an indication..

As a side note if this is a mega machine I gave up with them because most of the problems were because 16 megahertz clock goes from the shifter at the top all the way down the board to the MMU and it was just a total nightmare.

[Badwolf]

Have you tried just tying BR high and see if it gets to the desktop that way? The floppy drive won't obviously work but if it gets to the desktop reliably it can be an indication..

Good & quick idea. No, not yet. Very little other than combination testing so far.

Ta.

As a side note if this is a mega machine I gave up with them because most of the problems were because 16 megahertz clock goes from the shifter at the top all the way down the board to the MMU and it was just a total nightmare.

Yeah I know you've written them off as shockers hence why the clock was the first thing I played with and thus found that odd inverted-is-grand result. Oh well, if it's a dead end, it's a dead end. I'll have to get the desoldering gun out on the 68k socket instead. That's what I was hoping to avoid

BTW is your Mega TOS board one of the end of life ones or will more be coming back into stock?

BW