*** M E M O R U M ***

Not sure why you need to use fp numbers?

Why not do a byte at a time and set the values as integers?
Martin’s suggested hex values are good test values, FFh=11111111b=255 etc
AA=10101010=170
55=01010101=85

As far as I can remember MTX BASIC doesn't have a true integer type so numeric arrays will allocate memory large enough for any sized value.

So, to test the memory allocated in the array you need to assign values which set/unset every bit in that storage class.

As for 1010101010 etc. unless you have data line issues this is pointless as each chip is only storing one bit of every byte and seeing as this is to test the chips themselves you may as well merely write 0x00 and 0xff to each address. Also, the march algorithm requires the zeros and ones to be written in the correct order to work.

But if you don't use arrays or variables, you should be able to POKE/PEEK individual memory locations.

A loop counter would likely use a variable, but the target address and data values needn't

0x55 and 0xAA are however useful to check if there are any cross connections between adjacent data bus lines

They are also useful for when you are testing 4 bit DRAM chips, or when testing SRAM chips...

I agree with Dave, if using BASIC, forget using an array, use POKE and PEEK instead. Just watch that you don’t overwrite any important system memory locations that are used by the system!

As DRAM chips only use a 7 or 8 bit address bus (16K bit and 64K bit devices), then testing A0 to A7 will check this bus. But will not fully test the multiplexing circuitry or the internal DRAM chip circuitry. But hey, it’s best to start with the easy sections first

Mark

Hmmm.. I wonder if I can find the address of the start of the array. I hate accessing unallocated memory. Blame my system programming background.

You might find this interesting

http://primrosebank.net/computers/mtx/t ... c_vars.htm

Dave wrote: ↑15 May 2019 17:38 You might find this interesting

http://primrosebank.net/computers/mtx/t ... c_vars.htm

Indeed, interesting. I'd still need to decode the address in assembler.

That document also hints that the numeric format for the MTX is indeed the same as the ZX81 & ZX Spectrum, being five bytes per value.

Looking on another page, the floating point value "-0.5" gets very close to being all ones, being 0x7fffffffff in this representation. I'm missing the topmost bit in every five bytes but also keeping things simple. This may be "good enough" for a quick test anyway.

I could try using "-1.0" to get all the bits set but there's a danger that the interpreter may coerce this into being the integer "-1" which would only set two of the bytes to 1s.

As suspected "-1.0" gets changed from a floating point to an integer.

I've been thinking (that's a dangerous concept in itself), as BASIC is rock solid on the machine and I can't get any memory test to fail at all whether the issue with the CTX is to do with the generation of the /GROM signal. If this is inconsistent could this cause the external ROM based programs to fail?

Unlikely, CFX does not use /GROM.