exxos blog - random goings on

[stephen_usher]

The CMOS part would be slightly faster to react to a rising signal as the transition voltage between 0 and 1 is lower for CMOS and hence it would trigger at a different point. Basically the CPU would see the transition to 0 later than the NMOS part and the transition to 1 earlier by a nanosecond or so.

In other words the STE's timing only just about works by accident.

[exxos]

The CMOS part would be slightly faster to react to a rising signal as the transition voltage between 0 and 1 is lower for CMOS and hence it would trigger at a different point. Basically the CPU would see the transition to 0 later than the NMOS part and the transition to 1 earlier by a nanosecond or so.

Yeah it's all a bit of a mixed bag. It's also possibly why 2.2K pullups help with DMA issues as it changes timings by about 7ns IIRC. Though that's another oddity as why would the address and databus effect busgrant timings. Another rabbithole I am not going down. Though the pullups help with stability in particular with the HC CPU with boosters as well.

In other words the STE's timing only just about works by accident.

Yeah that's pretty much it. Thats why its such a problem (as always) to do fixes which work across all machines. You can make or break a machine by putting a SGS or MOT CPU in the thing, or changing the ROMs. That's how bad the whole thing is. As I have always said for years, it is a miracle these things ever worked at all.

I suspect this is one of the problems I had back in the early STE booster days where only particular CPU's or GAL's would work. With fake GALs in the mix with "Random" timings to start with. Makes diagnostic very problematic. Its why I started moving away from GALs to ATF series chips as at least I had a similar starting point for timings. Getting things working across all machines I think it is going to be pretty much impossible. Things which fix one machine can then inherently break another machine.

I really did not want to go down another DMA rabbithole. I'm only doing these experiments to give people a possible solution if they have problems only when using the STE booster. Ultimately I think it can just be a plugin board because all the later boosters had the GALs in sockets. So a small plugin PCB should help solve issues should they arise again somewhere in the future. Though again unfortunately this is going to soak up a lot of my time which I don't have

[stephen_usher]

Maybe adding a pull-up to the bus grant line could help (or break things further if it's the transition down to low which is the problem) then.

[exxos]

Maybe adding a pull-up to the bus grant line could help (or break things further if it's the transition down to low which is the problem) then.

I've tried a million related things already. It's why I gave up in the end and started on fixing the timings instead.

[exxos]

A bit neater version.

This one picks up the 8MHz after the first buffer as that is what will be on the GAL. So by the time it goes though more buffers and the GAL adding around 10ns delays, as if by magic, the 8MHz clock is still perfectly in sync

IMG_1659.JPG (111.28 KiB) Viewed 264 times

IMG_1658.JPG (69.18 KiB) Viewed 264 times

Rather problematical to find parts in stock and correct values in JLC Managed to bodge it in a way that I have 2 presets to either advance or retard the timings. It should be fine for a second test board anyway.

[exxos]

Finally got all the MC68882 FPUs tested and accurately speed rated with my new cool stickers . They be heading to the store over the weekend.

Options will be 16MHz, 40MHz, 50MHz. All tested properly with the DFB1X accelerator.

MC68882.jpg (57.55 KiB) Viewed 214 times

[TheNameOfTheGame]

One of those things is not like the others.

[exxos]

One of those things is not like the others.

Always done to annoy

[PhilC]

Where’s the tick box for the “f*caked ones?”

[exxos]

Where’s the tick box for the “f*caked ones?”

The bin eated all those ones.