Shoestring's Atari 8bit RAM tester

[shoestring]

Been working on this a little tonight. I don't think my changes will have any effect when flashed and run from the Syschecker board. If anyone is interested in helping out and testing a bunch of different versions so I can narrow down the issue, then feel free to send me a private message.

 

You can see it runs happily in my XE.

My Movie.mp4

 

My goal is to get something legible on the screen even without the memory.

After making some changes to the code. I removed both 4464s from the motherboard and this was the result after powering on.

 

 

 

 

[+Nezgar]

OK so i made a new Sys-Check flash replacing $10000-$13FFF and $14000-$17FFF regions (Firmware 3+Repeat) with a8diag1-2.rom.

Selecting 3rd OS on Sys-Check doesn't work Just coloured Green or Brown screen. The other 3 selectable OS's continue to work.

I programmed the same 16KB file to a 27C128 and it works just fine when replacing the OS ROM on the system board in a stock 800XL.

Some other combinations...
With a8diag1-2 27C128 EPROM in the 800XL ROM socket, and Sys-Check D it works with Sys-Check DIP 3_1 on the mode block is set to OFF (64KB of main memory on Atari PCB is used), and DIP 3_2 set to OFF (OS on Atari PCB is used). If the 64KB is provided by Sys-Check, only a blank screen results.

Oh wait here....
With Sys-Check set to:
DIP 3_1 on the mode block is set to OFF (64KB of main memory on Atari PCB is used)
DIP 3_2 set to OFF (OS on Atari PCB is used)
and Sys-Check OS set to #3 programmed with a8diag1-2.rom and Atari PCB OS socket ALSO containing 27C178 programmed with a8diag1-2.rom it works!
With SysCheck OS set to #3 programmed with a8diag1-2.rom and Atari PCB OS socket containing stock OS ROM it does NOT work.

Maybe the $D406 register used by Sys-Check for bank switching is at play here, Sys-Check modes getting changed by writes to it?
From page 9 of the Sys-Check Manual:

Bit 0: When 0, then the SRAM on Sys-Check´s PCB is active. When 1, then the RAM on the XL/XE mainboard will be accessed
Bit 1: When 0, then the ROM or EPROM on Sys-Check´s PCB is selected, otherwise the ROM or EPROM located on the XL/XE mainboard.
Bit 2: Address line A14 to Sys-Check´s ROM/EPROM socket (see below)
Bits 3...7: Reserved - no function at this time

[+Nezgar]

Hmm re-reading that, I have to re-check if OS #3 works when DIP 3_2 set to ON (OS on sys-check) with main PCB OS also with a8diag1-2.rom - I think that worked.

 

Edit: yes it does. With DIP 3_2 in either mode, but only if onboard OS matches the Sys-check boards OS.

[shoestring]

Nice troubleshooting. So are you saying that it only works if the internal ram of the computer is used ?

[+Nezgar]

No, I think your tester is making sys-check disable the external OS, and switching back to the on-board OS ROM.

 

For example, when the system powers up using the OS from the Sys-Check, bit 1 of $D406 is 0. If a8diag1-2 writes a 1 into bit 1, the OS region is switched to the on-board OS, resulting in a crash if it is a different OS. By me making sure BOTH the external and on-board OS's are the same, it keeps working.

 

I did a simple test in BASIC... ?PEEK(54278) always returns 255, so it appears to be a write-only register.

 

With a8diag1-2 in the on-board OS socket, and stock Atari OS selected on Sys-Check, DIP DIP 3_2 set to ON (use OS on sys-check with Stock Atari OS). I enter POKE 54278,2 (Changes bit 2 to 1, switching OS from Sys-Check to on-board) and i see the Gr.0 character set change to garbage (indicating chbas pointer now points to non-charset data) and the system is locked (indicating previous OS is no longer present)

 

Maybe easy fix is to not write to $D406? (Maybe could cause issues with other things in the I/O area $D000-$D7FF too) I believe Atari OS only writes zeros to the I/O area on OS initialization, but this tester seems to be writing 1's.

 

One other minor observation.. my 800XL PCB RAM Layout is in this order, top to bottom:

U9 U10 U11 U12 U16 U15 U14 U13 - but the tester currently lists them sequentially. It might be nice to have the on-screen order match the PCB

[+Nezgar]

I'm not an expert, but a bit of reading I found some supporting text about the I/O Registers area...

 

https://www.atarimagazines.com/compute/issue77/insight_atari.php

"...it turns out that, even if we disable the OS ROMs in order to access the extra RAM, there is no way to disable the hardware I/O space (which occupies addresses $D000 through $D7FF). There simply is no RAM in these 2K. Period. So we are down to 14K of hard-to-use RAM with a nasty hole in the middle of it."

 

in the first post, you state one step the tester takes is: "Turns the OS ROM off then tests the DRAM 0xc000 - 0xFFFF."

So.. i guess this should be revised to "Turns the OS ROM off then tests the DRAM 0xc000 - cFFF, d800 - 0xFFFF."

[shoestring]

in the first post, you state one step the tester takes is: "Turns the OS ROM off then tests the DRAM 0xc000 - 0xFFFF."

So.. i guess this should be revised to "Turns the OS ROM off then tests the DRAM 0xc000 - cFFF, d800 - 0xFFFF."

 

Perhaps I am misunderstanding your post but it doesn't do this straight away though, I check the bottom of the ram first. So I'd expect it to run for a few minutes before crashing.

 

1.First of all it evaluates the first 2kb 0x0 - 0x7ff. ( I do not stop at the first error found, every potential bad data bit is evaluated against the expected value via a simple XOR and iterated over.)

2.Calculates a checksum of the BASIC ROM and stores the result in zero page.

3.Turns off BASIC

4.Performs evaluation of 0x800-0bfff using the same checks.

5.Copies a large chunk of the ROM to RAM starting at offset 0x900.

6.Turns off OS rom.

7.Tests the remainder of the memory 0xc000 - 0xffff

 

Edit:

 

I don't think I write to D406 at all and I definitely skip the I/O area $D000-$D7FF when writing to memory. But I'll have another look when I get home this afternoon/

[shoestring]

Just looking over this code now. I'm definitely skipping this range when evaluating memory between 0xC000 - 0xFFFF.

 

LDA $1

CMP #$D0

BEQ SKIPD0

JMP NOSKIP

SKIPD0

LDA #$D8

STA $1

NOSKIP

....

 

 

 

However I think on to something here, I spot a bug where I am comparing X instead of Y in my loop. I don't have time to test yet but I'm attaching 1.3 for you to flash and take a look. I'll have a closer look tonight when I get back later on.

 

LDA #0 ; INIT STA $D303

TAY

LI1

STA $D000,Y

STA $D200,Y

STA $D400,Y

CPX #low PORTB

BEQ LI1

....

 

 

One other minor observation.. my 800XL PCB RAM Layout is in this order, top to bottom:

U9 U10 U11 U12 U16 U15 U14 U13 - but the tester currently lists them sequentially. It might be nice to have the on-screen order match the PCB

 

 

I used the order based on this schematic and others.

 

https://www.atarimax.com/jindroush.atari.org/data/ahard/xlwiring.gif

a8diag1-3.rom

Edited August 30, 2018 by shoestring

[+tf_hh]

I used the order based on this schematic and others.

 

https://www.atarimax.com/jindroush.atari.org/data/ahard/xlwiring.gif

 

The order in the schematics is not the same like on the mainboards. Look into the Sys-Check manual, there´s a picture of the different mainboard variants with the correct order.

[shoestring]

I'm not even sure why the order even matters in any case.

 

As long as the IC is mapped top the correct data bit when a bad one is identified.

 

For the 800XL

 

U9 = D0 , U10 = D1, U11 = D2, U12 = D3, U13 = D4, U14 = D5, U15 = D6, U16 = D7

 

In the 800XLs case, I order them based on the data bits, not so much the layout of the motherboard.

 

Obviously it's slightly different for XLF.

 

Edited August 30, 2018 by shoestring

[+Nezgar]

The user of the program will be only concerned with where the chip is in the real world. EG.. If its the bottom chip (U9) flagged in the program, the user may instinctively look at the bottom chip on their 800XL mainboard, but that is actually U13.

 

I'll give 1.3 a try this evening. 16 hour time zone difference between our evenings.

[atarixegs]

a8diag1-3 on syscheck in set #3, Atari 65xe board, 8x4864

 

+U9 means that only the chip number 9 is present on the board, etc

 

In all following cases the program stopped at the stage visible in the picture without any sounds.

 

With all chips present in sockets test is positively completed.

 

 

[shoestring]

 

 

The user of the program will be only concerned with where the chip is in the real world.

 

I'll get that fixed, it's really trivial change.

 

 

 

In all following cases the program stopped at the stage visible in the picture without any sounds.

 

Thanks for this.

 

I suspect it's going to bomb out with unpredictable results when any of the 8 ram chips are missing & the cpu uses the stack page ( $0100-$01FF ). The custom DLI procedure and NMI routine relies on the stack instructions ( RTI, PLA ..etc ) so I'll need to find a way around that if I can.

[E474]

Hi,

 

Is there any chance of this being extended to check the extra 64K in a stock 130XE?

 

Also, is this up and running in a Sys-Check - I haven't tried updating mine with the flash-tool yet, but would like to give it a go, and would like to also try and flash one of the omnimon type ROMs, for debugging though I'm not sure exactly which one would be best?

[shoestring]

Not in this version right now, I know I could easily squeeze in another column by shifting the text to the left and combining 4 x player missiles. I'm looking to add a 600xl column for people with upgraded machines.

 

Keeping it simple for now until I sort out some issues but who knows. I could release source code once I'm done and people could do their own variations.

 

I'm not ruling out an exclusive 128kb XE version in the future but I'll need to upgrade my 65XE to 128kb configuration first. Shouldn't be too difficult with the 130xe motherboard under the hood.

Edited August 30, 2018 by shoestring

[E474]

Wouldn't it be simpler to mark bad ram chips in inverse video? Also, I think there are 2 130XE configurations, one with 16 ram chips, and one with 4 (iirc). Also, if a system has 128k RAM, you don't need to display the chip positions for the 800's.

[shoestring]

Yes, probably. It doesn't have to look great. All solutions are on the table.

 

130s should probably have their own version. The 16 DRAM config could be represented in 2 columns.

[_The Doctor__]

I like where this is going because on a messed up machine you never know what it could identify as, showing them all works for me

[+Nezgar]

However I think on to something here, I spot a bug where I am comparing X instead of Y in my loop. I don't have time to test yet but I'm attaching 1.3 for you to flash and take a look. I'll have a closer look tonight when I get back later on.

 

Just re-flashed my Sys-Check Slot #3 and can confirm 1.3 appears to work as expected with external OS from the Sys-Check, even with Stock OS still on the mainboard. Got all the way to "Completed." (Still no idea what the beeps and boops all mean though ) Good work!

[shoestring]

High beeps indicate it's cleared one of the available ram tests.

 

Exhaustive takes the longest which is why I decided to introduce a series of low beeps. Each low beep indicates that it successfully tested 100 memory addresses. When that is done ( about 5 minutes later ), you hear a final high beep indicating the exhaustive test is complete.

[shoestring]

One other minor observation.. my 800XL PCB RAM Layout is in this order, top to bottom:

U9 U10 U11 U12 U16 U15 U14 U13 - but the tester currently lists them sequentially. It might be nice to have the on-screen order match the PCB

 

 

This is fixed now. I believe only the 800xl column needed changing. 4th column is now in for 600xl 64kb systems, I'll need to emphasize that this version is for 64kb systems only.. "For Atari 64kb 8 Bit Systems"

 

I suspect I might not even need additional graphics for the last column. The 4464 XE and 600XL could be merged together into 1 single column.

 

Something like this ( arrow denotes bad d0 or d1 or d2 or d3 ). So if you have an XE.. replace u9, if you have a modded 600xl then replace u11.

 

Hopefully this won't be too confusing ?

 

 

 

Edited September 1, 2018 by shoestring

[shoestring]

v1.4a8diag1-4.rom

[shoestring]

V1.5 - a8diag1-5.rom

 

Not much difference between the previous version. The NMI that normally services the video is temporarily disabled until the first 2kb passes the test, I'm updating the video display in a loop when a bit fails the eval and subsequent tests are suspended.. it's a crude way to do things but it works. So now it's virtually crash proof. The DLI is also disabled, I figured it should be since that's going to use the stack when it enters and exits the procedure.

 

I discovered that pulling RAM chips wasn't a valid test since the PMG bit patterns are also copied to the RAM, so that gives unreliable results (it sets the PMG to the wrong vertical position resulting in wrong indications). I tried pulling the outputs high, low or floating them but that doesn't seem to give reliable results either. Problem is, every address within the 64kb address space is going to have the same output floating, high or low and that doesn't always happen in the real world.

 

Probably best if I can get my hands on some bad RAM.

 

Edit: Or maybe even get my hands on a logic pulser.

 

http://www.sunequipco.com/electronic%20test%20and%20measuring%20equipment/logic%20probe&pulser/logic%20pulser/LR-02002.HTM

Edited September 2, 2018 by shoestring

[seastalker]

Anyone try this with a U1MB / Side 2 cart setup?

[shoestring]

I’ve moved to a new apartment recently so haven’t had the chance to do any updates.

 

Still waiting on my logic pulsar too.