CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

[exxos]

Been having a lot of issues to the point I cannot even remember what I was actually supposed to be investigating

Though overall, I think a more advanced clock switching is needed.. So I've gone back to more conventional switching methods and now it seems totally stable and waveforms look a lot better than the original boosters...

aass.png (4.51 KiB) Viewed 2828 times

Of course this uses more FF's to sync, so there is more delays, and there is a few percent slowdown over the previous boosters.. .Think it is better this way and seems to be a lot more stable..

The problem is, even changing the PLD brand/type is enough to screw things up. So I think adding in a little bit better delay system will ultimately help with all the issues.

[exxos]

32MHz osc now added.. clock is glitching all over the place, but I don't care as its working ASYNC and stable

Yellow = /AS
BLUE = CPU_CLK

aa32.png (4.55 KiB) Viewed 2818 times

Had to add blitter to compare to STE benchmarks as only machine I can reference 32MHz to..

STE 32MHz..






32MHz STFM..

stf32a1.jpg (111.92 KiB) Viewed 2818 times

For some odd reason ROM access is slower than it should be So need to investigate that next.. probably be Friday now before get time to work on this again...

Oddly it seems to switch in steps from 8mhz to 16mhz then 32mhz .. In anycase, this is really good start and the first stable testing of 32MHz ASYNC

[rpineau]

So you're switching between a 32MHz oscillator and the system clock. The 32MHz not being the one from the mother board ?
This looks good indeed and once you have this you can then move to 32MHz all the time
congrats on the progress.
RoRo

[exxos]

So you're switching between a 32MHz oscillator and the system clock. The 32MHz not being the one from the mother board ?

Yes

This looks good indeed and once you have this you can then move to 32MHz all the time
congrats on the progress.

I don't plan to run 32mhz constant with this, I don't think there is any use with 68000 stuff. I've ran constant 16mhz ages ago, actually after sync and gate delays it actually works out a fraction slower.

I don't really think ASYNC is any use with the 68HC000.. easier to use the 32MHz system clock... I only really went for ASYNC to allow me to find top speed of 68SEC000 CPU. but I still need to finish that project.

[exxos]

I have a WIP thought..

I know STE is really easy to build boosters.. it seems to not be fussy about anything..

I know the STFM can run double speed MMU & CPU without problems.. and I also know I can run 16MHz CPU constant without problems..

The problem is, something screws up on the STFM, preventing ASYNC operation (STE doesn't seem to care about this at all). So I was thinking it must be MMU related... as system can work at double speed easily.

As soon as the CPU goes ASYNC from the system clock it starts to fail. Now I think this might be relating to the interleaving of RAM and CPU cycles. The CPU has a "slot" to do anything it wants, really at any speed. Though even when not accessing the bus, it still screws up something.. which makes no sense..

A thought was it could just be slow bus isolation drivers LS244.. Because when system is in sync, the delays of the drivers doesn't really matter, since the CPU will not put /AS low for 100+ns... BUT, imagine now if the CPU has /AS low all the time, aka data constant on the bus.. then there will now be a conflict of data on the bus because of propagation delays of bus isolation. This may only be 20ns, but condition can be there where CPU has control of the bus at the same time the MMU is starting a RAM cycle.. basically CPU & RAM bus shorted out via LS244...

There will be delays in MMU logic also.. but problem will get worse the faster the CPU goes, and the more it goes out of sync, more chance of bus conflict. Of course with using system clock, this "fault" is never seen, as CPU will take much longer to put data on bus than propagation delay of LS244 buffers. But even 8MHz ASYNC would likely easily "drift" into same problem.

Also, STE is re-design of ST circuit (but still very similar) , fully integrated MMU/GLUE logic, so problem is likely still there, but delays much less.. so STE can operate easily with ASYNC because logic isn't as "slow" as STFM.

It is also possible 38MHz CPU on the STE, might not actually be the top speed of the CPU, but the speed which is needed to run into bus isolation faults again.

So if I get time tomorrow, I am going to see if I can work out delays through MMU and isolation delays. I will also order some F244 and see if these improve the stability....

[Neffers]

So, in laymans terms you are running into issues with latency, the ability to switch from 0 to 1 without ramping? (sorry for the laymans reply, I just want to understand what you are battling with)

[exxos]

So, in laymans terms you are running into issues with latency, the ability to switch from 0 to 1 without ramping? (sorry for the laymans reply, I just want to understand what you are battling with)

I don't know if it is a issue yet... its just a idea..

but there are 2 bus paths to RAM, so CPU has to be isolated, only I suspect the isolation isn't fast enough so the 2 busses are shorting out during the delays in isolation.

[Neffers]

Again, laymans reply, is it capacitance that's causing you issues maybe? I have no idea of the layout of the traces but mebbe there's some feedback or something causing your issue? Holding thing high, skewing, all that malarkey.

[exxos]

https://en.m.wikipedia.org/wiki/Propagation_delay

[Neffers]

Ah, latency to attain a solid result. Half way between a logical 1 from a 0. And you are there stressing that to the fullest, riding the wave, so to speak. Noise is your enemy.

I dunno how far down the rabbit hole you have to go to get this far, but I wish you all the best. Honestly. Without you probing, who would know? Please carry on your research. It's great to witness.