Re: [Freedos-devel] Where to start and continue?

[Jim Hall]

Jerome wrote:
> Like Tom said, there are books available.
>
> With few exceptions, the books are much better than trying to learn this
> stuff from websites. Most of the stuff you will find online probably
> will not go into the details you need. In my opinion, most of the
> online stuff requires a minimum of understanding and experience. I’m
> not saying that it cannot be learned strictly using the web. But,
> it will probably be a lot more difficult.
>
> Fortunately, nowadays most of the books related to DOS programming are
> cheap. Very cheap. Like pennies on the dollar cheap. A book that came
> out in the 90’s on the topic for around $50 can usually be had now
> for about $5.
>
> I don’t think your ready to tackle assembly under DOS yet. Not only
> do you need to know some variant of assembly language. That really does
> require some understanding of how DOS, BIOS and the computer itself
> work at such a low level. This knowledge is mostly gained through
> experience programming for DOS.
>
> Therefore, you will need to start with one of the higher level
> languages. Either a variant of C or Pascal. For Pascal, the most
> common for DOS is Turbo Pascal. There are loads of example programs
> for it in books and online. However, Turbo Pascal is a closed source
> compiler. Nowadays, you can download v5.5 for free from Embarcadero. But
> being a closed source compiler, there are many individuals in the
> open source community that frown upon using it. That probably make C
> a better choice. There are lots of C resources online as well.
>
> For example, I recommend watching Jim’s video on creating a simple
> graphics program to display some images to represent LEDs counting in
> binary from 0 to 255. It could be a definite starting point on C with
> graphics in DOS. He goes through the whole processes of creating the
> program and explains each aspect during the process. He sometimes also
> takes requests on different topics.
>
> https://www.youtube.com/watch?v=--YP8yuRP-g



More generally, I did a whole video series about "learning C
programming" that you might be interested in:
https://www.youtube.com/watch?v=6fThPftZuAQ=PLzuACU-W7Omo3VEnMKuM0IPupdOHFDzL3

Although an easier starting point is this "HTML ebook" version on the website:
https://www.freedos.org/books/cprogramming/


The series is meant for beginners - you know C++ already, so some of
the topics will be too entry-level for you. Feel free to skip ahead to
the sections that interest you.

I'd recommend starting with command-line programs, then moving on to
conio programs. Leave graphics programming last. Remember how many
console-mode programs were written for DOS in the 1980s and 1990s? You
can get really far with DOS programming using conio.

The conio library will be different for every compiler, since it is a
nonstandard extension. OpenWatcom and IA-16 GCC both have conio
implementations, but read the documentation for what you want to do.


Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Where to start and continue?

[Jerome Shidel]

Hi,

> On Jan 10, 2023, at 4:14 AM, Knedlik  wrote:
> 
> Hello all again,
> thanks for all the responses. Definitely useful stuff. I’d just like to 
> respond to the concerns regarding the VM - I’m afraid I don’t have any 
> silicon able to run FreeDOS. My main computer is not only an overkill (Ryzen 
> 5 3600X, SSD, RTX 2060, 32 gigs of RAM), but I don’t think it supports legacy 
> BIOS. And the secondary I’m on right now is a MacBook with an M1 CPU, so even 
> if I had bootcamp, that option wouldn’t be possible.
> -Knedlik
> 

Don’t worry about the VM issues too much. I just wanted to point out they 
exist. Depending on what you may write, you could make something that is done 
100% perfect that doesn’t work in a VM. 

I generally use on older Intel based Mac. I have several workflows for creating 
stuff for DOS. When making stuff in assembly, I do my writing in BBEdit. Then 
compile in a terminal on the Mac. Then switch over to one of a couple VMs or 
Real Hardware and test. The testing part can vary based on the know limitations 
for the VMs. 

Generally, that testing happens under DOSBox. Here I run FreeCOM on top of the 
DOSBox kernel. It is a sort-of hybrid install that the FreeDOS installer can 
perform. This permits the DOS VM easy access to the host file system. However, 
there are some issues. Most have to do with the disk and file system. For 
example, updating a files time stamp in DOS gets completely ignored.  There are 
other issues as well. But, I usually find this the easiest workflow.

Sometimes the DOS part of my workflow includes a VirtualBox instance. In the 
early days, getting files to and from the VM was more work. I would copy them 
onto a diskette image file (which is easy on a Mac). Dismount the image file. 
Then mount the image in VirtualBox. Test and Dismount it in the VM. And repeat. 
Needing to make sure I did not mount the image in both places at the same time 
or the image file would be trashed.

Nowadays. I have a Linux server with a Samba share mounted by the Mac. The 
server also shares the directory over EtherDFS to the VirtualBox DOS instance 
running an EtherDFS client. It works well except EtherDFS does not support long 
file names. Which is fine because you should avoid those in DOS development. 

As for VirtualBox itself, first there is no PC Speaker support. The VGA 
limitations mostly crop up with more advanced things like using features that 
require talking to the card. The basic BIOS calls work fine. 

Then there is real hardware. It’s the ultimate test and nothing is better. I 
use both real floppies and EtherDFS to get files onto that machine. 

While the different limitations of the various VMs do exist, they are issues to 
just avoid. You just need to be aware and able to spot them when/if they crop 
up. Then figure out how to avoid the problem when possible in your code. 

After all, a large number of users will not have real hardware either. Like 
you, they will be limited to running the program in a VM. It wouldn’t make much 
sense to create something that neither the users or yourself can actually run. 
Even if it would work fine on real hardware. :-)

When it comes down to avoiding the VM issues, sometimes you can and sometimes 
you can not. 

For example, let’s say you want to make a better file copy program. One that 
copies file time stamps and verifies everything. You test it on real hardware 
and it works great. Try it under VirtualBox and it is incredibly cool. You jump 
into your DOSBox hybrid install and… Error: Copied file failed verification. 
What? Why? It worked fine on my test machine under VirtualBox! So after some 
debugging and head banging and more debugging, you realize the program was fine 
and DOSBox just ignores the timestamps. 

Not much you can do about that. Maybe you test to see if you’re running under 
DOSBox and warn the user that this occur. Maybe some other or even no solution. 
It’s up to you. :-)



> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Where to start and continue?

[Louis Santillan]

One reference, HelpPC might also be useful (https://stanislavs.org/helppc/).

On Tue, Jan 10, 2023 at 1:32 AM Carsten Strotmann via Freedos-devel
 wrote:
>
> Hi,
>
> On 10 Jan 2023, at 10:13, Knedlik wrote:
>
> > Hello all again,
> > thanks for all the responses. Definitely useful stuff. I’d just like to 
> > respond to the concerns regarding the VM - I’m afraid I don’t have any 
> > silicon able to run FreeDOS. My main computer is not only an overkill 
> > (Ryzen 5 3600X, SSD, RTX 2060, 32 gigs of RAM), but I don’t think it 
> > supports legacy BIOS. And the secondary I’m on right now is a MacBook with 
> > an M1 CPU, so even if I had bootcamp, that option wouldn’t be possible.
> > -Knedlik
>
>
> a dedicated PC emulator might be a better option than an VM
>
>  * PCem https://www.pcem-emulator.co.uk/
>  * DOSBOX https://dosbox-x.com/
>  * PCE http://www.hampa.ch/pce/
>  * PCEjs https://github.com/jsdf/pce
>
> Greetings
>
> Carsten
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Where to start and continue?

[Carsten Strotmann via Freedos-devel]

Hi,

On 10 Jan 2023, at 10:13, Knedlik wrote:

> Hello all again,
> thanks for all the responses. Definitely useful stuff. I’d just like to 
> respond to the concerns regarding the VM - I’m afraid I don’t have any 
> silicon able to run FreeDOS. My main computer is not only an overkill (Ryzen 
> 5 3600X, SSD, RTX 2060, 32 gigs of RAM), but I don’t think it supports legacy 
> BIOS. And the secondary I’m on right now is a MacBook with an M1 CPU, so even 
> if I had bootcamp, that option wouldn’t be possible.
> -Knedlik


a dedicated PC emulator might be a better option than an VM

 * PCem https://www.pcem-emulator.co.uk/
 * DOSBOX https://dosbox-x.com/
 * PCE http://www.hampa.ch/pce/
 * PCEjs https://github.com/jsdf/pce

Greetings

Carsten


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Where to start and continue?

[Knedlik]

Hello all again,
thanks for all the responses. Definitely useful stuff. I’d just like to respond 
to the concerns regarding the VM - I’m afraid I don’t have any silicon able to 
run FreeDOS. My main computer is not only an overkill (Ryzen 5 3600X, SSD, RTX 
2060, 32 gigs of RAM), but I don’t think it supports legacy BIOS. And the 
secondary I’m on right now is a MacBook with an M1 CPU, so even if I had 
bootcamp, that option wouldn’t be possible.
-Knedlik

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Where to start and continue?

[Carsten Strotmann via Freedos-devel]

Hi,

On 9 Jan 2023, at 19:51, Knedlik wrote:

> Any help with places to learn this stuff will be appreciated.

the Internet Archive has many good (old) books on MS-DOS/PC development that 
are still valid today: 


Greetings

Carsten


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Where to start and continue?

[jerome]

Hi,

> On Jan 9, 2023, at 6:44 PM, Ralf Quint  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 
 
[2] 
https://www.amazon.com/Ultimate-DOS-Programmers-Manual/dp/0830641149/ref=sr_1_1?crid=14LG283XYRNMS=ultimate+dos+programmers+guide=1673317834=ultimate+dos+programmers+guide%2Caps%2C110=8-1
 

Re: [Freedos-devel] Where to start and continue?

[Ralf Quint]

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




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Where to start and continue?

[Jerome Shidel]

Hi,

> On Jan 9, 2023, at 2:46 PM, Knedlik  wrote:
> 
> That’s actually a good question.
> I would say the second option, as I’m in for the trip to DOS world for 
> learning how it worked in „the old days“. I do have FreeDOS running on a VM 
> on my Mac, so that I can access it at pretty much any time when I have *a* 
> computer with me. I will definitely explore the link you sent.
> -Knedlik

Just a minor warning for when you start working on DOS stuff through a VM.

Different Virtual Machine platforms have different limitations when it comes to 
supporting DOS hardware. For example, Virtual box does not support the PC 
Speaker or some common VGA functions. Generally, the lack of good VGA support 
does not affect most programs. While others may not work at all.

DOSBox tends to do alright. But, there are limitations while using it as well. 




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Where to start and continue?

[Knedlik]

That’s actually a good question.
I would say the second option, as I’m in for the trip to DOS world for learning 
how it worked in „the old days“. I do have FreeDOS running on a VM on my Mac, 
so that I can access it at pretty much any time when I have *a* computer with 
me. I will definitely explore the link you sent.
-Knedlik



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Where to start and continue?

[Louis Santillan]

Depends on where you want to start.  Do you want to learn an
API/library like Allegro or DOjS and start "extending system" sooner?
Or would you rather learn how to write against the VGA or VESA
standards or other hardware standards?  If the latter, then PCGPE
would be helpful (http://qzx.com/pc-gpe/), as would a real machine,
DOSBOX or VM setup for DOS would be helpful.  But having some info on
the development stack you've chosen would be helpful to point you in
the right direction.

On Mon, Jan 9, 2023 at 11:30 AM Knedlik  wrote:
>
> Thanks a lot Louis, that is definitely something to look at.
> I suppose the general way to learn stuff in this world is to look at the 
> source code of other applications?
> -Knedlik
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Where to start and continue?

[Knedlik]

Thanks a lot Louis, that is definitely something to look at.
I suppose the general way to learn stuff in this world is to look at the source 
code of other applications?
-Knedlik



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Where to start and continue?

[Louis Santillan]

Otherwise, Allegro and DOjS likely your best bets today.

On Mon, Jan 9, 2023 at 11:25 AM Louis Santillan  wrote:
>
> You'll want to look at
>
> Allegro 4.4.3 for DOS
> (https://liballeg.org/stabledocs/en/readme.html), a complete game C
> library for DOS and djgpp.
>
> Microwindows for DOS (https://github.com/ghaerr/microwindows), a
> Windowing system with Win32 and X11 like APIs available, also for
> djgpp.
>
> DOjS (https://github.com/SuperIlu/DOjS), a JavaScript engine ported to
> DOS & djgpp that embeds Allegro, Sound and several other libraries.
>
> Depending on your stack, there's also BGI for Borland compilers.  Otherwise
>
> On Mon, Jan 9, 2023 at 10:53 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.
> > Thanks in advance,
> > -Knedlik
> >
> > ___
> > Freedos-devel mailing list
> > Freedos-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Where to start and continue?

[Louis Santillan]

You'll want to look at

Allegro 4.4.3 for DOS
(https://liballeg.org/stabledocs/en/readme.html), a complete game C
library for DOS and djgpp.

Microwindows for DOS (https://github.com/ghaerr/microwindows), a
Windowing system with Win32 and X11 like APIs available, also for
djgpp.

DOjS (https://github.com/SuperIlu/DOjS), a JavaScript engine ported to
DOS & djgpp that embeds Allegro, Sound and several other libraries.

Depending on your stack, there's also BGI for Borland compilers.  Otherwise

On Mon, Jan 9, 2023 at 10:53 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.
> Thanks in advance,
> -Knedlik
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Where to start and continue?

[Knedlik]

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.
Thanks in advance,
-Knedlik

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel