Unable to run a program

[creoguy]

Completed building up a 6502 SBC using this design. https://github.com/chrisabird/sbc65

I assembled his test code using cc65 to test out the VIA and the ACIA and they are working fine. I can modify the VIA code and can adjust the ACIA baud rate without any issue so the SBC appears to be fine. After verifying all that I assembled the OS (EhBASIC 2.22) and enter in the normal Hello World test, but I can't get it to actually run anything. With "10 PRINT "HELLO WORLD", I get the follow message, "Type mismatch Error in line 10" when I attempt to run it. With "PRINT 1 + 1" the unit locks up and I have to reset.

Any suggestions on what to check next?

[hoglet]

creoguy wrote:

Any suggestions on what to check next?

I've attached a PDF of the design, for folk that don't have KiCad.

The first thing to that comes to mind is the Ram's WE signal is directly driven from the 6502's R/W, and the Ram's chip-select select signal is gated with Phi2.

See this thread for an alternative that may work better.
viewtopic.php?p=60630#p60630

Dave

[BigDumbDinosaur]

creoguy wrote:

Completed building up a 6502 SBC using this design. https://github.com/chrisabird/sbc65

I assembled his test code using cc65 to test out the VIA and the ACIA and they are working fine. I can modify the VIA code and can adjust the ACIA baud rate without any issue so the SBC appears to be fine. After verifying all that I assembled the OS (EhBASIC 2.22) and enter in the normal Hello World test, but I can't get it to actually run anything. With "10 PRINT "HELLO WORLD", I get the follow message, "Type mismatch Error in line 10" when I attempt to run it. With "PRINT 1 + 1" the unit locks up and I have to reset.

Any suggestions on what to check next?

A pox on schematics in color!

After printing the schematic in monochrome and examining it, I see several things worthy of note.

hoglet wrote:

The first thing to that comes to mind is the Ram's WE signal is directly driven from the 6502's R/W, and the Ram's chip-select select signal is gated with Phi2.

I concur with Dave. You want the RAM selected before Ø2 goes high (ditto for ROM). The RAM's /WE input should be gated with Ø2, and RAM's and ROM's /CS should not. Similarly, the RAM's and ROM's /OE inputs should be gated by Ø2 to avoid ambiguous data bus conditions during a write cycle. Dave's link points you to a circuit that will meet these requirements using a single chip.

WDC does not recommend the use of the PHI1OUT and PHI2OUT clock signals in new designs. These signals lag PHI2 (Ø2) by an unspecified amount. All timing in the MPU is referenced to Ø2. Using the PHIxOUT clocks for other devices means they will lag the MPU's internal clock by an unknown amount that will vary from one MPU to the next. Obscure timing issues are bound to arise.

Speaking of clock signals, your clock generator circuit isn't illustrated in your schematic, but should be a "can" oscillator whose output fully swings between ground and Vcc. The WDC 65C02 and 65C816 are somewhat persnickety about clock quality. WDC recommends the use of a can oscillator, not a crystal.

Your schematic specifies 74LS glue logic, which is TTL-compatiblenot CMOS compatible. You should be using CMOS glue logic, such as 74HC (good to 8-10 MHz) or 74AC (good to at least 20 MHz).

The DS1813 attached to your reset circuit is drawn as though it is a transistor. It is not a transistor.

In the future, I recommend you also use a DS1813 on NMI, along with a suitable pullup resistor, so you can use NMI to break a loop in a "stuck" program. I did that on my POC V1 design and it saved my bacon more than once when I accidentally sent the MPU off into the wild, blue yonder.

[BigEd]

Welcome creoguy! I'm sure we can help you out: hoglet's link to the thread on safe design of glue logic is a very good starting point.

[creoguy]

Thanks for the pointers! Always interesting following someone else's design when you don't fully have a grasp of the overall design, but it makes for a good learning experience!

I did use a 1mHz can oscillator connected to pin 37 of the 65c02. I've got an 74HC00 coming and will try that out using the link Dave provided to clean up the glue logic. For RST, I forgot to order a DS1813 and ended up using a 555 circuit with the unused inverter on the 75LS132 instead.

[Dr Jefyll]

Welcome, creoguy! We'd enjoy seeing some photos of your project if you have any. Also they may prove helpful. (No need to use a third-party image hosting site, BTW -- on this forum you can attach images with your posts.)

Although you might find that this...

read_write_qualify_alt.gif (16.76 KiB) Viewed 15443 times

... alternative setup suggested by Hoglet and BDD works better, that's not to say your existing arrangement is incorrect -- it's not (as Garth points out later in the linked thread). That may seem paradoxical, but there are a lot of things that can cause funny behavior, and sometimes (especially when you're stuck) it's good to rock the boat -- to try something else. (There'll be some inadvertent changes along with those which are intentional.) I'm not convinced we're at that point yet, but anything that results in a happy outcome is fine with me.

What sort of power supply are you using? And do you have multiple bypass capacitors installed (as shown in the schematic)?

I agree HC logic is a better choice. BTW you can easily avoid the need for a 555 or DS1813 if you have an extra 74_132 section available. Here's a circuit from Garth's 6502 Primer (which is recommended reading, BTW). To replace the 'hc14 with 'hc132 just tie its two inputs together, or tie one of them high.

-- Jeff

GARTHWILSON wrote:

There's no problem in qualifying [ /CE ] with phase 2 unless you need the additional time before the rise of phase 2 when the address may already be valid. SRAM tends to be available in faster speeds than ROM or any of the I/O ICs on the board though, so that extra time is often not needed. If you're pushing the upper speed limit of the 65c02, the guaranteed advance address-valid time nearly disappears anyway.

[creoguy]

I've been powering it directly from the 5v FTDI cable that I'm using for communication with my computer. I've also tested it out with a 5v 2.5A cellphone supply that I modified with the same result. I have gone through Garth's primer, that is where I got the circuit for the 555 RST and also the setup for the VIA PA and PB output headers. I have bypass cap for all IC's as well. The 74HC00 came in the mail today, so I'll test it out later this evening and see if that make any difference before I start rewiring stuff.

[Dr Jefyll]

Nice looking project!

creoguy wrote:

Completed building up a 6502 SBC using this design. https://github.com/chrisabird/sbc65

I assembled his test code using cc65 to test out the VIA and the ACIA and they are working fine. I can modify the VIA code and can adjust the ACIA baud rate without any issue so the SBC appears to be fine.

Emphasis added. And IMO the schematic is entirely satisfactory, given that you don't need the extra speed that Garth mentioned in the quote I included above.

Quote:

After verifying all that I assembled the OS (EhBASIC 2.22) and enter in the normal Hello World test, but I can't get it to actually run anything. With "10 PRINT "HELLO WORLD", I get the follow message, "Type mismatch Error in line 10" when I attempt to run it. With "PRINT 1 + 1" the unit locks up and I have to reset.

Any suggestions on what to check next?

It's still possible you have a hardware error (construction related, I mean -- not the schematic per se). But what I notice is that chrisabird's test code works with chrisabird's hardware design but EH Basic doesn't. Have you got EH Basic configured so it uses the same I/O addresses as the test code? That's one thing that needs to be checked. (Also I'm curious -- how extensive is that test code? Can you describe it?)

From the schematic I see $5000-5FFF is filled with images of the ACIA register set, and $6000-6FFF is filled with images of the VIA register set. (The waste of so many addresses is harmless.) But addresses in the range $7000-7FFF cause both the VIA and ACIA to respond. If EHBasic is trying to use those addresses then the results are unlikely to be good!

-- Jeff

[creoguy]

I swapped in the 74HC00N for the 74LS138N with the same results. A hardware (wiring) issue is totally possible as this is my first major point-to-point wiring job. I've Ohm'd out the board a few time to verify it matches the schematic and even picked up a cheap logic probe to make sure I didn't have a stuck pin on one of the IC's.

As for the code, that is my weak point, and as such I'm can't really speak to how Chris has it set up. My understanding is the ACIA test sends out a constant stream of "A" over TX. The VIA test sets every other pin high on the VIA outputs. I bodged together some assembly code to use by the breakout board with LEDs to run a Cylon pattern, because who doesn't like some blinky LEDs! These all worked as expected. Here's the link to Chris's YouTube videos on the board working along with his build log. It appears he's updated the schematic to take into consideration all the issues he ran into during his buildup.

https://www.youtube.com/playlist?list=P ... KpdBFD-G78

As for the EhBASIC, I get the following when booting up...

Code: Select all

6502 EhBASIC [C]old/[W]arm ?C

Memory size ? 

15615 Bytes free

Enhanced BASIC 2.22

Ready
LIST


Ready
10 PRINT "HELLO WORLD"
20 GOTO 10
LIST

10 PRINT "HELLO WORLD"
20 GOTO 10

Ready
RUN

Type mismatch Error in line 10
Ready

So EhBASIC is starting up, receiving and sending text, it's just the running of programs that is causing issues. I'll start going through everything again to see if I missed something. I also have a new SRAM chip coming to match exactly what Chris has in his design, as I used a AS6C62256 vs. the CY62256N he used in case that may be the root of my issues.

[creoguy]

A note on the SRAM swap... I did wire it up using the AS6C62256 pinout vs. CY62256N as they are not the same.

[Dr Jefyll]

creoguy wrote:

So EhBASIC is starting up, receiving and sending text, it's just the running of programs that is causing issues.

Well, your ohmmeter tests indicate all the connections which should exist do, but perhaps you also have a connection which shouldn't exist. In particular I'm wondering about the address lines. If an address line were shorted high or low, or shorted to another address line, no fault would be apparent until the line is required to assume a value it can't. Maybe that's what happens when you hit RUN. The CPU "goes" somewhere it hasn't gone before, and in doing so it runs afoul of the the erroneous connection. It's slightly far fetched, but hardly impossible.

To detect this sort of error maybe you should consider a NOP Generator.

... although "AS6C62256 pinout vs. CY62256N as they are not the same" sounds a bit worrisome. Can you post or link to those datasheets please?

[creoguy]

Here are the two data sheets. The note was just to head off any questions if I had wired up the AS6C62256 using the pinout of the CY62256N, which would cause all sorts of issues!

[Dr Jefyll]

creoguy wrote:

Here are the two data sheets. The note was just to head off any questions if I had wired up the AS6C62256 using the pinout of the CY62256N, which would cause all sorts of issues!

It's bedtime and I'm sleepy, but I don't see any incompatibility between those pinouts. You're aware, I hope, that on a RAM it's OK to swap any address line with any other address line (and likewise OK to swap data lines with data lines)? Yes the data gets scrambled as it's written, but the complementary scramble occurs when the data is read back. Just checking! I'm pretty sure one of us is missing something.

[Klaus2m5]

Shouldn't this be a 32k RAM? EhBASIC only seems to see half of it. 15615 is $3CFF which should be correct for a 16k RAM. However EhBASIC does not run a full memory test to determine the usable space. So problems could already start within the detected RAM.

Unfortunately I am not aware of a simple RAM test. This would be the best thing to start with.

[8BIT]

NickH93 had a similar trouble with his system. viewtopic.php?f=12&t=4556

It ended up being a bad 65C02. He replaced it and EhBASIC worked. Put back the old one and the trouble returned.

Might be worth a shot if you have a spare.

Daryl