Little help? [C4PMF restoration]

[geowar1]

I’ve been restoring a C4PMF I got off eBay.
I replaced its memory with a GlitchWorks 48K board. Tests good.
Tracked down video echo’s(/noise) to bad backplane connector (A4) on 540 video card; replaced
At this point I get good "H/D/M?” prompt on a clear screen
Can’t seem to “L”oad anything.
Some troubleshooting later… determine DTR (IIRC pin 8) must be low on modem port AND .F703/30 to make ACIA use it.
Now can “L”oad using modem port.
—
No data from floppy; replace MB52 with Teac…
Fails floppytest_v1.04u; 360 instead of 300 RPM
Download Teac manual; jumper for 300 RPM
Pass floppytest_v1.04u RPM test.

Fail floppytest_v1.04u read test. Need data separator for Teac drive
Build KLyball D-13 data separator…
Ok, floppy works (pass all floppytest_v1.04u tests).

Download many C4P Disk Images from <http://osi.marks-lab.com/software/osios5.html>.
All of them copy to floppy (using DiskTool) with no write errors.
All FAIL to boot.
I can hear floppy seek to track zero and step out a few times but I never get anything on screen or serial port.

Looking at memory it appears everything loads as expected (at address at first two bytes of track zero).

I tried poking first three bytes of a floppy image with D0 00 08… writing it to floppy and…
That worked (floppy data loads into VRAM)

But none of the C4P 5.25” *.65D I could find online do anything (other than just move the disk head).

Any clues? Debugging tips?

[bxdanny]

If the drive can be set for 300 or 360 rpm, it sounds like it could be an 80-track drive. Might it be stepping only a "half track" instead of a full track when it tries to read track 1, resulting in a failed read?

[bxdanny]

On second thought, if the drive is stepping at 96 tpi when reading, I guess it would have stepped that way when writing the disks in the first place, so they should work anyway, even if they wouldn't be compatible with standard 48 tpi drives. Anyway, you can check if the right data is being loaded from track 1. The first few bytes of track 1 in 65D (all 5.25" versions) should be 52 41 43 4B (part of the word TRACK) and should load to $2A00. Are you seeing that? If yes, try changing the instruction at $2294 to JMP $2A51, to skip trying to load BASIC and just go straight to the 65D kernel on loading track 1. You can first load just track 0 by entering the ROM at $FFF3, which loads track 0 and goes to the Monitor. Make that change, then start execution again at $2200.

Is there a second drive on the cable? You didn't mention one, but if there is, disconnect it. PIA port A is set up as all inputs when the ROM starts to boot the disk, but is then switched to make PA6 an output for the second drive's select line. Could that be causing some kind of interference?

I may be barking up the wrong tree entirely, but since no one else gave any suggestions, I thought I would at least try.

[davisgw]

I just went through debug of three systems that failed to boot, but I had original copies of OS65D, DOS/65, and HEXDOS to try booting, not ones written by the drive in question from Disktool. In the end I found that my data separators had two places on the trimmers where it looked like the timing was correct even though it was not. I can't explain it better than that. Also, verify all the lines in the ribbon cable are good and that the drive is getting correct signals. Do you have access to any original floppies to verify the reading? Debugging your system without one could send you down a rabbit hole.
Perhaps you should start with very simple software like HEXDOS which only loads from one track. Good luck.

[davisgw]

I forgot to mention that most drives have a terminator resistor pack which may be pulling down your drive levels. If you have 2 drives on the same ribbon cable you will likely need to remove one pack. And if you are using a PC ribbon cable your drive needs to be connected before the twist.
When I purchased my used floppy drives, in some cases it was not clear they were 80 track and they would not read my old floppies.

[geowar1]

SUCCESS!
The problem turned out to be that I had the KLyball D-13 data separator \ready set for 8" drives instead of grounded for 5.25" drives.
Once I changed that jumper the system booted just fine!

Next task is to get the Gotek working. Thanks for the help!

[geowar1]

Figured out the Gotek problem… turns out all the other systems were using the "twisted" [puke-cannon:PC] drive cables with all drives set for DS1.
The OSI used a non- "twisted" cable so I had to re-jumper the Gotek to use DS0 and… [drumroll]
IT WORKS!!!

I can use the OSI Serial Disk Tool to "3. Receive Disk Xmodem" and transfer '*.65d' disks and they work just fine.

I also tried using the osihfe tool to convert '*.65d' disk to '*.hfe' disks and copy those directly to the USB stick…
But… no good…

[This whole OSI project reminds me of the truism: "Experience is what you get when you didn't get what you wanted".

[Mark]

Here is an updated OSIHFE that may correct your conversion problems.

I still have some changes to make before the next release.
This version corrects a problem where sectors could be missed when writing OS65D images depending on the end of sector marker.
It also increases the number of characters searched before giving up on finding the start of track data.
As an experiment I changed the timing delays on 5.25" to match the timing in gotek HFE files written with Disktool.

Oh, my FF.CFG has two lines in it, and I don't think any are actually needed to use OSI HFE files. They are:
interface=shugart
index-suppression=no

When writing/converting .65D files it may help to run them through a clean operation on OSIHFE. e.g. "osihfe -c some_file.65d some_clean_file.65d"

I hope this helps!

[geowar1]

Sorry (not), Apple retiree here… I have a PC (hidden in an arcade box)… Not going to drag it out for this (too hard PITA)… Guess I could BootCamp…
If it's not too much to ask… a macOSX version? TIA