Hi, I want to know if there is any software to do stress test on the RAM.
I'm searching for something that can test not only the internal, but at least to the 1mb (like in trump card) or even better if can test the 2mb or 4mb of GC/SGC.
I know of the Minerva test on boot, but I want a more stressful test for cases where Minerva consider valid.
There is any RAM tester, different from Minerva?
-
stephen_usher
- Super Gold Card
- Posts: 581
- Joined: Tue Mar 11, 2014 8:00 pm
- Location: Oxford, UK.
- Contact:
Re: There is any RAM tester, different from Minerva?
My diagnostic ROM can do this, at least for memory up to 768K. I don't know what the memory map above that looks like and whether there's a risk that the memory test code might hit I/O ports etc. and give false reports of bad RAM.
Re: There is any RAM tester, different from Minerva?
Various OSs test RAM slightly differently but in general:
Ram is tested in 16k blocks starting at $20000 and goes up (depending on OS) to $FC000, 1FC000 or FFC000 (*). Normally he first long word is written expecting to read the same thing, if it is the same, then the 16k block is further checked, and if the check passes, RAM is assumed taking up that 16k block.
Checking for RAM stops if reading a previously written value does not return the same value, and at that point it is assumed that the 'end of RAM' is reached. The OS normally assumes contiguous RAM so once a 16k block fails the RAM test, it stops checking for further 16k blocks.
It should be noted that it DOES check addresses above $C0000 where expansion peripherals should reside, however, peripherals should normally have ROM starting at the beginning of a 16k boundary (this is checked at every 16k boundary from $C0000 and up, unless a JM ROM is used, which has a bug and checks only $C0000) so writing the first long word of a 'peripheral' will attempt to write ROM (and fail) stopping the RAM detect process. If a 16k block is used up by a peripheral, any IO control registers used by peripheral expansion are normally at the end of the block of addresses, so no problem of upsetting some peripheral hardware during the RAM test.
There is also a caveat which deserves clarification:
Let's assume the usual 68008 CPU. The version used in the QL has 20 address lines, so a 1M address range, i.e. $00000 to $FFFFF. Internally, however, the address registers are 32-bit but since there are no external address pins on the 68008 for the higher address bits, any address $XXXYYYYY will appear as $YYYYY on the bus. So, in principle the RAM test should test for this, not to test the same addresses for RAM where the XXX portion of the address is different, because it might discover the same physical RAM more than once. This is handled 'automatically' - the OS relies on the OS ROM starting at $00000, so if the RAM test goes further than $FFFFF, say to $100000, it will actually address $00000, i.e. the contents of the ROM, so writing and reading back a test value will fail, and further testing for RAM will stop before address 'wraparound' occurs.
It should be noted that there is also a version of the 68008 in a different package that has 2 more address lines and consequently a 4M address range. I am not sure about JM but the JS ROM and Minerva certainly keep checking above $FC000, and will (on appropriate hardware) support more than 896k of RAM. That being said, there is a problem with the slave block table which uses a 16-bit offset for addressing and on JS using somewhere between 2 and 3M of RAM will crash the OS while initializing the slave block table, because the table will wrap around and start writing into the screen and then into the system variables. Minerva had that problem in early versions but it has been corrected and it will work with 3M of RAM without patching. Once the SGC is in the picture, with 4M of RAM, the OS needs patching, which is what the SGC ROM does during initialization.
Ram is tested in 16k blocks starting at $20000 and goes up (depending on OS) to $FC000, 1FC000 or FFC000 (*). Normally he first long word is written expecting to read the same thing, if it is the same, then the 16k block is further checked, and if the check passes, RAM is assumed taking up that 16k block.
Checking for RAM stops if reading a previously written value does not return the same value, and at that point it is assumed that the 'end of RAM' is reached. The OS normally assumes contiguous RAM so once a 16k block fails the RAM test, it stops checking for further 16k blocks.
It should be noted that it DOES check addresses above $C0000 where expansion peripherals should reside, however, peripherals should normally have ROM starting at the beginning of a 16k boundary (this is checked at every 16k boundary from $C0000 and up, unless a JM ROM is used, which has a bug and checks only $C0000) so writing the first long word of a 'peripheral' will attempt to write ROM (and fail) stopping the RAM detect process. If a 16k block is used up by a peripheral, any IO control registers used by peripheral expansion are normally at the end of the block of addresses, so no problem of upsetting some peripheral hardware during the RAM test.
There is also a caveat which deserves clarification:
Let's assume the usual 68008 CPU. The version used in the QL has 20 address lines, so a 1M address range, i.e. $00000 to $FFFFF. Internally, however, the address registers are 32-bit but since there are no external address pins on the 68008 for the higher address bits, any address $XXXYYYYY will appear as $YYYYY on the bus. So, in principle the RAM test should test for this, not to test the same addresses for RAM where the XXX portion of the address is different, because it might discover the same physical RAM more than once. This is handled 'automatically' - the OS relies on the OS ROM starting at $00000, so if the RAM test goes further than $FFFFF, say to $100000, it will actually address $00000, i.e. the contents of the ROM, so writing and reading back a test value will fail, and further testing for RAM will stop before address 'wraparound' occurs.
It should be noted that there is also a version of the 68008 in a different package that has 2 more address lines and consequently a 4M address range. I am not sure about JM but the JS ROM and Minerva certainly keep checking above $FC000, and will (on appropriate hardware) support more than 896k of RAM. That being said, there is a problem with the slave block table which uses a 16-bit offset for addressing and on JS using somewhere between 2 and 3M of RAM will crash the OS while initializing the slave block table, because the table will wrap around and start writing into the screen and then into the system variables. Minerva had that problem in early versions but it has been corrected and it will work with 3M of RAM without patching. Once the SGC is in the picture, with 4M of RAM, the OS needs patching, which is what the SGC ROM does during initialization.