VOGONS

Common searches


Reply 20 of 35, by jal

User metadata
Rank Oldbie
Rank
Oldbie
wd wrote:
Don't know, at the moment the dos time/bios time/cmos time/ticks are consistent, but i'm not sure in what way they are really de […]
Show full quote

Don't know, at the moment the dos time/bios time/cmos time/ticks
are consistent, but i'm not sure in what way they are really dependent
under dos. Maybe the file create times might be a problem (afair
dosbox leaves the current system time set on them).

FCBwrite uses the dos structure's date, I'll change that (probably remove de date-field), otherwise I couldn't find anything. I tested the CMOS clock, it works now, I'll have to check BIOS RTC support (int 1ah), and have DOS int 21h call the BIOS functions. Possibly finished this evening, but more likely next week.

JAL

Reply 21 of 35, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

> otherwise I couldn't find anything.

Well the regular dos file creation functions use fopen on the host level,
and for querying the time (findfirst i think) stat returns that time/date.
If the dos time/date is set (in dosbox) to a different value, this should
maybe modified accordingly. Packers/unpackers use that stuff iirc.

Reply 22 of 35, by jal

User metadata
Rank Oldbie
Rank
Oldbie
wd wrote:
> otherwise I couldn't find anything. […]
Show full quote

> otherwise I couldn't find anything.

Well the regular dos file creation functions use fopen on the host level,
and for querying the time (findfirst i think) stat returns that time/date.
If the dos time/date is set (in dosbox) to a different value, this should
maybe modified accordingly. Packers/unpackers use that stuff iirc.

Yes, I agree that may remain problematic, I'll have to look into that. Otherwise, the CMOS and BIOS are done now (a few tests to be performed yet). CMOS RTC is now almost completely emulated, including correct am/pm and non-BCD modes, 'lock' bit (bit 7 of statreg B) and 'update in progress' bit (bit 7 of statreg A). Both reading/writing possible, after writing an offset is kept from UTC to determine 'DOSbox time'.

JAL

Reply 23 of 35, by jal

User metadata
Rank Oldbie
Rank
Oldbie

Ok, time for a small update. I sent Qbix my alterations to bios.cpp, dos.cpp and cmos.cpp to check. I tested them, though not as extensively as I would like, and everything seems to function fine. I did not alter any routines that use the dos.date field (FCB routines), that's for another exercise. It would be nice to have commandline date/time functions, but unfortunately I have no time to implement that. I included the latest version of the above mentioned files. They are based on the 0.65 sources, not the CVS.

JAL

Attachments

  • Filename
    dosbox.zip
    File size
    22.42 KiB
    Downloads
    120 downloads
    File license
    Fair use/fair dealing exception

Reply 24 of 35, by ykhwong

User metadata
Rank Oldbie
Rank
Oldbie

This really slow downs a software that has a clock.
(for example, using a IMS/OPL player)

static bool RtcUpdateDone ()
{
while ((ReadCmosByte(0x0a) & 0x80) != 0);
return true; // cannot fail in DOSbox
}

Reply 25 of 35, by jal

User metadata
Rank Oldbie
Rank
Oldbie
ykhwong wrote:
This really slow downs a software that has a clock. (for example, using a IMS/OPL player) […]
Show full quote

This really slow downs a software that has a clock.
(for example, using a IMS/OPL player)

static bool RtcUpdateDone ()
{
while ((ReadCmosByte(0x0a) & 0x80) != 0);
return true; // cannot fail in DOSbox
}

I'm not entirely sure whether I understand what you mean, can you elaborate a bit more? Do you have specific software in mind?

JAL

Reply 26 of 35, by ykhwong

User metadata
Rank Oldbie
Rank
Oldbie

I attached a midi software ocplay. Another one is a patch that I applied for cvs .
Run play/ocp10/ocplay.exe in dosbox then move your mouse cursor or play midi file. Mouse cursor stops moving, and playing sound is stuttering every second.

Attachments

  • Filename
    date.diff
    File size
    21.9 KiB
    Downloads
    105 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    play.zip
    File size
    275.84 KiB
    Downloads
    91 downloads
    File license
    Fair use/fair dealing exception
Last edited by ykhwong on 2006-10-05, 14:56. Edited 1 time in total.

Reply 27 of 35, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Maybe like this? (didn't test it though)

static bool RtcUpdateDone ()
{
while ((ReadCmosByte(0x0a) & 0x80) != 0) CALLBACK_Idle();
return true; // cannot fail in DOSbox
}

1+1=10

Reply 29 of 35, by jal

User metadata
Rank Oldbie
Rank
Oldbie
ykhwong wrote:

That fixes the bug. I will do more tests.
[EDIT] There's no problem playing song,
but the song graph is being drawn intermittently.

Thank you for looking at it. I'll await Qbix final verdict 😀.

JAL

Reply 32 of 35, by jal

User metadata
Rank Oldbie
Rank
Oldbie
wd wrote:

nope

Heh, I almost forgot I've made that one. My only contribution to DOSbox, never to be incorporated 😀. O well, I had fun making it.

JAL

Reply 33 of 35, by SocietalEclipse

User metadata
Rank Newbie
Rank
Newbie

Syndicate Wars:

Research progress is accomplished through two time measurements: 1. The amount of time taken to accomplish a mission and 2. Your […]
Show full quote

Research progress is accomplished through two time measurements:
1. The amount of time taken to accomplish a mission and
2. Your computer's internal clock.
That is, once your computer's internal clock strikes 12 o'clock, a new day begins and research progresses.

There you have it. Games need it too. 😜

Reply 35 of 35, by nyh

User metadata
Rank Newbie
Rank
Newbie
jal wrote:

Wouldn't it be a lot easier to just read the system time (with e.g. time()), and convert that to the right value (with e.g. localtime()) at the int 21h call, not using the BIOS values? The fact that 'real' DOS does it this way shouldn't stop DOSbox from doing a better job?

I think so. I was running an old MS DOS punch clock program on my Linux server using Dosemu. I switched to FreeBSD and had the problem Dosemu isn't ported to FreeBSD.

DosBox runs fine but has the date problem. I patched dos.cpp to return the server time:

        case 0x2a:              /* Get System Date */
{
struct timeval tv;
struct timezone tz;
struct tm *loctime;

gettimeofday(&tv, &tz);
loctime=localtime(&tv.tv_sec);

reg_al=loctime->tm_wday;
reg_cx=1900+loctime->tm_year;
reg_dh=1+loctime->tm_mon;
reg_dl=loctime->tm_mday;

// int a = (14 - dos.date.month)/12;
// int y = dos.date.year - a;
// int m = dos.date.month + 12*a - 2;
// reg_al=(dos.date.day+y+(y/4)-(y/100)+(y/400)+(31*m)/12) % 7;
// reg_cx=dos.date.year;
// reg_dh=dos.date.month;
// reg_dl=dos.date.day;
}

and

        case 0x2c:              /* Get System Time */
//TODO Get time through bios calls date is fixed
{
struct timeval tv;
struct timezone tz;
struct tm *loctime;

gettimeofday(&tv, &tz);
loctime=localtime(&tv.tv_sec);

reg_ch=(Bit8u)(loctime->tm_hour);
reg_cl=(Bit8u)(loctime->tm_min);
reg_dh=(Bit8u)(loctime->tm_sec);
reg_dl=(Bit8u)(tv.tv_usec/10000);
/* Calculate how many miliseconds have passed */
// Bitu ticks=5*mem_readd(BIOS_TIMER);
// ticks = ((ticks / 59659u) << 16) + ((ticks % 59659u) << 16) / 59659u;
// Bitu seconds=(ticks/100);
// reg_ch=(Bit8u)(seconds/3600);
// reg_cl=(Bit8u)((seconds % 3600)/60);
// reg_dh=(Bit8u)(seconds % 60);
// reg_dl=(Bit8u)(ticks % 100);
}

Now my application runs fine. I hope the code is useful for someone else too.

Nyh