6502.org

How did you know the story of my life ?!?!
Have you been in secret contact with my friends or family?

Mike

I warned you that Facebook is insecure and I told you Windows was easily cracked. Yet you stubbornly insisted on using them. Now it's all out there for everyone to read, including the NSA and MI5.

POC V1.1 achieved 300 days of uptime in the early AM hours.

For those keeping track, Dec 10 will be the year date. Let's home for stable power through then.

Funny you mention that. The power supply that runs POC is plugged into the 1.4 KVA UPS that keeps our two servers going. Unless a protracted outage (>1 hour) occurs, loss of power isn't likely. If anything, me doing something boneheaded and crashing the unit is a more likely scenario.

I've been wanting to make some changes to some of the BIOS primitives that would compact the code and make it run a bit faster, but held off on doing so in order to see how far I could push the uptime. I decided to bring the uptime saga to an end, as I also wanted to change a SCSI primitive function in a way that would/might allow me do an ISL from tape. So I decided to burn a new ROM and try it out.

POC V1.1 had reached 306 days, 13 hours and 21 minutes at the time of shutdown.

Arguably, this is better progress. There's always next year to go for an uptime record. Now you can focus on the shortest uptime as you start making changes and improvements.

I figured that 306 days demonstrated that hardware stability isn't an issue. Making it a full year would be something to crow about, but trying to do so was impeding progress.

Last year I replaced the NXP SCC2692A dual UART (DUART) with the SCC26C92, which has a number of added features. To quote from the NXP data sheet:

• Its differences from the 2692 are: 8 character receiver, 8 character transmit FIFOs, watch dog timer for each receiver, mode register 0 is added, extended baud rate and overall faster speeds and programmable receiver and transmitter interrupts.

Not mentioned was that the 26C92's response to the control inputs (chip select, etc.) is substantially faster than the 2692, which allows a high Ø2 clock rate without wait-stating.

The interesting improvements are in the FIFOs and the higher supported communication rates. The receiver FIFOs are also present in the 2692, but can only buffer four bytes. The transmitter FIFOs are new and create an opportunity to reduce the overall interrupt processing load when a lot of output is being generated, e.g., when a full-screen paint is required. Whereas the 2692 had a one byte transmit buffer and generated an IRQ each time a byte was serialized and shifted out to the TIA-232 interface, the 26C92 makes it possible for the IRQ part of the DUART's driver to keep stuffing bytes into the transmitter FIFO until the DUART says it's full, after which the IRQ handler can go on to something else and not return until the FIFO is empty. The result is that a lot fewer IRQs will occur during transmission.

Also worth noting is that the 26C92 supports extended baud rate tables, with a maximum standard speed of 230.4Kbps versus 38.4Kbps [edited] with the 2692. By coupling the receive and transmit clocks directly to the built-in counter/timer and setting the latter to the minimum underflow period of 1.8432 MHz (the X1 clock divided by 2), reception and transmission at 921.6Kbps is possible—if the system can stay with an interrupt rate of about 11,520 per second per channel. As the 26C92 can be set up to operate in TIA-485 mode, a non-Ethernet local area network running at an effective rate of about 91KBps could be rigged up with a little programming and suitable line drivers. While that's nowhere near the speed of 10Base-T Ethernet, it's still plenty fast.

I finally got around to reworking POC V1.1's DUART driver to take advantage of the 26C92's improvements (the holdup was my now-abandoned quest to achieve a year of uptime with POC V1.1). As part of the rework, I am now running the console port at 115.2Kbps, which is the maximum speed supported by the ADDS terminal I am using as a console. I've also increased the auxiliary port speed to 115.2Kbps for testing purposes. The console port speed increase doesn't increase the apparent terminal display rate, since that is influenced by design factors unrelated to communication speed. However, the tripled communication speed on the auxiliary port is very noticeable when transferring a lot of code from my UNIX development machine.

The Equinox SST serial hardware in my UNIX server can support a maximum speed of 230.4Kbps simultaneously on all 16 channels, which speed also happens to be the highest at which the 26C92 can be run using the standard baud rate generator tables. Sooner or later I'll give 230.4Kbps a try on the auxiliary port and see if I can transfer a program without error at that speed.
———————————————————————————————————————————————————————————————————————
Edit: The 2692's maximum speed using the standard baud rate tables is 38.4Kbps.

Later became sooner. Transfers at 230.4Kbps run error-free. A 1KB program loads almost in an eye-blink.

In a related test, I temporarily patched POC V1.1's console port to the serial port on my PC workstation, fired up Dynacomm (a commercial grade terminal emulator we install on client PCs for connection to Linux servers) in WYSE 60 compatibility mode and used the PC as the console. The effect of running the console port at 115.2Kbps is much more evident than on the ADDS terminal, as screen painting seems to happen almost instantaneously.

Here's a crude video of POC V1.1. It's not publicly-accessible. Eventually I'll do a different one at a higher resolution.

Nice one BDD. Interesting that you display IRQV in your monitor - is that because your plan is to keep modifying it depending on what the OS is doing? (The PET did something like that, as mentioned in another thread)
Cheers
Ed

Thanks. When I shot the video I inadvertently did so at 320x200 resolution, which is why the picture quality isn't quite up to BAFTA and Oscar standards. As soon as time allows, I'll produce a new video at 640x480, which should make it a lot easier to read what's on the screen.
I originally did that because as I was debugging and testing my SCSI driver, I needed a visual indication of when the SCSI interrupt service routine was wedged into the firmware ISR. One time when I was debugging I forgot to run the code that disengaged the SCSI ISR. When I went to load a revised driver I crashed the machine when the currently-executing ISR was overwritten by the new version. So I arranged the monitor register dump to display what was in the IRQ indirect vector at $000106. If it shows $E8FC or thereabouts, then the indirect vector points back into the firmware.
So did Jim Butterfield's SuperMon. The C-128's resident monitor didn't display the current IRQ vector, which should have been included in the software. Every once in a while I'd make the above mistake of overwriting the test IRQ handler while it was still wedged into the kernel's ISR.

Speaking of IRQ vectors, one of the handy things about the 65C816 is that there is no need to bracket an IRQ vector change with SEI -- CLI if the new vector is set up with a 16 bit write..

Good point about the atomic vector write!

After hearing your voice for the first time, I'd have to say that you sound more like a big smart dinosaur than a big dumb one!

Mike