Another C1P build

[HOWARDHB]

Thanks for the monitor "test" for manually getting Track 0 read.

To be clear, I haven't yet booted any images with the Gotek or Shugart A400.

What I have achieved though, is to write a 35 track hfe image to a physical disk on the A400, using the Greaseweasle, and then read it back and converted it back to .65D, and opened in WinOSI.

I have run the memory test, $0400 to $7FFF, for a number of hours... asterix chars fill the screen eventually, meaning no errors...

Here follows the test you described, with the Gotek attached, and C1-PICO_DOS.hfe selected:
In Monitor mode, after entering .FC06, when I type "G", I can see the Gotek display quickly change Track 1, then 0. Nothing else happens, seems to "hang" as no further key entries are possible until I hit BREAK,then "M".
Then, when examining address $2200 to $2204, I see: $F7, $77, $77, $FD, $FF

I tried this with various other C1 .hfe files on the Gotek.
The result for address 2200 to 2204 is always the same: $F7, $77, $77, $FD, $FF

H.

[ronin47]

looking at the cut closely, it seems to be certainly deliberate....
(the rest of the board is "pristine", and is Gold flash plated)

Very odd. I just checked my 610 board, as yet unbuilt (Too many projects on the go!), obviously a different supplier, and it's fine.

[Thomas]

You may try a machine code tool, I'm using to setup a boot disk.
It simply does the boot sequence of the of the ROM and reads in 256 bytes into memory.
The first 8 bytes are displayed on the screen. This gives a lot of information, what the computer is actually reading in.
Example of PicoSOS:

TRK00.JPG (48.96 KiB) Viewed 159 times

Here the program in Cassette loader format.

[HOWARDHB]

Thanks for that Thomas!

Subsequent to finding and repairing the cut B02 track, I meticulously re-tuned the one-shot timers on the 610 and the D-13 data separator.
I also checked the chip sellect and R/W circuits of the PIA and ACIA.

With the Gotek attached, (OS65Dv32-C4&C1.hfe on the USB) I attached the scope ch 1 (yellow trace) to separated data (pin 11 on the D-13) and ch 2 (blue trace) to separated clock (pin 10), and set ch 2 as trigger...

Separator.png (3.45 MiB) Viewed 139 times

I followed these signals to the ACIA pins 2 and 3... This looks correct, I thought to myself...

Then, after 3 seconds, THIS showed up on the monitor:

DISK SUCCESS.jpg (101.33 KiB) Viewed 139 times

Success!

I tried a few other C1 .hfe images.
Most booted fine but some failed to boot, not sure why yet.

fun.png (3.19 MiB) Viewed 130 times

So now that I know the OSI hardware is working (with the Gotek floppy emulator) as it should, I can move on to getting a physical disk drive working...

H.

[Thomas]

CONGRATULATIONS

[HOWARDHB]

Thank-you everyone that helped!

Be aware that any RAM "issues" above 8k will prevent a disk from booting. No error is reported, just boot failure!
I say this because this morning, the Gotek would not boot again, UNTIL I pressed each and every RAM chip FIRMLY in it's socket.
(a few chips were not fully seated)

All good again

H.

[ronin47]

That's brilliant!!

Hopefully when I get to building my 610 I can use your info as a guide.

[HOWARDHB]

Super happy that it works!

Thanks again everyone!

I've attached two .zip files that contain the files that I used with the Gotek.
FF.zip contains FF.CFG, which is what worked for me, after updating the Gotek firmware to FLASHFLOPPY 3.42

*NB*
If you make a change to the FF.CFG file (in the root of the USB memory stick, you MUST first perform a RESET on the gotek
(without a USB stick in the Gotek) in order for your new change to be read into the Gotek's flash memory.

Today I used OSIHFE.EXE to recreate the .hfe files that did not boot.
Bingo!
They all boot now

Tried again writing an hfe file to my floppy disk, using the Greaseweasle, but I'm not sure of the parameters.
The separated clock and data waveforms look "similar" to those when the Gotek is attached, but no boot.

Can someone confirm the following disk parameters...

IBM FM or MFM flux encoding?
how many sectors per track :
how many bytes per sector :
inter sector delay/gap
dara rate :

...and any other parameters perculiar / unique to OSI.

My floppy disk is "working" in that it will react correctly to <BREAK> "D" by stepping the head to track 0 and loading the head,
then, after a few rotations of the disk, the head un-loads, but no boot.

As I mentioned, the separated data stream and clock waveforms, look very similar to the Gotek, but with some "jitter",
which is expected from a disk spinning at 300rpm.
The jitter shouldn't have any effect though, as, the clock and data, being "combined" in the magnetic flux, jitter "together".
The data separator's re-triggerable monostable and the 610's "one-shot" timers correct it.
Clever chaps at SHUGART, back in the 70's !

H.

HFE IMAGES THAT WORK.zip

(1.72 MiB) Downloaded 16 times

FF.zip

(4.51 KiB) Downloaded 13 times

[bxdanny]

Well, congratulations from me too!

I am honored that three of the five disk images you showed booting on your systems were ones that I originated.

As for the parameters for writing floppies with the Greaseweasel, the modulation method is definitely FM and not MFM. But beyond that, I don't know. The number and length of sectors on 65D-format disks is of course variable, and so are the gap lengths. I thought that information is all encoded in the .hfe files. Perhaps Thomas has some ideas about how those questions should be answered.

[Thomas]

The HFE disk image format contains all necessary information of the disk layout and bitrates,
Check out this discussion: https://torlus.com/floppy/forum/viewtopic.php?t=3942

Using Greaseweasel, you do not need to setup any track/sector format options for writing to disk.
Actually, OS65D does not have a standard track/sector layout like ISO IBM for example. With the consequence, no Floppy Controller would be able to read in any OSI disks nor write any.
Therefore, raw data formats like HFE have been created, to work around this issue. In the HxCFloppy Emulator, you can see how the raw format looks like,

HxC.JPG (49.82 KiB) Viewed 57 times

Disk_View.JPG (75.69 KiB) Viewed 57 times

To setup Greaseweasel for writing HFE files to a "real" disk drive, have a look to the Host Tool setting

GW_HostTool 118.JPG (61.39 KiB) Viewed 57 times

HFE version 3 supports a disk protection mechanism, which isn't relevant for OS65D disks. OS65D disks use HFE version 0.

A typical HFE File header created by OSIHFE.EXE looks like:

HEADERSIGNATURE[8]; // "HXCPICFE"
48 58 43 50 49 43 46 45
formatrevision; // Revision 0
00
number_of_track; // Number of track in the file 40
28
number_of_side; // Number of valid side 2
02
track_encoding; // Track Encoding mode UNKNOWN_ENCODING 0xFF
FF
bitRate; // Bitrate in Kbit/s. Ex : 250=250000bits/s
FA 00
floppyRPM; // Rotation per minute 300
2C 01

Remarks:
- On a single sided disk, Mark uses a two-sided disk layout. The second side is just empty
- Track Encoding mode UNKNOWN means, we do not have any standard like ISO IBM MF/MFM or other
All track data is stored as "raw" bit data
- Bitrate 250000bits/s
This is the clock needed to encode FM or MFM data, whereas MFM can pack more data bits (almost double) into the same bitstream.
Using 250k bits also simplifies the software HFE encoding as 2 data bits can go into 1 HFE byte

The difference between MFM and FM us just the encoding method. The 610 board operates in FM mode.
If you still have problems with the Shugart drive, make sure the drive is running at 300 rpm.