RAM expansion problem

[Bob Kircher]

I'm playing around with my new PAL-1 with 32K RAM expansion and I find something odd.  Writing to locations $2000-$9FFF via the keypad doesn't work; it sets the rightmost bit if I key in any odd number and resets it if entering an even number, the other bits are all cleared. In other words, attempting to enter $FF or $33 results in $01, and $FE or $32 results in 00.  However if I use a program to store values in the $2000-$9FFF range, it seems to work fine: eg LDA #$FF; STA $2000 does indeed store an FF in location 2000.

Writing to available RAM in the $0000-$17FF range through the keypad works just fine.

Can anybody shed some light on this?

-Bob

[GN Liu]

Hi Bob,

You can make sure that the RAM expansion is working properly, such as jumper settings and motherboard connections. You can set a value to $0000 then check the $2000, if the values are the same, maybe the expansion is not working.

Then you can use the memory test program to test the $2000-$9fff range, Jim post a memory test program for PAL-1 on GitHub (https://github.com/w4jbm/PAL-1-6502-SBC/blob/main/pal_memt.lst), or on the ROM expansion if available.

Since the program seems to be working fine, but the keyboard does not, I suggest you check if the solder joints related to the keyboard are completely fine, you can refer to the schematic in the kit.

Liu

[Bob Kircher]

Let me emphasize that the *only* time I have a problem is using the keyboard to write to expansion memory.  Programs can write to it with no problems, and I can write to onboard memory from the keypad with no problems.  I checked for crosstalk type issues, and found none.

That being said, I'll try that memory test.  Thanks for the suggestion.

-Bob

[Jim McClanahan]

When you say programs can write successfully, do you mean fairly complex programs or just something like a simple load and store? Even if the memory expansion isn't enabled, the KIM will let you successfully do a write and read to $2000 (or $4000 or $6000...), but what is really happening is that it is writing and reading at $0000 since the upper address lines aren't decoded.

The memory test is the only thing that will really give a reliable indication that the memory can be written to and read back. I can think of a few odd ball things that could cause the symptoms. A careful visual inspection is usually the best start. Then I'd pull the RAM chip (but leave the board in place) to make sure I didn't see RAM where there isn't any.

Something like a bridged solder joint that isn't a dead short can cause strange issues. I could imagine a scenario where a solder bridge on the memory board might not show issues at a slightly higher voltage, but cause enough of a draw of current to make things flaky if the voltage dropped even a tiny bit. And using the LEDs instead of something like the serial port (or a program running without the LEDs being used) will likely cause a (very, very) slight drop in voltage.

From the perspective of chips, there isn't much that is likely to go wrong unless you get a bad chip. A bad solder connection, missed solder connection, bit of clipped wire hidden under a socket, or those types of things are most likely. The ribbon cable being off by one or something would be another possibility although I think it would have more catastrophic symptoms.

The other thing could be that the issues isn't the RAM board at all, but more around the onboard decoding. In that case, it just wouldn't have shown itself until you tried to use something like the RAM board.

Let us know what you find with the memory test. I don't think the group has failed to help everyone with an issue eventually get things going--sometimes it just takes longer than others. :-)

Thanks,

Jim W4JBM

[Bob Kircher]

I have inspected the board for cold solder joints, solder shorts, pieces of wire etc, and can't see anything untoward.  That doesn't mean there isn't one somewhere of course, but I'm pretty confident there isn't.

I entered this short program:

lda #$90

sta $9000

lda #$80

sta $8000

lda #$70

sta $7000

...

lda #$00

sta $0000

After running it I read back the locations via the keyboard, everything had the expected values; $9000 had $90, $8000 had $80, etc, down to $2000- had $00 and $0000 had $00.

If I enter any address in the range $2000-$9FFF and press the data switch, then press a digit the rightmost digit on the display moves to the left and a 1 is entered of the key was an odd digit or a 0 if an even digit. If I press a second digit the left data digit goes to zero regardless if the right digit was 1 or 0 and the right digit gets a 1 or zero again depending on if I typed an even or odd key.  This *only* happens in the range $2000-$9FFF; $0000-$17FF work fine.

I keyed in and verified the memory test then ran it.  It blanked the screen and stayed that way for about five minutes at which time I hit the RS button and got control back. How long should the memory test take? I've known of exhaustive memory tests that took hours to run.  Also, even though I stepped back through the program to verify it, it's still very possible I made a mistake.

I'll try the memory test again after I learn how long it's expected to take.

Thanks for your input.

-Bob

[Jim McClanahan]

I'll have to dig out the PAL and try the memory test. As I remember, it usually hits an error pretty fast if something is wrong and only takes a minute or two to complete if everything is okay. (But my memory isn't great.)

I understand better what you mean about the 1 and 0 now. I hate to play twenty questions, but this is definitely an unusual problem. Does the lower RAM load from the keyboard okay even when the RAM card is plugged in? What happens if you try to "load" a value into one of the ROM locations (like $1FF0 for example)? I know it won't store it, but I wonder if it flakes out there also. What about if you try to load something into non-existent memory (like $DFF0 that would be on the ROM expansion card)? Again, nothing should really be stored, but entering a hex value from the keypad should work.

If the problem only happens between $2000 and $9FFF, then the problem almost has to be on the RAM card itself. I would pull the RAM chip and see what happens in that case. Again, you couldn't store anything for real, but if the keyboard behaves in the strange manner in that case, I'd suspect the chip select logic having a solder bridge to some other control line. If things work fine in that case, I'd have to think some more since the RAM seems to be working when you use the processor to load and store things.

If you see the problem when you are addressing the ROM, I would tend to suspect the issue is on the PAL's main board, not on the RAM board. The same if you saw it when you tried to write to an address where there is nothing (neither RAM nor ROM). Nothing jumps out at me as being a clear cause in either of those cases either.

I need to look at the code to see how it is handling the entry of the two digits for fill memory. I thought that was all in the main board memory until it wrote the value, but I could be wrong and never really had to dig into the details before.

Thanks,

Jim W4JBM

--
You received this message because you are subscribed to the Google Groups "PAL 6502 computer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pal6502+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pal6502/6d775bc8-6a94-4690-b83e-661ee8bfe817n%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bob Kircher]

The lower RAM  works fine with or without the RAM board plugged into the expansion bus.  Writing to ROM or nonexistent RAM works as expected; ie, nothing happens when I press a key. It doesn't matter which slot the RAM card is plugged into, same results.  With the RAM chip removed from the board it behaves like nonexistent memory (hitting numeric keys doesn't change anything).  I swapped out the RAM chip with another 62256, same problem. I can read and write to all RAM, onboard and expansion, through the serial interface.

I'm starting to suspect a misprogrammed ROM.

-Bob

[Jim McClanahan]

The ROM code really doesn't differentiate between address blocks. It doesn't know if it's in the lower 8K, RAM, ROM, the RIOT, etc.. But the quickest way I can think of to verify it would be to create a quick program to calculate a checksum. The other way would be to create a kind of hex dump using the ROM paper tape punch routine to dump the ROM content.

Have you tried doing something "beefy" with the RAM card like loading the in-RAM version of BASIC?

Also, have you set the NMI and IRQ vectors in RAM? Nothing should be kicking off an interrupt, but if it does it is going to get pointed someplace random if they aren't set.

I'm looking at the code in the monitor. It uses indirect indexed addressing to point to the memory location being modified. That means that if there were issues with Page Zero memory, things would get flaky. But I'm struggling to think of anything that would match the symptoms. The fact that the problem goes away when you pull the RAM chip makes me suspect an addressing conflict is happening and both memory chips are trying to put data on the data bus at the same time. But even if that was happening, it seems like both would get the write and be trying to put the same data back so the impact would be minimal (or catastrophic--this is so predictable, not random).

Something going on around the DEN line on the RAM card could cause strange behavior.

Actually one thing that could cause strange behavior would be if pins 4 and 5 on U2 (the 74LS00) had a solder bridge or if pin 4 wasn't soldered. That would mean that the phi 2 clock wouldn't be checked. The fact that the address mode loads an address from page zero and adds the y register to it means the timing for that may look a lot different than just an LDA ADDR and STA ADDR. (This would be an issue that went away when the RAM chip was pulled also.)

I guess that is the other thing that would probably be worth trying a test program--store a known value in memory and then use LDA (addr),Y to load the value and save it off someplace else and then STA (addr),Y to write a second value. It is really rare to have a problem that shows up only in certain address modes, but it isn't unheard of.

Thanks,

Jim W4JBM

To view this discussion on the web visit https://groups.google.com/d/msgid/pal6502/cb70dc98-5f35-408b-9bdd-c73974768356n%40googlegroups.com.

[Bob Kircher]

It's picked up a new trick, it now drops bit 1 when writing to expanded memory via the terminal.  Writes with the keyboard are unchanged.  Now a few minutes later it's unable to write to expansion RAM at all.  Onboard RAM still works fine. Going backwards here.

I'll give it yet another visual inspection then try swapping some chips. And break out the scope and see if there's a difference in write/enable timing between the RAM chips.

[Bob Kircher]

Oops, when I said it wasn't writing to expansion RAM at all it was because I had JP2 closed.  D'oh.  Still dropping bit 1, though.  Anyway tomorrow I'm going to start scoping things.

[Bob Kircher]

Problem solved.  There was a bad solder joint on the RAM socket.  I reflowed the pins and it seems to work now, it passes the RAM test in ROM.

Now to try to find out why BASIC and Forth in ROM don't seem to be working, but that's for another thread.

[Jim McClanahan]

Great news! Our unbroken streak of getting things working on the list continues. :-)

On BASIC and Forth from the ROM, let us know if you have problems. The most common issue if you don't use the start up menu is that decimal mode isn't cleared because the status register start up byte hasn't been set.

Thanks,

Jim W4JBM

[GN Liu]

Thanks Jim!

and Thanks Bob for update, debug-ability also a 'feature' of a vintage replica kit ;)

Liu