Guys --

I took Daryl's sample code and dropped it into the ROM so that I could prove that video output worked. I didn't do the kind of stability testing that would have revealed a timing condition such as this. I would bet that it's the software that waits for the chip to be ready as Daryl points out. The previous hardware design had an additional chip or two. If we discover that the flip-flop is again needed, I think there's room on the board for it.

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org

@Jeff, thanks for the explanation, that makes sense.

@Rich, no worries things went too smoothly so far, so some hitch had to surface. I don't have a logic probe or oscilloscope, but I might be able to program a microcontroller to act like a bus monitor and tell me what the CPU is up too.

I was able to get your ROM compiling under the Java As65 with a few minor tweaks to the op codes and making sure the label cases matched the references. I was also able to get TASS working on 64 bit Windows 7 via DOSBox 0.74. So I can build new ROM's and try and debug this, but I'm out of time today.

Great news Martin on getting a compiler working. I sometimes use Microsoft Virtual PC or DOS-Box for stuff like that. There is also a native 64-bit version of TASS (the Table Assembler) that I use quite a bit, too.

Keep us posted on what you find out. If there's an easy software fix, I'll make it a permanent part of the BIOS.

Thanks!

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org

Good idea -- the microcontroller is a useful tool. But it would take a lot of connections to monitor all the bus lines, so it would be time consuming to set up a bus monitor.

An easier test that's almost as good is to merely halt the CPU and then read the address bus using a multimeter or even an LED. That would reveal just a single address, but it'd probably be enough to tell you where the program is getting stuck.

The microcontroller could either pull RDY low, or, if it were set up to generate the 6502 clock, it could merely cease generating clock pulses at the appropriate time. Ideally you would only halt when SYNC is true, although that could be accomplished just by running repeated tests until you get lucky.

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

If you want to single-step the 6502, look in the original KIM manuals -- it has a simple circuit you can use to do that and it can be grafted onto the SBC with not a lot of trouble. I actually toyed with adding an "SST" connector but I never got around to it.

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org

Plus, with the 65C02 and 65C816 you can do something like:

Code:

          lda some_register
          bpl did_not_interrupt
;
          bit #some_mask
          beq not_an_irq_source

This gives you the ability to load a register and make multiple non-destructive tests on the value read from it. Also, BIT <zp>,X and BIT <addr>,X are possible.

Indeed, as Jeff notes, BIT is very useful and versatile.

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

I believe I've confirmed that the problem is in the VOutput routine in video.asm. Here's my methodology:

* Test 1 - I removed all traces of video.asm from the ROM and the computer worked flawlessly for six restarts.

* Test 2 - I added back video.asm, but didn't call the initialization function, and again it performed flawlessly.

* Test 3 - I added back the call to VInitDisp and again the ROM performed perfectly.

At this point there's only one difference between the ROM that fails and the one that works:

So I would say that confirms the hunch that it's a problem with the ATMega88 ability to process characters and the synchronization code in the VOutput routine. I'm not sure what to do about it yet, but at least I have a solid ROM and understand the problem. In reading VOutput the problem could be either in the wait to be available, or the wait for the ACK. My guess is it's the wait for ACK which is missed because of the lack of a flip flop. Which raised a question why wait for an ACK?

Note that I had one lockup that I attributed to PuTTY weirdness and not the computer ROM. Sometimes PuTTY gets confused when you tab between windows and isn't able to process keystrokes afterwards. The lockups I experienced occurred while you were typing in the terminal window.

Does anyone have a pointer to the firmware for Daryl's single-chip ATMEGA88 video controller? I want to read through it to understand how the synchronization is supposed to happen.

I have it but I believe it's on the video controller page on his site.

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org

I poked around on Daryl's site before asking and could only find this one:

http://sbc.rictor.org/vid3.html

From the schematic and code sample it looks like it uses a parallel interface while yours uses a shift register. Do they use the same firmware?

Hi Martin,

I have to confess that I had a huge memory lapse. My first look at the schematic you posted last week was evidently too quick. I did not notice it was using the serial interface and just assumed it was the parallel one. I feel even dumber because I provided the video circuit to Rich which included the serial interface but somehow forgot that point!! Sorry Rich, been so busy - didn't mean to leave you hanging out there!

I have not posted the ATMega88 firmware that uses the SPI port for input. I actually wrote that code originally for my graphical video display but never really worked that to completion.

I collaborated with Rich to get the ATMega88 working with the 65C22 SR. After initially testing the code I developed, I discovered the handshaking was an issue. I added a timer to the AVR firmware to ensure the AVR kept the busy flag high long enough for the SBC to see it. At that time it appeared to have fixed the problem.

I have not looked over the code Rich published. I am attaching a copy of the latest code I had worked on.

Let me know if you have any questions. If I don't respond, send me PM.

thanks!

Daryl




I have attached that code I sent Rich.

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

The code I'm using is Daryl's code I didn't make any modifications to either the chip firmware (other than selecting the Apple font) or the driver code that I grafted into the system ROM. So, if the version that Daryl just posted is different, then I need to merge that in. I guess I should WinDiff it and see.

PS...just WinDiff'ed the code. The firmware looks fine other than the addition of the alternate font in the new version. The differences are in vid2c.asm. The initialization of the 6522 is different, but I really haven't done a deep dive to understand the change. The schematics are fine.


Thanks guys!

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org

Thanks Daryl and Rich, this is making more sense now. Rich has confirmed he's using the same firmware with the exception of an additional font. Since the font shouldn't alter timing, let's assume it is not the issue. In looking at Rich's VOutput routine and the one in Daryl's ZIP they're in same ballpark now, with one small difference.

Here's Rich's SBC 2.7 OS:

This is in Daryl's firmware ZIP archive:


They're identical except for what looks like a substantial delay loop before the rts in Daryl's code. That loop could significantly slow the 6502's frequency of VOutput calls, but the SBC 2.7 OS is doing a whole bunch more than Daryl's sample. For now I'll assume the two VOutput routines are effectively identical.

Which makes me think the ATMEGA88 firmware is getting wedged and never altering the pin state. I was looking at the schematic and it claims that the ATMEGA88 is reset when the 6502 is, but I've noticed that often the only way to get the system unstuck is to power it off and power it back up again. I don't know if that is significant or not.

Martin --

Can you try your test with the delay that's in Daryl's output code?

Rich

_________________
Rich Cini
Build Master and maintainer of the Altair32 Emulation project
http://cini.classiccmp.org
http://altair32.classiccmp.org

I just did. It looks like 300 baud TTY and it still locks up.

I can also confirm that after it locks up power cycling it is the only way to get it to work again. The hard reset or panic buttons won't cut it.

I haven't completely eliminated the 6522 as a suspect, because it is between the ATMEGA88 and the 6502. But I would think it would fail more like a lightbulb than work and then lock up like this.