osiweb.org

My name is John and I'm in the UK with a recently built KlyBall 600D machine with 610 board. The 610 is populated with 16K of RAM, making 24K in total. The machine currently has the CEGMON monitor using the standard 32x32 display.

So far I have been unable to boot either a disk or a Gotek image and any help you guys could offer would be gratefully received.



I have been closely following Howards thread 'Another C1P build' (viewtopic.php?t=885&hilit=can%27t+boot) as he seemed to have had similar symptoms and traced his issue to bad RAM, however, I have tested all of my RAM chips in a 2114 RAM tester and feel confident that this is not my issue.

Not being any kind of expert in this stuff I am a little unsure how best to proceed but this is what I have done so far...

• I have built and added the Data Separator and ensured that pin 14 of J3 has the required 5v.

• I have calibarted each of the one shot timers as per the 600/610 Servicing manual, however, the frequency was shown as 123Khz not 125Khz as I was expecting. In addition in order to reduce the RX Data negative going pulse to 6uS I had to change R20 from 18K to 10K. I have no idea if either of the above is significant.

• I have calibrated the D13 by connecting pin 9 of the 24 pin connector to Link pin 1 and adjusting for positive width of 6uS.

• I have created some .hfe images using OSIHFE (v2.21) from the .65d disk images published on https://osi.marks-lab.com/. The .hfe images boot fine when used with WinOSI.

• I have tested all of the RAM using a 2114 ram tester.

I configured a Gotek with Flash Floppy (alas no OLED display) and placed the .hfe images on the associated USB disk. When I press the 'D' option from the CEGMON 'D/C/W/M' menu, the Gotek displays '0_' on the 7 segment display. Which usually means that track 0 is being accessed, however, the machine hangs. It doesn't matter which disk image I try to boot from.

The Gotek FF.CFG I am currently using is as follows although I have tried many variations.
In order to investigate further, I created some real 40 track double sided disks from the OS65D and HexDos .hfe files using Greaseweazle. When I connect a known good drive instead of the Gotek, I get the same symptoms. However, I can see from the real drive that each time I reset and press 'D' the head steps to the next track, i.e. it steps one track at each attempt to boot. After several attempts the head is sat in the middle of the disk and at no point does it return to track zero. As I say the drive is a known working drive and is used regularly with Greaseweazle.

Like I say, any help would be very much appreciated.

When the disk drive load routine is called, it first steps up a track and checks for track 0 active, then steps down multiple times until track 0 is active. If your disk only steps up or track 0 is not detected, the transfer data process will not be started and the machine will appear to hang.
The commented ROM disassembly can be found here. See ROM page 4.

You can use David Gesswein's floppy test program here: to step disk up & down and see status bits. I don't think the actual read/write disk test works correctly with Gotek though.
These and other programs can be found on the Tools page here.

Thanks Mark, I will give Davids floppy test program a try.

Well done so far, sir!
Having assembled a machine that boots up, is an achievement in itself, I know!

Getting the Gotek to boot is probably the right place to start:

I believe you are very close, and your symptoms are very similar to the "issues" that I faced, initially...
Below are the pertinant settings (for your Gotek) in FF.CFG that work for me is:

interface = shugart
host = unspecified
pin 02 = nc
pin 34 = rdy <=== **** i think it is THIS signal that is causing your issue ****
track-change = instant
write-drain = instant
index-suppression = yes
head-settle-ms = 25
chgrst = step

comment out the write-protect = no"" (because you may WANT to protect a file, I protect all the OSI original HFE's)
i.e. # write-protect = no

** NB *
You MUST first RESET the Gotek's internal flash memory, (without the USB memory stick)
(I'm not sure how to do that on a Gotek without an OLED)
This is necessary, so that the changes to FF.CFG will be read and applied, the next time you insert the USB memory.

Note:
Changing resistor values to achieve the correct one-shot timing is acceptable, and depends largely on the quality (tollerance) of the caps in the timing circuit, but it does indicate that something is not quite the same as how the OSI engineers had it, so long ago!
I had used cermic disk type caps in there at first, and could not achieve the correct pulse widths.
After I changed them to higher quality polyester caps, I was able to correctly set the one-shots, using the original resistor values.

For sanity sake: below is a screen-shot of the Greasweasle GUI settings, for WRITING a physical, bootable 5.25" disk


H.

Thank you Howard, I will set those as suggested. Not sure how to reset the Gotek, I'll ask Keir.

Did you finalise the link settings for the D13?

I know that Grant lost a lot of his notes for the D13 after a hard disk failure so I thought I would try and gather a set from information on the forum and my own experience of assembling it e.g. BOM, layout, settings, calibration etc. naturally I'll share it once completed in case it's of any use.

I have just used Davids floppy test program as suggested by Mark and it shows me that the index is stuck active. So I now have some new clues to work with.

I have also added 'How to Reset a Gotek" to my set of notes.

"Hold the Prev and Next buttons (or Rotary Select button) in for three seconds with no USB device inserted."

You're welcome!

Below is a pic of my D13-V2, for jumper setting reference:

Thanks Howard, that is set the same as mine so that's good.

Some progress has been made here. I still cannot boot to a disk, however, your Gotek settings (FF.CFG) have helped, you were right about the rdy signal.

Based on the results of Marks FloppyTest program, I am able to write to the gotek disk but not read from it. The FloppyTest program seems to access all tracks etc. and it does update the .hfe disk image but the read seems to not be working so its back to the service manual to trace the fault.

Thanks for the help so far, it's really appreciated.

One thing I must congratulate you on is the build quality of your system, particularly the case it is awesome. I would love to build one of those at some point. First things first though eh!

Thanks!
I have already shared (email) my case laser cutting files and 600D pcb stand-off models, with Grant, a member here..., so just shout if you want them too.
I'm having a lot of fun with it now!

Progress is progress yes?

Trying to recall my issues...
I did have ussues with writing to a "new," (unintialised) Gotek image, i.e. when copying from Gotek "A" to a new Gotek entry.
It failed every time, unitil:
I first made a copy (using the Gotek's "file copy menu" of an arbitrary OSI .hfe file (already on the GOTEK), and then OVERWRITING that copied image, using the OSI copy function (C1P-OS65D_3.3 Tutorial5, menu item 8.)

I haven't figured out why, but when I copy from the Gotek "A" to an OSI 5¼ disk, I have to copy from "A" (Gotek) to "D" (OSI floppy disk) and not the expected ”C".

If I try to copy from "A" (sel0 active, head 0) to "C” (sel1 active) it will try to copy to the 2nd head on the floppy disk( h1), which will fail on a single sided disk drive, or, it will successfully copy to the 2nd head on a double sided disk drive, but obviously that disk can’t boot! .

I haven't figured out why, but when I copy from the Gotek "A" to an OSI 5¼ disk, I have to copy from "A" (Gotek) to "D" (OSI floppy disk) and not the expected ”C".

If I try to copy from "A" (sel0 active, head 0) to "C” (sel1 active) it will try to copy to the 2nd head on the floppy disk( h1), which will fail on a single sided disk drive, or, it will successfully copy to the 2nd head on a double sided disk drive, but obviously that disk can’t boot! .

This still sounds very strange. The normal meanings for A, B, C, and D are:

A: Drive 0, side 0
B: Drive 1, side 0
C: Drive 0, side 1
D: Drive 1, side 1

So the first side of the second drive should be B, not C or D. What happens if you try copying to B?