REV 3 - REV 5 - The beginning (ST536)

[agranlund]

It does seem to in general yes. I don't understand why.
Can HD11 "alter" any of the lower RAM variables which get reallocated somehow ?

This is one of my theories also.
TOS has a 1024 byte buffer used for floppy things and this one must remain in st-ram (it's a different thing from the _FRB, which also must be in st-ram)
This buffer lives somewhere in the first 32kb region by default, so maprom attempts to find out where it is and ignores that page.

One theory is if this code is not functioning properly, and HD11 saves the day by either moving it, or simply makes it redundant due to how it replaces the low-level disk functions.
A very quick glance at the code reveals that it would be an issue if that buffer crosses the boundary of two pages, but there could certainly be other problems too.

Another theory is if maprom itself ends up partly in the lower 32k area. Especially if ran from auto.
Now, this should not be a problem in theory but maprom may need to either prevent this or make very sure that it doesn't become a problem..
Apart from itself, it does allocate an _FRB in st-ram. I would have thought the memory returned would be above 32k regardless but I'd need to double check and make sure this is always going to be the case..

[exxos]

@agranlund Not sure if you saw my results just https://www.exxosforum.co.uk/forum/viewt ... 560#p83743 did not realise I was replying to BW :lol:

Not sure if it would really help, but could the upper 4K block be simply reserved to shift things around ? I'm not sure there is any point as it would basically be the same as the 4K version you posted anyway.

I just booted from IDE again, just to confirm that MR19 does work with HD11 loaded still.

[agranlund]

Not sure if you saw my results just viewtopic.php?f=94&t=3992&start=560#p83743 did not realise I was replying to BW :lol:

Hehe, no I think that came while I was typing a reply to a previous post :D

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".

Great!
Then I'll make it 4k for all TOSs. At least for now.
It's the most important page anyway with all the interrupt related things :)

It would only do 32k for TOS206 anyway and it was fun when trying to get higher numbers in Gembench since a region of that size would include a bunch of VDI memory.
But if it breaks floppy I don't really think it's worth it :)

Someone could always go in later and see if that particular TOS206 optimisation can be fixed.
I'm not sure I am very interested in it, a majority of the TF related time was already spent on TOS206 specific things so I'm a bit fed up with that particular version :lol:

[agranlund]

I pushed the new maprom build + sourcecode to Github:
https://github.com/agranlund/tftools

Now does 4k ram relocation on all TOS versions.

[exxos]

Someone could always go in later and see if that particular TOS206 optimisation can be fixed.
I'm not sure I am very interested in it, a majority of the TF related time was already spent on TOS206 specific things so I'm a bit fed up with that particular version :lol:

Yeah know that feeling! what was you saying the other day about "Those people" been obsessed with TOS206 :lol:

The screen corruption I was talking about seems to consistently disappear when I turn off the desktop cache option. However if I disable the cache on the TF536 jumper, the floppy still malfunctions, but the screen corruption does not seem to be there. You would think the cache option in the menu would do the same as the physical jumper.. But it acts differently :shrug: So basically, even if you disable the cache on the board, is no guarantee that it will function correctly.

MR 4K Seems to solve the screen corruption problem :shrug: the floppy contents are not corrupted, but the cache in the menu needs to be turned off for the floppy to not run like a snail.

So if I have grabbed the correct image, this is MR19 (8K) vs 4K build now.

MR19.JPG

IMG_0491.JPG

Rather a drop! but I guess if people want maximum desktop performance then they should be using NVDI anyway I guess.

Testing FrontBench :
MR19 (8k) - 3156
MR19 (4k) - 3130

I need to check EMUTOS as well yet...

BTW have you tried TOS306 on the TF536 ?

I think the conclusion with TOS206, is you need to use the 4K MAPROM program, and turn off the caches on desktop when using the floppy drive (or DMA I guess as well).

[agranlund]

Rather a drop! but I guess if people want maximum desktop performance then they should be using NVDI anyway I guess.

Yeah, I was super uncomfortable with having it relocate 32k for any other computer than my own, but it appeared to work and the performance gain for VDI was just a bit too good to ignore :lol:
(Although as you already pointed out, installing NVDI makes these numbers seem incredibly tiny anyway..)

But without making some kind of configuration utility I think it's better to be safe than sorry.

BTW have you tried TOS306 on the TF536 ?

I remember trying TOS306 at some point and it did boot up fine, but I can't remember how exhaustive that test actually was and if I had any floppy or Ultrasatan attached..

I admit to being a bit obsessed with getting TOS206 working somewhat back then, mostly due to the homemade blitter addon in my ST.
Not that I was actually using it much, but you know, if it's there...
Hence Blitfix.prg was born as well :)

In practice though, nothing beats NVDI in fastram. It's on a different planet entirely and it really feels like you're getting a whole new machine.

[exxos]

I admit to being a bit obsessed with getting TOS206 working somewhat back then, mostly due to the homemade blitter addon in my ST.
Not that I was actually using it much, but you know, if it's there...
Hence Blitfix.prg was born as well :)

I did at some point managed to compile the PAK changes, and enable the caches etc in 206. But it did not seem to make any difference. I will see if I can find that ROM and retest. Though it was looking like simply enabling the cache stuff is not enough anyway.

I will see if I can load 306 with FASTROM thing next :)...Actually when did that vanish ?? :lol:

EDIT: oh TTRAM.TOS only works with 206 ? :(

[Steve]

@exxos Perhaps you could try ROMSPEED? https://github.com/uweseimet/atari_publ ... n/ROMSPEED
since it is designed for TT and 3.06.

[agranlund]

Maprom should work for TOS306 too provided you have it in rom.

It even works for Kaos TOS104.. was added mostly for curiosity rather than being useful.
(While 104 itself ends up in fastram, it still doesn't know how to allow applications to use that ram.
If someone needs an interesting, but probably a bit "pointless" project, I'm sure it would be possible but certainly not trivial to make maprom add the missing maddalt, mxalloc and pexec functionality to that tos version :) )

[exxos]

Maprom should work for TOS306 too provided you have it in rom.

It even works for Kaos TOS104.. was added mostly for curiosity rather than being useful.
(While 104 itself ends up in fastram, it still doesn't know how to allow applications to use that ram.
If someone needs an interesting, but probably a bit "pointless" project, I'm sure it would be possible but certainly not trivial to make maprom add the missing maddalt, mxalloc and pexec functionality to that tos version :) )

I'm trying to compile TOS206.. but with the PAK patches.. It seems to have compiled fine but in steem it locks up after the logo ( presumably because compiled for a 030 CPU but no idea). Using TTRAMTOS Locks up with just a bunch of vertical lines on the screen.

Obviously I want ideally some way of trying all this before before actually burning a ROM or 20 :)

EDIT:

OK booted up now.. Doesn't seem to be displaying the PAK logo even on boot.. odd..