Running this under DOSBox reports date and time correctly, e.g. Mon 3-20-2023
A bit more details on the context is needed. What runs where, what's the communication channels between the two, etc.

I noticed that in DOSBox too. My guess is since it can't find the Apple II clock, it's just defaulting to the current DOS clock.

As for technical details about the program, I'm afraid I can't provide them. I have no idea how it communicates with the Apple II side of things.

Since the the app shows date correctly under DOSBox this implies the app itself has no issues with Y2K stuff, and the data is lost in between the app and the clock chip, or something was not correct in the way it is used.

I'm not familiar with that specific card, so could you explain stuff from the user point of view, like where do you launch the app, what's the apple clock chip/card/whatever, do you pass some command line switches to this app, what's the MS-DOS version where you check the date, etc.

Watched the installation videos, explains some stuff.

A quick sanity check, can you set the date to year 2023 using DOS (version ?) commands on PC Transporter? If it doesn't work then there's no point in blaming APLCLOCK

I did a quick look, its looking at hardware IO port 0x2C0, 0x2C1, 0x2c2, 0x2C3. and gets 0xFF invalid results, it then calls dos v1 api 0x21/2B, to set date with those invalid results, which returns an error (invalid date/time), so that dos set datetime fails. It then reads hardware io 0x2C4, 0x2C5, calls dos v1 api 0x21/2D set time, with invalid results again which fails.

it then calls dos v1 0x21/2A for get date, prints it out.
it then calls dos v1 0x21/2c for get time, prints it out.

So, any failure to set the date/time it just reads back the system, which in your case is the default startup of 1980-1-1.

according to ralf brown,

1AH = 2Bh
2CX = year (1980-2099)
3DH = month (1-12)
4DL = day (1-31)

2B is fully y2k compliant.

I suspect the apple system is doing something funky to the date before it gets to the transporter card.

example, in DOS, testing setting CX to 1987 (0x7C3) works, setting it to 2023 (0x7E7) works. no year translation is required, it just has to be between 0x7BC and 0x833. the aplclock.exe set those fine for me. so yeah I think its on the apple side, in what its passing to the IO ports (0x2C0 + 0x2C1).

Can you run this program on transporter, it will read and print the content of ports 0x2c0-0x2c3.
Worth checking if there is something meaningful at all.

vstrakh wrote on 2023-03-20, 16:14:

Can you run this program on transporter, it will read and print the content of ports 0x2c0-0x2c3.

02C0:83
02C1:07
02C2:03
02C3:15

Ok, something is there.
The value in port 2c0-2c1 looks like a year, but 0x783 would mean year 1923.
You didn't mistake B3 for 83? This would make it a year 1971, which is still way below acceptable ranges for ms-dos.

Can you try setting various dates - years/months/days - on Apple, and then rerun this test program to report how it looks from the transporter side.
We need to know the value as you've set it, and values read back by transporter to see the patterns.
Maybe also change something back in order to confirm there is one-to-one mapping between date set and values read.

OK, I tried with three random dates, here's the result:

August 11, 1984: C0,07,08,0B
February 20, 1993: C9,07,02,14
November 9, 2003: 6F,07,0B,09

Ok, the 2003 is read back as 1903. This could explain why ms-dos is rejecting the date.

Play a bit more around year 2000. Set dates below 2000, on 2000 and above 2000 (like current 2023)

I don't know if that's the apple clock not storing the century, or if it's lost in translation between apple and transporter, there is surely some mapping between PC and Apple hardware ports.
Reading the wiki article (https://en.wikipedia.org/wiki/Apple_II_system_clocks) I see the reference to RTC chip DS1216, and it seems it does not store the century.

The possible fix would be to patch the APLCLOCK to check the year against something like 1980, and switch the century when the date read is below it.

ProDOS only displays the last two digits of the year, so I reckon you're correct.

I tried these:

December 3, 1999: CF,07,0C,03
April 30, 2000: 6C,07,04,1E
June 1, 2015: 7B,07,06,01

Ok, the pattern is confirmed, I can patch it up. Stay tuned for updates 😀

That's very kind of you, thank you.

In case you're curious, I'm not just asking about this "for fun" or because I'm too lazy to set time & date by hand. I'm putting together a custom, ready-to-go hard drive image to share with the community. Even with the manual, setting up a hard drive for the PC Transporter is tedious and a touch confusing, too. Added to which, many (most?) Apple II enthusiasts aren't familiar with MS-DOS, making FDISK + FORMAT + installing the OS intimidating. I figure if I provide a pre-made hard disk image for them, more people who own the hardware will start putting it to better use. Worth a try, at least.

Try this app.
The intrusion was pretty minimal. I got lucky, there were 15 free bytes in the last paragraph of the code segment, so the check for the year 1980 was put there.
I did not test it on real DOS though, just checked with debugger that the year passed to the DOS set date function is correct.

Tried it and seems to work fine with 2000s and 1990s years alike. So, great! Thanks again for taking the time out to whip up the patch. This updated program will be quite useful.

For the record, and for curious - the body of the patch looks like this (output of fc /b):

100000012: C2 35    ; 2 lines, EXE header CRC, should be irrelevant though, and could be omitted
200000013: 2F 13
30000056F: B8 E8    ; 3 lines, hijack the execution right after reading out the significant byte of the year
400000570: C2 2F
500000571: 02 1B
6000020A1: 00 81    ;  check the year in stack frame at [bp+16h] against 1980
7000020A2: 00 7E
8000020A3: 00 16
9000020A4: 00 BC
10000020A5: 00 07
11000020A6: 00 73    ; skip if it's 1980 or later
12000020A7: 00 04
13000020A8: 00 83    ; add 100 years to the value in stack frame, because the year wrapped around the 1900
14000020A9: 00 46
15000020AA: 00 16
16000020AB: 00 64
17000020AC: 00 B8    ; perform instruction that was replaced with the call to the patch, and return
18000020AD: 00 C2
19000020AE: 00 02
20000020AF: 00 C3