freedos-devel — FreeDOS debugging questions and other developer topics

[Freedos-devel] [FreeDOS-Devel] FOSS Game crobots

[Richard S. <rs...@gm...>]

https://tpoindex.github.io/crobots/

crobots is now FOSS opensource robot learning game for kids:
gplv2
https://tpoindex.github.io/crobots/

from site:
Documentation

The original manual for CROBOTS is in docs/crobots_manual.html
<https://tpoindex.github.io/crobots/docs/crobots_manual.html>.
<https://tpoindex.github.io/crobots/#history>History

CROBOTS was my first adventure into the world of compilers and virtual
machines, and not all that long after I learned C.

In early 1985, I found Jeff Lee's posting of a Yacc grammar for ANSI C, on
the USENET group net.sources
<https://groups.google.com/forum/#!search/net.sources%2420yacc%2420ansi%2420c/net.sources/3gmx4As0aSM/F--W3xnQlEsJ>.
Taking Jeff's advice in his post *"(Y)ou can sit and crank your own output
through it to amuse yourself if you have the personality of a cumquat(sp?)"*,
I played with Yacc/Lex and the C grammar to the point of moderately
understanding how it all worked.

Re: [Freedos-devel] Back at it with DOG

[Eric A. <e....@jp...>]

Hi and welcome back, Wolf :-)

>> I used to map a virtual drive to a folder on Linux - but like you
>> found, I sometimes had problems with that (not all the time, just
>> sometimes) so I stopped doing that. When I need to get access to my
>> virtual drive, I use guestmount from the libguestfs package to "mount"
>> the virtual disk from Linux:
>>
>> $ mkdir mystuff
>> $ guestmount -a mystuff.qcow2 -m /dev/sda1 mystuff
>> ...
>> $ guestunmount mystuff
>>
>>
> Ah so you do less frequent copying from the DOS image to your linux system
> for things like git commit?
> I'm also going to try EtherDFS and see if that can solve it so that I can
> edit code on linux and then build and test in a QEMU box which is
> constantly running. :)

Time for the usual advertisement: DOSEMU2 makes those things very
easy by magically letting you use Linux directories of your choice
as drives for DOS :-)

Cheers, Eric

Re: [Freedos-devel] Back at it with DOG

[Wolf B. <wol...@be...>]

On Thu, May 30, 2024 at 4:50 PM Steve Nickolas via Freedos-devel <
fre...@li...> wrote:

> On Thu, 30 May 2024, Wolf Bergenheim via Freedos-devel wrote:
>
> > I'm using Borland C++ 3.1 for now as that's the compiler I used 22 years
> > ago... Looks like porting to Watcom will require a bit of work... It is
> > something I want to do eventually, I think. Just need to read up on the
> > inline assembler stuff and how to build COM binaries :)
>
> The methods that work in Borland 3.1 for both work in OpenWatcom as well,
> in my experience.
>
>
Good to know! :)

-Wolf

-- 

  |\_
  | .\---.
 /   ,__/
/   /Wolf <wol...@be...>_

Re: [Freedos-devel] Back at it with DOG

[Wolf B. <wol...@be...>]

On Thu, May 30, 2024 at 4:25 PM Jim Hall via Freedos-devel <
fre...@li...> wrote:

> On Wed, May 29, 2024 at 9:53 PM Wolf Bergenheim via Freedos-devel
> <fre...@li...> wrote:
> >
> > What do your dev environments look like? How do you make an efficient
> > edit-build-test cycle? Has anyone tried using watcom as a crosscompiler?
>
> I run Linux on my desktop, and I boot FreeDOS inside that using QEMU.
> Here's my command line:
>
> qemu-system-i386 -enable-kvm -m 32 -audiodev pa,id=snd -machine
> pcspk-audiodev=snd -device sb16,audiodev=snd -device
> adlib,audiodev=snd -hda freedos.qcow2 -hdb mystuff.qcow2 -cdrom
> T2405LIVE.iso -boot menu=on
>
> Ooh nice, I was wondering how I can hook up the PC speaker to test my BP
command! :D
Thanks! (and I can confirm it works, and also that BP works!)


I use '-boot menu=on' because I sometimes need to boot the LiveCD for
> testing, and the boot menu makes that easy. I can also use the same
> command line (it's a script) to install the next FreeDOS monthly test
> release and just use the menu to select the LiveCD to install from.


Sweet! Yeah I also have my QEMU launch script :)


My "C:" drive is freedos.qcow2 and my "D:" drive is mystuff.qcow2.
>

Yeah I have a bunch of OS disk images, for additional DOSes, etc and at
different versions to make sure that DOG works for all these versions. :)


> Keeping these separate makes it really easy to reinstall FreeDOS with
> the monthly test releases. I keep all my stuff on "D:" and just
> wipe/reinstall the "C:" drive. I don't keep any of my data on "C:".
>

My D drive is where I've installed my compiler and other stuff like WP 5
(because nostalgia) and jed (it's like a lightweight emacs) for code
editing.


> I used to map a virtual drive to a folder on Linux - but like you
> found, I sometimes had problems with that (not all the time, just
> sometimes) so I stopped doing that. When I need to get access to my
> virtual drive, I use guestmount from the libguestfs package to "mount"
> the virtual disk from Linux:
>
> $ mkdir mystuff
> $ guestmount -a mystuff.qcow2 -m /dev/sda1 mystuff
> ...
> $ guestunmount mystuff
>
>
Ah so you do less frequent copying from the DOS image to your linux system
for things like git commit?
I'm also going to try EtherDFS and see if that can solve it so that I can
edit code on linux and then build and test in a QEMU box which is
constantly running. :)


> I write my code directly in FreeDOS. I often use OpenWatcom, but I
> also like IA-16 GCC. I use FED as my programming editor.
>

Wow, that's actually really cool. Are you able to get more than a 50-line
screen?
Does QEMU support any of the more exotic resolutions? Or are you happy with
the standard 25 lines?

Is IA-16 GCC able to produce 8086 code?

Thanks!
-Wolf

-- 

  |\_
  | .\---.
 /   ,__/
/   /Wolf <wol...@be...>_



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

[Freedos-devel] one more proposal for upload via fdnpkg

[Wilhelm S. <wil...@ma...>]

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi, its once again me.</div>

<div>At the fd gitlab account there is a game called row4, (four in a row) see:</div>

<div>https://gitlab.com/FreeDOS/games/row4</div>

<div>This version is out of date.</div>

<div>There is an update at the programmers site, see:</div>

<div>&nbsp;</div>

<div>https://akfoerster.de/dl/software/dos/fdos/ROW4.ZIP</div>

<div>The game runs in english.</div>

<div>Would it be possible to enable an upload via fdnpkg&nbsp; or to add it in FDT2407?</div>

<div>&nbsp;</div>

<div>Thx.</div>

<div>&nbsp;</div>

<div>W. Spiegl</div></div></body></html>

Re: [Freedos-devel] Back at it with DOG

[Steve N. <uso...@bu...>]

On Thu, 30 May 2024, Wolf Bergenheim via Freedos-devel wrote:

> I'm using Borland C++ 3.1 for now as that's the compiler I used 22 years
> ago... Looks like porting to Watcom will require a bit of work... It is
> something I want to do eventually, I think. Just need to read up on the
> inline assembler stuff and how to build COM binaries :)

The methods that work in Borland 3.1 for both work in OpenWatcom as well, 
in my experience.

-uso.

Re: [Freedos-devel] Back at it with DOG

[Jim H. <jh...@fr...>]

On Wed, May 29, 2024 at 9:53 PM Wolf Bergenheim via Freedos-devel
<fre...@li...> wrote:
>
[..]
> Now a question:
> What are your dev setups like? I'm on a linux host computer and I've
> been using both DOSBox and QEMU to build and test in. I find though
> that it's a bit of a chore, since DOSBox crashes randomly (like when
> compiling), or QEMU segfaults when I mount my dog source directory
> as a virtual FAT drive. So now I'm looking at setting up Dosemu2
> (I remember using doemu ~20 years ago).
>
> What do your dev environments look like? How do you make an efficient
> edit-build-test cycle? Has anyone tried using watcom as a crosscompiler?


I run Linux on my desktop, and I boot FreeDOS inside that using QEMU.
Here's my command line:

qemu-system-i386 -enable-kvm -m 32 -audiodev pa,id=snd -machine
pcspk-audiodev=snd -device sb16,audiodev=snd -device
adlib,audiodev=snd -hda freedos.qcow2 -hdb mystuff.qcow2 -cdrom
T2405LIVE.iso -boot menu=on


But that has some extra stuff in there just to make the PC speaker
work. If you don't care about the PC speaker, but still want SB16 and
Adlib, you can just do this:

qemu-system-i386 -enable-kvm -m 32 -device sb16 -device adlib -hda
freedos.qcow2 -hdb mystuff.qcow2 -cdrom T2405LIVE.iso -boot menu=on


And if you don't care about sound at all, then it's a very simple command line:

qemu-system-i386 -enable-kvm -m 32 -hda freedos.qcow2 -hdb
mystuff.qcow2 -cdrom T2405LIVE.iso -boot menu=on


I use '-boot menu=on' because I sometimes need to boot the LiveCD for
testing, and the boot menu makes that easy. I can also use the same
command line (it's a script) to install the next FreeDOS monthly test
release and just use the menu to select the LiveCD to install from.


My "C:" drive is freedos.qcow2 and my "D:" drive is mystuff.qcow2.
Keeping these separate makes it really easy to reinstall FreeDOS with
the monthly test releases. I keep all my stuff on "D:" and just
wipe/reinstall the "C:" drive. I don't keep any of my data on "C:".

I used to map a virtual drive to a folder on Linux - but like you
found, I sometimes had problems with that (not all the time, just
sometimes) so I stopped doing that. When I need to get access to my
virtual drive, I use guestmount from the libguestfs package to "mount"
the virtual disk from Linux:

$ mkdir mystuff
$ guestmount -a mystuff.qcow2 -m /dev/sda1 mystuff
...
$ guestunmount mystuff


I write my code directly in FreeDOS. I often use OpenWatcom, but I
also like IA-16 GCC. I use FED as my programming editor.

[Freedos-devel] ClamAV and FDT24xx

[Wilhelm S. <wil...@ma...>]

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi,</div>

<div>one more question about fixing a FDT24xx thing:</div>

<div>&nbsp;</div>

<div>Clamav is NO part of FDT24xx, but it can be downloaded via fdnpkg:</div>

<div>fdnpkg install clamv &nbsp;&nbsp; (downloads in about 7 MB)</div>

<div>fdnpkg install clamdb&nbsp; (downloads in about 33 MB) --&gt; alltogether in about 40 MB.</div>

<div>Database Version 51 of clamdb is the latest version working with FD.</div>

<div>&nbsp;</div>

<div>If you run</div>

<div>fdnpkg search clamav</div>

<div>these two files are offered.</div>

<div>&nbsp;</div>

<div>This is a big download, means: it lasts a while till download is finished.</div>

<div>&nbsp;</div>

<div>With these two files you can start a virus checking with good luck (e.g. it requires 128 MB RAM!), but the syntax to do so is a &quot;little&quot; complex,</div>

<div>for this reason I added the &quot;howto&quot; in my help file:</div>

<div><a href="https://deref-mail.com/mail/client/6odOG3BHRNI/dereferrer/?redirectUrl=https%3A%2F%2Fbootablecd.de%2FFreeDOS-Internet-version%2Fhelp110%2Fen%2Fhhstndrd%2Futil%2Fclamav.htm" target="_blank">https://bootablecd.de/FreeDOS-Internet-version/help110/en/hhstndrd/util/clamav.htm</a></div>

<div>&nbsp;</div>

<div>
<div>There is a simple user interface available at:</div>

<div><a href="https://deref-mail.com/mail/client/OQsXLd_mUAU/dereferrer/?redirectUrl=https%3A%2F%2Fwww.ibiblio.org%2Fpub%2Fmicro%2Fpc-stuff%2Ffreedos%2Ffiles%2Futil%2Fsystem%2Fclamav%2Ffdavx-0.2.2.zip" target="_blank">https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/clamav/fdavx-0.2.2.zip</a></div>

<div>which makes it much more comfortable to run the virus checker. It is also a little buggy, but it works.</div>

<div>&nbsp;</div>

<div>This file can NOT be downloaded via fdnpkg!</div>

<div>&nbsp;</div>

<div>So I think it is good that the whole virus checker is not on FDT24xx, but it should be possible to download all THREE packets via fdnpkg and to install fdav into the same</div>

<div>directory as clamav.</div>

<div>To make it easier &quot;fdnpkg search clamav&quot; should also be able to show this file and offer for installation.</div>

<div>&nbsp;</div>

<div>Yes, I have a clue that the virus definitions and the executables are completely out of date and that the required RAM is enormous,</div>

<div>but it should good enough for most DOS viruses.</div>

<div>&nbsp;</div>

<div>Question: Should&nbsp; it be possible to install fdavx (702 kB) via fdnpkg?</div>

<div>&nbsp;</div>

<div>If anybody knows a better virus checker for FreeDOS that is free and needs less RAM etc, please inform us.</div>

<div>&nbsp;</div>

<div>&nbsp;</div>

<div>&nbsp;</div>

<div>Willi / Fritz</div>
</div></div></body></html>

Re: [Freedos-devel] Back at it with DOG

[Wolf B. <wol...@be...>]

On Thu, May 30, 2024 at 11:52 AM Bernd Böckmann via Freedos-devel <
fre...@li...> wrote:

> Hi Wolf,
>
> welcome to the mailing list. Great to hear you started working again on
> DOG. Putting it on Github (or some other publicly accessible repo) sounds
> like a good idea :)
>

It's currently on sourceforge, and I have recovered my SF account, so I
have the git history, but for personal reasons I'm planning to move to
github (I also plan to leverage the wiki and issue tracker). Maybe I'll
also keep the sf repo up-to-date, it's not much extra work to push to a
second upstream. :)


> Looking at https://gitlab.com/FreeDOS/util/dog, that seems to be version
> 0.83c. Is this the latest publicly available version? Otherwise we should
> update the package.
>

Huh, that's an impossible version number for DOG. the correct version
should be 0.8.3b. The version number is built up like this (from the
release notes):

Version is built up like this:

A H  A L
---  ---
| |  | |
| |  | +-- code maturity always one of a (=alpha), b (=beta) OR f (=final)
| |  +---- Patchlevel
| +------- Minor version
+--------- Major version

(this implies that the maximum version for DOG is 15.15.15f ;)

So yeah, I think we should update that, but we can do that when I release
the 0.8.4b version, in the near future. I'm planning on creating a 0.9.0a
branch after the 0.8.4b release.


> > Now a question:
> > What are your dev setups like? I'm on a linux host computer and I've
> been using both DOSBox and QEMU to build and test in. I find though that
> it's a bit of a chore, since DOSBox crashes randomly (like when compiling),
> or QEMU segfaults when I mount my dog source directory as a virtual FAT
> drive. So now I'm looking at setting up Dosemu2 (I remember using doemu ~20
> years ago).
>
> I mainly edit the source code of the DOS programs I work on with my Mac
> and compile them inside DosBox-X. For me, this is quite stable. I would
> like to test Dosemu2, but that seems not to be fully ported to Mac yet.
>

It works okayish for me, especially after setting things up in dosbox that
when I launch it everything is ready for me to just run make. I did have
some odd stuff happening from time to time. though.


> I use OpenWatcom 1.9 to compile my programs under DOS(Box),


I'm using Borland C++ 3.1 for now as that's the compiler I used 22 years
ago... Looks like porting to Watcom will require a bit of work... It is
something I want to do eventually, I think. Just need to read up on the
inline assembler stuff and how to build COM binaries :)


> but also have setup Github actions for some projects to automatically
> build my commits using a Linux container with OpenWatcom v2 and IA16-GCC.
> While somewhat experimental, the Linux port of OpenWatcom v2 and IA16-GCC
> work good enough to produce functional kernel and FDISK binaries. We did
> not encounter major issues in recent times.

You might get some inspiration from the public repos under
> https://github.com/FDOS.
>

I'll have to take a closer look at how they are set up :) The cross
compilation stuff is especially interesting :)


> Regarding the edit-build-test cycle, this is where DosBox comes to its
> limit. Programs that use the ordinary DOS API and some BIOS interrupts tend
> to run fine.


I have noticed that, earlier this week I was implementing a ^C handler, and
it looks like DOSBox never emits an int23, or handle ^C in any way at
all... I plan to implement my int 24 handler over the weekend, and will
probably have to test on QEMU. For now I'm building on DOSBox and then
copying the files over to a floppy image and then load it from there in
QEMU, but that copy to floppy image is an extra step, makes testing that
much harder.


> But I had for example some minor problems with missing INT13 interrupt
> functions. Though the DosBox-X people were fast at implementing the missing
> pieces after I filed a report at their issue tracker. The kernel and other
> low-level stuff I test under 86box or on a real machine.
>

Hmm I'll have to try DOSBox-X, I see a lot of people mentioning it.


> Regarding debugging, for me the Watcom Debugger is a good enough debugger
> to debug most of the user space programs. It has a TUI and supports
> symbolic debugging. There are also free sophisticated debuggers like lDebug
> (command line based) that might be worth a look at, albeit I would consider
> this more geared towards assembly.
>

Thanks for the pointers, I'll take a look! DOG is mostly C but I do have a
whole bunch of inline assembly, and might move some of that over to actual
assembly.

So, once again welcome.
>

Thanks! It's good to be back :)
-Wolf

-- 

  |\_
  | .\---.
 /   ,__/
/   /Wolf <wol...@be...>_




> Bernd
>
>
>
> _______________________________________________
> Freedos-devel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>

Re: [Freedos-devel] Back at it with DOG

[Bernd B. <ber...@bo...>]

Hi Wolf,

welcome to the mailing list. Great to hear you started working again on DOG. Putting it on Github (or some other publicly accessible repo) sounds like a good idea :)

Looking at https://gitlab.com/FreeDOS/util/dog, that seems to be version 0.83c. Is this the latest publicly available version? Otherwise we should update the package.

> Now a question:
> What are your dev setups like? I'm on a linux host computer and I've been using both DOSBox and QEMU to build and test in. I find though that it's a bit of a chore, since DOSBox crashes randomly (like when compiling), or QEMU segfaults when I mount my dog source directory as a virtual FAT drive. So now I'm looking at setting up Dosemu2 (I remember using doemu ~20 years ago).

I mainly edit the source code of the DOS programs I work on with my Mac and compile them inside DosBox-X. For me, this is quite stable. I would like to test Dosemu2, but that seems not to be fully ported to Mac yet.

I use OpenWatcom 1.9 to compile my programs under DOS(Box), but also have setup Github actions for some projects to automatically build my commits using a Linux container with OpenWatcom v2 and IA16-GCC. While somewhat experimental, the Linux port of OpenWatcom v2 and IA16-GCC work good enough to produce functional kernel and FDISK binaries. We did not encounter major issues in recent times.

You might get some inspiration from the public repos under https://github.com/FDOS.

Regarding the edit-build-test cycle, this is where DosBox comes to its limit. Programs that use the ordinary DOS API and some BIOS interrupts tend to run fine. But I had for example some minor problems with missing INT13 interrupt functions. Though the DosBox-X people were fast at implementing the missing pieces after I filed a report at their issue tracker. The kernel and other low-level stuff I test under 86box or on a real machine.

Regarding debugging, for me the Watcom Debugger is a good enough debugger to debug most of the user space programs. It has a TUI and supports symbolic debugging. There are also free sophisticated debuggers like lDebug (command line based) that might be worth a look at, albeit I would consider this more geared towards assembly.

So, once again welcome.

Bernd

[Freedos-devel] Back at it with DOG

[Wolf B. <wol...@be...>]

Hi everyone,

After ~22 years I got back into coding on DOG. I'm working my way towards a
new release, 0.8.4b, in the ~soon timeframe. I'm also working on moving the
source code to GitHub and fixing the website. It had apparently broken
several years ago...

So far I've been fixing the code and implementing missing bits. It's a lot
of fun, and I really enjoy that the coding is so different from my day job
coding. :) Earlier this year I found Jim's great YT channel, and I think
that was a big part of me picking up DOG again, so thanks for that!

Now a question:
What are your dev setups like? I'm on a linux host computer and I've been
using both DOSBox and QEMU to build and test in. I find though that it's a
bit of a chore, since DOSBox crashes randomly (like when compiling), or
QEMU segfaults when I mount my dog source directory as a virtual FAT drive.
So now I'm looking at setting up Dosemu2 (I remember using doemu ~20 years
ago).

What do your dev environments look like? How do you make an efficient
edit-build-test cycle? Has anyone tried using watcom as a crosscompiler?

--Wolf

-- 

  |\_
  | .\---.
 /   ,__/
/   /Wolf <wol...@be...>_

Re: [Freedos-devel] Proposal for new package in T2405

[<je...@sh...>]

Hi Jim,

I created an i16env package.

Since it is very small and you did not specify a license anywhere, I assumed you intend it to be “Public Domain”. 

So, that’s how I listed it in the metadata. If that is incorrect, let me know. 

I added the package to be included on the BonusCD along with the other IA-16 packages. 

So, it will be on the next interim test build.

:-)

Jerome

Re: [Freedos-devel] FreeDOS on Pocket386

[Jim H. <jh...@fr...>]

Jim Hall wrote:
[..]
> > It arrived Friday. I powered it on to make sure it works, and it does.
> > They've pre-installed some pirated copy of Win95 on there, but I'll
> > reinstall the whole thing with FreeDOS anyway. :-)
> >
> > The Pocket386 only boots from the internal C: drive (a CF card). I
> > thought I still had a CF card reader (can't find it) so I've ordered a
> > new one. My plan is to image the CF card from Linux and make a copy,
> > then use QEMU with that drive image to install FreeDOS, then write the
> > image to the CF so I can boot the Pocket386 with it.
> >
> > I also ordered a PS/2 keyboard, because the built-in keyboard is too
> > tiny to do real work on. It's 8 1/4 x 4 1/2 x 1 1/4 (inches).


Jerome Shidel wrote:
> Having fun with your 386?
>
> Does it have sound and does it work under DOS?
>
> Where are you Benchmarks??


I haven't tinkered with it too much yet, because that micro keyboard
makes my wrists ache just by *looking* at it. The keys are so tiny
(letters are 13mm x 11mm .. arrows and punctuation keys are 10mm x
11mm) that I often hit the key next to the letter I'm trying to type.
I'm looking forward to using a full-size PS/2 keyboard. :-)

Win95 says:

Cirrus Logic CL-GD 5420 r1 Rev 0 video card (512k video memory)
8 MB RAM
Ad Lib Gold compatible OPL3 sound card

The CPU is 386SX-40.


Since I can't install DOS applications yet (that's why I ordered a CF
card reader) I can't say if the Ad Lib sound card actually works with
DOS games. I'll share an update when the CF card reader arrives and I
wipe this with FreeDOS and put some games and other software on it.
:-)


Jim

Re: [Freedos-devel] FreeDOS on Pocket386

[<je...@sh...>]

Hi Jim,

> On May 28, 2024, at 6:12 PM, Jim Hall via Freedos-devel <fre...@li...> wrote:
> 
> *I'm resending (with a few edits/updates) because this message failed
> over the weekend due to the SF list server outage
> 
> 
> You may remember the Book8088 micro-laptop and Hand386 handheld from
> last year. I always said I'd buy one if they were the other way
> around: a handheld 8088 or a '386 laptop.
> 
> Well, then they started selling the Pocket386 - and I bought one.
> 
> It arrived Friday. I powered it on to make sure it works, and it does.
> They've pre-installed some pirated copy of Win95 on there, but I'll
> reinstall the whole thing with FreeDOS anyway. :-)
> 
> The Pocket386 only boots from the internal C: drive (a CF card). I
> thought I still had a CF card reader (can't find it) so I've ordered a
> new one. My plan is to image the CF card from Linux and make a copy,
> then use QEMU with that drive image to install FreeDOS, then write the
> image to the CF so I can boot the Pocket386 with it.
> 
> I also ordered a PS/2 keyboard, because the built-in keyboard is too
> tiny to do real work on. It's 8 1/4 x 4 1/2 x 1 1/4 (inches).

Having fun with your 386?

Does it have sound and does it work under DOS?

Where are you Benchmarks??

:-)

Re: [Freedos-devel] FreeDOS on Pocket386

[Louis S. <lps...@gm...>]

Instead of investing in PS2, I’m building one or more of these.

https://docs.pikvm.org/pico_hid_bridge/


On Wed, May 29, 2024 at 12:15 AM Jerome Shidel via Freedos-devel <
fre...@li...> wrote:

>
> > On May 28, 2024, at 6:12 PM, Jim Hall via Freedos-devel <
> fre...@li...> wrote:
> > [..]
> > I also ordered a PS/2 keyboard, because the built-in keyboard is too
> > tiny to do real work on. It's 8 1/4 x 4 1/2 x 1 1/4 (inches).
>
> I just got one a few weeks ago along with a PS/2 mouse. Both brand new. I
> was kind of surprised they are still being manufactured. Maybe I should
> stock up.
>
> :-)
>
>
>
> _______________________________________________
> Freedos-devel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>

Re: [Freedos-devel] FreeDOS on Pocket386

[<je...@sh...>]

> On May 28, 2024, at 6:12 PM, Jim Hall via Freedos-devel <fre...@li...> wrote:
> [..]
> I also ordered a PS/2 keyboard, because the built-in keyboard is too
> tiny to do real work on. It's 8 1/4 x 4 1/2 x 1 1/4 (inches).

I just got one a few weeks ago along with a PS/2 mouse. Both brand new. I was kind of surprised they are still being manufactured. Maybe I should stock up.

:-)

 

Re: [Freedos-devel] Virtual dot matrix printer

[<je...@sh...>]

Hi Jim,

> On May 27, 2024, at 11:41 AM, Jim Hall via Freedos-devel <fre...@li...> wrote:
> 
> I created a FreeDOS program that simulates printing on a 9-pin impact
> ("dot matrix") printer.
> 
> I made this for a few reasons: 1. I am writing an article about dot
> matrix printing, and didn't have a good way to demonstrate it; and 2.
> It was something fun to do in an afternoon.
> 
> A few notes:
> 
> - This is a simplified version of a dot matrix printer. Characters are
> 5x8. The 9th "pin" is reserved for underline only. Although printer
> control codes aren't implemented yet, so underline doesn't work
> anyway.
> 
> - I didn't create a character set as "firmware" for the virtual
> printer. So currently, printable characters are rendered as the bit
> pattern for the character's ascii code (except 32, which is rendered
> as a space).

This gives you the perfect opportunity to demonstrate another program included with FreeDOS. 

You could use ImgEdit (under the Apps program group). While creating "the Danger Engine” 2D DOS gaming engine, I needed graphics and fonts. So, I built ImgEdit and DE at the same time. Because ImgEdit runs onto of DE, it was a "chicken or egg” development. 

ImgEdit is not perfect. There is a lot of stuff that ImgEdit does that was improved and moved into the actual DE at later points. Plus, there are at least 2 bugs I should get around to fixing someday. But overall, it works fairly well. Especially for this kind of thing. 

You can easily create a “new” font. The minimum size is 8x8. Doing a 5x8 font, you would just want to discard the extra bits in your program. 

You can only change sizes from the command line. So, you would run “imgedit myfont.fnt /size 8:8” 

ImgEdit will see there is no font file called “myfont.fnt” (or whatever filename you used) and create a new 8x8 font based on it’s own 8x8 font. 

You can then simply iterate through the characters, rotate them and save the font file. (note: since height and width are the same, rotate is available)

You can do this by using the mouse. Which I advise having the driver loaded, so you can navigate menus without having to remember the hotkeys. Also, the mouse will be needed if you want to make any pixel level changes to the font.

However, iterating and rotating will be much quicker to simply use the keyboard. 

Click on the first character (or use the arrow keys to get there). 
Press LEFT_ALT+T (rotate counter clockwise) or RIGHT_ALT+T (rotate clockwise)
If you need to adjust the position use LEFT_SHIFT+ARROW_KEY (move and fill with clear bit. right shift + arrow fills with set bit)
Use RIGHT_ARROW to move to the next character.
repeat until all characters were rotated
press ALT+S or click save in the menu.

Some notes: 

The file name is displayed in the lower right. If there have been changes made, it is in RED. If no changes since the last save, it is Gray. 
Left mouse click to set a pixel, right click to erase a pixel.
You can click and drag draw or erase.
The White and Gray carrots above the character indicate the farthest pixels in that character when it was selected. They do not change unless you select a different character. 
The Green and Red carrots below the character indicate the farthest pixels in the entire font. This is not much use in an 8x8 font or event x 9x16 font. But, ImgEdit supports bitmap fonts up to 32x32 at present. Actually the menu bar text is a proportionally spaced 16 bit wide font. All the lower case letter are less than 8 bits. Many of the uppercase letters are 10-bits wide. 
8-bit wide fonts are always saved and loaded the common format used by DOS bitmap raster font files. They can be loaded using programs like vfont, gnuchcp and other DOS programs. Fonts over 8-bits wide use a different file format by necessity. 

Down a rabbit hole… Technically from a programming standpoint, ImgEdit is not really an application with a graphical user interface. It’s a game. All the UI elements like buttons and menus are simulated by the Danger Engine using game elements like sprites. It’s abstracted a lot and the game engine presents it to the program like UI elements (buttons, menu items, etc). But, going a couple layers into the abstraction it is nothing like that at all. Depending on memory requirements, the engine is locking, releasing, loading and discarding all that stuff from images to font files behind the scenes through it’s game element asset management routines. 

:-)

Jerome


> I've shared it on my GitHub, with screenshots of the output:
> https://github.com/freedosproject/vp
> 
> 
> Compile with OpenWatcom. Uses the MIT license.
> 
> 
> Jim
> 
> 
> 
> *I grabbed the "freedosproject" username some time ago so no one else
> could take it and use it for something else. I use this account to
> share source code for programming projects that I do on the YouTube
> channel. The FreeDOS source archive is at GitLab:
> https://gitlab.com/FreeDOS (there's also a link from my GitHub
> profile)
> 
> 
> _______________________________________________
> Freedos-devel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Proposal for new package in T2405

[Jerome S. <je...@sh...>]

> On May 28, 2024, at 7:56 PM, Jim Hall via Freedos-devel <fre...@li...> wrote:
> 
> Jim Hall wrote:
>> 
>>> This didn't get any discussion a month ago. Since it didn't appear in
>>> T2405, I wanted to raise it again for T2406. Can we add this to T2406?
>>> Adding a DJGPP.ENV file is all you need to compile programs with IA-16
>>> GCC without installing the full DJGPP environment.
>>> 
>>> To make it easier to add to the distribution, I've created a 427-byte
>>> zip file that contains DJGPP.ENV and SETENV.BAT; if you unzip this at
>>> the root dir, then both get installed to \devel\i16gcc. I've copied
>>> the zip file to the FreeDOS Files Archive at Ibiblio, here:
>>> 
>>> https://ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/c/gcc-ia16/
>>> I16ENV.ZIP
>>> 
>>> The I16ENV.TXT file is just a brief Readme about it.
> 
> Jerome Shidel wrote:
>> 
>> Wouldn’t it make more sense to just add those files to the https://gitlab.com/FreeDOS/devel/i16gcc package?
>> 
>> But, I don’t use it. So, maybe that would be an issue or confusing to users.
> 
> 
> We can add it to that package, if you think that's better. But I also
> wrote this in my original email:
> 
> [..]
> :: But because we aren't updating any original IA-16 GCC packages, it
> :: keeps things clean at the expense of a little extra "overhead" for the
> :: package. But if you're installing a C compiler, you likely can spare
> :: the tiny extra space.
> 
> ..so I thought it might be nice not to "pollute" TK Chia's IA-16 GCC
> release with these two files. And we already have several other
> packages that are part of IA-16 GCC, adding this one didn't seem like
> a lot of overhead.
> 
> But ultimately it doesn't matter to me if it gets merged into the
> https://gitlab.com/FreeDOS/devel/i16gcc package or stays separate.
> 
> 
> Jim
> 

I see what you’re saying about “polluting” the existing package. It also would require additional care anytime the package received an update.

Maybe it be possible to convince TK Chai to add the changes in his upstream version?

We could always add a small package for it. Then if the upstream version is updated, we could drop the “patch” package.


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

Re: [Freedos-devel] Proposal for new package in T2405

[Jim H. <jh...@fr...>]

Jim Hall wrote:
>
>> This didn't get any discussion a month ago. Since it didn't appear in
>> T2405, I wanted to raise it again for T2406. Can we add this to T2406?
>> Adding a DJGPP.ENV file is all you need to compile programs with IA-16
>> GCC without installing the full DJGPP environment.
>>
>> To make it easier to add to the distribution, I've created a 427-byte
>> zip file that contains DJGPP.ENV and SETENV.BAT; if you unzip this at
>> the root dir, then both get installed to \devel\i16gcc. I've copied
>> the zip file to the FreeDOS Files Archive at Ibiblio, here:
>>
>> https://ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/c/gcc-ia16/
>> I16ENV.ZIP
>>
>> The I16ENV.TXT file is just a brief Readme about it.

Jerome Shidel wrote:
>
> Wouldn’t it make more sense to just add those files to the https://gitlab.com/FreeDOS/devel/i16gcc package?
>
> But, I don’t use it. So, maybe that would be an issue or confusing to users.


We can add it to that package, if you think that's better. But I also
wrote this in my original email:

[..]
:: But because we aren't updating any original IA-16 GCC packages, it
:: keeps things clean at the expense of a little extra "overhead" for the
:: package. But if you're installing a C compiler, you likely can spare
:: the tiny extra space.

..so I thought it might be nice not to "pollute" TK Chia's IA-16 GCC
release with these two files. And we already have several other
packages that are part of IA-16 GCC, adding this one didn't seem like
a lot of overhead.

But ultimately it doesn't matter to me if it gets merged into the
https://gitlab.com/FreeDOS/devel/i16gcc package or stays separate.


Jim

Re: [Freedos-devel] Proposal for new package in T2405

[Jerome S. <je...@sh...>]

Hi Jim,

> On May 28, 2024, at 3:47 PM, Jim Hall via Freedos-devel <fre...@li...> wrote:
> 
> This didn't get any discussion a month ago. Since it didn't appear in
> T2405, I wanted to raise it again for T2406. Can we add this to T2406?
> Adding a DJGPP.ENV file is all you need to compile programs with IA-16
> GCC without installing the full DJGPP environment.
> 
> To make it easier to add to the distribution, I've created a 427-byte
> zip file that contains DJGPP.ENV and SETENV.BAT; if you unzip this at
> the root dir, then both get installed to \devel\i16gcc. I've copied
> the zip file to the FreeDOS Files Archive at Ibiblio, here:
> 
> https://ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/c/gcc-ia16/
> I16ENV.ZIP
> 
> The I16ENV.TXT file is just a brief Readme about it.
> 

Wouldn’t it make more sense to just add those files to the https://gitlab.com/FreeDOS/devel/i16gcc package?

But, I don’t use it. So, maybe that would be an issue or confusing to users. 



> 
>> On Wed, Apr 10, 2024 at 10:52 AM Jim Hall <jh...@fr...> wrote:
>> 
>> Based on my other email about getting IA-16 GCC to work on T2404
>> without installing DJGPP, I propose adding a new package in T2405
>> called I16ENV that just has two files in it:
>> 
>> /devel/i16gnu/djgpp.env
>> /devel/i16gnu/setenv.bat
>> 
>> The DJGPP.ENV file contains just:
>> 
>> DJDIR=
>> 
>> And the SETENV.BAT file sets the PATH and points the DJGPP environment
>> variable to the DJGPP.ENV file, like this:
>> 
>> @ECHO OFF
>> PATH %PATH%;C:\DEVEL\I16GNU\BIN
>> SET DJGPP=C:\DEVEL\I16GNU\DJGPP.ENV
>> 
>> 
>> Since it gets installed in the IA-16 GCC directory, it shouldn't get
>> confused with the DJGPP stuff. If the DJGPP env file is called
>> DJGPP.ENV, it will make more sense when people find references to
>> "DJGPP.ENV" in other documentation. And because the package will be
>> named similarly to the other IA-16 GCC packages, users will be more
>> likely to install it when they install IA-16 GCC. But because we
>> aren't updating any original IA-16 GCC packages, it keeps things clean
>> at the expense of a little extra "overhead" for the package. But if
>> you're installing a C compiler, you likely can spare the tiny extra
>> space.
>> 
>> This will be a good way for others to start testing compiling programs
>> using IA-16 GCC in a working default configuration on a fresh install,
>> starting with the next test release.
>> 
>> This works on my T2404 installation. Here is a copy/paste of my
>> FreeDOS session after a fresh reboot (using unmodified FDAUTO.BAT):
>> 
>> C:\DEVEL>dir /b
>> I16GNU
>> WATCOMC
>> 
>> C:\DEVEL>cd i16gnu
>> 
>> C:\DEVEL\I16GNU>dir /b
>> BIN
>> IA16-ELF
>> LIB
>> LIBEXEC
>> SHARE
>> DJGPP.ENV
>> SETENV.BAT
>> 
>> C:\DEVEL\I16GNU>type setenv.bat
>> @ECHO OFF
>> PATH %PATH%;C:\DEVEL\I16GNU\BIN
>> SET DJGPP=C:\DEVEL\I16GNU\DJGPP.ENV
>> 
>> C:\DEVEL\I16GNU>type DJGPP.ENV
>> DJDIR=
>> 
>> C:\DEVEL\I16GNU>setenv.bat
>> 
>> .. now I'll switch to the D: drive to compile a program ..
>> 
>> D:\SRC>dir /b hello.*
>> HELLO.C
>> 
>> D:\SRC>type hello.c
>> #include <stdio.h>
>> int main()
>> {
>>    puts("Hello world");
>>    return 0;
>> }
>> 
>> D:\SRC>i16gcc -Wall -o hello.exe hello.c
>> 
>> D:\SRC>dir /b hello.*
>> HELLO.C
>> HELLO.EXE
>> 
>> D:\SRC>hello.exe
>> Hello world
> 
> 
> _______________________________________________
> Freedos-devel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Free FDISK 1.3.15

[Jim H. <jh...@fr...>]

On Tue, May 28, 2024 at 6:04 PM Bernd Böckmann via Freedos-devel
<fre...@li...> wrote:
>
> Free FDISK 1.3.15 is released.
>
> https://github.com/FDOS/fdisk/releases/tag/v1.3.15
>
> Fixes:
[..]


Thanks! I've posted a news item and mirrored this to the FreeDOS Files
Archive at Ibiblio.

[Freedos-devel] Free FDISK 1.3.15

[Bernd B. <ber...@bo...>]

Free FDISK 1.3.15 is released.

https://github.com/FDOS/fdisk/releases/tag/v1.3.15

Fixes:
    • HIGH: Fix FDISK not modifying partition type via
      command /MODIFY and via UI if FDISK is started in
      extended options mode /XO.
    • HIGH: respect selected video page instead of hardcoding
      it to zero when calling INT 10 routines.
Changes:
    • FDISK provided MBR bootloader does not require more
      than 128K of RAM anymore. It should run with as low
      as 64K of RAM.
    • Work around Xi8088 and Book8088 BIOS bug
      (bootloader and FDISK itself).
    • Assume BIOS drive number of 0x80 to boot from if
      BIOS tells us it is unit 0. This should be an error,
      because we boot from hard disk. FDISK would not
      even "see" the disk if it is unit 0.

Bernd

[Freedos-devel] FreeDOS on Pocket386

[Jim H. <jh...@fr...>]

*I'm resending (with a few edits/updates) because this message failed
over the weekend due to the SF list server outage


You may remember the Book8088 micro-laptop and Hand386 handheld from
last year. I always said I'd buy one if they were the other way
around: a handheld 8088 or a '386 laptop.

Well, then they started selling the Pocket386 - and I bought one.

It arrived Friday. I powered it on to make sure it works, and it does.
They've pre-installed some pirated copy of Win95 on there, but I'll
reinstall the whole thing with FreeDOS anyway. :-)

The Pocket386 only boots from the internal C: drive (a CF card). I
thought I still had a CF card reader (can't find it) so I've ordered a
new one. My plan is to image the CF card from Linux and make a copy,
then use QEMU with that drive image to install FreeDOS, then write the
image to the CF so I can boot the Pocket386 with it.

I also ordered a PS/2 keyboard, because the built-in keyboard is too
tiny to do real work on. It's 8 1/4 x 4 1/2 x 1 1/4 (inches).

Re: [Freedos-devel] Proposal for new package in T2405

[Jim H. <jh...@fr...>]

This didn't get any discussion a month ago. Since it didn't appear in
T2405, I wanted to raise it again for T2406. Can we add this to T2406?
Adding a DJGPP.ENV file is all you need to compile programs with IA-16
GCC without installing the full DJGPP environment.

To make it easier to add to the distribution, I've created a 427-byte
zip file that contains DJGPP.ENV and SETENV.BAT; if you unzip this at
the root dir, then both get installed to \devel\i16gcc. I've copied
the zip file to the FreeDOS Files Archive at Ibiblio, here:

https://ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/c/gcc-ia16/
I16ENV.ZIP

The I16ENV.TXT file is just a brief Readme about it.


On Wed, Apr 10, 2024 at 10:52 AM Jim Hall <jh...@fr...> wrote:
>
> Based on my other email about getting IA-16 GCC to work on T2404
> without installing DJGPP, I propose adding a new package in T2405
> called I16ENV that just has two files in it:
>
> /devel/i16gnu/djgpp.env
> /devel/i16gnu/setenv.bat
>
> The DJGPP.ENV file contains just:
>
> DJDIR=
>
> And the SETENV.BAT file sets the PATH and points the DJGPP environment
> variable to the DJGPP.ENV file, like this:
>
> @ECHO OFF
> PATH %PATH%;C:\DEVEL\I16GNU\BIN
> SET DJGPP=C:\DEVEL\I16GNU\DJGPP.ENV
>
>
> Since it gets installed in the IA-16 GCC directory, it shouldn't get
> confused with the DJGPP stuff. If the DJGPP env file is called
> DJGPP.ENV, it will make more sense when people find references to
> "DJGPP.ENV" in other documentation. And because the package will be
> named similarly to the other IA-16 GCC packages, users will be more
> likely to install it when they install IA-16 GCC. But because we
> aren't updating any original IA-16 GCC packages, it keeps things clean
> at the expense of a little extra "overhead" for the package. But if
> you're installing a C compiler, you likely can spare the tiny extra
> space.
>
> This will be a good way for others to start testing compiling programs
> using IA-16 GCC in a working default configuration on a fresh install,
> starting with the next test release.
>
> This works on my T2404 installation. Here is a copy/paste of my
> FreeDOS session after a fresh reboot (using unmodified FDAUTO.BAT):
>
> C:\DEVEL>dir /b
> I16GNU
> WATCOMC
>
> C:\DEVEL>cd i16gnu
>
> C:\DEVEL\I16GNU>dir /b
> BIN
> IA16-ELF
> LIB
> LIBEXEC
> SHARE
> DJGPP.ENV
> SETENV.BAT
>
> C:\DEVEL\I16GNU>type setenv.bat
> @ECHO OFF
> PATH %PATH%;C:\DEVEL\I16GNU\BIN
> SET DJGPP=C:\DEVEL\I16GNU\DJGPP.ENV
>
> C:\DEVEL\I16GNU>type DJGPP.ENV
> DJDIR=
>
> C:\DEVEL\I16GNU>setenv.bat
>
> .. now I'll switch to the D: drive to compile a program ..
>
> D:\SRC>dir /b hello.*
> HELLO.C
>
> D:\SRC>type hello.c
> #include <stdio.h>
> int main()
> {
>     puts("Hello world");
>     return 0;
> }
>
> D:\SRC>i16gcc -Wall -o hello.exe hello.c
>
> D:\SRC>dir /b hello.*
> HELLO.C
> HELLO.EXE
>
> D:\SRC>hello.exe
> Hello world

Re: [Freedos-devel] zoo just needs packaging

[Bernd B. <ber...@bo...>]

On 28.05.2024 19:00, thraex via Freedos-devel wrote:

> There's also someone who has been updating zoo with bug fixes for 
> UNIX-like platforms on <https://github.com/troglobit/zoo>, maybe 
> cherry-picking some of them could make sense. 

Cherry-picking might not the best idea here. In my opinion providing a 
DOS makefile to the repository would be more beneficial. As the 
repository owner says:

> This project exists as a service to all computer archaeologists and 
> acts as a focal point for patches and maintenance for the long haul.

The FreeDOS package is updated with the fixed binary. Apart from that, I 
am not planning to do any work on the code. But I may update the package 
if someone else continues to work on it...

Greetings, Bernd