REV 3 - REV 5 - The beginning (ST536)

[exxos]

Capture.PNG (35.53 KiB) Viewed 2178 times

As to if it all actually still works or not is another question...

[stephen_usher]

It compiles, ship it!

[exxos]

It compiles, ship it!

If only! The floppy drive is not behaving now. So trying to figure out what I broke!

[exxos]

So this is VERY odd. If I boot from IDE (HD11) with or without MAPROM, I can access the floppy fine...
BUT, If I don't load HD11 from C:, no matter what I do, I cannot access the floppy.. it just shows corrupted contents.

It seems to also be relating to loading MAPROM from floppy as well.

NO IDE or BLITTER - MAPROM loading from floppy nothing else.. floppy contents corrupted(even though it seems to load MAPROM fine)

CLEAN BOOT TO DESKTOP - can access floppy fine. If I load MAPROM, same as above.

LOADING HD11 from floppy only - HD11 loads. C: drive comes up on desktop fine. floppy comes up fine. run MAPROM from C:, still fine.

Though I just saw some screen corruption.. Not sure where that is coming from. ST & TT RAM seem to pass fine.

[exxos]

It seems it's the "copy lower ram variables to alt-ram" thing is causing it all I went back to the build of MR18 without the lower ram variables enabled and the floppy is now behaving. I don't know why that suddenly started acting up. Maybe as it's got very hot in my room tonight

@agranlund Could you build me a MR19 with lower ram variables turned off ?

[exxos]

Doing more tests currently with TOS206. Floppy is basically malfunctioning with or without cache turned on while using MR19. If I go back to the build which does not copy lower RAM variables to fast-ram, floppy works fine again.

However, there seems to be a "new" problem which unfortunately seems to be intermittent. I'm trying to replicate it somehow. But I was seeing corruption while opening and closing the A: drive on desktop. I turned the cache off in the menu and the problem seemed to disappear. I enabled it again and the problem appeared again. I rebooted, and have not managed to replicate the problem since. But I have seen this odd corruption on and off for the past couple of days. I'm not sure where it is emanating from.

It seems to be a more recent development though I don't know if there is a bad connection on this board somewhere or not.I can port back to a earlier firmware but without being able to replicate when the first place I don't know if it is a hardware or firmware or software problem.

[agranlund]

It seems it's the "copy lower ram variables to alt-ram" thing is causing it all I went back to the build of MR18 without the lower ram variables enabled and the floppy is now behaving. I don't know why that suddenly started acting up. Maybe as it's got very hot in my room tonight

@agranlund Could you build me a MR19 with lower ram variables turned off ?

Based on your rather comprehensive tests, it sounds having HD11 loaded fixes it?
I have some theories but I would need to spend some time debugging in that case.
It could be the act of loading HD11. Or it could be the act of loading anything large enough and resident before maprom is..

For now you could try the quick modifications attached:

maprom_test.zip

(7.46 KiB) Downloaded 106 times

There's two folders. The ones in map0k disables ram relocation completely, and the ones in map4k will do just the first 4k.
I think the 4k one will probably work. It'll be quite useful to know if it doesn't

[exxos]

Based on your rather comprehensive tests, it sounds having HD11 loaded fixes it?

It does seem to in general yes. I don't understand why.

I have some theories but I would need to spend some time debugging in that case.
It could be the act of loading HD11. Or it could be the act of loading anything large enough and resident before maprom is..

Can HD11 "alter" any of the lower RAM variables which get reallocated somehow ?

For now you could try the quick modifications attached:
maprom_test.zip

There's two folders. The ones in map0k disables ram relocation completely, and the ones in map4k will do just the first 4k.
I think the 4k one will probably work. It'll be quite useful to know if it doesn't

I can certainly try the floppy problems. I did wonder about lowering the block to 4K aswell, but you beat me to it:)

Will report back shortly..

[Badwolf]

So this is VERY odd. If I boot from IDE (HD11) with or without MAPROM, I can access the floppy fine...
BUT, If I don't load HD11 from C:, no matter what I do, I cannot access the floppy.. it just shows corrupted contents.

Has this only started since your Blitter supporting mods to the firmware?

If so, perhaps check your new bus isolation logic is Blitter (or ROM) specific?

BW

[exxos]

Has this only started since your Blitter supporting mods to the firmware?

If so, perhaps check your new bus isolation logic is Blitter (or ROM) specific?

I thought that last night and I backtracked software several builds and the floppy problem is still there. But remember originally I had this problem anyway. But oddly seemed to "disappear" at some point. But it probably happened at the time I got IDE working.. So basically the problem was "unnoticed" not "resolved"..

MAPROM_C 4k - floppy contents are displaying correctly, albeit very slowly to come up, but the slowness seems to be related to the caches anyway.. So I'm not too worried about that particular problem.

I switched back-and-forth between MR19 and the corruption happens every time. Using your 4k version seems to work fine every time.

I have not tried the other versions you posted because not sure there is any point now ? basically looks like 8k is "to much".

I wonder if it is possible if HD11 Is commandeering some of that upper 4k block making it work properly again