DSR CLOCK device and any program that used it with standard DSRLNK access?

[+jedimatt42]

Some thread somewhere recently, which I cannot find again, said that some form of BOOT supported the Corcomp 'CLOCK' device strictly through the DSR.

 

Which version of the menu program was that?

 

I implemented a 'CLOCK' device in the TIPI DSR, that is compatible with the example usage of the Corcomp Clock manual. However with the menu program found in the TIMXT / 9640 Menu system that comes with a PDF doc saying the Corcomp clock is supported, I get some pretty weird behavior.

 

1st, if loaded with CALL TIPI("TIPI.F18A.BOOT"), I get no clock display.

2nd, if loaded from DM2K that was loaded by CALL TIPI("TIPI.DM2K.DM2K") I do get a garbled clock display... in the middle of the screen, without any parsing of the record returned by my "CLOCK" dsr.

 

 

I'm just fishing for if there is any program that would benefit from a "CLOCK" device that is DSR level compatible, and if so, which programs, so I can test.

 

The corcomp manual implies a DISPLAY record of 3 comma separated strings.

Field 1: day of week, I am assuming that in the 80s, in the US, 1=Sunday.

Field 2: date mm/dd/yy -

Field 3: time hh/mm/ss

 

If it doesn't work via DSR with existing software, then I don't want a device in the way during the DSRLNK process.

 

-M@

[+jedimatt42]

"Benefit" is too vague of a term. "function correctly" is the term I should have used.

 

-M@

[Tursi]

I thought someone showed a picture of one of them working with Classic99, so yeah, it must be out there somewhere...

 

I have in my notes a comment that the day of week is 0-6, not 1-7 as the manual states. Otherwise what you show matches what I've got.

[+jedimatt42]

I thought someone showed a picture of one of them working with Classic99, so yeah, it must be out there somewhere...

 

I have in my notes a comment that the day of week is 0-6, not 1-7 as the manual states. Otherwise what you show matches what I've got.

 

Hey, your classic99 manual matches that...

 

Ok, the triple tech card manual scanned up in the hardware docs on WHTECH as 1-7 crossed out, and 0-6 noted...

 

---

 

If I include a DSR friendly CLOCK, is it likely to get in the way of the programs that read the memory mapped registers directly? Are they all smart enough to just skip to crubase >1D00 or whatever it was, and read the bytes?

 

If it won't get in the way, I'll include it... if it will get in the way, I'll feel compelled to call it PICLK instead so users have to edit their apps to use my clock and not cause bad behavior in other programs... Right now, it clearly causes bad behavior in 9640 Menu System...

 

-M@

[+jedimatt42]

Ooh, I get the same goofy behavior of 9640 Menu System in Classic99 ( v399a )

 

EA option 5, no clock display.

DM2K load, clock in the middle of the screen, raw, with the same gnarly bits as in my screen shot earlier.

 

Maybe I'll just do "CLOCK" the dsr way, and if people don't want it, they can smudge it out in the ROM and share that themselves. Or just not upgrade the ROM whenever it becomes available.

 

I know.... If I write some software, then there will be some.

 

-M@

[HOME AUTOMATION]

I hope this isn't too far off base, but... The system I employ for my ti-99/4a clock/scheduler; is to have an external device send a short pulse through the LOAD interrupt line at 60 sec. intervals thus triggering my clock program to advance by 1 min. I like to avoid constantly polling devices in my program. I know TIPI doesn't use interrupts... so I'm wondering if it would be hard to program the TIPI's RPI to generate this clock pulse using an unused I\O pin!!!

[+jedimatt42]

I hope this isn't too far off base, but... The system I employ for my ti-99/4a clock/scheduler; is to have an external device send a short pulse through the LOAD interrupt line at 60 sec. intervals thus triggering my clock program to advance by 1 min. I like to avoid constantly polling devices in my program. I know TIPI doesn't use interrupts... so I'm wondering if it would be hard to program the TIPI's RPI to generate this clock pulse using an unused I\O pin!!!

 

The bus pins are passed through on the sideport TIPI. It shouldn't interfere with what you are doing... You could run a line from a GPIO pin to trigger your circuit and control that with a little shell script on the PI...

 

alternatively, I'd start by setting up a vdp interrupt counter to keep time, then read the time to initialize it, and then poll the clock source once in a while to 'correct' the time. ... NTSC : 60 hz * 60 sec/minute = 3600 cycles/minute. You can decide to poll the time source appropriate for you application...

 

-M@

[+InsaneMultitasker]

Some thread somewhere recently, which I cannot find again, said that some form of BOOT supported the Corcomp 'CLOCK' device strictly through the DSR.

 

Which version of the menu program was that?

 

I implemented a 'CLOCK' device in the TIPI DSR, that is compatible with the example usage of the Corcomp Clock manual. However with the menu program found in the TIMXT / 9640 Menu system that comes with a PDF doc saying the Corcomp clock is supported, I get some pretty weird behavior.

 

1st, if loaded with CALL TIPI("TIPI.F18A.BOOT"), I get no clock display.

2nd, if loaded from DM2K that was loaded by CALL TIPI("TIPI.DM2K.DM2K") I do get a garbled clock display... in the middle of the screen, without any parsing of the record returned by my "CLOCK" dsr.

 

IMG_20180830_225140058.jpg

 

I'm just fishing for if there is any program that would benefit from a "CLOCK" device that is DSR level compatible, and if so, which programs, so I can test.

 

The corcomp manual implies a DISPLAY record of 3 comma separated strings.

Field 1: day of week, I am assuming that in the 80s, in the US, 1=Sunday.

Field 2: date mm/dd/yy -

Field 3: time hh/mm/ss

 

If it doesn't work via DSR with existing software, then I don't want a device in the way during the DSRLNK process.

 

-M@

I alluded to this in another post : I added DSR-based "CLOCK" support to the 9640 menu program some time ago, however, I apparently didn't release the correct version. The artifact next to the B or C option when a clock is not present was intentional for my testing, as was the PAB/buffer display as shown in the screenshot. I guess I need to figure out what I did with the right code, which simply parses the returned string and displays the time/date in the upper right corner. It also got rid of the direct-access TripleTech code in place of the DSR-based routine.