Re: [Freedos-devel] Two remarks about FreeDOS 1.3 RC5

[Jerome Shidel]

> On Dec 24, 2021, at 5:27 PM, Juan Manuel Guerrero  
> wrote:
> 
> I have been playing with the latestet FreeDOS 1.3 RC5 and I have
> observed that the line:
>  if exist %dosdir%\LINKS\NUL set PATH=%path%;%dosdir%\LINKS
> in FDAUTO.BAT does not work because LINKS and all the other network
> stuff is installed in the C:\NET directory and not into the directory
> pointed by %dosdir%. E.g.: LINKS is installed in the directory
> C:\NET\LINKS.  Thus the above line in FDAUTO.BAT will never work.
> Either the NET directory is removed and its content is moved into
> %dosdir% or the above line is adjusted accordingly so it points to
> C:\NET.

The PATH setting for %DOSDIR%\LINKS has nothing to do with either 
networking or the LINKS web browser. It is a directory where the package
manager places small com or batch files that “link” to programs that are
not generally included in the PATH settings. 

Depending on wether or not a full installation is performed. Or, if other 
packages that use the %DOSDIR%\LINKS directory are installed, that
directory may or may not exists. That is why was entered into FDAUTO
using the IF EXIST statement and not just always set into the PATH.





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

[Freedos-devel] Two remarks about FreeDOS 1.3 RC5

[Juan Manuel Guerrero]

I have been playing with the latestet FreeDOS 1.3 RC5 and I have
observed that the line:
  if exist %dosdir%\LINKS\NUL set PATH=%path%;%dosdir%\LINKS
in FDAUTO.BAT does not work because LINKS and all the other network
stuff is installed in the C:\NET directory and not into the directory
pointed by %dosdir%. E.g.: LINKS is installed in the directory
C:\NET\LINKS.  Thus the above line in FDAUTO.BAT will never work.
Either the NET directory is removed and its content is moved into
%dosdir% or the above line is adjusted accordingly so it points to
C:\NET.

The second issue is that the DJGPP port of lynx distributed with RC5 is
broken. As I have announced in:
  https://www.delorie.com/archives/browse.cgi?p=djgpp/2021/12/02/18:54:50
the fixed port is available as:
  http://ftp.delorie.com/pub/djgpp/current/v2tk/l290d10b.zip
  http://ftp.delorie.com/pub/djgpp/current/v2tk/l290d10d.zip
  http://ftp.delorie.com/pub/djgpp/current/v2tk/l290d10s.zip
Please note the time stamp of 2021-11-30 or later for the zip files.
Please use the fixed port in your distribution so I do not get bug
reports about things that have already been fixed.

Kind regards,
Juan M. Guerrero


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

Re: [Freedos-devel] The land that time forgot

[perditionc]

On Fri, Dec 24, 2021, 9:39 AM Jerome Shidel  wrote:

> Hello Everyone,
> ...
>
> One such item I noticed was the ATAPICDD driver. It might be nice to have
> an alternate CD driver that might cover some additional hardware. So, I
> added to that one to the repos. But, I don’t know much about this driver
> other than it is open source. I don’t know if it will cover any hardware
> not currently supported. I don’t know if it is rock solid or buggy. I don’t
> know if we should include it in the release or not. I know very little
> about it.
>
>
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/atapicdd.html
> https://gitlab.com/FreeDOS/drivers/atapicdd
>
> I’m going to try to find some time over the next few days to do some
> testing of that driver. But, I’d appreciate any feedback on it the group
> has regarding it. Does anyone remember anything about it?
>
> ...
> :-)
>
> Jerome
>


Hello,

So quick answer, it's my driver, Jack's is way better, it is PIO only (no
DMA) so slow and buggy.  No need to include.

Longer answer, at the time we had no free general CD driver.  We had
permission to include the eltorito driver and I forget the exact brand but
also have permission to include a closed source one that unfortunately
worked with older CD drives and not modern ones (around 2005 era, so really
wouldn't work with current drives probably).  So I started reading the
specifications and implementing one.  It works for some definition of work,
but was never completed.  Jack made his available and so I never got back
to it when I had some time.  I had a more advanced version than released
but lost sources a long time ago.  I do not have it in public source
control (only private git repository now), though it is/was somewhere on my
fdos.org site.

>
Jeremy


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

Re: [Freedos-devel] Testing FreeDOS 1.3 RC5 (Games)

[Ralf Quint]

On 12/24/2021 7:49 AM, TK Chia wrote:

Hello Daniel, hello Jim,


Thanks for the tests!
Both games use a combination of kbhit + getch (with the arrow keys
taking an extra getch, if the first one yields either 0 or 224).


[...]


Right now I'm writing a new real mode game (actually, a demake of my
WIP protected mode game, https://montyontherun.itch.io/sub), using
ia16-gcc and reading the keyboard with inline ASM by invoking int 16
and int 21. Would that be safer? If so, I can modify all my games to
use that option, if so.


Apparently DJGPP uses int 0x16 to implement kbhit (), but int 0x21 to
implement getch () --- I am not sure why --- and this might be a source
of the "double keypress" problem.  (I.e. there might be a DJGPP bug.)


In general, I think it is best to stick to one way of getting keyboard
input (different OS interfaces may have different buffers for keyboard
input, and thus slightly different ideas on which keys have been
processed or not).

So, if you poll for keyboard input using int 0x16, then you should also
consume the keyboard input using int 0x16; if you poll using int 0x21,
then consume using int 0x21 as well; if you poll using an IRQ 1 handler,
then consume the input there as well; etc.

If you still want to build your code to build under DJGPP, perhaps
instead of writing inline assembly, you can consider using the
_bios_keybrd (.) function ().  This function will consistently
call int 0x16 to read keyboard input. :-)  It is also supported by Open
Watcom, and by my libi86 + gcc-ia16. 


That's what I tried to tell you guys at the last online meeting. Mixing 
the different levels of access (DOS (INT21h),  BIOS (INT16h) and direct 
I/O port calls) is most likely to cause some issues. Even more so in 
environments that switch between real mode and protected mode, like 
DJGPP. At least one has to be careful to consider the exact state of 
things like keyboard buffer etc when doing so...


Ralf


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



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

Re: [Freedos-devel] Testing FreeDOS 1.3 RC5 (Games)

[TK Chia]

Hello Daniel, hello Jim,


Thanks for the tests!
Both games use a combination of kbhit + getch (with the arrow keys
taking an extra getch, if the first one yields either 0 or 224).


[...]


Right now I'm writing a new real mode game (actually, a demake of my
WIP protected mode game, https://montyontherun.itch.io/sub), using
ia16-gcc and reading the keyboard with inline ASM by invoking int 16
and int 21. Would that be safer? If so, I can modify all my games to
use that option, if so.


Apparently DJGPP uses int 0x16 to implement kbhit (), but int 0x21 to
implement getch () --- I am not sure why --- and this might be a source
of the "double keypress" problem.  (I.e. there might be a DJGPP bug.)


In general, I think it is best to stick to one way of getting keyboard
input (different OS interfaces may have different buffers for keyboard
input, and thus slightly different ideas on which keys have been
processed or not).

So, if you poll for keyboard input using int 0x16, then you should also
consume the keyboard input using int 0x16; if you poll using int 0x21,
then consume using int 0x21 as well; if you poll using an IRQ 1 handler,
then consume the input there as well; etc.

If you still want to build your code to build under DJGPP, perhaps
instead of writing inline assembly, you can consider using the
_bios_keybrd (.) function ().  This function will consistently
call int 0x16 to read keyboard input. :-)  It is also supported by Open
Watcom, and by my libi86 + gcc-ia16.

Thank you!

--
https://gitlab.com/tkchia :: https://github.com/tkchia


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

[Freedos-devel] The land that time forgot

[Jerome Shidel]

Hello Everyone,

Recently, I noticed we had translations for a program that was not in the 
online repositories. This caused me to to do some digging and I found out 
something rather interesting. 

Many years ago when FreeDOS 0.9 SR2 was released, it included several things we 
seem to forgotten about. There are programs and drivers present that are not in 
more modern releases. Some of these are were not in any of the repositories or 
even the file archives on ibiblio. They were only on the CD itself.

One such item I noticed was the ATAPICDD driver. It might be nice to have an 
alternate CD driver that might cover some additional hardware. So, I added to 
that one to the repos. But, I don’t know much about this driver other than it 
is open source. I don’t know if it will cover any hardware not currently 
supported. I don’t know if it is rock solid or buggy. I don’t know if we should 
include it in the release or not. I know very little about it.

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/atapicdd.html
 

https://gitlab.com/FreeDOS/drivers/atapicdd 


I’m going to try to find some time over the next few days to do some testing of 
that driver. But, I’d appreciate any feedback on it the group has regarding it. 
Does anyone remember anything about it? 

I would assume that when it comes to old programs most things that have been 
replaced or removed for good reason. But, this also raises an additional 
question. Are there other programs that we may have included long ago that we 
should re-examine now?

:-)

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

Re: [Freedos-devel] RC4 Videos (was Testing FreeDOS 1.3 RC5)

[Louis Santillan]

Agreed.  It was all mostly good feedback and notes about quirks in FD vs.
other DOSes.



On Fri, Dec 24, 2021 at 2:10 AM Jerome Shidel  wrote:

> Hi Louis,
>
> On Dec 24, 2021, at 4:36 AM, Louis Santillan  wrote:
>
>
> An interesting (and series of very very long) "hot takes" of FD 1.3RC4
> from the "Temporarily Offline Retro Tech" youtube channel.
>
>
> I’ve seen all but part 4 (which I’m going to watch in a few minutes). I
> didn’t think to mention them here. I’m glad you did.
>
> His video’s provide a very ingesting perspective on RC4. Some of which has
> changed in RC5. Many things have not.
>
> He is new to FreeDOS but not new to DOS. Watching the videos, points out
> several glaring issues that should be resolved.
>
>
> FreeDOS Install and Bundled Apps - Part 1
> https://youtu.be/j6s50qGZzO4
> FDOS! What's in the FDOS folder? - FreeDOS Part 2
> https://youtu.be/v-_RqLP_Bgs
> More FDOS! = The Executables #DOSCember
> https://youtu.be/Qph-cg7K9bs
> The Return of FreeDOS | Part 4 | The wrap!
> https://youtu.be/g892q2XxcKs
>
>
>
> On Wed, Dec 22, 2021 at 11:07 AM Jim Hall  wrote:
>
>> On Wed, Dec 22, 2021 at 12:45 PM Bret Johnson  wrote:
>> > I realize that VMs are all the rage these days for DOS, but I would
>> > also like to see how things work on real hardware.  I rarely play
>> > games myself any more, but games are usually a pretty good test of
>> > compatibility.
>> [..]
>>
>> Yes, that's why I started this discussion thread. I'd love for others
>> to test and share their experiences here.
>>
>> Please test on real hardware and reply on this thread. Good to have
>> testing all around.
>>
>> 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
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Testing FreeDOS 1.3 RC5 (Games)

[Daniel Monteiro]

Hello - I'm the author of both Dungeons of Noudar and The Mistral Report.

Thanks for the tests!
Both games use a combination of kbhit + getch (with the arrow keys
taking an extra getch, if the first one yields either 0 or 224).
While I should certainly write my own keyboard handler, that was very
low in my priorities when writing those games. I suppose the problem
happens only with the arrow keys? Both use the libc from "modern"
DJGPP cross-compilers, BTW.

Right now I'm writing a new real mode game (actually, a demake of my
WIP protected mode game, https://montyontherun.itch.io/sub), using
ia16-gcc and reading the keyboard with inline ASM by invoking int 16
and int 21. Would that be safer? If so, I can modify all my games to
use that option, if so.

Cheers,
Daniel "MontyOnTheRun" Monteiro

PS: Noudar can be played with Adlib, OPL2LPT and PC Speaker, by using
special parameters to the executable (which are the lowercase name of
those sound options, eg. "noudar opl2lpt"). I've been dragging my feet
to add a nice sound setup like the one in Mistral (which was a homage
to the old Microprose simulators)

On Wed, Dec 22, 2021 at 1:03 AM Jim Hall  wrote:

> Mistral (turn-based spy RPG game)
> VB: Plays okay
> QEMU: Starts up okay, and I get sound, but I get the "double keypress"
> problem and can't select Quit.

> Noudar (3D dungeon crawler)
> VB: Plays fine.
> QEMU: Starts up okay, but I have the "double keypress" problem so if I
> hit right/left to turn right or left, it turns me all the way around.
> Unplayable.


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

[Freedos-devel] RC4 Videos (was Testing FreeDOS 1.3 RC5)

[Jerome Shidel]

Hi Louis,

> On Dec 24, 2021, at 4:36 AM, Louis Santillan  wrote:
> 
> 
> An interesting (and series of very very long) "hot takes" of FD 1.3RC4 from 
> the "Temporarily Offline Retro Tech" youtube channel.

I’ve seen all but part 4 (which I’m going to watch in a few minutes). I didn’t 
think to mention them here. I’m glad you did.

His video’s provide a very ingesting perspective on RC4. Some of which has 
changed in RC5. Many things have not. 

He is new to FreeDOS but not new to DOS. Watching the videos, points out 
several glaring issues that should be resolved. 

> 
> FreeDOS Install and Bundled Apps - Part 1
> https://youtu.be/j6s50qGZzO4 
> FDOS! What's in the FDOS folder? - FreeDOS Part 2
> https://youtu.be/v-_RqLP_Bgs 
> More FDOS! = The Executables #DOSCember
> https://youtu.be/Qph-cg7K9bs 
> The Return of FreeDOS | Part 4 | The wrap!
> https://youtu.be/g892q2XxcKs 
> 
> 
> 
> On Wed, Dec 22, 2021 at 11:07 AM Jim Hall  > wrote:
> On Wed, Dec 22, 2021 at 12:45 PM Bret Johnson  > wrote:
> > I realize that VMs are all the rage these days for DOS, but I would
> > also like to see how things work on real hardware.  I rarely play
> > games myself any more, but games are usually a pretty good test of
> > compatibility.
> [..]
> 
> Yes, that's why I started this discussion thread. I'd love for others
> to test and share their experiences here.
> 
> Please test on real hardware and reply on this thread. Good to have
> testing all around.
> 
> 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] Testing FreeDOS 1.3 RC5 (Games)

[Louis Santillan]

An interesting (and series of very very long) "hot takes" of FD 1.3RC4 from
the "Temporarily Offline Retro Tech" youtube channel.

FreeDOS Install and Bundled Apps - Part 1
https://youtu.be/j6s50qGZzO4
FDOS! What's in the FDOS folder? - FreeDOS Part 2
https://youtu.be/v-_RqLP_Bgs
More FDOS! = The Executables #DOSCember
https://youtu.be/Qph-cg7K9bs
The Return of FreeDOS | Part 4 | The wrap!
https://youtu.be/g892q2XxcKs



On Wed, Dec 22, 2021 at 11:07 AM Jim Hall  wrote:

> On Wed, Dec 22, 2021 at 12:45 PM Bret Johnson  wrote:
> > I realize that VMs are all the rage these days for DOS, but I would
> > also like to see how things work on real hardware.  I rarely play
> > games myself any more, but games are usually a pretty good test of
> > compatibility.
> [..]
>
> Yes, that's why I started this discussion thread. I'd love for others
> to test and share their experiences here.
>
> Please test on real hardware and reply on this thread. Good to have
> testing all around.
>
> 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