6309 SBC. Issues with RAM - Page 1
Forum section: electronics / projects

author: gmc
author_rank: Regular Contributor
timestamp: October 06, 2025, 09:09:42 pm
content: I'm busy building a 6309 SBC mostly based off the design here:https://github.com/jefftranter/6809/tree/master/sbcI'm only using the 6309, RAM, ROM and GAL (And some latches to drive from I/O)The decoding logic used in the design is:But i my case I've decided to go with a GAL16V8 to do the decoding logic.Code:FIELD address = [a15..8];led1= address:[80XX..80XX];led2= address:[81XX..81XX];Read= !(e & rnw);Write= !(e & !rnw);RAMcs= a15;ROMcs= !(a14 & a15);I've also got a LED connected via a latch so I can turn it on and off.So far I've got a 27C256 ROM connected and a simple programCode:LED_PORT EQU $8100CPU_LED_PORT EQU $8000ROM EQU $4000FILL $12,ROMORG ROMSTARTLDS #$1000LDA #%11110000 ;Last 4 LEDS onSTA LED_PORTENDBRA END;* Boot and interrupt vectorsORG $7FFEFDB STARTThis all works 100% without the 32k 65536 RAM inserted. As soon as I insert the RAM the program doesn't run. I can only guess it's some kind of overlapping RAM/ROM causing this.I've got the RAM connected as per the original design:Been pull my hair out for a few days now and can't seem to get it working with the RAM inserted.Is there something I'm missing. I've read a few posts that the original design works and has been built by a few people but with my GAL I can't get it working.Is there something wrong in my GAL code and/or 6309 code?

author: PCB.Wiz
author_rank: Super Contributor
timestamp: October 06, 2025, 09:27:04 pm
content: Quote from: gmc on October 06, 2025, 09:09:42 pmThat seems a bit suss ? ROMcs starts at 0xC000 ?

author: gmc
author_rank: Regular Contributor
timestamp: October 06, 2025, 09:35:17 pm
content: I'm using a 32k ROM so the reset vector is at 0x7FFE/7FFF, and code at 0x4000On the CPU this maps to 0xFFFF/FFFE and 0xC000

author: mikerj
author_rank: Super Contributor
timestamp: October 06, 2025, 10:08:37 pm
content: Does it run if you insert the RAM but isolate the CS pin (e.g. bend it out slightly so its not in the socket)?

author: pqass
author_rank: Super Contributor
timestamp: October 06, 2025, 10:55:24 pm
content: Do you have pullup/pulldown resistors on your data bus?If so, reading non-existing RAM will yield $00 or $FF which are NEG and STU op codes.Which should execute and proceed to the next op code until your 32k ROM is reached.See if your assembler output matches mine below.I've compiled it on Linux with: $ asm6809 -l test.lst -H -o test.hex test.asmAnd get the following for test.hex:Code::200000001212121212121212121212121212121212121212121212121212121212121212A0:20002000121212121212121212121212121212121212121212121212121212121212121280.... 4k of NOPs here ($12):203FC0001212121212121212121212121212121212121212121212121212121212121212A1:203FE000121212121212121212121212121212121212121212121212121212121212121281:0B40000010CE100086F0B7810020FEFB:027FFE00400041:00000001FFNotice the $4000 at end (:027FFE00400041). That'll jump into random data if there's RAM there.Besides, you should be copying your code from ROM to $4000 before jumping to it.Have you thought of putting theASSIST09 monitorin ROM instead? It'll help with uploading SRECs into RAM and then execute it.

author: gmc
author_rank: Regular Contributor
timestamp: October 07, 2025, 09:25:58 am
content: Quote from: mikerj on October 06, 2025, 10:08:37 pmI've done some further testing and instead of bending the pin, if I comment out:Code:RAMcs= a15;Then it runs with the RAM inserted.Quote from: pqass on October 06, 2025, 10:55:24 pmI don't have any pull up/down resistors.I have compared my output and it matches yours.One thing to note is that I'm not trying to run my code from RAM. I only intend to use the RAM for the stack so I can run functions which push/pull values onto the stack.I think this comes down to my misunderstanding of how the mapping works.From the authors website:Code:Memory Map0000-7FFF 32K RAMC000-FFFF 16K ROMSo 4000h is in the RAM space which I think is causing the issues. I should be starting at C000h (Something the second poster pointed out)I think the failure of me understanding the mapping is causing issue.I've now changed the code to:Code:LED_PORT EQU $8100ROM_START EQU $C000ROM EQU $4000FILL $12,ROMORG ROMSTARTLDA #%11110000 ;Last 4 LEDS onSTA LED_PORTEND ; Loop foreverBRA END;* Boot and interrupt vectorsORG $7FFEFDB ROM_STARTWhich has improved things. I've re-enabled the GAL equation for RAMcs and the program runs with the memory inserted.Next tried to initialise and use the stack but that's giving issues. So not sure if RAM is working:My new code is:Code:LED_PORT EQU $8100ROM_START EQU $C000ROM EQU $4000FILL $12,ROMORG ROMSTARTLDS #$7FFFLDA #%11110000 ;Last 4 LEDS onSTA LED_PORTJSR TESTCALLLDA #%00001111 ;First 4 LEDS onSTA LED_PORTEND ; Loop foreverBRA ENDTESTCALLNOPNOPRTS;* Boot and interrupt vectorsORG $7FFEFDB ROM_STARTIt should runs on 4 LEDs, jump and return from a routine, and the turn on the other 4 LED'sProgram runs and only turns on last 4 LED's so it's not happy with the routine.If I comment outCode:JSR TESTCALLit runs and turns on the first 4 LEDsSo still pointing to some RAM issue. I've played around with setting the stack to 7FFF, 5FFF, 1000 - makes no difference.

author: pqass
author_rank: Super Contributor
timestamp: October 07, 2025, 01:13:52 pm
content: It's not the hardware (yet).Your new code translates to the following listing output:Code:8100 LED_PORT EQU $8100C000 ROM_START EQU $C0004000 ROM EQU $40000000 121212121212121212121212121212121212121212121212121212121212121212121212121212121212.....FILL $12,ROM4000 ORG ROM4000 START4000 10CE7FFF LDS #$7FFF4004 86F0 LDA #%11110000 ;Last 4 LEDS on4006 B78100 STA LED_PORT4009 BD4013 JSR TESTCALL400C 860F LDA #%00001111 ;First 4 LEDS on400E B78100 STA LED_PORT4011 END ; Loop forever4011 20FE BRA END4013 TESTCALL4013 12 NOP4014 12 NOP4015 39 RTS;* Boot and interrupt vectors7FFE ORG $7FFE7FFE C000 FDB ROM_STARTNote the "4009 BD4013JSR TESTCALL".It's putting in an absolute address here; jumping into uninitialized RAM.Use BSR or LBSR (relative addressing) instead of JSR for subroutines that are +/-128, 64k bytes away, respectively.Or use PCR (eg. "JSR TESTCALL,PCR") for subroutines that are +/-32k bytes away.Review addressing modeshere.

author: gmc
author_rank: Regular Contributor
timestamp: October 07, 2025, 02:20:00 pm
content: Wow! A thousand thank yous.That did the trick. It's all working as expected now.Coded another routine to push and pull a value from the stack and compare which confirms RAM is working as expected.Great link to the address modes. Should have started with reading that book