Recent content by per

Datasheet lists 1500 KHz as maximum data clock source for this particular model, so you're overclocking it just a little. You might have snagged on a edge-case timing case internal to the chip which you might not have hit at 2000 KHz E clock.

While keeping formal paperwork may not be expected when running a private archive on a voluntary basis, not having any agreements is bound to cause conflicting assumptions at one point or another. It may well be that a donator and archivist have a mutual understanding of the nature of the...

I was wondering if anyone recognize which company made the Audio/Video/Power connector of the Luxor ABC80. See the images for details.

It is worth noting that the 74F series of chips are quite fast devices, and are known source of flakiness if the hardware is not designed to handle the sharp/fast transitions. If your replacement chip is too new, then it might for instance be a little bit quicker and have a little more RF...

From what I have found, it is clear that BC40 points to character output routine at least. But yes, it's weird. It almost seems like someone used the Poly88 version and adapted it for a different machine or something. Eventually it may expect a later version of the support ROM. I won't have the...

In other words, I am in no doubt that this is FDOS-III, but as I mentioned it might be the raw output from a build rather than a finished system disk. You may have to pack the binary files in an executable format the support-PROM can deal with, and write them to an empty disk formatted with a...

There is a string in the EXEC binary that literally reads "ICOM FDOS-III POLY88 VER. 1.0", while the writing on the disk itself is "System III 32k 9.8, FDOS"

If I remember correctly, the diagnostics utility should be part of the standard IBM Diagnostics disk versions that came with the PC/XT or PC/AT Guide to Operations after 1984.

I've had electrolytics fail dead short as well a few times, but luckily not in any places that caused carnage to other components around it. Usually it's either been stuff like triggering current-protection of the PSU, or flatlining half of my CRT image.

Ok, here is the files, if you want a look at them. The memory image bin files are just the hex imported as binary, using absolute addresses. Everything seems to load at 0x2100 and onwards as mentioned, so all the bin files start out with a lot of empty space as a result.

Yes, I made a disk image already. Pretty standard IBM3740, as mentioned formatted with a basic Intel ISIS file system. From the looks of it, it seems like someone had the source code for FDOS-III on an Intel Intellec, and just assembled it to hex there. I say this because of the file-system, and...

As posted in the DEC forum, I am archiving a pack of 8" floppy disks I came over. While most of those disks are for the PDP-11, one of the disks seems to be a release of FDOS-III for the Poly88. Does anyone here have experience with this? I don't know enough about this system to say if this...

Since these are all RX01, my plan is to convert them to sector-images, that would be with the software interleave in place (the FM/MFM decoder I use undoes the hardware interleave for this, if present).

Right, was looking at this at late night, my bad. On second glance I see now that the HW sectors on the DEC disks are sequential.

Got the imaging going. More or less all disks seem to be single sided, about half of them flippable. Looking at the data, am I right that these are both hardware- and software-interleaved? That seems quite a bit like an odd choice.. Also, most of the difficult to read sectors seems to be...