Re: [Freedos-devel] Help Development with djgpp

2023-10-26 Thread Danilo Pecher via Freedos-devel
As far as I know, VESA graphics mode numbers are not standardized,
which is why the vesa info block of standard 1.2 and higher, returned
by INT 10h function AX=4F00h, contains a mode list, which you then
need to traverse using INT10h AX=4F01. So as a first step I'd check if
the watcom graphics library does that. As a first test you might want
to use the 'listvesa' package from the FreeDOS Live-CD (utilities
section IIRC) to see if your graphics card does support at least VESA
1.2 and then if it supports that specific mode.

cheers, Hippo

On Fri, 27 Oct 2023 at 01:18, Jim Hall via Freedos-devel
 wrote:
>
> On Wed, Oct 25, 2023 at 5:58 AM Walter Oesch via Freedos-devel
>  wrote:
> >
> > 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.
> >
>
>
>
> If it helps to have a quick test program to try on your board, you can
> find GRAFTEST.EXE here:
>
> https://personal.freedos.org/temp/GRAFTEST.EXE
>
>
> This just puts the display into graphics mode then draws a square,
> circle, and diagonal line. The EXE is compiled with OpenWatcom C using
> the defaults (using "WCL -q GRAFTEST.C") so it's without optimization
> - it's just a demo program. Source code is in GRAFTEST.C (at same
> location, also copied below)
>
>
> #include 
> #include  /* getch */
> #include  /* graphics mode */
>
> int main()
> {
> if (_setvideomode(_VRES16COLOR) == 0) {
> puts("cannot set video mode");
> return 1;
> }
>
> /* draw shapes */
>
> _setcolor(1); /* blue */
> _rectangle(_GFILLINTERIOR, 50,75, 350,375); /* from 50,75 to 350,375 */
>
> _setcolor(2); /* green */
> _ellipse(_GFILLINTERIOR, 300,200, 500,400); /* from 300,200 to 500,400 */
>
> _setcolor(15); /* br white */
> _moveto(10,10);
> _lineto(600,400); /* line from 1,1 to 600,400 */
>
> if (getch() == 0) {
> /* if getch is zero, then extended key. call getch again to clear
>it and get a new extended code */
> getch(); /* but we don't really need it anyway :-) */
> }
>
> /* done */
>
> _setvideomode(_DEFAULTMODE);
> return 0;
> }
>
>
>
> (my code formatting may be messed up when copied/pasted into an email)
>
> I'll delete the https://personal.freedos.org/temp/ URL around November 1.
>
>
> ___
> 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] Help Development with djgpp

2023-10-26 Thread Jim Hall via Freedos-devel
On Wed, Oct 25, 2023 at 5:58 AM Walter Oesch via Freedos-devel
 wrote:
>
> 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.
>



If it helps to have a quick test program to try on your board, you can
find GRAFTEST.EXE here:

https://personal.freedos.org/temp/GRAFTEST.EXE


This just puts the display into graphics mode then draws a square,
circle, and diagonal line. The EXE is compiled with OpenWatcom C using
the defaults (using "WCL -q GRAFTEST.C") so it's without optimization
- it's just a demo program. Source code is in GRAFTEST.C (at same
location, also copied below)


#include 
#include  /* getch */
#include  /* graphics mode */

int main()
{
if (_setvideomode(_VRES16COLOR) == 0) {
puts("cannot set video mode");
return 1;
}

/* draw shapes */

_setcolor(1); /* blue */
_rectangle(_GFILLINTERIOR, 50,75, 350,375); /* from 50,75 to 350,375 */

_setcolor(2); /* green */
_ellipse(_GFILLINTERIOR, 300,200, 500,400); /* from 300,200 to 500,400 */

_setcolor(15); /* br white */
_moveto(10,10);
_lineto(600,400); /* line from 1,1 to 600,400 */

if (getch() == 0) {
/* if getch is zero, then extended key. call getch again to clear
   it and get a new extended code */
getch(); /* but we don't really need it anyway :-) */
}

/* done */

_setvideomode(_DEFAULTMODE);
return 0;
}



(my code formatting may be messed up when copied/pasted into an email)

I'll delete the https://personal.freedos.org/temp/ URL around November 1.


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


Re: [Freedos-devel] Help Development with djgpp

2023-10-25 Thread 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(&memory_mapping);
> __dpmi_lock_linear_region(&memory_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.
>
> Y

Re: [Freedos-devel] Help Development with djgpp

2023-10-25 Thread 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(&memory_mapping);
   __dpmi_lock_linear_region(&memory_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 al

Re: [Freedos-devel] Help Development with djgpp

2023-10-25 Thread 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


Re: [Freedos-devel] Help Development with djgpp

2023-10-24 Thread Jim Hall via Freedos-devel
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


Re: [Freedos-devel] Help Development with djgpp

2023-10-24 Thread tom ehlert via Freedos-devel



>> I work for embedded software on the board Vortex86DX 800MHz.
>> I need at least SVGA graphic (800X600).

> https://www.vortex86.com/products/Vortex86DX SoC has no built-in VGA, 

https://icop-shop.com/product/vdx-6324rd/  has buildin VGA so there are at 
least some boars available.

it might still be easier to o your project on a Raspberry Pi.

Tom





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


[Freedos-devel] Help Development with djgpp

2023-10-24 Thread Walter Oesch via Freedos-devel
Dear Community

I need help compiling an application with djgpp comiler, for payment.
I need an example program with graphic library ( draw circle)
Communicate with RS232 if there is a library for this that simplifies it.

Is it recommanded to use the cross compiler on Ubuntu 20.04 hier:
https://github.com/andrewwutw/build-djgpp ?

I need a starting point to set up the compiler and an example c source to
demonstrate the graphics and may be RS232.

Best Regards
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

24.10.23,
09:51:13
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel