VOGONS

Different RTC behavior when reading register C

Topic actions

First post, by McCoy

Posted on 
User metadata
Rank Newbie
Rank
Newbie

I'm programming a small game for MS-DOS in ASM using Turbo Assembler. As it's such a nuisance to develop in pure DOS, I'm developing in DosBox. So far, everything has worked perfectly, everything which worked in DosBox also worked in real DOS (v6.22). But I've come to a thing which behaves differently.

I manage the game's timing using the RTC. For that, I activate the RTC and also activate the PIE flag at register B so it will generate an interruption which executes the code pointed at the address stored in the interruption vector 1C0h (70h*4). This is the code of my attention routine for that periodic interruption:

         CLI
         PUSH AX

        ;testing it was PIE who interrupted
        ;***************
        MOV   AL, 0CH      ;we're going to read register C of the RTC
        OUT   070H,AL      ;send it to port 70h
        IN    AL,071H        ;put register C's content into AL
        AND   AL,01000000b    ;test that PF is 1
        JZ   return           ;if it's not, return
        ;***************

        MOV CS:FLAG, 1 ;mark that a RTC cycle has passed.

return:   ;  send EOI to the PICs
         MOV  al, 020H   ; load EOI
         OUT  020H, al   ;send EOI to master PIC
         OUT  0A0H, al   ;send EOI to slave PIC

         POP  AX
         STI
         IRET

That works in DOS. But it freezes the game in DosBox. BUT, if I remove the code which reads the C register for testing PF (de code between the ***********), it works in DosBox just as the original code worked in MS-DOS. But, it doesn't work in MS-DOS (the game freezes exactly as in DosBox whith the complete code). So I think the way the RTC is implemented in DosBox is a little bit different than from a real PC.

My DosBox version is 0.63, so maybe this is fixed in CVS.

I think this is not a very important thing, but I thought it would be good to know, just in case.

Last edited by McCoy on 2006-02-04, 17:02. Edited 3 times in total.

...unless I'm wrong.

Reply 1 of 6, by Qbix

Posted on 
User metadata
Rank DOSBox Author
Rank
DOSBox Author

I think I changed something to that part of the code.
contraction zack needed to see what caused the rtc interrupt.

I would glad if you could test the cvs version of dosbox to see if I fixed in a way that works with your thing as well.

Water flows down the stream
How to ask questions the smart way!

Reply 2 of 6, by McCoy

Posted on 
User metadata
Rank Newbie
Rank
Newbie

Ok, I've just tested it with the 2006-01-08 CVS version which is currently at CVS Compile website (I didn't want to compile it myself 😜 ), and I'm glad of saying that it works with the PF check code, just as in MS-DOS, it doesn't freeze anymore.

But, if I remove the code, it keeps working, it doesn't freeze like in MS-DOS. But I think that's secondary.

Thank you, I think I'll keep using this CVS version to further my development. If I find any other difference between DOS and DosBox I'll post the in the forums, although I see it as unlikely 😀

...unless I'm wrong.

Reply 3 of 6, by McCoy

Posted on 
User metadata
Rank Newbie
Rank
Newbie

Hmmm is the direct serial port access working in the CVS version? My game also has multiplayer between two computers using the serial port. So far, while I was using DosBox 0.63, I was using a virtual serial port driver for connecting 2 dosbox instances through a virtual serial port, thus emulating two computers connected with a serial cable. It worked like a charm. But now that I'm using CVS, in the output of DosBox, it doesn't say "Opening Windows serial port" anymore when you first start DosBox, and the virtual serial port doesn't work (the two DosBox instances doesn't connect). That means the direct serial port feature is not working in CVS version, or am I doing something worng?

...unless I'm wrong.

Reply 4 of 6, by wd

Posted on 
User metadata
Rank DOSBox Author
Rank
DOSBox Author

Ar you using your old dosbox.conf? If so, delete it and create a new
one, and modify the settings accordingly.

Reply 5 of 6, by bugs_bugger

Posted on 
User metadata
Rank Member
Rank
Member

Did you really test your program in native DOS? I once had a problem similiar to your problem. I used the system timer to generate an interrupt. My program ran fine in Windows' DOS-shell but crashed native DOS as well as DOSBOX. My fault was that I used DOS software interrupt calls. These interrupt calls are NOT reentrant (hope I translated right). This means that they cannot reenter into your code. Windows actually seems to have reentrant DOS calls. This means, that DOSBOX is allright and that Windows has some extra features.

PS: Maybe I am talking crap, this was a long time ago and I cant remember exactly.

Reply 6 of 6, by McCoy

Posted on 
User metadata
Rank Newbie
Rank
Newbie
wd wrote:

Ar you using your old dosbox.conf? If so, delete it and create a new
one, and modify the settings accordingly.

Yes, I was using the old one. I did what you said and it worked. Thanks!

About your reply bugs_bugger, yes, I'm using true native good old MS-DOS, the 6.22 version, not a Windows console. Anyway, this small issue is solved in CVS, so time to move to other things 😀

...unless I'm wrong.

Go to top of page Go to top of page
Back to DOSBox Development
Close window
Close window