View Full Version : Need assistance fine tuning floppy emulator on Kaypro 4/84

May 19th, 2018, 11:43 AM
So I had some time to kill on this particularly rainy saturday; So I thought Id finally get to setting up my gotek floppy emulator for use in one of my kaypro 4/84's.
I decided to go with the HXC firmware..... Just because. I like the HXC website and documentation I suppose. I flashed the gotek with the HXC loader and installed the newest beta firmware (all this per the documentation)

I also decided to install the OLED screen and piezo sound mod... Because why not?

So first off, it all seems to work.. Sort of. Documentation to use a gotek with HXC firmware on a kaypro is pretty spotty so im just picking and grabbing at facts I find.

The big problem I get is I am using the floppy file format from Joes computer museum explains here: https://youtu.be/CL2C4geiF7Q?t=142
I made a couple blank floppies using this format and saved them to the usb stick. I used the IMD image disks found on daves old computers http://www.classiccmp.org/dunfield/img54306/system.htm
and with the hxc floppy emulator software I converted the IMD files into HFE files. I was then able to boot the kaypro from a CP/M boot image.
ITs strange, HXC states the reader will read image disk .IMD file formats but mine only seems to like the HFE format, thats why I did that.

So I created those blank floppy images and then using MFDISK.COM I formatted them to Kaypro DS/DD and they went to track 80 with no errors.

When I try to use pip and copy files from the floppy B: (which is still a standard floppy drive) I get an error. See attached images.


I am wondering if I have a setting wrong somewhere. Is write protect enabled somewhere? I assume not if I can format it. I have a jumper across the SO pins on the header with JB going to the piezo and thats it.

On another note, does anyone know how to change the volume on the piezo speaker? Its set way to low I think and I want to try the max setting.

May 19th, 2018, 12:43 PM
Try doing a Crtl-C before you do the PIP. Usually, CP/M BDOS gives that message when it detects that you've changed a disk that you're writing to without telling it about what you did. In other words, CP/M computes a checksum from the disk directory and if said checksum changes when BDOS is about to write, it shuts you down and declares the target to be R/O.

May 19th, 2018, 12:53 PM
Hey Chuck, problem with that is it does a warm boot. See when I boot it to a floppy image with CP/M I then have to switch to a blank floppy image. If I do a warm boot then it will try loading cp/m from the selected blank image and just sit there.

Again, just trying to copy files from the B: floppy drive to the blank formatted disk on the gotek. Its weird

May 19th, 2018, 01:04 PM
I suppose you could write a little program to do a BDOS CP/M call to "reset disk system", but I think your cheapest and dirtiest option is to make the real floppy drive A: and the HxC one B: I assume that you have a boot diskette.

May 19th, 2018, 01:07 PM
Sure I can do that. But in my mind that somehow defeats the purpose of the whole venture. Having to rely on the old floppies. Reason I started doing this is 4 kaypro floppy drives died on me. I was able to get one working again by calibrating it, but these things are ticking time bombs. Wont be that long before they expire.

May 19th, 2018, 01:13 PM
An alternative is to place valid boot data on your A: drive images. It doesn't occupy any user disk space--that way, you can still do the Crtl-C and not worry about not having a system to load.

Back in the day when I still cared about using CP/M, that was my modus operandi when formatting up a blank floppy--always have boot data on every floppy.

May 19th, 2018, 02:54 PM
Well Chuck, your method is working. If I run sysgen and make each diskette a boot disk IT lets me copy the files over with PIP. Anyway, Id still like to understand what is really going on here. What is loaded into RAM that is causing the bdos error when I change disks?

May 19th, 2018, 03:44 PM
As I explained, everytime the BDOS accesses the disk directory, it computes a checksum of a (BIOS-determined) number of the directory entries. Clearly, the number for hard disks is zero, as most hard-disk CP/M systems don't change media in mid-task. When the BDOS is going to write (or update) a directory entry, it first re-computes the checksum and compares it against the one it last computed.

If the two sums are different, then the floppy has been changed and it is no longer safe to write to that disk. So BDOS sets the status of the drive to read-only and it stays that way until either a program makes a BDOS call 13 or the system is rebooted (warm or cold).

Were this not to happen, then any disk swapped in could inadvertently get overwritten. This situation is well-understood and has been part of CP/M since at least version 1.4.

May 19th, 2018, 03:49 PM
Thanks for explaining it Chuck. Guess, I will learn to work around this functionality.

May 19th, 2018, 05:57 PM
You could write a small program to issue a BDOS 13 request, but where would you put it? :)

May 19th, 2018, 06:39 PM
If I ever add a hard drive to a kaypro that might be a viable option.

May 21st, 2018, 09:19 AM
It was very common practice to sysgen every disk you formatted when using CP/M. That way you never worried about hitting ^C when changing disks. Unless you were using a SSSD system, the boot tracks simply didn't occupy enough space to worry about.


May 21st, 2018, 09:33 AM
Presence or absence of boot tracks has no effect on the amount of user space on a CP/M floppy. Boot tracks are completely outside of the file system. If you format and don't sysgen, you get whatever format pattern the formatter last wrote on the boot tracks (e.g. all E5 or F6).