Geneve clock issues

[mizapf]

Users of real and emulated Geneves should be aware that we have a calendar issue since last Sunday. I first thought I had a regressing in MAME when booting the Geneve, and it asked for a new date, but my real Geneve showed the same behavior.

 

The day-of-week is wrong for dates after July 16, 2016. Tim (Insane Multitasker) has been informed by me and is already tracking the problem.

[Shift838]

i noticed this today as well. Good to hear you and Tim are on top of it.

[+Ksarul]

Interesting. Shades of Y2K. Here is a whole list of future computer time issues. At least we have more than 20 years to solve the next ones. . .

[+Schmitzi]

I am a little bit anxious and nervous with my FAT-formatted systems, concerning the Year-2108 problem

[+InsaneMultitasker]

The day of week display problem spans MDOS (Geneve OS) versions 2.21 to present.

 

Some quick testing showed that one year later, 7-24-2017, the day of week displays correctly.

 

Further review shows erroneous days of the week from 7-16-2016 to 7-29-2016, a 2-week span. A quick review of the clock code did not reveal a solution though the error appears to reside in the Julian calendar calculations. I don't know if this error is limited to the above 2 weeks, or if it will occur at later dates.

 

Day of week does not directly impact the file system timestamps so the most visible place you'll see this is the DATE setting and display.

[Shift838]

i actually noticed something very similar a few months back on my Triple-Tech card as well on my real TI system.

 

Good thing my BBS does not rely on the day of the week setting, but more of MM-DD-YY.

[+InsaneMultitasker]

I tracked the error to the MDOS routine responsible for converting a date from DD/MM/YYYY to its equivalent Julian number. (file L9\GENERALS)

 

July 17,2016 is converted to a Julian value of 2392051, which represents February 10, 1837. There certainly were no Myarc cards that long ago. The next 13 days continue in sequence.

 

July 16th,2016 is Julian 0x00257FF2. July 30th,2016 is Julian 0x00258000. The dates in between calculate from 0x00247FF3 to 0x00247FFF. I suspect a boundary calculation error as the LSWord approaches 0x8000.

 

When setting the date from the OS prompt, the Julian calculation's only function is to determine the day of week. So for now, this is a minimal impact bug which may disappear in three days. I'll see what else I can dig up as time permits.

 

Edit: typo in the erroneous dates. MSWord changed from 0023 to 0024

Edited July 27, 2016 by InsaneMultitasker

[+InsaneMultitasker]

The time of day bug is the result of an improper use (understanding?) of the Overflow bit during a Subtraction operation.

 

One of the offending dates, July 25th 2016, is represented as a 32bit word, 0x00258008, where R6=0x0025 and R7=0x8008. Within the MDOS algorithm a final leap year adjustment is stored in R1, calculated this year as 0x000D (13d). When the correction is applied to obtain the final Julian value using the following code:

 

 

S R1,R7  (Subtract R1 from R7, results in R7.
JNO  NEXT
DEC  R6

...an overflow occurs. Overflow detection works by looking at the MSBit of both operands as well as comparing the MSBit of the result and destination operand. When compared, the MSBit of the destination is set (1) and the MSBit of the result is reset (0). This results in the overflow bit being set, which in turn causes execution of the DEC R6 instruction. Remember, R6 is the Most Significant Word of the 32 bit Julian value, meaning the error now subtracted 65K from the Julian value! This is why for these 13 days in July, the Julian values are calculated from 0x00247FF3 to 0x00247FFF, and our day of week is derived from the year 1837.

 

I have noted the error however, since the next opportunity to experience this time warp will happen sometime in April 2106, some 89+ years from now, I'm not overly concerned...

[Tursi]

I have noted the error however, since the next opportunity to experience this time warp will happen sometime in April 2106, some 89+ years from now, I'm not overly concerned...

 

All right, but if you don't have it fixed by then we're going to call you and wake you up!

[mizapf]

I have noted the error however, since the next opportunity to experience this time warp will happen sometime in April 2106, some 89+ years from now, I'm not overly concerned...

 

I actually planned to live for at least another 300 years, because I'm pretty much concerned how the current national and global challenges will be solved.

 

Good work, Tim. These OV handling errors are pretty ugly to track. This reminds me of an error in my TMS9900 implementation in MESS that also had to do with OV and C, which became obvious only in Microsurgeon, where the first four patients almost immediately died.

[Opry99er]

This is the coolest thing I've read all day.

[+Schmitzi]

I recognized this "Wrong day of the week"-behaviour last year (!), on my PFM-Geneve.

But I did not care, because I thought "OK, so it is"

I have John G. Schroeder´s BIOS v3.0

 

But I have to re-check again for that, but I am almost sure about.....

[atrax27407]

On another note, the clock on my BWG Card works fine.

[+InsaneMultitasker]

I recognized this "Wrong day of the week"-behaviour last year (!), on my PFM-Geneve.

But I did not care, because I thought "OK, so it is"

I have John G. Schroeder´s BIOS v3.0

 

But I have to re-check again for that, but I am almost sure about.....

Were you impatient, using your Geneve in June while setting the date to July?

 

If your Geneve has the PFM512 revision (single 512K Atmel 29c040) you have the option of updating the BIOS using the PFM files included with the Geneve OS.

[+InsaneMultitasker]

 

I actually planned to live for at least another 300 years, because I'm pretty much concerned how the current national and global challenges will be solved.

 

 

 

All right, but if you don't have it fixed by then we're going to call you and wake you up!

We may need to ask Omega to add a 9900-based Cryogenic freezer to the quarterly project list 'just in case'. It would be the ultimate test of 'debugging in my sleep'.

[+Schmitzi]

Were you impatient, using your Geneve in June while setting the date to July?

 

If your Geneve has the PFM512 revision (single 512K Atmel 29c040) you have the option of updating the BIOS using the PFM files included with the Geneve OS.

 

♫ if only I could... ♪♫

 

this is my babe:

 

 

 

HiRes:

 

[+InsaneMultitasker]

schmitzi, on 28 Jul 2016 - 6:26 PM, said:

 

♫ if only I could... ♪♫

 

this is my babe:

 

Oh yea two 128K chips. Well, you can still install an updated MDOS into the PFM device using the on-board menu. If you have a SCSI in the system, you will need to hunt down my SCSISPLIt and SCSI4PFM programs - I think they are on the MDOS v4.00 release disk. So all is not lost !

[+Schmitzi]

Sadly, I have no SCSI. I could mount an HFDC, or my IDE-Controller.

So, is it possible to go higher than MDOS5.0 ? Would be nice

But I cannot really use the machine, as i only have an AV-Video-cable (composite),

on the 10" TI-Monitor, and this does not work for more than 5 minutes on my eyes.

Any other cabling (ie Scart or RGB for my 19" Samsung 910er) failed

(because of my soldering skills or whatever). So I gave up on this machine a year ago.

 

Ah, I have some more pics (no login needed):

 

https://www.facebook.com/326551627536797/photos/?tab=album&album_id=350516061807020

 

https://www.facebook.com/326551627536797/photos/?tab=album&album_id=350914528433840

 

https://www.facebook.com/326551627536797/photos/?tab=album&album_id=352728778252415

[+InsaneMultitasker]

Sadly, I have no SCSI. I could mount an HFDC, or my IDE-Controller.

So, is it possible to go higher than MDOS5.0 ? Would be nice

But I cannot really use the machine, as i only have an AV-Video-cable (composite),

 

Yes, you can go higher The OS size increased from 120K to 128K when SCSI support was incorporated into SYSTEM/SYS. The SCSI DSR for the Geneve resides in the last 8K of the file. The older PFM devices only have 120K available for the OS file. SCSI4PFM/SCSISPLIT splits the last 8K into an executable that loads the SCSI DSR into memory. The only caveat is you must load this file before accessing the SCSI device. The HFDC driver resides in the 120K portion, so it does not have the same 'issue'.