[Freedos-user] EVOC 1714VNA does not support a real floppy controller...

[michael]

I'm talking about the ISA variety via a digital research multi I/O card

It does however support USB floppy drives, but I doubt that they work in 
freedos.

I think the problem is the bios, it has to show the correct geometry, etcetera.

As this is an industrial single board computer that's 20 years old, I'm 
wondering if I can get the source code to the bios?

Windows XP picks up the floppy controller, it just gets an unrecognized error 
when I try to format a disk.

Freedos 1.3 tries to use the floppy drive, but I cannot format a disk there 
either getting a DMA overrun error.

 -- Michael Robinson
___
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

[Swap Jim via Freedos-user]

Tried it. Didn't change anything. But thanks for the suggestion.

On 2020-03-19 05:48, Louis Santillan wrote:

Something to note in the original bug report is that CFLAGS chosen are
not optimal for performance (`make 'CFLAGS=-Wall -g -O2 -w'`).
Specifically, the `-g` and `-O2`  flags should probably be changed.

`-g` [0] adds debugging info which will make the QEMU binary larger,
and produce code & data to allow instrumenting and debugging at
runtime.  This will blow cache performance since more code & data
overflow the cache.  I recommend removing this all together.

`-O2` [1] instructs the compiler to enable all performance options
that do not involve a space-time tradeoff.  Generally `-O3` is
considered to produce the most "optimal" code, `-Os` is beneficial for
CPUs with small caches and `-Ofast` can enable further performance
potentially at the cost of program execution correctness.

I recommend trying `-O3` or `-Ofast` without `-g` and retesting/rebenchmarking.


[0] https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
[1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options

On Wed, Mar 18, 2020 at 1:48 PM Jim Hall  wrote:




On Wed, Mar 18, 2020 at 3:00 PM Eric Auer  wrote:



Hi Ralf,


How about first installing to a directory or diskimage stored
in a ramdisk on the host OS, then copying that to mass storage?



This would be a bit like the old chicken and egg problem. The time you
would spend to copy the contents of the FreeDOS distro from the SD card
to a RAM disk on the RPi is likely not much faster...


I expect it to be much faster because: You only read from the
slow SD card and you read fewer, larger files. The bad parts,
writing many small files, would be on the fast ramdisk side.
Also, you can start from a FreeDOS ISO on the SD card, which
again is only one big file to copy from the web to the card.
When done, you copy one big file, the diskimage, once from
the ramdisk to the SD card :-)
[..]



Someone had suggested that option to me - install FreeDOS to a HD image in a 
RAM drive, then copy the HD image back to storage.

But I didn't want to explain those extra steps in my article. And really, installing FreeDOS on 
QEMU+RPi takes longer, but it's not "all day" long. It's more like "start the 
install, and make a cup of coffee while the install finishes." For a one-time thing, it's not 
too bad.


___
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

[Felix G.]

Hello everyone!
I am blown away, in the most positive sense of the word, by the
fruitful discussion my original post seems to have sparked, or
rekindled. For this discussion to have its heated moments is only
natural as emotions, passions and frustrations are involved.
If there is one point of constructive criticism I would like to make,
it is to draw attention to the fact that some remarks have ranked
rather high on my personal confrontational scale. While this does not
render these remarks false in any way, they might come across as
intimidating or, depending on personal associations, eristic.
I want to appeal to all of us, explicitly including myself, if we feel
we need to correct someone, to always do so gently and charitably.
Here's to the accessibility of FreeDOS, and to tomes full of knowledge
rather than dictionaries of limitations.
Best,
Felix

Am Fr., 20. März 2020 um 11:01 Uhr schrieb Eric Auer :
>
>
> Hi Mateusz, hi speech experts,
>
> >> 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.
>
> Actually the FD32 project is or was about running the DOS kernel
> in protected mode, but the performance gains were small. I have
> used DJGPP myself for tasks where I wanted many megabytes of RAM
> directly available and of course you do notice that DOS will not
> do anything in the background. So for example I buffered file I/O
> during busy periods and only called DOS to write data files later
> when it did not disturb me that I had to wait until DOS was done.
>
> 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!
>
> About the feasibility of speech synthesis in DOS: If you use the
> SoundBlaster AWE, you can load samples into the RAM of the sound
> card and "play" speech like an instrument :-) Games usually take
> either the protected mode or EMS (or XMS) route to access their
> sample library. The PC speaker speech TSR contains a few dozen,
> of course low quality, phoneme samples in only tens of kB RAM.
>
> So yes, it can be done, but which modern computer can still be
> connected to a SoundBlaster? You would have to use HDA / AC97.
> Which a few modern DOS media players are actually able to use.
>
> 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. This
> would be pretty hard but still feasible. On the other hand, it
> just is a lot easier to run DOS in dosemu or a VM and make use
> of sound drivers, speech synthesizers and infrastructure running
> on the host operating system with all fancy multitasking and 32
> or 64 bit memory and disk management features readily available.
>
> 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. Maybe somebody could publish a howto for using
> them with FreeDOS, either on raw hardware or in a VM or dosemu?
>
> Thanks :-) Exiting to have such featurs for DOS!
>
> Regards, Eric
>
> PS: auersoft.eu is down at the moment due to an IP address
> change, let me know if you want to help fixing that ;-)
>
>
>
> ___
> 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]

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] Introducing myself, and inquiring about using FreeD OS as a blind user

[Eric Auer]

Hi Mateusz, hi speech experts,

>> 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.

Actually the FD32 project is or was about running the DOS kernel
in protected mode, but the performance gains were small. I have
used DJGPP myself for tasks where I wanted many megabytes of RAM
directly available and of course you do notice that DOS will not
do anything in the background. So for example I buffered file I/O
during busy periods and only called DOS to write data files later
when it did not disturb me that I had to wait until DOS was done.

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!

About the feasibility of speech synthesis in DOS: If you use the
SoundBlaster AWE, you can load samples into the RAM of the sound
card and "play" speech like an instrument :-) Games usually take
either the protected mode or EMS (or XMS) route to access their
sample library. The PC speaker speech TSR contains a few dozen,
of course low quality, phoneme samples in only tens of kB RAM.

So yes, it can be done, but which modern computer can still be
connected to a SoundBlaster? You would have to use HDA / AC97.
Which a few modern DOS media players are actually able to use.

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. This
would be pretty hard but still feasible. On the other hand, it
just is a lot easier to run DOS in dosemu or a VM and make use
of sound drivers, speech synthesizers and infrastructure running
on the host operating system with all fancy multitasking and 32
or 64 bit memory and disk management features readily available.

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. Maybe somebody could publish a howto for using
them with FreeDOS, either on raw hardware or in a VM or dosemu?

Thanks :-) Exiting to have such featurs for DOS!

Regards, Eric

PS: auersoft.eu is down at the moment due to an IP address
change, let me know if you want to help fixing that ;-)



___
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 
*Sent: *Thursday, March 19, 2020 1:13 PM
*To: *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