Memory issue

[miwa]

Hi,

I recentlt hooked up my old Commodore 128 and tweaked it to run just fine, except for one thing. When I enter 64-mode I only get about 2KB och memory! ;-( In 128-mode though I get all the KB I can get. Any ideas what to do?

[miwa]

Hello again!

I've tried to find information about what IC's actually represent the RAM-modules on the C-128 motherboard, but haven't found it. Are the IC's in the bottom left corner of this image the memory-circuits (marked "MN4164P-15A")? How do I locate which one is faulty and where can I get new components?

[Andrew Wiskow]

If you haven't already seen it, you may find this document to be helpful. 

[SmallCleverDinosaur]

Hello again!

I've tried to find information about what IC's actually represent the RAM-modules on the C-128 motherboard, but haven't found it. Are the IC's in the bottom left corner of this image the memory-circuits (marked "MN4164P-15A")? How do I locate which one is faulty and where can I get new components?

The IC's you refer to are indeed the memorycircuits. There are 16 of them on this motherboard, they each hold 8K of RAM. When it comes to RAM memory the C64 and the C128 tests memory in different ways on startup and reset. The C64 (or the C64 mode of a C128) does this more thoroghly since it has to determine how much RAM is actually available. And that's because an external device (like a cartridge) can replace the internal RAM with it's own ROM. And the only way for the C64 to know that this has been done is to test every byte of the RAM.

The C128 doesn't do this as thoroghly since it can have both RAM and external ROM at the same time, due to the MMU. So there's actually a risk that one of the circuits in your comupter are faulty and that will show up even in C128 mode if you create a program that checks every memorylocation in the computer. That's probably the best way to find out where the problem lies.

[miwa]

Thanx for your replies guys!

Do you know where I can find a program that tests the memory in 128- and 64-mode? Since I can't transfer anything from my PC to my Commodore (I know it is possible but I don't have the necessary harware for it, e.g. cables) I guess I have to do a manual "cut'n'paste" from my PC-screen to the Commodore. That is, if I, or you guys help me, find a program...

[SmallCleverDinosaur]

I figured you might ask that

So, I've written an ML program for you that checks every byte in the visible memoryconfiguration. You can download it by clicking here.

It's a ZIP-file which contains three files. First, there is a textdocument which contains the commented sourcecode of the program. You can use this to type in the program in your computer. That file also includes information on how the program works and how to use it.

Second, there is an emulator disc image file (D64) which contains the binaryfile of the program which in turn can be loaded directly into the memory of the emulator. The program runs in both C64 mode and C128 mode.

Third, there is an emulator cartridge image file that is a small cartridge testfile that I wrote to see how cartridges work.

I included the two last files so you can see the program in action by using an emulator like VICE. If you attach the discimage to the emulator and issue LOAD"MEMTEST",8,1 the program will be loaded into the memory of the emulator and you can run it with SYS4864. It takes a few seconds to run the program. When it exits you can check the last memorylocation that was checked by the program. And that memorylocation is in ROM (or in a faulty memorycircuit). The result can be found in address 254 and 255.

If you run the program in C128 mode both address 254 and 255 will contain 0 when the program ends. That means that the entire 64KB of RAM bank 0 has been tested and that the program stopped testing when the address to be checked wrapped around from $FFFF to $0000.

If you run it in C64 mode address 254 will contain a 0 but address 255 will contain 160. That means that the last address checked was 0+256*160=40960 ($A000) which is the first byte of the C64's BASIC-ROM.

I included the cartridgetestfile so that you could see the change when a cartridge is inserted. If you then run the program address 255 will contain 128.  That means that the last address checked was 0+256*128=32768 ($8000) which is the first byte of the cartridge ROM. (In order to attach this cartridgefile to VICE use "Generic 8KB image").

Sadly, this only shows you how it works. But as you wrote, you can't transfer the program to your real C128. However, your profile suggests that you live in Sweden. If that is in fact so, then drop me an email, and I can snail-mail you a real 5,25" disc containing the program

BTW, if you look closely at the screen as the program runs, at one point you can see some flickering across the screen. That's when the screenmemory at 1024-2024 is being tested

[BigDumbDinosaur]

So, I've written an ML program for you that checks every byte in the visible memory configuration.

With a small modification, the test program can avoid having to use page zero pointers for the address being tested.  Also, you could stuff the program into BASIC's input buffer at $0200, which would place it into common RAM, allowing a test of RAM-1 as well as RAM-0.  BTW, the bit patterns  %01011010 ($5A) and %10100101 ($A5) are better suited for detailed RAM tests.

Incidentally, RAMTAS's function in all eight bit Commodore machines prior to the C-64 was to determine how much RAM was available for BASIC, and where that RAM was located.  The memory map in the CBMxx series and the VIC-20 would change if memory was added or subtracted.  Therefore, RAMTAS didn't "test" memory in the technical sense, it detected it—stopping as soon as ROM was encountered.  If a RAM location failed to return what was written to it RAMTAS would assume it was the start of ROM, not a defective piece of memory.

At reset, the C-64's memory map is determined by the state of the 6510's data port, which is initialized to a known state, making the map static.  Therefore, the amount of RAM available to BASIC will never change, which makes RAMTAS's memory detection activities unnecessary.  The same applies to C-128, which always establishes a "hard wired" memory map at reset.  If you examine the C-128 RAMTAS subroutine, you won't see a detailed memory test at all.

[SmallCleverDinosaur]

With a small modification, the test program can avoid having to use page zero pointers for the address being tested.  Also, you could stuff the program into BASIC's input buffer at $0200, which would place it into common RAM, allowing a test of RAM-1 as well as RAM-0.

Those are good ideas, I didn't think of that

BTW, the bit patterns  %01011010 ($5A) and %10100101 ($A5) are better suited for detailed RAM tests.

I chose $55 and $AA since that's what RAMTAS uses.

At reset, the C-64's memory map is determined by the state of the 6510's data port, which is initialized to a known state, making the map static.  Therefore, the amount of RAM available to BASIC will never change, which makes RAMTAS's memory detection activities unnecessary.

This is not entirely true. The memory map of the C64 is determined by the state of the LORAM and HIRAM lines of the 6510's data port as well as two other lines; the GAME and EXROM lines connected to the expansion port. So if a cartridge is plugged in to the expansion port, the memory map will change and not be the same at startup as it would be without the cartridge. So the memory map of the C64 is not static at startup. If a cartridge is plugged in, that for example only grounds the EXROM line of the expansionport, the available RAM will end at $8000 (instead of $A000), because the ROM of the cartridge will be placed there.

The same applies to C-128, which always establishes a "hard wired" memory map at reset.  If you examine the C-128 RAMTAS subroutine, you won't see a detailed memory test at all.

This is very true, the memory map of the C128 at startup can't be changed, through hardware, by an external device like a cartridge. That's why the RAMTAS of the C64 and the C128 are very different.

[BigDumbDinosaur]

I chose $55 and $AA since that's what RAMTAS uses.

As I'm well aware.  However, way back when I was first learning about this stuff (some 40 years ago), it was determined the 10100101 and 01011010 patterns had a higher probability of detecting errors.  I can't recall the exact reason why anymore, but I've used those patterns many times.

At reset, the C-64's memory map is determined by the state of the 6510's data port, which is initialized to a known state, making the map static.  Therefore, the amount of RAM available to BASIC will never change, which makes RAMTAS's memory detection activities unnecessary.

This is not entirely true.

I neglected to mention the effects of /EXROM and /GAME, either of which can potentially change the amount of RAM available to BASIC, depending on the cartridge's design.  As for HIRAM and LORAM, those two lines are initialized to a known state at reset, guaranteeing that the I/O block and both ROMs are mapped in.  At least six clocks will occur before the 6510 loads the PC with the reset vector.  Therefore, until that happens, the memory map is identical to that of a C-64 with no cartridges installed.