Read OK, can't write to 1.2MB image

[schadel]

Hello Jeff,

I'm trying to emulate the external 8" drive on a Japanese SORD computer. I can read the directory and the files that were on the disk I used to make the image. When I do a write operation, the SD emulator sounds like a floppy drive should and things like "WR" appear on the display--nothing that looks like an error. The OS does not give an error either, but if I then do a directory listing, the new file is not there.

If I write-protect the card, I get an error from the OS, so that function works properly. With no activity there is a 500kHz clock signal on the WD line and WG is high. When I attempt to write, WG toggles and data appears on WD.

I was using a cheap 2GB SD card at first, so I bought a 20Mb/s SDHC card, but the result is the same.

At power-up the emulator remembers which image I was using, so that means it can write to the config file on the card.

The OS is CP/M-68K. The SORD also has an internal 5.25" floppy which uses the same NEC D72065C controller chip although the signals are buffered separately. The parameters of the 2 drives match: 500kb/s, 77 tracks, 1.2MB, etc., so I used ImageDisk on a DOS-based PC to create an image of a 5.25" disk.

I traced signals back through the buffers to correlate them between the 8" and 5.25" drives and constructed an adapter to connect between the 50-pin external drive cable and the 34-pin HxC interface. The 50-pin cable is round and long so I put lower impedance terminators on the adapter board (270 ohms to +5V [in parallel with the 1K resistors on the emulator board] and 330 ohms to ground) for incoming signals. That matches the termination impedance of the 8" drive very closely and greatly improves the shape of the WD signal. I also put a 330uf electrolytic capacitor and a .02uf ceramic disc there to stiffen the power. I made the 34-pin cable between the adapter and the emulator as short as possible so I the signal integrity is very good.

I also used HxCFloppyEmulator.exe to create a blank floppy image. That image has no directory, so I tried running the INIT command on the SORD to create one. Again, there was no error, but the directory was not created.

Can you think of a reason I can't write to the image files?

Thanks and all the best to you,
--Bruce--

PS: Do you have a document that explains the various messages that might appear on the LCD display?

[Jeff_HxC2001]

Hello Jeff,

I'm trying to emulate the external 8" drive on a Japanese SORD computer. I can read the directory and the files that were on the disk I used to make the image. When I do a write operation, the SD emulator sounds like a floppy drive should and things like "WR" appear on the display--nothing that looks like an error. The OS does not give an error either, but if I then do a directory listing, the new file is not there.

If I write-protect the card, I get an error from the OS, so that function works properly. With no activity there is a 500kHz clock signal on the WD line and WG is high. When I attempt to write, WG toggles and data appears on WD.

I was using a cheap 2GB SD card at first, so I bought a 20Mb/s SDHC card, but the result is the same.

At power-up the emulator remembers which image I was using, so that means it can write to the config file on the card.

The OS is CP/M-68K. The SORD also has an internal 5.25" floppy which uses the same NEC D72065C controller chip although the signals are buffered separately. The parameters of the 2 drives match: 500kb/s, 77 tracks, 1.2MB, etc., so I used ImageDisk on a DOS-based PC to create an image of a 5.25" disk.

I traced signals back through the buffers to correlate them between the 8" and 5.25" drives and constructed an adapter to connect between the 50-pin external drive cable and the 34-pin HxC interface. The 50-pin cable is round and long so I put lower impedance terminators on the adapter board (270 ohms to +5V [in parallel with the 1K resistors on the emulator board] and 330 ohms to ground) for incoming signals. That matches the termination impedance of the 8" drive very closely and greatly improves the shape of the WD signal. I also put a 330uf electrolytic capacitor and a .02uf ceramic disc there to stiffen the power. I made the 34-pin cable between the adapter and the emulator as short as possible so I the signal integrity is very good.

I also used HxCFloppyEmulator.exe to create a blank floppy image. That image has no directory, so I tried running the INIT command on the SORD to create one. Again, there was no error, but the directory was not created.

Can you think of a reason I can't write to the image files?

Thanks and all the best to you,
--Bruce--

PS: Do you have a document that explains the various messages that might appear on the LCD display?

Did you have a WEOE / WETO or WEBS message on the lcd during write ?

Can you send me the hfe file before & after the write ?

[schadel]

Did you have a WEOE / WETO or WEBS message on the lcd during write ?

I did not notice any WExx message but I could have missed it if it appeared very briefly. (I'm at home, the SORD is 1/2 hour away.)

Can you send me the hfe file before & after the write ?

I will zip and upload original_imd.hfe which is the file generated by HxCFloppyEmulator.exe and sdcard_imd.hfe which is the file read back from a card I've been trying to write to. VBinDiff says both files are identical.

One thing I have not tried yet is to start with a different image format. I downloaded a floppy image for Sharp X68000 (.XDF) from Dave Dunfield's site. I believe the format parameters are the same, but it has a FAT rather than a CP/M directory. I could convert it to .HFE and try running the INIT command on the SORD to create the directory.

Thanks,
--Bruce--

[Jeff]

Did you have a WEOE / WETO or WEBS message on the lcd during write ?

I did not notice any WExx message but I could have missed it if it appeared very briefly. (I'm at home, the SORD is 1/2 hour away.)

Can you send me the hfe file before & after the write ?

I will zip and upload original_imd.hfe which is the file generated by HxCFloppyEmulator.exe and sdcard_imd.hfe which is the file read back from a card I've been trying to write to. VBinDiff says both files are identical.

One thing I have not tried yet is to start with a different image format. I downloaded a floppy image for Sharp X68000 (.XDF) from Dave Dunfield's site. I believe the format parameters are the same, but it has a FAT rather than a CP/M directory. I could convert it to .HFE and try running the INIT command on the SORD to create the directory.

Thanks,
--Bruce--

The hfe seems ok. just try to increase the gap3 lenght (actually set at 84, try 120...)
Did you have the last firmware (v1.5.1.0) ?

[schadel]

The hfe seems ok. just try to increase the gap3 lenght (actually set at 84, try 120...)

ImageDisk refers to a "Format Gap" (total gap between sectors) and a "Read/Write Gap" which must be less than the Format Gap. I let ImageDisk guess at both of those since I don't know any better. I suspect the R/W gap is gap3 so if I set it to 120 I should specify 240 for the Format gap. I don't know how those are encoded in the .IMD file. Is there a way to change the gap3 length during conversion?

Did you have the last firmware (v1.5.1.0) ?

The firmware is v1.3.0.4. The emulator was shipped only a month ago and I assumed it would be up-to-date. I will flash it.

Thanks again,
--Bruce--

[Jeff]

The hfe seems ok. just try to increase the gap3 lenght (actually set at 84, try 120...)

ImageDisk refers to a "Format Gap" (total gap between sectors) and a "Read/Write Gap" which must be less than the Format Gap. I let ImageDisk guess at both of those since I don't know any better. I suspect the R/W gap is gap3 so if I set it to 120 I should specify 240 for the Format gap. I don't know how those are encoded in the .IMD file. Is there a way to change the gap3 length during conversion?

Did you have the last firmware (v1.5.1.0) ?

The firmware is v1.3.0.4. The emulator was shipped only a month ago and I assumed it would be up-to-date. I will flash it.

Thanks again,
--Bruce--

In fact the gap3 is computed. you cannot change it in the imd.
You have to :
export the IMD file to IMG with the HxC software and use the load raw function to set the right parameters.

But before try this, update your firmware .

[schadel]

Hi Jeff,

You asked earlier about WExx messages. In fact I do get WETO every time.

I updated the firmware. Still get WETO.

I studied the .imd file format and I see that the gap lengths are not encoded. I guess IMD only uses those settings when writing an actual floppy. So, when exporting to .hfe, how does HxC choose gap lengths? From the NEC tables?

I still don't quite understand working with raw files. I had thought a "raw" file would contain everything--headers, CRCs, sync fields, etc., but apparently it has only sequential sector data, with no info about the disk layout so one has to provide that. I clicked the button to load the raw file (previously exported). That took me back to the main menu. So I went back to the raw/blank dialog and filled in the parameters, then went back to the main menu to export as .hfe. I got an apparently empty file. Maybe I did things in the wrong order--should have set parameters first, THEN loaded the raw file. I assume I DON'T want to click "Create Blank Floppy". It may all seem obvious to you, but a short discussion in the next manual rev. would be welcome.

Can I examine a .hfe file to find out if I got what I wanted (e.g. more gap) or is it proprietary?

Incidentally, the 5.25' disks I have are preformatted for IBM and have 26 128-byte sectors FM recorded on the first track and 26 256-byte sectors (MFM) on the other side (head 1) of cylinder 0. SORD ignores cyl. 0 and only formats the other cylinders. IMD has no problem with this if I tell it to analyze all tracks and HxC doesn't complain either. But I can see a problem exporting to raw (if I understand it now ) and then reloading because all tracks will be assumed to be formatted the same. So I opened a .imd file in a hex editor and, using Dave's documentation, replaced the data on the first track with 26 zero-filled sectors and changed the parameters for that track to MFM, 256 bytes/sector, etc. (The rest of that disk was also formatted with 256-byte sectors). I got a readable .hfe but I still can't write to it. Of course, I don't know what its gap3 length is and I didn't try to change it (yet).

I have some internet access from the location of the equipment, but I can't access the forum there (because of scripts, I think).

Thanks and best regards from California,
--Bruce--

[Jeff]

Hi Jeff,

You asked earlier about WExx messages. In fact I do get WETO every time.

I updated the firmware. Still get WETO.

I studied the .imd file format and I see that the gap lengths are not encoded. I guess IMD only uses those settings when writing an actual floppy. So, when exporting to .hfe, how does HxC choose gap lengths? From the NEC tables?

I still don't quite understand working with raw files. I had thought a "raw" file would contain everything--headers, CRCs, sync fields, etc., but apparently it has only sequential sector data, with no info about the disk layout so one has to provide that. I clicked the button to load the raw file (previously exported). That took me back to the main menu. So I went back to the raw/blank dialog and filled in the parameters, then went back to the main menu to export as .hfe. I got an apparently empty file. Maybe I did things in the wrong order--should have set parameters first, THEN loaded the raw file. I assume I DON'T want to click "Create Blank Floppy". It may all seem obvious to you, but a short discussion in the next manual rev. would be welcome.

Can I examine a .hfe file to find out if I got what I wanted (e.g. more gap) or is it proprietary?

Incidentally, the 5.25' disks I have are preformatted for IBM and have 26 128-byte sectors FM recorded on the first track and 26 256-byte sectors (MFM) on the other side (head 1) of cylinder 0. SORD ignores cyl. 0 and only formats the other cylinders. IMD has no problem with this if I tell it to analyze all tracks and HxC doesn't complain either. But I can see a problem exporting to raw (if I understand it now ) and then reloading because all tracks will be assumed to be formatted the same. So I opened a .imd file in a hex editor and, using Dave's documentation, replaced the data on the first track with 26 zero-filled sectors and changed the parameters for that track to MFM, 256 bytes/sector, etc. (The rest of that disk was also formatted with 256-byte sectors). I got a readable .hfe but I still can't write to it. Of course, I don't know what its gap3 length is and I didn't try to change it (yet).

I have some internet access from the location of the equipment, but I can't access the forum there (because of scripts, I think).

Thanks and best regards from California,
--Bruce--

WETO means-> Write Error Time Out
This means that the emulator failed syncing on the input data.
this can be caused by :
-> a bad bitrate (the write bitrate is really in 500K?)
-> an hardware problem (bad write data signal)
-> or an attempt to write sector with a "deleted address mark".
On this last point there are maybe a bug in the firmware. Did you know if your system use this ? can you post the original IMD file here ?

[schadel]

WETO means-> Write Error Time Out
This means that the emulator failed syncing on the input data.
this can be caused by :
-> a bad bitrate (the write bitrate is really in 500K?)
-> an hardware problem (bad write data signal)

When not writing there is a 500kHz clock signal at pin 22 (WD). The emulator has only 1K pullups on incoming signals and the cable is about 1M long with no other drives on it, so the signal looked rather poor with slow risetime and considerable overshoot at the bottom (photo attached). So I put 2 resistor networks, 270 & 330 ohms, on incoming signals as close as possible to the emulator. 270 (in parallel with the 1K) to +5V, 330 to ground closely approximates the 220/330 ohms a terminated drive would have. I also put a 330uF capacitor and a .02uF disc close to the SIP resistors for filtering. The signal looks much better now (but I didn't take another picture ). It becomes "random" indicating the presence of data during a write.

-> or an attempt to write sector with a "deleted address mark".
On this last point there are maybe a bug in the firmware. Did you know if your system use this ? can you post the original IMD file here ?

I'll attach world256.imd. I started by formatting a floppy with 256-byte sectors and putting a small text file on it (it says "HELLO WORLD".) As I noted before, FORMAT doesn't touch the first cylinder and the first track is preformatted at 250kb/s. You can see that in the .imd file, so I edited a copy to define the first track the same as the others. For convenience I used the compressed notation to fill all 26 sectors with 00h. Both versions produce a readable .hfe file.

Most of world256.imd is compressed because the floppy was freshly formatted. I don't see any 04 xx codes which would indicate a deleted address mark.

But I notice something very interesting at 2A93. My HELLO WORLD file begins there and the text is padded out to 128 bytes with 1A and it appears to overwrite something put there previously during formatting (there's a copyright notice in the remaining half of the sector).

Data for disk I/O is passed between CP/M-68K and an application through a 128-byte buffer, regardless of the size of the sectors. I assume larger sectors are buffered in the BIOS, but it appears it doesn't write out a full sector if it doesn't have to. Is this common? How would the emulator respond if writing stopped in the middle of a sector?

I have not tried using 128-bytes sectors yet.

More thanks,
--Bruce--

[Jeff]

-> or an attempt to write sector with a "deleted address mark".
On this last point there are maybe a bug in the firmware. Did you know if your system use this ? can you post the original IMD file here ?

I'll attach world256.imd. I started by formatting a floppy with 256-byte sectors and putting a small text file on it (it says "HELLO WORLD".) As I noted before, FORMAT doesn't touch the first cylinder and the first track is preformatted at 250kb/s. You can see that in the .imd file, so I edited a copy to define the first track the same as the others. For convenience I used the compressed notation to fill all 26 sectors with 00h. Both versions produce a readable .hfe file.

Most of world256.imd is compressed because the floppy was freshly formatted. I don't see any 04 xx codes which would indicate a deleted address mark.

But I notice something very interesting at 2A93. My HELLO WORLD file begins there and the text is padded out to 128 bytes with 1A and it appears to overwrite something put there previously during formatting (there's a copyright notice in the remaining half of the sector).

Data for disk I/O is passed between CP/M-68K and an application through a 128-byte buffer, regardless of the size of the sectors. I assume larger sectors are buffered in the BIOS, but it appears it doesn't write out a full sector if it doesn't have to. Is this common? How would the emulator respond if writing stopped in the middle of a sector?

If the write stop in the middle of a sector the emulator act as a real floppy : the data sector have a bad crc value and data cannot be read back.
To get the real write sector size , have a look to the Write Gate line :
At 500kbits/s:
256bytes = 4ms write.
512bytes = 8ms write.
1024bytes = 16ms write.

You should maybe check if your emulator is working well.
Connect it on a PC and try to write something on a ms dos floppy disk image.

Did you know which write precompensation setting is used on the SORD ? Can you measure it ?

[schadel]

If the write stop in the middle of a sector the emulator act as a real floppy : the data sector have a bad crc value and data cannot be read back.

Of course, you're right about the CRC. I guess the BIOS just buffered the whole sector, overwrote half of the buffer, then wrote all 256 bytes back to the disk. Anyway, today I made an image from a disk formatted with 128-byte sectors. Unfortunately, SORD will only do this at 250kb/s and one side only so the capacity is 1/4. But the conversion succeeded and Sord could read the file from the emulator (the clock signal changed to 250kHz after the first access). I still got WETO.

You should maybe check if your emulator is working well.

When connected to the SORD with no activity, D2 (SDCard Access) stays on all the time. D1 flashes about every half second (but irregular). The index "pulse" appears as 2 pulses, about 1 us each and about 1 ms apart (if I remember). The backlight turns on at random intervals, times out and turns off. (Power comes from a spare connector in the SORD in this case although I was using a 5V "brick" before adding the pullups.)

When not connected to the computer D2 lights for about 30 seconds after power up then goes out except for very short flashes, about one per second. D1 stays off and the backlight stays off. (This is using the 5V brick here at home.)

Connect it on a PC and try to write something on a ms dos floppy disk image.

Good idea

Thanks,
--Bruce--

[Jeff]

If the write stop in the middle of a sector the emulator act as a real floppy : the data sector have a bad crc value and data cannot be read back.

Of course, you're right about the CRC. I guess the BIOS just buffered the whole sector, overwrote half of the buffer, then wrote all 256 bytes back to the disk. Anyway, today I made an image from a disk formatted with 128-byte sectors. Unfortunately, SORD will only do this at 250kb/s and one side only so the capacity is 1/4. But the conversion succeeded and Sord could read the file from the emulator (the clock signal changed to 250kHz after the first access). I still got WETO.

Interesting. To check if there are an hardware problem (with the emulator/ the cable or the buffers...) or an precompensation problem can you try to make some floppy images at 250kbits/s and write on them with the SORD ?

[schadel]

...can you try to make some floppy images at 250kbits/s and write on them with the SORD ?

That's what I did today, made an image at 250kb/s. SORD could read the directory and the file that was in the image but could not write to it (WETO).

Do the behavior of the LEDs and backlight seem normal to you?

Thanks,
--Bruce--

[Jeff]

...can you try to make some floppy images at 250kbits/s and write on them with the SORD ?

That's what I did today, made an image at 250kb/s. SORD could read the directory and the file that was in the image but could not write to it (WETO).

Do the behavior of the LEDs and backlight seem normal to you?

Thanks,
--Bruce--

Ok so this is probably not an compensation problem...
Can you make a small schematic of your buffer stage ?

For the backlight and led behaviour this can be normal since some host poll reguraly the disk drive to check a disk change. this is probably the case of the SORD.
(have a look to the DS0 line to confirm this).

[Jeff]

Another point : can you take some oscilloscope pictures of the Write Data line synced on the Write gate line during sector writing ?