H8D Utility & Les' Z80 CPU

19 views
Skip to first unread message

Kenneth L. Owen

unread,
Aug 9, 2013, 4:36:29 PM8/9/13
to se...@googlegroups.com

Hi Les and others,

 

Today, I have been working with Chris to get his H8 working with the H8D Utility.  He is running the 8080 card and, as far as I know, it should work with his setup.  I explained that while I have an H8, it is running Les’ Z80 CPU with dual ROM and would not run the H8D utility.

 

Well, at least that is what I have read on the site, so I had never tried to use it.  Today, I did try it.  I have a Loader Disk that I made on my H89.  I installed this into the H8 floppy and booted.  With my PC cabled to the H8’s LP port (340Q), I started the H8D Utility and checked client status.  It said “Client is ready.”  I inserted a CP/M single-sided disk and uploaded it with no problem.

 

Next, I tried to send a file to the H8.  Status was still “Client is ready.”  It did not work, but timed out.

 

Attached are two files:  a screen capture of the H8 uploading a CP/M disk and the error message generated when I tried to send.

 

-- ken

 

 

H8_UpLd.gif
H8D_Err.pdf

Glenn Roberts

unread,
Aug 9, 2013, 6:25:51 PM8/9/13
to se...@googlegroups.com

This may be the issue I had been working on back in the spring.  I can’t use the loader with my Z80-based H8 but it does work with my original 8080-based one.  To test this I was using Dwight Elvey’s H89LDR program (not the version built into Les’ emulator, though both should function the same). I had determined that this was an issue with the H8 keeping up with serial transfer (by using the front panel to monitor one of the count down buffers – it never reaches 0 and the code hangs.)  I concluded that turning off the front panel display update during transfer might fix this as it was “stealing” CPU cycles.  I have all the pieces to try and fix this but stopped short of actually trying patching the code.

 

There was discussion at the time that this is related to what CPU ROM you have, though I’m not quite sure why.  What ROM version is on his 8080?  I think mine (on the system that works) is PAM8GO (444-13?) but would have to go pull open the system to check.  My Z80 system (XCON8) does not work with the H89LDR.  Someone on the list said that by switching to the older ROM they were able to make this work, though it would be nice to fix the code to be ROM-independent…

 

The previous discussion thread is in the google groups archive under H89LDR (May 17)

 

https://groups.google.com/forum/?hl=en#!forum/sebhc

 

the immediate issue went away for me once I got the USB interface working so I haven’t spent any more energy on it since then.

 

-          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 post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/99A99B7633774CDEB5D6E01AFB9DA461%40kws1?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

dwight elvey

unread,
Aug 9, 2013, 7:23:13 PM8/9/13
to se...@googlegroups.com
What serial card are you using? The one on the serial/cassette was not well
designed and couldn't keep up at 9600. There is an option to run at 4800.
It was a problem with the optical isolator.
Sending out data to the PC shouldn't be a problem with interrupts on
the H8 side. There have been problems with windows on the PC side.
That is why I recommend a true DOS boot but Les' code should work.
I can't recall about which boards had which serial chip. The code
is different for the two types of chips ( 8250 and 8251 ).
Dwight

 

From: glenn.f...@gmail.com
To: se...@googlegroups.com
Subject: RE: [sebhc] H8D Utility & Les' Z80 CPU
Date: Fri, 9 Aug 2013 18:25:51 -0400

Chris Osborn

unread,
Aug 9, 2013, 7:27:59 PM8/9/13
to se...@googlegroups.com
Gave up on trying to get the H8D Utility to work and installed Linux and tried out H8trans. It has a step about loading the second stage bootloader which I didn't see anything about in H8D Utility.

It told me it was successful transferring the 2nd stage loader, but after that it didn't do anything. I told it to read a disk but it just sat there and the H8 never tried to do anything.

Kenneth L. Owen

unread,
Aug 9, 2013, 8:04:15 PM8/9/13
to se...@googlegroups.com

Hi Dwight,

 

I am using the H8-4 serial card and believe that is the same card that Glenn is using as well.

 

The H8 works just fine using MAPLE at 4800 baud on either 330Q or 340Q doing X-modem transfers on HDOS.  On CP/M, I run ZMP at 4800 doing Z-modem transfers using the same two ports with no problem as well.

 

-- ken

 


To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/BLU178-W92219E971DFE325DC7498A3580%40phx.gbl?hl=en-US.

Norberto Collado

unread,
Aug 9, 2013, 8:32:32 PM8/9/13
to se...@googlegroups.com
Please replace the second ROM (XCON-8) with the H17 ROM 444-19 and then it should work. Let me know if that is not the case. 
 
Norberto
Glenn
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/5D7E9DD7362F4DE58BE67E4238098C5A%40kws1?hl=en-US.

dwight elvey

unread,
Aug 9, 2013, 9:04:45 PM8/9/13
to se...@googlegroups.com
Norberto is most likely correct. I'm a little lazy.
I used a lot of the H17 ROM code. Any part of the
code changed would cause failure for sure.
Dwight

 

To: se...@googlegroups.com
Subject: RE: [sebhc] H8D Utility & Les' Z80 CPU
Date: Fri, 9 Aug 2013 17:32:32 -0700

Kenneth L. Owen

unread,
Aug 9, 2013, 9:30:04 PM8/9/13
to se...@googlegroups.com

Hi Norberto,

 

My 8080 CPU board appears to have 444-70 (XCON8 half ROM).

 

I don’t think I have a 444-19 ROM.

 

-- ken

 


To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/20130809173232.1321cca37f09b4ab87c5049afdc8ceaa.38120114cb.wbe%40email09.secureserver.net?hl=en-US.

Norberto Collado

unread,
Aug 9, 2013, 10:42:34 PM8/9/13
to se...@googlegroups.com
The fix is for Les' Z80 board. The XCON8 contains the H17 ROM, which is somehow not working properly with the H8D utility. Terry knows very well the XCON8 code and maybe he can figure out the issue with the H8D utility.

On the H89 the 444-19 ROM is present and it works fine; correct?

Norberto

Glenn Roberts

unread,
Aug 10, 2013, 7:05:43 AM8/10/13
to se...@googlegroups.com

I believe I had diagnosed this but may not have documented it.  The client side of Dwight’s program (the part that runs on the H8) executes simple commands like read, write, etc.  the write command has code that writes a full track of data. It looks like this (this is based on a version I reformatted for use with HDOS ASM):

 

044.311  001 000 012 00766           LXI  B,ZBUF     one track

                     00767   *

                     00768   *  Read and store BC bytes

                     00769   *

044.314  315 352 043 00770   WRIMG2  CALL CHRIN      get data

044.317  167         00771           MOV  M,A        store it

044.320  043         00772           INX  H          point to next

044.321  013         00773           DCX  B          decrement counter

044.322  170         00774           MOV  A,B

044.323  261         00775           ORA  C          check for counter=0

044.324  302 314 044 00776           JNZ  WRIMG2     if not, keep looping

 

It simply reads a full track of data off the serial line one byte at a time (CHRIN which is a polled serial read, not interrupt driven).  What I did was use the front panel to watch the program counter and the BC register.  This code will only exit the loop if it successfully reads a full track, i.e. 256*10=2,560 bytes.  I was seeing a small but random number of bytes that were being left unread because BC never decrements the entire way to 0 (it gets down to a small number).  This means that bytes are being lost.  I presume this is because there is an interrupt service routine that takes enough time that occasionally one of the incoming bytes is never read before the following one comes in.  Since we see this only on XCON8 systems I presume there was some additional code in that ROM that got added to the clock interrupt. 

 

One fairly simple thing to try is running it at a lower BAUD rate.  Then hopefully characters wouldn’t be dropped, but this would slow things down of course.

 

Alternately, since the code doesn’t turn off the front panel refresh (which we know takes extra CPU cycles) we could disable FP refresh during this part of the code.  Hopefully then the polling loop will be able to keep up and no characters will be dropped.  This is a few lines of code to implement but I stopped short of doing that because it means rebuilding everything.  It might also be straightforward to just develop a patch.

 

If there’s interest I can try this, but I’m not sure how soon I can get to it…  I’m happy to share my code and knowledge with others if someone else would like to try.

 

-          Glenn

Reply all
Reply to author
Forward
0 new messages