H8DUtility 3

[Les Bird]

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]

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]

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]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/79d75c2c-785e-4bf3-a827-d44fc51c89can%40googlegroups.com.

[Glenn Roberts]

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]

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]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/af16bf82-9c31-4f4a-9013-802b1e469af0n%40googlegroups.com.

[Joseph Travis]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/009801d7d05a%246242d4a0%2426c87de0%24%40gmail.com.

[Glenn Roberts]

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:



To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBA5DQGRy-Jvg2Pbiny3xo2OUFvcRgS%2BNCrpNAx3uZr_Jg%40mail.gmail.com.

[Les Bird]

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]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/94B5964F-AAF3-4804-9A80-156FA68D18A7%40gmail.com.

[glenn.f...@gmail.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!

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/33d90faa-83ea-49ab-83c4-9c024d2328b3n%40googlegroups.com.

[Les Bird]

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]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/6a9bae23-e947-49fa-9182-b1f5feebb9den%40googlegroups.com.

[Glenn Roberts]

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:



To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/9685f716-c2ed-8016-e565-8bcdf14a1143%40gmail.com.

[Glenn Roberts]

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?

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/6a9bae23-e947-49fa-9182-b1f5feebb9den%40googlegroups.com.

[Les Bird]

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]

Interesting… tx.

 

But see the note I just sent for more info 😊…

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/a8565324-4d96-4c6e-ac14-a9f4c8eda064n%40googlegroups.com.

[Les Bird]

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]

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]

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?

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/58746076-8590-493b-9ec5-251f2630b858n%40googlegroups.com.

[Les Bird]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/41eb8f7e-ee7b-4279-98ad-831bb94585d6n%40googlegroups.com.

[Les Bird]

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]

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!

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/25347ee7-c1eb-42fc-acb8-c120df634ecdn%40googlegroups.com.

[Les Bird]

I'll try running on a Windows box to try and reproduce the results.

Les

[Les Bird]

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]

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,

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/13ec88ba-be23-4340-aaeb-223c4dd023bdn%40googlegroups.com.

[Glenn Roberts]

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,

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/13ec88ba-be23-4340-aaeb-223c4dd023bdn%40googlegroups.com.

[Glenn Roberts]

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]

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]

H89LDR ASM source code attached. The BIN file for some reason I renamed to H89LDR3 even though it was assembled from H89LDR2.ASM

Les