REV 3 - REV 5 - The beginning (ST536)

[exxos]

Thought I would just try my TOS206 build which was going nuts with the floppy drive yesterday seems to be working fine if I don't run the cache on version of MAPROM :shrug:

TOS206 "vanilla" has the screen corruption when refreshing the floppy drive contents ( no other software other than HD11 loaded). Running MAPROM (not Cache version) the corruption seems to stop. MAPROM.PRG seems to solve the cache problem as before. Without MAPROM, the cache option in the desktop menu must be turned off.

TOS206 "exxos build" does not seem to have the corruption when refreshing the floppy drive contents ( no other software other than HD11 loaded). Running MAPROM (not Cache version) seems fine also. Running MAPROM_C.PRG the floppy drive goes nuts unless turning off the cache off in the desktop menu ( which is what vanilla TOS206 does). So my build must have corrected something at some point.

I just keep coming back to the same problem that whenever ST-RAM caches are enabled, things just inherently starts screwing up one respect or another :( I'm not really sure what the problem is as the same thing happens in EMUTOS. So I'm just currently assuming that the idea is not a good one :shrug:

[stephen_usher]

How does the CPU know to invalidate an ST-RAM page when the DMA has written to that ST-RAM without the CPU's interaction?

Does your CPU cache setting have write-through, rather than write-back, caching for ST-RAM?

It seems to me that your modified OS will need to turn off caching for the screen area and also set up the translation tables to temporarily turn off caching for memory targeted for any DMA operation until such time as that DMA operation completes.

[mrbombermillzy]

@stephen_usher I was thinking a similar thing.

Perhaps it would be an idea to have a look at what TOS 4.04 does with regards to blitter/DMA cache settings?

[exxos]

:shrug: I have no idea what I'm doing with the TOS sources or how they really work with it all. But it screws up with EMUTOS as well.. So I don't think it is just a TOS thing.

caches aside, I'm trying to get back the TTram stuff which TOS does. I think what the problem is the PAK patches enable everything you need, but they also install a bunch of other stuff which breaks a lot of other stuff. It seems to default to thinking it has a graphics card or something. So when it tries to initialise all that stuff, it simply cannot because it is only really running on a "ST". Unfortunately there are so many places that this code is patched it is pretty much impossible to follow it all.

So what I'm currently doing is going through various parts of the code and trying to enable parts of the PAK patches. In other parts of the code I am just taking out the checks altogether. It is difficult to know at what point the video gets messed up which is what I'm trying to work out as well currently.

It will take a lot of time I think, it is just process of elimination with it all. If I can just stop that odd corruption thing with 206 and get it to work with the alt-ram "out of the box". Then that is just going to have to do.

[exxos]

I think what's upsetting things is Hatari seems to force 24bit addressing on ST dispite using a 030 CPU. When its TOS306 it assumes a TT and disable 24bit addressing. So when it crashes when its supposed to be doing TTram test, could mean it would actually work on the TF536.

I've got some UV roms coming hopefully tomorrow. I will probably have to slow the ROM access down on the TF536 to use them. Then I can try some things out again. Problem is I'm not sure what point things broke. I had the TTram working until about the time I enabled all the cache stuff. So might just have to back track to day 1 code and try and get TTram working first then go line by line on the cache stuff to see where it broke, which will not be fun as a full erase and compile takes about a hour. If there's 20 things to try its going to take forever :roll:

EDIT:

Hexhack to "fool" Hatari into TOS306.. and looky now..

Capture.PNG

Now to find someone to shoot over that "auto mode" !! :cussing:

[Elethiomel]

Here's the results of some testing today. All tests done with a freshly formatted SD card each time containing the exact same release of FreeMint. Nothing in the AUTO folder except the Mint loader. No MAPROME. No nothing. All tests performed using the exact same ROM chip containing EuTOS 1.1.1

v2-IBE_AB : the boot would fail due to FS corruption. I'm betting it was due to the writing to the disk of the INI early in the boot file causing corruption. I would get FAT read errors and then a reboot. The drive was verified as corrupted by attempting to mount the filesystem back on a Linux system.

8MHz/16MHz 68000 with Exxos TOS Decoder/Booster System boots AOK and gives me a functional Mint as expected.

New firmware REV5 ST526 April 25, 2022 - Official BETA release. I installed the cache off version, crossed my fingers and booted up a fresh copy of Mint and it worked!

Well done Exxos! :D

[exxos]

New firmware REV5 ST526 April 25, 2022 - Official BETA release. I installed the cache off version, crossed my fingers and booted up a fresh copy of Mint and it worked!

Well done Exxos! :D

:bravo:

Emutos I think just loses a bit of speed without maprom... Its kinda a requirement for 206... If only we could integrate maprom into 206, that be cool :twisted:

[Badwolf]

I think what's upsetting things is Hatari seems to force 24bit addressing on ST dispite using a 030 CPU.

That's a command line or a configuration menu switch. --addr24 off IIRC.

If there's 20 things to try its going to take forever :roll:

Shame it's basically impossible to buy parallel flash ATM!

BW

[exxos]

That's a command line or a configuration menu switch. --addr24 off IIRC.

I can turn it off in the menu, but as soon as it sees 206 it turns it back on again anyway.

Shame it's basically impossible to buy parallel flash ATM!

I do have flashy clock somewhere. But I would have to do new firmware for the 536.. And I don't want to throw in another " almost completed" project into the mix at this point in time. I really need to get off the PC for a few weeks at some point :roll:

[Badwolf]

That's a command line or a configuration menu switch. --addr24 off IIRC.

I can turn it off in the menu, but as soon as it sees 206 it turns it back on again anyway.

Oh really? I hadn't noticed that before. Perhaps the Hatari boys reckon 2.06 isn't 32 bit safe? It does annoy me when it switches machine based on the OS when I might *want* to be doing what I'm doing.

But then again, I'm not like the target end user and I could probably hack the code away if I really had to.

BW