4hubbs Posted November 20, 2010 Share Posted November 20, 2010 Is it possible to read the SpartaDOS realtime clock in BASIC? I am trying to write a short program that will save data every 30 minutes or so. thanks Quote Link to comment Share on other sites More sharing options...
1050 Posted November 21, 2010 Share Posted November 21, 2010 Yes. From the SpartaDOS Construction Set Manual... APPENDIX D___How to Access the Real Time Clock SpartaDOS keeps the internal time and date clock running and stores the values in memory. These can be used in your applications programs whenever access to time or date is desired. The values are stored in COMTAB+13 to COMTAB+18. The pointer to the COMTAB location is stored at DOSVEC (locations 10 and 11). COMTAB+13=location of day COMTAB+14=location of month COMTAB+15=year COMTAB+16=hours (24 hour format) COMTAB+17=minutes COMTAB+18=seconds The BASIC program below will display these values. It was written as a plain and simple example for those starting out in BASIC or new to programming the Atari. To read the time and date values use PEEK and to change the values use POKE. 10 CMTAB=PEEK(10)+PEEK(11)*256 20 FOR T=13 TO 18 30 ? PEEK(CMTAB+T) 40 NEXT T Note: A special SpartaDOS handler is used with the TD, XTD and TSET commands to access our optional R-Time 8 clock/calendar cartridge. This automatically updates the internal real time clock used by DOS. Since the cartridge is very difficult to read directly, we recommend you read it with the proper handler installed through the DOS locations as shown in the above example. .... __________________________ Chapter 5___The BASIC Time and Date 'Z:' Handler Functions The following is a list of Time and Date 'Z:' handler functions and how to implement them from BASIC through XIO statements. The DOS command, if applicable, follows the function name in parenthesis. General Notes It is assumed that a 'Z:' handler has been installed into your system. This is accomplished by the command 'ZHAND' under SpartaDOS 3.2 (also install the display with 'TDLINE' if using a display function under 3.2). If using an earlier version of SpartaDOS or Atari DOS 2 (or versions thereof), you must use the 'RTIME8.COM' file. Type 'RTIME8' if using a Command Processor driven DOS (like SpartaDOS), or rename the file to 'AUTORUN.SYS' and boot the diskette if using a DUP.SYS type of DOS (like Atari DOS 2.5). Throughout these examples, 'IOCB' represents an Input/Output Control Block number from 1 through 7. __________________________ Turn Time and Date Display ON (TD ON) Syntax XIO 38,#IOCB,0,0,"Z:" Notes An extra line will appear at the top of the display containing the current time and date. The SpartaDOS version number will also be displayed. If you are using the 'RTIME8' handler for Atari DOS 2, the message 'R-Time 8' will appear instead of the SpartaDOS version message. An error 139 (Device NAK) will occur if the 'TDLINE' handler has not yet been installed under SpartaDOS. __________________________ Turn Time and Date Display Off (TD OFF) Syntax XIO 39,#IOCB,0,0,"Z:" Notes The extra line at the top of the display is removed. This has no effect on SpartaDOS's internal time keeping. __________________________ Read Formatted Date Syntax XIO 34,#IOCB,0,0,"Z:" INPUT #IOCB,DATE$ Notes This sequence will read the date into 'DATE$'. This string should be at least 13 characters long (as defined by the BASIC 'DIM' statement). The string will be returned in the format 'Mon 21-Oct-85'. Attempts to read more characters will return an end of file error 136. The IOCB must be opened for read prior to the execution of these statements (ie. OPEN #1,4,0,"Z:"). An error 139 (NAK) will be returned if the TDLINE handler has not yet been installed when using SpartaDOS 3.2 __________________________ Read Formatted Time Syntax XIO 32,#IOCB,0,0,"Z:" INPUT #IOCB,TIME$ Notes This sequence will read the time into 'TIME$'. This string should be at least 10 characters long (as defined by the BASIC 'DIM' statement). The string will be returned in the format '10:20:46am'. Attempts to read more characters will return an end of file error 136. The IOCB must be opened for read prior to the execution of these statements (ie. OPEN #1,4,0,"Z:"). An error 138 (NAK) will be returned if the TDLINE handler has not yet been installed when using SpartaDOS 3.2 __________________________ Read Unformatted Date (DATE) Syntax XIO 35,#IOCB,0,0,"Z:" GET #IOCB,DAY : GET #IOCB,MONTH : GET #IOCB,YEAR Notes This sequence will read the numerical date into the variables, 'DAY', 'MONTH' and 'YEAR'. The year is returned as the last two digits of the actual year (ie. 1985 is returned as YEAR 85). Attempts to read more characters will return an end of file error 136. The IOCB must be opened for read prior to the execution of these statements (ie. OPEN #1,4,0,"Z:"). No error will occur with this command under SpartaDOS 3.2 since this is an internal function of SpartaDOS 3.2 __________________________ Read Unformatted Time (TIME) Syntax XIO 33,#IOCB,0,0,"Z:" GET #IOCB,HOUR : GET #IOCB,MINUTE : GET #IOCB,SECOND Notes This sequence will read the numerical time into the variables, 'HOUR', 'MINUTE' and 'SECOND'. The hour is returned using the 24 hour clock where 0 is midnight, 12 is noon and 15 is 3PM. Attempts to read more characters will return an end of file error 136. The IOCB must be opened for read prior to the execution of these statements (ie. OPEN #1,4,0,"Z:"). No error will occur with this command under SpartaDOS 3.2 since this is an internal function of SpartaDOS 3.2 __________________________ Set Date (DATE) Syntax XIO 37,#IOCB,0,0,"Z:" PUT #IOCB,DAY : PUT #IOCB,MONTH : PUT #IOCB,YEAR Notes This sequence will set the date from the variables, 'DAY', 'MONTH' and 'YEAR'. The year is given as the last two digits of the actual year (ie. 1985 is given as YEAR 85). Attempts to write more characters will return an end of file error 136. The IOCB must be opened for write prior to the execution of these statements (ie. OPEN #1,8,0,"Z:"). An error 139 (NAK will occur if the handler is unable to set the date. The set function is an internal function of SpartaDOS 3.2 __________________________ Set Time (TIME) Syntax XIO 36,#IOCB,0,0,"Z:" PUT #IOCB,HOUR : PUT #IOCB,MINUTE : PUT #IOCB,SECOND Notes This sequence will set the time from the variables, 'HOUR', 'MINUTE' and 'SECOND'. The hour is given using the 24 hour clock where 0 is midnight, 12 is noon and 15 is 3PM. Attempts to write more characters will return an end of file error 136. The IOCB must be opened for write prior to the execution of these statements (ie. OPEN #1,8,0,"Z:"). An error 139 (NAK will occur if the handler is unable to set the time. The set function is an internal function of SpartaDOS 3.2 Some Examples Using the 'Z:' Handler The following program will keep a constant time display: 10 DIM TIME$(13) : POKE 752,1 : REM turn cursor off 20 OPEN #1,4,0,"Z:" 30 XIO 32,#1,0,0,"Z:" 40 INPUT #1,TIME$ 50 POSITION 2,0 60 PRINT TIME$ 70 GOTO 30 Do not be alarmed if the time and date display line seems to stop while running this program. This is because both the TDLINE and the ZHAND routines try to use the SpartaDOS time and date vectors and priority is given to ZHAND rather than the interrupt display handling. If using the 'RTIME8' handler under Atari DOS 2 or SpartaDOS 2.3 and earlier versions, there is no conflict. End of SDCS quotes^^^^^ I would use XIO#33 due to the internal Z: handler being installed at boot up requiring nothing else to be done execept to use it and clear the three variables (HOUR,MINUTE,SECOND) with each read. I would throw the first away like so: GET MINUTE:GET MINUTE use the MINUTE data as you see fit and then do another GET MINUTE and not use it just to keep the GET value at three GETs per XIO#33 invokement. I've never done it myself so no real help beyond stating the obvious that you needs to gets yourself the SDCS manual. SDCS manualSpartdoc.zip Quote Link to comment Share on other sites More sharing options...
4hubbs Posted November 21, 2010 Author Share Posted November 21, 2010 Thanks, i'll give it a try. Perry Quote Link to comment Share on other sites More sharing options...
tschak909 Posted February 27, 2021 Share Posted February 27, 2021 When I read the values of COMTAB+13-18 I only get initial values that were set, they do not update. What is the correct way to ensure these update so they can be read on-going from BASIC? -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted February 28, 2021 Share Posted February 28, 2021 Turns out, I need to thwack VGETTD in order to update those values, fair enough... But when I do the following from inside basic, it crashes, why? ``` PLA ; needed for USR LDA $D301 PHA AND $FE STA $D301 JSR $FFC0 PLA STA $D301 RTS ``` Quote Link to comment Share on other sites More sharing options...
+DjayBee Posted February 28, 2021 Share Posted February 28, 2021 Shouldn't this AND $FE actually be immediate? AND #$FE Quote Link to comment Share on other sites More sharing options...
tschak909 Posted February 28, 2021 Share Posted February 28, 2021 7 minutes ago, DjayBee said: Shouldn't this AND $FE actually be immediate? AND #$FE Yes, that was a typo from me while putting this in this thread. Quote Link to comment Share on other sites More sharing options...
ivop Posted February 28, 2021 Share Posted February 28, 2021 If I'm not mistaken, you cannot rely on RAM vectors underneath the OS ROM. You need to use I_GETTD. You don't even need to switch out the OS for that IIRC. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted February 28, 2021 Share Posted February 28, 2021 (edited) 12 minutes ago, ivop said: If I'm not mistaken, you cannot rely on RAM vectors underneath the OS ROM. You need to use I_GETTD. You don't even need to switch out the OS for that IIRC. Got an example for that? I'm at the end of my rope. I have been banging on this for three $#(@$%@#( days. I can't call my fujinet device to get the time because SIO interferes with concurrent mode, and I can't touch that for THIS SPECIFIC CASE. I JUST...WANT...TO GET AN ACCURATE #@(%$)#@( READING OF THE DAMNED CLOCK FROM BASIC, AND FOR SPACE REASONS, I CAN NOT USE THE DAMNED Z: DEVICE!!!! If you're talking about e.g. using $0703 and reading from $779 to $77D for SpartaDOS X, that doesn't update unless the actual GETTD vector is called. -Thom Edited February 28, 2021 by tschak909 Quote Link to comment Share on other sites More sharing options...
ivop Posted February 28, 2021 Share Posted February 28, 2021 33 minutes ago, tschak909 said: Got an example for that? I'm at the end of my rope. Sorry, no. I'm not that familiar with SpartaDOS. But I read that those under-the-RAM Vxxx vectors were replaced by so called symbols (Spartados speak). Old vectors might or might not be there, just for 3.x compatability. I have no idea how to call a specific "symbol", but I suppose @drac030 or @flashjazzcat can tell you Calling symbol I_GETTD should do the same as calling VGETTD, if I understand correctly. Quote Link to comment Share on other sites More sharing options...
+David_P Posted February 28, 2021 Share Posted February 28, 2021 Reading the SDX 4.49 manual (pages 145-146) it does warn: The vectors are created under the OS ROM to secure some backward compatibility with SD 3.2 and earlier versions. ... Each of these functions contain a jump (JMP) followed by the address of the function. It is good practice to always check for this JMP instead of assuming that the vector is still there. ... The vectors are not used by SDX itself and can be accidentally destroyed by software using the RAM under the OS ROM. So their use implies some trouble. In future versions of SDX they may disappear completely. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 28, 2021 Share Posted February 28, 2021 You're better off using kernel ($07xx) calls under SDX anyway. This of course means more code to handle different DOS versions, but will at least work. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted February 28, 2021 Share Posted February 28, 2021 6 minutes ago, flashjazzcat said: You're better off using kernel ($07xx) calls under SDX anyway. This of course means more code to handle different DOS versions, but will at least work. The issue I ran into with using kernel calls was that the clock doesn't update. -Thom Quote Link to comment Share on other sites More sharing options...
drac030 Posted March 1, 2021 Share Posted March 1, 2021 (edited) If calling the kernel you get no valid time values, then your system has no clock driver installed or your hardware clock is not working. Otherwise, if the rest of the system can read/write clock values, but your program cannot, then there must be a bug in your program, because everything else is reading time not by magic but via the kernel. kernel = $703 device = $761 date = $77b time = $77e lda #$10 sta device ldy #100 ;k_gettd jsr jkernel This is the code (also presented in the User's Manual if I am not mistaken), which is used by Sparta Commander to read current time and present it in the lower right corner of the screen: By the way, I_GETTD does exactly the same thing; also when I_GETTD is present (which means that the clock driver has been loaded), the VGETTD should also be present - unless it was destroyed in meantime by a program which uses RAM under ROM. Edited March 1, 2021 by drac030 3 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 1, 2021 Share Posted March 1, 2021 7 minutes ago, drac030 said: If calling the kernel you get no valid time values, then your system has no clock driver installed or your hardware clock is not working. Otherwise, if the rest of the system can read/write clock values, but your program cannot, then there must be a bug in your program, because everything else is reading time not by magic but via the kernel. kernel = $703 device = $761 date = $77b time = $77e lda #$10 sta device ldy #100 ;k_gettd jsr jkernel This is the code (also presented in the User's Manual if I am not mistaken), which is used by Sparta Commander to read current time and present it in the lower right corner of the screen: By the way, I_GETTD does exactly the same thing; also when I_GETTD is present (which means that the clock driver has been loaded), the VGETTD should also be present - unless it was destroyed in meantime by a program which uses RAM under ROM. Yes, I use that method, and the clock values stay the same as the last invocation of the TIME command, e.g. seconds do not change. But no matter, I've worked around it, I'm using the Z: handler which is chewing a LOT of space I do not have, just so I can read the damned clock consistently. This is aggravating as hell. -Thom Quote Link to comment Share on other sites More sharing options...
drac030 Posted March 1, 2021 Share Posted March 1, 2021 47 minutes ago, tschak909 said: Yes, I use that method, and the clock values stay the same as the last invocation of the TIME command, e.g. seconds do not change. This is impossible or I do not understand what you are telling here. "Z:" is just a wrapper around the call I posted above, it cannot improve thing if the kernel call is not working. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.