Can't get the code tag to work but hey, nothing new :(
Basically, I need a Z80 routine that checks as much of the RAM as possible.
Soooo, if somebody can have a nose at the basic listing below and devise an assembler equivalent, I'd be very grateful.
I've set the org low in screen RAM, but lower would be better :)
The listing was written really quickly and so may not actually work as is, but there's enough there to give an idea of what's needed I hope :)
org = 17384
for a = 17384 to 65535 : set up loop1
let V=peek a : rem save original value
for b = 0 to 255 :rem setup loop2
poke a, b
if peek a <> b then print “Error at “; a :rem display error address, if found
next b
poke a,v :restore original value
org 16384
ent
DI
ld hl, 16384+27
L1 ld a, (hl)
ex af, af'
xor a
L2 ld (hl), a
cp (hl)
ex af, af'
ld (hl), a
ex af, af'
jr nz, END
inc a
jr nz, L2
inc l
jr nz, L1
inc h
jr nz, L1
END ld b, h
ld c, l
EI
ret
Use PRINT USR 16384 to invoke.
If it prints zero all is OK
If it prints any other number then that is the first fail address.
27 bytes. Got to be worth 75p.
It also needs to shift from it's current location and test that location.
Also could it recognise 128K, page in each RAM block and test them too.
And the logic of the test isn't quite right though it should bick up most errors. it won't pick up influence problems.
For example, if setting 40000 to 128 also sets 40001 to 128 the prog will never know it.
/edit
And there would be a bit of fiddling around the stack area if the MC is using it.
and I don't think it has to save and restore memory it should be ok for a reset after the test has reproted results.
I guess it should be ok if the sys variables get vaped too.
/edit
Ah, "influence problems" - could such a symptom of that be:
Machine will initialise, with the top of physical RAM (PRAMT) being set at 32768 in the sysvars. BASIC can peek and poke the addresses from 32768 all the way to 65535 with no errors (the basic version of the above listing takes about a day and a half to finish ) and found no errors. Ran continuously for a WEEK, still no errors (just a nice warm ikkle Speccy).
Not tested the code Geoff, but when you exchage the regesters, don't you lose the value of HL? When you get to L2, HL has been exchanged - fair enough, it preserves AF for restoring later. But, does HL' hold the same value as HL - or isn't HL affected by EX AF AF'
:) Now you see why I don't code anything myself :D
75p - is that the cost of a tube of Rolos and postage? :D
Not tested the code Geoff, but when you exchage the registers, don't you lose the value of HL?
:) Now you see why I don't code anything myself :D
75p - is that the cost of a tube of Rolos and postage? :D
No - EXX changes the three registers HL, DE, and BC
EX AF, AF' exchanges only the two accumulators and flag sets.
I went for brevity and not speed although it shouldn't take more than a second or two. The code is admittedly cryptic relying on the EX AF, AF' to bring back the original byte while preserving the test of the comparison for later.
You want Testing and Comments included in that price? :-)
No - EXX changes the three registers HL, DE, and BC
EX AF, AF' exchanges only the two accumulators and flag sets.
I went for brevity and not speed although it shouldn't take more than a second or two. The code is admittedly cryptic relying on the EX AF, AF' to bring back the original byte while preserving the test of the comparison for later.
I don't think you need to do that. The load after the compare won't affect the flags, so you could just save the original data in a spare register, such as e, and save a further few bytes:
org 16384
ent
DI
ld hl, 16384+24
L1 ld e, (hl)
xor a
L2 ld (hl), a
cp (hl)
ld (hl), e
jr nz, END
inc a
jr nz, L2
inc l
jr nz, L1
inc h
jr nz, L1
END ld b, h
ld c, l
EI
ret
Machine will initialise, with the top of physical RAM (PRAMT) being set at 32768 in the sysvars. BASIC can peek and poke the addresses from 32768 all the way to 65535 with no errors (the basic version of the above listing takes about a day and a half to finish ) and found no errors. Ran continuously for a WEEK, still no errors (just a nice warm ikkle Speccy).
Erm could be,
One of the things that can happen is that one memory address or one bit of a memory address can affect the contents of another memory address (or the same memory address) This could be because of proximity or dodgy signals on the address lines.
consider dodgy Ram chip A.
Setting memory address 32766 to 170 sets 32767 to 170 also (both bytes in the same ram chip) the program outlined above won't find anything wrong
consider dodgy circuit B.
Setting memory address 32767 to 170 sets the whole of upper memory to 170, again the proggy will find nothing wrong.
consider dodgy circuit C.
Setting memory address 32767 to 170 does not affect any other memory address and tests ok - so we write 170 to 32768 address but when the memory fetch goes off to get what is currently in memory address 32768 it actually reads 32767 (or more likely 32768 - 8k or 24576) which has already been set to 170 and so reads ok. So you could have dodgy lines on the address bus.
Does that make sense? We are talking 20+ year old chips and circuits AND a 40ish brain which has been somewhat abused over the years.
OK these are obscure faults, but it is an obscure fault if you only suspect dodgy memory and can't pin it down.
Hang on what the fek are you listening to me for? Google to the rescue (again
Right, so I'll go with Geoff's pogram and send it around that for a few hours. Then, if it all tests ok I'll email the owner and tell him it's a 16K machine only and point him here so he knows what's gone on.
Lovely though she is, she's ony a Spectrum - she'll never grow up into a 48K machine, but we'll love her just the same, no matter what. (sniff)
Guys, seriously now, thats for all your help - you never know, one day I may be able to help you.
Matt's program is best - I'd over-egged it a bit. :-)
And I am going to spend some time with dekh's links.
Of course I've completely misinterpreted the program.
However: If the fault is in the address bus such that it keeps going to the same Ram chip when a fetch or write is called when it should be going to an upper memory chip the program won't pick up the problem.
Perhaps starting from 16384 (yes yes + 27)
if the loops inc H first then write a and test then inc a then inc H, until H = 0 then inc L from 0 to 255
The tested memory would follow this sequence and with these values:
16384 - 0
16640 - 1
16896 - 2 etc
then
16385 - 0
16641 - 1
16897 - 2 etc
Then the values tested across the chips don't match...
The test should of course be restarted 256 times increasing the start number in A each time.
16384 - 0
16384 - 1
16384 - 2
16384 - 3
etc...
The logic here is simplified to ignore the first few bytes where the code is living.
And if the address bus is always going to the same RAM chip ........
HMMMM .... it would probably be wise to write 0 to all memory and the beginning of each sequence and test that it is 0 before writing to it. That would pick up a few probs.
How difficult to replace the Speccy Rom with an EPROM? There's voltage and pin probs no doubt...
These days, use flash - don't bother with eprom. You can replace the ROM by making an external board that connects to the edge connector, and nails ROMCS high just like ZX Interface 2, so that the on-board ROM never gets selected. Simple decoding logic selects your ROM when addresses <0x4000 are requested (basically, when A14, A15 and MREQ is low - a single 3 input OR gate can do this).
The way the physical memory on the 48K Speccy (at least, up to issue 4 - I don't know if it changed after that) is laid out is the chips are actually 1 bit chips, not 8 bit. So 8 of them are ganged together - so every single memory location is stored in 8 chips (each chip holding one bit of the byte). So if setting a location in one chip causes an in-error adjacent location set, what you might see is this:
Set all of memory to zero. Then:
set location 0x8000 to 0xAA (binary 10101010)
in error, you find location 0x8001 - which should still be zero, is 00001000 - because the chip holding bit 3 is the faulty one.
But if you set 0x8000 to 0x55 (binary 01010101) you wouldn't even see that fault, because bit 3 of 0x8000 is 0, and therefore, bit 3 of 0x8001 will also be 0.
If you know which bit is faulty, you know which chip is faulty too - if you find bit 3 is faulty, look in the schematic for the chip whose output is on the CPU's D3.
As for the faulty address bus - the basic decision by the logic is - is A15 low or high? If A15 is high, then select the 8 chips that provide upper 32K memory. If A15 is low and A14 is high, then chip select all 8 of the 4116 RAMs that make up the lower 16K of RAM (and, if both A15 and A14 are low, go for ROM). Therefore, it's quite likely that a fault with A15 such that you can still access the lower 16K, you will never be able to access the upper 32K at all because the fault must be that A15 never goes high. Or other weirdness is occuring where A15 intermittently fails to go high. Fault finding is so much fun :-)
Well see if you can play this (to the tune of "The Devil went down to Georgia")
Go download it, you won't be sorry :)
The devil went to Jamaica
He was looking to sell some weed
He was doin' fine
They were standin' in line
It was excellent weed indeed
When he came across a young man
Who was likewise peddling pot
And the devil slid down the beach to the kid
And said boy let me tell you what
I guess you kind of figured
I'm a reefer head of course
And after all this time
I guess that I'm a conniseur of sorts
Now your stuff smells okay
But this could tranquilize a horse
I'll bet a million in cash against your stash
Cause I think mines better than yours
The boy said my names Johnny
And you ain't smoked nothing yet
One hit of this grass will kick your a@@
You got yourself a bet
Johnny roll a ball of hash
And make sure it's the bomb
Cause the devils got the kind of stuff they smoked in Vietnam
You'll get a million smack-a-roo's in cash if you can cope
But if you can't the devil gets your dope
The devil packed a bong
With a little Acapulco Gold
And resin flew from his finger tips
As he fired up his bowl
He filled that chamber all the way
And he took a mighty hit
And as they passed it back and forth
It gave them both a coughing fit
(coughing)
When the bowl was finished Johnny said
Hey man, that stuff was great
But fill your lungs with some of this
And prepare to vegetate
Cannibis Sativa, Sweet Maryjane
The devils in the backyard frying his brain
Zig-Zag filled with the diggity-dank
Hold on tight it will hit you like a tank
The devil nodded off
Because he knew that he was stoned
And he asked if he could by an ounce
Of the stuff that Johnny owned
Johnny said, Devil just come on back
If you ever wanna catch a buzz
I done told you once
You son of a bi$^h
Mine's the best there ever was
And they fired up doobies one by one
Ain't gonna stop until the bag is done
Green as a bullfrog
Sticky as glue
Granny do you get high, yes I do
Brilliant. I recognize topic drift when I see it and, since he's been mentioned already, this 2003 song from Weird Al parodying Bob Dylan's 1965 video outside the Savoy Hotel, London takes the prize http://youtube.com/watch?v=Nej4xJe4Tdg
Every line reads the same backwards. It would take me a Spectrum with 8 microdrives, 1000 monkeys and a million years to come up with something like that.
Brilliant. I recognize topic drift when I see it and, since he's been mentioned already, this 2003 song from Weird Al parodying Bob Dylan's 1965 video outside the Savoy Hotel, London takes the prize http://youtube.com/watch?v=Nej4xJe4Tdg
Every line reads the same backwards. It would take me a Spectrum with 8 microdrives, 1000 monkeys and a million years to come up with something like that.
Flippin' heck Geoff! I have this Weird Al video on DVD and I never spotted the palindrome on this video! I just thought it was Weird but now you've given me the insight that it is genius!
Get those Microdrives humming, boy!
PS: Sorry for the topic drift. I wish I'd spotted it earlier and put in my M/C suggestion.
PPS: Check out another Weird Al video I'm too white and nerdyhere. I wonder how many of us this applies to!?!?!
Comments
Can't get the code tag to work but hey, nothing new :(
Basically, I need a Z80 routine that checks as much of the RAM as possible.
Soooo, if somebody can have a nose at the basic listing below and devise an assembler equivalent, I'd be very grateful.
I've set the org low in screen RAM, but lower would be better :)
The listing was written really quickly and so may not actually work as is, but there's enough there to give an idea of what's needed I hope :)
I clicked "submit" rather than "preview post". Of course, it was meaningless crap at the time :D
It also needs to shift from it's current location and test that location.
Also could it recognise 128K, page in each RAM block and test them too.
And the logic of the test isn't quite right though it should bick up most errors. it won't pick up influence problems.
For example, if setting 40000 to 128 also sets 40001 to 128 the prog will never know it.
/edit
And there would be a bit of fiddling around the stack area if the MC is using it.
and I don't think it has to save and restore memory it should be ok for a reset after the test has reproted results.
I guess it should be ok if the sys variables get vaped too.
/edit
org 16384 ent DI ld hl, 16384+27 L1 ld a, (hl) ex af, af' xor a L2 ld (hl), a cp (hl) ex af, af' ld (hl), a ex af, af' jr nz, END inc a jr nz, L2 inc l jr nz, L1 inc h jr nz, L1 END ld b, h ld c, l EI retUse PRINT USR 16384 to invoke.If it prints zero all is OK
If it prints any other number then that is the first fail address.
27 bytes. Got to be worth 75p.
Ah, "influence problems" - could such a symptom of that be:
Machine will initialise, with the top of physical RAM (PRAMT) being set at 32768 in the sysvars. BASIC can peek and poke the addresses from 32768 all the way to 65535 with no errors (the basic version of the above listing takes about a day and a half to finish ) and found no errors. Ran continuously for a WEEK, still no errors (just a nice warm ikkle Speccy).
Not tested the code Geoff, but when you exchage the regesters, don't you lose the value of HL? When you get to L2, HL has been exchanged - fair enough, it preserves AF for restoring later. But, does HL' hold the same value as HL - or isn't HL affected by EX AF AF'
:) Now you see why I don't code anything myself :D
75p - is that the cost of a tube of Rolos and postage? :D
HL, DE, BC are unaffected.
If you want to swap HL with its shadow, the 'exx' instruction does that. You can also switch HL and DE with 'ex de, hl'.
No - EXX changes the three registers HL, DE, and BC
EX AF, AF' exchanges only the two accumulators and flag sets.
I went for brevity and not speed although it shouldn't take more than a second or two. The code is admittedly cryptic relying on the EX AF, AF' to bring back the original byte while preserving the test of the comparison for later.
You want Testing and Comments included in that price? :-)
I don't think you need to do that. The load after the compare won't affect the flags, so you could just save the original data in a spare register, such as e, and save a further few bytes:
org 16384 ent DI ld hl, 16384+24 L1 ld e, (hl) xor a L2 ld (hl), a cp (hl) ld (hl), e jr nz, END inc a jr nz, L2 inc l jr nz, L1 inc h jr nz, L1 END ld b, h ld c, l EI retErm could be,
One of the things that can happen is that one memory address or one bit of a memory address can affect the contents of another memory address (or the same memory address) This could be because of proximity or dodgy signals on the address lines.
consider dodgy Ram chip A.
Setting memory address 32766 to 170 sets 32767 to 170 also (both bytes in the same ram chip) the program outlined above won't find anything wrong
consider dodgy circuit B.
Setting memory address 32767 to 170 sets the whole of upper memory to 170, again the proggy will find nothing wrong.
consider dodgy circuit C.
Setting memory address 32767 to 170 does not affect any other memory address and tests ok - so we write 170 to 32768 address but when the memory fetch goes off to get what is currently in memory address 32768 it actually reads 32767 (or more likely 32768 - 8k or 24576) which has already been set to 170 and so reads ok. So you could have dodgy lines on the address bus.
Does that make sense? We are talking 20+ year old chips and circuits AND a 40ish brain which has been somewhat abused over the years.
OK these are obscure faults, but it is an obscure fault if you only suspect dodgy memory and can't pin it down.
Hang on what the fek are you listening to me for? Google to the rescue (again
http://www.netrino.com/Articles/MemoryTesting/index.php
and here is an answer beyond my humble capacity to understand...
http://etrij.etri.re.kr/Cyber/servlet/BrowseAbstract?paperid=SC0402-0007
I knew that, honest guv :redface:
Lovely though she is, she's ony a Spectrum - she'll never grow up into a 48K machine, but we'll love her just the same, no matter what. (sniff)
Guys, seriously now, thats for all your help - you never know, one day I may be able to help you.
And I am going to spend some time with dekh's links.
Cheers once again guys, much appreciated :)
Of course I've completely misinterpreted the program.
However: If the fault is in the address bus such that it keeps going to the same Ram chip when a fetch or write is called when it should be going to an upper memory chip the program won't pick up the problem.
Perhaps starting from 16384 (yes yes + 27)
if the loops inc H first then write a and test then inc a then inc H, until H = 0 then inc L from 0 to 255
The tested memory would follow this sequence and with these values:
16384 - 0
16640 - 1
16896 - 2 etc
then
16385 - 0
16641 - 1
16897 - 2 etc
Then the values tested across the chips don't match...
The test should of course be restarted 256 times increasing the start number in A each time.
16384 - 0
16384 - 1
16384 - 2
16384 - 3
etc...
The logic here is simplified to ignore the first few bytes where the code is living.
And if the address bus is always going to the same RAM chip ........
HMMMM .... it would probably be wise to write 0 to all memory and the beginning of each sequence and test that it is 0 before writing to it. That would pick up a few probs.
How difficult to replace the Speccy Rom with an EPROM? There's voltage and pin probs no doubt...
The way the physical memory on the 48K Speccy (at least, up to issue 4 - I don't know if it changed after that) is laid out is the chips are actually 1 bit chips, not 8 bit. So 8 of them are ganged together - so every single memory location is stored in 8 chips (each chip holding one bit of the byte). So if setting a location in one chip causes an in-error adjacent location set, what you might see is this:
Set all of memory to zero. Then:
set location 0x8000 to 0xAA (binary 10101010)
in error, you find location 0x8001 - which should still be zero, is 00001000 - because the chip holding bit 3 is the faulty one.
But if you set 0x8000 to 0x55 (binary 01010101) you wouldn't even see that fault, because bit 3 of 0x8000 is 0, and therefore, bit 3 of 0x8001 will also be 0.
If you know which bit is faulty, you know which chip is faulty too - if you find bit 3 is faulty, look in the schematic for the chip whose output is on the CPU's D3.
As for the faulty address bus - the basic decision by the logic is - is A15 low or high? If A15 is high, then select the 8 chips that provide upper 32K memory. If A15 is low and A14 is high, then chip select all 8 of the 4116 RAMs that make up the lower 16K of RAM (and, if both A15 and A14 are low, go for ROM). Therefore, it's quite likely that a fault with A15 such that you can still access the lower 16K, you will never be able to access the upper 32K at all because the fault must be that A15 never goes high. Or other weirdness is occuring where A15 intermittently fails to go high. Fault finding is so much fun :-)
Do carry on.
Skarpo
:-?
You've been missed dude, glad to see you back :)
Thank you Death ... I shall try to avoid you though ;-)
Skarpo- "Death? An OK bloke if I ever sawr one."
:-)
(best Southern USA drawl) Wah thank eeeyou misser Skarpo sirrr!
well ... seeing as you are getting your musical instrument!
Oh, we're in Georgia now ... right?
Skarpo- "Fiddledeedoo!"
:-)
Well see if you can play this (to the tune of "The Devil went down to Georgia")
Go download it, you won't be sorry :)
The devil went to Jamaica
He was looking to sell some weed
He was doin' fine
They were standin' in line
It was excellent weed indeed
When he came across a young man
Who was likewise peddling pot
And the devil slid down the beach to the kid
And said boy let me tell you what
I guess you kind of figured
I'm a reefer head of course
And after all this time
I guess that I'm a conniseur of sorts
Now your stuff smells okay
But this could tranquilize a horse
I'll bet a million in cash against your stash
Cause I think mines better than yours
The boy said my names Johnny
And you ain't smoked nothing yet
One hit of this grass will kick your a@@
You got yourself a bet
Johnny roll a ball of hash
And make sure it's the bomb
Cause the devils got the kind of stuff they smoked in Vietnam
You'll get a million smack-a-roo's in cash if you can cope
But if you can't the devil gets your dope
The devil packed a bong
With a little Acapulco Gold
And resin flew from his finger tips
As he fired up his bowl
He filled that chamber all the way
And he took a mighty hit
And as they passed it back and forth
It gave them both a coughing fit
(coughing)
When the bowl was finished Johnny said
Hey man, that stuff was great
But fill your lungs with some of this
And prepare to vegetate
Cannibis Sativa, Sweet Maryjane
The devils in the backyard frying his brain
Zig-Zag filled with the diggity-dank
Hold on tight it will hit you like a tank
The devil nodded off
Because he knew that he was stoned
And he asked if he could by an ounce
Of the stuff that Johnny owned
Johnny said, Devil just come on back
If you ever wanna catch a buzz
I done told you once
You son of a bi$^h
Mine's the best there ever was
And they fired up doobies one by one
Ain't gonna stop until the bag is done
Green as a bullfrog
Sticky as glue
Granny do you get high, yes I do
That's great ... you mean there's also an actual "parody" song MP3 out there?
Skarpo
:-)
http://www.alioth.net/tmp/crs.mp3
The Colorectal Surgeon's Song!
http://youtube.com/watch?v=Nej4xJe4Tdg
Every line reads the same backwards. It would take me a Spectrum with 8 microdrives, 1000 monkeys and a million years to come up with something like that.
Flippin' heck Geoff! I have this Weird Al video on DVD and I never spotted the palindrome on this video! I just thought it was Weird but now you've given me the insight that it is genius!
Get those Microdrives humming, boy!
PS: Sorry for the topic drift. I wish I'd spotted it earlier and put in my M/C suggestion.
PPS: Check out another Weird Al video I'm too white and nerdy here. I wonder how many of us this applies to!?!?!