Hi Jeff
I know it's asking for something, but could you put together a new head post on Lancaster-style DMA? Shifting one byte per cycle is even better (and the operand can be the same as the opcode, so it's no more complex)

Cheers
Ed

I'll see what I can do, Ed -- I haven't forgotten. I can't get to it right away, unfortunately. But a new topic would prevent the POC from getting derailed.

That's right. I see you've been paying attention!

-- Jeff

Well, it's been close to three months since I last powered POC V1. Just for grins, I flipped the switch. The unit ran through POST and the SCSI hardware all checked in. For some reason, the date and time are way off. Something had to have tinkered with the watchdog with an improper write operation. Hmmm...a new hardware problem or a bug in the BIOS code?

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

Or the usual problem - drained BIOS battery? ;-)

Apparently not.

I checked the "battery good" bit in the watchdog's status register (has a built-in lithium ion battery) and it is set, meaning the battery voltage is in range. I reset all the clock registers and loaded a data pattern into NVRAM (256 bytes), powered down and disconnected the unit from the power supply. I'll come back to it in a few days and see if anything has changed.

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

Okay, I powered the POC unit this morning, only to discover that the watchdog timer is fine. It correctly set the console clock and the data I had loaded into NVRAM was intact. That rules out the battery as the culprit.

Next step is to leave this thing running and see what develops. I'm suspecting a bus glitch may have triggered a spurious write operation to the watchdog. Time should tell. Yeah, yeah...bad pun.

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

It's still running and nothing untoward has happened. <Scratching Head>

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

The uptime counter is 13 days, 2.6 hours, and nothing weird has transpired. I tried reading a few blocks from the hard drive and that's all working. There is no sign of the instability problem that I thought was present. Maybe there's a hinky solder joint that reacts to environment changes and makes the unit go wacko. Oh, I know! It's the price of gas that's doing it. <Scratching Head>

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

Maybe it's picking up cell transmission or maybe a cordless phone in close proximity to your board?

The nearest cordless phone is in the master bedroom, which is about 25 linear feet from my office, in which the POC unit is installed. As for cell transmission, it's very poor in my office -- I never use my cell phone in my office in any case.

The unit is close to the ATX power supply that runs it, but those power supplies are not supposed to emit EMI in a quantity sufficient to upset digital circuits.

This one's a puzzler...

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

Uptime is now more than 21 days and still no sign of any trouble. This is weird. If there is a hardware problem surely it would have reared its ugly head by now. Maybe there's a bug in the IRQ service code that only shows up under certain conditions. I can't imagine what those conditions might be. IRQ services RS-232 I/O and jiffy interrupts (100 per second), and if there were bugs in those I would have run into them long ago. I'm still thinking hardware...

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

Uptime is now 32.6 days and absolutely nothing untoward has happened. The past instability problem I thought I was seeing has not materialized and all functions are working, including SCSI I/O. Baffled...but maybe relieved. Time to move on, I guess, and get busy concocting a basic filesystem design so I can store stuff on the disk without having to manually address by block. In other words, it's time to make POC work like a real computer.

I do have one hardware issue to solve and that is attempting to access the SCSI controller's FIFO through the chip's DMA channel doesn't work. I see the correct setup lines are being diddled when I execute an instruction that is supposed to do a direct FIFO read or write but nothing happens. First step will be to slow down Ø2 to 1 MHz to eliminate any timing issues (Ø2 is currently at 8 MHz). If that fixes it then I will progressively increase Ø2 until failure occurs. The odd thing, though, is that my I/O timing, at least according to what I worked out, is well within the 53C94's specs. Hmmm...

As far as a filesystem goes, I think I'll model my initial attempt on the UNIX S51K example, but with 512 byte sectors (the old PDP series used 1K sectors because that's the way the disk subsystem worked). I will deviate in two regards:

S51K directory entries were limited to 16 bytes, of which 14 were for the filename. I will increase the directory entry size to 32 bytes, with 30 available for the filename.

S51K used the concept of clusters (usually 4K per cluster) for the basic unit of storage. As clusters are wasteful (4K would be consumed to store a 1 byte file), I will use the disk sector (block) size as the unit of storage. Space near the beginning of the filesystem will be devoted to a bitmap that will keep track of sector allocation.

S51K was a simplistic filesystem by today's standards, yet was quite robust. Once I've gotten more efficient SCSI I/O in place I will look at modeling a more up-to-date filesystem. Right now, the objective is to develop a working means of storage. So it's off to the land of hexadecimal and low-level bit twiddling!

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

Hi, BDD
This is certainly a puzzling situation, and you've been unable to re-create the problem by leaving the unit powered off for an extended period. But maybe the problem would appear if you cycled the power on and off repeatedly. Can you rig up something that would let that happen automatically, and let it cycle for a few days? I could be way off base, but you see what I'm getting at -- maybe it's the transition that's problematic. Don't ask me how or why; I admit I'm grasping for clues. But that's what you do when you're stuck, troubleshooting...
-- Jeff

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

Actually, the unit has been continuously powered in an effort to track down the stability problem, as I had discovered it after the unit had been up for about a week. Right now the interrupt-driven uptime counter is a hair over 33 days and everything seems normal.


That sounds like something worth trying. Right now I'm using an old ATX PC power supply, whose output is clean as a whistle (I checked it with the 'scope). As the past instability issue didn't seem to be a case of momentary power interruption, I didn't give it a second thought. However, it may be the buses are being diddled in some strange fashion right at power-on. Even there I'm grasping at straws. I used a Dallas 1813 econo-reset, which holds /RESET down for 250 ms after power on or after the reset button has been pushed. 250 ms should be more than enough time for system voltages and the Ø2 clock generator to stabilize before the MPU starts executing reset code.

I had also looked at the idea of a thermal issue being present. However, the only device that has significant power consumption is the 53C94 SCSI controller, and it barely gets warm to the touch. Everything else is very low power—minus the SCSI host adapter, the entire POC unit consumes less than 100 MA. And now it has been powered up for more than a month with absolutely no problems arising. A thermal issue just doesn't seem likely.

It seems if the now-elusive problem is related to power-on I need to rig up something that can cycle power at periodic intervals. The only power used by the POC is 5 volts, so free-running timer that interrupts the 5 volt supply, waits a short while and then reapplies the juice would do it. I'd also have to write a simple program to log each startup to the disk. Since the POC's reset code attempts to boot an OS from the disk at the tail end of reset, it seems logical to have the logging program be loaded and run from the boot sector (sector $000000), and just write data into other disk sectors—there's currently no filesystem in place, so it'll be raw reads and writes. This will take a bit of planning.

More work...

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

I used to work with someone whose standard semi-serious explanation for such things was "cosmic rays!" There was a time when alpha particles were a problem, depending on the materials used in packaging. I think 'single-event upsets' is the general term - it might be worth considering that this wasn't something that can be tracked down.

Cheers
Ed