Memory Test Time For TLC-MBC

Now that the memory map for TLC-MBC is sorted, I can put stuff in it and in this session that stuff is memory, both RAM and EEPROM. Sounds easy enough, wire a couple of chips into the bread board, write a test program and burn it into the EEPROM and give her the memory test. Well, I’ve had a busy week with other projects, which I’ll tell you about in other posts, and it ended up being Sunday before I could get back to TLC-MBC.

What assembler?

One major delay was finding an assembler that I liked. The first one I tried was one that it seemed most people used and that is cc65. It seemed ideal, x-platform, macro assembler, C compiler, linker, and other tools for the 65C02. I wasted nearly a whole day on it, first of all finding it as it is no longer supported and then trying to get it setup. I think I got it working at one point, but it seemed overly complicated for the task at hand, in the end I gave up on it.

I tried others, but trying to find one I like and is still supported is like trying to find a needle in a haystack. After much searching and playing I found TASM. It’s shareware ($25) but it doesn’t look like it is supported any longer, I have emailed the author. Good news is that it runs on the command line on my Win7 box, it also compiles for several other processors, sadly not the 6809. So I’m going to use TASM for now.


My first objective was to wire up the Eeprom and test it. I plugged the Eeprom into the bread board next to the 65C02 and spent an hour or so stripping and inserting wires, routing them so that I could still access the eeprom for programming. Not really much else to say.


Once that was done it was time to write the first part of the memory test. All that is required here is that the interrupt vectors are found, the reset vector is jumped to and the loop runs. It shouldn’t matter what speed the processor runs at, I should see a constant $84 and two flickering digits as the program loops around $840F to $8412 and back again constantly. The assembly program is below:

; Memory Map Constants

; 28256 EEPROM - 31K
ROMBASE     = $8000

; UNUSED ROM: $8000-$83FF is used by the I/O
            *= ROMBASE
            .FILL $400, $EA    ; Fill the first k with NOPs
RST_VEC        jmp MAIN

NMI_VEC        rti

IRQ_VEC        rti

; Cold reset

            ldx #$FF        ; Iniz SP to $01FF
            lda #$00        ; Iniz regs to zero
            cld                ; Clear decimal mode
            clc                ; Clear the carry
            cli                ; Enable interrupts
            jmp DOLOOP        ; do nothing forever

; Set the interupt vectors for 65C02 system

        *=  $FFFA
.word    NMI_VEC              ; NMI_VECTOR   : $FFFA  (NMI)
.word    RST_VEC                ; RESET_VECTOR : $FFFC  (Reset)
.word    IRQ_VEC              ; IRQ_VECTOR   : $FFFE  (IRQ) 


It consists of three blocks:

  • The first $400 (1024) bytes are filled with $EA to save me messing with offsets when I burn the eeprom. This area of the eeprom should never be accessed as it is masked out for use by the I/O.
  • The actual program, sets up the SP (not yet really! There’s no ram!!), A,X and Y regs and clears some flags then goes into a forever loop.
  • The interrupt vectors for IRQ, RESET and NMI.

The program assembled, I burnt it to the eeprom, put the eeprom back and powered up the system and something happened, but not what I expected… At Reset the PC jumped to $FFFC-$FFFD and got the correct address, $8400, this was placed in the PC and then it jumped to page 1, $01EF and stepped over consecutive addresses. Confusing!!! The fact that it went to $FFFC and got the correct address, told me:

  1. The address lines were wired correctly.
  2. Because it read $00 and then $84 it meant that bits 7 and 3 were probably wired correctly but any/all of the other data lines could be grounded.

Then I remembered my wiring fault on Bus Monitor. So I removed Bus Monitor and replaced it with Hex Display. Started the system again, same result…. so I turned it off and started checking the connections with an ohm meter. Connections looked good, so out of frustration I ripped out all the wiring and had some lunch.

After lunch I decided that instead of cutting up wires, I would use the jumpers that came with the bread boards. this would make the wiring job a lot quicker. Powered-up and failure with the same fault!!! With such a consistent error, I thought maybe the eeprom had been mis-programmed, so I took it out and got a  hex-dump. No, the contents were correct.

Where to now? This memory test was going nowhere! I removed everything from the bread boards, printed out a large version of the schematics and started to print out the pin-outs of each chip and that’s when I noticed something. I always knew that the data-bus on the 6502 was upside-down compared to that of most memory chips, but so is the address bus! So, just for kicks, I checked the 6522 and 6551, and the 6551 was the same. So the “natural” way to lay out the chips from left to right would be:

Optimum layout for memory and 65xx family

Optimum layout for memory and 65xx family

This way, connections to the outside world would be on the outside edges and there’s a minimum of cross over of address and data lines, though the memory could go either side of the 6502. But mostly, notice the 6522 and 6502 point up while the 6551 and memory point down.

Armed with this knowledge, I put the 28256 to the right of the 6502 and put the glue-logic above the 28256. First I connected all the power lines and bypass caps, then I cut and stripped wire to connect the data-bus in white, marking of the schematic as I went. then I cut and stripped wire to connect the address bus (A15-A10) in blue. Control lines, like chip selects were red. I didn’t really fancy cut more wire for A0-A9 so I used blue jumpers.

With the circuit completed I added in Hex Display as Bus Monitor would not fit over the jumpers. I also added a 75498 MOS-to-LED driver with 8 green leds connected to the data-bus so that I could keep an eye on it as well.

The Nano was in Single-Step mode, I hesitantly powered-up the system, hit the reset button and then pressed the Single-Step button slowly and repeatedly. It worked!! Third time was a charm 😉 Encouraged, I put the system into free-run mode and turned the clock up to top speed and it still worked, so I replaced the Nano clock with the 1Mhz oscillator and let her rip – no problem.

Final Memory Test

Bread Board layout for the memory test.

Bread Board layout for the memory test.

With that success under my belt, I decided to add the 62256, same orientation as the 28256. I cut and stripped wire for the control lines but for the address and data buses I used jumper wires. The only problem with using jumpers is that there is not a lot of room to get at the 28256.

Now I had to rewrite the memory test to test the ram as well as the eeprom. I decided to write a small subroutine, SUBLOOP,  that loads the X reg with 3 then decrements it until it’s zero and then returns. This subroutine is copied to multiple arbitrary places in ram. Then the program enters a loop where it calls one of the ram copies and then the original continually in a loop. This will test that we can copy into ram and run something from ram. Here’s the core of what I wrote:

<pre>            ldx #00
            lda SUBLOOP,x    ; Get the next byte
            sta RAMTEST1,x    ; Copy it
            sta RAMTEST2,x    ; Copy it
            sta RAMTEST3,x    ; Copy it
            sta RAMTEST4,x    ; Copy it
            cpx #06            ; 6 bytes to be copied (0-5)
            bne COPYBYTE
; SUBLOOP copied so continue
            jsr RAMTEST1    ; can we run in ram?
            jsr RAMTEST2    ; can we run in ram again?
            jsr SUBLOOP
            jsr RAMTEST3    ; can we run in ram?
            jsr SUBLOOP
            jsr RAMTEST4    ; can we run in ram?
            jmp DOLOOP        ; do silly stuff forever

; Relocatable code to be copied to ram
            ldx #03            ; small value chosen for single step mode
SLLOOP        dex
            bne SLLOOP
Memory test in progress

Memory test in progress

As I was going to single step I placed the four copies at easy to remember addresses. I burnt it into the eeprom, checked the wiring and powered-up. I initially had the clock go fast as I wanted to get through the copying portion of the program, then I slowed it right down so that I could check the data-bus leds as the program ran. The program successfully completed the memory test, looping over and over.

Now that TLC-MBC has completed the memory test and has working ram and eeprom, she is beginning to feel like a real computer. Before I go any further I would really like to remove the Hex Display and the leds along with the associated jumpers and chips. But I’m not sure that I should quite yet, the next step is to add the ACIA, 65C51, so that I can talk to TLC-MBC directly through the serial interface. I would like to think that it will work first time, but Murphy’s Law says that if I remove the test circuitry then the addition will probably fail. I would also like to replace those jumpers as I have noticed that the slightest nudge to some of them will alter the displays and as I have mentioned getting at the eeprom is a major task to not pull out one or more of the jumpers.

Memory Test Schematics

Memory Test Schematics

Well… I’ll leave it there, this post is getting quite long enough, I shall leave you with the schematics and note that if you want to look at the assembler stuff, I shall be uploading it to Git hub this evening sometime.



You may also like...