Re: [Freedos-user] OpenWatcom packaging (was: FreeDOS FDNPKG install CD)
I don't know OW well since I never used it, so I am not very well aware of what parts it needs exactly, but maybe a nice solution would be to create multiple packages, where every package would contain a part of OW - then the end user could download only what he wants/needs/uses. That's more or less what I did when packaging DJGPP (although for DJGPP it was much easier, because DJGPP provides some 'package segmentation' already): djgpp - DJGPP environnement djgpp-bn - DJGPP binutils: linker, assembler, etc... djgpp-bs - DJGPP Bison (a parser generator that is compatible with YACC) djgpp-db - DJGPP Debugger (GDB) djgpp-fq - DJGPP FAQ documentation djgpp-fx - DJGPP Flex (fast lexical analyzer generator) djgpp-gc - DJGPP GCC (C compiler) djgpp-gp - DJGPP GPP (C++ compiler) djgpp-mk - DJGPP make djgpp-ob - DJGPP Objective-C compiler djgpp-rh - DJGPP RHIDE editor djgpp-tx - DJGPP Texinfo (info file viewer) Anyway, maybe a similar method could be applied to OW, so users who wants it all could just install all packages, and users who need only a minimalistic compiler would just get the equivalent of Rugxulo's 7z file. Mateusz On 07/28/2013 11:35 PM, Rugxulo wrote: Hi, On Sun, Jul 28, 2013 at 12:19 PM, Bernd Blaauw bbla...@home.nl wrote: Rugxulo schreef op 28-7-2013 0:55: 1.9 has been latest stable for three years now. I haven't been following their latest progress, so I don't really know much about it. 1.5 was listed in above textfile, guess that's the last one Arkady made. Thought you had a more recent archive for v1.8 or so. Officially, they stopped including separate .ZIPs after 1.3, so everything after that had to be done manually. Most people never complained, AFAIK. A quick check shows that Arkady did at least package up 1.7.1 for us: http://www.openwatcom.org/index.php/Alternative_Open_Watcom_distribution Though I did always think having to download 80 MB .EXE (.ZIP'd with sfx installer, ~200 MB unpacked) just for the DOS-only portion was overkill, hence I did make a DOS host/target only .7z file, which was only 7 MB (or 45 MB unpacked). Though if all you wanted was bare bones C (and no helpfiles, etc), even this could be a bit much. http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/c/openwatcom/1.9/open-watcom-c-dos-1.9.7z -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] OpenWatcom packaging (was: FreeDOS FDNPKG install CD)
Hi, On Mon, Jul 29, 2013 at 2:30 AM, Mateusz Viste mate...@viste-family.net wrote: maybe a nice solution would be to create multiple packages, where every package would contain a part of OW - then the end user could download only what he wants/needs/uses. Well, I figured a full DOS only download was better than full everything already. Trying to split into smaller pieces might be nice, but it's quite tedious. It's hard to decide what is best for everyone, so usually people just throw everything and the kitchen sink in there. Sure, you can be ultra minimal in some instances, but most people want full C++ support, help files, debugger, vi editor, various DOS extenders, and libraries for all the various memory models. That's more or less what I did when packaging DJGPP (although for DJGPP it was much easier, because DJGPP provides some 'package segmentation' already): Just a few comments: 1). At minimum, you must always have the *.h headers and libc + libm (djdev*), GCC proper (gcc*), and BinUtils (bnu*). There's very little possible use for anything less than that. 2). RHIDE is old (IIRC, built only with G++ 3.3.6) and won't be further updated, but it does (mostly) work well. It has its own debugger, RHGDB, based upon older GDB (6.3, in Andris' last 1.5c snapshot, IIRC). But that relies on COFF debug info, which is somewhat limited and even broken in later (4.5.x or newer) GCC releases. So in that case, GDB is better (though less friendly to use, even with --tui). RHIDE is also basically SETEDIT editor, thus it has built-in a Info reader, so you don't also need Texinfo. 3). Bison and Flex are rarely needed. I don't ever use them (and don't understand their syntax anyways). Some few projects need them to build from sources, but not many do. 4). Make and GPP speak for themselves. A lot of projects need these, e.g. p7zip, UPX, Dungeon Crawl, etc. Well, even latest GCC 4.8.x is built with G++ nowadays. 5). The FAQ is ridiculously useful but quite old by now. It's lacking in some areas because of that. Honestly, a lot of that has to do with various workarounds in different environments, which seems to be a stumbling block for many users. That's a bottomless pit, almost, because nobody can stabilize on one environment. (NTVDM isn't as useful nor widespread as it used to be, and less emphasis has been made on building complex packages from atop other environments.) 6). Objective C ... I don't grok it, it seems interesting, but quite honestly I'm not sure if (barely) anybody has ever even properly tested this under DJGPP. The few projects I've seen that use this language rely heavily on third-party libs (GNUstep or similar), which I'm not sure will work (well, if at all) on DJGPP. At least, I can't name one public project that ever used this for DJGPP. 7). As far as dependencies go, GNU software (and thus many Linux projects) assume a lot more than just these. Just off the top of my head: m4, tar + gzip, sed, awk, grep, bash, pdcurses, diff + patch, coreutils (file + text + shell utils), etc. It's almost endless! :-) Anyway, maybe a similar method could be applied to OW, so users who wants it all could just install all packages, and users who need only a minimalistic compiler would just get the equivalent of Rugxulo's 7z file. The existing .7z is a full DOS install with everything DOS-related. It could be slimmed if someone didn't want all the fluff, e.g only wanted to recompile the FreeDOS kernel. I made a small .7z like that in the past, and it would fit on a floppy (so ~1.4 MB when compressed). But I'm not sure how many people would find that useful. -- 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=49501711iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Jack Ellis' drivers (UIDE, etc.) 2013-07-28
Jack Ellis has released a minor update to his drivers: UHDD/UIDE save 600 bytes of runtime (HMA) space by omitting their binary-search buffer and related code (they did not improve speed very much).Their /F switch is now deleted, and UHDD/UIDE will always set 64K blocks with a cache of 80-MB+, for faster speed if using protected-mode. Minor UDVD2 size reductions. XMGR/RDISK unchanged, re-dated only. I've updated the online .LSM for UIDE and XMGR and also mirrored this to iBiblio: http://www.freedos.org/software/?prog=uide http://www.freedos.org/software/?prog=xmgr http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/cdrom/uide/ -- 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=49501711iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Zmiy - a snake-like game for 8086 (like Nibbles)
Hi all, I had a few minutes of free time lately and felt the inexplicable need to write a Nibbles clone (remember this game that was shipped with QBasic ages ago?). I called it 'Zmiy'. It's written in C89, compiled with Turbo C, and, as usual, released under GNU GPL 3 (yes Rugxulo, I *am* aware that the license file is twice as big as the whole source code) ;-) Here it is - I hope it will provide some 5-minutes fun to other oldish-oriented geeks like me. http://sourceforge.net/projects/zmiy 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). 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. This works very well on a real machine, as well as on VirtualBox (with and without FDAPM). The CPU usage is very low. Surprisingly, under both DOSEmu and DOSBox the CPU usage is very high. I guess they don't support the APM v1.0 interface... The second is about calling the BIOS function int15h AH=86h. This works okay on a real machine, but makes keyboard controls under DOSemy laggy, and don't work at all with DOSBox. DOSBox keeps crying this: Illegal read from 5820585e, CS:IP f000:11c4 The third one is about using the Turbo C 'delay' function (supposed to provide a millisecond-grade sleep). I don't know what is behind this, but it makes CPU usage very high. It works fine under DOSBox (apart form the burning CPU), but not under DOSemu (don't sleep at all, which makes it impossible to play, unless your name is Barry Allen). 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. Anybody had such problems too? Is there a 'silver bullet' for such timekeeping gaming needs under DOS *and* keeping 8086 compatibility? Another issue I had (still have, in fact) is the timer resolution. The resolution of my APM-aware sleeping routines is of ~55ms (18,2Hz). This makes the game not as smooth as I'd like. 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). 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. Mateusz -- 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=49501711iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Zmiy - a snake-like game for 8086 (like Nibbles)
Hi :-) I had a few minutes of free time lately and felt the inexplicable need to write a Nibbles clone (remember this game that was shipped with Hehe :-D 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. This works very well on a real machine, as well as on VirtualBox (with and without FDAPM). The CPU usage is very low. I guess the recommended way is to notify DOS and let that do the rest. Not sure if DOSEMU implements this function. I remember that some VM, possibly DOSBOX, did not emulate HLT, because they were just happy to let DOS stuff run faster by making HLT a NOP :-p It is quite possible that DOSEMU does not do much with APM BIOS, but there is an API to check exactly that ;-) Surprisingly, under both DOSEmu and DOSBox the CPU usage is very high. I guess they don't support the APM v1.0 interface... The second is about calling the BIOS function int15h AH=86h. This works okay on a real machine, but makes keyboard controls under DOSemy laggy, This can be because int 15.86 can try to be smart: Use 18.2 Hz ticks for longer delays and do busy-waiting in a tight loop otherwise. It is possible that some BIOSes use CMOS 32kHz ticks or other fancy and energy-friendly waiting methods for shorter delays, but you simply do not really know. and don't work at all with DOSBox. DOSBox keeps crying this: Illegal read from 5820585e, CS:IP f000:11c4 Weird. Ask their forum? The third one is about using the Turbo C 'delay' function (supposed to provide a millisecond-grade sleep). I don't know what is behind this, Typical Borland IDE compilers come with runtime libraries which implement this as tight loops calibrated when your app starts. Well-known Error 200 for those where you get an overflow for fast CPU. Otherwise just CPU cycle waste. but it makes CPU usage very high. It works fine under DOSBox (apart form the burning CPU), but not under DOSemu (don't sleep at all, which makes it impossible to play, unless your name is Barry Allen). Barry Allen? I think the last time I wrote a Snake clone in 2.5 dimensions in Borland, in Pascal, I updated the code to use 40:6c aka 18.2 Hz timer ticks at some point. 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. In DOS, it was fine to HLT, but you can also tell DOS that you are idle, then FDAPM will either HLT or call the APM BIOS function, depending on what is available then :-) Another issue I had (still have, in fact) is the timer resolution. The resolution of my APM-aware sleeping routines is of ~55ms (18,2Hz). This makes the game not as smooth as I'd like. You can change frequency to anything faster, as long as you put your own int 8 handler which takes care that the original handler is only called as often as intended. Otherwise, lots of DOS and BIOS things would suddenly go faster. Programming the frequency of the timer is easy: Same hardware interface as what you use for different frequency PC speaker beeps :-) Regarding PIT programming, you normally just write hex 20 to the PIT port for IRQ ack when you are done, UNLESS you call the original int 8 handler, in which case that will do it for you. You want to avoid sending too many ACK but as you notice, most handlers do not actually take efforts to do SPECIFIC ACK such as am done with IRQ 0 aka int 8 but just send done with IRQ. Cheers, Eric -- 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=49501711iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
