Release 4.0: Updated Vinculum utilities
glenn.f...@gmail.com
I am turning over a new leaf for the year and will be housing all of my Heath software (at least anything that’s of broad interest to the group) in standardized GitHub repositories. I have released the first such project: the Vinculum (VDIP) utilities. These let you copy files to/from USB flash drives on any system equipped with the VDIP1 device.
They are housed at:
https://github.com/sebhc/vdip-utilities
This release is version 4.0 (replacing the previous 4.0 Beta). I have corrected the code to work with 8080 as well as Z80 processors and I have added wildcard file naming to the VPUT command on HDOS (previously only available on the CP/M version). Documentation is here:
https://github.com/sebhc/vdip-utilities/blob/master/docs/Vinculum%20Utilities.pdf
At the moment I have only posted the HDOS executables (since my CP/M development system is currently indisposed.) I will update those when I can, meanwhile what’s there for CP/M is still the 4.0 Beta (Z80 only).
HDOS executables and H8D:
https://github.com/sebhc/vdip-utilities/tree/master/Executables/HDOS
CP/M executables and H8D:
https://github.com/sebhc/vdip-utilities/tree/master/Executables/CPM
If you have a previous working version of these you can use your old VGET or VPIP to transfer over these new executables, otherwise you can use modem transfer software or you can use the H8D image and H89LDR to create a floppy copy and then mount that to retrieve the files.
I have discovered that if you have a USB Flash drive that has a lot of files (e.g. I had 14G of 16G used) the software can time out due to slowness of the VDIP firmware when creating new files on heavily used drives. This is true even if the files are in subdirectories. My advice is keep the total number of files on your flash drive small and clean it out often.
We now have the VDIP1 capability on a number of Norberto’s boards so I hope many of you will be able to take advantage of this software. Please let me know of any comments, concerns, corrections, bugs or suggestions. Thanks!
- Glenn
norberto.collado koyado.com
Thank you very much, Glenn. I used the Z180 to get the files into the H37 floppy drive, then swapped CPU boards and it worked fine with the new 8080A board.
I just realized that it was just easier to just download the H8D fie and use the 8080A menu to create such floppy on the H17 controller. This is something I need to validate.
Norberto
--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
sebhc+un...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sebhc/07d301d9312b%2475ef1da0%2461cd58e0%24%40gmail.com.
Glenn Roberts
On Jan 26, 2023, at 2:26 AM, norberto.collado koyado.com <norberto...@koyado.com> wrote:
Thank you very much, Glenn. I used the Z180 to get the files into the H37 floppy drive, then swapped CPU boards and it worked fine with the new 8080A board.
I just realized that it was just easier to just download the H8D fie and use the 8080A menu to create such floppy on the H17 controller. This is something I need to validate.
<image001.png>
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855E05EE3399FAF2F3703D9F7CF9%40SN6PR01MB3855.prod.exchangelabs.com.
norberto.collado koyado.com
Thanks!
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/9A621764-D501-4873-B44D-17BC0BA3DC60%40gmail.com.
norberto.collado koyado.com
Glenn,
I downloaded your https://github.com/sebhc/vdip-utilities/blob/master/Executables/HDOS/VDIP%204.0%20HDOS.H8D and the floppy failed to mount. Then I tried with the munchkin.H8D and that worked.
From: se...@googlegroups.com <se...@googlegroups.com>
On Behalf Of Glenn Roberts
Sent: Thursday, January 26, 2023 1:45 AM
To: se...@googlegroups.com
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/9A621764-D501-4873-B44D-17BC0BA3DC60%40gmail.com.
norberto.collado koyado.com
This is the failure.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855A28FC9DF4CB937324737F7CC9%40SN6PR01MB3855.prod.exchangelabs.com.
norberto.collado koyado.com
Init shows the following:
norberto.collado koyado.com
Douglas,
Can you check this file on your simulator?
https://github.com/sebhc/vdip-utilities/blob/master/Executables/HDOS/VDIP%204.0%20HDOS.H8D
Norberto
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB385504ACB43ABB98F748C975F7CC9%40SN6PR01MB3855.prod.exchangelabs.com.
Douglas Miller
I also get the read failure, so looks like the problem is with
the image contents. I can't seem to run INIT on my HDOS2 image
(hangs during "DISMOUNTING ALL DISKS:"), but perhaps INIT.ABS is
corrupted on my copy of HDOS2.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB38553F860AF5B0F189F06F76F7CC9%40SN6PR01MB3855.prod.exchangelabs.com.
Douglas Miller
I also get the same "read failure" under HDOS 3. There I can run
INIT, and I see that it can read the label but I did not proceed
further.
Glenn Roberts
On Jan 26, 2023, at 10:28 PM, norberto.collado koyado.com <norberto...@koyado.com> wrote:
This is the failure.
<image002.png>
From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of norberto.collado koyado.com
Sent: Thursday, January 26, 2023 7:19 PM
To: se...@googlegroups.com
Subject: RE: [sebhc] Release 4.0: Updated Vinculum utilities
Glenn,
I downloaded your https://github.com/sebhc/vdip-utilities/blob/master/Executables/HDOS/VDIP%204.0%20HDOS.H8D and the floppy failed to mount. Then I tried with the munchkin.H8D and that worked.
<image003.png>
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB38551215F6C035CC8F655DA5F7CC9%40SN6PR01MB3855.prod.exchangelabs.com.
norberto.collado koyado.com
Created the attached VDIP1 H8D file using the 8080A menu.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/3CF55372-3047-4053-9647-E7C6141E2332%40gmail.com.
glenn.f...@gmail.com
I’ve pushed this corrected H8D to the GitHub site. Doug Miller also helped by creating the CP/M .COM executables plus an H8D as well. so the V 4.0 executable versions of the Vinculum/VDIP utilities should all be out there now!
https://github.com/sebhc/vdip-utilities/tree/master/Executables
again, documentation here:
https://github.com/sebhc/vdip-utilities/blob/master/docs/Vinculum%20Utilities.pdf
let me know of any issues, comments, corrections or suggestions…
Thanks Doug and Norberto!
- Glenn
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/BN7PR01MB3844D1FB848C4E9C1D69B833F7CC9%40BN7PR01MB3844.prod.exchangelabs.com.
Douglas Miller
As a follow-up to the problems we were seeing, I ran across
something related while working on a JAVA program to create HDOS
H8D images and add files to them. It seems that HDOS 2 does not
tolerate the timestamp (as opposed to datestamp) field of the
directory entry. When I populate my file entries with BCD
hours/minutes in that field, HDOS 2 refuses to do a DIR (it mounts
OK, though). If I leave those fields 00 00, then HDOS 2 is fine
with it. I noticed that the H8D that Norberto created was made
just after midnight, so the time fields were things like 00 01 and
00 02. I'm not sure what HDOS 2 is choking on, but it does seem
that the time stamp needs to be close to 0. HDOS 3 is fine with
the timestamps set, but does not display that information in the
DIR output.
Anyone know what this is all about?
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/034001d932b3%2471dacdc0%2455906940%24%40gmail.com.
glenn.f...@gmail.com
Doug: what field are you referring to? to my knowledge there is no time stamping in HDOS directory entries, only dates. Here’s DIRDEF.ACM:
DIR SPACE 3,10
** DIRECTORY ENTRY FORMAT.
ORG 0
DF.EMP EQU 377Q FLAGS ENTRY EMPTY
DF.CLR EQU 376Q FLAGS ENTRY EMPTY, REST OF DIR ALSO CLEAR
DIR.NAM DS 8 NAME
DIR.EXT DS 3 EXTENSION
DIR.PRO DS 1 PROJECT
DIR.VER DS 1 VERSION
DIRIDL EQU * FILE IDENTIFICATION LENGTH
DIR.CLU DS 1 CLUSTER FACTOR
DIR.FLG DS 1 FLAGS
DS 1 RESERVED
DIR.FGN DS 1 FIRST GROUP NUMBER
DIR.LGN DS 1 LAST GROUP NUMBER
DIR.LSI DS 1 LAST SECTOR INDEX (IN LAST GROUP)
DIR.CRD DS 2 CREATION DATE
DIR.ALD DS 2 LAST ALTERATION DATE
DIRELEN EQU * DIRECTORY ENTRY LENGTH
16-bit date format is:
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/1004cfbc-a9d2-a739-97d2-2d0c13604640%40gmail.com.
Douglas Miller
Right, the HDOS 3 DIRDEF.ACM (from the guthub repo) has:
...
DIR.NAM DS 8 ; NAME
DIR.EXT DS 3 ; EXTENSION
DIRIDL equ * ; file identification length /3.0a/
DIR.CTH DS 1 ; creation time (BCD hours) /3.0a/
DIR.CTM DS 1 ; creation date (BCD minutes) /3.0a/
...
And I do see some HDOS 3 disk images with time stamps there. But, that seems to be an incompatibility, at least with the HDOS 2 version I'm running ("ISSUE # 50.06.00").
HDOS 2 prints a "DEVICE FORMAT ERROR" message when I try to DIR
an image with timestamps. At least with timestamps that are far
away from 00 00.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/001701d932bf%24f1c2ad30%24d5480790%24%40gmail.com.
norberto.collado koyado.com
You are right it won’t work with HDOS2 as it was created under HDOS 3.0, my bad.
Norberto
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/c5ee62e4-3f96-1097-3176-a4db49dcfa0b%40gmail.com.
Douglas Miller
Ah, the same error message I'm seeing when I set the timestamp fields non-zero.
While we're already off-topic, is the HDOS 2 source code
available someplace? Even the HDOS 3 source code I have may not be
complete (no utilities source, I believe). Or is there
detailed/authoritative documentation on how HDOS works -
particularly the filesystem? The article "Microcomputing Magazine
Dissecting the HDOS Disk" on SEBHC web is very superficial.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855AB399737ABDEC076A85CF7CD9%40SN6PR01MB3855.prod.exchangelabs.com.
glenn.f...@gmail.com
So David Troendle and I worked on a project a few years ago to scan the PDF listings for HDOS 2.0. Dave did some brilliant work to write software to remove artifacts from the scans (like the horizontal bars from the paper) and I did some spot checking to find/correct typos, I then re-assembled the code to verify that it agreed with the original HDOS .ABS code (except for “don’t care” space. At the time we hosted those source listings on BitBucket – perhaps it makes more sense to consolidate now on GitHub? The link is mentioned on the SEBHC website but perhaps not prominently enough. The scanned source code lives here:
https://bitbucket.org/HeathkitGuy/sebhcsoftware/src/master/HDOS/
I’m not sure if we ever finished every single program. Would have to go back and check.
David has also hosted other useful scans there
https://bitbucket.org/HeathkitGuy/heathkitinformation/src/master/
I’m not aware of an HDOS 3 GitHub repository. Where does it live? I’ve just been using a local copy on my PC . here are the source modules I see
Plus a bunch of device driver-related files (below) and a slew of ACM files (not listed here)
It does seem like a good idea to get more organized on all of this…
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/03c1e3d7-7341-0727-e838-74a700d56593%40gmail.com.
Douglas Miller
Thanks, the HDOS 2 source will help a lot with understanding how to fake an HDOS disk image.
I'm not sure where I got my HDOS 3 source files, but it does not appear to be from any github repository. Looks like I just put it into a git repo to store it someplace. I've added the HDOS 2 source to that repo now. I can push that out to github, and from there we can work on organizing it in a sensible manner. If you think that's useful.
The HDOS 3 source files I have are just a partial, looks like you
have much more below. I see they are all in H8D, which is not easy
to work with when you don't run HDOS. After doing the work in JAVA
to create HDOS disk images, I was considering taking the next step
and making a util to "explode" an HDOS H8D into native files. With
all these H8Ds to look at, that might be a worthwhile project.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/006f01d9331f%244958f630%24dc0ae290%24%40gmail.com.
glenn.f...@gmail.com
I hadn’t realized there was such a significant difference between the HDOS2 and HDOS3 directory entries (I guess I really need to get smarter on HDOS 3). They commandeered the PROJECT (DIR.PRO) and VERSION (DIR.VER) bytes to do the time/date and also got rid of the CLUSTER FACTOR (DIR.CLU) and RESERVED bytes.
I guess not surprising that there could be some backward compatibility issues, but I don’t see DIR.PRO, DIR.VER , or DIR.CLU specifically referenced in the HDOS 2 PIP source.
-glenn
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/c5ee62e4-3f96-1097-3176-a4db49dcfa0b%40gmail.com.
glenn.f...@gmail.com
Here’s some C code I wrote that does most of what you want if that helps (see extract() in h8dinfo). Can’t believe the date on this is 2013!
I believe I got the HDOS 3 disks from the SEBHC site
https://sebhc.github.io/sebhc/software.html
glad to help get this all cleaned up and organized!
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/edeb264f-654f-0f39-1e25-2d4bc6af7d0d%40gmail.com.
Mark Garlanger
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/00ab01d93322%24e75b8660%24b6129320%24%40gmail.com.
Douglas Miller
Thanks, Mark. That is definitely more than I had.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAAjkm78bOwzJv0_ftnSmdvzMG01-TSnY0rdZ6UFOeKg_fkZ4Dw%40mail.gmail.com.
Mark Garlanger
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/58412b6a-f950-497b-4ae2-2394e260c781%40gmail.com.
Douglas Miller
That's like asking someone what's missing from a landscape they've never seen before! :-}
I mainly wanted the HDOS 2 source, so I could make a reasonable attempt to replicate the disk initialization. From the INIT 2.0 code I'm looking at, it made a lot of assumptions and hard-coded many things. Did HDOS 2 ever use sector sizes other than 256? Since my main goal is to create a disk image that will work on any version of HDOS, I probably need to stick to HDOS 2 restrictions. I already got into trouble adding the timestamp from HDOS 3, which was not tolerated by HDOS 2.
Right now, it (vdip floppy image creation) is working for the
single-side 48tpi "H8D" images. At some point I'll test DS and DT,
and probably try H37 formats (that have 256-byte sectors). But I
guess those aren't strictly "H8D" - although I can still create
images for my simulator and test them there.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAAjkm785Ygn%2BxM45%2Bsv1vn6n68xx_GzCECXPC%3DMS1eSauxwrPQ%40mail.gmail.com.
glenn.f...@gmail.com
I don’t think I’ve seen any HDOS devices or drivers where sector size wasn’t 256. Even the Z67 uses 256-byte sectors. This makes large devices very inefficient in use of storage space. E.g. my Z67IDE+ has eight 1.9M devices (SY0: .. SY7:), but because there can only be 256 “groups” on a device (The Group Reservation Table is always 1 sector) each group is 30 sectors, so even the smallest file automatically uses 7.5K of storage.
MS-DOS had a similar problem with 12-bit FAT entries, but it was easier to extend that to 16 bits and later 32. Changing the GRT to be multiple sectors would probably be a pretty big change…
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/b198aaf7-4200-fd71-f8d1-8e906b5306b0%40gmail.com.
