Home » RBC Forums » General Discussion » Z80 memory count / check ideas
| Z80 memory count / check ideas [message #8822] |
Fri, 09 July 2021 15:19  |
comwarrior
Messages: 11
Registered: April 2019
|
Junior Member |
|
|
Good evening everybody.
First off, apologies for no progress on my Z80 build, the reason for this is that i had a blood clot and a heart attack back in febuary.
I'm ok-ish now so soon i'll be picking it back up again.
So, I'm upto the point of loading the first program into ram (all flat ram system) and i wanted to ask everyone on advice for a ram count and check. I'd thaught of reading the ram that 'could' be present at the address for each address line, then write to it and read it back to see if what was wrote has been stored. Does this sound like a good idea or could it have flaws?
Next would be a memory check. The supervisor uC will do a check and verify when it puts the first part of the kernel into ram but after that, the Z80 needs to do a memory check. What is the optimal way / test paturn to check the rest of the ram from the Z80 to catch and connection issues etc?
Looking for suggestions / ideas.
tia
CW
|
|
|
|
| Re: Z80 memory count / check ideas [message #8829 is a reply to message #8822] |
Sat, 10 July 2021 09:19  |
etchedpixels
Messages: 333
Registered: October 2015
|
Senior Member |
|
|
A lot depends on the chips being used and how it is wired and if you have aliasing with smaller RAMs
I normally run a test from 0-FF on address 0000 or FFFF (or wherever - FFFF is nice because if you've got an address bus error you won't notice yet). If you can cycle 00-FF then your data bus is good. You can then write to 1,2,4,8,16,32,64,128 etc and each time check that 00 wasn't effected in order to check the address pins are all working and not stuck/unconnected. Bridged ones need further patterns to write one address, test another. Same works if you have RAM high using FFFF FFFE FFFD etc (ie walking a 0 not a 1). If you have bridged pins then writing to that pin and that pin + the bridged one will usually give you the same address on the RAM so you'll see the fault.
If you are working with old DRAM parts then it's a lot more complicated, and the 4116 at least had a proper testing scheme (and you were supposed to test them all with a fancy test kit before putting them in product)
Alan
|
|
|
|
| Re: Z80 memory count / check ideas [message #8867 is a reply to message #8829] |
Mon, 19 July 2021 05:10 |
lynchaj
Messages: 1080
Registered: June 2016
|
Senior Member |
|
|
Hi
I've been very interested in a RAM test for the Z80 MBC and Z80 SBC for a while now. Things sort of came to a head recently when I started testing the Z80 MBC with the second 512KB SRAM chip installed. I had been using only the first SRAM chip and since it worked fine I had assumed everything was OK.
However things are a bit different with the second SRAM chip because none of the systems derived from the 2006 Z80 SBC design used 1024KB RAM total. This brought in some interesting considerations I needed to address but first was to determine if the Z80 RAM board actually worked with 1024KB RAM installed.
So fast forward a few weeks and I've been writing a simple RAM test utility for the Z80 MBC and hopefully will be extended to all the retrobrew type computers. I am not aware of any general purpose Z80 or CP/M type RAM test programs although if anyone knows of one or more please post here.
The RAM test program I am writing relies on the bank switching concept of 32KB lower pages. A typical Z80 MBC will have either 16 or 32 lower 32KB RAM pages available. Some however are special and reserved like page $0F is used for the upper 32KB RAM page even though it can also be used for a 32KB lower RAM page. Need use caution to avoid over-writing page $0F so that it doesn't blow away CP/M or the RAM test program itself.
My RAM test program is still in its infancy. The basic design is to leverage an older version of the dbgmon program and add a RAM test feature. This was done to re-use the handy utility functions available in dbgmon while also having a stand alone design not dependent on external libraries or other data dependencies.
The testing concept is pretty simple; write each memory location in the selected lower 32KB RAM page with a set of values and read them back to verify they work. Initially I picked $00, $FF, $55, and $AA for all on, all off, checkerboard, and inverse checkerboard patterns. Write the pattern to each memory location and read it back. If it is the same then assume the memory location is good and move to the next one until the whole page is covered.
Yes, I realize there are much more sophisticated RAM test schemes available but I was looking for something simple to implement and would catch the 99% percent of cases. I think the most obvious one is the RAM chip not installed which it definitely picks up. The second case would be the "walking wounded" part with some bad/dead RAM cells and it should catch most of those as well. The really subtle cases are left for future versions as needed.
It is probably too early to post a version of the RAM test for general public consumption but if you're interested in this topic please post in reply. I think the design I have now would certainly work on the Z80 MBC and any of the 2006 Z80 SBC derivatives which use the similar memory bank switching scheme of MPCLs. I suspect the Zetas and mini-SBC would work with little or no modification. I think it could be extended to the Omega MSX computers fairly easily. Ideally it would support all the RBC machines capable of running RomWBW which I think is achievable but it's not there yet.
Thanks, Andrew Lynch
[Updated on: Mon, 19 July 2021 05:14] Report message to a moderator |
|
|
|
| Re: Z80 memory count / check ideas [message #8868 is a reply to message #8822] |
Mon, 19 July 2021 05:20 |
lynchaj
Messages: 1080
Registered: June 2016
|
Senior Member |
|
|
comwarrior wrote on Fri, 09 July 2021 18:19Good evening everybody.
First off, apologies for no progress on my Z80 build, the reason for this is that i had a blood clot and a heart attack back in febuary.
I'm ok-ish now so soon i'll be picking it back up again.
Hope you're doing OK. Having some fairly serious health issues myself I can sympathize and genuinely hope the best for you. Stay active as possible and stick with the diet and meds like the doctors say. I am also on a strict regime and it helps keep all the other issues than come along with the condition at bay. It is quite an adjustment but stick with it and you can recover to a nearly normal life. But some things are gone for good (excessive salt, too much fluids, lack of exercise, poor diet, etc.)
Best wishes, Andrew Lynch
[Updated on: Mon, 19 July 2021 05:20] Report message to a moderator |
|
|
|
| Re: Z80 memory count / check ideas [message #8869 is a reply to message #8829] |
Mon, 19 July 2021 10:56 |
lynchaj
Messages: 1080
Registered: June 2016
|
Senior Member |
|
|
etchedpixels wrote on Sat, 10 July 2021 12:19A lot depends on the chips being used and how it is wired and if you have aliasing with smaller RAMs
I normally run a test from 0-FF on address 0000 or FFFF (or wherever - FFFF is nice because if you've got an address bus error you won't notice yet). If you can cycle 00-FF then your data bus is good.
Are you referring to addresses in the following?
Quote:
You can then write to 1,2,4,8,16,32,64,128 etc and each time check that 00 wasn't effected in order to check the address pins are all working and not stuck/unconnected. Bridged ones need further patterns to write one address, test another. Same works if you have RAM high using FFFF FFFE FFFD etc (ie walking a 0 not a 1). If you have bridged pins then writing to that pin and that pin + the bridged one will usually give you the same address on the RAM so you'll see the fault.
If you are working with old DRAM parts then it's a lot more complicated, and the 4116 at least had a proper testing scheme (and you were supposed to test them all with a fancy test kit before putting them in product)
Alan
I am thinking to add these tests to my RAM test to enhance detection. Sounds like two simple tests before starting the RAM test; one to verify the data bus is working and the second to verify the address bus is working.
Thanks, Andrew Lynch
[Updated on: Mon, 19 July 2021 11:55] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
| Re: Z80 memory count / check ideas [message #8874 is a reply to message #8829] |
Tue, 20 July 2021 03:32 |
lynchaj
Messages: 1080
Registered: June 2016
|
Senior Member |
|
|
etchedpixels wrote on Sat, 10 July 2021 12:19A lot depends on the chips being used and how it is wired and if you have aliasing with smaller RAMs
I normally run a test from 0-FF on address 0000 or FFFF (or wherever - FFFF is nice because if you've got an address bus error you won't notice yet). If you can cycle 00-FF then your data bus is good. You can then write to 1,2,4,8,16,32,64,128 etc and each time check that 00 wasn't effected in order to check the address pins are all working and not stuck/unconnected. Bridged ones need further patterns to write one address, test another. Same works if you have RAM high using FFFF FFFE FFFD etc (ie walking a 0 not a 1). If you have bridged pins then writing to that pin and that pin + the bridged one will usually give you the same address on the RAM so you'll see the fault.
If you are working with old DRAM parts then it's a lot more complicated, and the 4116 at least had a proper testing scheme (and you were supposed to test them all with a fancy test kit before putting them in product)
Alan
Hi, I implemented both the data bus and address bus tests at the beginning of my RAM test program. Both were pretty simple and seemed like a good precaution to take before starting the rest of the RAM test.
Thanks, Andrew Lynch
|
|
|
|
| Re: Z80 memory count / check ideas [message #8878 is a reply to message #8874] |
Wed, 21 July 2021 08:08 |
lynchaj
Messages: 1080
Registered: June 2016
|
Senior Member |
|
|
Hi
The RAM test program I've been working on is now ready for testing. It is meant for Z80 MBC or Z80 SBC running RomWBW. You can build on Windows using TASM and on Linux using uz80as. My try it out on your retrobrew computer and send me your feedback. It should work on any of the Z80 SBC derivative type RBC computers assuming you are using MPCLs and bank switching through RomWBW. Give it a try and post your feedback. Looking forward to seeing whatever you have. Note, the program does not include an "exit" function because the presumption is after you do RAM testing you'll want to exit via the reset button. The program wipes all RAM pages except $0F where itself and CP/M is running.
-
Attachment: ramtest.zip
(Size: 11.28KB, Downloaded 278 times)
[Updated on: Wed, 21 July 2021 08:10] Report message to a moderator |
|
|
|
| Re: Z80 memory count / check ideas [message #8882 is a reply to message #8822] |
Wed, 21 July 2021 11:28 |
jayindallas
Messages: 110
Registered: June 2021
|
Senior Member |
|
|
comwarrior previously wrote:
> ...I wanted to ask everyone on advice for a ram count and
> check. I'd thaught of reading the ram that 'could' be present
> at the address for each address line, then write to it and
> read it back to see if what was wrote has been stored. Does
> this sound like a good idea or could it have flaws?
> Next would be a memory check...
If you're trying to identify the ram blocks installed, among known configurations, then YES, your knowledge of possible configurations can make the determination easier. In addition, its quicker because you only need test one* byte in any ram block to discover that its installed. Once you have found all installed ram blocks, then you can have your next step, memory test, validate those known ram blocks for active use.
* You can test a few to be tolerant of a single byte ram failure; i.e. if first byte fails, test next one too... thus you can identify its installed but has a ram error.
When it comes to ram tests, everyone develops their favorite strategies. I start with a test pattern that is a function of each ram byte address, for example test.pattern = high.address + low.address. This will let you know that you have a ram block that answers to more than one ram block address.
This can happen in ram/rom when:
1) a socket might be installed for various sizes of a memory chip (example: 2KB, 4KB or 8KB chip can be installed, thus the socket chip select is mapped as a 8K block. When 2KB is installed, you get echo-images of ram in the unused 6KB.
2) in sparse designs where a small memory block might use a unused address decoder pin for a bigger block size than the ram block it is tied to. Again this leads to echo-images of ram that a function-of-address test.pattern can find. But when SSI/MSI logic chip were doing chip selection, this was a common and valid way to reduce chip count.
This function-of-address test.pattern detection is part of a solved-problem I call "Deceptively Mapped Memory". It doesn't seem likely to be in your project. "DMM" is something you'd use in discovering the configuration upon initialization, and it invalidates the echo-images because the test.pattern doesn't match the echo-images of ram's address... I just use it as a carry-over.
"DMM" is a topic for another day; more important in the 70s and 80s and maybe bus systems like S-100.
Just for those that see it, you paint all ram from high memory to low memory with a function-of-address test.pattern, then typically test results from low to high memory. That validates the lowest ram block and identifies or rejects the echo-images, depending upon how you wish to treat them.
[Updated on: Wed, 21 July 2021 12:57] Report message to a moderator |
|
|
|
| Re: Z80 memory count / check ideas [message #8889 is a reply to message #8822] |
Thu, 22 July 2021 09:42 |
jayindallas
Messages: 110
Registered: June 2021
|
Senior Member |
|
|
Andrew Lynch wrote:
> I am thinking to add these tests to my RAM test to
> enhance detection...and the second to verify the
address bus is working.
etchedpixels replied:
> Yes - the idea is you test for any combination where
> two bits are tied because a change on one address
> is visible on another.
When two address pins are tied together, it affects 4 INTENDED addresses {0.0, 0.1, 1.0, 1.1}. Note that the addresses might not be ADRx and ADRx+1; they could occur tied together whereever their traces pass close enough together to be bridged. Thus the two pins would be more accurately be ADRx and ADRx+y. In other words by example: ADR5 and ADR6 can be bridged, but so can ADR5 and ADR15 if the traces at some point neighbor each other and happen to be bridged.
The latter ADRx+y example as A15 encompasses more chaos as a high address bit, as it may affect address decoder results and the two cases become a RAM and a ROM. Now the ROM response to a Ram test might be further misleading. At some point the only way to figure it out is to pull out a probe.
Depending on pin drivers you're going to get different logic results. Its easy to imagine {0.0, 0.1, 1.0} becoming {0.0} and {1.1} remaining so. But chaotic results are possible.
But you'll end up with ram bytes that hold the test pattern for another address and that's something detectable with the DMM algorithm I mentioned previously.
DMM detects ram locations that have been accessed twice during a sweep of memory addresses. That could detect the scenario mentioned, though it could appear as a quite confusing result.
Just goes to show there is some diminishing return by testing for every ram error scenario imaginable.
[Updated on: Thu, 22 July 2021 17:18] Report message to a moderator |
|
|
|
| Re: Z80 memory count / check ideas [message #9067 is a reply to message #8868] |
Mon, 30 August 2021 13:38 |
comwarrior
Messages: 11
Registered: April 2019
|
Junior Member |
|
|
lynchaj wrote on Mon, 19 July 2021 05:20comwarrior wrote on Fri, 09 July 2021 18:19Good evening everybody.
First off, apologies for no progress on my Z80 build, the reason for this is that i had a blood clot and a heart attack back in febuary.
I'm ok-ish now so soon i'll be picking it back up again.
Hope you're doing OK. Having some fairly serious health issues myself I can sympathize and genuinely hope the best for you. Stay active as possible and stick with the diet and meds like the doctors say. I am also on a strict regime and it helps keep all the other issues than come along with the condition at bay. It is quite an adjustment but stick with it and you can recover to a nearly normal life. But some things are gone for good (excessive salt, too much fluids, lack of exercise, poor diet, etc.
Best wishes, Andrew Lynch
Thank you Andrew, much appreciated. The blood clot was caused by my gf loosing her balance and accidentally giving me a hard chest compression (perfect CPR technique if i was dead) on valentines day (I'll leave the graphical details to your imagination). Two blood clots left side of my heart 90 and 95% blockage. I almost joined the zipper club with a double bypass. Thankfully they agreed with me and put in two stents. The good thing is I'm now fitter than I've ever been except the side effects from the meds can get a little rough...
So, back my project...
I looked at making the base plane of my stack as a PCB, but at £50 just for one... erm no. I'm still building and modifying my CnC but won't be long before i can start trying to do my own PCB's. I needed something to help with the recovery of my right hand where they went in twice with angeo and majorly bruised all my tendons. My 3D printer has had a few custom upgrades too.
So, mem count and brief check, well primarily we want to see if memory is there. So, since my databus is pulled low as termination (thereby causing the Z80 to execute NOPs if there is nothing there) and static ram is 255 (FFs) at power-up a simple check if not 0 indicates there is something there.
The question is, where do we check? I'm not adverse to putting in bank switching at some point especially since the ram chip that i'm going to use is 128K and thus has 64K unused. I'm thinking, the lower 1K is checked by the supervisor so it makes sense to start at 1024 (A10) and count every 1k upwards.
So, we now have a count that 'something' is at memory locations... so then I'm thinking write 255 (FF's) and verify (if the ram is corrupt/warm boot) then all 0's, then a walking 1's and finally walking 0's test.
The question then becomes, do we check for bad wiring/memory at boot or leave that to a dedicated test program? I'm thinking we can skip this at boot and leave to a dedicated program.
What do you all think?
[Updated on: Mon, 30 August 2021 13:41] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
Current Time: Mon Mar 24 22:48:00 PDT 2025
Total time taken to generate the page: 0.03860 seconds
|
RetroBrew Computers Forum
Members
Search
Help
Login
Home
