exxos's Atari, Amiga & retro forum

PhilC wrote: 15 Jul 2020 22:02 what is it compared to a standard st? 605% cpu?

Stock STE.

Nice!! These numbers will improve dramatically when TOS is in fastram, and then go absolutely bonkers when you get NVDI installed as well :)

agranlund wrote: 16 Jul 2020 11:56 Nice!! These numbers will improve dramatically when TOS is in fastram, and then go absolutely bonkers when you get NVDI installed as well :)

I tried MAPROM again, same issues. So is that a fixable thing then ?

exxos wrote: 16 Jul 2020 18:32

agranlund wrote: 16 Jul 2020 11:56 Nice!! These numbers will improve dramatically when TOS is in fastram, and then go absolutely bonkers when you get NVDI installed as well :)

I tried MAPROM again, same issues. So is that a fixable thing then ?

Anything is fixable :lol:
I assume so but I haven’t investigated it any further. And to be honest I probably wont have time to do so in the next couple of weeks as I’m going away for vacation.

Not sure if the floppy is an issue on EmuTos+maprom also? else you could just use that instead of 206 in the meanwhile.
Or, if you get an IDE disk up and running and dont need floppy anymore (ive been using maprom in my auto folder with the 534 for a long time now and its been working fine on my floppy-less machine)

That older copy-206-to-ram-not-using-mmu program (ttramtos) did not work for you on the 536? (It may need a firmware fix to work, or rebuilt with a software workaround, but i am not 100% sure)

Another neat way of getting a speedy Tos without tricks is to build Emutos as a ram-loadable .PRG instead of a rom image. Specifying fastram size and location at compile time makes it extra speedy since it will be able to place internal variables in fastram as well (this is how Emutos for Vampire is built)
I did this for the 534 way back and that build is probably somewhere in a thread or on my website, but it’s an older Emutos by now and I built it for 4MB of course so it may not be very interesting for that reason (unless it detects the additional ram anyway, i dont know)
If noone else does it before me I’ll make another such Emutos build for the 536 when I get around to it - my ST and the 536 aren’t getting along yet and I’d want them to be friends first before making software I can’t test or use myself :)

A single application to map whatever is in rom to ram, be it Maprom or something else, is generally a lot more convenient and user friendly though, as long as it works that is :)

@agranlund my floppy doesn't work with EmuTOS so far but then not tried it without maprom running

PhilC wrote: 16 Jul 2020 20:25 @agranlund my floppy doesn't work with EmuTOS so far but then not tried it without maprom running

There are some older stuff here:
http://www.happydaze.se/tf534/

Here is an older RAM loadable EmuTos that knew about Fastram at compile time to make it extra fast (4MB at location at 0x01000000).
This probably means it will not detect anymore than that but interesting as an experiment if it works ok your machine anyway, especially if the floppy works (I assume it will, but just to make 100% sure it's maprom that is doing something wrong)

It's just a normal .PRG, stick it in the auto folder or run it as it is and it'll load itself to RAM and "reset" into it - just don't use maprom at the same time, there's really no need and it'll probably just cause conflicts :)

http://www.happydaze.se/wp-content/uplo ... 3x-prg.zip

agranlund wrote: 16 Jul 2020 20:21 That older copy-206-to-ram-not-using-mmu program (ttramtos) did not work for you on the 536? (It may need a firmware fix to work, or rebuilt with a software workaround, but i am not 100% sure)

It loads, but doesn't seem to do anything. No speed gain, so no idea whats going on there.

exxos wrote: 16 Jul 2020 20:39

agranlund wrote: 16 Jul 2020 20:21 That older copy-206-to-ram-not-using-mmu program (ttramtos) did not work for you on the 536? (It may need a firmware fix to work, or rebuilt with a software workaround, but i am not 100% sure)

It loads, but doesn't seem to do anything. No speed gain, so no idea whats going on there.

Weird, yeah I don't know then, it works here on the 534. It could very well be because of the memory size bug, it would end up loading it to the top of the ST-RAM if it detects 68MB from the TF536 (those non-existing 4MB at the top ends up in ST-RAM space).

That program is quite old though. I was basically P.Putniks open source "ramtos" program with these quick modifications:
- Loads the TOS image file to the top of TT-RAM instead of top of ST-RAM
- The second time the program is executed (by the TOS in RAM) it will do the maddalt and frb stuff to let it know about fastram.
(This is why it has to be launched from the auto folder. It needs to run once by the ROM tos and then again a second time by the RAM tos)
Oh, and you don't want to have any other fast-ram enabling programs running possibly conflicting with it..

It was an early attempt, but you quickly get tired of seeing two boot screens every time you start the machine. Hence I abandoned these things for maprom instead.

ah.. Did not realise it had to be run twice...

What I did just work out is running the TTRAM program you did in the auto folder, then running TTRAMTOS... that seems to load it, when it reboots I hold down control and alternate to skip loading it again to get to desktop..

So this is the GB6 results without blitter enabled, and this is now actually a lot faster as expected now!

Not sure why integer division has halved in speed then now... Could be a cache "issue".. Also alt-ram test has stopped working :shrug:


WITHOUT BLITTER




WITH BLITTER

exxos wrote: 16 Jul 2020 21:17 ah.. Did not realise it had to be run twice...

What I did just work out is running the TTRAM program you did in the auto folder, then running TTRAMTOS... that seems to load it, when it reboots I hold down control and alternate to skip loading it again to get to desktop..

So this is the GB6 results without blitter enabled, and this is now actually a lot faster as expected now!
Not sure why integer division has halved in speed then now... Could be a cache "issue".. Also alt-ram test has stopped working :shrug:

It's because it's running gembench in st-ram :)

You want it to load twice regardless, so try again not holding down ctrl when it reboots to TOS-in-ram.
Since it's starting TOS again fresh, it'll do it's usual init stuff and I figure whatever fastram you had installed in the "old" tos you launched from will not be known to the new tos)

Good call with using the ttram program first though.
The way it works (at first launch), if I remember correctly, is that it first asks the currently running tos if the TT-RAM top address is known (it will be if running emutos, and in your case as well since you ran the ttram program).
If the top address is already known then put TOS there and reset into it.
When the top address is not known, it probes the accelerator for the amount of memory, place TOS at top and reset into it.
Top address is then adjusted down so nothing overwrites where tos was loaded into.

(The probing of memory may or may not work with current TF536 firmware. EmuTOS gets it wrong, and I highly suspect my program will also get it wrong since I copied the principle from EmuTOS :lol: )

Try letting it run the auto folder again, if you're lucky then the ttram program and ttramtos will not conflict on the second start..
Else, try holding ctrl as you did, but run ttramtos manually once again.