Megabus dimensions

[exxos]

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

They are in my basket to order more. Just haven't pulled the trigger yet. Will try and do it later.

[Badwolf]

They are in my basket to order more. Just haven't pulled the trigger yet. Will try and do it later.

Cool. Ta.

BW

[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.

Ah, rats. I completely forgot there is a fully functional on board processor which will honour those bus requests even if the external processor has its BR tied high.

That will definitely make things worse!

Time to break out the custom no-DMA emutos again, but that will only boot to CLI as will have to fit on a cartridge until the TOS boards are back.

BW

[Badwolf]

Time to break out the custom no-DMA emutos again.

I didn't have time to do much last night, but my no-DMA Emutos cartridge ran happily for an hour and a half last night.

It was doing absolutely nothing, of course. No mass storage and CLI only, but AFAIK the cursor flash is interrupt based.

So DMA looking the more likely now. Which does make sense really.

BW

[Badwolf]

I don't think it's the whole story, but I have found one glaring error. Not sure how to fix it just yet.

I've been fortunate in my mods so far that I've not tried to have two base 68000s going at the same time so hadn't thought about the synchronous bus system much. I should have done!

The E clock is only the second output pin that isn't quiescent during bus relinquishment (the other being BG, for obvious reasons). Putting a second 68000 in as is own bus master was leading to contention on the E line. Oops.

OK, so isolate the external CPU's E line, no problem. But now we're left with an asynchronous synchronous bus. This will obviously be a bit hit and miss and sure enough mouse and keyboard inputs are the bits that really fall by the wayside when DSTB1 kicks up to 16MHz.

I was thinking to isolate VPA from the external CPU as well and just have some kind of timing-based DTACK synthesised when the motherboard generates VPA, but VPA being visible to the CPU is required to indicate autovectored interrupts (VBL and HBL on the ST).

So I think my logic has to have its smarts upgraded to detect and facilitate autovectored interrupt cycles plus also do something about the newly asynchronous synchronous cycles.

So one step forward, two back. But a plan emerges.

BW


PS. I think the combined delay of the clock and the bus arb when DSTB1 is in the slot was too much and inverting the clock pushed things into the next cycle which is why I was seeing better results with an inverted clock. It may be version two needs its own oscillator and a set of jumpers to choose the delay to the clock to allow the user to fine-tune their skew. We'll see.

[exxos]

Ah I didn't even notice you had 2 CPU plugged in at once. I can confirm that doesn't work

Not sure I follow what you are exactly trying to do in the first place?

[Badwolf]

Not sure I follow what you are exactly trying to do in the first place?

Turn the Megabus into an expansion slot. "Megabusmaster".

It works with the 030 as it doesn't have an 'E' line. The 030 in the Falcon can still talk to the ACIAs, so I think isolating the synchronous bus, synthesising DTACK at the appropriate time and treating the evolution as async should work, but I would need to detect autovectored interrupt acknowledge cycles and pipe in VPA instead of DTACK for those.

Which means more lines routed to the CPLD than I have done. I'm contemplating using a GAL for some basic logic as I built in some prototype footprints for them and they'll be easier to solder than an additional 7-12 lines to the CPLD pins!

BW

[exxos]

So are you requesting the bus from the old CPU to new one like the dfb1 type stuff does?

[Badwolf]

So are you requesting the bus from the old CPU to new one like the dfb1 type stuff does?

Correctamundo.

Any bus request from the board slams the brakes on the external CPU and lets the internal one dish out arbitration as usual, all the time holding the internal one in HALT so it doesn't start to try executing itself. When whatever bus master has done its job and BGACK goes high, my board steps back in, requests the bus and lets the external CPU loose.

It's why we don't quite get to 100% on Gembench (there's a few cycles lost every time the DMA chip does its little tick), but the idea was to be able to fit a DFB1 or PiStorm etc, without desoldering the main CPU.

I think this should still be perfectly possible, but my inexperience with the synchronous bus mode of the 68k has caught me out in my beta one design as I'm not sniffing enough pins nor isolating enough others.

BW

[Badwolf]

Some progress!

With a block on synchronous 6800 cycles and a synthesised DTACK instead (plus an override for autovectored interrupt acknowledge cycles) I'm able to boot up with DSTB1 in the slot and use the mouse and keyboard.

I'm not 100% sure the mouse is fully reliable yet, but it needs some testing.

IMG_0309.jpeg (844.89 KiB) Viewed 6 times

(CPLD dev board doing the VPA/DTACK work)

It also works at 16MHz.

IMG_0310.jpeg (206.9 KiB) Viewed 6 times

Although the blitter doesn't seem play nicely with AltRAM at the moment (soft-running EmuTOS to get AltRAM, I get artefacts on the screen with the blitter enabled), my suspicion is that's actually because I'm using an experimental firmware on DSTB1 and have broken the external AltRAM timing.

Anyway, sufficient progress for me to be happy with the evening's work.

Cheers,

BW


EDIT: using the inverted clock stabilises the blitter access too.

Here's a like-for-like GEMBench:

IMG_0314.jpeg (223.79 KiB) Viewed 4 times

Edit 2: of course the big one is frontbench goes from ~850 to ~1450 frames. Happy with that.