Another Disk Operating System for OSI Superboard II / C1P

[davisgw]

bxdanny,
I don't really know how to easily make a floppy of the DEMO disk, since the GOTEK will only operate one image at a time and I don't know what will happen if I use the BOOT image to load the format or copy commands, then switch to the DEMO image....I think I have corrupted images when I've done this before. Do you know how to avoid image corruption?
Both the DFMT command and FORMAT.BAS only format 35 tracks. The stated sectors free for a formatted disk is 264. For the BOOT disk it is 206. And I'm certain it will not write to and track that has not been formatted.

[bxdanny]

davisgw,

The DEMO disk is bootable, there would be no need to change disks. (At least the 40-track .img version is, and since it shows 125 sectors free, which is well over 5 tracks, which would be 40 sectors, I presume the 35-track .hfe version is bootable as well. It would probably show 85 sectors free.)

Mark,

Would it be possible to "reformat" the 35-track .hfe files into 40-track files (double-sided if necessary) that could be read by both WinOSI and a Gotek drive?

[nama]

Yes, I downloaded these a few days back and tried them out today on a real system with a Gotek drive. I played around for some time trying to get them to work before I realised (after reading the above post) that these wont work on a real system with a Gotek drive.

[Mark]

Generally the HFE images are OK as-is, it's just that they use 8N1 serial words instead of 8E1 like all other OSI floppies and operating systems. As such they are just unrecognized binary blobs to my software.

My HFE files are encoded as 2 sided disks just for compatibility with long ago versions of FlashFloppy and HxC firmware. FlashFloppy seems to work fine with single sided images now, I haven't check out HxC firmware for a long time though.

Internally OSIHFE (& my WinOSI) can decode 8N1 since it is used on OS65U. As an experiment I have decoded the posted .hfe files as an OSI Dump image, and realized I never considered a disk image of less than 40 tracks.

So that seems like the 1st change - pad converted images to emulator recognized lengths, or change emulator loader to recognize short disks.
How to detect YEDOS disks? boot track <generally> loads at $6800 for 8 pages with 8E1 encoding.... what about 80 track disks?
Trial decode of 8N1 track data looking for 15 byte track header and/or 9 byte sector headers?

Since I do not own a C1P, I can not run YEDOS on real hardware.
You'd think it would be possible to use it to format and copy itself from gotek to real floppy drive. The FM flux lengths should fit correctly on a 300RPM 48 TPI drive - not sure what the problem is yet.

Update - I'm seeing these long gaps in the demo HFE file on each track after every 51 or 52 bytes of data, where no bytes are present. It looks like when the sector was being written, it paused during write. There are also a few parity errors on the boot track according to my decoder... not sure where the error lies. The decoded HFE are close to the posted IMG files, but contain many errors. The log file shows the null gaps in bitstream.

I started writing the code to decoded tracks/sectors etc. from the YEDOS images & create HFE files from IMG files, but the headers are crazy long, there are multiple checksum bytes, sync bytes, gap bytes, link bytes, etc. and I'm not feeling it. But who knows?

The attached OSI dump are decoded from the posted HFE files, but do not work. In the included log file "PE" is parity error, "Zeros" are long sequences of idle space in the HFE file (just FM clock bits, no data.) Expected during gaps or R/W switching, but not in the middle of a sector.
Binary compare with IMG files show regular corruption of data - possibly my error.

[Thomas]

Hi Mark,
I haven't noticed the recent interest and investigation on YEDOS.
Just a few comments to the disk format. Track 0 is in 8E1 to match with the standard OSI disk boot loader. All other tracks are 8N1, to provide sufficient byte space per track for data, sync and sector gaps. Data integrity of sector header and data is ensured by checksum bytes.

You have mentioned "Zeros" are long sequences of idle space in the HFE file (just FM clock bits, no data.) Expected during gaps or R/W switching, but not in the middle of a sector."

In the HFE bitstream, actually 256 bytes of bit stream segments alter between first and second side of the disk. This is how the HFE format is defined. In case the second side is just empty, you will see zeros of long sequences of idle space every second segment.
Other idle spaces are a result of R/W gaps in the sector gaps and before/after the sector data block. This is where the drive R/W head kicks in when writing new data to a sector.

The posted HFE was generated by the WinOsi Emulator (WinOsi 18b). 35 tracks have been chosen, because I have two Shugart SA400 drives attached, which reliably support max 35 tracks and a 35 track disk will work anyhow on a 40 track drive.
Within the emulator, you may save the disk in 40 track format as well (besides some missing track warning messages)

What works fine in my case is to use a Gotek as boot drive 0 and DCOPY the disk to the Shugart drive 2. Make sure, that the motor ON time period is increased by a monoflop (10sec or so) on the disk interface card, as it was standard on interface solution of that area or you have a drive that spins all the time and uses the head load input.

For disk copy, you will need two drives connected.

In case you what to switch the Gotek drive 0 image, you have to enter "SEL 0" to reload FAT from drive 0. Or if you first time insert a disk in drive 2, you can enter "DISK 4" to rescan all dives for disk inserted and reload FAT from drive 0. YEDOS will not automatically detect, if disk have been changed or removed. (see YE-OSI DOS X3.54.pdf)

YEDOS can work on 3,5 double side disk 80 tracks, but the posted version is just the basic version that should run on any system with 32k of memory.

Thomas

[Thomas]

Just to avoid confusion, here the YE-DOS image files, that work fine under Mark's emulator.
Mount these as Drive A and B respectively Drive 0 and 2 under YE-DOS.

YE-OSI_V54_35.zip

(37.86 KiB) Downloaded 115 times

Thomas

[davisgw]

bxdanny,
I was successful creating a DEMO floppy by booting the GOTEK BOOT image, loading DCOPY and waiting for drive activity to "settle", then switching to the DEMO image on the GOTEK, and beginning the disk copy to the floppy. But in light of these discussions I am quite sure that posting a dump of the diskette would not be successful.

nama,
I don't understand your inability to get YE-DOS to run on your GOTEK system. The original .hfe files posted by Thomas run perfectly on my Superboard II system with a GOTEK and a floppy drive. Do you have at least 32K of RAM as is stated in the requirements or do you have a modified set of ROMs? My BASIC ROMs are original and my Monitor ROM is modified to boot Dos/65 but is original otherwise.

Mark,
I can't say whether it is worth modifying OSIHFE or DISKTOOL to recognize YE-DOS images other than to allow analysis and replication by interested users, but I do think the floppy images posted by Thomas are not currently usable with existing tools....a GOTEK is necessary.

[Thomas]

davisgw,
just for curiosity, what kind if disk drive interface are you using from the 610 board to the disk drive?

The Data separator I'm using is a self made version to support 3,5 inch drives with motor on port and delay and options for Head load ,Write Enable and Ready.
As 5 1/4 drives exist that handle motor on, or head load differently, it is important to configure your interface with care. I have also noticed, that some drives need a pretty long time (>200 usec) to start writing on the disk , when WE is activated. Especially on some first generation 3,5 inch drives.
Check your drive specification for this. Gotek does not have this kind of delay and most of the older 5 1/4 drives are fast enough.
Short WE to physical write are needed, as the YE-DOS is handling all sector and header updates within the track by software and the standard 6850 serial controller. Some inter sector gaps are short as 2 bytes or 176 usec. Slow drives can cause write errors. But most of the time, configuration of the HL/MotorON and Ready line may cause a disk problem.

[bxdanny]

Thomas [and Mark],

As I understand it, davisgw WAS able to create working floppies of YE-DOS by booting from the BOOT .hfe file you supplied, with the Gotek unit as drive A/0 and using DCOPY to copy to the actual floppy in the B/2 drive. The problem was not with writing the disk, but with getting the right data to it. Mark's programs are apparently not able to process your .hfe file, although the Gotek drive is. And since the .img file doesn't have enough info to reproduce the disk with the correct gaps, a Gotek unit to boot from is required to produce an actual YE-DOS diskette from your files.

I looked at the content of the YE-DOS .hfe files and (referring to the spec for .hfe files) saw that there are actually 40 tracks defined, each track image being $61B0 bytes, meaning tracks begin every $6200 bytes, with the total file size being 879,104. Whereas the files that WinOSI (and perhaps OSIHFE) expects have track images $6590 bytes long (and so beginning every $6600 bytes), with a total file size of 1,065,984. In both cases, the file extends beyond the end of the image for track 39, and I'm not sure what is in that extra space. Ironically, trying to mount one of the YE-DOS .hfe images in WinOSI produces the message that the file is too large, when in fact it is too small to be recognized as a valid .hfe image.

I tried padding the images to be the right size (by copying each track image to the appropriate place in a in a copy of a different, working .hfe file), but the resulting file would still not load YE-DOS in WinOSI (although it could be mounted and produced the menu box for C, W or E). I'm pretty sure I did the copying of track images correctly, so that seems to mean that Mark's software cannot process the contents. [But if Thomas can make .hfe files of the right size it would be a good check.] Yes, I'm able to boot YE-DOS from the .img files, but real hardware can't. I was looking to see if there could be a common file that could be booted on both the emulator AND on real hardware, and it seems that right now there isn't.

[nama]

"Do you have at least 32K of RAM as is stated in the requirements.."

Ah...That'll probably be the issue. I guess I missed that choice bit of information.