Resurrecting an MTX500.

About original Memotech hardware.
User avatar
Dave
Posts: 1280
Joined: 11 Aug 2012 18:16
Contact:

Re: Resurrecting an MTX500.

Post by Dave »

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
stephen_usher
Posts: 325
Joined: 27 Nov 2016 19:58

Re: Resurrecting an MTX500.

Post by stephen_usher »

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.
User avatar
Dave
Posts: 1280
Joined: 11 Aug 2012 18:16
Contact:

Re: Resurrecting an MTX500.

Post by Dave »

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
User avatar
1024MAK
Posts: 757
Joined: 24 Dec 2012 03:01
Location: Looking forward to summer, in Somerset, UK

Re: Resurrecting an MTX500.

Post by 1024MAK »

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 :mrgreen:

Mark
:!: Standby alert :!:
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb :!:
Looking forward to summer in Somerset later in the year :D

Not as many MTXs as Dave! :lol:
stephen_usher
Posts: 325
Joined: 27 Nov 2016 19:58

Re: Resurrecting an MTX500.

Post by stephen_usher »

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. ;-)
stephen_usher
Posts: 325
Joined: 27 Nov 2016 19:58

Re: Resurrecting an MTX500.

Post by stephen_usher »

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.
stephen_usher
Posts: 325
Joined: 27 Nov 2016 19:58

Re: Resurrecting an MTX500.

Post by stephen_usher »

As suspected "-1.0" gets changed from a floating point to an integer.
stephen_usher
Posts: 325
Joined: 27 Nov 2016 19:58

Re: Resurrecting an MTX500.

Post by stephen_usher »

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?
User avatar
Dave
Posts: 1280
Joined: 11 Aug 2012 18:16
Contact:

Re: Resurrecting an MTX500.

Post by Dave »

Unlikely, CFX does not use /GROM.
Post Reply