H8D Utility & Les' Z80 CPU
Kenneth L. Owen
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
Glenn Roberts
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
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
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
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
Norberto Collado
dwight elvey
I used a lot of the H17 ROM code. Any part of the
code changed would cause failure for sure.
Dwight
From: norberto...@koyado.com
Kenneth L. Owen
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
Norberto Collado
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/B5895718F72F4FF0B5EB08179723562F%40kws1?hl=en-US.
Glenn Roberts
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
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/20130809194234.1321cca37f09b4ab87c5049afdc8ceaa.d989ec4979.wbe%40email09.secureserver.net?hl=en-US.