--
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.
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…
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBCnWj8a13CxhbpfqEhp9VYteBMLS-Fdzt2wMQcAmuHucA%40mail.gmail.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).
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/895fd296-8d2e-4ea9-b3fa-381ba772fc30n%40googlegroups.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…?
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBAuEv%3DCJfRh%2BXP13cCJ970uG5bbYBe0Gpy3FXMuQ%3DzaOQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/012a01d8121f%243ad0d3c0%24b0727b40%24%40gmail.com.
On Jan 25, 2022, at 2:43 PM, Joseph Travis <jtravi...@gmail.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBCJdKkaxnyxkrKujRCBv8SqMOhppXtD4pzKvufov-_xsw%40mail.gmail.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/7BF88469-3871-4ACC-9CB1-BF2A36A467AA%40gmail.com.
On Jan 25, 2022, at 6:44 PM, dwight <dke...@hotmail.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/BYAPR01MB5319586D7C4DA081541CC728A35F9%40BYAPR01MB5319.prod.exchangelabs.com.
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.
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..
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBCxDUcj%3DhJ739wOAsi9hoyJPDWkaB9nrgq4UmGuc%2BYNYg%40mail.gmail.com.