I built Rich Cini's version of Daryl's SBC 2.5 and have a really weird transient problem.

When I first start it up it will often lock up after a few seconds, but if it doesn't lock up it will be perfectly stable for hours at a time afterwards. Now at this point if I turn it off and on the instability will return and it will take several power cycles before it runs in a stable manner. However, at that point it is rock solid again.

My first thought was power supply, so I swapped it out for a different one with the same results.

I'm honestly a bit confused, as I would sort of expect an unstable system to stay unstable. So I'm not quite sure how to debug it. Has anyone else had experience with something similar?

I thought about taking the 6522's and the ATMEGA88 off the board and seeing if the problem still occurs. My other thought was swapping out the 65C02 for another one and seeing if the instability remained. I'm also using sockets for the TTL oscillators but I didn't clip the leads short. I'm not sure if that could be a source of noise.

When I soldered the board I was really careful to avoid any solder bridges or cold joints. I also went over the board with a magnifying glass to inspect it and ensure things looked good.

Do you have a multimeter? When I solder a board I always test the resistance of each hole in the socket to see if it is really connected to what it is supposed to be. I also measure resistance between all adjacent holes to find solder bridges.

Yes I have a multimeter and used its continuity test function to check for solder bridges and that the connections were correct.

What generates the reset signal to the 65C02 and 6522, and how long does it hold the rest circuit down after power on?


I've got the Ø2 oscillator socketed in POC V1.1 and did not clip the leads. The unit is stable to 15 MHz (30 MHz oscillator). Unless the aggregate circuit length from the oscillator's output to the 65C02 and 6522 is multiple inches, I highly doubt this is your problem.


Druzyek's suggestion about putting the DVM to work is a good one. I'd meter every single connection looking for the one with dubious continuity. Also, chips sockets can be flaky, so be sure to determine that you are getting solid connections from chip pins into the circuit.

Something else to consider: do you have any gates with floating inputs? Dunno what you're using for glue logic, but CMOS devices can behave badly if unused inputs are not grounded or tied to Vcc.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

That is an odd symptom - you're saying it does come out of reset and run some code?

Perhaps this page could give you some insight, or at least a quick smile:

http://user.xmission.com/~trevin/SiliconSlough.html

My favorite one is the J(UN)K flip-flop.

Mike

That reminds me of this history of programming languages: http://james-iry.blogspot.com/2009/05/b ... wrong.html

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Seems down, but there's a copy at http://www.netfunny.com/rhf/jokes/88q1/8972.html which attributes this to a BYTE article. Which can be found in Best of BYTE:
https://archive.org/stream/best_of_byte ... rch/slough

Cheers
Ed

That's exactly the symptom, but if it doesn't lock up it will run for hours.

This is a PCB and here's the schematic:

http://www.classiccmp.org/cini/my6502/6 ... r0_sch.pdf

Here's the parts layout:
http://www.classiccmp.org/cini/images/6502spc_v27.jpg

@BigDumbDinosaur it's using a DS1813-5 reset that I bought from Digikey.

OK, I think I've isolated the problem, although I don't know exactly what the problem is.

I removed VIA2, the ATMEGA88, and its oscillator which were used for the on board video display. I then loaded Daryl's original ROM instead of Rich's. I've been able to boot it up multiple times without an instability now. So it is somewhere in the onboard video.

I'm going to put the parts back while continuing to use the old ROM. If it remains stable then the presences of VIA2 and the ATMEGA88 don't cause any problems.

UDATE: I put back all components and while using Daryl's ROM the system seems completely stable. The ATMEGA88 displays its video startup screen, so that chip is working. At this point it's either a bug in Rich's ROM, the connection of the 6522, or the 6522 itself.

What's it actually doing after it locks up? If the CPU ends up in a (reasonably short) loop, you can use an oscilloscope as a logic analyzer to collect info on the bus activity, one bit at a time. Not as bad as it sounds; just keep a pencil & paper handy.

No guarantees -- the info you collect may or may not provide a clue. But it CAN be the key! I had a lockup problem recently and tracked it down to a faulty signal on an IO pin. The software was in a loop, waiting for a bit from an external timer to go true. Once I knew what it was waiting for, I easily found the problem (in this case, a flaky IC socket, as BDD just mentioned).

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

One thing I see in the schematic that might be of concern is the interface between the VIA and the ATMega88. Rich has CB1 and CB2 tied directly to the ATMega88. In my design of the handshaking, I used an external flip flop to hold the busy bit. Since the two systems run independently, I wanted to be sure the handshaking was controlled outside of both systems.

If you put all the chips back in and my ROM runs ok, then I would look at Rich's code to the video output. If it runs a loop waiting for the handshaking, its quite possible something got out of sync and the ROM code is waiting for something that already happened and it missed, or the ATMega88 didn't see something the ROM code sent and the ROM is waiting for something that will never come.

The big complication with the video firmware is that the AVR is not guaranteed to be ready for the next byte in "x" number of cycles. This is due to variable time needed to process each character input. Some may require just placing text while others require the whole screen to be shifted (scrolled). I have not looked at Rich's code to see how he is handing the handshaking, but that would able where I would start.

If you have a logic probe, you could examine the address bus to get an idea where the system is running. If its a tight loop waiting on IO, most of the upper address lines will be stable and you can see at least what page in ROM its stuck at.

To experiment even further, you could do a manual jump to the reset code using Rich's ROM when the system seems to have started correctly to try to get it to lock up. If it does, then that points to a software issue (which is again probably in the handshaking).

Good luck!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Oddly enough, I've just experienced about the same sort of thing this past week. I'm using the same 2-board system I've been using for over a year without any issues.

CPU board:
WDC 65C02
Alliance 32KB 70ns SRAM
Atmel 28H256 32KB EEPROM
74HC logic: 00, 30, 138
Half-size can oscillator (2,4,6MHz)
DS1815 reset chip

I/O board:
WDC 65C22
Synertek 6551
Maxim 238 RS232 interface chip
(or FTDI USB to UART DB9 connector)

In my case the problem started out as once in a while, then consistent after power up, then would run for a while, then crash with some bizarre scenarios.

The last thing I did was extend the IRQ BIOS with a RTC using the 65C22 timer set for a 4ms interval (250 times per second). It was working fine... but once in a while, after sending data to the console (6551) it would lock up. I narrowed it down to the RTC code running (versus it not running and the board being 100% stable again).

After chasing some earlier 65C51 noise problems, I decided to solder an additional bypass cap directly between pins 1 and 20 on the 65C22. Problem went away and the board has been running a large macro that endlessly sends data to the console at 38.4K (overclocked 6551), constantly fills, searches and erases memory, displays uptime (new RTC code) plus some memory and register dumps, all running at 6MHz. It seems anytime the 65C22 is generating HW interrupts, it creates a fair amount of noise on the supply and was corrupting memory and/or registers.

Might want to try adding some additional bypass caps directly to the DIP sockets, can't hurt to try.

_________________
Regards, KM
https://github.com/floobydust

Thanks Daryl, that's really helpful information.

I've been able to write an ehBasic sample that toggles some of the 6522's pins. Now I've seen microcontroller's have the occasionally flakey pin, but given that this works once it is stable, I think software is much more likely than hardware at this point. To me the most likely point of failure is the character out routine because that has a tight loop waiting for a bit to set. Here's the code:



I don't like this code because what happens if VOutput is called with an accumulator value which doesn't have bit7 set, then I think the bit instruction won't result in a proper test of the handshake and the code will fall through. By comparison some code you wrote was much more explicit about the masking of the bit:

Martin, the BIT instruction is tricky because the flags are affected in two different ways. The Z flag is updated according to the result of ANDing the accumulator with memory. But the N and V flags get updated directly from memory bit 7 and bit 6, respectively -- they do not reflect the result of the AND operation. So, the accumulator value has no bearing on the result in N and V.

This makes BIT instruction useful and versatile... but also slightly misleading!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html