Hi, > On Jan 9, 2023, at 6:44 PM, Ralf Quint <freedos...@gmail.com> wrote: > > On 1/9/2023 10:51 AM, Knedlik wrote: >> Hello! >> I have quite some experience programming in various languages ranging from >> Python to C++ on modern x64 and Arm64 hardware, but I seem stuck when >> wanting to do something on DOS. I’m mainly stuck at advanced stuff like >> graphics mode, audio, extending the base system, and also if it’s even >> possible to have sprites/spritesheets as files. Any help with places to >> learn this stuff will be appreciated. > Well, in addition to what Jerome cautioned about when using VMs instead of > "real iron", one important thing to consider is that DOS doesn't really have > a concept of OS level drivers, certainly not when it comes to anything > video/graphics card related. Any such driver was the responsibility of the > applications running on DOS., though some rudimentary attempts were made to > try and define a standard, for example like Borland did for their Turbo > series of programming languages and their use of BGI (Borland Graphics > Interface). > > Also to consider is that back in those days, there were a lot of competing > and partially incompatible (graphics) hardware existed. IBM had set some > "standards" with their MDA (and in extension Hercules with their Hercules > Graphics Card), CGA, EGA and VGA standards. But beside some very basic memory > layout and graphics controller registers, any compatibility here was only > give on the BIOS level (INT10h), which specially for games and things like > sprites that you mentioned, was commonly deemed to slow, if calls for such > functions didn't exist in the first place. > > This is a HUGE difference to today's world, where all lower level stuff is > handled by OS level drivers and the programmer is presented with a higher > level API to the graphics functions. Differences on that level though exist > between different GUI based OS, like any such function will likely be > different between Windows, macOS, Linux, Android, iOS, etc... > > > Ralf
Like Ralf said, there is a big difference between writing programs for “modern” operating systems and for DOS. A similar comparison would be… An experience C developer for Windows saying “Tomorrow, I’m going to make an iOS app.” That developer will soon realize he has dozens of new API’s and thousands of functions he needs to learn just to get something simple working. I say that not to discourage you. Only to point out, you have to learn some stuff to develop for DOS. I think you should start with some simple things to get your feet wet. Maybe checkout Jim’s FreeDOS channel[1] on youtube at where he often makes some example programs. If that is to basic for your skill level, get a good DOS programming book. Yes… Most DOS related programming information is available online somewhere. But, some is hard to find and there is a ton of garbage to wade through. As a suggestion, Ultimate DOS Programmers Manual[2] on Amazon. They contain tons of relative information some of which is extremely difficult to locate online. Also, consider working on fixing bugs with existing programs. You could learn a lot about how things work in DOS and different techniques that can be employed. Once you really get moving, you’ll want to start checking out RBIL[3][4] and maybe the OSDev wiki[5]. However, the OSDev Wiki is geared more towards “modern” operating systems. Now on to Graphics… In a “modern” OS, you might do something like this: use_library GRAPHICS set_mode VGA320 declare SPRITE_IMAGE as sprite1 load_sprite sprite1, “my sprite.ico” put_sprite sprite1, 5, 20 And you’re done. There are many such libraries under DOS. They are all very different and by no means equal. I don’t use them. But, others may have some suggestions. I have my own called the Danger Engine that on FreeDOS 1.3 power some games (like BlockDrop and SaysWho) and the FreeDOS Credits program use. However, the Danger Engine is still early in it’s development and I do not recommend else use it. It is mostly a working prototype. However if the graphics needs are not to dramatic, many programmers do it themselves. VGA 320x200x256 is the easiest to program directly. You can switch to mode 0x13 through a simple interrupt call[6]. Once there, you can write directly to ram to put pixels on the display. Once your program is done, you can switch back to the original video mode and exit. It can be a lot of work. But, it can also be a lot of fun. :-) Jerome [1] https://www.youtube.com/@freedosproject <https://www.youtube.com/@freedosproject> [2] https://www.amazon.com/Ultimate-DOS-Programmers-Manual/dp/0830641149/ref=sr_1_1?crid=14LG283XYRNMS&keywords=ultimate+dos+programmers+guide&qid=1673317834&sprefix=ultimate+dos+programmers+guide%2Caps%2C110&sr=8-1 <https://www.amazon.com/Ultimate-DOS-Programmers-Manual/dp/0830641149/ref=sr_1_1?crid=14LG283XYRNMS&keywords=ultimate+dos+programmers+guide&qid=1673317834&sprefix=ultimate+dos+programmers+guide,aps,110&sr=8-1> [3] Original RBIL: http://www.cs.cmu.edu/~ralf/ <http://www.cs.cmu.edu/~ralf/> [4] My HTML version: https://fd.lod.bz/rbil/ <https://fd.lod.bz/rbil/> [5] https://wiki.osdev.org/Expanded_Main_Page <https://wiki.osdev.org/Expanded_Main_Page> [6] https://fd.lod.bz/rbil/interrup/video/1000.html#103 <https://fd.lod.bz/rbil/interrup/video/1000.html#103>
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
