[Freedos-devel] Graphics APIs

[David McMackins]

Some web searching has yielded no useful results for my query.

I'm considering developing some graphical programs for FreeDOS, but I'm
not sure what graphics APIs are available and documented for it.

My expertise is in C, but if I can achieve it in Pascal, I'm open to
getting deeper into it. What interfaces are available, and/or what
documents can I review to learn more about graphics programming on DOS?

Happy Hacking,

David E. McMackins II
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.gnu.org www.fsf.org

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

[Freedos-devel] Compiling PowerPaint

[David McMackins]

I have some modifications I'd like to make to PowerPaint as hosted on
the FreeDOS archives, but I'm unable to compile the source. I'm
attempting to use FreePascal to do the job, but it's failing to compile
some of the units due to assembler syntax errors.

I can't exactly tell what the problem is; the syntax looks fine to me,
but it's throwing 'Unknown identifier "DX"' and similar for vga2.pas

Is there another assembler or compiler I need to be using for this program?

Happy Hacking,

David E. McMackins II
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.gnu.org www.fsf.org

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

Re: [Freedos-devel] Compiling PowerPaint

[David McMackins]

>> Uh, why are you doing that? Don't do that, you don't need to bootstrap
>> (and it probably won't work like you want).
>> 
>> Are you trying to use the Win32-hosted cross-compiler in actual DOS?

Not sure why it shouldn't work if compiled from source. My ideal is to
be able to actually change my software on the host system since it has
enough disk space.

My primary OS is Debian Sid, so I'm not using any Win32 compilers. I'm
downloading the msdos cross-compiler for it, and I'll test the outputs
on my VM, since it will be a few days until I have the hardware to
transfer files to my FreeDOS computer without burning a CD.

>> Read the docs.

That's what I'd been doing for hours before ever sending my initial
message. Seems to me the problem is that the go32v2 compiler doesn't
count as "DOS", so it refuses to allow far pointers like all the other
ones except i8086. That's why I would like to have the i8086 version on
my DOS box so that it will actually compile programs that are
distributed for FreeDOS.


Happy Hacking,

David E. McMackins II
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.gnu.org www.fsf.org

On 07/29/2016 11:04 PM, Rugxulo wrote:
> Hi,
> 
> On Fri, Jul 29, 2016 at 10:45 PM, David McMackins <cont...@mcmackins.org> 
> wrote:
>>
>> Indeed, the msdos target exists, but it's not in the distribution on the
>> FreeDOS host.
> 
> Go32v2 (32-bit DPMI, COFF) is the main DOS target (since the '90s!).
> The i8086-msdos (OMF) target is new to 3.0.0.
> 
>> I've changed to using the TP compatibility mode, and that has resolved
>> most of the problems. Now, my biggest problem is getting far pointers to
>> work, since they're only enabled for msdos.
> 
> Read the docs.
> 
>> I'm attempting to compile the msdos compiler, but fpcmake is failing due
>> to a missing Makefile.fpc in the utils directory in the source tree.
> 
> Uh, why are you doing that? Don't do that, you don't need to bootstrap
> (and it probably won't work like you want).
> 
> Are you trying to use the Win32-hosted cross-compiler in actual DOS?
> Snapshots for 3.1.1 are found on the FTP here:
> 
> ftp://ftp.freepascal.org/pub/fpc/snapshot/v31/i8086-msdos/
> 
> --
> ___
> 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] Compiling PowerPaint

[David McMackins]

Indeed, the msdos target exists, but it's not in the distribution on the
FreeDOS host.

I've changed to using the TP compatibility mode, and that has resolved
most of the problems. Now, my biggest problem is getting far pointers to
work, since they're only enabled for msdos.

I'm attempting to compile the msdos compiler, but fpcmake is failing due
to a missing Makefile.fpc in the utils directory in the source tree.


Happy Hacking,

David E. McMackins II
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.gnu.org www.fsf.org

On 07/29/2016 09:43 PM, Rugxulo wrote:
> Hi,
> 
> On Fri, Jul 29, 2016 at 7:52 PM, Ralf Quint <freedos...@gmail.com> wrote:
>> On 7/29/2016 5:04 PM, David McMackins wrote:
>>
>>> I have some modifications I'd like to make to PowerPaint as hosted on
>>> the FreeDOS archives, but I'm unable to compile the source. I'm
>>> attempting to use FreePascal to do the job, but it's failing to compile
>>> some of the units due to assembler syntax errors.
>>
>> Well, I can tell you exactly what the problem is: It is a Turbo Pascal
>> program, using the BGI (Borland Graphics Interface) library for the
>> graphics. That simply won't fly to compile in FreePascal, which is from
>> the get-go a 32bit compiler that can't handle the BGI graphics drivers.
> 
> Dunno. Are you trying to use Go32v2 or i8086-msdos target?
> 
>> Furthermore, any inline assembler, beside being 32bit, is by default in
>> AT syntax and not the Intel like syntax used in the Borland compilers...
> 
> I thought Intel was default for {$mode tp}? But it's not 100%
> compatible (yet?), no, so any low-level stuff might indeed have to be
> reworked. See the online docs:
> 
> http://www.freepascal.org/docs.var
> 
> http://www.freepascal.org/docs-html/current/prog/progch3.html#x144-1450003
> 
>> For all practical purposes, even there is now a 16bit x86 target option
>> for FreePascal, just trying to compile the sources without significant
>> re-working simply won't work...
> 
> The 16-bit "msdos" target is finally officially released/supported as
> of 3.0.0, but it's a cross-compiler only (and you still need NASM,
> WLINK, WLIB). Trunk (which has Win32 snapshots) doesn't need those
> tools anymore and also supports "huge" model. It's meant to be mostly
> (even binary??) compatible with TP, in theory, but so far it lacks in
> a few ways. (The only supported calling convention, last I heard from
> the wiki, is "pascal", not Delphi's "register" nor "cdecl").
> 
> http://wiki.freepascal.org/DOS
> 
> "[Large] is the memory model used by Turbo Pascal version 4 and above"
> "[Pascal] is the default calling convention. It strives for
> compatibility with Turbo Pascal 7"
> 
> --
> ___
> 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] Linux commands in DOS - Minibox

[David McMackins]

I was thinking the same thing. I've been writing my own set of UNIX
tools for DOS for personal use. I've written cat, head, wc, and split,
and I've made my own implementation of getopt which uses DOS-style flags
(begin with '/', use ':' to separate flag from argument) called
getswitch. I used WCC specifically for binary size and 16-bit
compatibility/efficiency.

Would anyone like me to publish these here in their own thread? If so,
are there any other commands that would be nice to add to them?

Only slightly related, I also wrote a utility for taking a split archive
spread across multiple diskettes, reassembling it, and unzipping it at
C:\. I made this as a backup utility for DOS games I have in case the
original diskettes fail. I can publish that as well if requested.


Happy Hacking,

David E. McMackins II
Associate Member, Free Software Foundation (#12889)
Life Member, National Rifle Association of America (#226579338)

www.mcmackins.org www.delwink.com
www.gnu.org www.fsf.org

On 05/25/2017 06:59 PM, Jim Hall wrote:
> On Thu, May 25, 2017 at 8:59 AM, Ercan Ersoy  wrote:
>>
>>> But looking at the source commited 20 minutes ago, it seems that no commands
>>> are yet implemented, it is only like a stub.
>>
>> Please read README. Also, Minibox includes commands in one executable file. 
>> (e.g. Busybox)
>>
>> Command Line: minibox command [arguments]
>>
>>> I am curious why it need DPMI and DJGPP for that? It is not enought Watcom 
>>> C++
>>> in 16 bit real mode?
>>
>> Because, Minibox porting for other platforms easily.
>>
> 
> 
> Minibox is an interesting project, but I wonder why implement
> everything in one large binary, just to execute simple commands. I
> know you are mimicking Busybox (above). But on a DOS system, it seems
> very resource heavy to load a large exe that requires DPMI to do
> commands like: (from the README)
> 
>   beep
>   cat
>   cd
>   clear
>   cp
>   date
>   echo
>   ls
>   mkdir
>   mv
>   pwd
>   rm
>   rmdir
>   sh
>   time
> 
> 
> Wouldn't it be easier and more resource efficient to implement these
> as small, individual programs? "cat" is not a very big program, for
> example.
> 
> --
> 
> There's an interesting parallel here, and I think this would make a
> good project for someone: Years ago, there was the "GNUish" project,
> which ported the GNU utilities to DOS. But eventually the project
> stalled. Before GNUish shut down, they reached out to me to mirror
> their files. You can find them here:
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/gnuish/
> 
> Info here:
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/gnuish/gnuish.htm
> 
> 
> I think it would be great for someone to pick up the GNUish project
> again. Port the GNU Utilities (ftp://ftp.gnu.org/gnu/) to FreeDOS
> using OpenWatcom, or DJGPP. This is likely challenging, as it will
> require creating wrappers for different functionality, workarounds for
> other functionality that doesn't (or can't?) exist on DOS, etc.
> 
> *That* is something that would be really interesting on FreeDOS! We
> already have some Unix-like programs in FreeDOS (cal, du, bc, grep,
> sed, ...) and a few utilities exist at DJ Delorie's repo, but AFAIK no
> one has created a comprehensive update to GNUish.
> 
> 
> Jim
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Compiling with gcc

[David McMackins]

But isn't bcc proprietary, thereby undermining the entire goal here?


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 11/18/2017 11:34 AM, Andreas K. Foerster wrote:
> Am Sonntag, dem 29. Okt 2017 schrieb Jim Hall:
> 
>> That said, I'd love to see other tools become part of FreeDOS. If
>> there was a DOS-native GCC that could generate 16-bit binaries in the
>> different memory models, I'm all for that.
> 
> The problem is not only in the code creation, but you also need some
> libc functions. The libc of DJGPP is tied to the protected mode (DPMI).
> The libc of OW has an incompatible license...
> 
> How do you think about porting some things to bcc?
> 
> It is quite easy with preprocessor macros to make code compatible
> with pre-standard compilers, without losing anything for modern
> compilers.
> 
> The FSF encourages this:
> https://www.gnu.org/prep/standards/html_node/Standard-C.html
> 
> I know some more tricks and quirks of bcc...
> If you want, I could try to write a small porting guide.
> 
> I don't have an overview about FreeDOS, so could you recommend
> some easy tools for the start, I should have a look at?
> 
> Bcc supports the small and tiny memory models. The libc is lacking,
> but you can write code in inline assembly, if you can, to add missing
> features. (I only know some few basics of assembler and DOS/BIOS.)
> 
> By the way, can anybody tell me, how to access environment variables,
> when the compiler doesn't support it? (no getenv() and environ=NULL)
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Compiling with gcc

[David McMackins]

On 10/29/2017 09:36 PM, Ralf Quint wrote:
> MS/PC-DOS predates the FSF, GPL and the Stallman virus. DOS itself (in
> pretty much any incarnation, up to and including FreeDOS itself) has
> always been depending on "less-than free" development tools.

So what? UNIX was 100% proprietary when it was created and also relied
on proprietary development tools. People who care about free software
wrote free replacements. As far as I know, this is also the reason for
FreeDOS.

Do you really mean to say that because DOS development has historically
relied on proprietary tools that their should be no drive to make free
replacements? Come on.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Compiling with gcc

[David McMackins]

On 10/29/2017 11:00 PM, Ralf Quint wrote:
> Well, I  happily invite you to provide us with a free development tool
> that will work in our case and fits your (IMHO) overly idealistic POV.

I'm the one who started this mail chain. It started as a mere inquiry
(on behalf of a friend, really) as to whether gcc would be a viable
compiler. I got my answer: it's not.

I never said that we should reject FreeDOS because it lacks an
FSF-approved compiler. I'm just saying that your particular reason for
not being concerned about it lacks substance. I think the real argument
to be made against trying to change now is the fact that this is a niche
system and simply will not attract the number of developers required to
make that a reality. It's an argument of feasibility, not principle, and
I accept that.

It has obviously been a goal for FreeDOS to be a fully free system, and
what's a free system if it has proprietary dependencies? I was made
aware of the -m16 flag, didn't know how new it was, and I asked the
people on this list who are more knowledgeable about building software
for DOS than I am if it would work. I am willing to accept that it's not
feasible to make a new compiler, but that doesn't mean we ought to be
fully content, that's all.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] VGA/VESA vblank interrupt?

[David McMackins]

Interesting! Thank you for researching this. Sadly, this guy's program
is just a binary. I would be curious to read it and see exactly how he
did it. I would like to implement a function to test if this works so
that programmers can use it when available or otherwise use polling.

The big concern here really is battery life on laptops. I learned from
Game Boy programming that polling is really taxing on batteries. You can
run (anecdotally) nearly 10 times as long if you use interrupts instead,
because the CPU can sleep until the next event is to be processed.
Having the CPU at max load trying to catch the vblank state is really
expensive from a power standpoint, even if it really makes no difference
from an execution speed standpoint. I suppose CPU heat might also be an
issue. Why risk damaging an old CPU because you're too lazy to set up an
interrupt?

Anyway, this forum post has given me some things to look into. I'll
report back if I find anything good.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 07/01/2018 08:05 AM, TK Chia wrote:
> Hello all,
> 
> I am also curious about this topic.  I found a recent thread on VOGONS
> (https://www.vogons.org/viewtopic.php?t=58445), where Scali and others
> found, after some experiments, that some x86 machines do support a
> vertical retrace interrupt, when the IRQ (usually IRQ 2) is properly
> enabled --- but not all support it.  I guess this is why many programs
> tend to use the polling method.
> 
> Thank you!
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] UNIX utilities, arg parser, installer software

[David McMackins]

Okay. Regardless, I just pushed updates to both archives that change the
build script to UPX pack the binaries.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 06/24/2018 12:05 PM, Jim Hall wrote:
> Or I suppose I could soft links on ibiblio, if that's where I put them.
> Then they would appear in different directories but only get saved once.
> It's not big, so that should be okay. 
> 
> On Sun, Jun 24, 2018, 9:50 AM David McMackins  <mailto:cont...@mcmackins.org>> wrote:
> 
> I suppose I could do that. I left them together for the simplicity of
> the build script.
> 
> What if I added a deploy script that created separate distributions for
> each one while keeping the source together?
> 
> 
> Happy Hacking,
> 
> David E. McMackins II
> Supporting Member, Electronic Frontier Foundation (#2296972)
> Associate Member, Free Software Foundation (#12889)
> 
> www.mcmackins.org <http://www.mcmackins.org> www.delwink.com
> <http://www.delwink.com>
> www.eff.org <http://www.eff.org> www.gnu.org <http://www.gnu.org>
> www.fsf.org <http://www.fsf.org>
> 
> On 06/24/2018 08:30 AM, Jim Hall wrote:
> > Thanks. Any chance to split up the Unix utilities separately, like we
> > have already done with the others?
> > http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/unix/
> >
> > On Sun, Jun 24, 2018, 6:01 AM David McMackins
> mailto:cont...@mcmackins.org>
> > <mailto:cont...@mcmackins.org <mailto:cont...@mcmackins.org>>> wrote:
> >
> >     I've hosted the source code here:
> >
> >     https://mcmackins.org/dl/dos/UTILSSRC.ZIP
> >     https://mcmackins.org/dl/dos/MDSAISRC.ZIP
> >
> >     The first archive has my UNIX utils and arg parser (since I
> used the arg
> >     parser for them), and the second has the installer.
> >
> >     No docs at this time. MDSAI probably needs a short doc before
> being
> >     published explaining the configuration. Basically in the first
> diskette
> >     there needs to exist MDSAI.INF which contains literally a
> number in
> >     ASCII text of how many diskettes make up the full archive. The
> >     executable can be named anything, so even though the build script
> >     creates MDSAI.EXE, you may want to rename to INSTALL.EXE when
> making a
> >     distribution.
> >
> >
> >     Happy Hacking,
> >
> >     David E. McMackins II
> >     Supporting Member, Electronic Frontier Foundation (#2296972)
> >     Associate Member, Free Software Foundation (#12889)
> >
> >     www.mcmackins.org <http://www.mcmackins.org>
> <http://www.mcmackins.org> www.delwink.com <http://www.delwink.com>
> >     <http://www.delwink.com>
> >     www.eff.org <http://www.eff.org> <http://www.eff.org>
> www.gnu.org <http://www.gnu.org> <http://www.gnu.org>
> >     www.fsf.org <http://www.fsf.org> <http://www.fsf.org>
> >
> >     On 06/24/2018 05:36 AM, Jim Hall wrote:
> >     > Excellent! Do you have a website you could post these to? If
> so, put
> >     > them there and share the link. If not, email me off list and
> we'll
> >     > arrange to get them to me so I can share them on our files
> archive at
> >     > ibiblio.
> >     >
> >     > I like the very permissive license, especially for a
> library. For
> >     those
> >     > who don't know this license, it's this:
> >     >
> >     > Copyright (c) ___
> >     >
> >     > Copying and distribution of this file, with or without
> modification,
> >     > are permitted in any medium without royalty provided the
> copyright
> >     > notice and this notice are preserved.
> >     >
> >     >
> >     > I'll be curious to see the command line parser. Did you write
> >     something
> >     > like getopt, or something new? FYI that there's a getopt here:
> >     >
> >   
>  
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/getopt/
> >     >
> >     &

Re: [Freedos-devel] UNIX utilities, arg parser, installer software

[David McMackins]

zipsplit is good, but it does have a limitation for single entries which
are too big for a single disk. The hard split can handle entries of any
size.

When thinking about backups and recovery, zipsplit definitely seems
better since it has the possibility of partial recovery. My program was
designed with deployment in mind. Create the disks from a source, then
take immediately to the installation target.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 06/24/2018 03:23 PM, Jim Hall wrote:
>> On Sat, Jun 23, 2018 at 8:09 PM, David McMackins  
>> wrote:
>>>
>>> Finally, I also wrote a program called the Multi-Disk Split Archive
>>> Installer (MDSAI) which is an installer program designed for deploying
>>> software too big for a single floppy disk. You put the installer on the
>>> first diskette, along with a file that describes what's being installed,
>>> and then on each diskette, have a sequential piece of a ZIP archive.
>>> MDSAI will cat them together and then extract in the C drive.
> 
> 
> On Sun, Jun 24, 2018 at 2:50 PM, Rugxulo  wrote:
>> Sounds good. Now, don't take this the wrong way, but 
>>
>> PKZIP already had split disk support. I don't remember if Info-Zip
>> ever fully added it. I think their workaround was some tool to
>> manually make separate .ZIPs (if possible) of a certain size. That is,
>> fully intact .ZIPs that don't need special tools to reconstruct.
> [..]
> 
> There's also Zipsplit, part of Info-Zip's Zip original package. As the
> name suggests, you can use it to split up a zip file into smaller
> chunks, like what would fit on separate floppies. As a test, I created
> a DOS test.zip file that was 17k, and split it at the 10k threshold,
> so I had one test1.zip file just a little bit under 10k and another
> test2.zip file at 7k. You can unzip each separately. It's easy.
> 
> Zipsplit also lets you leave a certain amount of room on the first
> "disk," such as for an installer program (that is, the first split zip
> file won't take up the full size amount).
> 
> jh
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreeDOS PASSWORD executable size

[David McMackins]

I've noticed that PASSWORD is written for FreePascal, but the executable
in the distribution is only 8k in size. When I compile myself, it is
60k. How is it being stripped to that small size?

Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] UNIX utilities, arg parser, installer software

[David McMackins]

In my playing about with FreeDOS, I wrote my own versions of cat, head,
wc, and split.

For these, I also wrote a small library for parsing command-line options
in a typical DOS-like fashion.

Finally, I also wrote a program called the Multi-Disk Split Archive
Installer (MDSAI) which is an installer program designed for deploying
software too big for a single floppy disk. You put the installer on the
first diskette, along with a file that describes what's being installed,
and then on each diskette, have a sequential piece of a ZIP archive.
MDSAI will cat them together and then extract in the C drive.

I wrote these for myself. They may need to be modified or have new
options before they are ready for others to use. If you are interested
in these, let me know where I should publish them. I'm releasing them
all under the GNU All-Permissive License.

Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] VGA/VESA vblank interrupt?

[David McMackins]

I'm new to graphics programming on DOS. My experience programming
graphics on PC is on modern systems where I can use a library that
handles all low-level calls for me. I know about Allegro, but it's kind
of fat and I don't think it supports 16-bit.

Anyway, I'm figuring out VGA and VESA graphics programming, but one
thing I can't find is how to wait for an interrupt to tell me when the
vblank period starts so that I can vsync. On the Game Boy, for instance,
there is a flag you can set which enables certain interrupts from the
hardware, and you specify a function to be called on those interrupts.
One of these is the vblank interrupt, which gets thrown once every frame
so that the program knows when it is safe to draw.

All the tutorials I can find online just use a while loop to constantly
poll for the vblank state, but that seems very inefficient and could
make it cumbersome to consider other types of interrupts.

Surely there is a way, but I don't know where to look. Also, what about
interrupts for mouse movement, etc.? Where is a good place to learn
about this kind of thing, or perhaps a book to recommend?

Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Compiling with gcc

[David McMackins]

I have been informed that gcc has a -m16 flag that actually outputs
binaries that can run in 16-bit mode. Is there then anything stopping
FreeDOS from being compiled fully with gcc?

If not, why are we still using Watcom?

Happy Hacking,

David E. McMackins II
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.gnu.org www.fsf.org

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] irc oper required at #freedos

[David McMackins]

Might pop by #freedos on there at some point if other people go there 
:)


I idle in there. I had asked before if anyone on the mailing list was 
there but it appeared no one was.



Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 2018-08-02 10:40, Kenway, Owain wrote:

Hi,

It's not just #freedos, the whole of Freenode has been under attack (I
didn't even realise there was a #freedos on there - I use it to talk
to other HPC people):

https://freenode.net/news/spambot-attack

Might pop by #freedos on there at some point if other people go there 
:)


Cheers,
Owain

--
/UCL/ISD/RITS/RC Applications & Support Team Leader/Owain Kenway
Twitter: @owainkenway   || E-mail: o.ken...@ucl.ac.uk
Internal: 59834 || External: 02031089834
The Green Zone, 1 St Martin's Le Grand, London, EC1A 4NP


From: Jim Hall 
Sent: 02 August 2018 15:52
To: Technical discussion and questions for FreeDOS developers.
Subject: Re: [Freedos-devel] irc oper required at #freedos

Thanks Steve, very helpful.

Having a little more time to research: looks like +q effectively
bans(?) users from chatting, except for matching users. And the $~a
pattern seems to match registered users?

At least, that's what I get from reading jjasghar's channel operator
quick reference
and freenode's channel
modes document.

Another note from jjasghar's
page says "if
you are overwhelmed, you can regain some stability by muting
unregistered users with /mode #reddit-diabetes +q $~a while you ban
the ip addresses that the troll is wielding." So that suggests when
Mdasoh said "we have had an enjoyable time hanging out in
#freedos/irc.freenode.net [..] until the day
before yesterday" that the day before yesterday the #freedos channel
on irc.freenode.net got spammed and/or
trolled? I am not usually on IRC, so I hadn't heard of this.






On Thu, Aug 2, 2018 at 6:34 AM, Steve Nickolas
mailto:usots...@buric.co>> wrote:
On Thu, 2 Aug 2018, Jim Hall wrote:

Hi!

So, what happened on IRC the day before yesterday?

I'm afraid you've lost me with the other IRC stuff you mention. I don't
know what "/mode #freedos +q $~a" does. Is that something visitors on 
IRC
would do in their clients, or is this an IRC server setting? (Note that 
I

don't run the IRC server at freenode.)

It's a channel mode.  (I don't know what it does because over on
Hoshinet we use Unrealircd, which does things different from whatever
Freenode's current ircd is.)

Also not sure what "irssi scripts" do. Again, is this something for the 
IRC
clients, it something in the server? I looked at the scripts you linked 
to

but don't know enough about IRC to know what I'm looking at.

irssi is an IRC client for Linux.  I suppose the scripts in question
are to make channel management easier.

(For what it's worth, about 6 years ago I wrote an IRC client for DOS.)

-uso.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Larger buffers in Watcom

[David McMackins]

I found the bad code. While your example works, if I change it to use
calloc (which is what my code is using at the particular failure point),
then it fails. Looks like calloc is doing something funny.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 07/28/2018 12:31 PM, Mateusz Viste wrote:
> On Sat, 28 Jul 2018 11:49:42 -0500, David McMackins wrote:
>> Is there a way to allocate a buffer in OpenWatcom that is larger than
>> 64k?
> 
> Sure. Either use XMS/EMS, or rely on the "huge model" kludge.
> 
>> I'm currently trying to stay within the compact memory model, but
>> even if I compile for huge memory model, I'm getting an out of memory
>> error for trying to allocate about 80k for a buffer.
> 
> Either your code is bad or you truly do not have any available block of 
> 80K contiguous conventional RAM.
> 
> I tested it right now with the code below, and it works as expected 
> (prints "success!"):
> 
> /* compile: wcl -0 -mh -os -lr test.c */
> #include 
> #include 
> 
> int main(void) {
>   char *buf;
>   buf = malloc(81920l);
>   if (buf == NULL) {
> printf("oops\n");
>   } else {
> buf[8l] = '!';
> buf[80001l] = 0;
> printf("success%s\n", buf + 8l);
> free(buf);
>   }
>   return(0);
> }
> 
>> My machine has 128M
>> of memory, so I'm not actually running out of memory.
> 
> That is irrelevant, since we are talking conventional memory here.
> 
>> This code works
>> fine under DJGPP, so I know my hardware is capable.
> 
> Apples and oranges. DJGPP is protected mode, while you are using real 
> mode.
> 
> Mateusz
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Fwd: Larger buffers in Watcom

[David McMackins]

Perhaps I should clarify that by "buffer" I just mean some space on the
heap allocated via malloc()


 Forwarded Message 
Subject: Re: [Freedos-devel] Larger buffers in Watcom
Date: Sat, 28 Jul 2018 18:55:31 +0200
From: Eric Auer 
To: David McMackins 


Hi David,

maybe there is a misunderstanding in the meaning of buffer
between you (general memory allocation) and the compiler
(maybe uses buffers for something specific only, eg DMA)?

Or you selected a memory model with real mode pointers or
pointers with 16 bit offsets? Probably you can nevertheless
allocate multiple memory blocks of max 63.99k each?



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Larger buffers in Watcom

[David McMackins]

Is there a way to allocate a buffer in OpenWatcom that is larger than
64k? I'm currently trying to stay within the compact memory model, but
even if I compile for huge memory model, I'm getting an out of memory
error for trying to allocate about 80k for a buffer. My machine has 128M
of memory, so I'm not actually running out of memory. This code works
fine under DJGPP, so I know my hardware is capable.

Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Compiling EDIT with free software

[David McMackins]

While I was doing something else, I went on a tangent that led me to
look at the FreeDOS EDIT source code. I noticed some problems.

The first of these problems is that it appears at first glance EDIT has
a build dependency on Borland C. At least, there isn't a build script
for any other compiler. I think it was last packaged before Watcom was
the official preferred C compiler. I think it would be very important to
try and port it to Watcom for the next version of FreeDOS at least.

Next, it depends on the DFlat+ library, which I failed to find in the
software archives! I have an old copy of it from the FreeDOS 1.1
archives, but how is anyone new supposed to build this program without
its primary dependency?

Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Compiling EDIT with free software

[David McMackins]

I currently have 4 projects in my queue for NEW programs for DOS. Once I
finish those, I'd be happy to collaborate in translating the base system
to Watcom.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 08/11/2018 01:32 PM, Jim Hall wrote:
> For at least several months, I've had this on the Contribute page:
> http://www.freedos.org/contribute/
> 
>   * Port FreeDOS utilities to OpenWatcom C and NASM (currently our
> preferred C compiler and Assembler for FreeDOS)
> 
> 
> So we're trying to encourage folks to Port these programs to an open
> source compiler. But as Tom said, many devs use whatever is their
> favorite compiler. That said, I'd like to see folks port these to the
> open source tools.
> 
> On Sat, Aug 11, 2018, 9:45 AM David McMackins  <mailto:cont...@mcmackins.org>> wrote:
> 
> While I was doing something else, I went on a tangent that led me to
> look at the FreeDOS EDIT source code. I noticed some problems.
> 
> The first of these problems is that it appears at first glance EDIT has
> a build dependency on Borland C. At least, there isn't a build script
> for any other compiler. I think it was last packaged before Watcom was
> the official preferred C compiler. I think it would be very important to
> try and port it to Watcom for the next version of FreeDOS at least.
> 
> Next, it depends on the DFlat+ library, which I failed to find in the
> software archives! I have an old copy of it from the FreeDOS 1.1
> archives, but how is anyone new supposed to build this program without
> its primary dependency?
> 
> Happy Hacking,
> 
> David E. McMackins II
> Supporting Member, Electronic Frontier Foundation (#2296972)
> Associate Member, Free Software Foundation (#12889)
> 
> www.mcmackins.org <http://www.mcmackins.org> www.delwink.com
> <http://www.delwink.com>
> www.eff.org <http://www.eff.org> www.gnu.org <http://www.gnu.org>
> www.fsf.org <http://www.fsf.org>
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> <mailto:Freedos-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Does Digital Mars C/C++ compiler able to compile FreeDOS kernel, FreeCOM, and others?

[David McMackins]

And that means you still have to pay
$59 to get the source code for the compiler, which I think, regardless
of license, doesn't really qualify as ' more "free" than
OpenWatcom'...


Not really. If it's under a free (as in freedom) license, then only one 
person (or many pooling together) needs to put up the cash to get one 
copy, then they can give it away.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 2018-08-23 13:01, Ralf Quint wrote:

On 8/23/2018 7:47 AM, Roy Tam wrote:

Hi all,

Since Digital Mars C/C++ compiler can target DOS16, and they
relicensed compiler in Boost license, which is more "free" than
license that OpenWatcom uses currently, I wonder if core components
like kernel, FreeCOM, or accessories like EDIT can be compiled with
DMC?

Do you have a link stating that Walter Bright changed the license on
his C(++) compiler?
All I see on his web site is the same as it was when I downloaded the
last version about a year ago. And that means you still have to pay
$59 to get the source code for the compiler, which I think, regardless
of license, doesn't really qualify as ' more "free" than
OpenWatcom'...

On 8/23/2018 7:59 AM, Tom Ehlert wrote:

long time ago (before even WATCOM existed as a free compiler), I tried
this and failed, as some critically required segment directives were
missing. 15 years later, this may have changed.

good luck when trying this.

Having known and used the Zortech/Zorland compiler "way back when...",
I looked into the re-release of the Digital Mars compiler (<10 years
ago) and it worked just fine for "regular" programs, though I did not
try to use it against  the kernel or FreeCOM.
But then the source code for the compiler isn't openly available and
hence a lot of those infected with the Stallman virus would object
anyway, so I have not looked any further into it, beside occasionally
downloading a newer version of the C compiler and the DOS related
libraries...

Ralf

Ralf

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Does Digital Mars C/C++ compiler able to compile FreeDOS kernel, FreeCOM, and others?

[David McMackins]

A lot of this is petty nonsense, but I'll humor you anyway.

> Walter is still charging
> for the source code, which by the very fact is contradictory to any
> Open Source/"free" software idea.

If you have a naive understanding of the way those terms are used
nowadays, yes. I implore you to read the definitions of open source and
free software given by the OSI and FSF, and you will find nothing
prohibiting charging fees for copies, and indeed you may find encouragement.

> And the "one guy pays, everyone else plays"
> statement you made is totally bollocks, and you should know it.

Bollocks in what sense? In a legal sense, you couldn't be more wrong.
Now you do say that you're not an attorney, so perhaps you should talk
to one about the terms of the license in question. I assure you they
will fall on my side. By the letter of the license, this absolutely is
legit. Now, if you think it's silly to have terms allowing such a
situation to occur, that's a completely different argument that I'm not
interested in having.

I would also accept criticism if you could identify an instance in which
I had a 'holier than thou' attitude on this mailing list. I do prefer
free software to proprietary, and I have expressed before my interest in
making and using only free software, but I don't believe I have ever
pretended to be above other users who don't. On the contrary, it is you
who come across as a condescending elitist in this thread, and your
seniority in the project has no bearing on the facts being discussed.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 08/25/2018 04:15 PM, Ralf Quint wrote:
> On 8/24/2018 4:48 AM, David McMackins wrote:
>>> in that case, you are showing acute symptoms of stallmanitis.
>> You can use slurs all you want. I'm citing an accepted definition to
>> clear a misconception. By the way, I don't even like Richard Stallman,
>> and I won't be part of the FSF much longer.
> Well, ever since you got on this mailing list, you are making statements
> that are showing the clear symptoms of the Stallman virus, with a "I am
> holier than you" attitude when it comes to tools and applications
> related to FreeDOS. There simply is an ever growing disconnect between
> what Stallman and the FSF are trying to promote and real life. Some
> people understand this, some don't. Or take a really long time to
> realize that...
>> FreeDOS claims to be a free
>> system with all software released under "open source" licenses (which
>> was a term invented in an attempt to make the "free software" term less
>> confusing and more friendly to businesses).
> FreeDOS is perfectly free/open source. You have the source and can
> modify it, improve it. But as it has been shown in the +20 years that I
> am following this project (doubt that there is anyone but Jim Hall
> active on here who is participating longer than me by now) that there is
> only an extremely limited number of people that are really active. Or
> stay around for a prolonged period of time. And a lot of folks that join
> lately (well, for at least the last 10 years), seem to see FreeDOS as a
> second coming of Linux or the like, hardly understanding the differences
> between DOS and later OS. And that quite frankly shows.
>>
>> Anyway, all I noticed is that someone made a claim that this compiler
>> couldn't have been released under the Boost license because the original
>> site is still asking a fee for a copy of the source. Because the Boost
>> license is a free license, we can already toss out this claim, because
>> it goes against the definition without even having to get into the
>> specifics. The FSF, OSI, and others have already done the looking for us.
> What the FSF/OSI might have done is to see if that license (like sooo
> many before) is fitting their agenda or not. What I was questioning was
> why the supposed change in license was not mentioned anywhere on the
> Digital Mars web site, while on the same site, Walter is still charging
> for the source code, which by the very fact is contradictory to any Open
> Source/"free" software idea. And the "one guy pays, everyone else plays"
> statement you made is totally bollocks, and you should know it.
>> It may very well be the case that this compiler has not actually been
>> relicensed under the Boost license, but the fee is not evidence of this.
> You're still kidding. The best explanation, as the web site has not been
> updated for almost a year, since the release of the 8.57 version of the
> basic compiler, that the web site also has not been update

Re: [Freedos-devel] Does Digital Mars C/C++ compiler able to compile FreeDOS kernel, FreeCOM, and others?

[David McMackins]

> Sorry David, but you are naive at best.

Except that I'm actually very well read on this subject, and I know what
I'm talking about. If you think that I'm wrong, present a real argument.
Just saying "but you're wrong" isn't an argument. I can go through that
license line by line if you need that and prove my case. Show me where
in the license the situation I described is prohibited.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 08/25/2018 10:21 PM, Ralf Quint wrote:
> On 8/25/2018 4:22 PM, David McMackins wrote:
> ...
> Sorry David, but you are naive at best. And I leave it at that...
> 
> Ralf
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> 
> --
> 
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Does Digital Mars C/C++ compiler able to compile FreeDOS kernel, FreeCOM, and others?

[David McMackins]

> You're kidding, right?

Um, no I'm not kidding. You should read any one of the free licenses on
this list:

https://www.gnu.org/licenses/license-list.html#SoftwareLicenses

For any given one of them, whoever is distributing it is allowed to
charge a fee, and then the recipient may distribute at their own will or
for a fee of their own. That is in the definition of free software.

If you don't like the FSF, try the OSI:
https://opensource.org/licenses/category

Or Copyfree: http://copyfree.org/standard/licenses

This is what "free software" (as a technical term) has meant for decades.

Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 08/24/2018 01:39 AM, Ralf Quint wrote:
> On 8/23/2018 11:42 AM, David McMackins wrote:
>>> And that means you still have to pay
>>> $59 to get the source code for the compiler, which I think, regardless
>>> of license, doesn't really qualify as ' more "free" than
>>> OpenWatcom'...
>>
>> Not really. If it's under a free (as in freedom) license, then only
>> one person (or many pooling together) needs to put up the cash to get
>> one copy, then they can give it away. 
> You're kidding, right?
> 
> Ralf
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> 
> --
> 
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Does Digital Mars C/C++ compiler able to compile FreeDOS kernel, FreeCOM, and others?

[David McMackins]

> in that case, you are showing acute symptoms of stallmanitis.

You can use slurs all you want. I'm citing an accepted definition to
clear a misconception. By the way, I don't even like Richard Stallman,
and I won't be part of the FSF much longer. FreeDOS claims to be a free
system with all software released under "open source" licenses (which
was a term invented in an attempt to make the "free software" term less
confusing and more friendly to businesses).

Anyway, all I noticed is that someone made a claim that this compiler
couldn't have been released under the Boost license because the original
site is still asking a fee for a copy of the source. Because the Boost
license is a free license, we can already toss out this claim, because
it goes against the definition without even having to get into the
specifics. The FSF, OSI, and others have already done the looking for us.

It may very well be the case that this compiler has not actually been
relicensed under the Boost license, but the fee is not evidence of this.


> still annoying.

Get over it. No one's forcing you to read it, and it doesn't get in the
way of the actual message. It's an email signature, and almost everyone
has had them for a long time.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 08/24/2018 06:39 AM, Tom Ehlert wrote:
> 
> 
>>> You're kidding, right?
> 
>> Um, no I'm not kidding.
> 
> you are not kidding, because it's not even remotely funny.
> 
> in that case, you are showing acute symptoms of stallmanitis.
> 
> 
>> Happy Hacking,
> 
>> David E. McMackins II
>> Supporting Member, Electronic Frontier Foundation (#2296972)
>> Associate Member, Free Software Foundation (#12889)
> 
>> www.mcmackins.org www.delwink.com
>> www.eff.org www.gnu.org www.fsf.org
> 
> still annoying.
> 
> Tom
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] VGA frame rates and mouse

[David McMackins]

I've discovered something weird (to me). I'm on a 1998 Sony Vaio with a
Pentium 3 processor running FreeDOS 1.2. I have a test program which
draws 64 full frames to the screen via VGA mode 13h. Each frame is a
different color to force a full redraw. In addition, I draw a 1-pixel
mouse cursor onto the frame buffer before copying.

I regulate the frame rate by explicitly waiting for the vblank period
before doing the buffer copy to VRAM. Normally, my program gets a frame
rate of about 15fps. This seems a bit slow given my processor speed.
However, I've noticed if I am moving the mouse, the frame rate doubles
to nearly 30fps.

I've done some testing to try and identify the cause. I've determined
that it has nothing to do with the way I'm handling the mouse in my
program, because even if I never initialize the mouse in my program,
this still happens, and it stops happening (always low frame rate) if I
unload CuteMouse before running the program.

This is with a PS/2 mouse and the laptop's trackpad, which I think is
also a PS/2 device since when I tell CuteMouse not to load from serial,
it still loads the trackpad.

Any idea what's causing this? I'd like my program to run at the highest
frame rate the hardware can manage while still obeying the display's
refresh rate.

Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] VGA frame rates and mouse

[David McMackins]

Check earlier emails. The issue was related to a BIOS power setting. The
CPU was being throttled because of "no activity".


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 07/20/2018 01:17 AM, Ralf Quint wrote:
> On 7/19/2018 12:34 PM, David McMackins wrote:
>>> so basically you want to find out how fast you can
>>> update blocks of 64 000 pixels
>>
>> I never said that. I wanted to find out why my frame rate was
>> dependent on the mouse activity. 
> Without seeing the actual source code, my best WAG is that there us a
> logic error regarding updating the mouse cursor (or) not...
> 
> Ralf
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> 
> --
> 
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Check if VGA is available

[David McMackins]

The EGA check does not come back positive on my VGA machine. Is this 
expected?



Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 2018-07-16 10:26, Jerome Shidel wrote:

:-)

On Jul 16, 2018, at 11:11 AM, Mark Olesen 
wrote:


https://github.com/shidel/DustyTP7/blob/master/INFO/INFO.PAS [1]


Wow, that’s some ancient Pascal code. Pretty sure it pre-dates
FreeDOS and the Internet.

LOL

It’s been so long. If I recall correctly, it was made with
information in “The Ultimate DOS Programmers Manual”, a really
good EGA/VGA book I no longer have and some info gleamed from HelpPC.

I think some of the check functions no longer work properly on modern
hardware. (To many changes).

But, most of it should still be useful.


On Mon, Jul 16, 2018 at 9:08 AM, Mark Olesen 
wrote:

https::/gitub.com/shidel/DustyTP7/blob/master/INFO/INFO.PAS [2]

On Mon, Jul 16, 2018 at 4:51 AM, David McMackins
 wrote:
I'm doing some graphics programming, and I want to support many
different graphics modes, but I need a way of checking to see if
they
are available. Currently I'm working on VGA. How do I check if it's
available without just trying to enter graphics mode?

Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org [3] www.delwink.com [4]
www.eff.org [5] www.gnu.org [6] www.fsf.org [7]



--

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org [8]! http://sdm.link/slashdot [9]
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel [10]





--

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org [8]! http://sdm.link/slashdot [9]



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



Links:
--
[1] https://github.com/shidel/DustyTP7/blob/master/INFO/INFO.PAS
[2] http://gitub.com/shidel/DustyTP7/blob/master/INFO/INFO.PAS
[3] http://www.mcmackins.org
[4] http://www.delwink.com
[5] http://www.eff.org
[6] http://www.gnu.org
[7] http://www.fsf.org
[8] http://Slashdot.org
[9] http://sdm.link/slashdot
[10] https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Check if VGA is available

[David McMackins]

I was replying to Jerome who is the original author of the Pascal one.

I get that VGA is widely available. I'm writing a library, so I want to 
support as much as possible. My intended targets (in the order of 
planned implementation) are VGA, VESA, CGA, and EGA. I want to have 
contained tests for each of them (and separate for different VESA modes, 
but I already have a document on doing that) so that an application 
could list to the user all the supported modes for their hardware.



Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 2018-07-16 13:52, Eric Auer wrote:

Hi David,


The EGA check does not come back positive on my VGA machine.
Is this expected?


We suggested several: Do you mean the Pascal one suggested
by Mark, the PC Mag one suggested by Mateusz, or the ones
suggested by me? If all of them, then I would say NO, this
is not expected. If SOME of them, then I suggest that you
simply use those which work ;-)

Also, I think it is sufficient to have a good VGA test:

Only weird people like me still have EGA boards in some
dusty cardboard boxes. So you could say "either use VGA
or fall back to text mode" without risking much harm ;-)

Regards, Eric

PS: Does anybody know a computer museum? I know people with
way more exotic stuff who would be interested to SELL some!


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] VGA frame rates and mouse

[David McMackins]

If you think you can do ti with subtraction and bit-shifting (without
requiring MMX or something similar) please show it to us.


With multiplication:

new_mask = color & alpha_mask;
new_mask >>= 6;
new_mask *= 0x7F;

Without multiplication:

new_mask = color & alpha_mask;
new_mask <<= 1;
new_mask -= new_mask >> 7;

This gets the same result with only two shifts and a subtraction.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 2018-07-23 13:15, Bret Johnson wrote:

Multiple issues. First, if you're going to do it in "pure C", you
can't depend on anything like MMX. You're going to need to virtualize
the multiple-byte-functions-at-the-same-time manually, taking
advantage of CPU and data storage characteristics (little-endian,
two's complement, etc.). That pretty much defeats the purpose of
sticking with "pure C".

What you're trying to avoid is (conditional) JMPing and
multiplication/division, since they are costly in terms of speed, even
though they will work just fine. You are probably also going to want
to minimize the number of loops, since loops are also a type of JMP.
But, in modern CPU's with caches and branch prediction and pipelining
and similar enhancements, loops generally aren't that bad in terms of
overall speed. Any kind of speed or size optimization you do in C
(whether it's the compiler doing the optimization or you doing it
manually) again depends on specific CPU characteristics and features,
and again defeats the purpose of using "pure C".

If you think you can do ti with subtraction and bit-shifting (without
requiring MMX or something similar) please show it to us.


'GENIUS' PILL - TOP 1% DIDN'T WANT THE PUBLIC TO KNOW ABOUT
The Brain Insider
http://thirdpartyoffers.juno.com/TGL3142/5b561b7888f711b787b75st03vuc
[1]


Links:
--
[1] 
http://thirdpartyoffers.juno.com/TGL3142/5b561b7888f711b787b75st03vuc


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] VGA frame rates and mouse

[David McMackins]

I have two oppositions to this. First, I'd like to be able to do this in 
pure C. Second, this appears to be a byte-level operation, but the whole 
point of doing this is to work on multiple bytes simultaneously.


I think I might be able to do it with a subtraction and two bitshifts, 
though. Think that would be meaningfully faster?



Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 2018-07-23 11:44, Bret Johnson wrote:

One way around this might be to use CBW, which essentially copies the
high bit of AL into all the bits of AH. Using your example, if this is
the value in AL:

0100
 ^ the alpha bit

You can put a saturated mask in AH with two instructions:

SHL AL,1

CBW

Or put a saturated mask in AH and leave AL unchanged with three
instructions:

ROL AL,1

CBW

ROR AL,1

Those instructions will work even on an 8086 CPU.


UNDERGROUND TREATMENT MELTS TUMOR WITH NO CHEMO (WATCH)
pro.allianceforadvancedhealth.com
http://thirdpartyoffers.juno.com/TGL3142/5b560616f196e6162acbst04vuc
[1]


Links:
--
[1] 
http://thirdpartyoffers.juno.com/TGL3142/5b560616f196e6162acbst04vuc


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] VGA frame rates and mouse

[David McMackins]

>>> 1) new pixels = (old pixels & mask1) | (new pixels & mask2)
>>>
>>> Where mask1 and mask2 are the negated forms of each other.
>
> That one only works for boolean masks, but it works on 386.

By boolean mask, do you mean something like all 1s over the colors for
opaque and all 0s for transparent? The way I've got it now is just 1 bit
in the color byte represents opacity. It's either opaque or transparent,
and then the remaining bits are for colors.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 07/22/2018 06:41 PM, Eric Auer wrote:
> 
> Hi David,
> 
>>> 1) new pixels = (old pixels & mask1) | (new pixels & mask2)
>>>
>>> Where mask1 and mask2 are the negated forms of each other.
> 
> That one only works for boolean masks, but it works on 386.
> 
>>> This even works for alpha masks:
>>>
>>> 2) new pixels = (old pixels "*" mask1) "+" (new pixels "*" mask2)
> 
> That one needs a CPU and compiler which supports at least MMX
> or some newer vector unit, so you are right that there is no
> effective way to do this on 386 with real alpha masking.
> 
> You are right that you could first check your mask for areas
> which can be done the 1) boolean way and then only do the more
> costly computations with multiplications for those pixels where
> the mask is neither 0.0 nor 1.0, but whether that really helps
> will depend on which fraction of your pixels has 0.0 or 1.0
> (or 0 and 100 percent, if you prefer) alpha masks and which
> fraction has more complicated values...
> 
> Regards, Eric
> 
> PS: As http://locklessinc.com/articles/sat_arithmetic/ shows,
> even saturated addition is tricky to do without having actual
> hardware support for it (MMX has saturated operations, too).
> 
> Also notable: http://locklessinc.com/articles/booleans/
> (testing for 0, 1 or -1)
> 
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] VGA frame rates and mouse

[David McMackins]

> 1) new pixels = (old pixels & mask1) | (new pixels & mask2)
>
> Where mask1 and mask2 are the negated forms of each other.
> This even works for alpha masks:
>
> 2) new pixels = (old pixels "*" mask1) "+" (new pixels "*" mask2)

I understand what you're going for in principle, but I'm not sure what
magic you're trying to do. The computation for number 1 above doesn't
actually work. This just returns what new_pixels was except with the
alpha value of old_pixels.

So far the best way to do this I can think of is to do a multi-byte
alpha check, and then if any one of the bytes fails, go through one byte
at a time to find the offending one so that it is not written, and then
proceed.

I've been pulling my hair out all day today trying to come up with a way
to do this without byte-level checking.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 07/19/2018 03:21 PM, Eric Auer wrote:
> 
> Hi David,
> 
>>> so basically you want to find out how fast you can
>>> update blocks of 64 000 pixels
>>
>> I never said that...
> 
> What I mean is that you changed ALL pixels to make
> sure to know what the frame rate in the WORST case
> is, when ALL 320 x 200 pixels actually need updates.
> 
>>> You probably want to optimize that copying routine.
> 
>> Not sure what that is.
> 
> Some people do really heavy tweaking to speed up games:
> 
> http://archive.gamedev.net/archive/reference/articles/article817.html
> 
> Note that this is sort of outdated, as most game people
> now worry about optimum use of 3d graphics chipsets.
> 
>>> In C, you can at least use logic calculations, to
>>> avoid having to do "if then" for every single pixel.
> 
>> Not sure what you mean here.
> 
> Roughly the following: If necessary, you first expand your
> transparency mask into a format which has one byte per pixel.
> 
> Then you negate the mask to get a one byte per pixel mask of
> the opposite of transparency. Then you compute something like
> 
> 1) new pixels = (old pixels & mask1) | (new pixels & mask2)
> 
> Where mask1 and mask2 are the negated forms of each other.
> This even works for alpha masks:
> 
> 2) new pixels = (old pixels "*" mask1) "+" (new pixels "*" mask2)
> 
> The trick is that you can do all operations using data
> types which are big enough for SEVERAL PIXELS. It means
> you can calculate the updated values for for example
> FOUR pixels in ONE step. For the alpha mask version,
> this requires the ability to treat a 32 bit value as
> a vector of four 8 bit values. This is exactly what
> MMX does: Like a floating point coprocessor which is
> specialized on floating point calculations, MMX is
> a CPU component which is specialized on vectors :-)
> So the "*" and "+" must work on "bytes in a longer
> data type". A normal 386 "add" or "mul" would fail.
> 
> Note that MMX uses 64 bit values and never stuff such
> as SSE uses even longer values, so you can do yet more
> pixels in parallel :-) The problem is that MMX, SSE and
> other things are often not well supported by compilers
> so you would have to manually write special code.
> 
> HOWEVER, the first (non-alpha) variant which only has
> yes / no decisions works with ALL COMPILERS which have
> a 32 bit integer data type :-) Of course it only gives
> you the expected speed when the compiler knows how to
> use 32 bit integers efficiently on 386 and newer CPU.
> 
>> Maybe I need to check again, but I'm pretty sure VGA RAM
>> is considered outside my allocated memory.
> 
> In DJGPP, you can request a mapping of the VGA RAM to
> a normal pointer. Then you can use it as if it would
> be part of your allocated memory. Using macros for a
> low level global memory peek or poke is much slower.
> 
> Here are some snippets from an old program of mine:
> 
> #include  /* stuff with __dpmi_... names */
> #include  /* int86, union REGS */
> #include  /* things like inportb() */
> #include  /* in case you want to access _dos_ds */
> #include  /* e.g. _farpeekb(_dos_ds or other, offset) */
> 
> __dpmi_meminfo memory_mapping;
> int lfbSel;
> 
> memory_mapping.address = vesamode.lfbPTR; /* physical linear address */
> memory_mapping.size = ( (vesamode.bytes_line * vesamode.height)
>  + 65535) & (uint32)0x;/* round up to multiple of 64k */
> 
> For VGA, you would just say address=0xa, size=0x1, obviously.
> 
> __dpmi_physical_address_mapping(_mapping); // fail if != 0
> __dpmi_lock_linear_region(_mapping);
> 
> // for memory below 1 MB, this just made 1:1 mappings,
> // but you SHOULD use the LDT to stay more compatible:
> 
> lfbSel = __dpmi_allocate_ldt_descriptors(1); /* alloc 1 slot */
> __dpmi_set_segment_base_address(lfbSel, memory_mapping.address);
> __dpmi_set_segment_limit(lfbSel, memory_mapping.size - 1);
> 
> Now you can use _farpokeb(lfbSel, offset, value) for single
> bytes, _farpokew(...) 

Re: [Freedos-devel] VGA frame rates and mouse

[David McMackins]

I'll take a look at that. An idea I came up with last night while I was
asleep was a method that uses my current encoding.

With 4 pixels loaded in a 32-bit register:

AND the input pixels with the alpha mask
SHR this result so that the bit is in position 0
Multiply so that this bit is expanded to a full byte of 1s
AND the input and screen with this mask
OR the modified input onto the screen

I'm trying to think of how I may be able to skip something near the end,
but this is pretty good so far I think.



Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 07/23/2018 05:27 AM, Eric Auer wrote:
> 
> Hi, just a quick extra idea: You could read about
> the PCX file format for 8-bit colors and define one
> color to be "opaque". Then you can store your image
> in PCX format in RAM and do run length coded BLOCKS
> of either overwriting or not overwriting pixels on
> screen, without needing per-pixel decisions at all!
> 
> https://www.fileformat.info/format/pcx/egff.htm
> 
> Note that PCX compression uses values 192 to 255
> for special codes, so it helps to optimize your
> palette to use mainly pixel colors 0 to 191...
> 
> Regards, Eric
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] VGA frame rates and mouse

[David McMackins]

The multiplication does appear to be costly indeed. I'm now trying to
find a way to get around it. I'll explain the method using a 1-byte
example, but the logic scales up:

Our dear color:

0100
 ^ the alpha bit

Alpha mask:

0100

The color on screen doesn't matter, as will be demonstrated.

First, we AND the color with the alpha mask, yielding the alpha mask itself:

0100 & 0100 -> 0100

Then we shift this bit to the right:

0100 >> 6 -> 0001

Then multiply by 255 so that the whole byte is filled:

0001 * 255 -> 

Next we invert the mask (this is a modification I considered after
writing my previous email):

~ -> 

Now since this color is opaque, when we AND the screen with it, it sets
this pixel on screen to 0 (if our color were transparent, the mask would
all be 1s here, so ANDing it would have no effect on the screen).

screen &  -> 

Finally, with the assumption that transparent pixels in our input are
all 0s, we can just OR the color onto the screen:

0100 |  -> 0100

That's the method. Suggestions on improving it are greatly appreciated.

P.S. In response to the other criticism of cutting down my color depth,
I'm really not concerned about that. In the interest of making my
library support many different color formats, it's not feasible at this
time to change it all up just to squeeze out some more colors.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 07/23/2018 05:58 AM, Eric Auer wrote:
> 
> Hi! I am not sure whether I understand your method, so
> maybe you can explain it in more detail. Is the alpha
> mask 1 byte per pixel, either 00 or ff per pixel? The
> multiplication is costly. You can also use bit test
> and "set conditionally" (to 0 or 255) and "move
> conditionally" byte sized 386 operations, but then
> you are back to pixel wise processing. The good
> thing about conditional setting and moving is that
> you avoid conditional jumps which are always more
> time-consuming than a fixed calculation which can
> involve conditional setting and moving :-)
> 
> Eric
> 
>> With 4 pixels loaded in a 32-bit register:
>>
>> AND the input pixels with the alpha mask
>> SHR this result so that the bit is in position 0
>> Multiply so that this bit is expanded to a full byte of 1s
>> AND the input and screen with this mask
>> OR the modified input onto the screen
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] VGA frame rates and mouse

[David McMackins]

> Your definition of "force full redraw" sounds odd. What
> should be forced by that? A graphics library? Hardware?

I suppose I'm not explicitly forcing, but since every pixel on the
screen is being changed, it shouldn't be something weird where the
hardware is not actually doing what I ask as an optimization.

> Indeed. Do you use a fast way of writing the graphics memory,
> such as the "string and block processing" Assembly language
> commands or at least a library function in the programming
> language of your choice which internally uses them?

No. In fact, my copying routine is extra slow, because since mode 13h
doesn't have hardware alpha checking, I have to do it myself. Basically
I've defined my own alpha mask, and so I have to check if it's on before
drawing to the screen. Also, I don't even know of a copying function
that supports far pointers in gcc, and I want my program to work with
both Watcom and gcc. I suppose I could remove alpha support from my
screen copying routine and only support it between bitmaps.

> You mean without cutemouse, frame rate is fixed to 15 fps?

More or less. I'm not measuring the rate each frame, but rather the
execution time of this program which has a fixed number of frames it
draws. This of course varies a little bit between runs, but the
difference when moving the mouse is very significant, and at these frame
rates, it is even visible to the eye.

> PS: Mode 13h is a bad choice for high frame rates. Try a VESA
> mode with enough RAM for 2 or more frames, so you can update
> one during the full time when the other is visible, then flip.

Yeah I know about this, but I want my program to be compatible with
various video modes. Mode 13h is easy when just getting started to test
that the other graphics functions are working instead of worrying about
if my VESA tricks are working. My program will eventually target
basically all DOS graphics modes. "Use something that you don't know
exists on your target machine" is not a solution.

P.S. I did some playing with BIOS power settings and found that indeed
the BIOS can be blamed for this behavior. Even while leaving OS power
controls enabled, disabling the "idle slowdown" fixed the issue.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 07/19/2018 04:53 AM, Eric Auer wrote:
> 
> Hi David,
> 
>> I've discovered something weird (to me). I'm on a 1998 Sony Vaio with a
>> Pentium 3 processor running FreeDOS 1.2. I have a test program which
>> draws 64 full frames to the screen via VGA mode 13h. Each frame is a
>> different color to force a full redraw. In addition, I draw a 1-pixel
>> mouse cursor onto the frame buffer before copying.
> 
> Your definition of "force full redraw" sounds odd. What
> should be forced by that? A graphics library? Hardware?
> 
>> I regulate the frame rate by explicitly waiting for the vblank period
>> before doing the buffer copy to VRAM. Normally, my program gets a frame
>> rate of about 15fps. This seems a bit slow given my processor speed.
> 
> Indeed. Do you use a fast way of writing the graphics memory,
> such as the "string and block processing" Assembly language
> commands or at least a library function in the programming
> language of your choice which internally uses them? You can
> for example use "rep stosd" to full a buffer of N * 4 bytes
> at a speed of 4 bytes per iteration, or "rep movsd" to copy
> from one buffer to another at the same speed. A good compiler
> with 386+ awareness will automatically chose a good memcopy,
> move, memcpy, memset or whatever you are using right now,
> using variants optimized for your chosen CPU generation.
> 
>> However, I've noticed if I am moving the mouse, the
>> frame rate doubles to nearly 30fps. [... but it ...]
>> stops happening (always low frame rate)
>> if I unload CuteMouse before running the program.
> 
> You mean without cutemouse, frame rate is fixed to 15 fps?
> 
>> This is with a PS/2 mouse and the laptop's trackpad, which I think is
>> also a PS/2 device since when I tell CuteMouse not to load from serial,
>> it still loads the trackpad.
> 
> Your BIOS or drivers probably measure how busy your computer
> is and throttle the CPU when it is not, lowering your frame
> rate. The trackpad might actually be USB based with your BIOS
> just simulating PS/2 based on the actions. You can also check
> whether you use FDAPM or the IDLEHALT kernel options or have
> BIOS settings about energy saving active. Of course you will
> not want to waste battery, so it is probably better to make
> your program "look more busy" to the energy drivers WHILE it
> is important for you to have full speed, as opposed to just
> disabling the drivers, but having minimal battery endurance.
> 
> Regards, Eric
> 
> PS: Mode 13h is a bad choice for high frame rates. Try a VESA
> mode with enough 

Re: [Freedos-devel] VGA frame rates and mouse

[David McMackins]

I said at the very beginning of my first email what hardware I'm using, 
but I also said that I'm not just writing this for my own hardware, so 
that is really irrelevant.


I'm not sure what this has to do with the topic at all. Yes, I know 
about Allegro. Allegro is big and fat, doesn't work on 16-bit, and is no 
longer actively receiving updates for DOS (the new version won't even 
run on it). Besides, you don't even know what I'm trying to do.


"Have you tried using different software?" is not an answer to "Why is 
this program behaving this way?". You must be a regular on 
StackOverflow.



Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 2018-07-19 09:48, Louis Santillan wrote:

What hardware are you doing this on?  Have you seen Allegro? [0][1]

[0] http://liballeg.org/stabledocs/en/index.html [8]
[1]
https://github.com/liballeg/allegro5/releases/download/v4-2-3-1/all4231.zip
[9]

On Thu, Jul 19, 2018 at 5:42 AM David McMackins
 wrote:


Your definition of "force full redraw" sounds odd. What
should be forced by that? A graphics library? Hardware?


I suppose I'm not explicitly forcing, but since every pixel on the
screen is being changed, it shouldn't be something weird where the
hardware is not actually doing what I ask as an optimization.


Indeed. Do you use a fast way of writing the graphics memory,
such as the "string and block processing" Assembly language
commands or at least a library function in the programming
language of your choice which internally uses them?


No. In fact, my copying routine is extra slow, because since mode
13h
doesn't have hardware alpha checking, I have to do it myself.
Basically
I've defined my own alpha mask, and so I have to check if it's on
before
drawing to the screen. Also, I don't even know of a copying function
that supports far pointers in gcc, and I want my program to work
with
both Watcom and gcc. I suppose I could remove alpha support from my
screen copying routine and only support it between bitmaps.


You mean without cutemouse, frame rate is fixed to 15 fps?


More or less. I'm not measuring the rate each frame, but rather the
execution time of this program which has a fixed number of frames it
draws. This of course varies a little bit between runs, but the
difference when moving the mouse is very significant, and at these
frame
rates, it is even visible to the eye.


PS: Mode 13h is a bad choice for high frame rates. Try a VESA
mode with enough RAM for 2 or more frames, so you can update
one during the full time when the other is visible, then flip.


Yeah I know about this, but I want my program to be compatible with
various video modes. Mode 13h is easy when just getting started to
test
that the other graphics functions are working instead of worrying
about
if my VESA tricks are working. My program will eventually target
basically all DOS graphics modes. "Use something that you don't know
exists on your target machine" is not a solution.

P.S. I did some playing with BIOS power settings and found that
indeed
the BIOS can be blamed for this behavior. Even while leaving OS
power
controls enabled, disabling the "idle slowdown" fixed the issue.

Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org [1] www.delwink.com [2]
www.eff.org [3] www.gnu.org [4] www.fsf.org [5]

On 07/19/2018 04:53 AM, Eric Auer wrote:


Hi David,


I've discovered something weird (to me). I'm on a 1998 Sony Vaio

with a

Pentium 3 processor running FreeDOS 1.2. I have a test program

which

draws 64 full frames to the screen via VGA mode 13h. Each frame

is a

different color to force a full redraw. In addition, I draw a

1-pixel

mouse cursor onto the frame buffer before copying.


Your definition of "force full redraw" sounds odd. What
should be forced by that? A graphics library? Hardware?


I regulate the frame rate by explicitly waiting for the vblank

period

before doing the buffer copy to VRAM. Normally, my program gets a

frame

rate of about 15fps. This seems a bit slow given my processor

speed.


Indeed. Do you use a fast way of writing the graphics memory,
such as the "string and block processing" Assembly language
commands or at least a library function in the programming
language of your choice which internally uses them? You can
for example use "rep stosd" to full a buffer of N * 4 bytes
at a speed of 4 bytes per iteration, or "rep movsd" to copy
from one buffer to another at the same speed. A good compiler
with 386+ awareness will automatically chose a good memcopy,
move, memcpy, memset or whatever you are using right now,
using variants optimized for your chosen CPU 

Re: [Freedos-devel] VGA frame rates and mouse

[David McMackins]

so basically you want to find out how fast you can
update blocks of 64 000 pixels


I never said that. I wanted to find out why my frame rate was dependent 
on the mouse activity.



You probably want to optimize that copying routine.
Game programmers would at least use MMX to do the
alpha checks for several pixels at the same time.


Not sure what that is.


In C, you can at least use logic calculations, to
avoid having to do "if then" for every single pixel.


Not sure what you mean here.


If by gcc you mean DJGPP: Pointers are protected mode
there, so everything is "far" in the sense that each
pointer can point anywhere in your allocated memory.


Maybe I need to check again, but I'm pretty sure VGA RAM is considered 
outside my allocated memory.



Yeah I know about this, but I want my program to be compatible with
various video modes. Mode 13h is easy...


Easy yes, but also slow.


You missed the whole point of the first sentence you quoted. 
"Optimizing" by using a better video mode that *might not be supported 
by the hardware* is not a real answer. I *will* use VESA, but I will 
*not* throw out plain VGA support just because it's slow. I'm not using 
mode 13h because it's easy; I'm doing it because I want to support 
pre-VESA hardware. The fact that it's easy is merely why I decided to 
implement support for it *first*. By this logic, I could just as easily 
assume faster hardware and be unconcerned with optimization, but that's 
a non-solution that wastes everyone's time to consider.



Various games used a somewhat convoluted
variant with the same resolution but with pages and bits and so
on, just to have several pages to flip between.


I may very well eventually support page flipping in VGA, but it's simply 
not what I'm trying to do right now.



Which settings are available for that BIOS idle slowdown? Maybe a
compromise is possible which has good frame rate but still saves
at least some energy :-)


There are no options. The setting is either on or off.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 2018-07-19 14:07, Eric Auer wrote:

Hi David,

so basically you want to find out how fast you can
update blocks of 64 000 pixels, starting at a VSYNC
and if possible taking at most very few VSYNC periods
until the update is done. Assuming ALL pixels change.


No. In fact, my copying routine is extra slow, because since mode 13h
doesn't have hardware alpha checking, I have to do it myself. 
Basically
I've defined my own alpha mask, and so I have to check if it's on 
before

drawing to the screen.


You probably want to optimize that copying routine.
Game programmers would at least use MMX to do the
alpha checks for several pixels at the same time.

In C, you can at least use logic calculations, to
avoid having to do "if then" for every single pixel.

If by gcc you mean DJGPP: Pointers are protected mode
there, so everything is "far" in the sense that each
pointer can point anywhere in your allocated memory.

For Watcom, things depend on the target memory model,
whether you want to use real or protected mode etc.


I suppose I could remove alpha support from my screen
copying routine and only support it between bitmaps.


That can be a sensible optimization, but depends on what
your requirements are, so the decision is yours.


You mean without cutemouse, frame rate is fixed to 15 fps?


That probably means that the IRQ and I/O activities of cutemouse
do give your drivers or BIOS the impression that the computer is
busy, keeping it from entering lower clock states to save energy.


Yeah I know about this, but I want my program to be compatible with
various video modes. Mode 13h is easy...


Easy yes, but also slow. Various games used a somewhat convoluted
variant with the same resolution but with pages and bits and so
on, just to have several pages to flip between. The downside is
that you have to switch between different hardware pages and the
whole "one pixel one byte" thing is lost. So VESA would clearly
be less pain. The obvious way would be to use VESA when available
and fall back to MCGA mode 0x13 otherwise, even if it is slow.

It is probably not worth the effort to use complex VGA modes just
to have faster frame rates on ancient hardware when most computers
will have VESA anyway. So mode 0x13 is okay when VESA is absent.


P.S. I did some playing with BIOS power settings and found that indeed
the BIOS can be blamed for this behavior. Even while leaving OS power
controls enabled, disabling the "idle slowdown" fixed the issue.


Which settings are available for that BIOS idle slowdown? Maybe a
compromise is possible which has good frame rate but still saves
at least some energy :-)

Regards, Eric


--
Check out the vibrant tech 

Re: [Freedos-devel] Check if VGA is available

[David McMackins]

This looks very useful. I'll do some tests in C later and report back.

Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 2018-07-16 10:11, Mark Olesen wrote:

https://github.com/shidel/DustyTP7/blob/master/INFO/INFO.PAS [9]

On Mon, Jul 16, 2018 at 9:08 AM, Mark Olesen 
wrote:


https::/gitub.com/shidel/DustyTP7/blob/master/INFO/INFO.PAS [8]

On Mon, Jul 16, 2018 at 4:51 AM, David McMackins
 wrote:


I'm doing some graphics programming, and I want to support many
different graphics modes, but I need a way of checking to see if
they
are available. Currently I'm working on VGA. How do I check if
it's
available without just trying to enter graphics mode?

Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org [1] www.delwink.com [2]
www.eff.org [3] www.gnu.org [4] www.fsf.org [5]





--

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot [6]
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel [7]




Links:
--
[1] http://www.mcmackins.org
[2] http://www.delwink.com
[3] http://www.eff.org
[4] http://www.gnu.org
[5] http://www.fsf.org
[6] http://sdm.link/slashdot
[7] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[8] http://gitub.com/shidel/DustyTP7/blob/master/INFO/INFO.PAS
[9] https://github.com/shidel/DustyTP7/blob/master/INFO/INFO.PAS

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS Coreutils

[David McMackins]

Yeah, seems he wants the program to write itself via "contributions".


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 07/05/2018 04:16 PM, Jim Hall wrote:
> Good luck in your project!
> 
> I have a question: Did you write any code yet? I can only see the readme
> and the license.
> 
> 
> On Thu, Jul 5, 2018 at 7:36 AM, Ercan Ersoy  > wrote:
> 
> 
> Hello,
> 
> I have abandoned DOS Coreutils Project. But, I started
> FreeDOS Coreutils Project.
> 
> FreeDOS Coreutils Project includes only 16 bit DOS port
> GNU Coreutils.
> 
> GitHub address:
> https://github.com/ercanersoy/FreeDOS-Coreutils
> 
> 
> GitLab address
> https://gitlab.com/ercanersoy/FreeDOS-Coreutils
> 
> 
> I accept contributions.
> 
> Thanks,
> Ercan
> 
> 
>  
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Watcom COM format directive

[David McMackins]

I'm trying to link a program as a COM executable, but when I add the
"format DOS COM" directive to the linker, it complains that libraries
aren't available (such as clibs.lib). It works fine and produces an EXE
if I leave out this directive. What's really happening?

Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Ideas

[David McMackins]

On 07/07/2018 12:49 PM, Ercan Ersoy wrote:
> I think FreeDOS needs a 16 bit calculator program.

Is FoxCalc not 16-bit?


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Good BASIC interpreter?

[David McMackins]

It is good idea. Will this BASIC environment be compatible BASICA?


Maybe eventually. Sounds like a good goal, but I care first about 
minimal BASIC and shell access, then I can consider extensions.



Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 2018-07-12 14:01, Ercan Ersoy wrote:
Eh, we may have different goals here. I'm looking for something  
closer to ANSI BASIC (actually I'm thinking of
basing mine on ECMA-55 since it's free). I just want a plain old  
BASIC with the ability to run shell commands. My > vision is to have  
a really small binary that could reasonably run on an IBM PC and  
replace MS BASIC.


It is good idea. Will this BASIC environment be compatible BASICA?

I don't really see a need to replace QBASIC, because FreeBASIC  
already replaces QuickBASIC which I believe is a

superset of QBASIC.


FreeBASIC is 32 bit. It needs CWSDPMI.

I've wanted to clone GW-BASIC, but trying to do even that is quite a  
bit out of my range as a programmer (plus
I've been pretty deep into Microsoft's 6502 BASIC source code, which  
is a close relative to GW-BASIC, so...)


Good idea.

I think GW-BASIC clone name's and QBASIC clone name's is "FD-BASIC".

Thanks,
Ercan


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Good BASIC interpreter?

[David McMackins]

I think I'd go with "basica" for a GW clone, simply because it's what
a lot of batch files will expect.  (And "GW-BASIC" is trademarked.)


Or you could just add an alias to your AUTOEXEC.BAT file.

---
Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 2018-07-12 15:13, Steve Nickolas wrote:

On Thu, 12 Jul 2018, Ercan Ersoy wrote:


It is good idea. Will this BASIC environment be compatible BASICA?


(BASICA and GW-BASIC are about 99% identical.  Main difference is that
GW-BASIC doesn't make calls into the IBM Cassette Basic ROM.  I
usually use the latter term to make it clear I'm referring to the
generic dialect, but there's no practical difference.)


I think GW-BASIC clone name's and QBASIC clone name's is "FD-BASIC".


I think I'd go with "basica" for a GW clone, simply because it's what
a lot of batch files will expect.  (And "GW-BASIC" is trademarked.)

-uso.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Good BASIC interpreter?

[David McMackins]

As someone who would like to write code that can be easily understood by
users of other 80s computer systems, I prefer to write my scripts in
BASIC. I've been using Bywater BASIC from the FreeDOS distribution, and
it's quite good up until you want to start considering the outside world.

In my particular example, SHELL() is supposed to return the exit code of
the program that you tell it to run, but it seems to always return 0.

I tried my damnedest looking at the source code for this program, but it
is perhaps the messiest code I have ever looked at (and I've looked at
mathematicians' code which is a sight to behold). I spent at least 2
hours digging and couldn't even find where the actual work was being
done to execute these external commands, much less what is done with the
exit code. I'll spare you my full rant about how bad it is in there.

Anyway, are there any other decent BASIC interpreters to be found? My
requirements are: a free software license, ability to run external
commands, ability to run on 16-bit systems.

Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Removing non-free packages

[David McMackins]

Yeah, 4DOS is another one that I think should be removed. If I remember 
right, it has something in the license about commercial usage which 
makes it nonfree. In the interest of making rare software available, I 
think it would be fine to continue hosting it on the server, but it 
should not be included with the base installation.



Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 2018-07-12 11:14, Ercan Ersoy wrote:

Hello,

Will non-free packages (for example "cdp" package) that
included on FreeDOS be removed for FreeDOS 1.3?

Thanks for replies,
Ercan


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Good BASIC interpreter?

[David McMackins]

Well, that being the case, I guess I'll write my own. I'll send out an 
announcement when development starts; I'd like to finish the library I'm 
working on first.


For those interested in BASIC, if there are those among you with some 
experience with interpreters, I'm sure I could use some assistance in 
making a fast parsing routine. I've done something a little bit like 
this before that's pretty fast, but that program runs on modern 
computers with plenty of memory.



Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 2018-07-12 11:08, Jim Hall wrote:

We only have bwbasic and Free BASIC in the FreeDOS software list, and
they are the only updated BASIC environments I know of. I don't code
in BASIC these days, so this isn't my area of expertise.

But Free BASIC is 32 bit. So I think bwbasic is the only one that
meets your requirements.

On Wed, Jul 11, 2018, 5:50 PM David McMackins 
wrote:


As someone who would like to write code that can be easily
understood by
users of other 80s computer systems, I prefer to write my scripts in
BASIC. I've been using Bywater BASIC from the FreeDOS distribution,
and
it's quite good up until you want to start considering the outside
world.

In my particular example, SHELL() is supposed to return the exit
code of
the program that you tell it to run, but it seems to always return
0.

I tried my damnedest looking at the source code for this program,
but it
is perhaps the messiest code I have ever looked at (and I've looked
at
mathematicians' code which is a sight to behold). I spent at least 2
hours digging and couldn't even find where the actual work was being
done to execute these external commands, much less what is done with
the
exit code. I'll spare you my full rant about how bad it is in there.

Anyway, are there any other decent BASIC interpreters to be found?
My
requirements are: a free software license, ability to run external
commands, ability to run on 16-bit systems.

Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org [1] www.delwink.com [2]
www.eff.org [3] www.gnu.org [4] www.fsf.org [5]



--

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot [6]
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel [7]



Links:
--
[1] http://www.mcmackins.org
[2] http://www.delwink.com
[3] http://www.eff.org
[4] http://www.gnu.org
[5] http://www.fsf.org
[6] http://sdm.link/slashdot
[7] https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Good BASIC interpreter?

[David McMackins]

Will the BASIC interpreter comptiable Microsoft QBASIC?

I wish this BASIC interpreter is QBASIC.EXE for FreeDOS
for compatibility. It's name may be "FreeQB".


Eh, we may have different goals here. I'm looking for something closer 
to ANSI BASIC (actually I'm thinking of basing mine on ECMA-55 since 
it's free). I just want a plain old BASIC with the ability to run shell 
commands. My vision is to have a really small binary that could 
reasonably run on an IBM PC and replace MS BASIC.


I don't really see a need to replace QBASIC, because FreeBASIC already 
replaces QuickBASIC which I believe is a superset of QBASIC.


Really I want to to this because COMMAND.COM is just too limited for 
some of the things I want to script, and I hate having to 
cross-communicate between COMMAND and bwBASIC.



Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 2018-07-12 11:42, Ercan Ersoy wrote:

Hello,


Well, that being the case, I guess I'll write my own. I'll send out an
announcement when development starts; I'd like to finish the library 
I'm

working on first.

For those interested in BASIC, if there are those among you with some
experience with interpreters, I'm sure I could use some assistance in
making a fast parsing routine. I've done something a little bit like
this before that's pretty fast, but that program runs on modern
computers with plenty of memory.


Will the BASIC interpreter comptiable Microsoft QBASIC?

I wish this BASIC interpreter is QBASIC.EXE for FreeDOS
for compatibility. It's name may be "FreeQB".

Ercan emailed me off list last week that he was interested in writing 
a

BASIC environment. He may want to help you.


Yes, I may help for BASIC interpreter.

Thanks for replying,
Ercan


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] UNIX utilities, arg parser, installer software

[David McMackins]

I've hosted the source code here:

https://mcmackins.org/dl/dos/UTILSSRC.ZIP
https://mcmackins.org/dl/dos/MDSAISRC.ZIP

The first archive has my UNIX utils and arg parser (since I used the arg
parser for them), and the second has the installer.

No docs at this time. MDSAI probably needs a short doc before being
published explaining the configuration. Basically in the first diskette
there needs to exist MDSAI.INF which contains literally a number in
ASCII text of how many diskettes make up the full archive. The
executable can be named anything, so even though the build script
creates MDSAI.EXE, you may want to rename to INSTALL.EXE when making a
distribution.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 06/24/2018 05:36 AM, Jim Hall wrote:
> Excellent! Do you have a website you could post these to? If so, put
> them there and share the link. If not, email me off list and we'll
> arrange to get them to me so I can share them on our files archive at
> ibiblio.
> 
> I like the very permissive license, especially for a library. For those
> who don't know this license, it's this:
> 
> Copyright (c) ___
> 
> Copying and distribution of this file, with or without modification,
> are permitted in any medium without royalty provided the copyright
> notice and this notice are preserved.
> 
> 
> I'll be curious to see the command line parser. Did you write something
> like getopt, or something new? FYI that there's a getopt here:
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/getopt/
> 
> Also FYI that our Unix workalikes are here:
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/unix/
> 
> Thanks!
> Jim
> 
> 
> On Sat, Jun 23, 2018, 10:57 PM David McMackins  <mailto:cont...@mcmackins.org>> wrote:
> 
> In my playing about with FreeDOS, I wrote my own versions of cat, head,
> wc, and split.
> 
> For these, I also wrote a small library for parsing command-line options
> in a typical DOS-like fashion.
> 
> Finally, I also wrote a program called the Multi-Disk Split Archive
> Installer (MDSAI) which is an installer program designed for deploying
> software too big for a single floppy disk. You put the installer on the
> first diskette, along with a file that describes what's being installed,
> and then on each diskette, have a sequential piece of a ZIP archive.
> MDSAI will cat them together and then extract in the C drive.
> 
> I wrote these for myself. They may need to be modified or have new
> options before they are ready for others to use. If you are interested
> in these, let me know where I should publish them. I'm releasing them
> all under the GNU All-Permissive License.
> 
> Happy Hacking,
> 
> David E. McMackins II
> Supporting Member, Electronic Frontier Foundation (#2296972)
> Associate Member, Free Software Foundation (#12889)
> 
> www.mcmackins.org <http://www.mcmackins.org> www.delwink.com
> <http://www.delwink.com>
> www.eff.org <http://www.eff.org> www.gnu.org <http://www.gnu.org>
> www.fsf.org <http://www.fsf.org>
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> <mailto:Freedos-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS PASSWORD executable size

[David McMackins]

When I try to UPX it, I get an assertion failure. Apparently UPX has
trouble with FreePascal executables. I think this additionally confirms
another compiler was used.


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 06/24/2018 05:33 AM, Bitácora de Javier Gutiérrez Chamorro (Guti) wrote:
> Following your details, I can confirm it is UPXed. I have unpacked it,
> and increased from 8264 bytes up to 17424 bytes.
> 
> Then I examined the headers, and according to the signatures (Portions
> Copyright (c) 1983,92 Borland) it should be Turbo/Borland Pascal 7
> compiled.
> 
> Hope that helps.
> 
> -
> Javier Gutiérrez Chamorro
> http://www.javiergutierrezchamorro.com
> <http://www.javiergutierrezchamorro.com>
> 
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 
> Remitente:    Mateusz Viste < mate...@nospam.viste.fr
> <mailto:mate...@nospam.viste.fr>>
> Destinatario: freedos-devel@lists.sourceforge.net
> <mailto:freedos-devel@lists.sourceforge.net> <
> freedos-devel@lists.sourceforge.net
> <mailto:freedos-devel@lists.sourceforge.net>>
> Fecha:        domingo, 24 de junio de 2018, 11:41:01
> Asunto:       [Freedos-devel] FreeDOS PASSWORD executable size
> Archivos:     
> --====----=======--
> 
> On Sat, 23 Jun 2018 21:09:17 -0500, David McMackins wrote:
> 
> *> I've noticed that PASSWORD is written for FreePascal, but the executable
>> in the distribution is only 8k in size. When I compile myself, it is 
>> 60k. How is it being stripped to that small size? 
> 
> *I wrote it ages ago, and I guess FreePascal gained some bloat in the mean
> time. Try compiling it with FreePascal's version from 2005. It's also
> possible I compiled the final release using Turbo Pascal, if I noticed
> back then that it could significantly decrease the binary's size... I'm
> not sure of anything.
> 
> Also, it's UPXed of course.
> 
> Mateusz
> /--
> FreeDOS is present on the USENET, too! alt.os.free-dos
> 
> 
> --
> 
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! /http://sdm.link/slashdot
> <http://sdm.link/slashdot>
> /___
> Freedos-devel mailing list
> /Freedos-devel@lists.sourceforge.net
> <mailto:Freedos-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> <https://lists.sourceforge.net/lists/listinfo/freedos-devel>
> 
> /=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 
> /

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] UNIX utilities, arg parser, installer software

[David McMackins]

I suppose I could do that. I left them together for the simplicity of
the build script.

What if I added a deploy script that created separate distributions for
each one while keeping the source together?


Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org

On 06/24/2018 08:30 AM, Jim Hall wrote:
> Thanks. Any chance to split up the Unix utilities separately, like we
> have already done with the others?
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/unix/
> 
> On Sun, Jun 24, 2018, 6:01 AM David McMackins  <mailto:cont...@mcmackins.org>> wrote:
> 
> I've hosted the source code here:
> 
> https://mcmackins.org/dl/dos/UTILSSRC.ZIP
> https://mcmackins.org/dl/dos/MDSAISRC.ZIP
> 
> The first archive has my UNIX utils and arg parser (since I used the arg
> parser for them), and the second has the installer.
> 
> No docs at this time. MDSAI probably needs a short doc before being
> published explaining the configuration. Basically in the first diskette
> there needs to exist MDSAI.INF which contains literally a number in
> ASCII text of how many diskettes make up the full archive. The
> executable can be named anything, so even though the build script
> creates MDSAI.EXE, you may want to rename to INSTALL.EXE when making a
> distribution.
> 
> 
> Happy Hacking,
> 
> David E. McMackins II
> Supporting Member, Electronic Frontier Foundation (#2296972)
> Associate Member, Free Software Foundation (#12889)
> 
> www.mcmackins.org <http://www.mcmackins.org> www.delwink.com
> <http://www.delwink.com>
> www.eff.org <http://www.eff.org> www.gnu.org <http://www.gnu.org>
> www.fsf.org <http://www.fsf.org>
> 
> On 06/24/2018 05:36 AM, Jim Hall wrote:
> > Excellent! Do you have a website you could post these to? If so, put
> > them there and share the link. If not, email me off list and we'll
> > arrange to get them to me so I can share them on our files archive at
> > ibiblio.
> >
> > I like the very permissive license, especially for a library. For
> those
> > who don't know this license, it's this:
> >
> > Copyright (c) ___
> >
> > Copying and distribution of this file, with or without modification,
> > are permitted in any medium without royalty provided the copyright
> > notice and this notice are preserved.
> >
> >
> > I'll be curious to see the command line parser. Did you write
> something
> > like getopt, or something new? FYI that there's a getopt here:
> >
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/getopt/
> >
> > Also FYI that our Unix workalikes are here:
> > http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/unix/
> >
> > Thanks!
> > Jim
> >
> >
> > On Sat, Jun 23, 2018, 10:57 PM David McMackins
> mailto:cont...@mcmackins.org>
> > <mailto:cont...@mcmackins.org <mailto:cont...@mcmackins.org>>> wrote:
> >
> >     In my playing about with FreeDOS, I wrote my own versions of
> cat, head,
> >     wc, and split.
> >
> >     For these, I also wrote a small library for parsing
> command-line options
> >     in a typical DOS-like fashion.
> >
> >     Finally, I also wrote a program called the Multi-Disk Split
> Archive
> >     Installer (MDSAI) which is an installer program designed for
> deploying
> >     software too big for a single floppy disk. You put the
> installer on the
> >     first diskette, along with a file that describes what's being
> installed,
> >     and then on each diskette, have a sequential piece of a ZIP
> archive.
> >     MDSAI will cat them together and then extract in the C drive.
> >
> >     I wrote these for myself. They may need to be modified or have new
> >     options before they are ready for others to use. If you are
> interested
> >     in these, let me know where I should publish them. I'm
> releasing them
> >     all under the GNU All-Permissive License.
> >
> >     Happy Hacking,
> >
> >     David E. McMackins II
&g

[Freedos-devel] PASSWORD modification to not print passwords in plain text into the log file

[David McMackins]

I noticed the PASSWORD program puts password attempts in plain text into
its log file. This is dangerous if the user only barely miskeys their
password and another user reads the log file.

I made a modification to only say which user was attempted. Patch file
included.

Happy Hacking,

David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)

www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org


PASSWORD.DIF
Description: video/dv
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Proposition for what a DOS package should be

[David McMackins]

Something related to this that I think should be higher priority for FreeDOS is 
addressing the fact that many packages rely on proprietary compilers to be 
built from source. At the very least, it should be possible to build all 
FreeDOS packages using compilers and assemblers also available in FreeDOS.

David McMackins
 Sent from  mobile

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

Re: [Freedos-devel] FreeDOS is 25 years old

[David McMackins]

Yes, thank YOU Jim and all the long time devs who made FreeDOS a thing 
we can enjoy today. I've learned a lot and had quite a bit of fun so 
far, and I'm looking forward to making some contributions of my own to 
the community.



Happy Hacking,

David E. McMackins II
www.mcmackins.org www.delwink.com

On 6/30/19 6:49 PM, Jayden Charbonneau wrote:

Thank YOU for being such a great opensource OS project! :-)

On Sun, Jun 30, 2019 at 6:34 PM Jim Hall > wrote:


FreeDOS has now been around for 25 years. That's a major milestone
for anything, especially an open source software project.

I just wanted to say THANK YOU to everyone in the FreeDOS community
- past and present. Open source software is about people coming
together to work on something, and that's you. If I ever meet any of
you in person, I'll buy you a beer/beverage.

And it's great that our community remains so positive. So THANKS for
helping keep out the trolls.

I'm looking forward to FreeDOS 1.3! :-)


Jim
___
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 mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Fastest way to start programming for DOS

[David McMackins]

There really isn't going to be anything Qt-like for DOS. Qt is built around the 
existence of a display server which isn't really a concept in DOS. 
Theoretically it could be done in protected mode, but I don't know of anything 
that does this.

Your best bet is going to be C or C++ and just do some basic graphics 
programming. If your machine is 20 years old, it most certainly has VGA 
available which is pretty easy to program for in plain old C. It'll be a good 
learning opportunity for you, since it seems like you have yet to dip your feet 
into low level development.


Regards,

David E. McMackins II
www.mcmackins.org www.delwink.com

On 4/12/20 12:45 PM, Michal Kochman wrote:
> Thank you for your answers, I really do.
> I started coding the same functionality for Ubuntu in QtCreatotr with Qt 
> libraries, just to clarify what exactly I want 
> (https://github.com/MichalKochman/pictureGame). My sister saw it and was 
> quite excited, so I'm gonna firstly finish a little different version (so I 
> am afraid that as soon as the second commit I will be in a territory I would 
> not even think to attempt for freeDOS) there for any ubuntu/windows PC and 
> then I will reconsider my freeDOS dream. Have anyone ever tried to 
> crosscompile in Qt with Qt libraries for DOS? I would probably end with 
> bigger app than the whole OS, but I am a lazy guy and if it would work for a 
> while I would be OK with it. :D :D
> 
> 
> 
> ___
> 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