ICOM FDOS-III for the Poly88

[per]

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 ability to read the 5.25" disk soon, but maybe that has some more clues...

 

[deramp5113]

Today, I did a bit more work on disassembly of those sections of EXEC involved in disk I/O. It expects several functions not present in the PROM shown in the manual, and some of the functions it expects change/overlay existing jump vectors to do something else. Maybe they were trying to make FDOS work with a 5.25” controller instead of the iCOM controller and the 5.25” disk you have is the executable version of that effort.

Mike

 

[per]

I finally had the chance of dumping the 5.25" disk. It's single-sided, 35 out of 40 tracks used, single-density (125kbps FM), 16 sectors per track and 128 bytes per sector for a total of 70kb storage space.

The label reads as following:

SYSTEM-III 32K / 9.80

NAME   ATTR TRAK SCTR  SIZE

EXEC    00   05   01   00048
SYSGN   00   08   01   00017
HABMO   00   09   02   00007
FORMT   00   09   09   00012
COPY    00   10   05   00009
MTDK    00   10   14   00016
RDBFL   00   11   14   00009
EDIT    00   12   07   00031
ASMB    00   14   06   00081
LINK    00   19   07   00029
LIB     00   21   04   00018
DREHZ   00   22   06   00011
DKHN    00   23   01   00016
BASIC   00   24   01   00164

00012 SECTORS FREE

 

[deramp5113]

Good stuff! As we were surmising, it appears the FDOS files on the 8” disks are the files you need to build an FDOS 5.25” disk. Most likely, the hardware required is the iCOM MicroFloppy controller.

deramp.com

deramp.com

I may know someone who has the required controller. I’ll ask.

Mike D

 

[per]

I have looked a bit closer, and in general it seems like the whole disk has a static 1:4 soft-interleaving for its sectors. In addition to this, it seems like the executable binary files are divided into chunks separated by 6-byte headers, where at least one word (offset 3) is the load address of the chunk and one byte (offset 2) is the length (usually 32 bytes).

And yes with this in mind it seems like a good binary match with the hex-files from the 8" disk

 

[per]

Good stuff! As we were surmising, it appears the FDOS files on the 8” disks are the files you need to build an FDOS 5.25” disk. Most likely, the hardware required is the iCOM MicroFloppy controller.

deramp.com

deramp.com

I may know someone who has the required controller. I’ll ask.

Mike D

In the case, I think it would be beneficial if they had the ability to dump the EPROM on it. Being a FD1771-based design, it should be fairly simple to wrap your head around it, or even reproduce something compatible.

 

[hjohnson]

OK, that’s an important answer. As I mentioned, the FDOS-III manual says the support PROM is at C000 (for the Poly-88) and the support PROM listing in the FDOS-III manual matches the PROM I have. That PROM listing, in turn, says it’s for “8080 Altair/IMSAI/Poly 88 FDOS III Version 1.0”. However, the EXEC file from this disk (FDOS command processor) expects the PROM to be at B800 (in disagreement with the manual) and calls a couple of invalid entry points in the PROM as listed in the manual. Unfortunately, this version of FDOS-III for the Poly-88 appears to be slightly different than documented in the FDOS-III manual.

Mike D

Responding after the thread paused, but I saw this today and had a consideration. It was a trick or dodge in the era, to make some memory space at the top of memory near whatever BIOS was in use, by relocating whatever OS in use a little lower in memory. The space became either resident code, or a "jump table" in order to patch the jumps intended for some fixed ROM code, to some new/modded RAM code instead.

So is it possible, the point of "calling the PROM" at B800H, was a means to *patch* the actual PROM at C000H by changing the jumps at B800H to that modded code? And evidence supports this as it, "calls a couple of invalid entry points in the PROM".

If so, there will be some kind of patch code file somewhere which runs near B800H; or one will have to be synthesized.

Regards Herb Johnson

 

[per]

Responding after the thread paused, but I saw this today and had a consideration. It was a trick or dodge in the era, to make some memory space at the top of memory near whatever BIOS was in use, by relocating whatever OS in use a little lower in memory. The space became either resident code, or a "jump table" in order to patch the jumps intended for some fixed ROM code, to some new/modded RAM code instead.

So is it possible, the point of "calling the PROM" at B800H, was a means to *patch* the actual PROM at C000H by changing the jumps at B800H to that modded code? And evidence supports this as it, "calls a couple of invalid entry points in the PROM".

If so, there will be some kind of patch code file somewhere which runs near B800H; or one will have to be synthesized.

Regards Herb Johnson

That might be an interesting consideration, but looking in the manual for the iCOM microfloppy controller that was linked to, it does indeed have some EPROM at B800 to BBFF. If the assumption that this controller is the target for this build holds, I'm pretty certain this "patch" will be in there in the case.

 

[hjohnson]

That might be an interesting consideration, but looking in the manual for the iCOM microfloppy controller that was linked to, it does indeed have some EPROM at B800 to BBFF. If the assumption that this controller is the target for this build holds, I'm pretty certain this "patch" will be in there in the case.

I don't want to add to confusion, but here's another source of ICOM FDOS materials:

Rich Cini's Classic Computing - IMSAI System

Look in the section "Disk Drive System: iCOM "Frugal Floppy" dual 8" drive system." That includes a list of the following documents:

Synetic Design Company FDS-2 Binder:

• Synetic FDS-2 Core Manual
• Operator's Guide - FDOS-II
• Operator's Guide - iCOM Macro Assembler
• Operator's Guide - Text Editor
• Operator's Guide - Text Editor rev. B
• FD360/FC360 Controller/Formatter Maintenance Manual
• FD360/FC360 Schematic Diagrams
• 
  

Yes, these say "FD360" and "FDOS II". But the "operators guide FDOS II" amounts to this manual

http://cini.classiccmp.org/pdf/iCOM/iCOM%20FDOS-II%20Manual.pdf

which actually is "Operator's Manual iCOM Microperipherals (TM) FDOS-II forSBC/8800/Altair/IMSAI/Poly88" . It describes building an FDOS-II system on a FD360. As noted earlier the FD360 has a ROM which starts at C000. Thus my confusion (perhaps other's confusion) in my earlier post about the apparent ROM address for the FDOS-III codes as discovered on the disks in discussion. Nonetheless, these FDOS-II manuals may be informative.

These also appear on the dramp Web site at:

deramp.com

deramp.com

And of course on the dramp site is a manual which while FDOS III may not fully cover the target hardware:

https://deramp.com/downloads/altair/hardware/icom_floppy/iCOM%20FD3712/Pertec-iCOM_FDOS-III.pdf

A careful read of the page 1-1 on "Loading FDOS-III" shows a table of FDOS-III environments - Intel MDS, Poly, Sol, Altair. Each has a resident PROM at some address. Also note, they use various floppy controllers (not specifically listed in that table). Obviously a Multibus system isn't going to use an Altair bus (S-100 as later known) controller. Code examples in that document may reference *different* target hardware: it has to be read carefully to navigate possible choices.

Point being, these early 8080 floppy operating systems were not as orderly as later CP/M-80 OS's. They did not have a strong hardware-isolating BIOS. Methods of bootstraping an OS onto a target were complicated at least. Documentation was ambiguous at the time, and now is often found in isolation from software or hardware. Documentaton and codes referenced all kinds of hardware dependencies, which were not well-described by later BIOS-isolating standards. So our confusion about target hardware is understandable.

Perhaps at this point, enough code has been examined and disassembled to identify the development computer (ISIS on Multibus) and target hardware for the found software. Even so, if documents and sources are absent, then reference to related FDOS and iCOM work may yield some useful information and prior or subsequent codes.

Short of my doing independent disassembly (kinda redundant and I have other work), I'll just point to these resources, suggest this strategy, and leave it to my colleagues to follow up. IT's good to find another source of early S-100 floppy OS software. Thanks from me for working this.

Regards Herb

PS: Thanks for Rich Cini for uncovering these FDOS II and related "frugal floppy" materials, as I discussed them with him at the time he restored an IMSAI with that hardware:

Icom "Frugal Floppy" of Rich Cini

 

[deramp5113]

Rich’s FDOS material is for the 8” FD360 (iCOM) or FD3712 (Pertec). I reached out to Rich to borrow and archive any FDOS disks he had, but by the time I did, he had already donated the system and materials to a museum in NJ. Rich and I spent about a year (2022-2023) trying to get Rich’s contacts at the museum to find the material he donated, but we were never able to get much action out of the museum.

The FDOS disk in this thread is FDOS-III for the iCOM MicroFloppy (5.25” disk) instead of the 8” FD360 and FD3712 FDOS that Rich had. The 5.25” disk is configured for a Poly-88 computer. I have found someone who has the iCOM MicroFloppy controller that FDOS expects and he’s sending it to me soon. I have a working Poly-88, so maybe we can get this copy of FDOS-III up and running!

On a side note: Rich, if you see this thread, stop by the museum and see if you can find your FDOS disks yourself

Mike D

 

[deramp5113]

I received the iCOM MicroFloppy controller and have disassembled the EPROM on it. The EPROM entry points called by the EXEC of Per’s FDOS-III disk line up as expected with this EPROM. That’s good news. However, this EPROM expects an Altair 88-SIO for the console serial port and the changes required to support Poly-88 console I/O appear to go far beyond simply calling the equivalent Poly-88 console routines. I’ll have to dig deeper to figure out why.

Here’s the disassembly https://deramp.com/downloads/altair/hardware/icom_floppy/iCOM FD2400 Microfloppy/

Mike D

 

[deramp5113]

A careful read of the page 1-1 on "Loading FDOS-III" shows a table of FDOS-III environments - Intel MDS, Poly, Sol, Altair. Each has a resident PROM at some address. Also note, they use various floppy controllers (not specifically listed in that table). Obviously a Multibus system isn't going to use an Altair bus (S-100 as later known) controller. Code examples in that document may reference *different* target hardware: it has to be read carefully to navigate possible choices.

FDOS was created for and by iCOM for their FD360 disk system (8 inch floppy, IBM 3740 compatible). The FD360 was later repackaged by Percom as the FD3712. The controller for this disk system was actually in the disk drive cabinet and remained the same no matter what computer it was used with - even 6800 computers and mini-computers. The only hardware required in the host computer was a parallel interface board, so as far as the resident PROM for FDOS is concerned, the difference in that code between these various machines is surprisingly minimal.

The version of FDOS we’re looking at in this thread, however, is specifically for the “new” 5.25 inch MicroFloppy controller made by iCOM for S-100 systems. Because the controller interface to the MicroFloppy controller is completely different than the parallel interface to the FD360/FD3712 drives, the listing and other info about the resident EPROM that we find in the FDOS manual does not directly apply. I have not been able to find an FDOS manual that covers the 5.25 inch versions.

Mike D

 

[deramp5113]

I was able to use the original system files for FDOS-III found on the ISIS 8” disk to recreate bootable 5.25” disks that can run on an actual Poly-88. The same system is then easily sysgen’d to run on an Altair, IMSAI, etc., but code all starts at 2100h (as required for the Poly), so it wastes the bottom 8K of memory space in these other machines.

I still have more work to do to get disks built with “Binary Hex” system files so that less space is wasted on these tiny 1st generation 5.25” disks.

Thanks for recovering these files - it’s the first FDOS of any kind I’ve been able to find.

Mike D

 

[per]

Nice to hear it could be of help! There's just so much diversity among the early micros that are lost because nobody kept stuff in use once things got fairly standardized with popular platforms.

Did you have a look at the files from the already prepared 5.25" disk? Not sure they are sys-gen'ed for the Poly88, but those appear to be in this "binary hex" format you mention.

 

[deramp5113]

Yes, I used that disk as-is to begin with, but it requires special code at 400h-800h and some additional code on the 9E00h page (in addition to the binary loader code that gets loaded at 9Fxxh via S-records at the start of each binary-hex file). I loaded patch code I created into those locations to make the disk work, but this is clearly not how the original distributions worked. I decided to move on from that disk an attempt to recreate something closer to what the original distribution disk might have been.

I noticed there are two additional files on your 5.25” disk that are not on the 8” ISIS disk. I’ll extract those two files and create S-record files for them as well.

Mike D

 

[Bruce Tomlin]

So I got interested in looking at some of this with a disassembler. I noticed very quickly that the MS-BASIC is a 4.x Extended version, with quite a few things similar to the BillG 3.0 listings drop of this year. TRS-80 Level II BASIC is an example of a 4.x Extended, but this one has the new split keyword table and tokenized constants. For all I know it may be one of the earliest versions with the new tokenizer, but there aren't really many dates on these things. The TRS-80 version was from 1978, so this one is probably from 1979 or 1980. That disk image has "9.80" in it, which sets the upper end of its era. CP/M 5.21 has a 1982 date.

I was able to apply labels to most references by using both the BillG and CP/M 5.21 sources. It's always interesting to see which parts change between versions, and how they change. Some parts barely changed, some it seemed like they couldn't keep their fingers out of and are rarely the same, and others were probably due to adding Z80 relative jumps into the PDP-10 sources.

This is a very obscure operating system. I did a quick search of my Byte PDFs and FDOS was barely mentioned. The only real mention outside of ICOM ads was 1979-04 page 194. There were at least three other FDOS, one of which was the redundant term for CP/M's BIOS plus BDOS combined. There was also an unrelated FDOS IV, sometimes mentioned on the same page! And a 6800 FDOS, also from ICOM, but doesn't seem to have been compatible. (For one thing, it used 256 byte sectors, while this one uses 128 byte sectors.) The use of hex files for executables is an adorable quirk of this dead end of operating system evolution.

Anyhow, I converted everything to binary files (by hand, one of the fun things about hex files is just paste 'em around with a hex editor), and ran my (nice) disassembler on it all, dropping a few comments here and there. It was interesting that ASMB wasn't just a macro assembler with a linker, it also had Intel-style mnemonics for Z80 opcodes! Otherwise, not one of the great operating systems. It doesn't even have resident directory handling. BASIC had to have code to parse the file names and raw directory sectors.

 

[per]

It's always interesting to see which parts change between versions, and how they change.

When I look at version differences in things I disassemble myself, I usually use Git to get a better overview of the changes. For instance:

• https://github.com/Frodevan/TDV-5010_Firmware/commits/main/
• https://github.com/Frodevan/Tandberg_Operating_System/commits/master/ (ongoing project at the moment)

It was interesting that ASMB wasn't just a macro assembler with a linker, it also had Intel-style mnemonics for Z80 opcodes!

That is very interesting. Having worked a lot with Intel-mnemonics for the 8080 lately, I have to say that I do prefer it's more distinct instruction names over the LD-heavy Z80 mnemonics. Having separate instruction names for Load/Store/Move makes sense, and makes the operands more uniform/faster to read. Just less clutter on the page, really.

Otherwise, not one of the great operating systems. It doesn't even have resident directory handling. BASIC had to have code to parse the file names and raw directory sectors.

As you see earlier in this post, I've been working a lot with another obscure 8080-based OS that's very much in the complete opposite direction. It has resident handling of several drive and disk formats, multiple abstraction layers, and abstract standard input/output file handle assignments that are handled by the OS before a program is loaded. Yet, some people I've talked with that used it back in the day were complaining that the many layers of abstraction made it very slow on a 2MHz 8080. While no directory handling is a major limitation, which can indeed be quite infuriating for the program developer, my point here is that it is possible to go too far in the other direction as well. I think CP/M really hit a sweet-spot in that regard.

 

[Al Kossow]

When I was digging into DEC 18-bit operating systems, I was surprised to discover that the file system for disk
devices was part of the disk driver.