Path: blue.weeg.uiowa.edu!news.uiowa.edu!hobbes.physics.uiowa.edu!newsrelay.iastate.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!darwin.sura.net!convex!bcm!news.tamu.edu!news.utdallas.edu!corpgate!bnrgate!nott!torn!news.unb.ca!coranto.ucs.mun.ca!nstn.ns.ca!newsflash.concordia.ca!altitude!altitude!not-for-mail From: vandry@CAM.ORG (Phillip Vandry) Newsgroups: comp.sys.apple2.programmer,comp.sys.apple2 Subject: Re: WANTED: ][gs clock info. Date: 24 Jun 1994 22:32:26 -0400 Organization: Communications Accessibles Montreal Lines: 48 Message-ID: <2ug4vq$5bv@altitude.HIP.CAM.ORG> References: X-Newsreader: NN version 6.5.0 #3 (NOV) Xref: blue.weeg.uiowa.edu comp.sys.apple2.programmer:2667 comp.sys.apple2:72919 dalloff@freenet.columbus.oh.us (Dave Althoff) writes: >Okay, I know there is data on this in an Apple tech manual, I'm sure, but >unfortunately, I don't have it. >Does anyone know how to get the date and time out of the IIgs on-board >clock/calander? >Please note the following conditions-- >o BASIC.SYSTEM is not present >o PRODOS is not present >I figure I ought to be able to get that info. from a memory location >(PEEK) or at worst a ROM routine call. Although I'm coding in Applesoft, >I'm not opposed to writing a 6502-code driver (sorry, my assembler doesn't >do 65C816 or even 65C02!). Here's what you do. You will have to have 65816 code no matter how you do it. clc xce rep #$30 pha pha pha pha ldx #$0d03 jsl $e10000 sec xce pla ; A=seconds pla ; A=minutes pla ; A=hour pla ; A=Year-1900 pla ; A=day (0-30) pla ; A=month (0-11) pla pla ; A=weekday (1-7, 1=Sunday) -Phil Newsgroups: comp.sys.apple2.programmer,comp.sys.apple2 Path: blue.weeg.uiowa.edu!news.uiowa.edu!hobbes.physics.uiowa.edu!newsrelay.iastate.edu!newsxfer.itd.umich.edu!gumby!wupost!waikato!comp.vuw.ac.nz!actrix.gen.nz!dempson From: dempson@actrix.gen.nz (David Empson) Subject: Re: WANTED: ][gs clock info. Message-ID: Organization: Actrix Information Exchange References: Date: Sun, 26 Jun 1994 02:36:36 GMT Lines: 117 Xref: blue.weeg.uiowa.edu comp.sys.apple2.programmer:2671 comp.sys.apple2:72933 In article , Dave Althoff wrote: > > Okay, I know there is data on this in an Apple tech manual, I'm sure, but > unfortunately, I don't have it. > > Does anyone know how to get the date and time out of the IIgs on-board > clock/calander? The safest way is to call the routine in the Miscellaneous Toolset which reads the time. There are two calls you can use: one returns the time as a series of bytes (year, month, day, etc.) and the other returns it as a formatted ASCII string, with the fields in the order specified in the control panel. My example code will use the first call (series of bytes). This will require writing a small assembly language routine. You should check that you're running on a IIgs before calling this routine. Here is a routine to test if you're on a IIgs: 0300: 18 SEC 0301: 20 1F FE JSR $FE1F ; IDROUTINE - carry clear if IIgs 0304: A9 FF LDA #$FF 0306: 69 00 ADC #$00 0308: 8D 0F 03 STA $030F 030B: 60 RTS Location $030F (783) will contain $FF (255) if you're on a IIgs, or 0 if not. The routine at $FE1F is called IDROUTINE. It clears carry on before returning on a IIgs, but is just an RTS instruction on other machines. (It also returns information about the IIgs such as the ROM version.) To use this from BASIC, poke it in, CALL 768, then test the value of PEEK(783). The routine is relocatable, apart from the STA instrucion, which could be changed to store the IIgs flag in a zero page location by replacing the 8D 0F 03 with 85 00 (STA $00) for example. You can't avoid using a small machine language routine for this - BASIC cannot detect whether the carry flag was set when a CALL returns. Here is a routine to read the time from the IIgs clock, starting from emulation mode (e.g. called by a BASIC program). 0310: 18 CLC 0311: FB XCE ; Set native mode 0312: C2 30 REP #$30 ; Set 16-bit registers 0314: 48 PHA 0315: 48 PHA 0316: 48 PHA 0317: 48 PHA ; Space for 8 returned bytes 0318: A2 03 0D LDX #$0D03 ; Call number for ReadTimeHex 031B: 22 00 00 E1 JSL $E10000 ; Call the IIgs toolbox 031F: 68 PLA ; Get the seconds and minutes 0320: 8D 40 03 STA $0340 0323: 68 PLA ; Get the hour and year 0324: 8D 42 03 STA $0342 0327: 68 PLA ; Get the date and month 0328: 18 CLC ; (both count from 0) 0329: 69 01 01 ADC #$0101 ; Add 1 to each to compensate 032C: EB XBA ; Swap them so month is first 032D: 8D 44 03 STA $0344 0330: 68 PLA ; Get day of week and dummy byte 0331: EB XBA ; Swap them so day of week is first 0332: 8D 46 03 STA $0346 0335: 38 SEC 0336: FB XCE ; Return to emulation mode 0337: 60 RTS The time will be stored as follows: $0340 (832) Seconds (0 to 59) $0341 (833) Minutes (0 to 59) $0342 (834) Hours (0 to 23) $0343 (835) Year (0 to 139, add 1900 to get year) $0344 (836) Month (1 to 12) $0345 (837) Date (1 to 31) $0346 (838) Day of week (1 to 7, with 1 = Sunday) To use this routine from BASIC, POKE it in, then CALL 784 and use PEEK to read the fields you are interested in. The routine is relocatable, apart from the locations at which it stores the time. You could change all of these to zero page locations if you prefer (the opcode for STA zero page is 85, and don't forget that this is running in 16-bit mode, so each STA will write to two adjacent bytes). > I figure I ought to be able to get that info. from a memory location > (PEEK) or at worst a ROM routine call. Although I'm coding in Applesoft, > I'm not opposed to writing a 6502-code driver (sorry, my assembler doesn't > do 65C816 or even 65C02!). You can't avoid using 65816 code if you want to call the toolbox. Just type in the opcodes and operands, and use the normal PEEK loop to convert it to a DATA statement in BASIC. If you try to disassemble the code on a II+, IIe or IIc, you will get garbage. Don't try calling this routine on any machine other than a IIgs! (The first routine, to detect a IIgs, is fine on any machine of course.) ProDOS-8's IIgs clock driver contains code similar to the above - it calls ReadTimeHex then packs the data into the form that ProDOS expects. In theory, you could do a complicated series of pokes and peeks to read the time directly from the clock chip, but Apple strongly discourages it because if you do anything wrong you might destroy the contents of the battery RAM, and you can also clobber the screen border colour. I agree with Apple in this case - use the toolbox call! -- David Empson dempson@actrix.gen.nz Snail mail: P.O. Box 27-103, Wellington, New Zealand