Attempting a 65c816 build (with learning opportunities.)

ssturgis · Post by **ssturgis** » Thu Jun 29, 2023 6:24 pm

Background:
I'm creating an 65c816 SBC based on the POC-V1 design of BigDumbDinosaur. My board differs from BDD's in that I'm using a 15ns 28c256 EEPROM (rather than BDD's 27c256) and two 15ns 71256SA SRAMs (rather than BDD's single SMT SRAM). Also, at the moment, I'm using a 6551 for serial I/O (sorry, BDD), because that's what I have on hand. I've got an 88C92 that I'll switch to once I get the board working. Which it's not, at the present time. The construction is wire-wrap, which I've used successfully in the past.

The board firmware is based on that in the KIM-1, with modifications to use a 6551 rather than the original KIM bit-banging. I've used this firmware successfully with 6502 and 65c02 boards I've built in the past. I started this '816 project with a 1mhz clock and will step up the speed, once the board is working. My initial goal is to explore the additional instruction capabilities of the 65c816, not to create a high-speed SBC.

My first attempts at running the board were no-gos and I spent quite a bit of time checking my wiring for errors and fixing a couple. With the board still not working, I tried monitoring the CPU activity with an Arduino MEGA and a very slow clock.

Diagnosis attempts:
Before starting this project, I had watched a series of videos from Ben Eater, in which he builds a simple 65c02 computer on a breadboard and diagnoses issues with a Arduino MEGA and a very slow clock built with 555 timers. What a great idea! So, I put one together, too. The MEGA, with Ben's software, monitors the 16 address lines, 8 data lines, and RWB, and is triggered by the rising edge of PHI2. Pretty cool to see the processor chugging along at 1 to 10hz!

I programmed an EEPROM with all values set to $EA, except for the first six bytes, which were set to AD 00 D0 4C 00 E0 (LDA $D000 - JMP $E000.) The RST vector is set to $E000. My 6551 is located at $D000 and initially, I wanted to make sure it was being selected correctly. I later temporarily removed the SRAM and 6551 from the board, thinking that they could be causing problems. The board was now running at ~2hz with just the 65c816, EEPROM and glue logic.

Tracing with the MEGA:
With the clock stopped, I reset the board and then started the clock. The results from the MEGA were:

Code: Select all

Address            Data       addr	R/W  data
0000001100000000   00110110   0300  r    36 ; processor starting up
1111111111111111   11101010   ffff  r    ea
1110101011100110   11101010   eae6  r    ea
0000000100010110   00000000   0116  r    00
0000000100010011   00000000   0113  r    00
0000000100010010   00000000   0112  r    00
1111111111111010   00000000   fffa  r    00 ; reads from NMI vector (which is set to $EAEA) ?
1111111111111011   11100000   fffb  r    e0
1110000000000000   10101101   e000  r    ad ; but starts executing at the RST vector ($E000) ?
1110000000000001   00000000   e001  r    00
1110000000000100   11010000   e004  r    d0
1011000000000000   00000000   b000  r    00
1110000000000101   01001100   e005  r    4c
1110000000001000   00000000   e008  r    00
1110000000001001   11100000   e009  r    e0
1110000000000000   10101101   e000  r    ad ; looking good
1110000000000001   00000000   e001  r    00
1110000000000100   11010000   e004  r    d0
1011000000000000   00000000   b000  r    00
1110000000000101   01001100   e005  r    4c
1110000000001000   00000000   e008  r    00
1110000000001001   11100000   e009  r    e0
1110000000000000   10101101   e000  r    ad ; still looking good
1110000000000001   00000000   e001  r    00
1110000000000100   11010000   e004  r    d0
1011000000000000   00000000   b000  r    00
1110000000000101   01001100   e005  r    4c
1110000000000101   01001100   e005  r    4c ; starting to go off the rails
0000000100011101   11100000   011d  W    e0 ; doing writes in deep space
0000000100011100   00000000   011c  W    00 ; this pattern continues ad infinitum
0000000100011001   01100111   0119  W    67
1111111111110010   11101010   fff2  r    ea
1111111111110011   11101010   fff3  r    ea
1110101011100110   11101010   eae6  r    ea
1110101011100110   11101010   eae6  r    ea
0000000100011101   11100000   011d  W    e0 ; ...

Tracing with a scope:
I have a Digilent Analog Discovery 2 and used its scope to look at the address and data lines. The address lines look sharp and well defined, but several of the data lines are peculiar. This trace is of the D0 (blue) and D1 (red) data lines running at the slow (~2hz) speed with the test firmware.

Continuing with the test firmware and slow clock, the D0 and D1 lines have occasionally shown some severe distortion.

Reinstalling the original firmware, RAM and 6551 and 1mhz clock, the data lines look more peculiar. D7 is blue and D6 is orange. Haven't seen the wild distortion, though.

Conclusion:
Any and all suggestions on how to continue make progress with debugging the problem are welcome!

Proxy · Post by **Proxy** » Thu Jun 29, 2023 6:48 pm

hmm, reading from an address in ROM and getting a value from another address sounds to me like a swapped address line.
i've also noticed that you didn't comment on the fact that your code is supposed to load from $D000 but the arduino tracer shows it accessing $B000 instead.

also since you said your design is only based on the POC and has some different hardware, a full schematic (and image) would be very useful to have as it's a hardware issue.

beyond that have you tried to just go down to the bare minimum? just the CPU and a ROM with the arduino tracer, then re-add components like RAM and IO to see when it breaks.
i am assuming this SBC is build on something like a breadboard where taking it apart is rather simple.

AndrewP · Post by **AndrewP** » Thu Jun 29, 2023 7:06 pm

I'm also thinking a swapped address line, but on the MEGA.

The reset vector should be FFFC but traced as FFFA. ... 1100(C) vs ... 1010(A) similarly for FFFD but it's traced as FFFB. 1101(D) vs 1011(B). The ROM contains FFFA:EA and FFFB:EA and if that is the address it receives that is what it would put that on the data bus. But it's not. It's putting out 00 then E0 which are at FFFC and FFFD.

So I think at least some of the confusion is in the trace wiring.

But that doesn't explain the weird oscilloscope levels. Someone more knowledgeable is going to have chime in but if it was just a short between two data lines I wouldn't expect to see sometimes full 5v signals and sometimes runty 1.5V signals. Maybe if it's shorted to another data line that is also changing?

BigDumbDinosaur · Post by **BigDumbDinosaur** » Thu Jun 29, 2023 7:19 pm

A clear, monochrome schematic would be *VERY* helpful. Scope traces alone aren’t all that useful without knowing how the circuit was designed.

As the others noted, you may have an address bus wiring error. However, the mess seen on D0 and D1 suggests there may other issues, possibly timing-related.

ssturgis · Post by **ssturgis** » Thu Jun 29, 2023 7:39 pm

Good point about trying to read from $D000 and actually reading from $B000. I didn’t notice that until you pointed it out. I believe that the cpu is actually reading from $D000, because I can see the chip select for the ACIA go low when I single step through that read operation. I’ve checked both the address and data lines with a continuity tester and they all seem to go where they’re supposed to. I’m thinking that the arduino is not reporting correctly. It also showed taking the NMI vector on reset, but landing on the correct RST destination (?)

The only (intentional) difference with the poc1 is that I’m selecting the first 32k RAM with the A15 linand the second RAM is selected with (A15 & !A14: $8000-$BFFF.) I’d post a modified schematic, but I don’t actually know how to use KiCAD or similar software. I’m working directly from BDD’s schematic for ROM select, I/O select, system clock generator, reset generator, and read/write qualification. The only difference is my RAM selects, described above.

I tried operating the board with RAM and 6551 removed, that’s where I got the arduino trace and the first scope trace.

ssturgis · Post by **ssturgis** » Thu Jun 29, 2023 8:09 pm

AndrewP wrote:

I'm also thinking a swapped address line, but on the MEGA.

The reset vector should be FFFC but traced as FFFA. ... 1100(C) vs ... 1010(A) similarly for FFFD but it's traced as FFFB. 1101(D) vs 1011(B). The ROM contains FFFA:EA and FFFB:EA and if that is the address it receives that is what it would put that on the data bus. But it's not. It's putting out 00 then E0 which are at FFFC and FFFD.

So I think at least some of the confusion is in the trace wiring.

But that doesn't explain the weird oscilloscope levels. Someone more knowledgeable is going to have chime in but if it was just a short between two data lines I wouldn't expect to see sometimes full 5v signals and sometimes runty 1.5V signals. Maybe if it's shorted to another data line that is also changing?

You are correct, two of the arduino address lines were swapped. Correcting that problem showed the correct values for the RST vector destination (as $E000) and also showing $B000 where the $D000 was correct address. Thanks a bunch for diagnosing that!

ssturgis · Post by **ssturgis** » Thu Jun 29, 2023 8:34 pm

BigDumbDinosaur wrote:

A clear, monochrome schematic would be *VERY* helpful. Scope traces alone aren’t all that useful without knowing how the circuit was designed.

As the others noted, you may have an address bus wiring error. However, the mess seen on D0 and D1 suggests there may other issues, possibly timing-related.

There certainly may be an address bus problem. But with the arduino correctly hooked-up now, I just saw the board make seven correct loops before going off the rails. How correctly hooking up the arduino made the circuit work better is a different question.

Code: Select all

0000000000000000   11111111   0000  r ff
0000000000000000   11111111   0000  r ff
1111111111111111   11101010   ffff  r ea
1110101011101010   11101010   eaea  r ea
0000000111111111   00000000   01ff  r 00
0000000111111110   00000000   01fe  r 00
0000000111111101   00000000   01fd  r 00
1111111111111100   00000000   fffc  r 00 ; displays the correct RST vector and goes there!
1111111111111101   11100000   fffd  r e0
1110000000000000   10101101   e000  r ad
1110000000000001   00000000   e001  r 00
1110000000000010   11010000   e002  r d0; displays a read from $D000 !
1101000000000000   00000000   d000  r 00
1110000000000011   01001100   e003  r 4c
1110000000000100   00000000   e004  r 00
1110000000000101   11100000   e005  r e0

... six more successful times through the loop ...

1110000000000000   10101101   e000  r ad ; start of the seventh loop
1110000000000001   00000000   e001  r 00
1110000000000010   11010000   e002  r d0
1101000000000000   00000000   d000  r 00
1110000000000011   01001100   e003  r 4c
1110000000000100   00000000   e004  r 00
1110000000000101   11100000   e005  r e0 ; seventh loop completed
1110000000000000   10101101   e000  r ad ; eighth loop started
1110000000000000   10101101   e000  r ad ; did the read at operation at $E000 a second time and then left orbit...
1110000000000000   10101101   e000  r ad
0000000111111100   11100000   01fc  W e0 ; the next seven operations appear ad infinitum ...
0000000111111011   00000000   01fb  W 00
0000000111111010   01100111   01fa  W 67
1111111111111000   11101010   fff8  r ea
1111111111111001   11101010   fff9  r ea
1110101011101010   11101010   eaea  r ea
1110101011101010   11101010   eaea  r ea
0000000111111100   11100000   01fc  W e0
0000000111111011   00000000   01fb  W 00
0000000111111010   01100111   01fa  W 67

BDD, would it be OK with you if I repost your schematics for the circuit with my modification for my RAM selection?

barnacle · Post by **barnacle** » Thu Jun 29, 2023 8:54 pm

Mid-level signals on data or address lines are almost always indicative of shorts between active lines. If they're shorted to a rail then they'll stick either high or low (or very close to it, depending how the short is implemented) but what you've got is multiple cases of things - possible more than two - trying to drive in opposite directions.

If your wiring is correct then it's likely you've got an issue in your memory addressing and you're making two or more chips active at the same time.

Neil

leepivonka · Post by **leepivonka** » Thu Jun 29, 2023 8:55 pm

That looks like an Abort interrupt sequence.
Is the 65816 ABORTB input pin floating? If you're not using it, it should be tied inactive (high).

ssturgis · Post by **ssturgis** » Thu Jun 29, 2023 9:24 pm

leepivonka wrote:

That looks like an Abort interrupt sequence.
Is the 65816 ABORTB input pin floating? If you're not using it, it should be tied inactive (high).

Good find! ABT was floating and it's now tied high. Thanks!

ssturgis · Post by **ssturgis** » Thu Jun 29, 2023 10:21 pm

Thanks to everyone who's helped with this problem so far! The board is now correctly running the test program on the slow clock with all chips in place and has been running for about an hour. I'll try the more complex firmware tomorrow.

I'm thinking that the extremely noisy signals in my third scope trace were caused by the slow clock, which is on a breadboard. I found that I could make the clock go nuts by putting my finger on one of the clock ICs. When the clock went super noisy, so did the signals on the SBC. Possibly the floating ABT was picking up on all that noise and going wacky as well?

Again, thanks for all the help!

BigDumbDinosaur · Post by **BigDumbDinosaur** » Fri Jun 30, 2023 1:56 am

ssturgis wrote:

Possibly the floating ABT was picking up on all that noise and going wacky as well?

With rare exceptions, every input on a CMOS device *MUST* be connected to something that will drive it close to VCC or ground. CMOS inputs are extremely sensitive and it takes very little noise to perturb one that is floating, often leading to a misbehaving device. If an input is not to be used, it’s best to pull it high with a 3.3K resistor, if room is available for the resistor. Terminating unused inputs in that fashion allows you to use them in the future if needed—the resistor doesn’t have to be removed.

Quote:

BDD, would it be OK with you if I repost your schematics for the circuit with my modification for my RAM selection?

Yes. You need to get proficient with a schematic drafting program, unless you plan to manually draw everything.

Yuri · Post by **Yuri** » Sat Jul 01, 2023 3:10 am

ssturgis wrote:

Background:
...
Before starting this project, I had watched a series of videos from Ben Eater, in which he builds a simple 65c02 computer on a breadboard and diagnoses issues with a Arduino MEGA and a very slow clock built with 555 timers. What a great idea! So, I put one together, too.
...

I have a similar version to Ben's but I dropped the binary (the hex was more useful for me) and added some code to try and decode some of the op codes so I didn't have to keep referring back to the data sheet to look them up.

Here's the code, forewarning I never cleaned this up though!

Code: Select all

#define ADDR_PIN_CNT 16
#define DATA_PIN_CNT 8

//const uint8_t ADDR_PINS[16] = { 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52 };
//const uint8_t DATA_PINS[8]  = { 39, 41, 43, 45, 47, 49, 51, 53 };

//                                         0   1   2   3   4   5   6   7   8   9  10, 11, 12, 13, 14, 15
const uint8_t ADDR_PINS[ADDR_PIN_CNT] = { 23, 25, 27, 29, 31, 33, 35, 37, 39, 41, 43, 45, 47, 49, 51, 53 };
const uint8_t DATA_PINS[DATA_PIN_CNT]  = { 38, 40, 42, 44, 46, 48, 50, 52 };

const uint8_t CLOCK_PIN = 2;
const uint8_t RW_PIN = 3;

const uint8_t LOGIC_PROBE_PIN = 13;

const char* INST_DECODE[] =
{
    "BRK", "ORA", ""   , "", "TSB", "ORA", "ASL", "RMB0", "PHP", "ORA", "ASL", ""   , "TSB", "ORA", "ASL", "BBR0",
    "BPL", "ORA", "ORA", "", "TRB", "ORA", "ASL", "RMB1", "CLC", "ORA", "INC", ""   , "TRB", "ORA", "ASL", "BBR1",
    "JSR", "AND", ""   , "", "BIT", "AND", "ROL", "RMB2", "PLP", "AND", "ROL", ""   , "BIT", "AND", "ROL", "BRB2",
    "BMI", "AND", "AND", "", "BIT", "AND", "ROL", "RMB3", "SEC", "AND", "DEC", ""   , "BIT", "AND", "ROL", "BBR3",
    "RTI", "EOR", ""   , "", ""   , "EOR", "LSR", "RMB4", "PHA", "EOR", "LSR", ""   , "JMP", "EOR", "LSR", "BBR4",
    "BVC", "EOR", "EOR", "", ""   , "EOR", "LSR", "RMB5", "CLI", "EOR", "PHY", ""   , ""   , "EOR", "LSR", "BBR5",
    "RTS", "ADC", ""   , "", "STZ", "ADC", "ROR", "RMB6", "PLA", "ADC", "ROR", ""   , "JMP", "ADC", "ROR", "BBR6",
    "BVS", "ADC", "ADC", "", "STZ", "ADC", "ROR", "RMB7", "SEI", "ADC", "PLY", ""   , "JMP", "ADC", "ROR", "BBR7",
    "BRA", "STA", ""   , "", "STY", "STA", "STX", "SMB0", "DEY", "BIT", "TXA", ""   , "STY", "STA", "STX", "BBS0",
    "BCC", "STA", "STA", "", "STY", "STA", "STX", "SMB1", "TYA", "STA", "TXS", ""   , "STZ", "STA", "STZ", "BBS1",
    "LDY", "LDA", "LDX", "", "LDY", "LDA", "LDX", "SMB2", "TAY", "LDA", "TAX", ""   , "LDY", "LDA", "LDX", "BBS2",
    "BCS", "LDA", "LDA", "", "LDY", "LDA", "LDX", "SMB3", "CLV", "LDA", "TSX", ""   , "LDY", "LDA", "LDX", "BBS3",
    "CPY", "CMP", ""   , "", "CPY", "CMP", "DEC", "SMB4", "INY", "CMP", "DEX", "WAI", "CPY", "CMP", "DEC", "BBS4",
    "BNE", "CMP", "CMP", "", ""   , "CMP", "DEC", "SMB5", "CLD", "CMP", "PHX", "STP", ""   , "CMP", "DEC", "BBS5",
    "CPX", "SBC", ""   , "", "CPX", "SBC", "INC", "SMB6", "INX", "SBC", "NOP", ""   , "CPX", "SBC", "INC", "BBS6",
    "BEQ", "SBC", "SBC", "", ""   , "SBC", "INC", "SMB7", "SED", "SBC", "PLX", ""   , ""   , "SBC", "INC", "BBS7"
};


void setup() {
  for (int i = 0; i < ADDR_PIN_CNT; ++i)
    pinMode(ADDR_PINS[i], INPUT);

  for (int i = 0; i < DATA_PIN_CNT; ++i)
    pinMode(DATA_PINS[i], INPUT);

  pinMode(CLOCK_PIN, INPUT);
  pinMode(RW_PIN, INPUT);
  pinMode(LOGIC_PROBE_PIN, INPUT);

  attachInterrupt(digitalPinToInterrupt(CLOCK_PIN), onClock, RISING);

  Serial.begin(9600);
  Serial.println("Monitor Started...");
}

void onClock() {
  char buffer[32];

  uint32_t addr = 0;
  uint32_t data = 0;

  for (int i = ADDR_PIN_CNT - 1; i >= 0; --i)
  {
    int val = digitalRead(ADDR_PINS[i]) == HIGH ? 1 : 0;
    addr = (addr << 1) | val;
  }

  for (int i = DATA_PIN_CNT - 1; i >= 0; --i)
  {
    int val = digitalRead(DATA_PINS[i]) == HIGH ? 1 : 0;
    data = (data << 1) | val;
  }

  int rw = digitalRead(RW_PIN) == HIGH;
  int l = digitalRead(LOGIC_PROBE_PIN) == HIGH;

  snprintf(buffer, sizeof(buffer), "0x%04X %c %02X - %s   -- L:%c", addr, rw ? 'r' : 'W', data, INST_DECODE[data], l ? '1' : '0');
  Serial.println(buffer);
}

void loop() {
  // put your main code here, to run repeatedly:
}

Hope it helps!

Proxy · Post by **Proxy** » Sat Jul 01, 2023 7:51 am

also instead of a slow external clock with an NE555 or similar, you can just use the arduino as the clock source so it's always fully in sync

ssturgis · Post by **ssturgis** » Sat Jul 01, 2023 10:31 am

Yuri wrote:

Background:

I have a similar version to Ben's but I dropped the binary (the hex was more useful for me) and added some code to try and decode some of the op codes so I didn't have to keep referring back to the data sheet to look them up.

Here's the code, forewarning I never cleaned this up though!

Code: Select all

#define ADDR_PIN_CNT 16
#define DATA_PIN_CNT 8
 ...

Hope it helps!

Thanks Yuri, great idea!

Attempting a 65c816 build (with learning opportunities.)

Attempting a 65c816 build (with learning opportunities.)

Re: Attempting a 65c816 build (with learning opportunities.)

Re: Attempting a 65c816 build (with learning opportunities.)

Re: Attempting a 65c816 build (with learning opportunities.)

Re: Attempting a 65c816 build (with learning opportunities.)

Re: Attempting a 65c816 build (with learning opportunities.)

Re: Attempting a 65c816 build (with learning opportunities.)

Re: Attempting a 65c816 build (with learning opportunities.)

Re: Attempting a 65c816 build (with learning opportunities.)

Re: Attempting a 65c816 build (with learning opportunities.)

Re: Attempting a 65c816 build (with learning opportunities.)

Re: Attempting a 65c816 build (with learning opportunities.)

Re: Attempting a 65c816 build (with learning opportunities.)

Re: Attempting a 65c816 build (with learning opportunities.)

Re: Attempting a 65c816 build (with learning opportunities.)