exxos's Atari, Amiga & retro forum

terriblefire wrote: 01 Jun 2020 19:42 I think im too spoiled with WinUAE. It can access a CF card like its a raw IDE drive.

You can with Hatari and Steem but IIRC you either have to use a twisted cable to use regular ST images or byte swap the image?

,(still learning Atari, I was an Amiga dude back in the day)

I'm using the TF534 IDE :)

I bought HDDRIVER which is needed when booting Atari TOS.
P.Putnik has an alternative to HDDRIVER and I don't really know which one is best.
As far as I know, EmuTOS has built in IDE drivers that can handle both TOS and PC byte order and it won't actually load any drivers that happen to be stored in the bootsector.

My knowledge of IDE on Atari is extremely limited and I find it all very confusing to be honest.. with the different modes, size limits, and what works with what TOS and so on...
When I partitioned my drive I did it in TOS-only mode since I thought it would be simpler, plus I wanted it to be bootable with TOS1.04.
I was also slightly paranoid if the driver was going to do software byteswapping for PC compatible partitions and I don't want that.
In any case, since it was working and I could measure the speed being very close to the theoretical limit I never touched it again so I have no idea how those other, probably better(?), partitioning schemes work..

It sure would be nice if I could read/write that disk on my PC though...

Of course, with a TOS-only drive, you need to rewire the cable to swap the bytes compared to Amiga & PC. I don't think this is necessary for DOS or TOS/DOS partitions?
I'm now using a simple relocator PCB that does byteswap (and rotate the connector 180 degrees to make it fit better in the machine)

If you really want an image that is TOS-only partitioned I can try to make an image out of my CF-card? (I may need some pointers on what software to use) You'd have to make a twisted cable to use it though.

TF536 firmware to test.. rev2 only.

Has all Amiga performance enhancements enabled. Burst mode is available.

AltRAM is mapped 0x01000000 to 0x04FFFFFF with burst mode.

IDE interrupt patch is there .. my first attempt at this. I couldnt get IDE working so couldnt test it.

All sound fixes there. Works v nice for me on the H4.

Thanks @terriblefire ill give it a good test in the morning.

PhilC wrote: 01 Jun 2020 21:52 Thanks @terriblefire ill give it a good test in the morning.

Another update. It works for me in EmuTOS now.

@terriblefire yes that works in my H4 just fine. Gembench and Frontier give good results.

Once the decoder noard arrives ill test the IDE

First lot of Gembench results looking pretty good. Ofcourse once its running with NVDI and from fast ram its going to be pretty fast.

Here's the results

PhilC wrote: 02 Jun 2020 10:20 First lot of Gembench results looking pretty good. Ofcourse once its running with NVDI and from fast ram its going to be pretty fast.

My enduring frustration with the ST is the memory management from Apps. Almost all other OSes will allocate fastram first and chipram only if requested or if fastram is not available. Seems to be much more difficult to manage in TOS. Everything else about the ST i really like.

terriblefire wrote: 02 Jun 2020 11:30My enduring frustration with the ST is the memory management from Apps. Almost all other OSes will allocate fastram first and chipram only if requested or if fastram is not available. Seems to be much more difficult to manage in TOS. Everything else about the ST i really like.

in case of TOS the scheme is simple: the application decides which RAM should be used (by using MxAllox).
In case of old apps, which aren't aware about FastRAM, the user can define which ram will be used by using PRGFLAGS: http://www.atarimania.com/utility-atari ... 35601.html

Cyprian wrote: 02 Jun 2020 12:49 in case of TOS the scheme is simple: the application decides which RAM should be used (by using MxAllox).
In case of old apps, which aren't aware about FastRAM, the user can define which ram will be used by using PRGFLAGS: http://www.atarimania.com/utility-atari ... 35601.html

Perhaps thats the issue. Games like Frontier get loaded into ST-RAM by default. I'd bet they'd go much faster in Fastram.

EDIT: What i mean is by the time they get around to asking for RAM some games its already too late.

I've tried Frontier. The game runs but there are some issues and breakage.

You have to remember that there are two flags, data in fast ram and program in fast ram. The former allows the program to allocate memory and the former tells the OS where to put the program code.

(This is on a TT)