ST536 STE EDITION

[exxos]

My particular request wasn't to switch down to 8MHz, but to have an ability to disable the caches and MMU that wasn't reliant on the OS being present (for bootloading games, basically. They'd work under 2.06 which didn't enable the caches, declare TT-RAM nor set up an MMU table, but would fail under ExxTOS and EmuTOS which do). Jumpering the CDIS and MMUDIS pins did seem to do the trick for the most part, but obviously would need switch(es) in the case. I was asking if these could be set by register such than a program could shut them off in hardware for the duration of power up.

I forgot about the MMU.. Id assume I would have to run a wire from MMU_DIS to the PLD for that.

CDIS could be done as well, but its going to cripple STram speed to 78%. So at that point its a de-excelerator :P With I-cache on, it gets back to 91%. Its likely the datacache causing issues in games.

An 8MHz option sounds like a good idea (if it could be made to work), but wasn't part of my request. I'd just like three bits of a register to en/disable MMU, Cache and TT-RAM (although the latter was found not to be invovled in my tests in the end). Perhaps reserve a fourth bit for a possible 8MHz mode if it could be made to work in the future?

8MHz on its own will cripple stock speeds. It needs I-cache on, and 50MHz boost for the caches to work properly. But disabling D-cache alone in hardware isn't simple I think..

You would have to benchmark games with and without CDIS on to see what the realword impact is going to be.

I'm working on the TTram disabled now. I will issue BERR when it tries to access TTram. Then TOS won't know about it.

In terms of games, a register will be a problem to set. unless every games is patched which wont happen. So a simple hardware switch to disable TTram, CIS, MMU might be the way to go..

[Badwolf]

I forgot about the MMU.. Id assume I would have to run a wire from MMU_DIS to the PLD for that.

Yeah, I had in mind the next revision, or a user-added patch wire rather than an immediate fix. CDIS might be doable, though.

CDIS could be done as well, but its going to cripple STram speed to 78%. So at that point its a de-excelerator :P With I-cache on, it gets back to 91%. Its likely the datacache causing issues in games.

I'm confused by this. You're saying disabling the cache drops ST-RAM read performance at 50MHz? That's not behaving properly if so.

8MHz on its own will cripple stock speeds. It needs I-cache on, and 50MHz boost for the caches to work properly. But disabling D-cache alone in hardware isn't simple I think..

Don't bother with 8MHz, then. It's a nice-to-have rather than a major compatibility bonus (things might run, but run too fast -- compare with the cache which means things might not run at all).

I'm working on the TTram disabled now. I will issue BERR when it tries to access TTram. Then TOS won't know about it.

I still think simply turning off the buffers is the least impactful way to do that, but YMMV.

In terms of games, a register will be a problem to set. unless every games is patched which wont happen. So a simple hardware switch to disable TTram, CIS, MMU might be the way to go..

I don't think you follow what I mean here. A register can be set by a special program (it's just peeking and poking a [probably 8 bit] address) from the desktop. It will keep in effect until the next power down or it's changed again by the same program. You can then reboot into the game.

A register that's cleared at reset is no good at all. If game patching were on the cards, then you'd just patch it to do a movep.w #0,cacr (ok, that won't help the MMU ones, but probably the majority). The point is to be able to boot unpatched games.

Anyway, there's a hardware solution involving dual throw switches, but I thought it'd be pretty straightforward to make software driven.

BW

[dml]

Would it not be helpful to have an AUTO folder based driver that allows cache configuration to be set in software, per memory region, using the 030 PMMU? This would allow cache to be set on/off for STRam according to what the user wants to do.

The slow speed is caused by the CPU cache operating in 32bit words, while the bus is serving 16bits at a time. So a 16bit access is probably causing the cache to request both words off the bus, one after the other, to allow the cache entry to be filled. The performance will then be different according to the size & alignment of the read etc.

If the PMMU is used to mark STRam as non-cacheable, the cache can be left on for ALTRAM.

I think the Falcon deals with this in the COMBEL by inhibiting cache for 16bit-sized reads/writes (when not already filled - or something like that). This is how it manages to read a 16bit word in half the time of a 32bit word.

[EDIT] actually, remembering a bit more - this is not what it's doing - its still filling the cache but not interleaving the reads the same way

You might have other problems going on which complicates it further but this is maybe something worth a look at least before hardwiring the FW or the PCB to work around it.

[exxos]

From what I remember the 030 does 2x16 bit reads which is the cause of the slowdown. Data cache on makes 78% RAM speed, data cache off gives 91%. I-cache on might be giving a bit of a boost, but data cache on is a hindrance at 8mhz.

Registers I'm trying to do, but iys screwing with the timings of everything again making it incredibly difficult to get it reliable.

TTram disable is working, I had issues because TOS was going nuts with the TTram test. I can't issue BERR, it has to not see STERM at all and cause the error that way. I can't simply disable the databuffers as that screws up the SDRAM timings which I was righting with the past few weeks..

Every single change no matter how innocent or minor it seems, basically every line of code I add ends up in a weeks (or more) testing and debugging. Frankly I am really getting a bit fedup of this xlinix stuff. Its like playing with a "house of cards" all the time. Make one tiny change somewhere and the whole things comes crashing down. It's why everything is taking so long. As fix one thing, someone unrelated breaks. Originally it *just* fit in a 144.. now its hitting up to 80% in the 288 just because of all the things I have had to fix.

I will try and do the registers but it may simply just be impossible to actually accomplish, because of all the extra code overhead everywhere shifting timings on other parts of the code again.

[dml]

From what I remember the 030 does 2x16 bit reads which is the cause of the slowdown. Data cache on makes 78% RAM speed, data cache off gives 91%. I-cache on might be giving a bit of a boost, but data cache on is a hindrance at 8mhz.

That's more or less what I'm saying - and the PMMU can stop that in software, which allows the HW side to be simpler?

Registers I'm trying to do, but iys screwing with the timings of everything again making it incredibly difficult to get it reliable.

You mean exclude the HW registers area from being cacheable? Again, PMMU can set up page tables to stop that on the software side.

TTram disable is working, I had issues because TOS was going nuts with the TTram test. I can't issue BERR, it has to not see STERM at all and cause the error that way. I can't simply disable the databuffers as that screws up the SDRAM timings which I was righting with the past few weeks..

TTram disable - is that about disabling TTRam when none is installed, or disabling cache when accessing TTRam? (I didn't follow that part)

Every single change no matter how innocent or minor it seems, basically every line of code I add ends up in a weeks (or more) testing and debugging. Frankly I am really getting a bit fedup of this xlinix stuff. Its like playing with a "house of cards" all the time. Make one tiny change somewhere and the whole things comes crashing down. It's why everything is taking so long. As fix one thing, someone unrelated breaks. Originally it *just* fit in a 144.. now its hitting up to 80% in the 288 just because of all the things I have had to fix.

I can see how annoying that could be.

"fedup of this xlinix stuff"

...but isn't the worst part about Xilinx stuff the fact the chips go obsolete and unobtanium 5 minutes after you design something with one? :D

There are jellybean parts still available from 1980 but you can't get a whole bunch of CPLDs anymore for stuff that's still being made!

I will try and do the registers but it may simply just be impossible to actually accomplish, because of all the extra code overhead everywhere shifting timings on other parts of the code again.

If I can de-tangle myself from 5 other things in the next week or two I'll have a look at the PMMU stuff again - I wanted to make a similar driver for DFB1X anyway (TOS->ALTRAM, PMMU pagetables + cache control etc.) and I expect that could mostly 'just work' on this board since it would do the same stuff, just with a different TOS image and maybe different addresses.

[exxos]

- and the PMMU can stop that in software, which allows the HW side to be simpler?

It can stop the double bus reads ? That would be good if that could be stopped.

You mean exclude the HW registers area from being cacheable? Again, PMMU can set up page tables to stop that on the software side.

Everything in STram has CIIS set to not cache the whole area.

TTram disable - is that about disabling TTRam when none is installed, or disabling cache when accessing TTRam? (I didn't follow that part)

@Badwolf suggested to disable TTram because of suspect compatibility issues. So it would simple "hide" TTram.

...but isn't the worst part about Xilinx stuff the fact the chips go obsolete and unobtanium 5 minutes after you design something with one? :D

That's the general problem with a lot of things these days, by the time you have learned something it's obsolete! Mostly why I tried to stick to GALs and Atmel PLDs as at least they still obtainable and 5 volt parts. But not much good for building SDRAM controllers though!

If I can de-tangle myself from 5 other things in the next week or two I'll have a look at the PMMU stuff again - I wanted to make a similar driver for DFB1X anyway (TOS->ALTRAM, PMMU pagetables + cache control etc.) and I expect that could mostly 'just work' on this board since it would do the same stuff, just with a different TOS image and maybe different addresses.

Sounds cool, yeah time is never anyone side these days..

[exxos]

This is what I mean... STram test passes fine on startup.. I enable my new register and it somehow corrupts video RAM! I mean all it has is the address decoding and DTACK basically.. Its like the address decoding is always wrong and triggering when its not supposed to be.

I think every time I plonk something on the addressbus the whole thing slows down.. then anything else which is decoded, ends up out of sync and everything breaks.

IMG_3272.JPG

EDIT:

Even more interesting...

IMG_3273.JPG

[Badwolf]

Everything in STram has CIIS set to not cache the whole area.

Actually, that's an interesting point.

I had to disable the caches to get a lot of games to run either at all or properly with the 144 firmware and memspeed indicated caching was working on STRAM at the time. Now, from my screenshot above (the one with the haywire TTRAM speeds), I can see STRAM isn't being cached at all.

Perhaps my stable 144 firmware simply didn't have this part enabled and now I won't need to set CIIN to boot some of my games?

I'll give that a try later if I can. I know Flight of the Intruder was a great test case for that.

I think it was F1GP that didn't work with the MMU set up -- but if this new firmware reduces the number of swiches needed to one, it may be more palatable to users.

BW

[exxos]

Perhaps my stable 144 firmware simply didn't have this part enabled and now I won't need to set CIIN to boot some of my games?

In early firmware STram was likely cached (most likely cached in 144 firmware) ,, but its been disabled in the past several firmwares most likely. I didn't keep every firmware revision code, so not sure when it changed exactly.

[exxos]

Been playing around with the register and it's very confusing..

I ran CLK100 and it screwed up.
I ran CLK8 and it screwed up.

I ran CLK100 / 2 for a new CLK50 and it works fine now.

:WTF: