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&keywords=ultimate+dos+programmers+guide&qid=1673317834&sprefix=ultimate+dos+programmers+guide%2Caps%2C110&sr=8-1
 

Re: [Freedos-devel] Incompatible "copy /b" operation

[Ralf Quint]

On 1/9/2023 3:39 PM, Louis Santillan wrote:

Over at vogons, Dave Dunfield
(https://dunfield.themindfactory.com/dnld.htm) has been working on
updating his DDLINK package to be able to bootstrap file transfer
between machines via COM, LPT or NIC.  This is a small package much
like LapLink and other tools of yesteryear.  LapLink could famously be
bootstrapped using a simple set of DOS commands.

However, Dave noted that FreeDOS's "copy /b COM1: DDBOOT.COM" strips
various non-printable characters
(https://www.vogons.org/viewtopic.php?p=1129367#p1129367), including
EOF which should end the transfer.  See other notes extracted from
DDLINK.ZIP (https://dunfield.themindfactory.com/dnld/DDLINK.ZIP)
below.

Smells like a bug in FreeCOM's copy
(https://github.com/FDOS/freecom/blob/master/cmd/copy.c).
Well, the problem is that Crtl-Z (EOF) doesn't get much love for the 
last couple decades at least. No OS since about 1995 actually requires 
an EOF characters anymore as it used to be mandatory in CP/M and kind of 
optional and recognized in MS-DOS 2.00 and newer.


The use case here is a bit of a Catch22, which requires special 
treatment as it is a redirection to a serial byte/character level device 
(COM1) but using it for transferring files between block/sector level 
devices.


It seems in this case, it still tries to interpret those control 
characters on for the former while the /b (binary) switch should tell it 
to do ignore those



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?

[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

[Freedos-devel] Incompatible "copy /b" operation

[Louis Santillan]

Over at vogons, Dave Dunfield
(https://dunfield.themindfactory.com/dnld.htm) has been working on
updating his DDLINK package to be able to bootstrap file transfer
between machines via COM, LPT or NIC.  This is a small package much
like LapLink and other tools of yesteryear.  LapLink could famously be
bootstrapped using a simple set of DOS commands.

However, Dave noted that FreeDOS's "copy /b COM1: DDBOOT.COM" strips
various non-printable characters
(https://www.vogons.org/viewtopic.php?p=1129367#p1129367), including
EOF which should end the transfer.  See other notes extracted from
DDLINK.ZIP (https://dunfield.themindfactory.com/dnld/DDLINK.ZIP)
below.

Smells like a bug in FreeCOM's copy
(https://github.com/FDOS/freecom/blob/master/cmd/copy.c).


%<-%<---
  3.4.1 FreeDos

 I have confirmed that this works well with several versions  of
 MicroSoft MS-DOS,  as well as IBM PC-DOS ...  but it  has  more
 trouble with FreeDos! Both MS-DOS and PC-DOS provide an "almost
 binary" transfer when you perforn:

   COPY COMn: file

 In fact, the only character which can NOT be copied this way is
 0x1A (EOF which stops the copy).

 To be able to copy on a bootloader,  I only had to make sure it
 does not contain the byte value 0x1A.

 FreeDos  however  blocks  more   byte   values.   DDLINK   1.7+
 bootloaders have been modified to contain NONE of the ones I've
 (so far)  identified ...  and it does work *sometimes* if  done
 right after booting!

 I've not found /B to be reliable under FreeDos.

 If you have trouble using /B,  please use the information below
 to try and determine which bytes are being blocked and  contact
 me.


  These are the bytes I've observed that FreeDos blocks/corrupts:
00 NULL   Often terminates strings
03 Control-C  Console Interrupt
0A Line-feed  ..probably related to 'newline'
0D Return ..difference between DOS & UNIX
11 XONresume output  \ used in UNIX
13 XOFF   suspent output / but not DOS
1A EOFTerminate file
  !There is no guarantee these won't change with new releases!

  These are the byte values DDLINK currently COPYs during bootstrap:
01 02 04-09 18 19 1C 26 31 34 36 38-3E 46 47 4A-4D 58 5F-61 64
68 6B 6F 72 73 75-7A 7E-83 85 88-8A 8C 8D 90 9B B0 B1 B3 B9 BB-BD
C0 C1 C3 C7 CE D0 D2-D4 D6 DA-DC DF E0 E2 E3 F0 F1 F5 F6 F8-FF


___
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