ST536 STE EDITION

[PhilC]

Ok re hddriver, I use ver11.17 with the bban interface with my Mega and it works great but only since changing the oscillator.

Once I've got the bits from @exxos this week I'll test with hddriver and a couple of others on the STe using bban and IDE. I can probably test with USatan as well.

I'll scope the STe536 clocks out later on if I get a chance but this will be without testing whether it runs or not. Will try and do the same for the ST536 in the short ST but can't presently test a TF536 in an Amiga.

[exxos]

@PhilC That osc issue is odd. The CPU runs at 8mhz when accessing the ST so it shouldn't matter. However, it's possible something is skewing the clock in the PLD just enough to get it working .

The whole thing is crazy. A 47pf cap on the clock can make or break the thing. Nothing should be that sensitive. If it was that bad with the original TF536, the forum would be full of people moaning. This doesn't seem to be the case.

What's more bizzare, is the TTram seems to be affecting the ST side bus which is not really possible since the ST bus is isolated during 32bit access anyway. There's just a lot of screwy things going on which don't make any sense. I can fiddle with the firmware but it will work on my machine then not others. Things have improved. But I'm moving further and further away from the original code base now which I'm not happy about.

So I need to look into the original problem more.. but if it's not the PLD , it would need a deep analysis doing with a LA which i simply dont have time or equipment for :(

[PhilC]

@exxos I have a tektronix TLA704 you can use if you want but you'd need to collect as I can't drive at the mo.

[exxos]

@exxos I have a tektronix TLA704 you can use if you want but you'd need to collect as I can't drive at the mo.

Thanks, will keep it in mind. It being finding the time which is always limited. I can't even get in my workshop anymore... Needs tidying up.. to much to do and not enough hours in the day to deal with everything..

[exxos]

I asked GPT about it all...

Yes, it's possible. When the design is very dense or nearly full, the placement and routing tools may have to make compromises that increase signal propagation delays or change the delay balance on critical paths. This can affect expected timings in several ways:

• Routing Delays: Limited resources may force longer or more congested routing paths, increasing delay.
• Clock Distribution: The clock tree might be reconfigured to work around resource constraints, which could introduce extra skew or delay.
• Timing Margins: With increased delays, timing margins shrink, making it more challenging to meet the required setup and hold times.

In short, if the compiler is struggling with resource constraints, the actual timings could indeed change from the expected values, and you might need to adjust your design or constraints accordingly.

[Steve]

@PhilC @exxos @coonsgm

I don't know if you guys saw the post I was talking about, but it's here:
'HD Driver works on your 030+ Atari just by coincidence'
https://www.atari-forum.com/viewtopic.php?t=44646

Now my basic reasoning is with this new accelerator, if EmuTOS internal hard disk driver is working but HD-Driver (on 2.06) is not, then I think it could be a red-herring to think TOS 2.06 is to blame. Don't forget that HD-Driver had certain 'patches/tools' to make certain accelerators work. Since ST536 is something Uwe Seimet has never used, it could possibly be an issue.

Just a tiny excerpt:

- HDDRIVER.SYS uses self-modifying code and yes, you've guessed it, without any cache flushing ... again, it's just an incredible luck that TT030/Falcon030 doesn't preload part of this code in their instruction cache (now you see why it works on Milan - disabled caches do not need flushing...)

- that self-modifying part is supposed to be super-optimised but on the contrary, it's "de-optimised", again because Dr. Seimet didn't understand how instruction cache works

I would say to anyone testing with 2.06, try ICD / PP drivers. See if they work, don't just rely on HD-Driver and then 'assume' the booster and/or TOS is to blame.

[exxos]

I don't know if you guys saw the post I was talking about, but it's here:
'HD Driver works on your 030+ Atari just by coincidence'
https://www.atari-forum.com/viewtopic.php?t=44646

So a quick read at it, it only effects TTram installs ? I've always ran the driver from STram AFAIK...

Why hasn't someone ported the EMUTOS driver as a standalone PRG for TOS by now ? With it being open source, all issues and improvements by developers could be done a lot easier..It be way better than keep depending on the old ICD tools for a "free" driver..

[coonsgm]

PP IDE driver does not work...it sees the drive, but will not partition.

[exxos]

PP IDE driver does not work...it sees the drive, but will not partition.

So basically, there is no fully functioning driver then by the sounds of it :roll:

I thought TOS took care of all the flushing anyway.. at least that's all the stuff I enabled in my build of 206 so it wouldn't screw up with the 030 :shrug:

I thought all the driver did was to "basically" set the sector numbers for the dma transfer.. DMA is then handled by TOS and flushes the caches itself... But it's not my area of expertise anyway..

[PhilC]

I've had mine booting to desktop using the CLK7M jed file but it's very unreliable without a CPU spacer in. Look at it the wrong way and it'll crash

Will give it a proper test once the spacer and ram have arrived.

Re programming on the Pi, took ages to get it set up, mainly because half of the guides are out of date but it's going now and the Pi 3 is going to be a dedicated Xilinx only programmer. At least I can connect to it via SSH from my Mac now.