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

[Louis Santillan]

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

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

[Jim Hall]

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

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

[Ralf Quint]

On 3/18/2020 12:58 PM, Eric Auer wrote:



The only way you could possibly speed this up (at least on a RPi4B+)
would be to use a USB media (external hard drive/SSD), with the
RPi4B+ being significantly faster than previous models...

Yes. It always is something to check how fast the USB and LAN
of Raspberry style computers of various brands actually are.
Luckily benchmarks exist on the web :-) Alas, SBC rarely have
SATA connectors, so USB3 it will be. But even a SSD with USB2
is a lot faster than SD because of the much better IOPS :-)

As I mentioned, the RPi4B+ has a full USB 3.0 controller now, working 
with full 3.0 speed without interference from the Ethernet traffic 
anymore. I tested it, in fact I have a USB 3.0 external 2.5" HDD 
connected to mine, that's where all the data for my various SQL, email 
and web sites tests is... ;-)


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

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

[Eric Auer]

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 :-)

> The only way you could possibly speed this up (at least on a RPi4B+)
> would be to use a USB media (external hard drive/SSD), with the
> RPi4B+ being significantly faster than previous models...

Yes. It always is something to check how fast the USB and LAN
of Raspberry style computers of various brands actually are.
Luckily benchmarks exist on the web :-) Alas, SBC rarely have
SATA connectors, so USB3 it will be. But even a SSD with USB2
is a lot faster than SD because of the much better IOPS :-)

Eric



___
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

[Ralf Quint]

On 3/18/2020 11:56 AM, Eric Auer wrote:

Installing FreeDOS*on the Raspberry Pi *will take a long time regardless of
what options you use in QEMU. It's because of the high disk I/O when you
install an operating system like FreeDOS. It's made worse by doing it
inside an emulator, but the biggest slowdown when *installing* is the
storage device on the Raspberry Pi.

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 than trying to 
install from an SD card.


The only way you could possibly speed this up (at least on a RPi4B+) 
would be to use a USB media (external hard drive/SSD), with the RPi4B+ 
being significantly faster than previous models due to having a 
dedicated USB 3.0 controller now, which also isn't encumbered anymore by 
having to play network controller for the Ethernet port...


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

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

[Eric Auer]

Hi Jim!

> Installing FreeDOS on the Raspberry Pi will take a long time regardless of
> what options you use in QEMU. It's because of the high disk I/O when you
> install an operating system like FreeDOS. It's made worse by doing it
> inside an emulator, but the biggest slowdown when *installing* is the
> storage device on the Raspberry Pi.

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

MicroSD cards and many USB sticks are notoriously bad in their
I/O per second rating even when they advertise dozens or many
MB/s transfer speed for large files. For Raspberry style use,
the "Application performance class" is important: A1 promises
500 writes (1500 reads) per second, A2 2000 writes (4000 reads)
and yes A2 ratings are rare in spite of all those cards which
proudly announce dozens of MB/s for video recording.

Some tiny computers use eMMC disks, those are significantly
faster in everyday use. I even enjoyed compiling kernels on
one of those. They usually are pre-soldered to the SBC board.

Similar issues affect USB flash sticks: Even "fast" ones
drop to the low single digit MB/s when you attempt to use
them with many small writes and an unlucky filesystem choice
(I would like to know which filesystems are most bearable
in that context, in Linux?) with the only exception being
SSD style USB sticks which actually advertise having high
write IOPS. A bit of a luxury but probably works fine :-)

Regards, Eric

PS: Interesting thought that Raspian uses the right endian
for x86 simulations. Would be nice to see some benchmarks,
maybe also comparing different virtual PCs beyond Qemu :-)

> My RPi3B has a SanDisk Ultra 64GB microSDXC UHS-I U1A1 card.




___
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] FreeDOS is slow in Raspberry 4

[Jim Hall]

On Wed, Mar 18, 2020 at 12:36 PM Jon Brase  wrote:

>
> On 3/18/20 11:44 AM, Jim Hall wrote:
>
> Actually, I think it's a problem on the Raspberry Pi 4. I've heard from a
> few folks since the RPi4 came out that my how-to about running FreeDOS on
> the Raspberry Pi (via QEMU)
>  results
> in a very slow FreeDOS. But I've only heard from people about the Raspberry
> Pi 4. The RPi3 seems to work okay. I have a Raspberry Pi 3, and it works
> fine. I've run my RPi3 with both Raspbian and Fedora ARM with the same
> results, so I don't think it's a distro issue, either.
>
> The Raspberry Pi (as lease version 3) is fast enough to emulate a '486 or
> Pentium CPU well enough to run DOOM and AsEasyAs and other DOS games and
> applications without lag.
>
>
> On a Pi 2, I'm getting the same slow video updates he describes, at least
> in text mode (haven't tried a graphical mode yet), but the emulated CPU
> seems to be running fast enough. Then again, the install process is taking
> a fair while, but I'm not sure it's slower than an install of similar size
> would be on legacy hardware.
>


Installing FreeDOS on the Raspberry Pi will take a long time regardless of
what options you use in QEMU. It's because of the high disk I/O when you
install an operating system like FreeDOS. It's made worse by doing it
inside an emulator, but the biggest slowdown when *installing* is the
storage device on the Raspberry Pi.

My RPi3B has a SanDisk Ultra 64GB microSDXC UHS-I U1A1 card. The U1 is
designed to support 1080p video recording (such as you might use in a GoPro
camera) at minimum serial write speeds of 10MB/s. By comparison, a V60 is
aimed at cameras that do 4K video and has a minimum sequential write speed
of 60MB/s. Using a V60 microSD card or even a V30 (30MB/s) would probably
give noticeably better disk I/O performance (up to 3x faster).


Jim
___
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

[Ralf Quint]

On 3/18/2020 10:34 AM, Jim Hall wrote:

My *dmesg* output shows it is a plain Raspberry Pi 3B:
[ 0.00] OF: fdt: Machine model: Raspberry Pi 3 Model B


My RPi4B+ shows


[    0.00] Booting Linux on physical CPU 0x0
[    0.00] Linux version 4.19.97-v7l+ (dom@buildbot) (gcc version 
4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1294 SMP Thu 
Jan 30 13:21:14 GMT 2020
[    0.00] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), 
cr=30c5383d

[    0.00] CPU: div instructions available: patching division code
[    0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT 
instruction cache

[    0.00] OF: fdt: Machine model: Raspberry Pi 4 Model B Rev 1.1




Not that it matters for me. I used it as a "desktop" system for about 
a week, as an experiment, before I reinstalled it with Fedora ARM 
Server 30 and used it as a mini-server for our house. It's a print 
server, an SSH-based file server, and a web server that I use to 
develop websites.


That's what my RPi4B+ now does too, though I am running Apache and MySQL 
for testing web sites and I am about to use it as a test bed for some 
email server trials in the next few days. Running this on the default 
Raspbian though, as I am also playing with cross-platform development 
using FreePascal/Lazarus on it...


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

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

[Jim Hall]

My *dmesg* output shows it is a plain Raspberry Pi 3B:

[0.00] OF: fdt: Machine model: Raspberry Pi 3 Model B


Not that it matters for me. I used it as a "desktop" system for about a
week, as an experiment, before I reinstalled it with Fedora ARM Server 30
and used it as a mini-server for our house. It's a print server, an
SSH-based file server, and a web server that I use to develop websites.




On Wed, Mar 18, 2020 at 12:06 PM Ralf Quint  wrote:

> On 3/18/2020 9:44 AM, Jim Hall wrote:
>
> Actually, I think it's a problem on the Raspberry Pi 4. I've heard from a
> few folks since the RPi4 came out that my how-to about running FreeDOS on
> the Raspberry Pi (via QEMU)
>  results
> in a very slow FreeDOS. But I've only heard from people about the Raspberry
> Pi 4. The RPi3 seems to work okay. I have a Raspberry Pi 3, and it works
> fine. I've run my RPi3 with both Raspbian and Fedora ARM with the same
> results, so I don't think it's a distro issue, either.
>
> The Raspberry Pi (as lease version 3) is fast enough to emulate a '486 or
> Pentium CPU well enough to run DOOM and AsEasyAs and other DOS games and
> applications without lag.
>
> Well, what kind of Raspberry Pi3 do you have? A "plain" 3B or a 3B+?
>
> The 3B+ has a 1.4GHz Cortex-A53 CPU, while the 4B+ has a 1.5GHz Cortex-A72
> CPU. And given that a 4B+ is on average 4x as fast as a 3B+, with only
> 0.1GHz difference in clock speed, there could be that QEMU just isn't using
> the 4B+ CPU properly.
>
> I haven't run QEMU on my RPi4B+ (beside that it is sitting off-site at a
> client right now) but everything I tested with it, in the way I intended to
> use it, it was a significantly, noticeable difference. So from the plain
> capabilities of the 4B+, there should be no reason why it would be so slow
> in QEMU.
>
> Well, the GPU part of the SoC chip could of course be culprit here, now
> that the 4B+ by default supports a two monitors. Can someone run a
> "speedtest" between a 3B+ and a 4B+ with an application that doesn't use
> any screen output to possibly verify this?
>
> Ralf
>
> PS: FWIW, I have not been able to run WCG via BOINC on the RPi4B+, getting
> the message that the project doesn't have any work units for computers of
> the type "arm-unknown-linux-gnueabihf", while it was running just fine on
> my RPi3B+.
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-5205383049343504348_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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 is slow in Raspberry 4

[Ralf Quint]

On 3/18/2020 10:02 AM, Swap Jim via Freedos-user wrote:


And in the meantime I'll try Fedora ARM, just in case it matters on 
the RPi4. 
FAIK, Rasbian is the best supported distro on the RPi4B+ (hardware 
wise). And beside that Raspberry.org itself otherwise only promotes 
Ubuntu. Fedora/Pidora was dropped at least a couple of years ago, so I 
am not sure that you will be able to yield any better results using an 
ARM based Fedora.


I still think that the problem is that QEMU doesn't take into account 
the new capabilities of the 4B+ over the 3B+, not only CPU wise, but 
also video (4K dual screen vs 1080p single), USB (3.0 vs 2.0) and 
networking (true Gigabit Ethernet vs Gigiabit over USB 2.0, limited to 
300MBit/sec), and defaults (at least for the video part, maybe) to a 
lower performing generic "fallback" mode.


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

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

[Ralf Quint]

On 3/18/2020 9:44 AM, Jim Hall wrote:
Actually, I think it's a problem on the Raspberry Pi 4. I've heard 
from a few folks since the RPi4 came out that my how-to about running 
FreeDOS on the Raspberry Pi (via QEMU) 
 results 
in a very slow FreeDOS. But I've only heard from people about the 
Raspberry Pi 4. The RPi3 seems to work okay. I have a Raspberry Pi 3, 
and it works fine. I've run my RPi3 with both Raspbian and Fedora ARM 
with the same results, so I don't think it's a distro issue, either.


The Raspberry Pi (as lease version 3) is fast enough to emulate a '486 
or Pentium CPU well enough to run DOOM and AsEasyAs and other DOS 
games and applications without lag.


Well, what kind of Raspberry Pi3 do you have? A "plain" 3B or a 3B+?

The 3B+ has a 1.4GHz Cortex-A53 CPU, while the 4B+ has a 1.5GHz 
Cortex-A72 CPU. And given that a 4B+ is on average 4x as fast as a 3B+, 
with only 0.1GHz difference in clock speed, there could be that QEMU 
just isn't using the 4B+ CPU properly.


I haven't run QEMU on my RPi4B+ (beside that it is sitting off-site at a 
client right now) but everything I tested with it, in the way I intended 
to use it, it was a significantly, noticeable difference. So from the 
plain capabilities of the 4B+, there should be no reason why it would be 
so slow in QEMU.


Well, the GPU part of the SoC chip could of course be culprit here, now 
that the 4B+ by default supports a two monitors. Can someone run a 
"speedtest" between a 3B+ and a 4B+ with an application that doesn't use 
any screen output to possibly verify this?


Ralf

PS: FWIW, I have not been able to run WCG via BOINC on the RPi4B+, 
getting the message that the project doesn't have any work units for 
computers of the type "arm-unknown-linux-gnueabihf", while it was 
running just fine on my RPi3B+.





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

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

[Swap Jim via Freedos-user]

So it's feasible! That's great news! A 486 or Pentium would be great!

Can you give me the links for these discussions? I'll visiting them in 
hope that maybe someone in the future might have found a solution.


And in the meantime I'll try Fedora ARM, just in case it matters on the 
RPi4.


Just some fun background: This is a project to create a dedicated DOS 
computer (it'll boot Linux and then straight to QEMU and FreeDOS) to use 
as a place to calm down and be more productive. And play classic games ;-)


On 2020-03-18 18:44, Jim Hall wrote:
Actually, I think it's a problem on the Raspberry Pi 4. I've heard from 
a few folks since the RPi4 came out that my how-to about running FreeDOS 
on the Raspberry Pi (via QEMU) 
 results 
in a very slow FreeDOS. But I've only heard from people about the 
Raspberry Pi 4. The RPi3 seems to work okay. I have a Raspberry Pi 3, 
and it works fine. I've run my RPi3 with both Raspbian and Fedora ARM 
with the same results, so I don't think it's a distro issue, either.


The Raspberry Pi (as lease version 3) is fast enough to emulate a '486 
or Pentium CPU well enough to run DOOM and AsEasyAs and other DOS games 
and applications without lag.


On Wed, Mar 18, 2020 at 11:17 AM Ralf Quint > wrote:


On 3/18/2020 6:31 AM, Swap Jim via Freedos-user wrote:
 > FreeDOS is very, very slow on QEMU running in a Raspberry 4.
 >
 > It's drawing the screen line by line when I do a DIR on C:\, with
only
 > 7 directories and files in it. It's worse in full screen.
 >
 > For those of you that run FreeDOS on a Raspberry, can you offer a
tip
 > to make it go faster?
 >
 > Here is some more info.
 >
 > It's a Raspberry Pi 4 B+ with 4GB of RAM. I'm running the latest
 > Raspbian. I couldn't manage to install QEMU from apt, so I've
compiled
 > version 4.2.0 with these flags:
 >
 >   ./configure --target-list=i386-softmmu --disable-vnc --enable-sdl
 >   make 'CFLAGS=-Wall -g -O2 -w'

That is a problem of QEMU, not FreeDOS.

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.

This is a complete different situation for example than emulating a
16bit x86 PC system on a 64bit x86 host system, like running DOSBox or
VirtualBox. While the later doesn't (in 64bit mode) support 16bit
operation anymore, it is still the same basic underlying CPU
architecture, and the same data "endian-ness".

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] FreeDOS is slow in Raspberry 4

[Jim Hall]

Actually, I think it's a problem on the Raspberry Pi 4. I've heard from a
few folks since the RPi4 came out that my how-to about running FreeDOS on
the Raspberry Pi (via QEMU)
 results
in a very slow FreeDOS. But I've only heard from people about the Raspberry
Pi 4. The RPi3 seems to work okay. I have a Raspberry Pi 3, and it works
fine. I've run my RPi3 with both Raspbian and Fedora ARM with the same
results, so I don't think it's a distro issue, either.

The Raspberry Pi (as lease version 3) is fast enough to emulate a '486 or
Pentium CPU well enough to run DOOM and AsEasyAs and other DOS games and
applications without lag.

On Wed, Mar 18, 2020 at 11:17 AM Ralf Quint  wrote:

> On 3/18/2020 6:31 AM, Swap Jim via Freedos-user wrote:
> > FreeDOS is very, very slow on QEMU running in a Raspberry 4.
> >
> > It's drawing the screen line by line when I do a DIR on C:\, with only
> > 7 directories and files in it. It's worse in full screen.
> >
> > For those of you that run FreeDOS on a Raspberry, can you offer a tip
> > to make it go faster?
> >
> > Here is some more info.
> >
> > It's a Raspberry Pi 4 B+ with 4GB of RAM. I'm running the latest
> > Raspbian. I couldn't manage to install QEMU from apt, so I've compiled
> > version 4.2.0 with these flags:
> >
> >   ./configure --target-list=i386-softmmu --disable-vnc --enable-sdl
> >   make 'CFLAGS=-Wall -g -O2 -w'
>
> That is a problem of QEMU, not FreeDOS.
>
> 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.
>
> This is a complete different situation for example than emulating a
> 16bit x86 PC system on a 64bit x86 host system, like running DOSBox or
> VirtualBox. While the later doesn't (in 64bit mode) support 16bit
> operation anymore, it is still the same basic underlying CPU
> architecture, and the same data "endian-ness".
>
> 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

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

[Ralf Quint]

On 3/18/2020 6:31 AM, Swap Jim via Freedos-user wrote:

FreeDOS is very, very slow on QEMU running in a Raspberry 4.

It's drawing the screen line by line when I do a DIR on C:\, with only 
7 directories and files in it. It's worse in full screen.


For those of you that run FreeDOS on a Raspberry, can you offer a tip 
to make it go faster?


Here is some more info.

It's a Raspberry Pi 4 B+ with 4GB of RAM. I'm running the latest 
Raspbian. I couldn't manage to install QEMU from apt, so I've compiled 
version 4.2.0 with these flags:


  ./configure --target-list=i386-softmmu --disable-vnc --enable-sdl
  make 'CFLAGS=-Wall -g -O2 -w' 


That is a problem of QEMU, not FreeDOS.

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.


This is a complete different situation for example than emulating a 
16bit x86 PC system on a 64bit x86 host system, like running DOSBox or 
VirtualBox. While the later doesn't (in 64bit mode) support 16bit 
operation anymore, it is still the same basic underlying CPU 
architecture, and the same data "endian-ness".


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

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

[joseph.norton]

Hi: 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? I just booted into FreeDOS and it worked ok.  Pressing /l told me I was on line 25 and read the DOS prompt. If I press return, it says “enter” and repeats the DOS prompt. Not sure what’s going on on your end.

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

[Freedos-user] Why I chose ASAP in my custom distro build

[joseph.norton]

Hi: Here's why I chose to include ASAP in my custom distro. It is true that the licensing model for Provox is probably the most compatible, as far as the distribution of packages with FreeDOS is concerned. Unfortunately, Provox's manual is sparse, to say the least. It's got the bare minimum, and, it throws around its terminology, such as the term "screen bank" without really explaining it, or, at least, you do get some explanation, but, you have to read through the manual. Version 6.71 is also available at: http://www.nfbnet.org/files/blind/PRVX671B.ZIP but, the source is not present in that package. Source is present in the v6.6 package here: http://www.nfbnet.org/files/blind/PROVOX66.ZIP I'm not sure what the differences in versions are, the only one that immediately jumped out at me was that the prefix key (slash) can now be assigned to either the Accent "`" key or the Escape key, whereas in version 6.6, you couldn't use the Escape key. This is another shortcoming of Provox.  The use of a prefix key is not bad, but, putting it on a key like the Slash is going to throw a user if he has just installed Provox and decides to do a dir /b or something like that. JAWS, on the other hand, is freeware and I even have the original "jdosfree.exe" self-extracting file with PKWare's authenticity verification from Henter-Joyce.  However, JAWS, I think, may use the most memory and I'm told uses a lot of overlays, so that can be a shortcoming. ASAP, while not released under GPL seems to be the best of both worlds.  I still couldn't free enough memory to load it high, though I didn't try too hard yet. It's author, Larry Skutchan gave me permission to include it in my package, though I don't know how he would feel if it were built into the main distro as an option.  It would be nice, because ASAP has an excellent manual and many loyal users. ASAP, also imho, has been the best overall experience I ever had with a DOS screen reader.  ASAP is constantly examining the screen to see if anything changes and alerts the user by reading the change.  While many screen readers can be customized, if one knows the row and column to expect certain changes, ASAP has consistently given me enough information to be able to figure my way around a lot of applications without resorting to writing complicated configuration files.  The capability is there, but, I have rarely had to use it.  ASAP has just worked for me over the close to 30 years I've used it, rather than me working for it. Cheers! Sent from Mail for Windows 10 From: joseph.nor...@gmail.comSent: Wednesday, March 18, 2020 11:05 AMTo: Discussion and general questions about FreeDOS.Subject: RE: Re: [Freedos-user] Introducing myself, and inquiring about using FreeD OS as a blind user Hi:  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,  Provox does work, but to install it you do two things. First, you need to run the provox.exe tsr. You can run it in fdconfig.sys, and if you do it after the memory manager loads, it will load high automatically. Or, you can put provox.exe in the fdauto.bat. You would need to do an lh on that to load it high. 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 I think bns defaults to com1, but, you can put a space and com1 after the bns perameter. 

___
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

[joseph.norton]

Hi:  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,  Provox does work, but to install it you do two things. First, you need to run the provox.exe tsr. You can run it in fdconfig.sys, and if you do it after the memory manager loads, it will load high automatically. Or, you can put provox.exe in the fdauto.bat. You would need to do an lh on that to load it high. 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 I think bns defaults to com1, but, you can put a space and com1 after the bns perameter.

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

[Freedos-user] FreeDOS is slow in Raspberry 4

[Swap Jim via Freedos-user]

FreeDOS is very, very slow on QEMU running in a Raspberry 4.

It's drawing the screen line by line when I do a DIR on C:\, with only 7 
directories and files in it. It's worse in full screen.


For those of you that run FreeDOS on a Raspberry, can you offer a tip to 
make it go faster?


Here is some more info.

It's a Raspberry Pi 4 B+ with 4GB of RAM. I'm running the latest 
Raspbian. I couldn't manage to install QEMU from apt, so I've compiled 
version 4.2.0 with these flags:


  ./configure --target-list=i386-softmmu --disable-vnc --enable-sdl
  make 'CFLAGS=-Wall -g -O2 -w'



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

I'd also like to add that when I speak of a battle, I am in no way
referring to a battle against anyone here, or any FreeDOS developer.
The rather military term was strictly in reference to the effort of
overcoming or circumventing technical limitations.
Best,
Felix

Am Mi., 18. März 2020 um 10:22 Uhr schrieb Felix G.
:
>
> Hello everyone,
> I'd like to report that I got FreeDOS to work, and speak to me, from a
> virtual machine using a speech synthesizer emulator on the host,
> thanks to Joseph's kind help in the form of valuable advice and a
> great live image with ASAP. I was also able to get files into the VM
> by converting a folder to an iso then mounting that as a virtual
> CD-ROM. Still moderately convoluted, as I am the first to admit.
> Karen, I agree with you, based on first principles, that every
> operating system should be accessible out of the box. However, given
> the nature of FreeDOS, I currently don't see any viable way of
> accomplishing this. Mind you, I want it to happen, and I have already
> joined you in this battle by doing research, I just haven't figured
> out how. On a related note, I like your style of advocacy for the
> blind, especially your emphasis on individual preferences, freedom of
> choice, and avoidance of unnecessary categorization.
> Best,
> Felix
>
> Am Mi., 18. März 2020 um 08:57 Uhr schrieb 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


___
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'd like to report that I got FreeDOS to work, and speak to me, from a
virtual machine using a speech synthesizer emulator on the host,
thanks to Joseph's kind help in the form of valuable advice and a
great live image with ASAP. I was also able to get files into the VM
by converting a folder to an iso then mounting that as a virtual
CD-ROM. Still moderately convoluted, as I am the first to admit.
Karen, I agree with you, based on first principles, that every
operating system should be accessible out of the box. However, given
the nature of FreeDOS, I currently don't see any viable way of
accomplishing this. Mind you, I want it to happen, and I have already
joined you in this battle by doing research, I just haven't figured
out how. On a related note, I like your style of advocacy for the
blind, especially your emphasis on individual preferences, freedom of
choice, and avoidance of unnecessary categorization.
Best,
Felix

Am Mi., 18. März 2020 um 08:57 Uhr schrieb 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


___
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] Zip 750 Atapi and freedos...

[Rugxulo]

Hi,

On Mon, Mar 16, 2020 at 4:29 PM  wrote:
>
> As freedos is not designed to support USB, USB floppy will not work.

I have a USB floppy drive. I'm pretty sure it's handled okay by the
BIOS. But I haven't used it in recent years much.

P.S. I believe Haiku (OS), allegedly, also had support for USB floppy
drive implemented because one of their developers needed it. So you
could maybe try booting that, temporarily??


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