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.
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:
<pre>.NOCODES ;===================================================================== ; Memory Map Constants ;===================================================================== .CODES ; 28256 EEPROM - 31K ROMBASE = $8000 .NOCODES ;===================================================================== ; UNUSED ROM: $8000-$83FF is used by the I/O ;===================================================================== .CODES *= ROMBASE .FILL $400, $EA ; Fill the first k with NOPs RST_VEC jmp MAIN NMI_VEC rti IRQ_VEC rti .NOCODES ;===================================================================== ; Cold reset ;===================================================================== .CODES MAIN ldx #$FF ; Iniz SP to $01FF txs lda #$00 ; Iniz regs to zero tax tay cld ; Clear decimal mode clc ; Clear the carry cli ; Enable interrupts DOLOOP nop jmp DOLOOP ; do nothing forever .NOCODES ;===================================================================== ; Set the interupt vectors for 65C02 system ;===================================================================== .CODES *= $FFFA .word NMI_VEC ; NMI_VECTOR : $FFFA (NMI) .word RST_VEC ; RESET_VECTOR : $FFFC (Reset) .word IRQ_VEC ; IRQ_VECTOR : $FFFE (IRQ) .END
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:
- The address lines were wired correctly.
- 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:
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
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 COPYBYTE 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 inx cpx #06 ; 6 bytes to be copied (0-5) bne COPYBYTE ; SUBLOOP copied so continue DOLOOP 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 SUBLOOP ldx #03 ; small value chosen for single step mode SLLOOP dex bne SLLOOP rts
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.
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.