H8D Utility in ROM

85 views
Skip to first unread message

glenn.f...@gmail.com

unread,
Sep 19, 2021, 8:16:38 AM9/19/21
to se...@googlegroups.com

Question for Douglas or maybe Norberto:

 

I tried using the “XH” function in the Rev. 4 board’s ROM.  But have been unsuccessful.  I believe my hardware is set up fine as I can boot my saved client from the H17 and transfer files.  But when I try to execute the XH function I’m unable to get the client and server to communicate.  The documentation for the ROM says the XH runs the H8D Utility bootstrap.  So that’s not the full client I guess. 

 

After doing XH on the H8 I run Les’ H89LDR program (v 2.2) and click on “create” and then “status”.  It times out and says client is not running but then gives me the “SAVE” option.  That causes H89LDR3.BIN to download, which is successful, but then I get “The operation has timed out”  if I click on Client Status I get “the client is not running…” message.

 

I’m able to run the H8D utility just  fine from my saved boot disk, which is very fast and easy.  Just boot the disk (a few seconds) and then H8D Utility immediately reports “client is ready”.

 

But if I could figure out how to use XH I might demo it at VCF…

 

Tx for any help.  Undoubtedly operator error 😊

 

  • Glenn

 

Douglas Miller

unread,
Sep 19, 2021, 8:35:07 AM9/19/21
to se...@googlegroups.com

I don't think I was able to test that function, as I think H8DUtility runs only on Windows? But I believe Norberto tested it out. But, we then started work on VH8DUTIL.SYS (http://sebhc.durgadas.com/mms89/h8mon2/vh8dutil.sys) which is run from a VDIP1 USB drive (H8D images also on USB drive). This method quickly became Norberto's favorite. Still room for improvement, but it avoids the whole serial port synchronization issues.

--
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/028301d7ad50%2430f7bcd0%2492e73670%24%40gmail.com.

glenn.f...@gmail.com

unread,
Sep 19, 2021, 8:59:03 AM9/19/21
to se...@googlegroups.com

I will give that a try.  Yes being able to pull off of H8D images on the flash drive sounds quite nice… tx.

dwight

unread,
Sep 19, 2021, 9:31:42 AM9/19/21
to se...@googlegroups.com
As I recall, there are parts of the H89LDR3 that are intended to over write part of the code that loads it. That is how it switches from the init of the serial to running the loader part. If it is running from ROM, it can't overwrite it. I'm assuming that XH is the part that initializes the serial port.
The original code had a small piece of boot strap code that was hand entered to get the serial port initialized and then load the main client H89LDR3. The H89LDR3 is loaded from high to low in memory when it gets to the bootstrap code it overwrites the last instruction with a nop. This transfers the code to the H89LDR3 code that then realigns itself, incase there is an extra byte in the serial buffer that wasn't cleared by simple serial bootstrap.
I'm assuming that that is what is being talked about.
Dwight


From: se...@googlegroups.com <se...@googlegroups.com> on behalf of glenn.f...@gmail.com <glenn.f...@gmail.com>
Sent: Sunday, September 19, 2021 5:16 AM
To: se...@googlegroups.com <se...@googlegroups.com>
Subject: [sebhc] H8D Utility in ROM
 
--

Douglas Miller

unread,
Sep 19, 2021, 9:35:02 AM9/19/21
to se...@googlegroups.com

This ROM command actually runs in RAM, at the same address as the manually-entered code. In fact, the entire ROM runs in RAM shortly after RESET.



On 9/19/21 8:31 AM, dwight wrote:
As I recall, there are parts of the H89LDR3 that are intended to over write part of the code that loads it. That is how it switches from the init of the serial to running the loader part. If it is running from ROM, it can't overwrite it. I'm assuming that XH is the part that initializes the serial port.
The original code had a small piece of boot strap code that was hand entered to get the serial port initialized and then load the main client H89LDR3. The H89LDR3 is loaded from high to low in memory when it gets to the bootstrap code it overwrites the last instruction with a nop. This transfers the code to the H89LDR3 code that then realigns itself, incase there is an extra byte in the serial buffer that wasn't cleared by simple serial bootstrap.
I'm assuming that that is what is being talked aboThis option runsut.
Dwight


From: se...@googlegroups.com <se...@googlegroups.com> on behalf of glenn.f...@gmail.com <glenn.f...@gmail.com>
Sent: Sunday, September 19, 2021 5:16 AM
To: se...@googlegroups.com <se...@googlegroups.com>
Subject: [sebhc] H8D Utility in ROM
 

Question for Douglas or maybe Norberto:

 

I tried using the “XH” function in the Rev. 4 board’s ROM.  But have been unsuccessful.  I believe my hardware is set up fine as I can boot my saved client from the H17 and transfer files.  But when I try to execute the XH function I’m unable to get the client and server to communicate.  The documentation for the ROM says the XH runs the H8D Utility bootstrap.  So that’s not the full client I guess. 

 

After doing XH on the H8 I run Les’ H89LDR program (v 2.2) and click on “create” and then “status”.  It times out and says client is not running but then gives me the “SAVE” option.  That causes H89LDR3.BIN to download, which is successful, but then I get “The operation has timed out”  if I click on Client Status I get “the client is not running…” message.

 

I’m able to run the H8D utility just  fine from my saved boot disk, which is very fast and easy.  Just boot the disk (a few seconds) and then H8D Utility immediately reports “client is ready”.

 

But if I could figure out how to use XH I might demo it at VCF…

 

Tx for any help.  Undoubtedly operator error 😊

 

  • Glenn

 

--
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/028301d7ad50%2430f7bcd0%2492e73670%24%40gmail.com.
--
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.

dwight

unread,
Sep 19, 2021, 9:43:11 AM9/19/21
to se...@googlegroups.com
Then that shouldn't be the issue. It might be that it is not switching to RAM and is still running from the ROM. Also, there is the init of the disk parameters that is often missed. This is by attempting a disk load first. 
Dwight



From: se...@googlegroups.com <se...@googlegroups.com> on behalf of Douglas Miller <durga...@gmail.com>
Sent: Sunday, September 19, 2021 6:35 AM
To: se...@googlegroups.com <se...@googlegroups.com>
Subject: Re: [sebhc] H8D Utility in ROM
 

Douglas Miller

unread,
Sep 19, 2021, 9:59:56 AM9/19/21
to se...@googlegroups.com

RAM is still on (stays on after RESET), unless something else turns it off. It may be that H8Dldr3 is manipulating port 362Q erroneously. H17 initialization is performed as part of the command.

glenn.f...@gmail.com

unread,
Sep 19, 2021, 10:46:38 AM9/19/21
to se...@googlegroups.com

It does appear to manipulate port 362Q to control single vs. double sided (below). Not sure if this could be the cause of what I was observing?

 

SETSID1:               ; Set port 362Q bit 6 (40h)

                                IN 362Q

                                ORI 40H

                                OUT 362Q

                                RET

                               

SETSID2:               ; Unset port 362Q bit 6 (0BFh)

                                IN 362Q

                                ANI 0BFH

                                OUT 362Q

                                RET

 

From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of Douglas Miller

Douglas Miller

unread,
Sep 19, 2021, 10:53:21 AM9/19/21
to se...@googlegroups.com

Ah, that code is not valid... "IN 362Q" reads the dipswitch settings, *NOT* the current value (last) output to 362Q. The "image" of the last "OUT 362Q" is maintained by the ROM at location 2036H (as was done by prior ROMs that support port 362Q). So, that code should be something like:

LDA 2036H
ORI 40H
STA 2036H
OUT 362Q

and should ideally do that with interrupts disabled (or at least 2mS clock OFF).

Norberto Collado

unread,
Sep 19, 2021, 5:24:47 PM9/19/21
to se...@googlegroups.com

Glenn,

 

Please use the VH8UTIL as it doesn’t depend on the use of a laptop. Just put the *.H8D file in the VDIP1 and start the utility as shown below (in this case I have an H8D image called “SAVE”). You can deploy H8D’s or create a backup from the floppy into the VDIP1 if needed. It is very easy to use and it doesn’t use the laptop to download files. The XH command works but there are some specific steps to follow. I will need to find my notes on this as I’m a fan of the VH8UTIL instead.

 

During the show you can make copies into H17 floppy media easily or copy from someone else floppy media if needed with the VH8UTIL.

 

 

Hope this helps.

 

Norberto

Glenn Roberts

unread,
Sep 19, 2021, 6:42:58 PM9/19/21
to se...@googlegroups.com
Have you used this with the SVD? Could be a nicer way to load images vs having to connect the SVD to a laptop?

Sent from my iPad

On Sep 19, 2021, at 5:24 PM, Norberto Collado <norberto...@koyado.com> wrote:



Glenn,

 

Please use the VH8UTIL as it doesn’t depend on the use of a laptop. Just put the *.H8D file in the VDIP1 and start the utility as shown below (in this case I have an H8D image called “SAVE”). You can deploy H8D’s or create a backup from the floppy into the VDIP1 if needed. It is very easy to use and it doesn’t use the laptop to download files. The XH command works but there are some specific steps to follow. I will need to find my notes on this as I’m a fan of the VH8UTIL instead.

 

During the show you can make copies into H17 floppy media easily or copy from someone else floppy media if needed with the VH8UTIL.

 

<image001.png>

Douglas Miller

unread,
Sep 19, 2021, 8:17:08 PM9/19/21
to se...@googlegroups.com

Just to summarize, whatever variation of H8xLDR that Glenn is using has a bug in it's double-sided support, and is not likely to work (although one could get lucky depending on their dipswitch settings - although I doubt it). The two source code repos I have do not show double-sided support, and the H89LDR9 link on sebhc.github.io is broken. It does appear that Les' code has been forked a few times by various developers, and so we are probably losing track of it. If this variation includes any changes to the bootstrap routine, then it is probably incompatible with the ROM's XH command as well.

VH8DUTIL.SYS does not (yet) support double-sided or double-track drives/media.

Les Bird

unread,
Sep 19, 2021, 9:46:45 PM9/19/21
to SEBHC
Douglas,

H8DIMGR is the utility used for multi-sided disk image support. It can found here along with the 8080 ASM source code (scroll down to the Utilities section):

H89LDR is not used for reading/writing multi-sided disk images. The way it works is you create a H8DIMGR disk using H89LDR and then you boot using that disk. It will boot into HDOS with H8DIMGR2.ABS on it. Launch H8DIMGR2.ABS and it works in place of H89LDR and handles reading/writing high capacity (100K, 200K and 400K) disk images.

Les

norberto...@koyado.com

unread,
Sep 19, 2021, 10:12:07 PM9/19/21
to se...@googlegroups.com

Not yet! In the To-Do-List!

 

Norberto

Les Bird

unread,
Sep 19, 2021, 10:13:34 PM9/19/21
to SEBHC
Douglas,

Fixed the broken link. Thanks for pointing that out.

Les


On Sunday, September 19, 2021 at 8:17:08 PM UTC-4 Douglas Miller wrote:

Douglas Miller

unread,
Sep 19, 2021, 10:16:32 PM9/19/21
to se...@googlegroups.com

Hi Les,

Your code there looks correct - the side 0/1 routines use location 2036H as expected. Glenn must be using some other variation.

Glenn Roberts

unread,
Sep 20, 2021, 6:37:29 AM9/20/21
to se...@googlegroups.com

My bad for posting a comment on an 10-year old file I found on my PC.  I shouldn’t have weighed in – caused confusion.  And to put any fears of a fork in the code to rest, I’m not using or enhancing this code, just had it from a download way back (dated 4/23/2011).

 

I’ve always used the “H8D Utility” to image disks.  I guess I should take a look at “H8DIMGR”…

 

For any demo I’ll focus on the VDIP-based VH8DUTIL – looks pretty cool!

Les Bird

unread,
Sep 20, 2021, 7:49:52 AM9/20/21
to SEBHC
Glenn,

H8DIMGR works alongside H8DUtility. You run H8DUtility (new version 3 coming soon by the way with OSX/Linux support) on the PC and H8DIMGR on the Heathkit (in place of H89LDR). H8DIMGR is a combination of H89LDR code and some HDOS calls to support up to DS/80 track disks.

Les

Douglas Miller

unread,
Sep 20, 2021, 9:01:48 AM9/20/21
to se...@googlegroups.com

Hi Glenn,

Do we still have a potential problem with the XH command in the new ROM? Or were you attempting to use this old code with the H8DUtility?

Thanks,

Glenn Roberts

unread,
Sep 20, 2021, 11:12:49 AM9/20/21
to <sebhc@googlegroups.com>
Im not sure. It sounds like Norberto made it work. I was running the latest (I think) version of the H8D Utility on the pc and after it reported successfully downloading the client i could get no response.

Douglas Miller

unread,
Sep 20, 2021, 11:21:22 AM9/20/21
to se...@googlegroups.com

I guess we wait and see if it can be reproduced. The source code you sent definitely has a problem, and would likely result in a hang (H8D Utility timeout) as it turns off the 2mS clock (assuming dipswitches are set for Z17). It could also affect CPU speed and possibly ROM/RAM (ORG0). If the H8LDR binary that got "booted" into the H8 was from that source code, it would very likely (almost certainly) hang. I don't know how easy it is to mix-and-match H8D Utility with various H8LDR versions, but it will all depend on what combination you were running.

Again, anything that was built using the source code you shared would likely hang and result in a timeout.

Norberto Collado

unread,
Sep 20, 2021, 11:37:44 AM9/20/21
to se...@googlegroups.com

I will verify again tonight once I get home.

 

Norberto

Norberto Collado

unread,
Sep 20, 2021, 11:46:26 AM9/20/21
to se...@googlegroups.com

This is what I did back them on this XH Utility using port 340Q and it worked. I will try again tonight.

 

On the H8:

A black sign with white text

Description automatically generated

 

 

On the Laptop:

A screenshot of a cell phone

Description automatically generated

 

On the H8 and it booted fine the H17 floppy.

 

A screen shot of a computer

Description automatically generated

 

Thanks,

Norberto

glenn.f...@gmail.com

unread,
Sep 20, 2021, 2:24:07 PM9/20/21
to se...@googlegroups.com

So here’s what I see

 

  1. Turn on the H8 (Rev 4.0 CPU with Beta 24 firmware) and execute XH. LEDs show “H8d rEAdY”

https://photos.app.goo.gl/Uit8mffmtoF2se6S6

console says to start the H8D utility…

https://photos.app.goo.gl/oo77VWYbDHXtGJoJ6

 

  1. Run H8D Utility on my Windows 10 PC.  This is labelled “Version 2.2 CP/M extract/Add. IMD Read/Extract/Convert”

 

 

The serial port is COM3 via a USB-to-serial converter.  Connected via straight-through cable to port 340 on CPU board. This configuration has been verified to work using the traditional technique of booting the H89LDR software via floppy.

 

  1. Click on “Create” and then click “Client Status”.  Receive timeout message, however I believe this is to be expected as the only code on the H8 is the bootstrap, not the full client.  The “SAVE” button becomes active…

 

  1. Click on the “SAVE” button to download the full client to the H8. Claims to have sent H89LDR3.BIN successfully, however I get operation timeout messages:

 

 

 

In contrasting this to Norberto’s screen I note that I never receive the “Ready.” Message on the H8 console.  I also can’t tell what version of the H8D Utility he is running.

 

  1. If I now reset the H8, bring out my old H17 floppy disk containing the saved H89LDR bootable client and boot it, all is well and I get the “Client is ready” message:

 

image001.png
image002.png
image003.png
image004.png

norberto.collado koyado.com

unread,
Sep 20, 2021, 3:00:16 PM9/20/21
to se...@googlegroups.com
Glenn,

I will check it out tonight once I get home. Also is a good test to verify that my new serial cables are all wired properly.

We always struggled with this H89LDR Utility. It is time to put an end to this and document proper files to use and with proper procedure.



Thanks,
Norberto


Sent: Monday, September 20, 2021 11:24 AM
To: se...@googlegroups.com <se...@googlegroups.com>
Subject: RE: [sebhc] H8D Utility in ROM
 

Douglas Miller

unread,
Sep 20, 2021, 5:10:27 PM9/20/21
to se...@googlegroups.com

If you're not getting the "Ready." message on the H8 console, that would imply that the bootstrap did not complete/work. But if H8D Utility reports "H89LDR3.BIN sent successfully" then it seems that that end thinks it sent the loader code.

Seems as though the most likely causes of that are serial port mismatch (port 340Q is not what is connected to the PC) or BAUD is not set the same on both ends. Is the port you are using actually the one at H8 I/O address 340Q? I think it is possible for that UART to be set for a couple different addresses, and maybe the other software you are using isn't configured for port 340Q.

Is H8D Utility hard-coded to 9600 BAUD? I don't see anything in the screenshots to indicate the BAUD being used.

The H8 (XH command) bootstrap code is pretty simple, and has not been changed since Norberto tried it, so I'm not inclined to think there is something wrong there - although the load address/size could be off if the H8D Utility (H89LDR3.BIN) you are using has changed it's bootstrap requirements. If your version supports double-side/double-track then I suspect it is a different size and probably requires a different bootstrap program - which is incompatible with having this function in ROM.


On 9/20/21 1:24 PM, glenn.f...@gmail.com wrote:

So here’s what I see

 

  1. Turn on the H8 (Rev 4.0 CPU with Beta 24 firmware) and execute XH. LEDs show “H8d rEAdY”

https://photos.app.goo.gl/Uit8mffmtoF2se6S6

console says to start the H8D utility…

https://photos.app.goo.gl/oo77VWYbDHXtGJoJ6

 

  1. Run H8D Utility on my Windows 10 PC.  This is labelled “Version 2.2 CP/M extract/Add. IMD Read/Extract/Convert”

 


 

The serial port is COM3 via a USB-to-serial converter.  Connected via straight-through cable to port 340 on CPU board. This configuration has been verified to work using the traditional technique of booting the H89LDR software via floppy.

 

  1. Click on “Create” and then click “Client Status”.  Receive timeout message, however I believe this is to be expected as the only code on the H8 is the bootstrap, not the full client.  The “SAVE” button becomes active…


 

  1. Click on the “SAVE” button to download the full client to the H8. Claims to have sent H89LDR3.BIN successfully, however I get operation timeout messages:

 


 

 

In contrasting this to Norberto’s screen I note that I never receive the “Ready.” Message on the H8 console.  I also can’t tell what version of the H8D Utility he is running.

 

  1. If I now reset the H8, bring out my old H17 floppy disk containing the saved H89LDR bootable client and boot it, all is well and I get the “Client is ready” message:

 


 

From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of Douglas Miller

Les Bird

unread,
Sep 20, 2021, 5:56:41 PM9/20/21
to SEBHC
Just an FYI, when H8D Utility sends the LDR there is no handshake return from the Heathkit so there is no way for H8D Utility to know that the receiving end got the code. It just says "sent" indicating that it fed it to the serial port and the serial port send did not report any errors.

Les

Les Bird

unread,
Sep 20, 2021, 6:06:58 PM9/20/21
to SEBHC
Additionally, to answer Douglas' question - the H89LDR3.BIN does not have 2 side support. It is the standard H89LDR.BIN, however, I noticed the original was H89LDR2.BIN and the one H8D Utility sends is H89LDR3.BIN. Not sure of why I changed the file name for that. Probably best to do a compare between H89LDR2.BIN and H89LDR3.BIN to see if there are any differences. They are both 818 bytes and doing a quick glance in a hex dumper they seem identical.

And the default baud rate for H8DUtility is 9600 baud when sending/receiving disk images and the LDR.

Les

Douglas Miller

unread,
Sep 20, 2021, 6:51:14 PM9/20/21
to se...@googlegroups.com

Well, 818 bytes sounds an alarm... The ROM XH command bootstrap is expecting 825 bytes for the "LDR". It appears to be based on a different version of H89LDR*.BIN. That would certainly cause a hang and failure to complete the bootstrap.

The version that this was built around is located here: https://github.com/durgadas311/MmsCpm3/blob/master/rom/newmon/src/h8dutil/bin/h89ldr3.bin. Comparing the two, I see some fixes related to turning on/off the "counter" a.k.a. the user vector for INT1 - 2mS clock. Older code was trashing other H8 display "MFlag" bits.

glenn.f...@gmail.com

unread,
Sep 20, 2021, 8:08:52 PM9/20/21
to se...@googlegroups.com

Dwight Elvey’s original implementation was clever but fragile – the client program overlays the bootstrap program so the two are joined at the hip. 

 

Having stumbled into this rabbit hole I guess I can plunge a little deeper…

 

Attached is the listing I re-created some time ago for the bootstrap (this is the program to be keyed into the front panel if you have an H-8-4).  I believe I took the source from Dwight’s posting and edited it to assemble with the Heath assembler.

 

Out of curiosity I control-C’ed out of the XH ROM function and examined memory to see what exactly was there.  The code at 2300H (043.000 mostly agreed with Dwight’s listing except for two differences:  One is the DBEND parameter which is 7 more than what’s in the attached listing (as noted in the email discussion between Les and Douglas). The other is one I don’t understand.  In the original bootstrap is the code:

 

 

  043.037  333 345     00037   LDR1  IN   LSTAT

   043.041  037         00038        RAR

   043.042  322 037 043 00039        JNC  LDR1       Wait for char

 

But at the address 043.042 I instead found:

 

   043.042  315 212 020 00039        CALL 020.212

 

And the code at 020.212 appears to be the XH H8d bootstrap code from the ROM…

 

Anyway when I changed the code back to agree with what’s on Les’ web site as the front panel key-in program (https://sebhc.github.io/sebhc/software/Utilities/H8DUtility/BOOTSTRP.TXT) I was able to complete the download of the client and it gave me the “Client is ready” message and asked me if I wanted to save a copy to a bootable disk.

 

Les and Darrell are the experts on this and the owners of the code.  I provide this information in case it helps enlighten how to use the “XH” function and the appropriate client software to use with it.

 

  • Glenn
BOOTSTRP.LST

Douglas Miller

unread,
Sep 20, 2021, 8:16:01 PM9/20/21
to se...@googlegroups.com

I think the missing step for using the XH command is to replace H89LDR3.BIN with the one from the URL that I posted.

norberto.collado koyado.com

unread,
Sep 20, 2021, 8:26:53 PM9/20/21
to se...@googlegroups.com
I should be home within the hour. I will retest using setup in my laptop which I have not change since last testing. 

Norberto


Sent: Monday, September 20, 2021 5:15 PM

Les Bird

unread,
Sep 20, 2021, 8:37:20 PM9/20/21
to se...@googlegroups.com
Yes, I think we've figured out the problem. The H89LDR3.BIN that is part of H8D Utility is 818 bytes and is compatible with Dwight's bootstrapper code that you type in using the H8 keypad. Douglas has a slightly modified version that is 825 bytes and is compatible with XH. For H8D Utility to work properly with XH you'll need to replace H89LDR3.BIN that is included with H8D Utility with the one that Douglas linked and that should do the trick.

Les


glenn.f...@gmail.com

unread,
Sep 20, 2021, 8:51:55 PM9/20/21
to se...@googlegroups.com

Yes. This worked.  Tx all!  Somewhere there’s an action here to synchronize versions.  At some point, if useful, I can post an addendum to my instructions in REMarks 3..

 

REMarks Issue 3 - 1 January 2021 (sebhc.github.io)

norberto...@koyado.com

unread,
Sep 20, 2021, 11:57:00 PM9/20/21
to se...@googlegroups.com

Anyhow I tested it again and it is working fine.

 

image001.png

norberto...@koyado.com

unread,
Sep 21, 2021, 12:37:20 AM9/21/21
to se...@googlegroups.com

Here are my files:

image002.png
image003.png

norberto...@koyado.com

unread,
Sep 21, 2021, 2:20:40 AM9/21/21
to se...@googlegroups.com

But my heart is with the VH8UTIL.SYS utility as I do not need to use a laptop to create/backup an H17 bootable disk. Just the Z80 V4.0 CPU card, H19, H17 controller, and the VDIP1 USB flash device loaded with H8D files.

 

Perhaps we can have a JUKEBOX.SYS file to read “all” the HDOS *.H8D files from the VDIP1 and load up into the Z67-IDE+ jukebox region. The *.sys files creates a lots of new opportunities to make things easier to do. This is a great tool within the Z80 V4 board.

 

Norberto 😊

image001.png
image002.png

Glenn Roberts

unread,
Sep 21, 2021, 6:24:38 AM9/21/21
to se...@googlegroups.com
Terry’s improvements to the Z67-IDE+ firmware enable a number of enhancements to the Jukebox capability (notably a directory). I could create a JUKELOAD.SYS utility to pull H8D images off the VDIP and load them into the jukebox (I already have a similar utility that runs under HDOS). 

We will need a way to identify which image goes in which slot. My current load utility takes an index file as input, but a simpler approach (and probably better) would be to use a file naming convention, e.g. SLOT1.H8D, SLOT2.H8D, … etc.  I could presumably add ability to read H17DISK and IMD images too.

We also need to add CP/M capability as currently the jukebox is just an HDOS device driver.

This will be a project for fall/winter/spring along with a REMarks article explaining it all. 

Another project that should be done at the same time is to appoint a librarian to sort these out. To use the (book) library analogy: right now we’ve got a pile of about 600 books shoved on the shelf (Les’ archive). No particular method to their organization - just put on the shelves in batches as they were donated. No Dewey Decimal system, but we do have all of their tables of contents. I will provide the bookmobile to house them (jukebox) and a card catalog, but we must do some work to curate this collection. Which ones are first editions (copies of original source disks)? Which ones are duplicates? Where we have overlap, which is the best source? We should also update the descriptions.

This will be a significant effort, but when we are done we can essentially keep all of the Heath software ever created (that we’ve been able to find/save) on a single $5 flash drive, and images can be easily loaded either to media (floppy disks, gotek, etc) or en masse (to Z67-IDE+ and it’s descendants)! Once we add CP/M capability the mind boggles, as there is a *ton* of that already out there.

 Wow.

Sent from my iPad

On Sep 21, 2021, at 2:20 AM, norberto...@koyado.com wrote:



But my heart is with the VH8UTIL.SYS utility as I do not need to use a laptop to create/backup an H17 bootable disk. Just the Z80 V4.0 CPU card, H19, H17 controller, and the VDIP1 USB flash device loaded with H8D files.

 

Perhaps we can have a JUKEBOX.SYS file to read “all” the HDOS *.H8D files from the VDIP1 and load up into the Z67-IDE+ jukebox region. The *.sys files creates a lots of new opportunities to make things easier to do. This is a great tool within the Z80 V4 board.

 

Norberto 😊

 

From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of norberto...@koyado.com
Sent: Monday, September 20, 2021 9:37 PM
To: se...@googlegroups.com
Subject: RE: [sebhc] H8D Utility in ROM

 

Here are my files:

 

<image001.png>

 

 

 

From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of norberto...@koyado.com
Sent: Monday, September 20, 2021 8:57 PM
To: se...@googlegroups.com
Subject: RE: [sebhc] H8D Utility in ROM

 

Anyhow I tested it again and it is working fine.

 

<image002.png>

Les Bird

unread,
Sep 21, 2021, 8:20:56 AM9/21/21
to SEBHC
Glenn, I’m starting to document the imaging process on the Wiki too. Come to think of it I should link your REMarks on the Wiki as well.


Les

glenn.f...@gmail.com

unread,
Sep 21, 2021, 8:22:04 AM9/21/21
to se...@googlegroups.com

Douglas Miller

unread,
Sep 21, 2021, 9:50:35 AM9/21/21
to se...@googlegroups.com

I'd also request that "we" quickly adopt a standard/convention for using the JukeBox index. I saw the beginnings of that in a previous email, but let's have a representative group of people have a discussion and conclude on some format and usage for the index.

I'll work on adding jukebox support to CP/M 3, and we'll also want boot support - I presume (this would also benefit from the index).

Glenn Roberts

unread,
Sep 21, 2021, 11:04:11 AM9/21/21
to se...@googlegroups.com

Great!  agree 100%.  We’ll start with a white paper outlining the design and get a dialog going.  Hopefully in October.  Thanks!

Reply all
Reply to author
Forward
0 new messages