Hi Eric/Rugxulo, Thanks for your input!
I did read a long time ago the power.txt that Mike wrote, but had forgotten it since. After looking again, I saw the note about INT28h. After a few tests, I see that it's actually the best way, since it works on DOSBox, DOSemu, and VirtualBox making them all running cool (ie. not at 100% cpu). So I added it to Zmiy, and made the default energy-saving method. I still haven't figured out any simple way of performing time polling with sub-55ms precision, so I will probably leave it as is (that's not a very big deal anyway). I'm suprised though, that there is well-known microsecond-grade sleep function provided by the BIOS (int15h AH=86h), but no sibling function to just retrieve a timer with such precision. The 'reprogramming the PIT' subject is interesting, but I fear I won't have enough time to really figure all the implications to do it right. About VGA: Yes indeed, Zmiy requires a VGA display for 80x50. On EGA, it will initialize the screen into 80x43, which will make the game hardly playable. I am thinking about converting Zmiy to 80x43 instead, then adding some VGA-detection routing to force it into 80x43. Will probably do this in some future release. cheers, Mateusz On 07/31/2013 12:13 AM, Rugxulo wrote: > Hi, > > 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 >> >> http://sourceforge.net/projects/zmiy > > 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 > much). > > 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: > > http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/libc/pc_hw/timer/uclock.c?rev=1.5 > > 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.) > > https://code.google.com/p/mtcp/ > > And here's some more obligatory links: > > http://www.bttr-software.de/forum/board_entry.php?id=10006#p10397 > http://www.delorie.com/djgpp/doc/rbinter/id/33/15.html > http://www.delorie.com/djgpp/doc/libc/libc_279.html > http://www.delorie.com/djgpp/doc/rbinter/id/47/45.html > >> 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. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
