Interesting problem w/H8-5 using HDOS & BH BASIC

45 views
Skip to first unread message

Joe Travis N6YPC

unread,
Jan 17, 2022, 11:14:38 AMJan 17
to SEBHC
Greetings All,

I have a Hayes Chronograph I want to use with my H8 to set the date / time on HDOS3. I'd like to use the serial port of the H8-5 for the interface.  My initial testing started with BH BASIC using the following program to verify serial output to TeraTerm on my laptop:

00005 REM H8-5 UART TEST
00010 OUT 251,64: REM RESET UART
00015 OUT 251,78: REM MODE N,8,1,X16 (1200B,N,8,1)
00020 OUT 251,55: REM CMD RTS,ER,RXE,DTR,TXE
00025 FOR I=32 TO 127
00030 OUT 250,I: PRINT CHR$(I);
00035 NEXT I

When I run the program in MBASIC on CP/M, it works exactly as expected.

When I run the program in BH BASIC, the computer will often "go off into the weeds" as if an interrupt (vector) was corrupted.  There may be garbage output to the serial port and / or a constant BELL character is sent to the console terminal (sounds like a continuous beep).

Are there any HDOS Gurus that can offer help / suggestions?  Thanks!

Regards,
Joe Travis n6ypc


Joseph Travis

unread,
Jan 20, 2022, 9:27:29 PMJan 20
to se...@googlegroups.com
After much digging, I was able to confirm my suspicions about interrupts being trashed.  Page 13-10 of the HDOS 3.0 Reference Manual, under the heading of I/O PRECAUTIONS:  "Don't disturb the H17, the H37, and the H47, and don't disturb the console ports" (which includes the H8-5).

I currently see two ways around this dilemma: (1) Find a AT.DVD driver for the H8-5 or (2) change the I/O address of the H8-5 to an unreserved address (Reserved I/O addresses are listed on page 13-6.  Oddly it doesn't list 362Q).

I hate to change the I/O address on the H8-5 as that would render it useless for it's original purpose.  Does anyone happen to have a copy of the AT.DVD for the H8-5 (8251)?

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/5ce760ef-0261-4122-b2c5-b8ddbdfe0b0fn%40googlegroups.com.

glenn.f...@gmail.com

unread,
Jan 21, 2022, 7:05:06 AMJan 21
to se...@googlegroups.com

Joe: Looking at the driver source for HDOS 2 it appears you can assemble the AT: driver for either the H8-4 or H8-5 card. You could take the source for ATH84.ASM from the HDOS 2 “Driver Source” disk and rebuild it. The H8D images are on the SEBHC site

https://sebhc.github.io/sebhc/software/HDOS/HDOS_2-0.zip

 

on the first line change “H84IO” to be equal to ‘1’ (counterintuitive but ‘1’ means false and ‘0’ means true to the HDOS assembler):

 

 

H84IO EQU   0           ASSEMBLE FOR H8-4 CARD

      IF    H84IO

      TITLE 'ATDVD      - AT: Device Driver, H8-4'

      ELSE

      TITLE 'ATDVD      - AT: Device Driver, H8-5'

      ENDIF

      EJECT

 

I note that the HDOS3 “drivers” disk contains a file “AT85.DVD” which may be this driver already built?  And it looks like the source is in the “DRIVERSOURCE1” disk (ATDVD.H8A).

 

You’ll probably need to dig deeper into these files to see if I know what I’m talking about but it looks like what you need is either in the HDOS3 disks or the HDOS2 Drivers disk.  I see a comment in ATDVD.H8A that seems to say the H8-5 ports would be 374-5, which sounds wrong??  I expected 372-3 ??

 

Keep us posted and let us know if you need further assistance…

 

 

  • Glenn

glenn.f...@gmail.com

unread,
Jan 22, 2022, 8:49:35 PMJan 22
to se...@googlegroups.com

Joe: looking at the HDOS 2 manual it appears that the recommendation for using H8-5 with the AT: device driver is to change the Serial Port I/O address to 374/5.  This means changing the ‘X’ jumper from hole ‘2’ to hole ‘4’.  Interrupts are not supported so remove the interrupt jumper from hole ‘S’ (normally goes to I3 when used as console).

 

 

image001.png
image002.png

Glenn

unread,
Jan 22, 2022, 8:51:10 PMJan 22
to SEBHC
ignore the red oval if it looks odd. poor attempt to highlight the "AT:" line ...

Joseph Travis

unread,
Jan 25, 2022, 1:44:24 PMJan 25
to se...@googlegroups.com
Thanks for all the info Glenn!  I apologize for my slow response as I've been sick for the last two and a half weeks, not feeling like doing anything more than suffering through it.  I'm feeling better now but still not completely over it.

I currently have a limited amount of reliable hard sectored disks and am reluctant to sacrifice what I've got to cobble together a working disk in order to assemble AT.DVD.  I know that sounds rather pathetic but I am trying to improve the situation (albeit slowly).  The other hassle is my SY0: is 40T while SY1: and SY2: are both 80T.

I recently pulled out the H8-5 and discovered the interrupt jumper was enabled.  That shouldn't have surprised me as the board was configured exactly as described in the assembly manual.  Based upon the info you provided, I did reconfigure it for 374Q, no interrupt and was able to get my program functioning with the board.  The unfortunate thing is that it is too slow to reliably receive data at 1200 baud when using BH BASIC (using direct I/O).

After reading your wonderful article in REMarks, I've decided to return the H8-5 back to it's original configuration and connect the Hayes Chronograph up to my last remaining port on the H8-4 board.  I'll still need to assemble the AT.DVD and use it in order for the program to function properly.  I wish there was a version of HRUN that runs under MS-DOS on the H-100...  then I could use the CF drive on it for all my development.

That's all for now.  Thank you once again!

Regards,
Joe Travis n6ypc


Glenn Roberts

unread,
Jan 25, 2022, 2:10:37 PMJan 25
to se...@googlegroups.com

Hmm. Yes, since the driver is not interrupt-driven your application will have to keep up with reading from the port or data will be lost, still a little surprising that it can’t keep up with 1200 BAUD (can you set the chronograph to 300?).  I haven’t looked at the AT.DVD for the H8-4 – is it interrupt-driven?  If not it will exhibit the same behavior - wouldn’t be too hard to put one together.  Let me know if I can help. also happy to assemble and send you any code. You could consider using Les’ H89 emulator to do the assembly work on a PC…? 

Joseph Travis

unread,
Jan 25, 2022, 2:43:38 PMJan 25
to se...@googlegroups.com
No, I don't believe the AT.DVD for H8-4 (or H8-5) is interrupt driven.  I don't recall seeing anything for an ISR (Interrupt Service Routine).  Using assembly language, you can get fairly reliable communications up to 9600 baud without interrupts on a 2 MHz Z80 (depending on the overhead).  At 9600 baud, characters are coming at about 1mS intervals.  I did have a look at the H84DVD.ASM code, it appears you can assemble this version for the H8-4 or the H8-5.  Years ago, I recall there were separate files.

Yes, I suppose I could run the chronograph at 300 baud. I may try that.  I tried the H89 emulator a few years ago and didn't have much luck with it.  That may have been when it was undergoing some changes, I don't recall the details.

BTW - The H8-5 uses INT3 for the console (372Q) for tape based programs.  Coincidently, that interrupt is also used by the H8-4 for the console (350Q) which explains why my earlier test program would send the computer into the weeds.  As long as the board's ports are used exclusively, it shouldn't be a problem keeping them both at INT3.

Best Regards,
Joe Travis n6ypc



Glenn Roberts

unread,
Jan 25, 2022, 4:08:22 PMJan 25
to se...@googlegroups.com
I agree a machine or compiled program will keep up using task time I/O but if you’re using BH BASIC to open and read AT: the interpreted code plus the device driver overhead will probably drag things down slow enough that you drop  characters?

I’ll do some poking around to see what’s been done here…

Sent from my iPad

On Jan 25, 2022, at 2:43 PM, Joseph Travis <jtravi...@gmail.com> wrote:



Douglas Miller

unread,
Jan 25, 2022, 4:58:28 PMJan 25
to se...@googlegroups.com

Lots of hidden pot-holes. Sooner or later you have to do something with the data you've loaded, at least in the case of saving to disk files. Then there's the 2mS clock and front panel updates, if those are still enabled. Things can happen, and it can add up. Dedicated code the loops on RxD does great, but if the call paths for each character are very long, things can fall behind (and get side-tracked). And of course, things like interpreted BASIC have all sorts of hidden pitfalls, like "garbage collection" that can run without warning and not return control to your program for a very long time.

norberto.collado koyado.com

unread,
Jan 25, 2022, 6:02:41 PMJan 25
to se...@googlegroups.com
I loved when the HW and SW works in harmony. I can run the system continuously for months and months without any system crash.


From: se...@googlegroups.com <se...@googlegroups.com> on behalf of Douglas Miller <durga...@gmail.com>
Sent: Tuesday, January 25, 2022 1:58 PM
To: se...@googlegroups.com <se...@googlegroups.com>

dwight

unread,
Jan 25, 2022, 6:44:38 PMJan 25
to se...@googlegroups.com
Although, I often get this wrong, I believe it is the H8-5 that transfers serial data through an optical coupler. ( I was there for interfacing to a TTY ). It limits the speed that a H8-5 can run at. I've had mine doing 1200 baud but not 9600 baud, when just copying data to a fixed buffer.
I often confuse the H8-4 with the H8-5 but this could possibly be your issue. The particular optical couple you have may not be able to keep up with the data rate.
The other serial board can easily keep up with 9600.
Dwight



From: se...@googlegroups.com <se...@googlegroups.com> on behalf of norberto.collado koyado.com <norberto...@koyado.com>
Sent: Tuesday, January 25, 2022 3:02 PM

Glenn Roberts

unread,
Jan 25, 2022, 7:51:35 PMJan 25
to se...@googlegroups.com
The H8-5 is the card with the optocouplers but I’m pretty sure that’s not the problem. It can handle 1200 BAUD fine. As Douglas points out there are all kinds of reasons characters will be dropped. BASIC is interpreted (slow), using a device driver adds some overhead, and then there are those pesky 2ms clock interrupts! 

IMO the most reliable solution is to have the device driver be interrupt driven. I actually have not been able to find an example of such a driver for serial I/O. Most of the drivers we have source for are for printers.

Joe perhaps remind us of the original objective of reading the chronograph? What are you doing with the result? Set the system date? Set the CK: driver time? Perhaps a simple little assembly program can do the job….

 I don’t see anything changing by going to the H8-4.

Sent from my iPad

On Jan 25, 2022, at 6:44 PM, dwight <dke...@hotmail.com> wrote:



Joseph Travis

unread,
Jan 25, 2022, 8:58:02 PMJan 25
to se...@googlegroups.com
Yes, the original plan is to read the Hayes Chonograph and use it to set HDOS system date / time.  I've had this chronograph since the early 80's when I used it with my first H-100 (before the FBE Smartwatch and others).

I believe the ATH84 (AT.DVD) may work sufficiently without interrupts but certainly would be much better with.  That opens up the number of possibilities for a variety of devices and languages.

I don't remember a TT.DVD for HDOS 2.0 but seem to recall seeing it in HDOS 3.  This would probably be the best place to start for an interrupt driven AT.DVD.

Once the communications is ironed out, the next thing is to find the memory locations in HDOS 3 to set the date and time.

Thank you all for your interest and assistance.

Regards,
Joe Travis n6ypc


You received this message because you are subscribed to a topic in the Google Groups "SEBHC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sebhc/tCk8651SSxI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/D6F786D7-293E-4BE4-8C63-BA1811055AC9%40gmail.com.

glenn.f...@gmail.com

unread,
Jan 25, 2022, 10:01:05 PMJan 25
to se...@googlegroups.com

Random thoughts (hey it’s almost my bedtime! …):

 

Love that you’re using the Hayes clock. Very cool piece of retro hardware!

 

Yes TT: has an interrupt-driven approach but I don’t think you need to build an interrupt-driven driver. Issue is probably that you’re using BASIC to read from AT:. Very slow.  Better to have an ASM program (or C, which is what I would do – I can help with that!)

 

HDOS3 has a CLOCK task and an .SCALL for communicating with the task manager (.TASK).  not sure if there’s a path there to talk to the clock task?

 

I wouldn’t plan on writing the time to RAM, better to use the built in TIME command?

 

HDOS 3 has batch files. Wonder if a .BAT can invoke another .BAT?  could have one .BAT read the time from hayes and edit a second .BAT (containing the TIME command) and insert the time/date. Then invoke that .BAT?

 

Maybe just edit Stanley Webb’s RTC program? My HDOS3 system sets the clock via RTC. As written it pulls the time from the OKI chip but you could substitute some code to talk to the serial port and voila!  See attached.

 

Night night..

RTCV23.ASM

norberto.collado koyado.com

unread,
Jan 25, 2022, 10:04:43 PMJan 25
to se...@googlegroups.com
I love assembly language as it is easy to control your destiny. 

Here are two files of a small program I did on CP/M and ported to HDOS in assembly language when using the calendar clock to display time and date. Just modify the entries for the date/time with your Chronograph routines (just polled the UART port to send/receive data). Once working, then add entries to HDOS to set the OS date/time.  

I hope this helps,

Norberto

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of Joseph Travis <jtravi...@gmail.com>
Sent: Tuesday, January 25, 2022 5:57 PM
HDOS CLOCKMON.ABS
HDOS CLOCKMON.ASM
Reply all
Reply to author
Forward
0 new messages