Image Map Image Map
Page 16 of 22 FirstFirst ... 6121314151617181920 ... LastLast
Results 151 to 160 of 219

Thread: KAYPRO and KayFreHD as a hard disk module

  1. #151

    Default

    So there is progress.

    1) I created a new HD image on the TRS-80. VHDUTL can create an image for a ST-251 on the fly as part of the mount (MNT) option. This is a 45MB drive which is all I need for the Kaypro.

    2) I connected up the adaptor board and the FreHD. Unfortunately the 50 way female connector I had has very short mounting pins so I couldnt get the adaptor to sit properly on the Kaypro MB and maintain a good contact. I need either a taller socket or some spacers to raise the mainboard a little to allow the daughterboard to clear the floppy cage. In the interim I made a second adaptor that can take a short ribbon cable.

    3) With a ribbon cable linking the adaptor to the Kaypro motherboard ADVFMT could see the FreHD as a HD adaptor but there was a massive amount of garbage on screen and lost characters when typing. Looking at the schematic for the adaptor it seems that the only source of power for the buffer chips is the two pin PWR connector on the adaptor board. It does seem to work without this power connected, maybe the LS chips can draw enough power from their inputs, it could be that this problem would be less if the adaptor was plugged straight into the Kaypro MB. For now I am powering both the adaptor and the FreHD. This seems to solve the garbage character issue.

    4) I discovered that ST-251 is NOT in the prepackaged list of HD's supported by ADVFMT. I therefore put in the required heads and cylinders using option 20 (user defined drive) This works and I ran the full HD test suite to test the FreHD without issue.

    5) I successfully partitioned the drive into 6 partitions of about 8MB each. I selected 4kb blocks and 1024 directory entries. ADVFMT says it formated ok. I checked in Turbomap and all drives are there.

    HOWEVER

    I cant copy anything onto the HD partitions, when I do I am told that there isnt enough directory space. Since these drives are empty I dont understand why that is happening. I have tried a variety of formats and block/directory sizes without luck

    Open to suggestions

  2. #152
    Join Date
    Jan 2012
    Location
    Connecticut, USA
    Posts
    2,720

    Default

    Quote Originally Posted by Fletch View Post
    4) I discovered that ST-251 is NOT in the prepackaged list of HD's supported by ADVFMT. I therefore put in the required heads and cylinders using option 20 (user defined drive) This works and I ran the full HD test suite to test the FreHD without issue.
    Can you post those settings?

  3. #153

    Default

    Quote Originally Posted by VERAULT View Post
    Can you post those settings?

    Cylinders: 840
    Heads: 6
    Skew: 1
    No landing Zone

    I have tried both Advent 512 byte format and Kaypro format. The Advent format lets you partition the drive with different combinations of block size and directory entries, none of which work. I have tried a couple of different SD cards including the one from the working TRS-80. The disk image filesize does increase after partitioning and the FreHD passes the "surface test" where there are multiple low level reads and writes to the card.
    Last edited by Fletch; March 2nd, 2020 at 08:22 AM.

  4. #154

    Default

    More progress.

    The image generated by the VHDUTL command produces a file that is only a few Kb in size and is expected to expand as more data is added. I can see that this works because just running the surface test on the drive increases the SD card file to around 32k. As a hunch I took one of Ian's TRS-80 image files that is about 42MB in size and formatted it for the Kaypro. This produced an immediate improvement. Instead of PIP failing on the first file I was able to transfer about 20 files before I ran out of directory space. When I list the directory, I see a number of "blank" <space>.<space> entries between the legitimate files. My guess is that the format of the directory isn't working properly.

    I tried again this time using Advent 1024 format. This time I was able to copy all the files (about 28 files) from A: to C: Directory listing again showed garbled none existent entries. I used Turbogen to copy a 56K system image to C:. This resulted in a bootable HD but all files on C: disappeared. Recopied them from A: and this time the directory is clean with no garbled entries.

    I never had a CP/M machine with a HD back in the day, would we expect that copying the system tracks to a HD would delete the data on that partition? Do I have to copy system tracks onto every partition?

  5. #155
    Join Date
    Aug 2008
    Location
    Burlington, VT
    Posts
    176

    Default

    I'm about to embark on replacement of the WD controller and disk in my Kaypro 10 with the FreHD. One concern at the moment is how to transfer the contents of the current (flaky) Seagate disk to the FreHD. I can image the hard drive using David Gesswein's mfmemu device, so that part of the equation is doable. Can anyone point me to a format description of the FreHD image file? I assume I'll need to prepend some sort of informational header to the raw block data, but prefer not to engage in a reverse engineering exercise if it's documented somewhere.

  6. #156
    Join Date
    Aug 2008
    Location
    Burlington, VT
    Posts
    176

    Default

    After a lot of digging, I found the header description in 'reed.h' from the xtrs sources. What I'm not understanding at all is how the FreHD determines the emulated disk geometry. The cylinder count is restricted to a single byte and there is no field for number of heads. The original drive had 820 cylinders and 6 heads, so I'm not getting how to properly describe it in the header.

  7. #157
    Join Date
    Aug 2008
    Location
    Burlington, VT
    Posts
    176

    Default

    Quote Originally Posted by Fletch View Post
    More progress.

    The image generated by the VHDUTL command produces a file that is only a few Kb in size and is expected to expand as more data is added. I can see that this works because just running the surface test on the drive increases the SD card file to around 32k. As a hunch I took one of Ian's TRS-80 image files that is about 42MB in size and formatted it for the Kaypro. This produced an immediate improvement. Instead of PIP failing on the first file I was able to transfer about 20 files before I ran out of directory space. When I list the directory, I see a number of "blank" <space>.<space> entries between the legitimate files. My guess is that the format of the directory isn't working properly.

    I tried again this time using Advent 1024 format. This time I was able to copy all the files (about 28 files) from A: to C: Directory listing again showed garbled none existent entries. I used Turbogen to copy a 56K system image to C:. This resulted in a bootable HD but all files on C: disappeared. Recopied them from A: and this time the directory is clean with no garbled entries.

    I never had a CP/M machine with a HD back in the day, would we expect that copying the system tracks to a HD would delete the data on that partition? Do I have to copy system tracks onto every partition?
    Hi, Fletch. I just re-read your posting. After you use the Advent tools to partition and format the drive, you must generate + write a system,then reboot before trying to access the new volumes. Perhaps you did that up front, but your description above implies you generated a new system _after_ first trying to access the drive. If that was indeed the case, I'm not surprised there were issues.

  8. #158
    Join Date
    Aug 2008
    Location
    Burlington, VT
    Posts
    176

    Default

    And... Success! The header description from the xtrs sources predates Kaypro CP/M support. The required information is in 'reed.h' from the FreHD v1.14 firmware sources. The reserved byte at offset 26 is repurposed for number of heads. Cylinder count is now a 16-bit word with high-order byte at offset 27 and low-order at 28. One point I'm still a bit unsure about is offset 29: number of sectors per cylinder. I'm assuming this means actual physical sectors (1024 bytes in the case of the Advent hard disk format) rather than TRS80 equivalent sectors (256 bytes). For my 6-head drive, this is 54 (36h).

    The steps to migrate my existing drive:

    Capture a sector data image from the ST251 using the mfmemu device (http://www.pdp8online.com/mfm/mfm.shtml)

    Grab the 256 byte header from any FreHD hard disk image (dd if=hdimage of=header.bin bs=256 count=1).

    Use a hex editor to enter physical drive parameters per 'reed.h' and my advice above. Zero the checksum byte at offset 3.

    Write a quicky C utility to generate the checksum (described in reed.h), then use hex editor to patch that into location 3.

    Concatenate header and data into a FreHD image (cat header.bin data.bin > hard4-1)

    Copy hard4-1 to an SD card and insert into FreHD

    Turn on system and... bingo! Booted the first time and appears to be operating correctly. All six CP/M volumes are showing up as expected. I'm going to continue testing, but so far so good. Next step is to update the vhdutlkp.com utility to accept real-life head, cylinder and sector counts rather than assuming the TRS80 LDOS environment.

  9. #159
    Join Date
    Aug 2008
    Location
    Burlington, VT
    Posts
    176

    Default

    Here are a couple of photos of the FreHD and adapter installed in my K10:

    install2b.jpg

    install2a.jpg

    I highly recommend mounting a female DIP connector and plugging the piggyback directly into the FreHD. Worked out very well. By angling the power connector, there's plenty of height for the 50-pin cable from the motherboard. All power is coming over the 50-pin connector from the motherboard. Although there have been reports of problems with this approach, it seems quite stable. Getting rid of the hard drive removed the major source of heat from the system. Although not shown here, I ended up replacing the noisy AC fan with an adjustable speed DC fan from my scrap box. I can back it down to just a whisper and it keeps the unit nice and cool.

    After a bit of thought, I'm not going to bother with the vhdutlkp utility. Should be simpler to code a Python application that can be used on any modern platform to create a blank Kaypro-compatible hard disk image.
    Last edited by shirsch; March 31st, 2020 at 10:58 AM.

  10. #160
    Join Date
    Apr 2018
    Location
    Los Angeles, CA
    Posts
    920

    Default

    I'm planning on embarking on this project soon but for an older Kaypro II. Would be great if anyone could share any Kaypro Hard Drive Images they have created.

    I do have a FreHD to build (as well as the shim for the older kaypro), but I'm curious is anyone has tried this with the TRS-IO instead of the FreHD (or has an idea why it wouldn't work). I'll likely try both but it would cool if that worked as well.
    -- Brian

    Systems: Amstad PCW 8256, Apple IIe/II+/GS/Mac+/Mac 512k, Atari 800/520STFM, Commodore 64/128/Amiga 3000/PET 4032/SX-64, IBM PS/1 2121-B82, Kaypro II, Osborne 1, Tandy 1000 SX, TI-99/4A, Timex Sinclair 1000, TRS-80 Color Computer 3/Model 4 GA

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •