Loading ...
Sorry, an error occurred while loading the content.

Re: Altairs and Disk Drives --- In altaircomputerclub@yahoogroups.com, "W Tom"

Expand Messages
  • mfeberhard
    I have an original Tarbell 1011D boot disk, which boots fine from a Tarbell board. But I cannot read it at all with a CCS (1792-based) disk controller, nor can
    Message 1 of 34 , Nov 14, 2011
      I have an original Tarbell 1011D boot disk, which boots fine from a Tarbell board. But I cannot read it at all with a CCS (1792-based) disk controller, nor can I read it with my PC. I dug into the 177X spec and 179X spec to understand the difference, and here is what I found: ( I will try to ASCII-format this here...)

      Single-Density Format

      1792 1772
      # Bytes Value Function # bytes Value Function
      40 FF 40 FF or 00
      6 00
      1 FC Index Mark
      ---per-sector---- ---per-sector---
      26 FF or 00
      6 00 6 00
      1 FE ID Addr. Mark 1 FE ID Addr. Mark
      1 Track # 1 Track #
      1 Side # (00 or 01) 1 Side # (00 or 01)
      1 Sector # (01-1A) 1 Sector # (01-1A)
      1 00 (sector length) 1 00 (sector length)
      2 CRC Bytes 2 CRC Bytes
      11 FF or 00 11 FF or 00
      6 00 6 00
      1 FB Data Addr. Mark 1 FB Data Addr. Mark
      128 Data (formatted E5) 128 Data (formatted E5)
      2 CRC 2 CRC
      27 FF or 00 10 FF or 00
      ---end of per-sector--- ---end of per-sector---
      ~247 FF or 00 ~369 FF or 00

      As you can see, the 177X does not write an Index Mark (and its preceding 6 00's) on each track. It also positions the sectors closer together (by 17 bytes), and positions all the data closer to the index hole (by 7 bytes).

      I am not sure exactly what it is about the 177X format that upsets the 179X or the PC disk controllers, but it is surely either the missing Index Mark or different the sector spacing.

      I read the 179X spec pretty carefully, and I couldn't help but notice that they never claimed that it was format-compatible with the 177X!

      I have used both the CCS and the Cromemco controllers on my Altair. Both work - and they even seem to be software-compatible. Makes me suspect one is a licensed version of the other.


      >Also: disks createdwith a controller board using the WD1772 are often
      > problematic on othercontrollers (including PCs), because the 177X does
      > not quite follow the IBM3740 floppy format. For this reason, I vastly
      > prefer disk controllers that usethe later WD179X controllers, which got
      > the format right.
      > Martin, you have me a little worried because I own several Tarbell 1011D
      > 1771 controllers. I'm not too worried because I did not have much
      > trouble exchanging diskettes when I had 8-inch Pertec drives. Would
      > boot/BIOS code written for a WD 1771 work un-modified with a WD179X
      > controller? My question is only about SSSD. How problematic is the 3740
      > standards problem?
      > What WD179X controllers are know to work in an Altair? I have a couple
      > of 8-inch Vector Graphic controllers to try after the Tarbell.
      > Tom S
      > --- In altaircomputerclub@yahoogroups.com, "Stephen L" <shlafferty@>
      > wrote:
      > >
      > >
      > > > My focus on 8-inch drives is changing due to 8800b-sm and 8800b-dm
      > > > mainframes. I need 5.25-in drives and controllers that are
      > affordable
      > > > and available for multiple mainframes.
      > >
      > > --- Those Foley mainframes with their integrated drives are
      > interesting.
      > > I take it that they used MITS DOS? I keep hearing that some old 360K
      > > drives may work with some controllers. Herb Johnson has mentioned
      > using
      > > Versafloppy-II controllers. Of course, it's all about mating the
      > > controller with the particular OS. I get the impression that I'm going
      > > to end up writing 8080 code again, after 35-years :) It also looks
      > like
      > > getting a custom 1702A eprom burned will be in the picture.
      > >
      > > > I like to hear of people restoring iCOM equipment. iCOM was a
      > pioneer
      > > > too. iCOM engineers made contributions to Altair design like the
      > 3202
      > > > drive cabinet. iCOM programmers helped repair Altair accounting
      > > > software.
      > >
      > > --- There is no doubt that solving the floppy controller/driver
      > problem
      > > was one of the tougher tasks that the microcomputer companies faced,
      > > back in the day. iCOM was indeed a pioneer. Offering a 5-1/4-inch
      > floppy
      > > system for the S100 bus back in 1977 was pretty innovative.
      > >
      > > > Reading and writing an a PC will be a challenge, especially the FDOS
      > > > format.
      > >
      > > --- Yes indeed. My hopes were buoyed by seeing evidence of the
      > XenoCopy
      > > software, though I guess it may have disappeared. Scanning their list
      > of
      > > formats though, doesn't turn up much for names like MITS, iCOM and
      > > NorthStar. Also stumbled across OmniDisk, which claims to be "capable
      > of
      > > reading, writing and formatting any physical format to the limit of
      > the
      > > hardware, and it will recognize (and a put a name to) some formats
      > seen
      > > before."
      > >
      > > >Part of my interest in the Teac FD-55 GFR drives is that
      > > > adaptors are available to make then look like 8-inch drives. The
      > > 8-inch
      > > > SSSD CP/M format can become a new 5.25-inch standard.
      > >
      > > --- That is an interesting option. I seem to remember something about
      > an
      > > adapter like that--who provides it?
      > >
      > > > Good luck with the Microfloppy. I hope someone comes up with a
      > manual.
      > > > Hopefully someone with a have a dual-drive Microfloppy system to
      > copy
      > > > boot disks. Perhaps someone has a CP/M BIOS configured for a
      > > Microfloppy
      > > > or close enough to modify.
      > >
      > > --- Yes---Please, if anyone has documentation on the iCOM microfloppy
      > > controller or software for it, I would be very grateful. My unit is
      > > missing one of the small chips and I can't even find out what that is
      > > supposed to be. If anyone has the controller, I would really
      > appreciate
      > > knowing what chip is in U12.
      > >
      > > > At this point I'm not so concerned with what
      > > > was common in the past. I want mainframes to have any drives that
      > are
      > > > affordable and have media that can be read by other Altair owners.
      > >
      > > --- That is a worthy goal. Achieving it would do a lot to get these
      > > systems running again. After looking around, I'm getting the
      > impression
      > > that having actual floppy hardware and software currently working is
      > > somewhat uncommon. When I asked one knowledgeable seller for a
      > > controller and floppy solution, he could not offer offer one, saying
      > > that controllers and floppies "aren't plug and play". I see a lot of
      > > people selling boards and drives but haven't found a source for a
      > > working combo. Of course, software is in the mix, too.
      > >
      > > Part of my interest in finding PC software which could use a 360K
      > drive
      > > to read/write multiple standards would be that it could become a
      > Rosetta
      > > Stone, allowing hobbyists to exchange software.
      > >
      > > Steve L.
      > >
    • dsroelov
      regarding herb s post below, i remember the days of writing disk drivers for my 8800B. it still had a 2MHz 8080 and it had the same old MITS disk controller.
      Message 34 of 34 , Jan 4, 2012
        regarding herb's post below, i remember the days of writing disk drivers for my 8800B. it still had a 2MHz 8080 and it had the same old MITS disk controller. timing out the read loop, i think it took 31.5 microseconds to run the loop, and a new byte came from the controller every 32 microseconds. you snooze, you lose.

        i also remember some crazy read code that came from extended basic, or DOS, or CP/M, or somewhere, that read two bytes at a time from the controller. it did not check the "ready" flag for every byte, it just checked the flag, read a byte, added a couple of NOP's for timing, then it just read another byte. after the second byte, it looped back to the beginning and checked the flag again. dangerous code. a stray microsecond here or there, and you were screwed.

        in any case, unless your controller has at least a one sector read buffer (whatever that sector size might be), single density is probably as good as you'll get on a 2MHz system with the original MITS disk controller.

        --- In altaircomputerclub@yahoogroups.com, "thinkpast" <hjohnson@...> wrote:

        > The core problem of use, relevant to MITS 8080 owners, is this. How can a 2Mhz CPU, keep up with all the data in real time from the floppy diskette, through the read head? Since double-density formats have twice the data, that increases the difficulty. Most say it's simply not possible to manage double-density with a 2MHZ 8080.

        > Regards,
        > Herb Johnson
        > retrotechnology.com
      Your message has been successfully submitted and would be delivered to recipients shortly.