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.
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)
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.
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.
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.
My 8080 CPU board appears to have 444-70 (XCON8 half ROM).
I don’t think I have a 444-19 ROM.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/B5895718F72F4FF0B5EB08179723562F%40kws1?hl=en-US.
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
00768 * Read and store BC bytes
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.
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.