HDD drivers. How does it work?

News,announcements,programming,fixes,game patches & discussions.

Moderator: Petari

fenarinarsa
Posts: 9
Joined: Mon Dec 18, 2017 4:03 pm

Re: HDD drivers. How does it work?

Post by fenarinarsa » Fri Dec 22, 2017 10:21 pm

A lot of interesting topics :)

ICD: Well I didn't use any HDD on Atari until two/three years ago (I think) when I bought a MSTE with a Satandisk. Back in the 90s I couldn't afford an HDD so I didn't know at all how the drivers worked etc (I didn't even know there were drivers, I learnt that with Satan/UltraSatan).
I remember ICD being a HDD vendor though. Didn't know they did drivers and that they extended the standard protocol.

Debug: I used Steem SSE debug a lot during the development of bad apple. Unfortunately with no ACSI emulation, but it did help me a lot anyway.
And yes I'm interested in drivers working in Hatari :)
I didn't use Steem SSE for anything else than debugging because it doesn't emulate the switch to 60Hz (the render stays at 50Hz so the demo is slowed down).
I haven't really used "the old" Steem for years.

TOS sector loading: THAT'S IT. So when I load small chunks of file, the TOS ends up loading a lot of unnecessary data and doing a lot of memory copies after that. When loading huge chunks, it loads most of them to the final destination directly. That was what I was wondering about :) Thanks for the confirmation!

DMA priority: yup during my tests I checked that the HDD DMA loadings take precedence over the 68000 and the blitter. I was not sure about the blitter but I did some checks :) In any case it was something that was great for me, it meant I could start a file read then fire an interrupt and do something else while the DMA was automatically taking cycles and transferring data.

Now about the blitter/cache.

It's really sad the MSTE cache page has disappeared, it had a ton of useful data in it.

In bad apple specifically, I don't mind using the blitter with cache on. I don't know if the blitter is behind the cache or not, but in my case, it only does copy between the loaded data and the screen. The 68000 does not need to access this data so it can be different in the cache than in RAM ;)
However if my memory's right the cache is an external one and quite simple (associative, write through). So maybe the blitter is not behind the cache but is wired in a way that it can invalidate cached data associated with its DMA writes. But it's a theory, I don't have any schematics right now (and my skills in reading schematics are quite low). My opinion is that if it were not the case, using the cache+blitter would end in a lot of crashes or erratic behaviors of many applications. And it's the default configuration in TOS 2.0x with the control panels loaded.

For ACSI DMA this may be different (is that documented?).

However to disable the cache during loading and restore it after the loading is done is maybe a bit overkill (I understood that you restore the cache once the loading's done, I wasn't clear in my "steps list").
Let say you load 8k in memory: start the DMA transfer, then when it's done, disable the cache and enable it back immediatly. If it works as advertised, all cached data are invalidated and the SW and/or TOS would access the newly loaded data safely.
If you disable the cache before starting the DMA and enable it back again at the end of the transfer, if a long interrupt fires (like it's my case with bad apple), all the interrupt will work without cache, which may not be expected.

I say that because I want to try to make some effects specifically using the MSTE cache :)

Maybe some tests on real HW could be necessary. Unfortunately Petari I don't have your skills in ACSI DMA programming.

Petari
Posts: 174
Joined: Tue Nov 28, 2017 1:32 pm

Re: HDD drivers. How does it work?

Post by Petari » Sat Dec 23, 2017 8:35 am

When you doing some extension - like ICD did with ACSI protocol, you do HW and SW parallel - that's the only way what ensures it work well.
In my opinion, it was one of best done on ST - basically, it just adds one byte in command chain to activate extended mod. That needs not some complicated HW. There was thinking about doing replicas. clones of ICD adapters some 6-8 years ago, but Flash cards won - and that's OK. Principle is still alive.
Latest Steem SSE v. have own ACSI emulation. With older Steems there is ACSI emul. in Pasti.dll .
Emulates not switch to 60Hz ? But it works fine in Steem 3.2 . It may be just one of more-less usual minor bugs in specific SSE v. Steven Seagal does lot of changes in short time, and we see often some bugs - or better said, what worked well in earlier v. works not in latest (usually some beta).
This is why I use 98% time good old Steem Dbg. 3.2 - it is good for most of SW. No bad surprises every 2-nd day. And I even modded it - sources are open now.
As I explained, blitter at 8 MHz can not benefit from using cache, actually blitter can not benefit at all from using cache. Yes, it''s theory, and I let to someone else to do practical tests. I have what to do months ahead.
There is not big chance that DMA load, blitter transfers (or even load from IDE port) will go in cached RAM space, with good SW design you can assure that it never happens. But driver SW can not know what area(s) are cached, so it must go safe way. And speed loss is not that big. Probably would lose more if using some mechanism to inform driver what areas are cached.
" if a long interrupt fires (like it's my case with bad apple), all the interrupt will work without cache," - why you think that ? Why should cache work different way in interrupt ? Cache will be active, and fill gradually during executing code - regardless is it in interrupt or not, regardless from CPU mode - user or supervisor.
Using MSTE cache in effects ? Indeed, you can do things faster with cache on. But there are things which will work only barely faster:
memory copy: try first with blitter and cache off , then with cache on - that will be good test for is blitter really using cache.
then, try movem.l (enroll same movem.l 8x in row for better speed) type memory copy with cache off, then with cache on. You will see that later is max some 10% faster (when using 15 registers in movem) . Because only opcode fetch and loop control will work faster, data copy speed is dictated with RAM speed. Of course, tests need to be done with larger blocks.
I started with IDE programming in 1991. So, that's long practice :D ACSI is not that hard when you know how it really works. As in most things, ProfiBuch was my main literature. That ACSI section from first edition is removed in later (1991 edition) from some reason. I don't think that it was because errors there (there was 1 for sure), or because bad DMA speed claims. I smell some interests there - we know that Germans were most active in hard disk driver business :D . Uh, now I'm the conspirationist :lol:

fenarinarsa
Posts: 9
Joined: Mon Dec 18, 2017 4:03 pm

Re: HDD drivers. How does it work?

Post by fenarinarsa » Sat Dec 23, 2017 11:10 am

Okay, I didn't know at all the ICD history, thanks :)

I don't think the blitter uses the MSTE cache, there is no interest in that. To my knowledge only the 68000 can swith to 16Mhz, the blitter stays at 8Mhz. A 16Mhz blitter would be useless anyway. But there may be a mechanism where the blitter "warns" the cache it changed something in RAM.
What I will try is to cache a small memory area (it's easy to do, just read the area with the 68000), then start a blitter transfer to write to this area, and then read the area again with the 68000 and check if something changed.

What I'm saying about interrupts is that if you disable cache before starting the ACSI DMA transfer and enable it again after the DMA transfer is done, if my render interrupt start during the DMA transfer (which actually happens), my interrupt will be running with disabled cache.
You don't have to know what area is cached or not, the only important thing is to know that DMA transfers are not cached. That means you can disable&enable cache after the DMA transfer is done, because then all cached data will be invalidated and all further RAM access will be forced to be cached again.

What would be interesting is to check how the 2.06 TOS handles cache when doing reads from a floppy, since it uses the same DMA channel.

fenarinarsa
Posts: 9
Joined: Mon Dec 18, 2017 4:03 pm

Re: HDD drivers. How does it work?

Post by fenarinarsa » Sat Dec 30, 2017 5:08 pm

Thanks to you Petari I released a new version that seems to work flawlessly with HDDRIVER. I don't stop Timer C anymore :)

https://fenarinarsa.com/badapple/fenari ... _final.zip

(source code)
https://fenarinarsa.com/badapple/fenari ... source.zip

Petari
Posts: 174
Joined: Tue Nov 28, 2017 1:32 pm

Re: HDD drivers. How does it work?

Post by Petari » Sat Dec 30, 2017 5:26 pm

HDDRIVER who ? :lol: Good work :dualthumbup:

Post Reply