H8DUtility 3

233 views
Skip to first unread message

Les Bird

unread,
Oct 30, 2021, 10:57:07 AM10/30/21
to SEBHC
Hey all,

So I have H8DUtility 3 mostly in a working state. The disk imagers should be working. For hard sector you can use the same setup as before. For soft sector you'll need my H37IMGR on the Heathkit computer. I'm working on a "cold boot" process but for now you'll need to burn it on a hard sector disk and then boot and run it from there - let me know if you want this and I'll create an H8D image. As I mentioned before I have a ton of soft sector disks and even more hard sector disks to image so that'll be an ongoing process.

H8DUtility 3 features include:
- hard sector disk imager
- soft sector disk imager (38,400 baud xfer speed)
- view and extract files from disk images (CP/M, HDOS)
- view files in HEX output if file is not ASCII
- view disk images in HEX
- output disk catalog as HTML or TEXT file
- format a soft sector disk (ha! seems dangerous to have this feature in an archiving utility huh? but I mostly added this for debugging - probably will remove in a future build)

What is not working yet:
- converting to IMD
- injecting files into an image

Platforms supported: macOS, WinX64
Platforms available upon request: Linux, Win32

Go to the Wiki for download links: https://github.com/sebhc/sebhc/wiki

If you get a chance to try it would appreciate some feedback so I can refine it.

The whole idea of rewriting it is because the old utility is becoming very dated and is not able to run on other platforms such as Mac and Linux and at the same time I'm able to clean up the code (or make it worse).

For the soft sector imager it talks directly to the WD1797 chip and will copy just about any soft sector disk you can throw at it. The source code is here: https://github.com/lesbird/WD179xImager

H8DUtility 3 source code is here: https://github.com/lesbird/H8DUtility3
As before, H8DUtility 3 is written in C# but this time using the Unity platform which is very very portable (many platforms supported) and more future proof.

Les

Joseph Travis

unread,
Oct 30, 2021, 11:54:03 AM10/30/21
to se...@googlegroups.com
Les,

Does it work with the H8-5?  I tried using the current version with the H8-5 without success. However, it works fine with the H8-4. I was hoping to have the H8-5 as a dedicated interface for this application.

Thanks,
Joe Travis n6ypc


--
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/de3aba8d-bd28-4cf3-9ac3-87ecc805c346n%40googlegroups.com.

Les Bird

unread,
Oct 30, 2021, 12:23:08 PM10/30/21
to SEBHC
Joe,

The H8-4/H8-5 should not make a difference. You just need to make sure you're using the H8-5 version of Dwight's H89LDR program, which you probably were. What issues were you having with the old version of H8D Utility and H8-5? If it was dropping characters then you can try this version but not sure if it'll help much. From what I remember I think Dwight said the H8-5 is not very reliable at 9600 baud.

So am I to understand you have a H8-4 and H8-5 in your machine and you want the H8-5 to be dedicated to this task?

Les

Joseph Travis

unread,
Oct 30, 2021, 5:54:02 PM10/30/21
to se...@googlegroups.com
Hi Les,

Thanks for the reply.  Yes, I was using the H8-5 version of the H89LDR and the board was setup for 9600 baud.  The program would timeout when trying to connect with the H8 using the H8-5.  I keyed in the H89LDR several times and verified it each time in case I made a mistake.  Occasionally when trying to connect, the H8 looked like it was going off into lala land.  I performed the H8-5 tests from the assembly manual and it checked out fine.

Since the setup works when using the H8-4, I'm fine with that.  The reason I wanted to have it dedicated to the H8-5 was so I wouldn't have to disconnect / reconnect peripheral(s) whenever I want to use it.

Regards,
Joe Travis n6ypc



Glenn Roberts

unread,
Nov 2, 2021, 11:10:52 AM11/2/21
to se...@googlegroups.com

I have been unable to get this to work, but more disturbingly I can no longer get the previous version to work.  This was all working fine at VCF East.  I’ve even tried different H8 setups and two different PC configurations.  This may have something to do with the H89LDR file differences (recall our discussion of getting this to work with the new “XH” feature in the Rev. 4 board ROM)…. 

 

Attempting to retrace my steps until I get a solid baseline that works…

 

I swear every time I try to do *anything* that involves floppy disks it ends up taking hours or days!...  but I’m determined to get this working again, then I’ll try the new version!...

--

Les Bird

unread,
Nov 2, 2021, 9:07:32 PM11/2/21
to SEBHC
If you can’t get “client ready” then it’s a serial port issue but you probably already know that.

Make sure you’re choosing the correct USB serial device.
Make sure the correct baud rate is selected (9600)
Make sure the connection to the H8 is correct (340Q) unless you have a different configuration 
Make sure the correct H89LDR is running

Les

glenn.f...@gmail.com

unread,
Nov 2, 2021, 10:27:46 PM11/2/21
to se...@googlegroups.com

First of all. Everything works great on my original 8080 system. It has the original h-8-4 board for serial I/O.  I am so far only testing the H17 portion.  Once I get  that working I’ll move on to the ’37.

 

I can’t get it to work on Rusty or Big Blue.  Rusty has 2.6 Z80 CPU and “Les Bird” H-8-4 w/ 16550 UARTs.  Big Blue has Z80 rev4 cpu with the 16C550 daughterboard.  Both have the new H37/H17 “piggback” boards.  The H17 disk works fine on both systems and passes TEST17 with flying colors.

 

Using the 8080 setup I keyed in the manual bootstrap program and was then able to save a bootable client.  Also writing disks went fine.

 

When I boot from the saved client disk on Rusty and run H8DUtility3 on the PC I get “CLIENT IS READY”.  So far so good…

 

When I try to send an image I get the messages:

DRIVE SY0 SELECTED ON CLIENT

DISK VOLUME SET TO 0

 

But nothing happens.

 

Using the front panel on the H8 I see that the code is simply sitting in a loop waiting for Data Ready:

 

043.362  333 345         IN   345           ; Line status register

043.364  037                 RAR                 ; rotate through carry

043.365  322 362 043  JNC  043.362 ; loop…

 

It never gets data.

 

Also I am not able to do the “SEND LDR” thing, presumably for a similar reason.  I had to save the loader using my old 8080 configuration.

 

I would wonder if there’s something about the 16550 UART that causes this discrepancy, except I did have a working version of this on Big Blue at VCF east… something I now cannot seem to reproduce

 

For now I’m stumped…

 

  • Glenn

Joseph Travis

unread,
Nov 2, 2021, 11:33:26 PM11/2/21
to se...@googlegroups.com
Glenn,

The 16450 / 16550 UARTs are not fully hardware compatible with the 8250.  On the 8250 pin 24 is CSOUT which goes to the buffer control logic on the H8-4 serial board.  In the case of the 16450 / 16550 pin 24 is /TXRDY and is used for DMA signaling in FIFO mode.  If your CPU clock is greater than 2 MHz, you need to use a 8250A or 8250B.

If you have an older H8-4 serial board like I do, it uses a CMOS chip for the BAUD clock.  It supplies 2 clock outputs, each feeding 2 UARTs.  A couple weeks ago I experienced a failure with that chip where it supplied only one output thereby making 2 channels dead.  I updated mine to eliminate that IC and match the later version of the board.  Works great!

Good luck!
Joe Travis n6ypc


Glenn Roberts

unread,
Nov 3, 2021, 5:57:58 AM11/3/21
to se...@googlegroups.com
Thx joe. We had some discussion on this a while back. If this is in fact a problem due to the 16550 it’ll be the first one I’ve seen on Rusty, which has been using this board for 10 years. One easy test would be to swap the chip, which I may do. The CPU clock is 2mhz…

Will continue to investigate…

Sent from my iPad

On Nov 2, 2021, at 11:33 PM, Joseph Travis <jtravi...@gmail.com> wrote:



Les Bird

unread,
Nov 3, 2021, 8:29:18 AM11/3/21
to SEBHC
Ah, Glenn, this may be an issue with H8DUtility 3 but did you say the old H8DUtility wasn't working either? I had issues during testing where H8DUtility 3 would send commands too quickly before the H8 was ready to receive them and the H8 would get stuck in a loop waiting for the command. I had to introduce delays in the H8DUtility to fix this. Might be a similar issue here.

On the H8 are you using H89LDR or H8DIMGR2?

Also, what are the steps you took? Sounds like you are trying to write a CPM disk? So you clicked on CLIENT STATUS and then SEND IMAGE? I just need to know where it might be missing a command. On my 2Mhz V2.1a Z80 board it was working very reliably but I'll do more testing to see if I can reproduce the problem.

Les

Joseph Travis

unread,
Nov 3, 2021, 8:32:23 AM11/3/21
to se...@googlegroups.com
What I forgot to say in my previous response was that the problem may possibly stem from how H89LDR initializes the UART vs. how it's done in HDOS or CP/M.

It's been over 30 years since I wrote any software for these chips and I may be grasping at straws based upon what little I remember.  Good luck once again.  I look forward to hearing how it goes.

Regards,
Joe Travis n6ypc


glenn.f...@gmail.com

unread,
Nov 3, 2021, 9:56:04 AM11/3/21
to se...@googlegroups.com

I’ll attempt to be more thorough in my notes. Here’s where I’m at:

 

Two systems: Rusty and let’s call it “Trusty” (or maybe “Dusty”? – he’s been in the closet for a while!).  Trusty is my very original H8 that  I built in 1981.  8080 CPU, 3x 16K SRAM; H17 controller board; H-8-4 with 8250 UARTs; single 100K Siemens disk drive.  Trusty still works great! 

 

Rusty contains the Z80 Rev 2.6 board; “piggyback” H17/37/67 I/O board combo built last spring; “Les Bird” H-8-4 clone board with 16550 UARTs.  It also has CPU speed control board and real time clock board.  All tests are at 2Mhz CPU speed.

 

I tried the following on Trusty (spoiler alert: everything below works fine):

 

  • Key in the original mini client software via the front panel
  • Set PC to 043.000 and hit “go”
  • Run H8DUtility3 on the PC
  • Select DISK IMAGER option
  • Select CLIENT STATUS.  No response (expected)
  • Select SEND LDR.  Disk activity on H17.  Message asks if I want to SAVE or CANCEL. Hit SAVE
  • Disk activity as loader is save to H17
  • Select CLIENT STATUS again. Receive “CLIENT IS READY”
  • Quit H8DUtility3
  • Boot Trusty from just created disk
  • Run H8DUtility3 again.
  • Select DISK IMAGER and then CLIENT STATUS. Receive “CLIENT IS READY”
  • Select SEND IMAGE
  • Select an H8D image that has Les’ H8DIMGR2 on it…
  • Hit “DONE”.  Disk image writing process begins on H8 (NOTE to Les: should you warn the user?  Older version issued a warning to allow user to swap out disk).
  • Imaging process proceeds as expected and completes after writing tracks 0..39
  • Quit H8DUtilit3
  • Boot Trusty from just-created disk
  • Run H8DIMGR2
  • On the PC run H8DUtility3 again
  • Select DISK IMAGER; CLIENT STATUS; response is “CLIENT IS READY”
  • Am able to send disk image just as before
  • Everything works fine!

 

Now for Rusty:

 

  • Key in the original mini client software via the front panel
  • Set PC to 043.000 and hit “go”
  • Run H8DUtility3 on the PC
  • Select DISK IMAGER option
  • Select CLIENT STATUS.  No response (expected)
  • Select SEND LDR.  Disk activity on H17.  Message asks if I want to SAVE or CANCEL. Hit SAVE
  • Disk activity as loader is save to H17
  • Disk LED stays solid; drove motor stays on; PC display shows execution at around 034.001 and looping (somewhere in H17 ROM code) H8D Utility says “LOADER SAVED TO DISK” but clearly something did not complete properly on the H8 side…
  • Select CLIENT STATUS again. No Response.
  • Abort; quit H8DUtility 3 and reset H8…

 

  • Boot Rusty from Z67IDE+ (HDOS) (can’t boot from floppy because the image was damaged by previous step).  Run H8DIMGR2. LED display goes blank (expected); console says “CLIENT READY” (question: is it OK to run this when SY0: is actually the Z67IDE+ or do I have to boot from the floppy?  Previously I tried booting from the floppy and had the same results as shown below)

 

  • Run H8DUtility 3; select DISK IMAGER; CLIENT STATUS; response is “CLIENT IS READY”

 

  • Select SEND IMAGE and select the same disk image as before (the one with H8DIMGR2 on it).

 

  • Select “DONE” and see message on the H8 console: “USING DRIVE SY0” and “SETTING DISK TYPE 0 – 1S40T”

 

  • On the H8Utilty3 message window I see “DRIVE SY0 SELECTED ON CLIENT” “DISK TYPE 0 SET ON CLIENT” “DISK VOLUME SET TO 0”  - so far so good…

 

  • Then nothing happens no activity on either end.  Cant’ tell what’s happening on Rusty because the program has turned off the LEDs.

 

  • Trying another approach: booted Rusty using the client software disk previously created with the “SAVE” operation on Trusty

 

  • Run H8DUtility3. Client status says “CLIENT IS READY”

 

  • Attempt to send disk image. Get message “DRIVE SY0 SELECTED ON CLIENT” AND “DISK VOLUM SET TO 0”..  then no activity

 

  • Pc display on H8 indicates looping activity at 043.362 (waiting for serial data as described in my previous email.)

 

 

  • Glenn

 

  •  
  • Boot Rfrom just created disk
  • Run H8DUtility3 again.
  • Select DISK IMAGER and then CLIENT STATUS. Receive “CLIENT IS READY”
  • Select SEND IMAGE
  • Select an H8D image that has Les’ H8DIMGR2 on it…
  • Hit “DONE”.  Disk image writing process begins on H8 (NOTE to Les: should you warn the user?  Older version issued a warning to allow user to swap out disk).
  • Imaging process proceeds as expected and completes after writing tracks 0..39
  • Quit H8DUtilit3
  • Boot Trusty from just-created disk
  • Run H8DIMGR2
  • On the PC run H8DUtility3 again
  • Select DISK IMAGER; CLIENT STATUS; response is “CLIENT IS READY”
  • Am able to send disk image just as before
  • Everything works fine!

Les Bird

unread,
Nov 3, 2021, 12:02:45 PM11/3/21
to SEBHC
Excellent notes Glenn.

Seems to me like there are some dropped characters on the serial port for Rusty. Are you using the same cable for both machines from the H8-4 to the PC? I don't have the 2.6 board with piggyback so can't test with that setup. I'm guessing you're also running a different firmware to support the piggyback board features so I wonder if that is causing lost characters on the serial port? For example, it might be doing more processing and eating up more CPU than the standard PAM37 firmware.

Maybe you can configure one of the other 4 ports as 340Q and see if that works any better.

Les

Douglas Miller

unread,
Nov 3, 2021, 12:35:36 PM11/3/21
to se...@googlegroups.com

That's a good point... If the ROM "2mS" interrupt handler is taking too much time, could that cause overrun? Seems like this program must disable normal front-panel updates, and otherwise minimize the interrupt handler work. H17 code requires that the 2mS tick be counting, but there might also be a "user handler".

Glenn Roberts

unread,
Nov 3, 2021, 12:43:37 PM11/3/21
to se...@googlegroups.com
The rom is pam37. The rev. 2.x CPU boards are relatively minor updates to the “Les Bird” z80 board (which as I understand it is essentially the Heath design). 

I will continue to experiment…

Sent from my iPad

On Nov 3, 2021, at 12:35 PM, Douglas Miller <durga...@gmail.com> wrote:



Glenn Roberts

unread,
Nov 3, 2021, 4:53:01 PM11/3/21
to se...@googlegroups.com

It was déjà vu (all over again 😊 ). 

 

8 years ago I was struggling with a problem when using the H8D utility on my (then) Z80 machine (this was with the HA8-6 standard Heath Z80 CPU at 2Mhz).  Looking at the code I saw that the I/O was not interrupt-driven, it simply did task-time reading from the serial port and storing into RAM.  Should an interrupt take any significant time during that transfer characters would be dropped.  The conversation is here:

https://groups.google.com/g/sebhc/c/EDdw031FNMI/m/3DHce3SpQXwJ

 

scroll down to my conversation at the bottom dated “Aug 10, 2013, 7:05:43 AM” which gives a complete description.

 

I noted that the BC register was used to keep track of the incoming characters and used the front panel to monitor BC.  If all works correctly it decrements all the way down to zero and then writes out the data to disk.  What I observed was that it decremented down to a small number and just stopped.  Bytes had been lost due to interrupt service issues!.

 

My solution at the time was to rewrite the software to disable the front panel update.  that was enough to get things to work.  I saved that client on a bootable disk and have always used that disk.  I believe this is what I used at VCF East and it worked fine.

 

So the question was: could this be what’s happening now?

 

So I set up a system with all “standard” Heath gear (except for the RAM where I used norberto’s more modern 64K card).  I used a standard H17 and H8-4 serial card and standard 8080 CPU (XCON8 ROM).  I set the front panel to monitor the BC register and started the client program.  I ran H8DUtility3 on the PC and sure enough everything worked fine.  As expected the BC counter would count down to zero and then a disk write would happen (one track) and then the cycle would repeat.

 

Then I changed out the 8080 CPU for the Z80 (again, standard Heath HA8-6 CPU with PAM37 ROM).  Again, I set the front panel to monitor the BC register and booted the client software from disk and ran H8DUtility3 on the PC.  It showed “client ready” but when I initiated a transfer the BC counter counted down but stopped at 011Q.  somewhere during the transfer 9 bytes had been dropped!  The program will wait forever for those 9 bytes….

 

So you might ask, why not use that version of the client I used at VCF East?  - the disk will no longer boot.  I should be able to recreate it but will have to dig through 8 years of cobwebs in my brain to remember how 😊

 

So Douglas was on the right track.  Characters are being dropped due to interrupt processing and the very simple mechanism being used to transfer data.  Apparently on any Z80-based CPU (at least those with the PAM37 ROM) the interrupt service routines can sometimes take long enough to cause a character to be missed.

 

Les: what configuration are you using to test this?  perhaps I can reproduce?  Or are you using an emulator?

Les Bird

unread,
Nov 3, 2021, 4:55:48 PM11/3/21
to SEBHC
Glenn,

My Z80 design is not the Heath design at all. It's a mishmash of bits of Z80 and bits of 8080. I took the address buffering and decoding (right side of board) from the 8080 schematic and parts of the rest from the Z80 schematic and then blended in the HA8-8 and GIDE stuff. At the time I didn't have a good copy of the Z80 board schematic so couldn't follow most of the lines to their endpoints. I also think the Heath Z80 schematic I had wasn't accurate, I think someone on here way back acknowledged that there were errors in the Z80 schematic. So the 2.x design is mostly me guessing at how to wire it up. That's also why Norberto had to make so many patches to it to make it more reliable, especially with the H37 board and the reset circuitry. I tried to take the reset circuitry from the Z80 design but I didn't have a good enough understanding of how it was supposed to work.

It seems like Norberto fixed all these issues with his 3.x design.

Les

Glenn Roberts

unread,
Nov 3, 2021, 4:57:27 PM11/3/21
to se...@googlegroups.com

Interesting… tx.

 

But see the note I just sent for more info 😊

Les Bird

unread,
Nov 3, 2021, 5:07:44 PM11/3/21
to SEBHC
Glenn, that totally makes sense that interrupts would cause dropped characters.

I'm using the standard H8DIMGR2 and H8DUtility 3 on a 2.1a Z80 CPU board with XCON-8 on the bottom and 444-140 on the top. I have a Heath H17 disk controller, Les Bird H8-4, HA8-3 Color Graphics, Heath H37 and Les Bird 2.1a CPU.

Also, for H37IMGR to run at 38,400 baud I had to DI when receiving characters at that speed and EI when the buffer was full because of this exact problem, dropped characters. At 9,600 baud with the standard setup and H8DIMGR2 it seems pretty reliable. I'll double check later tonight by sending/receiving disk images.

Les

Les Bird

unread,
Nov 3, 2021, 6:44:31 PM11/3/21
to SEBHC
Glenn,

Using H8DIMGR2 on the H8 and a MacBook with USB serial port adapter to the H8-4 I was able to consistently (3 times both ways) send/receive disk images with no dropped characters at 9600 baud using H8DUtility 3.

Les

Glenn Roberts

unread,
Nov 3, 2021, 7:53:47 PM11/3/21
to se...@googlegroups.com

Well I guess I’m back to stumped.  We have very similar configurations – my Rev 2.6 CPU board should be functionally equivalent to yours.  I note that with jumpers It’s possible to run your board at 1 Mhz (if you have the ECS-300CX chip) – you sure you’re running it at 2Mhz and not 1?  At 1Mhz I believe everything would work.

 

So far I’m unable to reproduce your results.

 

I will note that in some sense it’s “cheating” to run H8DIMGR2 because part of the purpose of this configuration is to bootstrap a system from nothing. That means entering the small program from the front panel and downloading either the H8DIMGR disk or the extended client boot disk.  Are you able to do that?  that “bootstrap” program is where I’ve definitely seen dropped characters with the Z80 processors (at 2Mhz).

 

I actually have the ECS-300CX chip on my board so theoretically could run the CPU at 1Mhz – except I can’t figure out how to set the jumpers (and the documentation isn’t very clear). Can you explain the “A+A”, “A+B” etc notations on the board?  how would I set the jumpers on the CPU board for 1Mhz? … or for 2, 4 , or 8?

Les Bird

unread,
Nov 3, 2021, 8:23:43 PM11/3/21
to SEBHC
Yes I am definitely running at 2Mhz.

So the jumpers work as follows:
The top jumper horizontally in the A position (left 2 pins jumped) would be no-divider so the board would run at 16Mhz
The top jumper horizontally in the B position (right 2 pins jumped) would be using the divider and the next 2 jumpers define the speed.
The middle jumper horizontally in the A position (left 2 pins) and the bottom jumper in the B position would be 2Mhz.
If they are both in the B position (right 2 pins jumped) then it is set to 1Mhz.

Seems like the only major differences between our set ups is the PC/MacBook and possibly the type of USB serial port cable. If this was working before then that shouldn't be an issue which leaves potentially a hardware failure on the H8-4 board. Try setting one of the other 4 ports as 340Q and see if you have better luck there.

I originally tested H8DUtility 3 by keying in the bootstrapped and sending the LDR but with this last test I just booted up H8DIMGR2 directly. And yes, it is cheating which is why H8DIMGR2 is on a bootable disk image that you can upload after keying H89LDR. Then you reset your computer with the new bootable H8DIMGR2 disk and run H8DIMGR2 from that point forward.

Les

Glenn Roberts

unread,
Nov 3, 2021, 8:28:11 PM11/3/21
to se...@googlegroups.com

Thanks les.

 

So I’m still stumped. I’ll step back but perhaps others can try it out.  I may try the H37 capability, which is really the nice new add.

 

If it’s just me then that’s my problem but I’m concerned that others will run into problems like I did…

 

If I get an epiphany perhaps I’ll revisit the H17 part.

Les Bird

unread,
Nov 4, 2021, 5:43:38 PM11/4/21
to SEBHC
Glenn,

Found a bug in H8DUtility 3 where when writing a HDOS disk image it was not properly setting the volume so the disks were unusable. Go grab the latest from the Wiki when you get a chance.

I also added a screen when writing disk images to notify the user to insert a disk in the drive (thanks for the feedback on this).

Les

glenn.f...@gmail.com

unread,
Nov 4, 2021, 8:20:32 PM11/4/21
to se...@googlegroups.com

So I am not able to reproduce this result.  When I run H8DIMGR2 I get “CLIENT READY” and also on the H8Utility3 side I get “CLIENT IS READY” but the transfer does not complete.  it starts since I see the messages “USING DRIVE SY0” and “SETTING DISK TYPE 0 – 1S40T” on the H8 console, but there is never any disk activity.  I am using a Windows 10 PC with a USB serial port adapter.  System spec’s:

 

 

Using RTM/0 on the H8 keypad I interrupted the (hung) code to see that the BC register (counts down incoming bytes) is set to 000 010 (should be 0) indicating 8 dropped bytes during transmission… the code will wait forever for those remaining 8 bytes ! 😊  I also repeated this but this time hit RTM/0 and then GO just after H8DIMGR2 starts. This has the effect of re-enabling the front panel display so I can monitor the BC pair in real time.  With FP refresh running more characters were lost (as expected due to the interrupt load of servicing the panel refresh):  the final value on BC when it hung was 000 013…

 

All I can think of to suggest is try running the H8DUtility3 software on a Windows box to see if you get the same results. 

 

Incidentally I was able to restore my old boot disk with the client software.  This allows me to once again use H8DUtility rev 2.2.  this version does not work with H8DUtility3.  But at least I can create disk images again!  This is the version I demo’ed at VCF.

 

To restore it I had to drag out a 10+ year old Dell laptop running MS DOS.  That’s where I made the changes which included mod’s to Dwight’s original (FORTH) code to get the download to work (one time use)!  Fortunately I documented all this back in ’13!

image001.png

Les Bird

unread,
Nov 4, 2021, 8:30:12 PM11/4/21
to SEBHC
I'll try running on a Windows box to try and reproduce the results.

Les

Les Bird

unread,
Nov 4, 2021, 8:59:30 PM11/4/21
to SEBHC
Glenn,

Just did a test over here. H8DUtility 3 running on a Windows 10 laptop (i7 Intel) connected to my H8 via USB serial port cable. H8 is running H8DIMGR2.

1. Sent a H8D disk image (1S40T). No problems.
2. Read it back. No problems.
3. Sent it again. No problems.
4. Booted the disk to verify. No problems.

Again, H8 with V2.1a CPU board and Les Bird H8-4. No changes to previously described configuration.

I double checked the chips on my H8-4 and I am using 16C550s.

Les

Glenn Roberts

unread,
Nov 4, 2021, 9:35:15 PM11/4/21
to se...@googlegroups.com
Ok thanks for taking the time. It would have been surprising if this didn’t work but for completeness was worth checking…

Sent from my iPad

On Nov 4, 2021, at 8:59 PM, Les Bird <lesb...@gmail.com> wrote:

Glenn,

Glenn Roberts

unread,
Nov 5, 2021, 6:06:43 AM11/5/21
to se...@googlegroups.com
I will try to get as close to your configuration as I can, but have to take a break this weekend. Will continue this next week…

Sent from my iPad

On Nov 4, 2021, at 8:59 PM, Les Bird <lesb...@gmail.com> wrote:

Glenn,

Glenn Roberts

unread,
Nov 5, 2021, 12:21:00 PM11/5/21
to <sebhc@googlegroups.com>
Les: how does the code locate H89LDR3.BIN? Wondering if the wrong version is somehow getting sent on my setup? As you know its critical for it to be the right version. I'm not at my computer at the moment. Also where is the source for H89LDR3? 

Thx.

Les Bird

unread,
Nov 5, 2021, 12:35:18 PM11/5/21
to SEBHC
Glenn, H89LDR3 is in the data folder.

H8DUtility3\H8DUtility3_Data\StreamingAssets\H89LDR3.BIN

Source? Not sure. Let me see if I can track it down.

Les

Les Bird

unread,
Nov 5, 2021, 12:38:22 PM11/5/21
to SEBHC
H89LDR ASM source code attached. The BIN file for some reason I renamed to H89LDR3 even though it was assembled from H89LDR2.ASM

Les
H89LDR2.ASM

glenn.f...@gmail.com

unread,
Nov 11, 2021, 3:37:34 PM11/11/21
to se...@googlegroups.com

So here’s what I’ve found so far.  For the purposes of this explanation I will refer to the 42-byte bootstrap program (that you enter from the front panel as the “mini server” and then when the additional code is downloaded and appended (H89LDR3.BIN) as the “full server” (Note while it’s tempting to call these programs clients the client is actually on the PC end – the server running on the H8 provides the response to the various 1-byte commands from the PC client, e.g.: W, R, S, V, C, I and T).

 

Configuration (Rusty):

                Z80 (Rev. 2.6) – XCON8/PAM37+ running at 2Mhz

                “Les Bird” H-8-4 w/ National Semiconductor NS16550AN UARTs

                “piggy back” I/O boards (17/37/67)

 

Procedure:

  1. Issue “fake boot” to load disk vectors
  2. Key in the mini server boostrap code https://sebhc.github.io/sebhc/software/Utilities/H8DUtility/BOOTSTRP.TXT
  3. Via front panel set PC=043.000 and set front panel to monitor DE register
  4. Hit key 4 (GO) to execute mini server
  5. DE register shows 046.132 as expected. DE will be decremented as the data for the full server are received (line from mini server source):

   043.034  021 132 046 00036   LXI  D,DBEND-1  Depends on size (to be determined)

  1. Run H8DUtility3 client on PC
  2. Select “Disk Image” select “Send LDR” to send the H89LDR3.BIN, which will be appended to the mini-server to create the full server.
  3. Read warning message and click “DONE”. Data is transferred (DE register decreases) and receive messages SENDING H89LDR3.BIN and H89LDR.BIN SENT SUCCESSFULLY on the client console. Receive popup to CANCEL or SAVE.
  4. Note that the DE register did *not* fully complete decrementing. Given the design of these two pieces of code the DE register must completely decrement down to 043.050 so that the PCHL instruction is overwritten (the PCHL acts as an effective JMP LDR1 since the HL register contains the address of LDR1.  The H89LDR3.BIN must overwrite the PCHL instruction in order to transfer control to the full server):

  043.037  333 345     00037   LDR1  IN   LSTAT

   043.041  037         00038   RAR

   043.042  322 037 043 00039   JNC  LDR1       Wait for char

   043.045  333 340     00040   IN   RX

   043.047  022         00041   STAX D

   043.050  033         00042   DCX  D

   043.051  351         00043   PCHL

  1. The DE register shows 043.052 indicating that two bytes have been lost in the transfer process. Both client and server are effectively stuck at this point.
  2. Using RTM/0 key combination on the H8 front panel I examine the contents of memory, comparing to the listing (attached) and find the two locations where bytes were dropped.
  3. Repeat all of above and this time DE shows 043.054 (4 bytes dropped). I examine the contents of memory and again find all of the locations where bytes were dropped (different each time).
  4. One possibility is that an interrupt service routine is taking a lot of time (would have to be about 1ms to cause a byte to be skipped) ??  but I don’t understand why Les doesn’t see this on his machine.  I have repeated this problem on multiple Z80 configurations.  In one of my sessions I replaced the 16550 with an 8250 and the results did not change.

 

As I’ve said in a previous email, back in 2013 I encountered this “dropped character” problem on my Heath Z80 box with Heath H-8-4 board.  My solution at that time was to modify both the mini server and full server code to blank the LED refresh during data transfer.  Using that code, and HDUtility 2.2 I can still transfer files successfully on this configuration.

 

Idea: boot the modified server code and see if it works with HUtility3:

  1. Boot server image containing modified server (that blanks LEDs during transfer).
  2. Run H8DUtility3 client on PC
  3. Select DISK IMAGER
  4. Select CLIENT STATUS. Receive “CLIENT IS READY”
  5. Select image to transfer (H8DIMGR2.H8D)
  6. get popup to BEGIN or CANCEL
  7. insert blank disk in H17 and select BEGIN
  8. it works!  LED display is blanked during transfer. Disk cycles on and off. Disk writing completes normally.

 

ok so having come this far, let’s boot the H8DIMGR disk, run it and see if it works!:

  1. boot from just-created floppy
  2. run H8DIMGR2.ABS
  3. see “CLIENT IS READY” (IMO should say server is ready 😊 )
  4. FP LEDs are blanked
  5. Run H8DUtility3 on PC, select Disk Imager, client status… get “client is ready” response.
  6. Select “send image”
  7. Again select H8DIMGR2.H8D
  8. Get popup CANCEL or BEGIN on PC client
  9. Insert fresh disk in H17
  10. Select BEGIN
  11. See message on H8: USING DRIVE SY0    SETTING DISK TYPE 0 – 1S40T
  12. Then nothing…!
  13. Using RTM/0 on H8 examine BC register. Contents are 013Q
  14. Repeating above several times get same results except BC contents vary. Usually 011Q, 012Q or 013Q, which suggests 9 to 11 bytes are being dropped during the transmission of a track image.

 

Summary: I can use H8Dutility3 to create disk copies but only with my modified server which blanks the LEDs.  Unable to get it to work with H8DIMGR2 from Les’ site…

 

 

I haven’t tried it recently because it’s a pain to set up but I believe all of this worked fine on Trusty (my original 8080 system).  I did this last week and that’s my recollection of how things went.

 

Happy to re-post information about the mod’s I made to the server code back in 2013 if useful.

 

Can’t understand why this works for Les.  Would love for someone else with a Z80-based setup to try so we could determine if there’s something about my system that’s “one off” (though I can’t imagine what that would be…)

H89LDR2.LST

dwight

unread,
Nov 11, 2021, 8:15:31 PM11/11/21
to se...@googlegroups.com
I think it is 50 plus a few and not 43 bytes for the boot strap.
The boot strap doesn't have enough smarts to know if there was an extra byte in the read buffer when it starts. Because of this, it realigns the code so that it is in the right location when it first overwrites the PCHL with a nop. 
The fact that it looks to be missing some count of the transfer would indicate to me that it is not servicing the UART fast enough. For this I'd recommend using a lower baud rate. Also make sure that the status wires on the PC side are wired to always enable data to send. The bootstrap does not use an handshake, it just looks to see if the buffer is full.
It has been a long time since I wrote the bootstrap code so I don't recall which bytes to change the baudrate.  I suspect Les should know.
If it doesn't work with a lower baudrate, it is possible that a handshake wire is floating in the serial wire at one end or the other. Since the H8 doesn't use any handshake and the PC doesn't either, these wires must be tied in at the connectors. The connection should be a 3 wire serial only.
Dwight



From: se...@googlegroups.com <se...@googlegroups.com> on behalf of glenn.f...@gmail.com <glenn.f...@gmail.com>
Sent: Thursday, November 11, 2021 12:37 PM
To: se...@googlegroups.com <se...@googlegroups.com>
Subject: RE: [sebhc] H8DUtility 3
 

Les Bird

unread,
Nov 11, 2021, 8:17:31 PM11/11/21
to SEBHC
Excellent feedback Glenn.

I will try from a blank slate and see how far I get.

One thought: a couple of differences in our setups are...
1. The "client :)" PC being used although I tried on both an i7 Dell laptop and MacBook.
2. The USB to serial port cable probably differs between our setups. My brand is this one: https://www.amazon.com/gp/product/B00IDSM6BW/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&th=1

There's a difference in how I'm sending the data out to the H8 in H8DUtility 3. Previously (in V2) I put delays and sent one byte at a time. With the new set up I send the whole buffer to the USB serial port adapter and I let it feed the bytes to the H8. Possible that the USB serial adapter you're using isn't handling this as well.

3. The cards (CPU, FP, etc) in the H8 and the firmware being used. This could certainly affect the interrupts on the Heathkit side of things.
4. Cable used to connect to H8-4 from USB serial port adapter. Nothing special about my setup. It's just a straight through DB9 to DB25 cable.

Also, a few days ago I successfully did a blank slate mini-server/full-server boot on an H89 using H8DUtility 3 so I've had success on both H8 and H89 setups. Still, I'll do a blank slate on the H8 to verify and report my results.

Another thought, I could easily modify H8DIMGR2 to DI when receiving bytes and EI when done. I do this with H37IMGR because it operates at 38,400 baud and is absolutely necessary to prevent dropped bytes.

Les

Glenn Roberts

unread,
Nov 11, 2021, 8:36:38 PM11/11/21
to se...@googlegroups.com

Ok thanks.  well just to bring it full circle, you asked us all to test and that was my goal and I’m basically reporting results for you to decide on. But even if the things you mention are the culprit(s) I presume you’d want a robust enough solution to handle little variations like that in your user base.   If it would help you with testing I can try from a macbook (it’s a pretty old one, 2013 vintage I think). 

 

I’m using a Sabrent USB-9290. It’s definitely a few years old (Windows 7/Windows Vista compliant!).  I should probably buy a new one anyway; if I do I’ll report the results.

 

I guess we really need more than one data point (me) to know if these are more generalized problems 😊

 

Attached are the mod’s I made 8 years ago, if they’re of use.  Both to the mini server and the full server… (search for GFR in comments). Happy to proved .ASM if useful.

H8LDR.LST
h8boot.lst

Les Bird

unread,
Nov 12, 2021, 5:56:46 PM11/12/21
to SEBHC
Glenn,

Blank slate test performed here using the H8 and everything went smoothly.

1. punched in the code
2. sent H89LDR from H8DUtility 3
3. loader saved to disk
4. booted from loader
5. sent H8DIMGR2 disk image
6. booted from disk image
7. transferred disk image to PC
8. transferred disk image back to H8

And yes we could use more data points. Hopefully someone else out there can try it and report back results.

As previously mentioned I was successful on both H8 and H89 setups.

Les

glenn.f...@gmail.com

unread,
Nov 13, 2021, 6:43:33 AM11/13/21
to se...@googlegroups.com

Thanks Les. The one thing in common with all of my attempts has been the older Sabrent USB-to-Serial converter.  I have ordered the newer one (same one you’re using) to see if that helps.  I don’t have any Win64 or Mac boxes that have built in serial so I’ll have to use the converter.  Will let you know if that resolves the problem…

 

I may be out of pocket for a few days (have to go help my son with something in upstate NY) so probably won’t check back in on this ‘til later sometime next week.

 

To try the H37 portion where can I find some disk images to test?

Les Bird

unread,
Nov 13, 2021, 4:42:56 PM11/13/21
to SEBHC
Glenn,

I'm putting some H37 images up on the Wiki. Grab them when you're ready to test things out. I also made some H37 bootable disks for CP/M and HDOS.


Les

Les Bird

unread,
Nov 13, 2021, 5:10:31 PM11/13/21
to SEBHC
Glenn,

So interesting situation I just encountered.

I'm now getting the dropped bytes when sending disk images to the H8 using H8DIMGR2.

What has changed?
My initial set up with the 2.1a Les Bird Z80 board was without Norby's mods to enable the PAM37 ROM. Without his mod I was unable to boot an H37 drive but I could read/write to it if I had the H37 drivers on an H17 disk. So today I wanted to boot from my H37 drive to test some of the bootable disks so I went ahead and applied his mods to my CPU board. See conversation here: https://groups.google.com/g/sebhc/c/GcmY1msoaEE

Then I enabled the 444-140 PAM37 ROM as ROM #1 (previously was ROM #2) and set the XCON8 as ROM #2 (previously ROM #1) using the CPU board jumpers. So now I was able to boot from the H37 controller and the PAM37 was the primary ROM.

With this set up I am getting dropped characters. I would imagine you also have this set up with PAM37 as the primary.

Seems like with PAM37 there are extra interrupts that are happening which is causing delays and dropped characters.

I'm going to update H8DIMGR2 and disable interrupts when receiving data. I think this will fix it.

Will keep you posted.

Les

Glenn Roberts

unread,
Nov 13, 2021, 5:50:08 PM11/13/21
to se...@googlegroups.com

Eureka. So I’m not going crazy.  I have the rev 2.6 board so I presume those reworks were incorporated directly into the board by then.  I’ve never had to do any mods.  I also have PAM37+ which is a slightly altered PAM37 image.  I can’t remember why that was done but Norberto or others (Terry G?) might be able to remind us.  I agree with you that there’s something in PAM37 that’s just occasionally taking a little too long in an interrupt service routine.

 

Let me know if you need any of the old .ASM programs I’ve mentioned (though the mods I did were minor and you may have a different approach)…  I’ll be out of pocket for a few days as far as accessing my H8 systems, but will continue to monitor/respond to email…

glenn.f...@gmail.com

unread,
Nov 13, 2021, 8:17:29 PM11/13/21
to se...@googlegroups.com

Les: I just  tried running H8DUtility3 before I remembered to plug in the Sabrent USB/Serial converter.  i.e. the computer has no COM: devices, but the software didn’t complain.  H8Utility2 would complain if I did this.

glenn.f...@gmail.com

unread,
Nov 13, 2021, 9:20:10 PM11/13/21
to se...@googlegroups.com

I had success at making an H37 image! I downloaded the HDOS2 boot image and was able to use HUtility3 and H37IMGR to create an image.  Initially I forgot that I had booted the system at 10Mhz (HDOS3 with AUTOEXEC.BAT) but once I stepped the speed down all worked well.

 

The intro message says that DK0 is supposed to be a 40Trk drive.  But I have a single 3.5” drive attached, which I usually use as DS/DD/80T.  is there a way to configure things so that DK0: can write 80T disks?  Also I couldn’t exit H37IMGR. Had to reboot.

 

Anyway, very nice.  I haven’t tried sending images (from the H8 to the PC) yet.

Les Bird

unread,
Nov 13, 2021, 9:20:48 PM11/13/21
to SEBHC
Right, I'll see about making H8DUtility 3 complain but it's a low priority at the moment.

So adding DI before reading serial port data fixed the problem. As a test I also bumped the baud rate up to 38,400 and was able to transfer a disk in 1:10. Initially I thought it was writing the tracks too fast but the disk image sent was verified good on the H8. Old single side 40 track speed at 9,600 baud was a hair under 3 minutes, 2:50 or something like that. Wow, what a difference.

I'll wrap things up and upload a new H8DIMGR3 version tomorrow.

Hopefully you can use your 8080 system to burn a disk and boot it on Rusty and Big Blue.

The steps to cold start a system will be a bit tricky now. In order to send H89LDR to a new system you'll have to do it at 9,600 baud. H8DUtility 3 lets you change the baud rate on the fly so you'll have to make sure it is set to 9,600. After sending the H8DIMGR3 boot disk and launching H8DIMGR3 you'll have to then switch H8DUtility 3 to 38,400 baud.

Les

Glenn Roberts

unread,
Nov 13, 2021, 9:23:08 PM11/13/21
to se...@googlegroups.com

Does 38.4KB require 16550 uart?

Les Bird

unread,
Nov 13, 2021, 9:26:34 PM11/13/21
to SEBHC
Yes you need to reboot when you're done with the imager. I think the same applies to H8DIMGR2 as well.

Interesting set up. So you don't have any 5 1/4" drives on your system? Hm.. H8DUtility and H37IMGR is pretty dependent on the correct drive configuration. Let me think on this a bit... perhaps I could add a single drive option. I just need to know what changes in both utilities I'd need to make to support this.

Good to know it worked. Glad to hear that.

Les

Glenn Roberts

unread,
Nov 13, 2021, 9:28:26 PM11/13/21
to se...@googlegroups.com
All I use for soft sector drives are 3.5”. Much more reliable.

Sent from my iPad

On Nov 13, 2021, at 9:26 PM, Les Bird <lesb...@gmail.com> wrote:

Yes you need to reboot when you're done with the imager. I think the same applies to H8DIMGR2 as well.

Les Bird

unread,
Nov 13, 2021, 9:28:40 PM11/13/21
to SEBHC
Good question Glenn, I'm not doing anything specific to enable special features on the 16550. It treats it just like an 8250 as far as programming it goes. Not sure if it would fail on an 8250. Technically the 8250 can support 38,400 but never tested the reliability at that speed so don't know for sure if it can handle it.

Les

Steven Hirsch

unread,
Nov 14, 2021, 9:12:38 AM11/14/21
to se...@googlegroups.com
On 11/13/21 9:28 PM, Glenn Roberts wrote:

> All I use for soft sector drives are 3.5”. Much more reliable.

Interesting - my experiences are exactly the opposite. The most reliable
floppy media I have are 8" diskettes, followed by 5.25". I've lost track of
the amount of data corruption seen on 3.5" drives.

Dave McGuire

unread,
Nov 14, 2021, 9:41:35 AM11/14/21
to se...@googlegroups.com
My experience is the same as yours. At the museum we get in an
occasional unreadable 8" disk, but most of them are fine. 5.25" are
about 50/50, maybe a bit better, and 3.5" are almost all garbage.

I attribute this to the rapid consumerization of floppy disk media.
Disk manufacturing was cheapened so rapidly that the useful lifetime of
new media is basically gone well within the useful lifetime of media
from two generations prior. Most of us saw that happen but it seems
many of us forgot. :)

-Dave

--
Dave McGuire, AK4HZ
New Kensington, PA

Glenn Roberts

unread,
Nov 14, 2021, 9:45:42 AM11/14/21
to se...@googlegroups.com
Well I guess I’m comparing 3.5” soft sectored to 5.25” hard sectored, so that’s a bit of apples to oranges. For some reason I never did much with 5.25” soft sectored drives on the H8, perhaps because I never had an H37 interface back in the day? I have had lots of failures on H17 style 5.25” hard sectored disks/drives. Don’t think I can recall personally encountering any failures in the 3.5” world. Lucky I guess? Perhaps my final caveat is that I generally make little use of floppy’s at all, and do most transfers and backup using USB flash drives… my main use of disk drives is to read, capture, and preserve old software.

Sent from my iPad

> On Nov 14, 2021, at 9:12 AM, Steven Hirsch <snhi...@gmail.com> wrote:
>
> On 11/13/21 9:28 PM, Glenn Roberts wrote:
>
>> All I use for soft sector drives are 3.5”. Much more reliable.
>
> Interesting - my experiences are exactly the opposite. The most reliable floppy media I have are 8" diskettes, followed by 5.25". I've lost track of the amount of data corruption seen on 3.5" drives.
>
> --
> 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/95ff456b-4891-d16e-d678-9f1f3f67493a%40gmail.com.

Kenneth L. Owen tx836519

unread,
Nov 14, 2021, 10:24:33 AM11/14/21
to se...@googlegroups.com

The Hard vs. Soft sectoring is an attribute of the disk media.  Any 5 ¼ “ disk drive will work with either. (Just different means of determining the start of sector – physical difference of the disks using the same hardware. Comparing 3.5” to 5.25” drives is a time difference - hardware from two different eras of technology.

 

  • ken

 

Sent from Mail for Windows

 

From: Glenn Roberts
Sent: Sunday, November 14, 2021 9:45 AM
To: se...@googlegroups.com
Subject: Re: [sebhc] H8DUtility 3

 

Well I guess I’m comparing 3.5” soft sectored to 5.25” hard sectored, so that’s a bit of apples to oranges. For some reason I never did much with 5.25” soft sectored drives on the H8, perhaps because I never had an H37 interface back in the day? I have had lots of failures on H17 style 5.25” hard sectored disks/drives. Don’t think I can recall personally encountering any failures in the 3.5” world. Lucky I guess? Perhaps my final caveat is that I generally make little use of floppy’s at all, and do most transfers and backup using USB flash drives… my main use of disk drives is to read, capture, and preserve old software.

Mark Garlanger

unread,
Nov 14, 2021, 12:47:35 PM11/14/21
to se...@googlegroups.com
Strange, for 5.25" disks, I'm seeing nearly 100% success. When it is failures, it's usually just a few sectors.

Mark


--
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.

Les Bird

unread,
Nov 14, 2021, 5:45:42 PM11/14/21
to SEBHC
Glenn,

When you get a chance here's where you can find the new H8DIMGR3 disk image. Also grab the latest H8DUtility 3 V3.01 from the same spot.

Link: wiki

Les

glenn.f...@gmail.com

unread,
Nov 20, 2021, 7:50:43 AM11/20/21
to se...@googlegroups.com
  1. I was able to create the 100K H8D bootable disk containing H37IMGR and H8DIMGR3 using my old version of the server and version 2.2 of H8Dutility.
  2. System is Big Blue (Z80 rev 4 board; piggyback H17/H37/H67 I/O).
  3. Booted from H17 floppy created in step 1
  4. Ran H8DIMGR3 and receive “CLIENT READY” prompt on H8 console
  5. On PC downloaded and ran H8DUtility3 from wiki link
  6. Clicked on Disk Imager
  7. Verified baud set to 9600
  8. Clicked on Client Status.  ION light goes out on H8; nothing happens.

 

Repeated steps on Rusty (Z80 Rev 2.6) and had similar but not identical results:

  • The ION light did not go out.
  • Console window on PC says “CLIENT IS NOT READY” then nothing happens.

 

The H37 imager worked fine and I was able to transfer an image and boot from it.  Just the H17 one not working for me.

 

From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of Les Bird
Sent: Sunday, November 14, 2021 5:46 PM
To: SEBHC <se...@googlegroups.com>
Subject: Re: [sebhc] H8DUtility 3

 

Glenn,

Les Bird

unread,
Nov 20, 2021, 9:35:09 AM11/20/21
to SEBHC
Thanks Glenn,

I've seen the "CLIENT NOT READY" bug too. I closed H8DUtility and restarted it and restarted the H8 and it worked the 2nd time. I'll try to find this. Seems to be a mix up of commands being sent to H8DIMGR. When the ION light goes out is waiting to receive the data but for some reason H8DUtility is getting the wrong response and thinks H8DIMGR is not ready.

Les

Les Bird

unread,
Nov 26, 2021, 1:33:52 PM11/26/21
to SEBHC
Glenn, All,

Lots of updates to H8DUtility 3 and a brand new version of H8DIMGR called H8DIMGR4. The new H8DIMGR4 has been completely rewritten from scratch fixing a lot of issues with the old H8DIMGR3. With H8DIMGR3 I copied some of the ROM functions to the H8DIMGR3 source files and hacked things together. With the rewrite I reset the H17 jump vectors back to the original ROM routines (away from the Ultimeth HSY ones) and called into the ROM functions directly. A much cleaner approach which results in a smaller executable (half the size) and very fast read/write results. I had to only override 2 ROM functions (D.SDT and D.STS) by loading the jump vectors to point to my functions in H8DIMGR4. The new overridden functions were rewritten to handle double sided disks.

Go grab H8DUtility 3.05 and H8DIMGR4 from the Wiki page here:

Source code project files have been updated here:

Les

Jeff Mowery

unread,
Nov 26, 2021, 2:48:19 PM11/26/21
to se...@googlegroups.com
Will H8D Utility 3 have the ability to emulate and boot disk images similar to H8D 2 utility?

Virus-free. www.avast.com

Les Bird

unread,
Nov 26, 2021, 7:07:23 PM11/26/21
to SEBHC
No, the emulator is a separate app now. It is built into the H19 emulator. You can grab it here:

Jeff Mowery

unread,
Dec 1, 2021, 5:16:44 PM12/1/21
to se...@googlegroups.com
Gave it a tryout, not sure if I am doing something wrong or what, but it is painfully slow. IE: as I type, letters are missed, and I am not fast typer.
Takes a while to display the folders to choose etc.
Jeff

Virus-free. www.avast.com

glenn.f...@gmail.com

unread,
Dec 5, 2021, 6:41:07 AM12/5/21
to se...@googlegroups.com

Les: finally got a few minutes to try this out.  I built H8DIMGR4.ABS from the source (no errors) and transferred to the same boot floppy that I had with H8DIMGR3 on it.  I boot from the floppy and run H8DIMGR4.  This is on Rusty (single 100K Siemens drive – single sided).

 

The message on the H8 console says:

 

CONFIGURE SYSTEM AS FOLLOWS:

SY0:  40 TRACK DOUBLE SIDED

SY1:  80 TRACK DOUBLE SIDED

 

 

But this is a single sided (100K) drive.  Is there code in there that’s trying to determine if I have a double sided drive? How do I tell it I don’t?

 

I ran H8DUtility3 and attempted to send the image “EMPTY1S40T”.  all seemed fine but after the message DISK IMAGE “EMPTY1S40D.H8D” sent in 0:40 the H17 drive made a lot of noise like it was trying to step to an unknown track?  I reset the system.  It seems troubling that the code doesn’t know that this is a single-sided drive.

 

That’s as much testing as I’ve been able to do so far…

Reply all
Reply to author
Forward
0 new messages