Re: [Freedos-user] Codepage and keyboard setting for Czech language

[Mateusz Viste via Freedos-user]

On 19/12/2023 18:18, Lukáš Kotek via Freedos-user wrote:

display con=(ega,852,1)
mode con codepage prepare ((852) C:\freedos\cpi\ega.cpx)
mode con codepage select=852

All czech-specific letters are printed correctly now.

Is this the recommended way?


Yes, it is the "official" way, as Microsoft intended. Essentially 
loading the set of CP852 characters into the EGA/VGA memory, otherwise 
the video hardware usually defaults to CP437.


Or is there some a bit more straightforward 
approach possible, please?


Back in the day it was common in Poland to use hacky TSRs to display 
Polish characters in the Mazovia format, which was a national standard 
superior in many aspects to the Microsoft 852 proposition. Our Pepíci 
brothers had a very similar solution, albeit the standard of course had 
to be different because we use different glyphs: on your side of the 
border you used the Kamenicky encoding, and there were TSRs floating 
around on floppies to support Kamenicky on EGA screens, just like there 
were TSRs for Mazovia on our side.


A couple of links so you can get a good idea what to look for:

http://www.cestina.cz/pocestovani/dos/system/display.html
http://www.cestina.cz/kodovani/#KEYBCS2
https://vitsoft.info/ (Podpora češtiny)


Mateusz


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

[Freedos-user] EduQiz rel 2023

[Mateusz Viste via Freedos-user]

Hello List,

About a year ago I have created a graphical, quiz-like program as a 
pretext for my kids to get some hands-on with my 386 PC and learn a 
thing or two in the process. I named the program EduQiz and kept it 
private until now. Since I am quite satisfied about how it turned out, I 
decided to publish it today. Here it is:


http://eduqiz.osdn.io/

"EduQiz is a computer tool that is meant to assist students or children 
in memorizing words, facts, dates, or any other information through 
repetitive quizzes. Supports VGA graphics and SoundBlaster digitized 
sounds."


EduQiz does not come with any good quizzes (only two simple examples), 
so you have to create the quizzes yourself. How to do so is explained in 
the documentation shipped with the program.


Mateusz


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

Re: [Freedos-user] ChkDsk / ScanDsk for Fat32

[Mateusz Viste via Freedos-user]

On 25/09/2023 11:20, Jürgen Wondzinski via Freedos-user wrote:

Thanks for the pointer!  Unfortunately, that one wants some DPMI memory:
"Load error: no DPMI - Get csdpmi*b.zip"

That's my current config.sys part on that USB-Sticks, which run that FoxPro 
program:

device=c:\freedos\jemmEx.exe PGE maxext=32000 noems

Do I need to add that csdpmi stuff, or is it possible to configure DPMI with 
the standard Freedos options?


You only need to install CWSDPMI.EXE in your %PATH%.

Mateusz


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

Re: [Freedos-user] ChkDsk / ScanDsk for Fat32

[Mateusz Viste via Freedos-user]

On 15/09/2023 19:42, Jürgen Wondzinski via Freedos-user wrote:

Is there a ChkDsk or ScanDsk etc available for FAT32?
The usual chkdsk92.exe doesn't support this.


You might want to try DOSFSCK.

Mateusz


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

Re: [Freedos-user] FreeDOS and the Gemini protocol

[Mateusz Viste via Freedos-user]

On 19/08/2023 09:11, Paul Dufresne via Freedos-user wrote:
I am writing this here, because I believe the low-resource needed to run 
a Gemini Browser is appropriate for FreeDOS.


Gemini is an invention that shoehorns a gopher-like protocol into TLS.

TLS is everything but "low ressource".

For a low-power internet protocol there is the original Gopher.
FreeDOS comes with at least one gopher client already: gopherus.


Mateusz


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

Re: [Freedos-user] Sved, yet another text editor

[Mateusz Viste via Freedos-user]

On 07/08/2023 02:47, Bret Johnson wrote:

Does it have copy/cut/paste functionality?


Yes, albeit I failed implementing text-selection without making the 
resulting binary bigger than my 7K goal, so I had to opt for an 
unconventional handling of copy/paste.


From SVED's documentation:

CTRL+C = copy the current line to clipboard
CTRL+X = cut the current line and move it to clipboard
CTRL+V = paste the clipboard content to current location


Mateusz


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

Re: [Freedos-user] How do I change screen resolution?

[Mateusz Viste via Freedos-user]

On 8/6/23 23:34, Ralf Quint via Freedos-user wrote:
DOS is using *text *mode, you just can't select a*graphics *mode and 
expect to get text output in that mode.


BIOS text output functions still work in most graphic modes, hence 
having a DOS shell running in graphic mode is nothing unusual. Of course 
problems may arise for text applications that make assumptions about the 
terminal size or that write directly to VRAM without re-setting a proper 
text mode.


And btw,  80x25 character text mode in fact is technically a 640x480 
"VGA mode"


It's 720x400.


(using the standard 8x16 character matrix, 80x8=640


On VGA there's this cool ninth's bit that improves readability quite a lot.


25*16-480).

Does not compute.


Mateusz


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

[Freedos-user] Sved, yet another text editor

[Mateusz Viste via Freedos-user]

Because I felt that the world needed another DOS text editor, I have 
spent past month's evenings on a new project named SVED.


SVED (short for "the SvarDOS editor") is designed for basic editing of 
configuration files and such. It is NOT meant to be a full-featured text 
editor. On the pro side, it has a low memory footprint and is only a 
couple kilobytes big, which makes it a good fit for bootdisks or systems 
with extremely limited resources.


 - runs comfortably on a 8086-class PC with 256 KiB of RAM
 - auto-detects color and monochrome video modes
 - supports unusual text modes like 80x43, 80x50, 40x25...
 - multilingual UI
 - only 7 KiB of disk footprint
 - screen estate dedicated to text (no stupid frames, menus and such)
 - loads files larger than 64 KiB
 - no line length limit
 - can load up to 10 files simultaneously
 - handles CR/LF and LF line endings and can convert between them

http://svardos.org/sved

Mateusz


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

Re: [Freedos-user] (C library) SvarLANG ver 20230730

[Mateusz Viste via Freedos-user]

On 02/08/2023 00:55, Jim Hall via Freedos-user wrote:

I posted a news item about it for the FreeDOS website, but I wanted to
ask before I mirrored a copy to ibiblio. Would you like me to make a
copy at the FreeDOS files archive at ibiblio?


Hi Jim, thank you for the news item.
I have absolutely nothing against mirroring things. Besides, SvarLANG is 
actually already on ibiblio in a hidden form, because it is embedded in 
the source of FDISK 1.3.8. :)


Mateusz


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

[Freedos-user] (C library) SvarLANG ver 20230730

[Mateusz Viste via Freedos-user]

Hi,

I have recently released a new version of SvarLANG. SvarLANG is a C 
library and toolset for enabling DOS applications to easily support 
multiple languages.


SvarLANG is like cats/kitten, but instead of parsing text files at 
runtime it stores them in a blob resource. It's lighter, faster and more 
space-efficient than the traditional cats/kitten. SvarLANG is part of 
the SvarDOS project, but can be used by any DOS application. It is used 
for example by the latest version of FDISK.


http://svardos.org/svarlang/

ver 20230730 changelog:

- added svarlang_autoload_exepath() and svarlang_autoload_nlspath()
- svarlang_load() simplified so it takes the target filename as an argument
- file access relies on fopen() when svarlang is compiled with -DWITHSTDIO
- new file format: sorted dictionary for faster lookup (by Bernd Boeckmann)

Mateusz


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

Re: [Freedos-user] Unicode and codepages in apps already bundled with FreeDOS?

[Mateusz Viste via Freedos-user]

On 24/06/2023 02:18, Michael Brutman via Freedos-user wrote:
A centralized mapping would be nice, but then you will run into the 
question of how strict you want the code to be.


In an ideal world, one could imagine a new nlsfunc service that answers 
with a best effort match from the local codepage for any unicode 
codepoint. I am not saying this is a good practical idea, though. Given 
the limited development nowadays, it is probably for the best that each 
application comes with its own rules and mappings.


Mateusz


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

[Freedos-user] EtherDFS ver 0.8.3

[Mateusz Viste]

Hello,

I've published a new version of EtherDFS today: version 0.8.3.
This version fixes a bug kindly reported by Jerome Shidel.

https://etherdfs.sourceforge.net

SvarDOS users can update it as follows:

 pkgnet pull etherdfs
 pkg update etherdfs.svp

Others will have to fetch the new zip file from sourceforge.

Mateusz


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

Re: [Freedos-user] Lure of the Temptress (again)

[Mateusz Viste]

On 02/04/2023 18:18, Brandon Taylor wrote:
Hello! It's me again. Over 6 years ago, I asked whether it was possible 
to get "Lure of the Temptress" running in FreeDOS (and yes, once again, 
I've played it in DOSBox). I eventually agreed to concede that it 
wasn't.


FreeDOS is very much capable of loading and executing this game.

I'm running a fork of PCem called "86Box," and have set up a FreeDOS 1.3 
environment on a virtual machine. I copied the "Lure of the Temptress" 
files to the emulated HDD image, and tried to run LURE.EXE -- only to be 
confronted with a message asking for "Disk B." Unfortunately, the 
apparent disk image files are in .VGA format, not in any format that 
86Box can recognize and mount to an emulated floppy drive.


These *.VGA files are not floppy images, but data files belonging to the 
game. If you copied only LURE.EXE to your directory, then the game fails 
to find its data files. You simply need to have all the DISK[1-4].VGA 
files present in the same directory as the LURE.EXE executable.


Mateusz


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

Re: [Freedos-user] Anyone want to write an article about FreeDOS?

[Mateusz Viste]

On 29/01/2023 22:00, Mart Zirnask wrote:

Another article worth considering is an overview of SvarDOS, or is it
not ready for this yet? A comparison of SvarDOS versus FreeDOS -- or
am I currently in the wrong church with this? :)


Sounds great. I'd definitely welcome such write-up.


An article about "Ultra minimal minimal minimal FreeDOS" (which is how
I sense SvarDOS) might be interesting to many curious (newbie-)
readers, I suppose. How to stripe FreeDOS only to the most essential
components.


Indeed. Worth noting though, that SvarDOS is not as much about striping 
FreeDOS, than about building a minimalist yet functional DOS on top of 
the FreeDOS kernel. It is also about 8086 compatibility and a more 
accommodating approach to licenses of 3rd-party packages (four freedoms 
not required).


Mateusz


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

Re: [Freedos-user] Questions about link files

[Mateusz Viste]

On 28/12/2022 16:50, M. Osman Talayman wrote:
I guess the source code for these .com link files is in the source tree. 


It is part of FDNPKG. The COM-launcher code specifically is here:

https://sourceforge.net/p/fdnpkg/code/HEAD/tree/trunk/comlink.asm

Please note that FDNPKG is abandoned and I no longer maintain it since I 
switched entirely to SvarDOS now.


Mateusz


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

Re: [Freedos-user] Questions about link files

[Mateusz Viste]

On 28/12/2022 17:21, Bret Johnson wrote:

All true, but you forgot about the most important: COM links are not
limited to 9 command line params (%1-%9). This is actually the reason
that made me design the COM links files that are used nowadays in
FreeDOS.


That's not true.  The SHIFT command in batch files allows you to access more 
than 9 parameters.


Sure, but the link files are not about running any batch logic, they are 
about executing another program feeding it with the exact same list of 
parameters that was provided by the user to the link.


Mateusz


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

Re: [Freedos-user] Questions about link files

[Mateusz Viste]

On 28/12/2022 15:21, Bret Johnson wrote:

In short, there are advantages and disadvantages to both methods.


All true, but you forgot about the most important: COM links are not 
limited to 9 command line params (%1-%9). This is actually the reason 
that made me design the COM links files that are used nowadays in FreeDOS.


Mateusz


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

[Freedos-user] New release: Gopherus 1.2.2

[Mateusz Viste]

Hello all,

I have published a new Gopherus release today.

Gopherus is a multiplatform Gopher client available for Linux, BSD, 
Windows and DOS. Changelog follows.


Gopherus v1.2.2 [12 Nov 2022]:
 - [new] F4 key loads the main menu of the current server
 - [new] key bindings can be reconfigured through a configuration file
 - [new] 0-byte answers are interpreted as a "selector does not exist" 
error

 - [fix] fixed a minor buffer overflow
 - [mnt] optimizations to decrease memory footprint
 - [mnt] Windows version is cross-compiled with mingw64 and requires x86_64
 - [mnt] DOS version: supports pages up to 65000 bytes long (was: 32000 
bytes)
 - [mnt] DOS version: increased max amount of lines in a menu from 128 
to 512

 - [mnt] dropped support for the DOS 32-bit (DJGPP) version
 - [mnt] dropped the SDL2 target

Links:

http://gopherus.sourceforge.net
gopher://gopher.viste.fr/1/projects/gopherus


Mateusz


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

Re: [Freedos-user] i made fdpget.bat for downloading and installing freedos packages

[Mateusz Viste]

On 05/08/2022 13:43, sparky4 insano wrote:
i made a badly written batch file that downloads and install freedos 
packages for 16 bit machines using mTCP htget and fdinst
link is here https://4ch.mooo.com/fdos/fdpget.bat 


http works too


If you're focused on 16-bit machines, then you might want to check out 
pkg & pkgnet: http://svardos.org/phpamb.php?fname=help/help-en=pkg.ama


I created these tools specifically as an 8086-compatible improvement 
over fdnpkg.


Mateusz


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

Re: [Freedos-user] Creating a minimal freeDOS bootable image that runs a single application

[Mateusz Viste]

On 10/07/2022 23:46, Nico via Freedos-user wrote:
I would like to create a minimal bootable image for a USB drive (or 
other formats, maybe even floppies, but USB is the focus) that boots 
into a single application (in my case, a custom minimal word processor, 
although freeDOS EDIT is a decent start for what I want) to create a 
kind of "typewriter on a USB drive", that will work on any hardware you 
throw it at and provide an environment for writing in.


FreeDOS won't work on non-BIOS machines. Also, the ability to 
write-access the USB drive after boot is not guaranteed, depending on 
the exact BIOS implementation.


Since you say the target is to use "any hardware", I assume you have 
mostly current hardware in mind. Hence no, FreeDOS is probably not a 
very good choice in my opinion.


You mention that you plan to write the application yourself, and that 
you'd like it to boot as fast as possible. With such constraints, 
programming an UEFI (EFI PE) application might perhaps be a good (and 
challenging) choice.


Mateusz


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

Re: [Freedos-user] ECHO vs @ECHO

[Mateusz Viste]

On 26/02/2022 15:09, Travis Siegel wrote:
Barring those solutions, you could always redirect the @echo off line to 
null, which would prevent it from displaying on the screen.


It would not, since the error message is output to stderr.

Mateusz


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

Re: [Freedos-user] DOSHEXED - memory bug

[Mateusz Viste]

On 12/01/2022 18:22, tom ehlert wrote:

You might want to try uHex. Requires some 20 KiB of RAM and handles
files up to 2 GiB.


use int 21, 6C EXTENDED OPEN/CREATE and you can handle 4GiB.


This does not appear to be present in the FreeDOS kernel. Or at least 
the source code comment says "not implemented yet" (and the O_LARGEFILE 
flag does not appear to be used anywhere later in the code):


https://github.com/FDOS/kernel/blob/master/kernel/dosfns.c#L498

Do you have a FreeDOS kernel version that supports this?

Mateusz


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

Re: [Freedos-user] DOSHEXED - memory bug

[Mateusz Viste]

On 12/01/2022 18:22, tom ehlert wrote:

You might want to try uHex. Requires some 20 KiB of RAM and handles
files up to 2 GiB.


use int 21, 6C EXTENDED OPEN/CREATE and you can handle 4GiB.


Sure, but that's not very portable code. And it is not enough anyway. To 
handle 4 GB one would also need to:

 - replace all 'long' position tracking variables by unsigned long
 - handle errors in a different way (than passing -1)
 - use a non-portable construct to replace fseek()
 - and probably more that I don't think about right away

Mateusz


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

Re: [Freedos-user] DOSHEXED - memory bug

[Mateusz Viste]

On 12/01/2022 14:58, Michał Dec wrote:

Is there any other hex editor for FreeDOS


You might want to try uHex. Requires some 20 KiB of RAM and handles 
files up to 2 GiB.


IIRC it is shipped with FreeDOS, but if not then you will find it here: 
http://uhex.sourceforge.net/


Mateusz


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

Re: [Freedos-user] Speaking of (tiny) DOS gaming PCs

[Mateusz Viste]

On 28 November 2021 21:31:34 CET, dmccunney  wrote:
>This also looks like it will be useful to Old Skool folks who want to
>boot DOS and run it directly on the bare metal, instead of in an
>emulator or VM.

In this context, I am very much impressed by the micro 8088, a minimalist 
homebrew PC XT clone by Sergey Kiselev:
https://github.com/skiselev/micro_8088

It uses a true 8088 CPU and not a SOC like the Vortex. Sadly, I couldn't find 
any place where I could buy one, it is rather targeted to people wanting to 
assemble it themselves.

Mateusz


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

Re: [Freedos-user] Enhanced Hangman EN_COMPS.VOC

[Mateusz Viste]

Howdy Bryan,

Very cool, thanks. I'm surprised people still play this game!

I have uploaded your files as "extras" on the game's website:
http://hangman-dos.sourceforge.net/

It seems your set does not contain the original words, is it on purpose?

Do not hesitate to send me any other resources directly if you'd like. I 
doubt this stuff is of much interest to the readers of this list. :)


Mateusz


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

Re: [Freedos-user] Announcements seen on BTTR: Lynx web browser, NDN file manager, DOSBOX emulator

[Mateusz Viste]

On 25/11/2021 19:31, Rugxulo wrote:

In case you haven't noticed, FTP is much simpler to implement than
Curl or Wget. Those are incredibly complex, especially for DOS.


FTP is actually more complex than HTTP. Curl and Wget are obviously huge 
programs, but that's because they do a lot of things beside just 
downloading a resource over HTTP.



Long story short: if I ever make an update (unlikely), I'll probably
include CURLLITE.EXE (386 DPMI) by default.


For *simple* HTTP jobs you might also use Gopherus (8086-compatible), 
since it embeds a tiny http-downloader.


Mateusz


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

Re: [Freedos-user] SvarCOM - a nimble COMMAND.COM shell

[Mateusz Viste]

On 25/11/2021 14:22, Jerome Shidel wrote:
Kinda busy right now, don’t know when I’ll get around to testing it. 


No worries. If you're happy with FreeCOM, no need to look after 
something else.



But, I did turn it into a package already. :-)


Cool, thanks!

Mateusz


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

[Freedos-user] SvarCOM - a nimble COMMAND.COM shell

[Mateusz Viste]

Hello all,

I tend to use FreeDOS mostly on old computers that often have no more 
than 1 MiB of RAM. On such setups FreeDOS doesn't leave much memory to 
applications, mostly due to FreeCOM.


This is the main reason that led me to develop a new command interpreter 
named SvarCOM. This interpreter will soon become the standard shell of 
the SvarDOS distribution. It's resident size is under 2K.


Today I published the first version of SvarCOM, version 2021.0. This 
version must be considered as a "functional preview", since there are 
still a few things missing. It is stable, though, and what is 
implemented works pretty well. I use it since a few days on my 
museum-grade machines without major troubles. The most annoying thing is 
probably the lack of an INT 24h handler: it may lead to surprising 
results if one tries to access an empty floppy drive.


While I developed SvarCOM specifically for the SvarDOS distribution, it 
works just as well on plain FreeDOS. As such, the FreeDOS project is 
welcome to mirror it or use it as an alternative shell, should that be 
of any interest to the community.


Read more on http://svardos.osdn.io/svarcom/

Mateusz


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

Re: [Freedos-user] FreeDOS game compatibility mass testing results/questions

[Mateusz Viste]

On 20/11/2021 18:25, Jim Hall wrote:
That's not to say that FreeDOS is perfect. For the life of me, I cannot 
get the Wolfenstein 3D installer (1wolf14.zip) to run on FreeDOS. Even 
with nothing loaded, INSTALL.EXE aborts with "Runtime error 200 at 
0774:0091"


Does not sound like a FreeDOS problem, but rather a variation of the CRT 
"CPU too fast" bug, where a division by 0 occurs because the CPU is so 
fast it executed all timing loops without any noticeable time passing.


Have you tried slowing down your PC? There is a lot of tools that can 
help with that. Sometimes the binary can be also patched (the TPP patch 
worked for me on the Jazz Jackrabbit game eons ago).


http://www.bttr-software.de/freesoft/system.htm#oldprogs

Mateusz


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

Re: [Freedos-user] MKEYB related stuff

[Mateusz Viste]

On 13/10/2021 21:41, E. Auer wrote:

I would not call KSSF experimental, I would
just call it rarely used, because most users
do have XMS drivers loaded :-)


The kswap documentation starts with exactly these words:
"This technique is an experimental implementation (...)"

Then, the documentation proceeds to list all the limitations of this 
(clever, but still) hack.



Also, to get back to MKEYB: It is tiny both
in RAM and on disk and the lack of support
for automated codepage magic is perfectly
okay for me.


Absolutely. That is, in fact, exactly what I was saying earlier. Choice 
is good, and having a tiny/limited keyboard driver available is 
definitely cool.


Mateusz


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

Re: [Freedos-user] MKEYB related stuff

[Mateusz Viste]

On 13/10/2021 11:49, tom ehlert wrote:

I'm 100% certain that MSDOS didn't generate € characters in any
codepage. this should end the story of €'s.


As explained by others numerous times, the display-talks-to-keyb 
mechanism is much wider than the one euro symbol.



1'st: 'problems' is the plural of problem. 1 person running a single
museum 256K computer and insisting on using a 21'st century OS is
still just 1 problem.


I must admit that referring to FreeDOS as a "21st century OS" is a 
hilarious joke. Well played, sir.



2'nd: your machine is perfectly fine with the software that it came
with: MSDOS 1.0 or maybe 2.x


MSDOS 3.3, to be precise. And yes, it works very well with MSDOS 3.3 and 
all newest versions as well. Following your line of thought, nobody 
should install FreeDOS, because it did not came with their machine 
originally.



3'd: use the non-XMS-SWAP version of FreeCOM. it does exist, and is
supposed to swap to/from disk (I never tried). case dismissed.


This is an experimental and very limited feature. The xms-swap kludge is 
a workaround, not an improvement. One could say that FreeDOS' kswap is 
to MSDOS swapping what mkeyb is to a proper keyboard driver.


I am not complaining of course - I am only demonstrating how subjective 
"real issues" can be.


Mateusz


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

Re: [Freedos-user] MKEYB related stuff

[Mateusz Viste]

On 12/10/2021 22:49, E. Auer wrote:

So at the risk of repeating the obvious: While it is possible to
construct some problems to justify your desired powerful solution,
this feels extremely over-designed from my view as Non-US DOS user.


As far as I understand, this is not about designing some new solution to 
a possibly rare situation. This is about mimicking what MS did already 
40 years ago... Isn't that the primary objective of FreeDOS?



If you want to address a REAL problem in FreeDOS


I do not think that anyone wants to address any problems in this 
discussion. The whole thing started merely as an explanation why MKEYB 
is not a fit replacement for FD-KEYB. While it may be a nice, tiny tool 
that covers 90+% of cases, it simply lacks more advanced features 
(dynamic codepage-mapping logic). And that's fine, choice is good.


Now, about "real" problems: it's highly subjective. You may find the 
2GB-limit thing to be a problem - I don't. I'd say that if there's is 
one problem with FreeDOS to pick up, it is COMMAND.COM's memory 
footprint: it is *huge*. On my current setup, COMMAND.COM takes up 76K 
of RAM. That's 30% of the total memory on this machine... MS-DOS has the 
ability to swap out COMMAND.COM at runtime, so it takes roughly 5K (as 
per MEM/C output).


Mateusz


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

Re: [Freedos-user] MKEYB related stuff

[Mateusz Viste]

On 08/10/2021 12:17, tom ehlert wrote:

it's not uncommon  for germans to use US-ASCII keyboards (QWERTY).
other use german keyboards (QWERTZ).

in both cases the codepage is 437 (BIOS default) or 858 (with €), but
Y and Z are swapped.

the same is probably true for french keyboards.


French people use only AZERTY keyboards, although IIRC Canadians in 
Quebec do have some weird QWERTY variation.


That being said, the "one nation uses two keyboards" situation is true 
in Poland. There, we use either the "Polish/Programmer" layout, which is 
in fact an US keyboard with Polish keys available under ALT+something 
(eg. ALT+x produces "ź"), or the "Polish/Typist" keyboard, that is a 
copy of the keyboard layout used on post-WWII typewriters, with Polish 
characters available without ALT combos.


Mateusz


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

Re: [Freedos-user] MKEYB related stuff

[Mateusz Viste]

On 07/10/2021 18:47, tom ehlert wrote:

were these 2 layouts dynamically switchable (and actually
switched)


They were actually not switchable, mainly due to their implementation: 
CP852 was provided by "mode con cp" through MS-DOS, while the Mazovia 
codepage was usually loaded through a custom TSR (maz.exe comes to 
mind). Hence "switching" required to unload maz.exe and run the 
appropriate mode con cp prepare/select combo. And that's what I was 
doing whenever I needed to use a program that was assuming CP852.


But now, since Mazovia and CP852 are both supported by FreeDOS, they can 
be easily switched without relying on any exotic TSRs.


The full story is that when the IBM PC came to Poland, it wasn't 
handling Polish glyphs at all, so Poles had to come up with their own 
codepage when creating their IBM PC clone (Mazovia 1016). It was first 
burned in custom ROMs, and later - with VGA cards - loaded to the VGA 
memory through TSRs.
Then, later, Microsoft/IBM decided to support Polish, and did so by 
cramming most of east-European glyphs into CP852... Which not only led 
to a poorly usable codepage (garbled Norton Commander semigraphics!), 
but also introduced chaos in the way Poles were exchanging text. Some 
started using the Microsoft 852 page, since it was meant to be the "new 
standard", and others kept using Mazovia since it was superior and 
well-established... Ah, those good times.


Mateusz


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

Re: [Freedos-user] MKEYB related stuff

[Mateusz Viste]

On 07/10/2021 15:43, tom ehlert wrote:

DISPLAY.SYS calls INT 2F.AD81h when the Code Page is changed to
inform KEYB so it can change its mapping.

please provide an example where this is necessary AND plausible.


In Poland, there were a few codepages used during the DOS era. The two 
main ones were CP911 ("Mazovia") and CP852. The character mappings are 
different, for instance "ą" (ALT+a) is byte 0xA5 in CP852, while in 
Mazovia it is under 0x86. Most polish programs could be configured to 
output their content in one of the codepages, but some were hard-coded 
to either Mazovia or CP852. In such cases, a mode con cp select was 
required -- in such case, a non-smart keyb driver would not be aware of 
the change and keep emitting byte codes for the initial codepage it was 
configured for.


Mateusz


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

Re: [Freedos-user] Standy in FreeDos?

[Mateusz Viste]

On 29/09/2021 14:06, Thomas Desi wrote:

Hi, is it possible (application? program) to put the computer to „sleep“ (i.e. 
„standby) in FreeDos?


"fdapm standby"

http://amb.osdn.io/phpamb.php?fname=lib/fdhelpen.amb=fdapm.ama

Mateusz


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

Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]

[Mateusz Viste]

On 01/06/2021 23:55, Lukas Satin wrote:
The driver VIDECDD is not working at all. It will not find my CD-ROM 
drive. Perhaps because 486 bios cannot find the CDROM. But driver such 
as MSCDEX or SHSUCDX will find the drive.


Hi Lukas, MSCDEX/SHSUCDX are not really drivers, they are only a 
subsystem that talks to the actual driver and presents a "network-like" 
filesystem to the DOS kernel. Back in the day, each CDROM drive came 
with a floppy that contained a DOS driver. This DOS driver had to be 
loaded (via config.sys), and only then MSCDEX (or SHSUCDX) could find 
it. I think you said earlier that your setup works fine with MSDOS - 
then perhaps you could use the same driver on FreeDOS, instead of the 
universal UDVD? MS-DOS does not come with a CDROM driver at all, so I do 
not know where you obtained your driver from.


As for EMM386/JEMM386 - simply do not use it. It is always cleaner to 
run in real mode anyway. The only difference is that you won't be able 
to run games that require EMS memory, but I am not sure there are really 
many games that require EMS memory, usually games are able to use either 
EMS or XMS, depending on what's available.


Finally, if you look for a more basic FreeDOS system, you might want to 
test SvarDOS. It is a FreeDOS distribution that aims for minimalism and 
8086 compatibility, I'd be curious to know how it runs on your 
"difficult" setup.


Mateusz


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

Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review

[Mateusz Viste]

On 30/04/2021 02:19, Jon Brase wrote:
I'm not particularly attached to any particular GUI, or to having a GUI 
in FreeDOS per-se, but I'm a bit concerned, in terms of preserving 
historical software, that the Win16 API is not well served by existing 
options (Wine, NTVDM, MS-DOS/Win3 under virtualization, Win3 under 
DOSBox, etc), compared to the resources that are available for DOS, so 
I'd really like to see something I'll call "Free-point-one", a FOSS 
implementation of Win16 built on FreeDOS.


Isn't this possible already using the HX extender? It focuses mostly on 
running Win32 application from within DOS, but IIRC it also comes with 
some Win16 support.


Mateusz


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

Re: [Freedos-user] hardware recommendations

[Mateusz Viste]

On 27/04/2021 18:00, Michał Dec wrote:
Hey I was wondering if it would make sense to step up FreeDOS to 
actually you know, be bootable under UEFI ;) The CPUs still got support 
for real mode so we should be fine.


Being able to boot is only the tip of the iceberg here. Without a 
working BIOS (ie. working INT 13h, INT 10h etc interfaces) neither DOS 
nor most DOS application will be able to function.


A functional solution would be to provide something that emulates a BIOS 
(video, storage, memory areas...) over UEFI. But at this point one could 
just as well run FreeDOS into an emulator.


Mateusz


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

Re: [Freedos-user] hardware recommendations

[Mateusz Viste]

On 27/04/2021 15:43, Liam Proven wrote:

UEFI vs BIOS is either-or. A single machine can't have both, and I do
not know of any where it is a choice. It is a design decision.


On my Thinkpads the BIOS allows to choose the boot method - either UEFI 
or "legacy". The latter allows to boot DOS, the former doesn't.


Mateusz


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

Re: [Freedos-user] Printing over the network

[Mateusz Viste]

On 21/04/2021 06:06, Michael Brutman wrote:
If you have a printer that is network enabled and it speaks Postscript, 
PCL, Epson ESC P2, or plain text then you can "print to a file" under 
DOS and then use Netcat to send the file to your printer.


+1. I used such method in the past, although I used jd.exe 
(wattcp-based) in lieu of netcat. I described the exact method on this 
list 14 years ago:


https://www.mail-archive.com/freedos-user@lists.sourceforge.net/msg06342.html

Mateusz


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

Re: [Freedos-user] Why do you use DOS

[Mateusz Viste]

On 16/04/2021 13:15, Thomas Desi wrote:
this one= 66297 2009-09-11 18:42:08 fdapm-2009sep11.zip 
 on 
https://www.auersoft.eu/soft/ 


Yes.

I read the fdapm.txt and notes but can’t figure out: does it go into 
CONFIG.SYS or AUTOEXEC ?


It is a TSR, not a driver - hence you can set it through autoexec.bat, 
or even run by hand from the command line.


Mateusz


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

Re: [Freedos-user] Why do you use DOS

[Mateusz Viste]

On 16/04/2021 12:53, Thomas Desi wrote:

Is there somebody who happens to know about the functionality (usability/) 
regarding DOSidle + FreeDos? Should I Autoexec.bat


FreeDOS comes with FDAPM, which provides a similar functionality (among 
other interesting features). There is also an IDLEHALT kernel 
configuration (to be set through CONFIG.SYS) that enables a subset of 
what FDAPM is capable of, for those who do not wish to use a powersaving 
TSR.


Mateusz


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

Re: [Freedos-user] Using a USB stick and an optical drive

[Mateusz Viste]

On 10/04/2021 14:26, Stephanos wrote:

I booted the stick, was a bit confused as to why freedos did not do
anything and fdos was the option, and found the BIOS file in drive C:\.
  I ran it.  It looked promising, but alas, alack, no.
-Start to flash ……. [ Y / N]: Y
- Error: Problem getting flash information
C:\>
The method is good. Now you need to figure out why the tool is unable to 
communicate with your BIOS chip. Perhaps the EXE tool is not compatible 
with your specific motherboard revision? Or there is some kind of "BIOS 
protection" (or "CMOS antivirus") enabled in the BIOS? I can only guess.



Making the USB stick bootable and being able to add files to it was so
easy.  It is as though the root of the memory stick was C:\?


The USB stick being C: is normal and expected, your BIOS emulates a 
normal hard disk and exposes that to DOS, doing the USB<->HDD interface 
translation on the fly.


Mateusz


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

Re: [Freedos-user] Using a USB stick and an optical drive

[Mateusz Viste]

On 09/04/2021 23:50, Stephanos wrote:

So I decided that it was slightly easier to put back Windows 7.
I used gparted to wipe the HDD (...)
I booted into the BIOS and the version was the same A02.
I rebooted back into Windows 7


You should have done like Liam tells you from the beginning. He provides 
correct, detailed and verified steps. The operation is as simple as 
booting DOS from a removable drive (CD/floppy/USB) to run a single 
executable... Any other method is likely to either not work or damage 
your PC (esp. if you follow what Michael C. Robinson has been 
suggesting). Using Windows to update a BIOS firmware looks perhaps like 
an easy way out, but I wouldn't risk my PC with it myself, even if it's 
one of the methods suggested by the motherboard producer.


Mateusz


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

Re: [Freedos-user] New AMB based FreeDOS Help

[Mateusz Viste]

I am sorry that this has been probably mentioned in the past, but, how 
does one get from HTML files to AMB?


I did the conversion using a tool that I created for this specific task. 
It is non-generic, messy and very ugly - its only goal was to make it 
possible to convert the FreeDOS help HTML files to AMB. The converter is 
here (but again - useless for anything else than converting existing 
FreeDOS help to AMB):

https://osdn.net/projects/amb/scm/svn/tree/head/samples/fdhelp2amb/


Or does AMB have a format that does not originate on an HTML file?


AMB is a container (like tar) that holds files in the *.AMA format 
(Ancient Machine Article). The AMA format is described at the link below 
- it is a very simple text-like format that allows hyperlinked content.

http://amb.osdn.io/phpamb.php?fname=archiwum/format-20201216.amb=ama.ama

Mateusz






On Mon, 22 Feb 2021 at 22:44, Jerome Shidel > wrote:




> On Feb 22, 2021, at 4:40 PM, Jerome Shidel 
wrote:
> The amp based …

The AMB based …

(I just love spell correction)

:-)

___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/freedos-user





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




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

[Freedos-user] SvarDOS (FreeDOS distribution)

[Mateusz Viste]

Hello, this quick message to announce that I decided to halt the 
Svarog386 distribution. Its successor is SvarDOS: http://svardos.osdn.io


SvarDOS is based on the same concepts as Svarog386, but is meant to be 
more universal, ie. including 8086 systems. Existing Svarog386 
installations can be easily "migrated".


Mateusz


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

Re: [Freedos-user] Which C compiler for targeting DOS?

[Mateusz Viste]

On 24/01/2021 08:54, Adam Nielsen via Freedos-user wrote:

Hi all,

Can anyone recommend a good C compiler for DOS?


Turbo C 2.01 (gratis, very good software) and OpenWatcom (open-source, 
tend to produce heavier binaries than OW, but comes with a more complete 
libc).



  * I would like to be able to cross-compile from a Linux machine, but
without having to install a complex cross-compilation environment -
meaning the two options I can think of are running a Linux platform
cross-compiler from within a Docker container, or running a native
DOS compiler from within a virtual environment like QEMU.


Use DOSEMU. You get a little "DOS in a window" that sees your native 
Linux files. No need to copy source files back and forth - write them 
with your usual Linux IDE/notepad, compile and test in the DOSEMU window.



Do they all target protected mode architectures
now or do they still support 8086-compatible real mode?


Both TC and OW produce 8086 code (OW needs the extra -0 argument for that).

Mateusz


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

Re: [Freedos-user] (no subject)

[Mateusz Viste]

Note that running a laptop with no battery is not necessarily a good 
idea - some laptops rely on the battery to act as a voltage regulator. 
Running a laptop without its aku pack is how I fried a RAM bank in my 
Toshiba T1100 a couple of years ago. I realized too late that the power 
supply was delivering a much higher voltage than what the laptop 
expected, and needed to be brought down by the battery not to damage 
anything. More recent constructions are probably sturdier, but one 
should be careful nonetheless.


Mateusz



On 09/01/2021 08:46, Šimon Dobeš wrote:

OK
I will try to explain more properly. I plugged in my Laptop. Pushed down 
the power button and nothing happened. I cleaned up and I did not found 
anything leaked or broken. I think there is a problem with power supply 
or some circuits. I will keep finding. I have also a battery pack for 
that Laptop too but I am not using since those batteries are way old to 
handle all operations and may explode.

Simon

-- Pôvodná správa --
Od: "Ralf Quint" 
Komu: freedos-user@lists.sourceforge.net
Odoslané: 9. 1. 2021 4:10:02
Predmet: Re: [Freedos-user] (no subject)


On 1/8/2021 8:28 AM, Šimon Dobeš wrote:

Hello
I want to ask if FREEDOS will run on Intel Pentium old-school PC from 
2002 and if it will work properly if this pc have 256 mb of ram.
I have a old IBM ThinkPad from 1998 and it is great computer. But it 
is not working. Where I can fix it?


Well, as others already mentioned, there is no reason why FreeDOS 
would NOT run on such a PC. More RAM that you would probably need, but 
not a problem either.


What however is a problem here is that "it is not working" is not a 
proper problem description. You need to be far more 
precise/descriptive of what exactly you are trying to do and what the 
results are. We can not look over your shoulder, and there simply is 
not enough information to even make an educated guess...


Ralf



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



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




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



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

Re: [Freedos-user] AMB update

[Mateusz Viste]

On 23/12/2020 16:38, Mateusz Viste wrote:

The AMB reader is available for download on the AMB project's webpage:
http://amb.osdn.net


And of course I mistyped the URL... Should have been:
http://amb.osdn.io

Mateusz


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

[Freedos-user] AMB update

[Mateusz Viste]

Today I published a new version of the AMB book reader. There has been a 
lot of improvements since my last announcement here. Changelog follows.


 - jump to a specific chapter when specified as command line argument
 - mouse support
 - optimized display routines (refresh only lines that may have changed)
 - optimized next-link-lookup (tab) so it is fast even on a 4 MHz machine
 - optimized memory usage
 - reloading same page does not insert a new history position
 - ported to the Windows platform (compiled with Mingw)
 - unicode output (on platforms that support it)
 - support for "notice" AMA tags (%!)
 - tab key jumps to next link
 - monochrome scheme is used on colorless terminals

The AMB reader is available for download on the AMB project's webpage:
http://amb.osdn.net

Mateusz


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

Re: [Freedos-user] IDE <-> CF adapters

[Mateusz Viste]

On 22/12/2020 14:37, DosWorld via Freedos-user wrote:

2. Use last generation of motherboard for Pentium-1 (as minimum) with VIA 
Apollo chipset (designed for Pentium and Amd K6/K6-2) - only this chipset 
understand ATA100 native and allow connect CF via simple IDE-CF reductor


I have a 486 Toshiba laptop and a 286 desktop. Both use CF cards as 
their only storage, connected through cheap mechanical CF<->IDE 
adapters. It works perfectly.


Mateusz


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

Re: [Freedos-user] Package discussion

[Mateusz Viste]

On December 18, 2020 9:01:09 PM GMT+01:00, Ray Davison  
wrote:
> In my scheme the system would only have two ISOs: the basic,
>and 
>a TBD "extras". 

Myself I do not have a very fast internet connectivity. When I download DOS, I 
prefer to download the strict minimum (MSDOS equivalent, ca 5MiB) and then 
fetch the 2 or 3 extra things I like through FDNPKG (without sources).

Mateusz


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

Re: [Freedos-user] AMB, Ancient Machine Book format and FreeDOS Help

[Mateusz Viste]

On 16/12/2020 12:39, C. Masloch wrote:
Very nice! I'd guess it may be the path of least resistance to add an 
AMB output format to the existing Halibut compiler.


That would be awesome, yes -- but I looked at the source code and it 
wasn't looking like a 5-minutes job, so I decided to go for the poor 
man's solution of improving your txt version with AMB tags.


I have added the NASM book to the AMB "library", below (I hope you don't 
mind):

http://amb.osdn.io/library.php


By the way, I am not a Christian. The C. does not stand for that.


Oh, I'm sorry - I was certain I had seen a Christian Masloch on the list 
at some point, but surely I am confusing with someone else then.


Mateusz


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

Re: [Freedos-user] AMB, Ancient Machine Book format and FreeDOS Help

[Mateusz Viste]

On December 15, 2020 6:45:46 PM GMT+01:00, ZB  wrote:
>There's no need to wait for "8086 code" - if you're interested I can
>show
>you example of TCL/Tk solution. Of course similar way it'll work in DOS

Doing things on modern platforms with lots of RAM and 32bit ints is easy. Doing 
the same with a 8086, fitting in kilobytes of RAM and providing a reasonably 
fast UI is entirely another story.

> (as Lynx does with HTML, for example).

Lynx is cool, but it is neither lightweight nor 8086 compatible.

>Actually that lightweight application could recognize \ as well as
>it presently recognizes "%h" - and then it could show that heading,
>say,
>centered and using "bold" attribute, right?

And the html should be preformatted for 80-columns displays. And it would have 
to be encoded in a code page that browsers do not understand. And the reader 
would need to handle a variety of html thingies likeetc.

>All the other HTML tags can be simply ignored (not interpreted and of
>course
>not displayed), so help files could remain HTML, maybe just being
>prepared
>most simplistic way - while still being HTML, therefore
>any-browser-compatible.

You just described how the FreeDOS help.exe works.

Mateusz


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

Re: [Freedos-user] AMB, Ancient Machine Book format and FreeDOS Help

[Mateusz Viste]

On 14/12/2020 19:08, ZB wrote:

Guys, I have no issues with AMB neither any other new invention - but...
maybe simpler solution would be to copy solution offered by Tk's "text
widget"? The "side advantage" would be ability to browse the texts prepared
such way under every OS where Tk toolkit is available.


That may be a good idea. Would you mind preparing an 8086-compatible 
prototype so we can compare both options side by side? It's always nice 
to have choice.



...which will become "hyperlink", that after being clicked will move you
to a later section of the same file having the header like this:

  5. Settings / preferences

 means "link"
 means "bold>

This is already done and easy to copy


Indeed easy. I'm very interested to see what you can come up with.

On a semi-related note, following "DosWorld's" questions I have added a 
rationale section in the AMB format spec file, so the thought process 
behind each element of the format is clearer. I have also converted the 
format spec itself to an AMB book (a txt version is available as well). 
The AMB version can be read online here:


http://amb.osdn.io/phpamb.php?fname=archiwum/format-20201215.amb

Mateusz


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

Re: [Freedos-user] AMB, Ancient Machine Book format and FreeDOS Help

[Mateusz Viste]

After some quick investigations, I found that the text version of insref 
is almost AMB-ready, it only needed to have a TOC generated.
I wrote a script that splits insref into multiple "chapters" using the 
Linux csplit command and then auto-generated a TOC from there. It is not 
perfect, because the files sometimes have mentions "See chapter xyz for 
abc", and these are not linkified, but it's as good as I can get it to 
be without spending too much time on it.


This is how it looks like:
http://mateusz.viste.fr/tmp/amb/phpamb.php?fname=insref.amb

The AMB file itself can be downloaded here:
http://mateusz.viste.fr/tmp/amb/insref.amb

And the script I created for the occasion is here:
https://sourceforge.net/p/ambook/code/HEAD/tree/nasmref2amb/convert.sh

Mateusz




On 14/12/2020 07:36, Mateusz Viste wrote:

Hi Christian,

Your docs seem very interesting! I didn't know about them. Having them 
available as AMB books would definitely be very cool.
I am not very fond of HTML as a source-to-be-processed data, but the halibut 
thing appears very promising. I will see how hard it would be to create a 
halibut2amb converter.

Mateusz




On December 13, 2020 9:27:06 PM GMT+01:00, "C. Masloch"  
wrote:

On at 2020-12-13 09:15 +0100, Mateusz Viste wrote:

I'd love to have the FreeDOS books in there, too.
https://www.freedos.org/books/
I don't think I have the free time to convert them, but if I sent

you

the ODT files, could you convert


Sure, if the books are terminal-friendly (ie. no illustrations or
illustrations can be removed easily).


Hi,

I wonder whether you could convert my documentation to AMB format too?
Most of it is found at [1] -- each HTML file contains a link to the
corresponding hg repository near the end, which has the source. Such as

[2].The source format is that accepted by the Halibut documentation
preparation system [3]. Perhaps you can convert from either the HTML
output or the Halibut sources to AMB?

Regards,
ecm

[1]: https://ulukai.org/ecm/doc/
[2]: https://hg.ulukai.org/ecm/insref/
[3]: https://www.chiark.greenend.org.uk/~sgtatham/halibut/


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



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




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

Re: [Freedos-user] Package discussion

[Mateusz Viste]

On 14/12/2020 01:22, ZB wrote:

I think before taking such decision it would be worthy to browse the list
again, but after doing "sort by size desc" first. Because the bigger the
file the more closely it's worthy to look at it


This leads to a situations where software is becoming less likely to be 
included when its sources are big -- even though the software itself 
(once compiled) might be tiny. The sane thing to do in my opinion (which 
I do since many years in Svarog386) is to drop sources from packages, 
and make them available through in different way (separate CD, DVD or 
online).


The Svarog386 CD is 300 MiB, but when sources are included it grows to 
470 MiB. If it reaches 700 MiB one day I will turn it into a DVD.


Mateusz


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

Re: [Freedos-user] Package discussion

[Mateusz Viste]

>Gopherus,
>> but it's "retro" and not too big (2MB) so I have no problems keeping
>it.
>
>That is larger than expected - make Gopherus EXTRA / ONLINE?

The (old, 1.1) 32 bit version was about 400 KiB, zipped. The newer (1.2+) 16 
bit version is under 100 KiB zipped.

Mateusz






On December 14, 2020 1:56:40 AM GMT+01:00, Eric Auer  wrote:
>
>Hi Jim,
>
>> Let me know your thoughts!
>
>Sure!
>
>> And a reminder that "To drop" only means "not included in the FreeDOS
>> distribution." We will still have them available in the FreeDOS
>archive
>
>My impression is that there would be FULL and EXTRA sized ISOs,
>with "only online / on ibiblio" as being the third level of
>escalation. And my general tendency is to have many smaller
>packages at least in EXTRA, maybe even in FULL and the live
>CD, so 1. we can show off our versatile app collection and
>2. people can use a lot of stuff without having to download
>things, in particular given DOS not being very online as OS.
>
>Although the virtual meeting also had good news about a new
>curated set of network drivers to be published, thanks O.Y.!
>
>
>> *Base:*
>> Keep everything, except the outdated sample config package.
>
>Ask for volunteers for an updated sample config? Otherwise: Cool.
>
>> *Archivers:*
>> Keep everything, except the packages as indicated in the wiki that
>are not
>> open source. Include everything in the "Live" CD. But only install
>zip &
>> unzip with the "Base" and "Full" distribution (the others should go
>in
>> "Extras" so they are not installed by default)
>
>I vote to also include full 7ZIP, plus *possibly* tar and lha, because
>users may enjoy a real tar? NOT if tar needs external gzip/bzip2. The
>reason to include LHA is being able to unpack LHA and LZH files, which
>were quite popular once. Note that 7zip can handle ZIP, CAB and maybe
>RAR (does the DOS version also do the last two?) as well as GZIP, BZIP2
>and TAR as well as combinations thereof and various additional funky
>formats (LZMA2, XZ, ARJ, CPIO, RPM, DEB, ISO and filesystem images).
>
>If the DOS 7ZIP does not support CAB, I also vote to include CABEXT
>(like 7ZIP both for the live CD and FULL) because it allows unpacking
>some files in certain cases when DOS drivers / apps are shipped as a
>"side-effect" of some windows software with windows based installers.
>
>> *to keep [only in "Extras"]:* 7zdec arj bz2 cabext gzip lpq1 lzip
>> lzma lzop p7zip tar zoo
>> 
>> *to drop:* lha unrar
>
>> *Boot Tools:*
>> These are small, but "ROM" boot utilities are not generally useful.
>
>I agree, but I would not drop syslinux. With memdisk, this class of
>boot utilities has helped to make bootable DOS media in various cases.
>
>> *Development:*
>
>It is impressive how un-DOS-like the sizes of certain compilers and
>interpreters are now :-p And of course, some languages are exotic.
>
>I would strip DJGPP-on-ISO to the minimal C, maybe C++ infrastructure
>(not sure what BN, BS, DB, FQ, FX, GC, GP, MK, OB, RH, TX are, would
>be nice to have long package names at least in the websites). So no
>RHIDE and no Objective C and similar in FULL, move those to ONLINE
>or at least EXTRA? Similarily, a less bloated IA16 C subset please.
>
>While I dislike the size, I agree that FreeBASIC and FreePascal are
>appropriate to keep. Not completely sure about the (outdated?) Perl.
>
>> *to keep:* bwbasic cpp2ccmt DJGPP (*djgpp djgpp_bn djgpp_bs djgpp_db
>> djgpp_fq djgpp_fx djgpp_gc djgpp_gp djgpp_mk djgpp_ob djgpp_rh
>djgpp_tx*)
>> fasm FreeBASIC (*fbc fbc_help*) fpc IA16GCC (*gcc-ia16 i16budoc
>i16butil
>> i16gcc i16gcdoc i16newli i16src*) *insight* jwasm nasm ow perl regina
>> *runtime* upx
>> 
>> *to drop:* bcc euphoria lua msa suppls tinyasm tppatch
>
>TPPATCH is both small and really useful (runtime error fixer for
>Borland compiled binaries which crash on too fast CPU, I believe?)
>and LUA and TINYASM also seem to have favorable size/use ratios.
>
>For SUPPL, I suggest to ship FreeCOM sources bundled with SUPPL,
>if that is not already happening anyway. What else would use it?
>
>> *additional questions: Is the Insight debugger still used/useful?
>
>Not sure, I positively remember the 386SWAT debugger and DPMIONE
>in any case! Those should be included. Insight sounded nice, too,
>but I have not really used it yet.
>
>> The 'Development' group is very big; should
>> these be installed during a "Full" install?
>
>Good question. It should be part of SOME of the ISOs in any case.
>
>> *Editors:*
>> I don't know what to suggest here. I think we all have our favorites.
>
>I tend to drop VIM as the largest - ELVIS still remains.
>MINED and SETEDIT are next in size: I do not know MINED,
>but SETEDIT is quite powerful. Most others are small, so
>we can indeed include all of those even in FULL :-) And
>VIM can stay in EXTRA or online (are those 2 the same?)
>
>> I think keep them unless there's a good reason to drop one.
>
>> *to keep:* biew blocek doshexed e3 elvis fed freemacs mbedit mined
>msedit
>> 

Re: [Freedos-user] AMB, Ancient Machine Book format and FreeDOS Help

[Mateusz Viste]

Hi Christian,

Your docs seem very interesting! I didn't know about them. Having them 
available as AMB books would definitely be very cool.
I am not very fond of HTML as a source-to-be-processed data, but the halibut 
thing appears very promising. I will see how hard it would be to create a 
halibut2amb converter.

Mateusz




On December 13, 2020 9:27:06 PM GMT+01:00, "C. Masloch"  
wrote:
>On at 2020-12-13 09:15 +0100, Mateusz Viste wrote:
>>> I'd love to have the FreeDOS books in there, too. 
>>> https://www.freedos.org/books/
>>> I don't think I have the free time to convert them, but if I sent
>you 
>>> the ODT files, could you convert
>> 
>> Sure, if the books are terminal-friendly (ie. no illustrations or 
>> illustrations can be removed easily).
>
>Hi,
>
>I wonder whether you could convert my documentation to AMB format too? 
>Most of it is found at [1] -- each HTML file contains a link to the 
>corresponding hg repository near the end, which has the source. Such as
>
>[2].The source format is that accepted by the Halibut documentation 
>preparation system [3]. Perhaps you can convert from either the HTML 
>output or the Halibut sources to AMB?
>
>Regards,
>ecm
>
>[1]: https://ulukai.org/ecm/doc/
>[2]: https://hg.ulukai.org/ecm/insref/
>[3]: https://www.chiark.greenend.org.uk/~sgtatham/halibut/
>
>
>___
>Freedos-user mailing list
>Freedos-user@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/freedos-user


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

Re: [Freedos-user] AMB, Ancient Machine Book format and FreeDOS Help

[Mateusz Viste]

On 13/12/2020 02:11, Jim Hall wrote:
This makes me wonder if we could 
adapt this to become a new version of the FreeDOS Help system.


No adaptation required I think. This is specifically one of the use 
cases I had in mind when developing AMB - as a simpler, lighter and more 
generic replacement of the FreeDOS htmlhelp.


thinking maybe we could create an alias or "shortcut" COM program that 
launches AMB to read the FreeDOS Help (with the correct language file).


I guess a simple BAT file would be enough.

IF EXIST %DOSDIR%\doc\fdhelp.%LANG% GOTO LOCALLANG
IF NOT EXIST %DOSDIR%\doc\fdhelp.%LANG%
:LOCALLANG
AMB %DOSDIR%\doc\fdhelp.%LANG%
GOTO GAMEOVER
:FALLBACK
IF NOT EXIST %DOSDIR%\doc\fdhelp.en GOTO OOPS
AMB %DOSDIR%\doc\fdhelp.en
GOTO GAMEOVER
:OOPS
ECHO NO HELP DATA FILE INSTALLED. RUN "FDNPKG INSTALL HELP.%LANG%"
:GAMEOVER


I'd love to have the FreeDOS books in there, too. https://www.freedos.org/books/
I don't think I have the free time to convert them, but if I sent you the ODT 
files, could you convert


Sure, if the books are terminal-friendly (ie. no illustrations or 
illustrations can be removed easily).


On 13/12/2020 02:24, Andy Stamp wrote:
I had been working on getting the existing HTMLHELP to compile in 
OpenWatcom as a pre-work step to fixing some of the existing bugs.  But 
assuming this can handle the non-english languages it may be the way to go.


I had a look at HTMLHELP as well. It is an impressive piece of software, 
but insanely complex for what it is expected to do (display some text 
with links). That is the reason why I decided to create a dedicated 
format - something as simple as possible, so writing software for it is 
easy even with severe hardware limitations.


And yes, AMB does handle non-engligh languages (see the french FDHELP on 
the AMB project's web page).


Mateusz


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

[Freedos-user] AMB: new samples

[Mateusz Viste]

Recently I announced my latest AMB tool here, along with a conversion of 
the FreeDOS help. This message to let you know that I also converted the 
french version of the FreeDOS help, as a show case for "high ASCII" 
(international) content.


I have also produced an AMB book with 8086 instructions (I am not the 
author of the content itself, I only "converted" it, the content comes 
from the EMU8086 documentation).


All files can be downloaded (and viewed online) on the project's web 
page: http://ambook.sourceforge.net/


Mateusz


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

Re: [Freedos-user] AMB, Ancient Machine Book format and FreeDOS Help

[Mateusz Viste]

On 08/12/2020 22:44, Robert Riebisch wrote:

We could probably only catch those by starting to wrap all URLs in <> at
the document source level manually.


Yes, that would be a very good compromise.


But there may be side effects, when <> is used for other stuff too.


The linkification engine would not look at the <> alone - it would 
rather try matching "". This would be much better than the 
current situation, and I do not think there would be any significant 
side effects. But, in any case, this would require many corrections in 
the help files.


Mateusz


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

Re: [Freedos-user] AMB, Ancient Machine Book format and FreeDOS Help

[Mateusz Viste]

On 07/12/2020 19:42, Robert Riebisch wrote:

Can we have:
1) Clickable web links, please? E.g., http://www.trumpet.com.au/ at
.
2) A back to home function by clicking on "FreeDOS help system (hhstndrd
1.0.8 en)".
3) A search function.


All very good ideas, but...

1) I implemented an experimental linkification of URLs, but the result 
is not really satisfactory. Problem is that URLs are sometimes 
multi-line or contain weird characters (like ":") or are followed by 
unpredictable content. I think I will remove this feature and instead 
add a provision in the language for content creators to be able to 
define external URLs, so the thing would behave in a predictable way.


2) easy and certainly good to have - added.

3) definitely useful, but non-trivial to implement in an efficient way. 
Full text search is something I plan to add to the DOS client anyway, so 
I might reuse the same mechanism in the web UI for consistency. But as 
said - non-trivial, planned "in the future".


Mateusz


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

Re: [Freedos-user] AMB, Ancient Machine Book format and FreeDOS Help

[Mateusz Viste]

Update: this evening I created an AMB reader for PHP. This allows one to 
host AMB books on a web server and read them with a browser, the 
conversion being performed on the fly.


The FreeDOS help that I have earlier converted to AMB can now be read 
on-line. Here's how it looks like:

http://ambook.sourceforge.net/samples/phpamb.php?fname=fdhelp.amb

A link to the above URL is also present on the main page of the AMB 
project now (at http://ambook.sourceforge.net/ ).


Mateusz




On 05/12/2020 18:08, Mateusz Viste wrote:

Hello,

These past few days I was working on a new hobby project. It is called 
AMB, and it is a simple hyperlink format that makes it possible to 
create "books" that are easy to read even on very limited hardware.


The "books" can be viewed with a tool named AMB. It is only a few 
kilobytes big and requires about 80K of available RAM.


As a demo, I converted the FreeDOS help today into an AMB book. This is 
something that I will use as the help tool in the Svarog386 FreeDOS 
distribution, but perhaps it could be an interesting alternative for 
vanilla FreeDOS as well. The AMB reader, as well as the format 
specification and the converted FreeDOS help file can all be downloaded 
on the project's home page:


   http://ambook.sourceforge.net

It is still a very much work-in-progress project, but perfectly 
functional already. I will certainly add a few features during incoming 
weeks (mouse support, some form of light compression, full-text search, 
etc).


I'd like also to compile the RBIL into an AMB book in some near future.

Enjoy.

Mateusz


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



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

Re: [Freedos-user] MS-DOS 7.1

[Mateusz Viste]

On 06/12/2020 22:31, Karen Lewellen wrote:

Its terrific, have been using it exclusively for years.


That's cool and all, but in what way exactly is it better than FreeDOS? 
That's a honest question.


BTW, MS-DOS 2.0 appears to be libre (MIT) nowadays - that could also be 
a good fit to some, given how small footprint (much smaller than 
FreeDOS) it has.


Mateusz


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

[Freedos-user] AMB, Ancient Machine Book format and FreeDOS Help

[Mateusz Viste]

Hello,

These past few days I was working on a new hobby project. It is called 
AMB, and it is a simple hyperlink format that makes it possible to 
create "books" that are easy to read even on very limited hardware.


The "books" can be viewed with a tool named AMB. It is only a few 
kilobytes big and requires about 80K of available RAM.


As a demo, I converted the FreeDOS help today into an AMB book. This is 
something that I will use as the help tool in the Svarog386 FreeDOS 
distribution, but perhaps it could be an interesting alternative for 
vanilla FreeDOS as well. The AMB reader, as well as the format 
specification and the converted FreeDOS help file can all be downloaded 
on the project's home page:


  http://ambook.sourceforge.net

It is still a very much work-in-progress project, but perfectly 
functional already. I will certainly add a few features during incoming 
weeks (mouse support, some form of light compression, full-text search, 
etc).


I'd like also to compile the RBIL into an AMB book in some near future.

Enjoy.

Mateusz


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

Re: [Freedos-user] problem with freedos help on fdos.org website

[Mateusz Viste]

On 01/10/2020 14:14, Jerome Shidel wrote:

However, he was not working on the code portion of HELP. He has only been 
working on the documentation. I think he has been looking for someone to assist 
him to make updates
to the program and resolve some bugs.

It has been a little while since I’ve heard from him and I don’t know the 
current state of his efforts.


He contacted me a couple of weeks ago - apparently still in search for a 
volunteer to fix a few issues in the FreeDOS help system. The current 
version exhibits bugs with some help articles, displaying garbage or 
even crashing when browsing links.


I'm sure he'd be happy to provide details, if only someone would be 
willing to look at it.


Mateusz


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

Re: [Freedos-user] Some networking present

[Mateusz Viste]

On 07/09/2020 18:15, Michael Brutman wrote:
Others have provided small utilities to let WATTCP apps use the mTCP 
DHCP program.  I think that is a reasonable solution given the history.


Interesting. Any links? mTCP seems to be quite popular nowadays - at 
least as much as Wattcp-based applications, so it could be nice to have 
such "glue" add-ons onboard in FreeDOS. That is assuming their licenses 
are compatible of course.


On a more positive note (which I think we all need) reinventing the 
wheel is fun.  Competition is part of a healthy ecosystem. 


Absolutely. Bridges are also nice things, when possible/applicable, so 
the ecosystem does not appear too much fragmented to end users. :)



Next up for mTCP - IPv6


That would be very nice indeed. Sooner or later IPv6 will replace IPv4, 
it'd be really cool to have a working networking solution then, without 
needing to rely on external 4to6 contraptions. I managed to build 
picoTCP with IPv6 support once, and it somewhat worked (at least it was 
exchanging ICMPv6 neighbor discoveries with peers) - but the added bloat 
was horrible (hundreds of KiBs), not much memory being left for the 
actual application. I ended up disabling IPv6 in the default build. I am 
curious to see how small you will be able to get.


I'm also thinking about a network drive for DOS.  EtherFlop is 
intriguing but I really want to go with something over UDP so that it is 
routable on a network and can be hosted on the server side by a Windows 
or a Linux machine.


I have added provisions to the EtherDFS protocol so it can be compatible 
with UDP. It would actually be relatively easy to make it work over UDP. 
I was planning to at one point, but then didn't really need it so it 
went into backlog for an indefinite time... Perhaps I'll revisit this in 
some near future. That being said I wouldn't use such drive over 
internet myself - DOS is very picky about timing and lost packets when 
it comes to I/O operations... But a routeable home LAN with a few 
different subnets could be a good use case.


small doses I'm still working my way up to TSRs, which are a lot harder 
to debug than the C programs I've been writing.


They are indeed - I've spent more nights than I can count debugging 
EtherDFS and EthFlop while battling with random freezes, memory 
corruptions, suddenly hanging games and such. TSRs are truly a toxic 
environment. But it's part of the challenge, after all.


Mateusz


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

Re: [Freedos-user] Some networking present

[Mateusz Viste]

On 07/09/2020 05:31, Michael Brutman wrote:
"Exotic" is a strange word ...  


Let me help. Quick web search suggests such definition:
"Intriguingly unusual or different"


WATTCP uses its own configuration file, mTCP uses its own configuration file.


My point exactly. There are users now that configure the mTCP config 
file and wonder why Wattcp isn't catching it.



After WATTCP came to my attentioned I looked at it and determined that I would 
continue to do my own thing.


Nothing wrong with that - on the contrary: the more the merrier! But 
some sort of compatibility layer would be most welcome. If not at the 
(ABI) library level, then at least sharing the same configuration file 
and directives (or subset/superset of).


One good reason not to share the configuration file that I can think of 
from the top of my head would be if mTCP used a leaner (binary) 
configuration format to avoid implementing a full blown text parser, 
hence saving a little bit on memory. But IIRC, mTCP's configuration file 
is ini-style, just like what Wattcp/Watt-32 use. Are there other reasons 
I missed?



You did write picoSNTP even though SNTP clients already exist, right?
Isn't this another example of a wheel being reinvented?


picoSNTP is (was) part of a larger proof of concept that aimed to show 
"something" working in DOS with a hacked version of the picoTCP. Not 
really a production-ready replacement for any existing TCP/IP stack. I 
didn't pursue this as I lost interest in the mean time, but I did have 
plans to implement a wattcp configuration generator within my 'ipcfg' 
picoTCP configuration tool (possibly extended further to generate mTCP 
configurations as well, in the spirit of "one tool to rule them all").


Mateusz


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

Re: [Freedos-user] Some networking present

[Mateusz Viste]

The FreeDOS wiki links to a website that no longer exists. Yes, 12 years ago it 
was saying "provided free without support.":

https://web.archive.org/web/20081002025059/http://www.trumpet.com.au:80/dosapps/

Today, however, the author's page does not feature such phrase - only a list of 
commercial prices for its DOS stack. He may just as well have changed his mind.

Mateusz





On September 6, 2020 8:07:43 PM GMT+02:00, dmccunney 
 wrote:
>On Sun, Sep 6, 2020 at 2:02 PM ZB  wrote:
>> On Sun, Sep 06, 2020 at 07:52:05PM +0200, Mateusz Viste wrote:
>>
>> > And the Trumpet TSR itself does not appear to be free:
>> > http://www.trumpet.com.au/index.php/products/tcpip-driver.html
>>
>> From what I see there it's paid only for >=10 units (so probably in
>case
>> of "corporate use" or similar)
>
>See http://wiki.freedos.org/wiki/index.php/Networking_FreeDOS_-_NTCPDRV
>
>> regards,
>> Zbigniew
>__
>Dennis
>
>
>___
>Freedos-user mailing list
>Freedos-user@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/freedos-user
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Some networking present

[Mateusz Viste]

On 06/09/2020 19:18, ZB wrote:

Perhaps it could be feasible to improve the programs to make them follow
such simple algorithm:

1. Let's find out, maybe Trumpet TSR offers its services?
2. If it's present, connect using Trumpet...


This is twice the programming work required for networking. Not really 
interesting from the programmer's point of view. But even assuming one 
would be willing to waste time on such double implementation, he'd need 
to figure out the Trumpet's API - it does not seem to be publicly 
available... And the Trumpet TSR itself does not appear to be free:

http://www.trumpet.com.au/index.php/products/tcpip-driver.html

Overall, not at all appealing to the DOS hobbyist.

Mateusz


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

Re: [Freedos-user] Some networking present

[Mateusz Viste]

On 06/09/2020 17:03, ZB wrote:

Gopherus works (although still it wants to configure network, that already
has been configured using mTCP's DHCP; so it seems Gopherus doesn't do any
detection "do I already have network acccessibler?" at all),


mTCP is kind of an exotic piece of software - its networking 
configuration works only with the tools that are supplied with the mTCP 
package.


Back in the day, the usual way to interact with IP/Ethernet networking 
was to rely on the Wattcp library (later forked as Watt-32). Watt-32 
uses its own configuration file, so you'd have to set it up first for 
being able to use Wattcp/Watt-32 based tools (or rely on DHCP, which is 
the default fallback if no config file is found). I can only wonder why 
Michael didn't make his software compatible with the Wattcp 
configuration file instead of reinventing the wheel.



So both programs seem to dislike Trumpet TCP (different API?)


Trumpet is a networking TSR, while Wattcp, Watt-32 and mTCP are 
libraries embedded into the executable. Completely different approaches.


Mateusz


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

Re: [Freedos-user] Some networking present

[Mateusz Viste]

On 06/09/2020 02:33, ZB wrote:

Anyway I was able to ping and to log into FTP server - so I can assume
network is present


Sounds good indeed. Is FDNPKG or Gopherus working as well? They rely on 
Watt-32 and Wattcp, respectively. The latter does not have DHCP support 
IIRC.


Mateusz


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

Re: [Freedos-user] Dosemu on its own - does it exist?

[Mateusz Viste]

No, it was application-level, and AFAIR it required the applications not 
to be too greedy about what they do. I think that what you describe now 
isn't possible without introducing some form of (expensive) emulation to 
avoid the different systems to fight for shared resources. At the very 
least it would require an emulation of a different BIOS for each instance.


I wonder how far one could get with just an emulated 8086 core, 640K of 
mapped memory and a simulated BIOS. Perhaps it could run some early 
MDA-compatible software that was made before the "use hardware directly" 
era.


Mateusz



On 02/09/2020 16:08, ZB wrote:

On Wed, Sep 02, 2020 at 03:56:26PM +0200, Mateusz Viste wrote:


https://en.wikipedia.org/wiki/DESQview


Indeed I recall that name - but somehow never used it before. Does it do
exactly what I've described? Like - for example - I could "split" 486 into
four x86 CPUs, then I can use one instance to boot FreeDOS there, the second
one to boot DOS 6.22 (for comparison), the third one for, say, DR-DOS etc.




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

Re: [Freedos-user] Dosemu on its own - does it exist?

[Mateusz Viste]

DOSemu relies on a number of Linuxisms, hence cannot be used as such 
kind of bootstrap. What you think about is called DESQview.


https://en.wikipedia.org/wiki/DESQview

Mateusz


On 02/09/2020 15:48, ZB wrote:

If I'm correct, Dosemu uses "virtual x86 mode" of 386 and later processors.
But Dosemu of course needs "host OS".

I wonder does there exist any utility that offers "virtual x86 mode" and
acts as "host" by itself? Suppose we have (quite modest for today) computer
with 386/486 and 4 MB RAM. Theoretically it should be possible to run quite
comfortably four DOS "instances" each one having 1 MB just for itself - and,
say, switching among them with - like among consoles in Linux.

So concentrating on using DOS - because 486 is much too "weak" for Linux of
today - I mean utility whose duty is just to switch CPU into "virtual x86
mode", split RAM among established "instances" and then just share hardware
resources (keyboard, CD-ROM, video, sound... everything) among them.

No idea - maybe it had been aleady created, just I didn't stumble upon it yet?



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

Re: [Freedos-user] A few suggestions to improve debug

[Mateusz Viste]

On 01/09/2020 04:16, Jon Brase wrote:

it's also meant to be an alternative to MS-DOS for the very oldest PC hardware, 
all the way back to the original IBM 5150. The core software might therefore be 
expected to work in very little RAM. As I recall, the minimum configuration for 
the 5150 had only 16k of RAM. (...) So for FreeDOS to work on such machines, it 
has to (...)


Sorry, but there is no chance that FreeDOS could possibly run on 16K 
RAM. It requires at least 10 times as much, only to load itself (kernel 
needs about 64K, command.com requires roughly another 64K, plus buffers 
and stack) - and more to run any application bigger than a COM-style 
hello world.


Mateusz


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

Re: [Freedos-user] BASIC

[Mateusz Viste]

On 28/08/2020 16:33, Richard Wegner wrote:

I would like to some BASIC programming but don't know what to use.


I recommend FreeBASIC (fbc), it's truly an awesome compiler. It features 
a "quickbasic-compatibility" switch if you prefer to stay with old-style 
basic.


https://freebasic.net/

Mateusz


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

Re: [Freedos-user] Open source thoughts about my DOS stuff

[Mateusz Viste]

On 27/08/2020 10:56, Eric Auer wrote:

Having no SVN, CVS, GIT, HG for DOS tells me
that we are stuck to cross-compilers or people
who just download in other OS, then use in DOS?


Myself, I open one terminal with dosemu (for compiling stuff) and a 
second one with the normal linux shell to operate svn and edit files. 
Since dosemu relies on the local fs, it is extremely convenient.


Mateusz


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

Re: [Freedos-user] zip programs and pure DOS?

[Mateusz Viste]

On 22/08/2020 07:29, Jim Hall wrote:
Sounds like what you need is the zipfix tool. I think PKware had 
pkzipfix? Check for that and run it. That tool will check for errors in 
your zip files.


From the little information OP provided, I'd guess that the issue might 
be rather related to missing LFN support - either in pkunzip or in her 
system, while the text files stored inside the zip archives may use long 
filenames or contain some unusual symbols (spaces...).


Another possibility is that the zip files store subdirectories with a 
slash (/) instead of the legacy backslash symbol. InfoZip processes such 
entries gracefully, no idea about pkunzip.


Mateusz


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

Re: [Freedos-user] FreeDOS 1.3-RC3 News / 8086 compatibility

[Mateusz Viste]

On 25/05/2020 17:29, Jerome Shidel wrote:

I wouldn’t get anything lower than a 286 to Run the current kernl86.sys.


Svarog86 is a FreeDOS distribution that uses the kernl86.sys. Works on 
my 8086 with no troubles, although it has a few things turned off (for 
memory saving, not 8086 compatibility).


Mateusz


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

Re: [Freedos-user] Configuration options for DOS beep

[Mateusz Viste]

Look for MUTE110.ZIP:

https://www.sac.sk/files.php?d=16=48

"Mute is a small TSR that, once it is installed in memory, will 
continuously scan the PC Speaker and reset it to 'No Sound' state."


If that one doesn't work for you, then there are certainly other, 
similar tools out there.


Mateusz



On 08/05/2020 17:55, Johnpaul Humphrey wrote:

Hi All,

I want to disable the beep in certain freedos applications.
Most importantly COMMAND.COM
I got on the IRC yesterday, and recieved a couple of suggestions.
The first one was to disconnect the bell from the motherboard. I want
to avoid that if possible.
The second is there might be a configuration option.
I searched for words like "bell" and "beep" in my entire installation,
and did not find any configuration options.
I also looked into freecom's source, and saw the configuration files there.

So I think I have two options as far as freecom is concerned:
1. cut the wires, I want to avoid that if possible.
2. recompile freecom or any app that doesn't explicitly configure the bell.
I thought before I sink a lot of time into recompiling, that I would
ask around and see if there is some configuration file I missed.




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

Re: [Freedos-user] DOSBOX Isn´t for everyone (off-topic remark)

[Mateusz Viste]

On 27/03/2020 11:25, userbeit...@abwesend.de wrote:

Yes, FreeDOS tends to be growing, which makes sense. For old computers,
original to that time, EDR-DOS might be a better choice.


Or you might try some minimalistic FreeDOS distribution tailored 
specifically for the truly ancient machines.


http://svarog86.sourceforge.net

Mateusz


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

Re: [Freedos-user] DOSBOX isn't for everyone...

[Mateusz Viste]

On 25/03/2020 14:07, ZB wrote:

On Wed, Mar 25, 2020 at 01:50:42PM +0100, Mateusz Viste wrote:


On 25/03/2020 12:28, userbeit...@abwesend.de wrote:

Afaik there is no Linux that will run with only 8 MB of RAM.


Extract from the Debian Buzz FAQ:

"Debian Linux can be installed on systems with only 4 MBytes of RAM. (...)
An 80386-based system with only 4 MBytes of RAM and 40 MBytes disk space has
been used to run Debian Linux in this way; i.e., both networking and basic
X11 server functions operated satisfactorily."


That was valid around 20 years ago... :D


Of course, that is why I am referring to Buzz. Now, why would anyone 
want to run a recent distribution on a 386? Linux distributions from 25 
years ago work just as well as they did back then.


Mateusz


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

Re: [Freedos-user] DOSBOX isn't for everyone...

[Mateusz Viste]

On 25/03/2020 12:28, userbeit...@abwesend.de wrote:

Afaik there is no Linux that will run with only 8 MB of RAM.


Extract from the Debian Buzz FAQ:

"Debian Linux can be installed on systems with only 4 MBytes of RAM. 
(...) An 80386-based system with only 4 MBytes of RAM and 40 MBytes disk 
space has been used to run Debian Linux in this way; i.e., both 
networking and basic X11 server functions operated satisfactorily."


Mateusz


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

Re: [Freedos-user] fdnpkg.exe - how does it know where to install the packages to?

[Mateusz Viste]

On 24/03/2020 00:05, mich...@robinson-west.com wrote:
I think I missed a command.com line in fdauto.bat where it still said 
C:\... and that this is why fdnpkg.exe installed to the C drive.


If I'm wrong, why does fdnpkg.exe install to C:\ when I'm running on a 
Zip disk mapped to A:\ by the bios?


Read FDNPKG.CFG for instructions, esp. its configuration of paths for 
installing various components.


Mateusz


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

Re: [Freedos-user] FreeDOS wishlist and feature requests

[Mateusz Viste]

On 23/03/2020 21:47, Mercury Thirteen via Freedos-user wrote:

I noticed that, but the driver itself reports it is 3.34.


In the source code I have seen "3.35", though:

VERSIONSTR  equ <'3.35'>
DRIVER_VER  equ 300h+35

have two 3.34 versions: one from 2015 and one from 2020. The new 2020 
version should have been bumped to 3.35, but it was kept at 3.34 for 
some reason.


Probably because Japheth did not work on the 2015 version, but forked 
off an older version, meaning his version is not an incremental update 
of the 2015 3.34... So there are effectively two different branches now.


Mateusz





‐‐‐ Original Message ‐‐‐
On Monday, March 23, 2020 4:40 PM, Mateusz Viste mate...@viste.fr 
<mailto:mate...@viste.fr> wrote:


On 23/03/2020 21:30, Mercury Thirteen via Freedos-user wrote:

Also, the packaged version of HIMEMX is done and can be found here
http://mercurycoding.com/downloads/DOS/HIMEMX.zip. Hopefully I
didn't
miss anything!

There is a version mismatch between the lsm (3.34) and the actual driver
(3.35).
Mateusz
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
<mailto:Freedos-user@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freedos-user




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




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

Re: [Freedos-user] FreeDOS wishlist and feature requests

[Mateusz Viste]

On 23/03/2020 21:30, Mercury Thirteen via Freedos-user wrote:
Also, the packaged version of HIMEMX is done and can be found here 
. Hopefully I didn't 
miss anything!


There is a version mismatch between the lsm (3.34) and the actual driver 
(3.35).


Mateusz


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

Re: [Freedos-user] Introducing myself, and inquiring about using FreeD OS as a blind user

[Mateusz Viste]

On 20/03/2020 11:00, Eric Auer wrote:

So I would say if you only need real-time at moments without DOS
kernel (or BIOS) interaction and if you need much RAM directly
available without the hassles of EMS or XMS, then DJGPP is nice!


DJGPP is nice, without question. But here we are talking about a TSR 
that would need to run in parallel of both DOS and another (real mode or 
not) game or application without disturbing it, while synthesizing 
speech at the same time.



In short, I think it is feasible to do this. But remember that
games are very different from a screen reader TSR which has to
run in the background without disturbing normal DOS usage.


Exactly right.


This would be pretty hard but still feasible.


That is why I was saying "unrealistic". Not "impossible".


Many speech synth and screen reader software packages for DOS and
other systems have been named in this thread, so I would be glad
to hear more about features and requirements of those which have
a free license.


I looked at 3 of them: JAWS, ASAP and PROVOX.

JAWS and ASAP are both "freeware for personal use, no sources". In both 
cases the subject of distribution rights is unclear. PROVOX is released 
under the GPL2 license, so no doubts there. I made a package for PROVOX, 
that is included in my own distribution (Svarog386), it can be imported 
into FreeDOS as well:

http://svarog386.sourceforge.net/repos/drivers/provox.zip


 Maybe somebody could publish a howto for using

them with FreeDOS, either on raw hardware or in a VM or dosemu?


Step one: load the PROVOX TSR (type "PROVOX")
Step two: activate correct synth output ("PV BNS" for Braille 'n Speak)

That's as simple as that, it talks immediately. Of course there is a 
huge amount of options, hotkeys and so on if one wants to use it really 
seriously. All is described (as you know) in the PROVOX manual.


The VM scenario is something I described on the emubns page along with a 
ready-to-use QEMU image: http://emubns.sourceforge.net


Mateusz


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

Re: [Freedos-user] Talking FreeDOS (through QEMU + emubns)

[Mateusz Viste]

On 19/03/2020 23:59, joseph.nor...@gmail.com wrote:

I always wanted to try QEMU, but, never could figure out the serial stuff.


Yes, serial emulation is somewhat tricky to setup. But once one finds 
the correct QEMU invocation, it works very well. I described the exact 
QEMU command line arguments that need to be used in the readme file 
within the package. Let me know if anything is unclear, I will do my 
best to improve the documentation. The nice thing is that there is no 
need to install the com0com kludge, since QEMU is able to talk directly 
to emubns over a loopback TCP socket.



Thanks for putting this together.


Well, thank you for your effort!

Mateusz




*From: *Mateusz Viste <mailto:mate...@viste.fr>
*Sent: *Thursday, March 19, 2020 1:13 PM
*To: *freedos-user@lists.sourceforge.net 
<mailto:freedos-user@lists.sourceforge.net>

*Subject: *[Freedos-user] Talking FreeDOS (through QEMU + emubns)

Hello all,

Today I have put together a QEMU FreeDOS-based image that comes

preinstalled with a screen reader. I also wrote instructions about how

to set it up under Linux and Windows, relying on the emubns synth

emulator. I tested it successfully under Windows 8 x64. The image can be

download on the emubns homepage:

http://emubns.sourceforge.net/

It is, by design, very similar to how Joseph's distribution works, ie. a

hypervisor running DOS with a screen reader, with vocalization being

performed by an external emulator. Different bricks used, but same idea.

Perhaps it will prove useful to anyone.

Mateusz

___

Freedos-user mailing list

Freedos-user@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/freedos-user



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




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

Re: [Freedos-user] Introducing myself, and inquiring about using FreeD OS as a blind user

[Mateusz Viste]

Hello Karen,

I will try to keep it on topic.

On 20/03/2020 06:03, Karen Lewellen wrote:

DJGPP is a complete 32-bit C/C++ development system for Intel
80386 (and higher) PCs running DOS.


I am saying that DOS is a 16-bit, real-time operating system. You say 
that DJGPP is more powerful. Yes, but DJGPP is not DOS. Then of course, 
one could imagine a 32-bit DOS-like system with 386 memory management, 
protected mode etc but it simply would not be called DOS. It would be 
called reactOS, Windows, Linux, or anything else.


unrealistic to expect performing any kind of native voice synthesis in 
such configuration.


According to whom?
it is one thing to claim,  that you do not know how something is done, 
quite  another to state something is unrealistic.


Proper speech synthesis through a SoundBlaster card in real mode DOS, 
within a TSR or driver that takes no more than a couple of KB or RAM 
while keeping compatibility with existing software? Yes, I am sorry to 
insist, but this is technically unrealistic and no amount of 
motivational talk will change that. Now of course speech synthesis in 
some limited way is possible on poor hardware, efforts were done even on 
machines like the ATARI 800XL, but the resulting quality was disputable, 
at best. Years ago I even played with some DOS tool that was attempting 
synth speech over PC Speaker, but to be honest I was unable to 
understand a word of it.


I'd be glad if you proved me wrong, though.

I realize you  mean no dishonor, but have you any idea how often I am 
told it is  unrealistic technically for me to use a computer...at all?


That is a feat I am most amazed about, but that's not the point. Human 
limitations are often misunderstood. It is much easier to understand 
limitations of machines and software designs, that is why the example 
you cite is not exactly relevant.


Mateusz, there are screen readers that talk to internal cards. to 
soundblaster  adapters, to USB devices


Under real mode DOS? Could you share some links or names of commercial 
products that achieved that? I'd be keen to know more about them.



after all scientists have been solving this problem since the  60's.


DOS has been designed in the 80's, and it is condemned to stay there for 
the sake of retro compatibility.


Your personal effort, while certainly appreciated does  not make you an 
expert.


I am definitely not an expert in the field of blind-related activities 
indeed. That is a field that I find highly interesting, but my practical 
knowledge is non-existent. That being said, I like to think that I know 
a thing or two about DOS and x86 architectures, including a more or less 
accurate idea of what can or cannot be done.


Individuals   pay  thousands for the ability to read write and 
communicate, buying synthesizers, and software practically daily, even 
if their ultimate goal is not achieved.


I am not disputing that. I am only saying that I find it unlikely that 
one would invest any amount of money for the only sake of playing an old 
game on an ancient system, while free ways exist to achieve the same. 
Now of course if one wants to buy an external synth and setup an old PC 
dedicated to DOS - more power to them. But there is a choice, and I 
believe choice is essential.


You mean the way Joseph integrated ASAP  which has  several prospects 
for speech, including a  generic driver created  to work  in case one 
has none of the synthesizers listed?


Yes. That's the very same way I found to be optimal after my own 
research, and that I implemented in the solution I presented in another 
message on this list about "Talking DOS", with the difference that I 
used a synth emulator that I wrote myself. I also relied on open source 
QEMU instead of using the non-free VMWare Player.


Incorporated after Joseph  asked permission, which sort of  skips past 
the licensing factor?


While I am happy it fulfills Joseph's need, it does not skip past the 
licensing factor as far as FreeDOS is concerned, sorry.


But, if permission is obtained, which Joseph did, one can use another 
tool.  meaning licensing compatibility is no reason to limit options.


True from the point of view of an individual, yes. But that won't work 
for FreeDOS, as the license exception obtained by Joseph does not 
include the 3 liberties that are at heart of the FreeDOS project.


Actually, it works fine when used  as designed.  My guess from your 
efforts is you were not using it as designed.


PROVOX works very well indeed, yes. Turns out the problem I had was not 
related to PROVOX at all, but to a wonky RS 232 support within 
VirtualBox. This is the reason why I dropped VirtualBox and switched to 
QEMU.



Why use Jaws when joseph has proven you can get permission  to use asap?


As far as I understand, this permission does not include permission for 
repackaging, unlimited distribution, access to source code and 
publication of own changes to the software.



clearly it works as joseph 

[Freedos-user] Talking FreeDOS (through QEMU + emubns)

[Mateusz Viste]

Hello all,

Today I have put together a QEMU FreeDOS-based image that comes 
preinstalled with a screen reader. I also wrote instructions about how 
to set it up under Linux and Windows, relying on the emubns synth 
emulator. I tested it successfully under Windows 8 x64. The image can be 
download on the emubns homepage:


http://emubns.sourceforge.net/

It is, by design, very similar to how Joseph's distribution works, ie. a 
hypervisor running DOS with a screen reader, with vocalization being 
performed by an external emulator. Different bricks used, but same idea.


Perhaps it will prove useful to anyone.

Mateusz


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

Re: [Freedos-user] FreeDOS is slow in Raspberry 4

[Mateusz Viste]

On 18/03/2020 17:16, Ralf Quint wrote:
What some people are forgetting (had the exact kind of discussion in a 
vintage computer forum just a few days ago) is that in this case, QEMU 
needs to completely emulate an x86 CISC CPU on an ARM RISC CPU, 
including converting all data on the fly between little-endian and 
big-endian format on the fly, all the time.


All true, with one exception: raspbian runs the ARM SoC in little-endian 
mode, so no conversion needed there.


Mateusz


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

Re: [Freedos-user] Introducing myself, and inquiring about using FreeD OS as a blind user

[Mateusz Viste]

On 18/03/2020 16:54, joseph.nor...@gmail.com wrote:
I just booted into FreeDOS and it worked ok.  Pressing /l told me I was 
on line 25 and read the DOS prompt.


Sounds nice. Thanks for confirming, at least I know now that it is 
supposed to work out of the box. It must be something off with my 
VirtualBox configuration then - in fact I tested ASAP right now and it 
immediately freezes. The only screen reader that appears to work for me 
is JAWS. I suspect this has to do with some RTS/CTS emulation glitch 
within VirtualBox, I will have to do some deeper investigations.


cheers,
Mateusz


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

Re: [Freedos-user] Introducing myself, and inquiring about using FreeD OS as a blind user

[Mateusz Viste]

On 18/03/2020 16:05, joseph.nor...@gmail.com wrote:

Provox does work, but to install it you do two things.

First, you need to run the provox.exe tsr.


Did that.

Next, at the end of the fdauto.bat, you place a pv.exe command with the 
synthesizer perameter after it, for example:


c:\provox\pv.exe bns


Did that, as well.

PROVOX loads fine, but it sends only "synth clear" (0x05) reset messages 
over COM1, for example when I press slash + L. It never sends me 
anything to actually read aloud. Did it talk to you? What key presses 
have you performed?


Mateusz


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

Re: [Freedos-user] Introducing myself, and inquiring about using FreeD OS as a blind user

[Mateusz Viste]

On 18/03/2020 02:37, Karen Lewellen wrote:
Why cannot speech be built  native to freedos the way it is, I 
understand, native to Linux distros, including the use of hardware?


FreeDOS, like other flavors of DOS, is a 16-bit, real-mode operating 
system. This means it runs within an extremely constrained environment: 
typically with access to a maximum of 640 kilobytes of memory, one taks 
at a time, and being able to address objects no bigger than 64 
kilobytes. It is technically unrealistic to expect performing any kind 
of native voice synthesis in such configuration. The only realistic way 
would be to output text through a hardware port, like the RS-232, and 
let an external device do the sound generation. And that's exactly what 
screen readers do already. But it means of course that one must have an 
extra hardware synthesizer, which may or may not be an acceptable 
investment, depending on the ultimate goal. For people like Felix, who 
only want to play an old adventure game from time to time, this seems 
overkill - hence my idea to use VirtualBox instead, to run FreeDOS 
inside of it and connect an emulated software synthesizer. All this can 
be done for free, without any extra hardware, given that one has the 
patience and skills to set it all up.


Now, going back to FreeDOS: the only improvement I can think of is to 
include some sort of screen reader into the distribution. That is why I 
was interested in the PROVOX option, since PROVOX appears to have a 
license perfectly compatible with FreeDOS. Sadly, I was unable to make 
it output any sound, so I wonder whether it works at all. JAWS, on the 
other hand, works very well, but cannot be included into FreeDOS due to 
an incompatible license.


Mateusz


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

Re: [Freedos-user] Introducing myself, and inquiring about using FreeDOS as a blind user

[Mateusz Viste]

On 16/03/2020 21:13, Mateusz Viste wrote:
In fact, I created my own Braille 'n Speak emulator last night. I'm not 
sure yet what to do with it - so far I connected it to a FreeDOS install 
running under VirtualBox and played with JAWS (...)


Hello,

Today I published my Braille 'n Speak emulator, it's available here:
http://emubns.sourceforge.net

It is alpha grade software, compatible with Linux only for the time 
being. But it works (I use it to make a VirtualBox install of FreeDOS 
talk through JAWS). In the coming days I will try to make a Windows x64 
version as well.


Mateusz


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

Re: [Freedos-user] Introducing myself, and inquiring about using FreeDOS as a blind user

[Mateusz Viste]

On 16/03/2020 20:35, Karen Lewellen wrote:
Joseph, you opted for the braille and speak emulator, does that mean 
there exist other synthesizer emulators, for example is there a type & 
speak one or  a dectalk one?


I did some research and did not find any. The braille and speak system 
has been chosen probably because its protocol is simple and amount of 
features quite limited, which makes it easier to emulate.


In fact, I created my own Braille 'n Speak emulator last night. I'm not 
sure yet what to do with it - so far I connected it to a FreeDOS install 
running under VirtualBox and played with JAWS, but other usages would be 
possible as well: for example it could be installed on some cheap 
Raspberry Pi as a hardware alternative to aging devices.


Mateusz,  your explainations   help me a great deal.  My understanding 
is that, rather than installing freedos  via this fashion in a way that 
allows the use of actual hardware, the ports themselves are virtual, 
meaning it must be installed on a machine running something else, 
windows I suppose.


Windows or Linux, yes. The thing that allows to run an operating system 
within another operating system is called a hypervizor, and some 
hypervizors (VirtualBox and VMWare Player are two examples, but there 
are more) make it possible to redirect the COM port of the virtualized 
system somewhere else - for example a program that emulates a synthesizer.


further,  how current is Freedos  with DOS browsers?  Lynx is updated 
regularly for example.  there is a dos edition of l i n k s, as well 
adding JavaScript  of a sort.  what is the most current edition of Lynx 
incorporated into Freedos for example?


No idea, I do not use DOS for browsing the www, sorry. That being said, 
you might be interested in browsing the gopherspace. The gopherspace is 
a fully textual environment, the predecessor of the web really. There 
are still many enthusiasts running their own gopher servers world wide. 
Of course it is not an alternative to the web, but it does have 
interesting content, and seems to be perfectly suited to sight-impaired 
people due to its "text only" nature. I have written a gopher client for 
DOS, it is called "gopherus" and can be found here: 
http://gopherus.sourceforge.net


Mateusz


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

Re: [Freedos-user] Introducing myself, and inquiring about using FreeDOS as a blind user

[Mateusz Viste]

Wow, that is much more convoluted than I was expecting. I'm impressed 
you were able to figure out such a solution.


Is this NVDA-over-ssh-over-dosemu approach providing satisfying 
usability compared to a native DOS screen reader like JAWS or ASAP? In 
other words, is there any point in trying to run a native screen reader 
within FreeDOS? As a test I tried this morning using FreeDOS being 
blindfolded, using only JAWS + espeak, and I am staggered how you guys 
are able to do anything at all in such environment. I was barely able to 
open a text file, and failed miserably trying to edit it - all this seem 
to require an outstanding memory just to keep track of what is supposed 
to be displayed on the screen at any given moment.


Mateusz



On 16/03/2020 14:20, Felix G. wrote:

Hi Mateusz,
I logged into a Linux server via SSH from Windows, installed Dosemu,
then started Dosemu with the -t option, putting it into terminal mode.
In effect, my Windows screen reader, which is called NVDA, detects and
reads changes to that terminal session, thereby giving access to the
DOS environment.
Here is how I got Dosemu2:
$ sudo add-apt-repository ppa:dosemu2/ppa
$ sudo apt-get install dosemu2
I then downloaded the FreeDOS Kernel, extracted KERNEL386.SYS, and
copied it to ~/.dosemu/drive_c/KERNEL.SYS so Dosemu boots it up. I
also replaced Dosemu's command interpreter by the COMMAND.COM that
comes with FreeDOS, and then I tweaked autoexec.bat and fdconfig.sys
until there was not a single error message during boot. Does a rather
convincing DOS approximation. Since Dosemu's virtual C: drive is just
a plain old directory on my Linux server, I can just unzip games to it
and start them up, without so much as exiting Dosemu.
Best,
Felix

Am Mo., 16. März 2020 um 14:03 Uhr schrieb Mateusz Viste :


On 16/03/2020 13:12, Felix G. wrote:

In the meantime I was able to play the Time And Magik trilogy by Level
9 in Dosemu2, using the current FreeDOS kernel 1.2


May I ask how you achieved this? Have you managed to install a screen
reader within DOSemu, which would talk through some Linux TTS? I'm
geniunely curious.

Mateusz



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