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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/79d75c2c-785e-4bf3-a827-d44fc51c89can%40googlegroups.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!...
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…
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/af16bf82-9c31-4f4a-9013-802b1e469af0n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/009801d7d05a%246242d4a0%2426c87de0%24%40gmail.com.
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/94B5964F-AAF3-4804-9A80-156FA68D18A7%40gmail.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):
Now for Rusty:
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/33d90faa-83ea-49ab-83c4-9c024d2328b3n%40googlegroups.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".
On Nov 3, 2021, at 12:35 PM, Douglas Miller <durga...@gmail.com> wrote:
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:
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?
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.
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.
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.
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.