STE536 debug thread

[exxos]

I figured out the slow down..

It was odd as during TTram test it was running the CPU at 8MHz most of the time...

IMG_3210.JPG

Afterwards...

IMG_3211.JPG

Who can figure out from that what happend ?

Show Spoiler

Forgot to set PRGFLAGS in YAARTTT
#Idiot
#SelfInflicted

So back to testing RAM again...

[Steve]

haha :) Well yeah it happens to the best of us :) :oops:

[exxos]

It threw up a bus error and locked up during TTram test :roll:

It's now on loop 3.... After a "random" change...

It backs onto the address problems with the shadow ROM.. I've latched the address before feeding it into the SDRAM module and so far so.good...

The addresses bus goes via the PLD... I think even a small delay is enough to upset the thing. But it shouldn't need latching as the address should be stable anyway.. BUT... When AS goes low,.the address still has to transition though the PLD... I'm not convinced the address bus is stable before the SDRAM controller starts with the address.

So I've latched the address , which means delaying it also .. but now seems stable..

It kinda sucks as is the address bus unstable and a 10ns PLD is effectively snubbing out the address errors... Or has this always been a problem...and the 6ns PLD is somehow aggravating it now...

I didn't have this problem on my 2 builds either...So I'm assuming it's a fluke of tollerences if it works or not.

So it's likely the delay will go into the next firmware build. Sucks again as I was wanting to speed up RAM access but I'm having to slow it down an it now as something is unhappy..

[exxos]

Still going...

IMG_3212.JPG

[dml]

Wondering about this (and same thing on DFB1/X)... the 68030 reference describes important parts of bus interfacing & synchronization and one thing that always stood out to me is the asynchronous bus capability.

IIRC, it specifies that CPU exchanges with the system bus should be synchronous (i.e. insert wait states or slow down the CPU) when the CPU is operating at 2x the bus clock, or less.

However if the CPU is operating more than 2x the bus clock, it can run asynchronously without forcing in waits. Isn't that going to be the case here with a bus/cpu at 8/50MHz or even 16/50MHz?

I'm asking because the 030 can continue executing microcode or can defer writes and keep crunching at full speed while the bus takes its time to signal ready, which would be more efficient than switching the CPU speed up and down all the time.

Doesn't matter when accessing ALTRAM of course but does matter when you start filling pixels or audio samples for output and you're trying to e.g. address the next pixel with a few instructions between each write.

I forget exactly where this stuff is properly described but I can probably find it.

[exxos]

@dml Likey @Badwolf can explain this stuff better than me..

The 030 is slowed down to 8Mhz during "ST access" as it helps keep the CPU cooler than running at 50MHz all the time (experiments I did a couple years ago in fact, IRRC 50MHz all the time didn't give any better results than clock switching). The good thing in this instance, you don't need to synchronise anything really because everything happens at stock speed and then we don't really care about it..

If we run the CPU at 50Mhz all the time, then we have all sorts of synchronisation logic and wait states otherwise we tip up on the ST bus side.

The CPU can run async mostly, as long as DTACK etc is timed properly, the CPU will pick it up just fine. BURST needs more tightly controlled sync as its running so feking fast..

The CPU internal cache can still run code, there's no bus access there anyway.

The ST data bus is isolated during TTram access.... So the ST could do something, but no idea what, as even the blitter would need bus access, and I assume drives the address bus..

I don't know about "microcode".. or coding point of view of things.. Other than the cache , I don't see how code can run any other way ?

[dml]

If we run the CPU at 50Mhz all the time, then we have all sorts of synchronisation logic and wait states otherwise we tip up on the ST bus side.

Ok, I'm not certain about the details of what extra signals/logic/complexity you would need so... fair enough. I just remember that it does support async bus exchanges.

I don't know about "microcode".. or coding point of view of things.. Other than the cache , I don't see how code can run any other way ?

The 030 takes multiple clocks to complete each instruction - each assembly op breaks down into simpler micro-ops on the chip - and each clock tick moves that pipeline forward - it can continue doing that even if it is waiting for a write to happen (writes are deferred) or while a write is happening.

That's assuming the instruction is cached, yes. The CPU blocks for reads but can defer writes and overlap them with instruction execution. So any losses during switch-down will be mainly during writes, for code that is trying to overlap computation with writes.

Normal application software probably won't be doing a lot of that. Games - depends. Demos will be doing a lot of that. :)

[exxos]

I just remember that it does support async bus exchanges.

Unless we're talking different things.. I mean you could run the 68000 async anyway. It doesn't work though on a ST because it doesn't have proper DTACK control on anything.

Probably an easy example is exactly what I did with my V1 STE booster one point (40MHz red edition) .. I use the 32MHz and 8MHz clock normally as they are synchronised so you know exactly when things will happen.

Now if I run something like a 40MHz CPU on its own clock.. You have to take the absolute worst case timings which means you have to wait a clock cycle longer than you did previously to "get past" the "Random clock" sync timings. Basically just add a waitstate in there.. which makes things run slower.. even though your running a faster CPU..

The 030 takes multiple clocks to complete each instruction - each assembly op breaks down into simpler micro-ops on the chip - and each clock tick moves that pipeline forward - it can continue doing that even if it is waiting for a write to happen (writes are deferred) or while a write is happening.

I mean sure like long divisions the CPU can run stuff internally... I get that.. and sure, clock ticks move stuff along.. but im not sure about much else. I just go with the CPU needs to do a write, so it just gets on with the end of story :lol:

That's assuming the instruction is cached, yes. The CPU blocks for reads but can defer writes and overlap them with instruction execution. So any losses during switch-down will be mainly during writes, for code that is trying to overlap computation with writes.

Normal application software probably won't be doing a lot of that. Games - depends. Demos will be doing a lot of that. :)

All too clever for me :)

[exxos]

I'll leave @Steve's board on today doing RAM test.. I was fiddling with fast ROM last night which only got to pass 7. So disabled the fast ROM and leave it testing all day...

[PhilC]

One down, one to go then @exxos