Re: [Freedos-devel] FreeDOS Interim Build T2310

[Rugxulo via Freedos-devel]

Hi,

On Mon, Oct 2, 2023 at 2:07 PM Jim Hall via Freedos-devel
 wrote:
>
> Jim wrote:
> > I want to compile some things using IA-16 GCC in the new Interim Build
> > T2310, but neither the LiveCD or BonusCD have the DJGPP Environment
> > package on it. We had this on previous FreeDOS installs; to compile
> > with IA-16 GCC, you need to set the DJGPP environment variable to a
> > DJGPP.ENV file.
> >
> > Or is the DJGPP Environment package on one of the ISOs, and I've
> > missed it somehow?
>
>
> Jerome wrote:
> > The DJGPP are massive. There is not enough room on the CDs for
> > everything else when DJGPP is included. Off-hand I think those packages
> > require something like 350Mb.
> >
> > Plus… there have been “complaints” that the DJGPP needed updating
> > and some other tools/packages should also get included.
> >
> > I’m not a DJGPP user and don’t want to break those packages. So,
> > I’m not updating them.
> [..]
>
> Yes I saw the discussion about DJGPP being out of date and really big.
> No problems there. I know the distro is getting really big (see also
> below) and we should try to trim some things. I just wanted to compile
> something with IA-16 GCC (not DJGPP) and found I couldn't because
> something was missing in T2310 that IA-16 GCC needed.
>
> I wonder what the mininum extra stuff is needed from DJGPP to get
> IA-16 GCC to work. I haven't tried, but I guess that's a project I'll
> try to tackle soon. If it's a matter of crafting an ENV file, then
> that's one thing. If IA-16 GCC really needs a bunch of stuff from
> DJGPP, that may preclude IA-16 GCC if we don't have DJGPP.

T.K. Chia's Gitlab site says this (untested by me):

"Alternatively, if you do not wish to install DJGPP, just set a DJDIR
environment variable thus: set DJDIR=c:\devel\djgpp"

* https://gitlab.com/tkchia/build-ia16/-/releases

Off the top of my head, I don't know of any hard requirements that
I16GCC.EXE (etc.) needs from DJDEV205.ZIP. (The 386 COFF libraries are
useless, for instance, presumably all of the headers too. The rest is
mostly just misc. utils and info files.)


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

Re: [Freedos-devel] Help Development with djgpp

[Walter Oesch via Freedos-devel]

>From Code:

  if(_setvideomode(_SRES16COLOR) == 0) /* Switch to 800*600 mode
with 16 colors */

  {

 printf("\n\nVideo mode not supported!!!\n");

 printf("Maybe the VESA driver has not been loaded!\n");


There must be used VESA driver.


Freundliche Grüsse
Walter Oesch

Walter Oesch
Erlenweg 12
3806 Bönigen
www.webdesign-oesch.ch
Tel: 033 822 22 75
Mobile: 076 382 55 58


[image: Mailtrack]

Sender
notified by
Mailtrack

25.10.23,
12:56:56

Am Mi., 25. Okt. 2023 um 12:45 Uhr schrieb Eric Auer via Freedos-devel <
freedos-devel@lists.sourceforge.net>:

>
> Hi!
>
> > I have no knowledge for protected mode. I think you need this for
> > OpenWatcom C compiler. This is the only reason to use DJGPP compiler. Am
> I
> > right?  Else the initializing you show on the YouTube Videos is very
> simple
> > for OpenWatcom.
>
> I think (check the youtube videos with examples by Jim) OpenWatcom C
> ships with libraries for convenient graphics access functionality.
>
> Both OpenWatcom C compiled 32-bit apps and DJGPP compiled 32-bit apps
> automatically use protected mode, for example by calling or including
> a DOS extender or DPMI host, so you do not have to know how to use it
> on the hardware level unless your apps have to do very special things.
>
> However, because they (and all other 32-bit C compilers, I assume)
> use protected mode, some things will work differently compared to
> what you would see in, for example 16-bit Borland Turbo C apps.
>
> For example access to raw memory locations or hooking int handlers
> will be different. On the other hand, once you include the right
> header files and use the right calls, 32-bit compilers let you do
> MORE. A good example is being able to map a large high resolution
> graphics framebuffer above the 1st MB of RAM to a simple C array.
>
> For app-internal purposes, using 32 bits is trivial: You can malloc
> larger amounts of memory and use larger variables and arrays. Your
> pointers will often be 32-bit unsigned integers instead of either
> 16-bit (tiny and small 16-bit model) or pairs of 16-bit (large or
> huge 16-bit model) values which you may know from 16-bit compilers.
>
> Only for special cases, pointers will combine 32-bit offsets and
> 16-bit selectors values, but macros will help you in those cases.
>
> Here are some examples for directly accessing individual bytes or
> words (for dwords, use farpeekl and farpokel) in 16-bit DOS RAM
> while the rest of your app naturally works as 32-bit application.
>
> #include  /* things like inportb() */
> #include  /* only for _dos_ds... */
> #include  /* e.g. _farpeekb(_dos_ds, linear) */
> #include  /* int86, union REGS */
>
> typedef unsigned int uint32;
>
> /* o is offset, s is segment, v is value. All of them "DOS-wise": */
> #define peek(s, o)  _farpeekw( _dos_ds, ((uint32)(s)<<4)+(o) )
> #define peekb(s, o) _farpeekb( _dos_ds, ((uint32)(s)<<4)+(o) )
> #define poke(s, o, v)   _farpokew( _dos_ds, ((uint32)(s)<<4)+(o), (v) )
> #define pokeb(s, o, v)  _farpokeb( _dos_ds, ((uint32)(s)<<4)+(o), (v) )
>
> Because the first megabyte is special (shared with DOS, with
> predictable absolute addresses of some data structures etc.)
> you have to access it with macros like farpeekw or farpokew,
> using the pre-defined "_dos_ds".
>
> Similarly, to access a frame buffer, you pin the memory area and
> create a selector for it, then read and write pixels with farpeek
> (b, w, or l for 8, 16 or 32-bit values) and farpoke (b, w, or l).
>
> #include/* to call the BIOS -- or use dos.h */
>
>  __dpmi_meminfo memory_mapping;
>
> memory_mapping.address = the physical linear address of your frame
> buffer according to what the VESA BIOS told you when you selected a
> graphics mode of your choice.
> memory_mapping.size = the size of your framebuffer in bytes. Note
> that the number of bytes per line can be larger than screen width *
> bytes per pixel. Use what the VESA BIOS tells you.
>
> __dpmi_physical_address_mapping(_mapping);
> __dpmi_lock_linear_region(_mapping);
>
> int lfbSel = __dpmi_allocate_ldt_descriptors(1);
> __dpmi_set_segment_base_address(lfbSel, memory_mapping.address);
> __dpmi_set_segment_limit(lfbSel, memory_mapping.size - 1);
>
> Now you can access the framebuffer by defining a macro such as,
> in this example for 16-bit (32k or 64k high color) and true color:
>
> #define putpixel16(x,y,c) _farpokew(lfbSel, \
>(((x)*2) + (vesamode.bytes_line*(y))), (c))
>
> #define putpixel32(x,y,c) _farpokel(lfbSel, \
>(((x)*4) + (vesamode.bytes_line*(y))), (c))
>
> For NORMAL variables or arrays, where you will NOT need to
> know which absolute linear memory addresses are used, you just
> use NORMAL pointers as you would do in Linux apps. No macros.
>
> You can also call the BIOS using 

Re: [Freedos-devel] Help Development with djgpp

[Eric Auer via Freedos-devel]

Hi!


I have no knowledge for protected mode. I think you need this for
OpenWatcom C compiler. This is the only reason to use DJGPP compiler. Am I
right?  Else the initializing you show on the YouTube Videos is very simple
for OpenWatcom.


I think (check the youtube videos with examples by Jim) OpenWatcom C
ships with libraries for convenient graphics access functionality.

Both OpenWatcom C compiled 32-bit apps and DJGPP compiled 32-bit apps
automatically use protected mode, for example by calling or including
a DOS extender or DPMI host, so you do not have to know how to use it
on the hardware level unless your apps have to do very special things.

However, because they (and all other 32-bit C compilers, I assume)
use protected mode, some things will work differently compared to
what you would see in, for example 16-bit Borland Turbo C apps.

For example access to raw memory locations or hooking int handlers
will be different. On the other hand, once you include the right
header files and use the right calls, 32-bit compilers let you do
MORE. A good example is being able to map a large high resolution
graphics framebuffer above the 1st MB of RAM to a simple C array.

For app-internal purposes, using 32 bits is trivial: You can malloc
larger amounts of memory and use larger variables and arrays. Your
pointers will often be 32-bit unsigned integers instead of either
16-bit (tiny and small 16-bit model) or pairs of 16-bit (large or
huge 16-bit model) values which you may know from 16-bit compilers.

Only for special cases, pointers will combine 32-bit offsets and
16-bit selectors values, but macros will help you in those cases.

Here are some examples for directly accessing individual bytes or
words (for dwords, use farpeekl and farpokel) in 16-bit DOS RAM
while the rest of your app naturally works as 32-bit application.

#include  /* things like inportb() */
#include  /* only for _dos_ds... */
#include  /* e.g. _farpeekb(_dos_ds, linear) */
#include  /* int86, union REGS */

typedef unsigned int uint32;

/* o is offset, s is segment, v is value. All of them "DOS-wise": */
#define peek(s, o)  _farpeekw( _dos_ds, ((uint32)(s)<<4)+(o) )
#define peekb(s, o) _farpeekb( _dos_ds, ((uint32)(s)<<4)+(o) )
#define poke(s, o, v)   _farpokew( _dos_ds, ((uint32)(s)<<4)+(o), (v) )
#define pokeb(s, o, v)  _farpokeb( _dos_ds, ((uint32)(s)<<4)+(o), (v) )

Because the first megabyte is special (shared with DOS, with
predictable absolute addresses of some data structures etc.)
you have to access it with macros like farpeekw or farpokew,
using the pre-defined "_dos_ds".

Similarly, to access a frame buffer, you pin the memory area and
create a selector for it, then read and write pixels with farpeek
(b, w, or l for 8, 16 or 32-bit values) and farpoke (b, w, or l).

#include/* to call the BIOS -- or use dos.h */

__dpmi_meminfo memory_mapping;

   memory_mapping.address = the physical linear address of your frame 
buffer according to what the VESA BIOS told you when you selected a 
graphics mode of your choice.
   memory_mapping.size = the size of your framebuffer in bytes. Note 
that the number of bytes per line can be larger than screen width * 
bytes per pixel. Use what the VESA BIOS tells you.


   __dpmi_physical_address_mapping(_mapping);
   __dpmi_lock_linear_region(_mapping);

   int lfbSel = __dpmi_allocate_ldt_descriptors(1);
   __dpmi_set_segment_base_address(lfbSel, memory_mapping.address);
   __dpmi_set_segment_limit(lfbSel, memory_mapping.size - 1);

Now you can access the framebuffer by defining a macro such as,
in this example for 16-bit (32k or 64k high color) and true color:

#define putpixel16(x,y,c) _farpokew(lfbSel, \
  (((x)*2) + (vesamode.bytes_line*(y))), (c))

#define putpixel32(x,y,c) _farpokel(lfbSel, \
  (((x)*4) + (vesamode.bytes_line*(y))), (c))

For NORMAL variables or arrays, where you will NOT need to
know which absolute linear memory addresses are used, you just
use NORMAL pointers as you would do in Linux apps. No macros.

You can also call the BIOS using __dpmi_int(...) to have extra
control over how mappings are treated, but DJGPP will handle
many popular cases AUTOMATICALLY if you use int86(...) with
__dpmi_regs from dos.h, for example if you want to call a
mouse driver via interrupt 0x33.

So you will often NOT need to use _dpmi_allocate_dos_memory()
or _dpmi_free_dos_memory(). Instead, you will use DJGPP library
functions for all common things. Accessing files will feel not
so different from accessing files in Linux with GCC compiled
apps, of course within the file size limits imposed by DOS.


SVGA is possible with the used board by installing a firmware.


Again, do you also have firmware for VESA VBE framebuffers?
That would make access fast and convenient. Of course, if you
use the graphics library of OpenWatcom C, or if you use the
Allegro library available for DJGPP, none of the convenience
issues will matter for you, as the libraries will do all the
work. 

Re: [Freedos-devel] Help Development with djgpp

[Walter Oesch via Freedos-devel]

Hi
I have no knowledge for protected mode. I think you need this for
OpenWatcom C compiler. This is the only reason to use DJGPP compiler. Am I
right?  Else the initializing you show on the YouTube Videos is very simple
for OpenWatcom.

SVGA is possible with the used board by installing a firmware.

Freundliche Grüsse
Walter Oesch

Walter Oesch
Erlenweg 12
3806 Bönigen
www.webdesign-oesch.ch
Tel: 033 822 22 75
Mobile: 076 382 55 58


[image: Mailtrack]

Sender
notified by
Mailtrack

25.10.23,
10:14:04

Am Mi., 25. Okt. 2023 um 01:41 Uhr schrieb Jim Hall via Freedos-devel <
freedos-devel@lists.sourceforge.net>:

> On Tue, Oct 24, 2023 at 9:31 AM Walter Oesch via Freedos-devel
>  wrote:
> >
> > Dear Eric
> >
> > Hear some facts of my project:
> >
> > I work for embedded software on the board Vortex86DX 800MHz.
> > I need at least SVGA graphic (800X600).
> > I prefer to work on Ubuntu 20.04 Linux (no Windows)
> > The target operating System is FreeDOS. May be later a Linux variant,
> but not at the moment.
> > The editor is an old version of Qt Creator or any other.
> > At the moment I compile with MSC70 (old Microsoft compiler) on DOSBox.
> > If possible i'd like to go with DOSBox or with a cross compiler.
> > The reason for change of the compiler: to overcome the memory limit of
> 640KB.
> >
> > So I'm looking to get a starter  c program to have a quick start on
> djgpp. The must is graphic for SVGA and may be library for RS232.
> >
> > I pay for the example program.
> >
>
>
> If you don't need DJGPP specifically, I wrote several demo programs
> about graphics programming using the OpenWatcom C compiler, for the
> FreeDOS YouTube channel. Here are a few videos: (most recent videos
> are listed first)
>
>
> Video resolutions
> https://www.youtube.com/watch?v=0wf-KqsOfnE
>
> Calculate pi by counting pixels (area method)
> https://www.youtube.com/watch?v=jHC1iLHtUP8
>
> How to get the color of a pixel (getcolor)
> https://www.youtube.com/watch?v=vH45OOSvQTk
>
> Using _getimage and _putimage
> https://www.youtube.com/watch?v=--YP8yuRP-g
>
> Simple banana trajectory game
> https://www.youtube.com/watch?v=xoDY0WEQkxs
>
> Making a board game in graphics mode
> https://www.youtube.com/watch?v=70CrhfELIjM
>
> Graphics mode programming
> https://www.youtube.com/watch?v=uhxKXdZKCeM
>
>
> ___
> 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