REV 3 - REV 5 - The beginning (ST536)

[exxos]

Does the problem appear when maprom is not used at all?

In my build of TOS, it works fine now without maprom at all. Maprom (no cache) 4K or 32k relocate seems to work fine now I think.

So I'm trying to read some of the older posts in the thread and found this:

Blitfix shouldn't touch any cache related things at all, and the option works in standard 206 with maprom + blitfix.
Maybe the custom built TOS is getting confused for some reason?

Hmm, problem is going backwards in posts, is its getting onto other faults as well in the mix. I have not retested BLITFIX much yet in my current setup.. But I think currently there are no problems.. But I been more focused on the floppy issue more than anything lately.

I had another thought about using patched ROM images., maybe a tweak to maprom. In that if it finds a file eg: TOS.BIN, it would load that into fastram, if the file isn't found, then it copies the ROM to fast ram like normal.

Yes, I do love this idea!
Last time I thought about exactly that I identified two potential problems:

• - MMU. It'll have to reset into the loaded OS, and it's probable that it will initialise the MMU on startup thus trashing the existing rom->ram mapping and everything goes south.
  But I guess that could be very easily verified by looking at TOS sources to see if it performs the PMMU setup always or only on cold boots.

I forgot about that idea. I thought it would be possible as you did a ROM loader anyway. I think there was some patch in the TOS sources, something about not resetting MMU on reset or something. Its not a deal breaker anyway. I stocked up on UV erasable ROMs now ;) But maybe we could look at that another day. Fiddle with TOS itself to look for TOS.BIN on floppy before it gets to desktop or something.

Mostly I just want to figure out that floppy cache issue with MAPROM. Then hopefully I can bring the TF536 project to a close then. The only other thing really I could do is put MAPROM into TOS206 itself. The only slight hiccup is MAPROM cannot be disabled if something screws up :) but I would not release the new 206 files unless I was confident all tests possible were done without issue.

[agranlund]

So I got the Gotek hooked up and I'm able to repro the issue with EmuTOS which is good.

Haven't had time to dig into it properly, not sure when I will, but trying some combinations ended up with some interesting results.
Floppy seem to go bonkers if rom is in fastram and cache is enabled for st-ram.
Just rom in fastram by itself is ok. Likewise, enabling st-ram cache is completely fine as long as rom is running from rom.

Could be maprom bug.
Could also be a case where some delay code/loop in TOS goes too fast when everything is essentially running at cache-speed (I don't think this is what is happening, but I also don't want to rule out the possibility)

I know it's not ideal, but I guess you could just use the maprom that cache-inhibits st-ram if you're in need of the floppy drive for anything?
Maybe I'm just influenced by the 520STM not having one built in, and maybe I'm in a minority, but is anyone actually using floppies for anything on accelerated machines?

[exxos]

Could also be a case where some delay code/loop in TOS goes too fast when everything is essentially running at cache-speed (I don't think this is what is happening, but I also don't want to rule out the possibility)

I considered that as well the other day. There was some code in TOS relating to accelerators and problems. I tried all sorts of values but made no difference.

I know it's not ideal, but I guess you could just use the maprom that cache-inhibits st-ram if you're in need of the floppy drive for anything?

Yep.

Maybe I'm just influenced by the 520STM not having one built in, and maybe I'm in a minority, but is anyone actually using floppies for anything on accelerated machines?

It would likely affect people with ultrasatan as well. Of course if people only use the IDE, then it should not be a problem.

[exxos]

I have released my build of TOS206 on the main webpage https://www.exxosforum.co.uk/atari/last/TF536/index.htm

It's had pretty much no testing other than what has been mentioned previously. But seems to work ;)

That's likely the last update for this project as there isn't anything else I can really do now.

[exxos]

To avoid crossing the streams here... @agranlund Updated MAPROM..

https://www.exxosforum.co.uk/forum/viewt ... =40#p85308


So to confirm that the previous version of MAPROM_C caused floppy corruption when clean booted. Loading HD11 First seems to alleviate that problem as previously discussed.

So my first test was with generic TOS206 with MAPROM_C v2.2. The floppy contents are not corrupted! The second test was loading a GB6 benchmarking file as these would sometimes get corrupted.. And that now seems to be working fine!

So TOS206 MAPROM_C 2.2 benchmark.

IMG_0589.JPG

I am actually surprised vanilla 206 works!

As previously mentioned @agranlund I suspect reallocating the 32k chunk may actually behave now as well.

[agranlund]

Nice! That's great news :)

As previously mentioned @agranlund I suspect reallocating the 32k chunk may actually behave now as well.

I suspect that too. I'll get some roms burned and take a look but may not be able to until the weekend.

[exxos]

I suspect that too. I'll get some roms burned and take a look but may not be able to until the weekend.

Be cool if 32K works. I didn't see any changes from testing 0k, 2k,4k in terms of the floppy problems in previous tests anyway.

My ST536 TOS 206 works just fine as well. I assume MAPROM is just skipping the install of the FRB if it's already found? (my ST536 installs it and the alt-ram automatically).

Great work! :cheers:

[agranlund]

I suspect that too. I'll get some roms burned and take a look but may not be able to until the weekend.

Be cool if 32K works. I didn't see any changes from testing 0k, 2k,4k in terms of the floppy problems in previous tests anyway.

My ST536 TOS 206 works just fine as well. I assume MAPROM is just skipping the install of the FRB if it's already found? (my ST536 installs it and the alt-ram automatically).

Great work! :cheers:

Yep it should just ignore anything alt-ram + frb if it's already there :)

[exxos]

Just popped in my head that because of my "wireless IDE autoboot hack" That MONO will likely not work with the current firmware. (***)

So at some point I will compile a firmware which does not do the "wireless IDE autoboot" So that colour or mono be used. But of course the classic ACSI pin10 wire will have to be added instead.

Unfortunately this is not fixable to have it all, because of space limitations in the PLD. Not really worth adding another £50 just for the sake of not using a physical wire. It might be possible to do a "mono only" setup with IDE autoboot. But I think it would just get too confusing with multiple options for different things.

(***)

Something which I don't think was abundantly clear is there are some 10K pullups to add on the bottom of the board if using the current firmware with "wireless IDE autoboot".

IMG_0016.JPG

IMG_0017.JPG

I am sure there could be neater ways of doing this but I was in a hurry so..

[exxos]

The above modifications I think are no longer required since it was fixed in firmware a while ago. The resistor packs will be on any future boards regardless. They are there to tie the bus high when the bus isolators are active. Likely only really needed when doing "bit injection".

I have updated the firmware and software pack on the website https://exxosforum.co.uk/atari/last/TF536/index.htm . Non-critical updates. The main one being it now includes a later tested version of MAPROM. The one included in previous builds, as I just found out, had extremely slow floppy access.

I copied over NVDI4 to give it a test. As I don't think results were previously posted anywhere.

ST536_NVDI.jpg