Tag: Floppy Disk

About Floppy Disk

Subscribe Feeds

Sorcerer/Micropolis Disk Imaging with FluxEngine

Posted on by Graham

My Sorcerer uses a Micropolis hard sectored floppy drive system. It uses 16 sectors, each of which includes a 256 byte data section and 19 bytes of bonus “metadata” used by Micropolis DOS (MDOS). This metadata is ignored by the CP/M implementations (Exidy & Software Source) that i have encountered.

The drives have an unusual track spacing of 100TPI. This is unusual so imaging has to be done using the actual drive units.

FluxEngine is a very low cost imaging solution that support Micropolis hard sector disks as used on my Sorcerer. At the time, Greaseweazle did not support hard sectors. It has since been added. I’ll do a separate post on that.

I followed the instructions here:

https://cowlark.com/fluxengine/doc/building.html

I connected to the drive using a straight through cable and using drive:0.  This selects the second drive in the dual drive unit (drive 1).  For the single drive unit, DS1 (the second drive select) must be selected.

I used FluxEngine on a new PC, so there would be no USB bandwidth issues.  My older machine does seem to work reliably, but if it gets busy then FluxEngine will sometimes throw a bandwidth error.

Initially i used my single drive unit (which I call Drive 2) mainly because it was compact. Once I started working my way through the disks, I found I was getting lots of errors.  I thought that I might do better with the dual drive unit (I call the top drive “Drive 0” and the bottom drive, “Drive 1”).  I found that Drive 0 was a little better than Drive 2 and that Drive 1 was the best drive to use. 

The results were a little disappointing but some further reading of the FluxEngine doco:

http://cowlark.com/fluxengine/doc/problems.html

hinted that I could fiddle with decoder.bit_error_threshold to perhaps get better results.  0.2 is the default.  0.4 improved things a lot.  0.5 was the best.  With the wrong setting, a lot of empty (?) sectors were read.  I also increased the retry limit.

Drive 1 remained the best performing drive.  I tried messing with the alignment on Drive 2, but I could not noticeably improve its performance.  I did some poking around with the scope but no obvious differences between the dual and single units leapt out at me.

Out of 87 disks, I was able to read 19 without any errors being reported. I was able to read another 18 with only a small number of errors.  A further 38 disks didn’t yield anything usable.  Some were shedding oxide, but most 24 were successfully reformatted.  Many were unlabelled, so perhaps no great loss.

fluxengine read micropolis --315 --layout.tracks=77 --layout.sides=1 -s drive:0 --decoder.retries=8 --decoder.bit_error_threshold=0.5 -o exidy_%1.img

Disks that were formatted with MDOS were read using the 275byte sector size.  CP/M disks were read with 256 byte sector size.  My understanding is that CP/M doesn’t use the “metadata”, and the 256 byte size is much easier to view.

fluxengine read micropolis --315 --vgi --layout.tracks=77 --layout.sides=1 -s drive:0 --decoder.retries=8 --decoder.bit_error_threshold=0.5 --decoder.micropolis.sector_output_size=275 -o exidy_%1.img

There were some examples of where I was able to copy a disk on the real machine, but FluxEngine was unable to read the disk without error, eg Disk 24.  The copy read fine.  This meant that there was potential to improve the yield by making fresh copies on the real machine.  Ie The real disk controller is still doing a better job in real time than the flux engine does in slow time.  That’s the advantage of inside knowledge, perhaps.

I attempted to copy all the errant disks to intermediate disks, which I subsequently imaged.  I did this for the CP/M disks using COPYDISK.  This yielded another 13 good images!  I think this confirms that FluxEngine is way less tolerant of problems than the sorcerer system.  Even many disks that had a lot of issues came good.

I repeated the exercise for the MDOS disks, which gave another 8 good images.

I was able to write back both CP/M and MDOS images:

fluxengine write micropolis --315 --layout.tracks=77 --layout.sides=1 --decoder.retries=8 --decoder.bit_error_threshold=0.5 -i exidy_%1.img -d drive:0

fluxengine write micropolis --315 --vgi --layout.tracks=77 --layout.sides=1 --decoder.retries=8 --decoder.bit_error_threshold=0.5 -i exidy_%1.img -d drive:0

The write process verifies each track by reading back so even the writes need the bit_error_threshold parameter.

Writing also work through the virtual sector generator to a soft sector disk.  The disk can be read by the system if the virtual sector generator is used.

I was very impressed with FluxEngine. David Given has done an amazing job.

Pulsar 7500 SASI/SCSI

Posted on by Graham

The system has two SASI cards that I thought might accept a SCSI2SD card.

The drive configuration comes up in two places – firstly in configuration of the master or single user system configuration program, and then again when the drive is formatted.

In both cases, the following information is required:

  • SASI card number: 0 worked for one card but I tried multiple numbers with the other card without success
  • Drive Number: It allows 1 or 2.  1 seemed to be SCSI ID 0. 
  • Drive Manufacturer: Somewhat randomly chose Tandon 700
  • Drive Model Number: 31.2MB drive
  • Block size and directory entries: Default

The configuration also deals with partitioning.  The default partition size is 4MB which is the optimal size. With large drives, that’s a bit of a nuisance because you need a lot of partitions.  Having some optimal 4MB partitions and a larger sub-optimal partition seemed like a reasonable compromise.

The drive selection gave some geometry, but the specifics probably don’t matter with a SCSI2SD.  The SCSI2SD was set up with a simple 32MB disk at ID 0 with 512B sectors.  Termination needs to be on.

The process went like this:

  1. Create a fresh single user floppy disk
  2. Run the Configuration program and select modify
  3. Set up the hard disk as above
  4. Format the hard disk using HFORM30 with the same disk parameters

At this point the new drives were available starting at E: but when the directory was listed it appeared the disk was read only and the directory looked corrupted.  It didn’t seem to matter if the format was done first and then the configuration.

The “Creating Boot Tracks” section of the System Initialisation Procedure mentioned a program called ERASEDIR but really just in the context of making faster hashed entries.  Running this program on each of the drives resolved the issue.  It says to run this after BOOTDISC (which writes the boot tracks).

So:

  • Run BOOTDISK and write to E: – only the first partition can be a boot partition.  It can also be written to A:.
  • Run ERASEDIR on each of the new drives from e: to the last one.
  • Copy all the files from the A: to E: using DO DCOPY A: E:

When the system is powered up, it looks for a bootable drive.  If a boot floppy is in A: it will use it; otherwise it will boot using E:.

Programs were then copied on to the solid state disk from a gotek. TurboDOS supports multiple user areas so the these can be used as directories. User 0 files marked a global can be accessed by all users.

All users are assumed to be using Televideo 950 terminals. A lot of the software on the 8″ disks was configured to use this popular terminal.

To copy from 0A to 1H:

Copy a:*.* h: ;D01

The user must be privileged.

DiskE:F:G:H:I:
Capacity4MB4MB4MB4MB16MB
User     
0TurboDOS Files   TurboDOS Files Backup
1Multiplan (118/101)  Multiplan (432/310) 
2   Supercalc (332/248) 
3   Wordstar (214/160) 
4   DBase (238/169) 
5     
6 MBasic Games (066/63)  MBasic & Basic Compiler (240/171)CP/MUG Vol 53 (Adventure & Mbasic Games) (088/77) 
7  JRT Pascal V3.0 (261/189)  
8  Diagnostics II (262/190)  
9  Microsoft Fortran (434/312)Fortran Stuff (434/312) 
10  Cross Assemblers (008/007)  
11Pascal MT/Plus V5.5 & Programs (047/044)Pascal MT/Plus Sources DevelopmentPascal MT/Plus V5.5 Support Files Development  Pascal MT/Plus V5.5 G. Purpose Development   
12  Turbo Pascal (055/052)  
13 Zork (440/318)   
14     
15 Other Games   

Using HD 5.25″ FDDs as 8″ Drive Substitutes

Posted on by Graham

High density 5.25″ disks have much the same capacity as 8″ double density disks, and they operate at the same data rate. A 5.25″ FDD typically has a few more tracks than an 8″ FDD.

This means that a floppy disk controller expecting to see an 8″ disk drive can potentially be fooled into working with an HD 5.25″ drive. This can be very handy if you don’t have an 8″ drive or if you want a more compact setup. This trick seems to work ok with a real HD drive or with a gotek/flashfloppy. 8″ disk images can be written to HD 5.25″ media without alteration using Greaseweazle, for example.

There are a few small issues. The first is the 8″ drive interface is usually 50 pins and the 5.25″ interface is usually 34 pins. The disk controller may have both interfaces (eg the Jade DD and the 16FDC) but not always (eg the Pulsar Little Big Board only has a 50 pin interface). If there is no 34 pin interface, then an adapter will be required. The 50 pin interfaces vary a bit, so a specific adapter may be required.

The second is that 8″ drives can detect whether a drive is single or double-sided and tell the host. The operating system driver may exploit this information (eg Jade DD CP/M) so there may need to be a way to fake this. For systems that use only single sided or only double-sided disks the signal can be tied appropriately otherwise a switch may be required – and if there are different drives in the system then it may be necessary to take the signal low through a diode from the drive select line.

Third is that 8″ drives typically produced a ready (RDY) signal. Without this signal, a host may just hang. This signal is available on many drives and can usually be setup on a gotek/flashfloppy but it may not be connected on the 34 pin interface. This can be overcome by connecting pin 34 on the 34 pin interface to the appropriate pin on the 50 pin interface.