On Mon, Jul 29, 2013 at 2:36 PM, Mateusz Viste <mate...@viste-family.net> wrote:
> I had a few minutes of free time lately and felt the inexplicable need
> to write a Nibbles clone
> I called it 'Zmiy'. It's written in C89, compiled with Turbo C, and, as
> usual, released under GNU GPL 3
Good to know.
> ---- Boring LONG tech stuff below // you might want to ignore this -----
> During the development, I encountered an interesting problem: timing.
> It's probably obvious stuff to most people here, but I actually never
> really played with game-oriented timing in DOS. I implemented inside
> zmyi 3 different timing mechanisms (configurable via command line).
I've not written a lot of low-level code, so my understanding of such
things is limited to what I can glean from online forums (i.e. not
What is the full list of environments you're trying to run under? Just
everything you can get your hands on? :-)
Apparently: native DOS, VirtualBox, DOSEMU, DOSBox, NTVDM
> The first (best so far) is checking the time in a loop (at 18,2Hz), and
> performing an int15h AX=5305h at every iteration to notify APM about
> available CPU.
> The second is about calling the BIOS function int15h AH=86h.
> The third one is about using the Turbo C 'delay' function (supposed to
> provide a millisecond-grade sleep).
So you want sufficiently smooth speed but also power savings (not hog cpu)?
> I was also wondering about issuing HLT instructions, but it doesn't look
> like a nice solution to me, since it would require to add some asm into
> my C project, and it wouldn't work on many platforms (Windows...), and I
> feel it's not the application's job to issue HLT, this should be taken
> care of by APM, or the BIOS, or whatever.. But not the application.
DOSBox has adjustable cycles (and core and frameskip). DOSEMU, I'm not
sure exactly what it's called, but it has some hogging threshold
setting in some tool somewhere. Other environments may let you cap
your cpu use too (e.g. VirtualBox: System Processor, Execution Cap or
perhaps Windows: Task Manager, Set Priority). But usually I just leave
things as default (since lacking much reason to delve further).
> Any suggestion about some neat (and simple, if possible) usleep()-like
> mechanism that I could use? My int15h AH=86h method is sleeping very
> nicely (with high resolution), but it makes the keyboard laggy, so I
> wonder if it's the best path.. I've read a bit about reprogramming the
> PIT, but it sounds a bit scary, and probably not allowed by Windows
> anyway (I'd like to keep zmyi 8086-compatible, but still playable on
> other platforms).
I consider Windows almost a lost cause. XP at least somewhat works
(barely), but outside of that (Vista, 7, 8) it's probably not (IMHO!)
worth even trying.
int 15h, 86h is limited under modern NT-based Windows, IIRC, something
about not updating as frequently as you'd want. You'd have to check
DJGPP libc sources, I forget the details:
As for just not wasting cycles, you may? wish to try the equivalent of
__dpmi_yield, which is basically just calling int 2Fh, 1680h. N.B. You
must call this via int 31h, 300h in order to work properly under
WinXP. And of course check to make sure the vector of int 2Fh isn't
zero first (before testing for DPMI before actually calling this). Not
supported by every DPMI environment but helpful to those that do. (I
think even mTCP uses this nowadays, see POWER.TXT.)
And here's some more obligatory links:
> BTW, if you test Zmiy on DOSBox, you will notice that the palette is
> wrong. I have no idea why - seems that DOSBox initializes a different
> palette on 80x50 than what a real PC do.
Just a silly question, if this is using 80x50, doesn't that mean it
requires VGA? Do you test for that before using it? Just saying, not
all 8086 machines had a VGA. ;-)
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
Freedos-user mailing list