Wow. That is extreme. My 128MB test only takes a couple of minutes IIRC & my RAM is slower than Stephen's.
BW

Wow. That is extreme. My 128MB test only takes a couple of minutes IIRC & my RAM is slower than Stephen's.

Not sure I follow that...

Ah, OK I must have missed that that was hard coded -- the amount of memory tested per character on the screen is calculated, obviously.exxos wrote: 05 Dec 2022 18:56Not sure I follow that...
$20000 = 128 So kinda assume thats the block size the RAM test is using.
I guess if @frank.lukas As a EPROM I could just change at number and see if it makes any difference...
Hatari will try to apply patches to TOS versions it know about even with --patch-tos false set. You may need to change the version number to something it doesn't recognise.I cannot seem to get Hatari to play nice testing these TOS versions out :(

Yeah turn that off but did not help. I either get four bombs with 206, or with a TT and patched to 306, it gets to desktop but does not ever do any memory test :roll: Why cannot something just be simple for once :roll:Badwolf wrote: 05 Dec 2022 19:01 Hatari will try to apply patches to TOS versions it know about even with --patch-tos false set. You may need to change the version number to something it doesn't recognise.
I actively commented out the patching routines when doing my TOS4 hack.

/*
* TP_49: Fix memory size display
*
* The memory test at boot time could
* not correctly print values > 64MB
*/

Perhaps you misread me: you can't turn off all patching. Also IIRC memvalid/ramvalid are automatically set so you never get a RAM test.exxos wrote: 05 Dec 2022 19:09Yeah turn that off but did not help. I either get four bombs with 206, or with a TT and patched to 306, it gets to desktop but does not ever do any memory test :roll: Why cannot something just be simple for once :roll:Badwolf wrote: 05 Dec 2022 19:01 Hatari will try to apply patches to TOS versions it know about even with --patch-tos false set. You may need to change the version number to something it doesn't recognise.

Just tested the TOS4 TT-RAM test routine (normally never happens, obviously) in DFB1 -- 50s for 128MB@50MHz.Badwolf wrote: 05 Dec 2022 18:53Wow. That is extreme. My 128MB test only takes a couple of minutes IIRC & my RAM is slower than Stephen's.
BW

It must be running a different branch of the memory tests somewhere then :shrug:Badwolf wrote: 05 Dec 2022 19:28 Just tested the TOS4 TT-RAM test routine (normally never happens, obviously) in DFB1 -- 50s for 128MB@50MHz.


Thanks.. its possible cache could be a issue... There is some experimental stuff in the TOS code relating to that, but I didn't turn it on.stephen_usher wrote: 05 Dec 2022 19:43 Here are my results:Just to note that the ST RAM test is similarly slow. with the PAK/3 TOS3.06 ROM taking only ~8 seconds to test 4MB.
- ST536 TOS2.06 - 4 minutes 40 seconds.
- PAK/3 TOS3.06 - 23 seconds.
I wonder if the 2.06 test is using 16 bit words during the test and the 3.06 test is doing 32 bit for a start. Maybe it's also turning the cache on before the test so that the whole loop of the program stays in cache.
Code: Select all
/*
* TP_32: CACHE_0X0: Activate caches for all cpus >= 68020
*
* This patch is still experimental. Note also that with this patch active,
* you won't be able to activate/deactivate the blitter from the desktop
* when you have a cpu >= 68020.
*/
#ifndef TP_32
#define TP_32 0
#endifUsers browsing this forum: Baidu [Spider], ClaudeBot and 4 guests