Need help with RTC on Intel Above Board PS/PC

[dhau]

I couldn't tell which way was right, but did originally have it the other way. I hope it didn't damage the circuit either!

Can you flip the battery, so the - (minus) side is towards the pcb and + (plus) side it visible? And then flip the RTC switch off and on again (SW2-1). May be it's oxidized?

 

[dhau]

Howdy folks. I changed the name of my repository to abovertc. I also took and updated high resolution photos of my board. And finally my assembly program can now reliably detect the board, but nothing else for now.

 

[640KB]

Howdy folks. I changed the name of my repository to abovertc. I also took and updated high resolution photos of my board. And finally my assembly program can now reliably detect the board, but nothing else for now.

Howdy there! Great project and will be a really fun learning experience too! So, I know you're in the middle of that... but if you wanted to take a break and try something on a different direction, I have added support for the Above Board (MSM6242) to GLaTICK. This is the one where all of the RTC support is handled by a BIOS option ROM - so no need for any software, TSRs or memory used. Just need a ROM slot (in option ROM address space) and at least a 2 KiB EPROM/EEPROM. If you want to give it a shot someday, there's a ROM image for the Above Board in the Releases section.

 

[Krille]

Howdy folks. I changed the name of my repository to abovertc. I also took and updated high resolution photos of my board. And finally my assembly program can now reliably detect the board, but nothing else for now.

Lines 311 to 313 in clock.asm;

        cmp    ah,24
        ja    bad_time
; now al is hour from 0 to 23

That's a bug. The ja should be a jae. Also, the comments regarding the rules on how to check for leap year is incorrect.

I would elaborate on that but I'm so tired I'm about to pass out.

 

[Krille]

I would elaborate on that but I'm so tired I'm about to pass out.

Here's an old post where I explained this: https://forum.vcfed.org/index.php?threads/pc-shell-date.63115/post-764874

 

[640KB]

Here's an old post where I explained this: https://forum.vcfed.org/index.php?threads/pc-shell-date.63115/post-764874

Though in the range of usable dates in (most) DOSes (1980-01-01 through 2079-12-31) there are no year % 100 leap year skips so it's not really necessary to implement that rule. It appears that the clock.sys doesn't anyway -- just does a `test mem, 3`. Interestingly the MSM6242B is one of the few that fully implement leap year in hardware so that's nice. That won't affect your driver but at least you don't have to fix the date every 4 years!

Fascinating about that ja bug - wonder how long that went unnoticed in the Intel software, or if it ever was fixed in any later versions (I'd hazard a guess of "no").

 

[dhau]

Is it a bug though? I think hours go from 0 to 23 and minutes/seconds from 0 to 59. There is no hour 24, it's hour 0. Like right after 23:59:59 comes 00:00:00

 

[640KB]

Is it a bug though? I think hours go from 0 to 23 and minutes/seconds from 0 to 59. There is no hour 24, it's hour 0. Like right after 23:59:59 comes 00:00:00

Right, though it is saying to jump if hour is strictly greater than 24, meaning that it wouldn't jump at 24 and would be treated as a valid hour. Seems like either jump above 23 or jump above or equal 24 would be correct, no?

That test is only to trap the case where the clock is on an invalid state. Assuming it is a bug it just wouldn't have likely to be noticed under normal conditions hours since would have never been 24 (at least while the rest of the registers are valid).

The only thing I thought of is that chip uses bit 3 of the hours register as a flag for PM if the chip is in 12 hour mode, but that driver always puts it in 24 hour mode so that really wouldn't make sense either.

 

[dhau]

I can't figure the new fancy quoting. Thanks for explaining the error. Good point!

 

[640KB]

Lines 311 to 313 in clock.asm;

        cmp    ah,24
        ja    bad_time
; now al is hour from 0 to 23

That's a bug. The ja should be a jae. Also, the comments regarding the rules on how to check for leap year is incorrect.

An interesting discovery... in the DOS 6 source (https://github.com/AR1972/astro/blob/91e0bc1f5cd213a6e682294e2f628f3f3d99ffe4/bios/ptime.asm#L577), it also does the same comparison when validating the time:

    cmp    byte ptr bin_date_time+1,24h
    ja     time_error

I couldn't find any authoritative documentation that says the valid range for hour is [0-24] inclusive, but perhaps there were some edge cases where hour 24 == hour 0?

 

[dhau]

I still can't figure out how to use quoting. I highlight a bit, press Quote, and it goes to some mysterious patch in the sky. No idea how to actually get it in my own message... I'll quote a primitive way:

>>> I couldn't find any authoritative documentation that says the valid range for hour is [0-24] inclusive, but perhaps there were some edge cases where hour 24 == hour 0?

Thanks for this finding, so it's best to leave it alone I guess. I'm curious if setting 24:01 is treated as next day from today. Like if it's May 9, 5:15pm, and I use time command and set time to 24:01, will it still show May 9, or will it jump to May 10?

Update: assuming this is from an MSDOS manual: https://home.csulb.edu/~murdock/time.html

hh        0-23 for hours

 

[modem7]

I still can't figure out how to use quoting. I highlight a bit, press Quote, and it goes to some mysterious patch in the sky. No idea how to actually get it in my own message... I'll quote a primitive way:

I highlight the text, then of the Quote/Reply options, I choose Reply.

 

[Krille]

I couldn't find any authoritative documentation that says the valid range for hour is [0-24] inclusive, but perhaps there were some edge cases where hour 24 == hour 0?

You're overthinking this. It's just poorly written code by an incompetent programmer. The same type of bug can be found just below in the bcd_verify procedure. They compare AL and AH with 10 to verify that these registers contain at most 9 and then use ja which means that the jump is only taken if it's 11 or higher. And for good measure they also mask off "erroneous bits" that is somehow magically shifted in. (Before anyone asks; No, there is no such bug in any processor.)

It's actually depressing to read the DOS sources because it's not very efficiently coded. And this is from an era where size efficiency was very important. *sigh*

 

[640KB]

You're overthinking this. It's just poorly written code by an incompetent programmer. The same type of bug can be found just below in the bcd_verify procedure. They compare AL and AH with 10 to verify that these registers contain at most 9 and then use ja which means that the jump is only taken if it's 11 or higher. And for good measure they also mask off "erroneous bits" that is somehow magically shifted in. (Before anyone asks; No, there is no such bug in any processor.)

I suppose I'm just giving them the benefit of the doubt... as if perhaps there's *some* reason (but it's most likely what you said).

It's actually depressing to read the DOS sources because it's not very efficiently coded. And this is from an era where size efficiency was very important. *sigh*

I sadly agree with you there. We always think of DOS as this perfect little thing at the heart of all of our PCs... but really it's one of those "don't ever meet your heros" things.

But... since we're talking about it... how about in the time_verify proc:

    cmp    byte ptr bin_date_time+3,59h
    ja    time_error
    clc
    ret
time_error:
    stc
    ret

Why not just this?

    cmp    byte ptr bin_date_time+3,59h
time_error:
    cmc
    ret

4 bytes and a branch saved. Let's also pretend they're not comparing a BCD number, since here a value like 4fh minutes would be considered valid.

And my second favorite of the day: https://github.com/AR1972/astro/blo...3f3d99ffe4/bios/msinit.asm#LL3605C12-L3605C12 . This one apparently so hated that it even contained a comment, seemingly blaming "cas".

    mov    ah,2            ;read real time clock
    int    1ah            ;call rom-bios routine
    cmp    cx,0            ; cas - arrrrgh!
    jnz    clock_present
    cmp    dx,0
    jnz    clock_present

How about just `or cx, dx` instead? 8 bytes and a branch saved there... it all adds up, especially on a PC where every K of low memory is precious.

Okay... done complaining. Back to the topic.

 

[Krille]

But... since we're talking about it... how about in the time_verify proc:

    cmp    byte ptr bin_date_time+3,59h
    ja    time_error
    clc
    ret
time_error:
    stc
    ret

Why not just this?

    cmp    byte ptr bin_date_time+3,59h
time_error:
    cmc
    ret

I had the same idea. You'd have to change it to compare with 5Ah though.

And my second favorite of the day: https://github.com/AR1972/astro/blo...3f3d99ffe4/bios/msinit.asm#LL3605C12-L3605C12 . This one apparently so hated that it even contained a comment, seemingly blaming "cas".

    mov    ah,2            ;read real time clock
    int    1ah            ;call rom-bios routine
    cmp    cx,0            ; cas - arrrrgh!
    jnz    clock_present
    cmp    dx,0
    jnz    clock_present

How about just `or cx, dx` instead? 8 bytes and a branch saved there... it all adds up, especially on a PC where every K of low memory is precious.

Okay... done complaining. Back to the topic.

"cas" appears to be one of the programmers. There are several comments in the code with that signature. I don't see the value of that particular comment though. "Arrrrgh" doesn't really convey that much information. Unless you're a pirate, I guess.

I have this recurring fantasy where Microsoft releases the source for DOS 6.22 just like they did with DOS 2.x. Then we could really show them how it should have been done.

 

[640KB]

"cas" appears to be one of the programmers. There are several comments in the code with that signature. I don't see the value of that particular comment though. "Arrrrgh" doesn't really convey that much information. Unless you're a pirate, I guess.

Does viewing the leaked source count as being a pirate? (lol) Looking through it, it seems like "cas" was actually documenting things they found questionable, rather than being blamed for them by someone else. Though as you pointed out, those comments are fairly unhelpful... examples: "cas - bad code!", "cas -- inefficient!" and the classic "cas - holy sh*t!!! CODE!". I could only imagine working at MS maintaining DOS at that time was probably not a very thankful experience... there were probably 20 managers for every developer and any proposed change to a single line of code probably required committee review and was unlikely to be blessed (so snarky comments were the only way to be heard). I actually did try some searching to see if we can find out who "cas" was but haven't turned up anything yet. cas, are you reading this forum?

Clearly, they were afraid to change anything they didn't absolutely have to, as the code base is a patchwork of very different programming styles, formatting, case, indentation, tabs v. spaces, etc. IF they had a style guide, I'd *love* to read it! It does not appear that this code has changed in any significant way since DOS 3.3 (other than the "arrrgh" comment). Though tragically IBM did mess with it in PC-DOS 7+ and introduced a V20 bug in this very code section.

I have this recurring fantasy where Microsoft releases the source for DOS 6.22 just like they did with DOS 2.x. Then we could really show them how it should have been done.

I tend to think it's unlikely they would release the source in its completeness any time soon, especially with all of the Symantec stuff in it (DEFRAG, etc). I have a suspicion that they do still sell it in an off-the-record way to large corporate and/or government customers who still use it and will pay handsomely for support. They probably know just as well what a mess it was anyway, so why suffer the embarrassment. And I mean, they couldn't be bothered to release 2.0 in its completeness (okay, I shouldn't complain, it was cool that they did it at all).

Last rant... so much work is done in memory with direct addressing, leading to those many 4-5 byte instructions there. Going back to that `bcd_verify` proc... using indirect+disp there alone would save you at least 3 bytes. Why would they do a `mov al,[bx] / inc bx` when lodsb would do the same? Also... `dec cx / jnz bv_loop` ... what? And yes, the `and ah, 0fh` after the four `shr`'s is quite perplexing indeed.

I do wonder if the source code could be golfed and optimized just how much speed and memory savings could be found. And I get it... this was their bread and butter at the time so why mess with a stable and proven code base. But... it seems like they got a bit complacent and just expected that everyone would just load things up in high/UMA so "who cares" about the size, right?

 

[maxtherabbit]

I do wonder if the source code could be golfed and optimized just how much speed and memory savings could be found.

That was essentially Vernon's approach in PC-D7. V20 RTC bug notwithstanding, I think he did a pretty good job.

 

[dhau]

Hi folks, I updated clock.asm with the hour validation bug fix from Krille. It is enabled if you pass /DTWEAK=1 to masm.exe.

If TWEAK is enabled, I also remove enough dead code to save 30 bytes, so tweaked driver should take 1250 bytes of conventional memory as opposed to 1280 for original driver.

If TWEAK is disabled, binary is same as Intel original driver.

I've attached tweaked driver to this post. Please test it if you can. Please report any issues or let me know if it works fine for you.

 

[dhau]

@640KB provided patches with more clock.sys file size optimizations: the size is now reduced from 2521 to 2301 bytes with no changes to functionality, a considerable saving for XT class PC. Testers are always welcome.