BBC Master 65C102 co-processor — test memory

Question

Out of the blue the other day, my friend found an internal 65C102 co-processor for the BBC Master in his attic, and gave it to me. It wasn't in particularly good physical condition (all the pins were bent) but I managed to get it connected, and it does appear to work! (Though I don't have any of the PCB stand-offs; I guess they're quite important to ensure the board isn't damaged by warping, so I should probably go and find some soon-ish).

However, I'm slightly more concerned than with most hardware, due to the condition that it was in, that there might be something wrong with it. While I can write a simple BASIC loop and see that it does indeed execute just over twice as fast as on the main processor, I'd like to test as much as the memory as is possible. I gather from the internet that the entire 64K address space of the thing is mapped to RAM, into which the chosen ROM is copied on boot? So I guess testing that bit won't be easy. Though I could easily write some BASIC to do some simple tests between PAGE and HIMEM (though that might be complicated since I suspect HIMEM especially will change during program execution!), and between &C000 and &F7FF (where "HI BASIC", which I also don't have a copy of, would usually sit), I wonder if there's a not-too-hard way to be a bit more thorough than this?

Unfortunately I've forgotten most things I used to know about my collection of 80s and early 90s home computers, since I had university between now and the last time I had access to them; so some basic things that I would have known how to do (eg getting files onto disk easily) are things that I can't do right now (especially since my main machine with a floppy controller is currently sitting dead). But I can remember the, err, basics of BASIC, and I can get files across using the tape interface.

Answer 1

PAGE and HIMEM are what you might call "system variables" in BBC basics, they mark the bottom top of the memory available for Basic use, they are intiialised from OS-provided values but can be changed by the user.

On a regular BBC micro HIMEM will point to the bottom of screen memory, so it can change if you change screen modes (this BTW meant you couldn't change screen mode within a procedure, because the procedure stack grows down from HIMEM), but on a second processor it should always point to the bottom of the OS unless it is manually changed.

So what I would do if writing a ram tester is manually change HIMEM to give my program a small workspace, the program can then test the space between the new HIMEM and the old HIMEM without worrying about being stepped on by BASIC. If you are using regular Basic you can also test the area between BASIC and the OS.

For testing the area with BASIC in it you could just run a checksum and compare the results running it on the copy of BASIC in the second processor to the copy in the machine itself.

Not sure of any easy way to test the OS code area at the top and the workspace areas at the bottom.

Answer 2

The 64KB of RAM for the 65C102 co-processor is provided by eight MB8264 64k x 1-bit chips. Each chip provides one bit of memory for every address, meaning that all eight chips are used for every memory location. In many instances, the failure of a RAM chip will affect all memory locations (including the 6502's page 0 registers), meaning that the co-processor won't be able to boot far enough to run any memory tests! But let's assume that the co-processor boots, and you want to test the rest of the memory.

Memory Map

Before you start testing specific memory locations, you'll need to know what use is made of different locations. The User Guide for the 65C102 Co-Processor includes a memory map for the host (I/O) processor and the co-processor. When using Hi-BASIC, it is as follows:

         -------------- &FFFF
          Used by MOS
         -------------- &F7FF
          Hi-BASIC
          (or other
          Hi-language)
HIMEM -> -------------- &C000

          User's BASIC
          program area

PAGE --> -------------- &0800
          Used by MOS
         -------------- &0000

Note that the I/O processor will also have a memory space with addresses from &0000 to &FFFF. Because programs can access memory from either processor, references to the co-processor's memory are prefixed with FFFF. So the command ?&2000=&55 would write the hexadecimal value &55 at &2000 in the I/O processor's memory, but ?&FFFF2000=&55 would write it at &2000 in the co-processor's memory.

---

Testing Memory Locations (without crashing the machine)

In my experience, most BBC Micro and Master RAM faults show up at many (if not all) possible locations, so you shouldn't worry about testing the highest and lowest 2K of RAM. Between PAGE and HIMEM, BASIC will arrange it's variables as follows:

   +-----------+ HIMEM
   |   BASIC   |
   |   stack   |
   +-----------+ STACK        ^
   |   free    |              |
   |   space   |              |
   +-----------+ VARTOP  increasing
   |   heap    |           memory
   |(variables)|          addresses
   +-----------+ LOMEM
   +-----------+ TOP
   |  program  |
   +-----------+ PAGE

So any addresses between the values returned by STACK and VARTOP are safe for you to PEEK and POKE at as much as you like. Writing and reading a selection of values (e.g. &00, &5A, &A5, %FF) from each address, and comparing the output with what you wrote, is a good strategy. You can use the PEEK and POKE commands or the indirect operators to do so. There are a few example BASIC programs on this forum thread to help you get started. Remember to prefix your memory locations with FFFF to use the co-processor's memory!

If you want to test the area of co-processor memory used for the language ROM (e.g. BASIC), this memory space is written to by the Master when copying BASIC there in the first place. You can read it back and compare it against the original. I suggest using BASIC rather than Hi-BASIC for this, as you can then test directly against the copy in the I/O processor's memory: testing for ?&FFFF8000 <> ?$8000 (and looping through to $BFFF) will pick out any memory locations that don't match.

Additionally, when using regular BASIC (instead of Hi-BASIC) on the co-processor, the 14k of memory from &C000 to &F7FF is free RAM, so you can test this memory be PEEKing and POKEing with the same BASIC programs as earlier.

---

Identifying the Faulty Chip

If you find any faults when writing to and reading from a memory location, you should be able to identify which bits of that byte are incorrect. The bits D0 to D7 (from most to least significant) correspond to the RAM chips IC18 to IC25 on the co-processor board, as seen in this circuit diagram.

D0 is provided by IC18
D1 is provided by IC19
D2 is provided by IC20
D3 is provided by IC21
D4 is provided by IC22
D5 is provided by IC23
D6 is provided by IC24
D7 is provided by IC25