Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

2023-03-07 Thread Volkert via Freedos-devel 
You might want to take a look at the VMusic project by javispedro
. It's an
open-soure extension pack for VirtualBox that enhances sound emulation
support, notably adding high quality OPL3 FM synthesis emulation and
MPU-401 emulation with MIDI passthrough to the host. It only supports Linux
hosts, though. Perhaps this extension pack could be further improved by
having it include an alternative SB16 emulation option that would implement
the fixes suggested in that VirtualBox ticket.

On Fri, Jan 27, 2023 at 6:24 PM Ben Collver  wrote:

> On Fri, 27 Jan 2023 at 16:42, tom ehlert  wrote:
>
> > any reason you don't download VirtualBox for your platform, select
>
> > proper devices (there is even a Soundblaster16 emulated), install DOS
>
> > on it and go.
>
> VirtualBox SoundBlaster16 emulation doesn't actually work with DOS.
> VirtualBox developers have gaslit DOS users about this in their forum.  It
> is a known problem and VirtualBox developers rejected fixes for it.  For
> technical details, see the following support ticket.
>
> https://www.virtualbox.org/ticket/14883
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

2023-01-30 Thread Liam Proven 
On Sun, 29 Jan 2023 at 14:00, Wilhelm Spiegl  wrote:
>
> Ehhm? Use vhd format supported in win ( except home edition )

That's not the native VirtualBox format, is it? I don't think so.

Anyway, I am talking about FOSS OSes here. I don't run Windows.

> with virtualbox and you can simply mount the vhd by getting a drive letter.

Never tried. I don't use it except occasionally for BIOS flashing.

> If this is to complicated, install imdisk on vhd/vdi, maybe others too, and a 
> right mouse click does the job when the vm is off. unmount with another right 
> mouse click.

Also a Windows tool; no help to me.

> Mounting also works in Linux, but there may be problems with space in 
> file/foldername.

I've managed to not only mount but also convert between formats, and
spaces in names weren't a problem, but this seems a clumsy way to do
it to me TBH. I want to just mount a shared folder on the host PC, as
DOSemu or DOSbox do.

-- 
Liam Proven ~ Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053


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

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

2023-01-29 Thread Jim Hall 
> On Fri, 27 Jan 2023 at 15:54, tom ehlert  wrote:
> > most people around here already have a working machine, most likely
> > Windows or Linux.
>

On Sun, Jan 29, 2023 at 5:21 AM Liam Proven  wrote:
> Are these people the target market for FreeDOS?
>
> Is there an overlap between this demographic and the users?
>

According to the results from the August 2021 user survey: yes, there
is an overlap with Windows and Linux users.

http://wiki.freedos.org/wiki/index.php/Survey/2021

We're seeing a lot of people who want to use FreeDOS casually. They
already have a primary machine running some other operating system,
and they want to use FreeDOS to play DOS games and do other DOS stuff.
Many of these users want to run FreeDOS in a virtual machine like
VirtualBox.

What's interesting to me is how many FreeDOS users have little (or no)
DOS experience. I had mis-remembered this as bi-modal, but the results
chart shows several "plateaus" at "beginner" and "moderate" and
"expert." My interpretation is that a lot of FreeDOS users are like
us: they used DOS in the 1980s and 1990s, and they're playing around
in FreeDOS. DOS isn't new to these people. Some of these people run
FreeDOS on real hardware, such as the vintage computing crowd that
restores Pentium computers (or older, like the PC 5150 or PC XT or PC
AT) and want to run FreeDOS on it. But my gut feeling is the vintage
computing folks are a minority to the other folks who choose to run
FreeDOS in a virtual machine like VirtualBox or PCem or QEMU, or
whatever.

But we also have a number of users who aren't very familiar with DOS.
Based on the "help me" emails I sometimes get, I think many of these
people are college students who probably heard about FreeDOS in a
computer science class. Some are probably people who read about
FreeDOS in an article somewhere (like on The Register, or
Opensource.com, etc.) and want to try it out. These people don't know
DOS and are new to it - they would prefer to run FreeDOS in a virtual
machine, not re-install their primary operating system with FreeDOS.


Tom wrote:
> > any reason you don't download VirtualBox for your platform, select
> > proper devices (there is even a Soundblaster16 emulated), install DOS
> > on it and go.
>

Liam wrote:
> Ever tried? I have and I wrote up the result.
>
> The main reason is that it's extremely hard to get any communications
> between the host and the guest. If you download DOS apps it is very
> difficult to get them into the VM, or any files you create out again.

There isn't a "live" filesystem communication back to the host OS in a
full Virtual Machine, to be sure. A PC Emulator is more likely to
provide this.

It is possible to exchange files with the VM, but only when it is in
the "off" state. I do this on Linux using command line tools, but I
know others have done it using the GUI (I'm a command line guy).

I find the easiest way via the command line (Linux) is to use
guestmount. I wrote a "how-to" article about it:

https://opensource.com/article/21/6/copy-files-linux-freedos


I'll add that if you have a QEMU disk image with FreeDOS on it, you
can easily access it from Linux/GNOME by right-clicking on the "img"
file, then clicking "Open with Disk Image Mounter." You can also
associate the "img" file extension with this action. On Fedora Linux,
the default action for "img" files is to use the Disk Image Writer
(easy to change when using the "Open with.." menu).


Jim


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

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

2023-01-29 Thread Liam Proven 
On Fri, 27 Jan 2023 at 15:54, tom ehlert  wrote:
>
> Hi,
>
> most people around here already have a working machine, most likely
> Windows or Linux.

Are these people the target market for FreeDOS?

Is there an overlap between this demographic and the users?

> any reason you don't download VirtualBox for your platform, select
> proper devices (there is even a Soundblaster16 emulated), install DOS
> on it and go.

Ever tried? I have and I wrote up the result.

The main reason is that it's extremely hard to get any communications
between the host and the guest. If you download DOS apps it is very
difficult to get them into the VM, or any files you create out again.

So in fact DOSbox is a better tool for this, and DOSbox is a rival to
FreeDOS: it includes its own DOS emulator and its users don't need
FreeDOS.

(Which is why I've been urging support for DOSemu 2, but that's an
aside. And it has its own DOS now anyway.)

> VirtualBox isn't perfect, but probably much better then 'UEFI, virtual
> BIOS and virtual hardware' will ever dream to be.

Not at all.

I submit that several core FreeDOS use cases are not covered by any VM:
* BIOS flashing
* Access to parallel-port devices
* Access to ISA devices
* Emergency diagnostics booted from removable media

> And it's probably getting better over time.

Not for any of these reasons I've given it isn't, no. In fact it's
getting worse as the host OS requirements increase.


-- 
Liam Proven ~ Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053


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

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

2023-01-27 Thread tom ehlert 
Hallo Herr Ben Collver,

am Freitag, 27. Januar 2023 um 18:23 schrieben Sie:

> On Fri, 27 Jan 2023 at 16:42, tom ehlert  wrote:

>> any reason you don't download VirtualBox for your platform, select   
>>
>> proper devices (there is even a Soundblaster16 emulated), install DOS
>>
>> on it and go.

> VirtualBox SoundBlaster16 emulation doesn't actually work with DOS.
> VirtualBox developers have gaslit DOS users about this in their
> forum.  It is a known problem and VirtualBox developers rejected
> fixes for it.  For technical details, see the following support ticket.

> https://www.virtualbox.org/ticket/14883

this is probably true. but fixing the VirtualBox SoundBlaster16 emulation
is several orders of magnitude easier then building your own SoundBlaster16 
emulation
on top of UEFI.

Tom




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

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

2023-01-27 Thread Ben Collver 
On Fri, 27 Jan 2023 at 16:42, tom ehlert  wrote:

> any reason you don't download VirtualBox for your platform, select
>   
> proper devices (there is even a Soundblaster16 emulated), install DOS 
>   
> on it and go.

VirtualBox SoundBlaster16 emulation doesn't actually work with DOS.  VirtualBox 
developers have gaslit DOS users about this in their forum.  It is a known 
problem and VirtualBox developers rejected fixes for it.  For technical 
details, see the following support ticket.

https://www.virtualbox.org/ticket/14883

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

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

2023-01-27 Thread tom ehlert 
Hi,

most people around here already have a working machine, most likely
Windows or Linux.

any reason you don't download VirtualBox for your platform, select
proper devices (there is even a Soundblaster16 emulated), install DOS
on it and go.

VirtualBox isn't perfect, but probably much better then 'UEFI, virtual
BIOS and virtual hardware' will ever dream to be.
And it's probably getting better over time.

Tom




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

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

2023-01-26 Thread Ivan Ivanov 
Louis, yes it would be great if coreboot supported more machines...
But you probably understand that it's not a coreboot's fault that the
choice isn't wide enough - instead, it's the fault of the modern
electronics world which becomes more proprietary-inclined and
telemetry (aka spying) -inclined.

But the problem isn't that big: if your old motherboard doesn't
support coreboot, there is always an option to sell it and buy another
supporting one - for peanuts, because of its age. And, by switching to
coreboot, you get a lot: i.e. the many years of free BIOS updates &
improvements (+ unlike the proprietary ones which are quickly
abandoned by corporations) and cool features not found in proprietary
BIOSes - such as this "virtual floppy inside a BIOS" miracle.

Also, I'd like to clarify that the coreboot firmware does not pose any
risk for the hardware: any "bricking" of hardware, caused by the
installation of incorrectly configured coreboot ROM, is temporary -
and easily recoverable by replacing it either with a good coreboot
ROM; or to the proprietary BIOS ROM in the worst case - but the people
rarely have to resort to that, because the coreboot community is
really helpful. So many people, even those who aren't really tech
literate (but had a strong determination in switching to coreboot,
i.e. security considerations) - were able to switch to coreboot with
the community's help, and I personally helped many people free of
charge.

P.S. By the way, if you would like to switch to coreboot opensource
BIOS yourself, I'm ready to provide you an exceptional support (free
of charge of course!) for any of these 3 motherboards which I own:
Lenovo G505S (laptop with A10-5750M CPU, up to 16GB of RAM and working
IOMMU), ASUS A88XM-E (desktop with A10-6800K/A10-6700 CPU which is
equally good) and AM1I-A (micro desktop with Athlon 5370 but no IOMMU)

^^^ All these coreboot-supported AMD platforms:
1) don't have AMD PSP backdoor (an equivalent of Intel ME backdoor)
2) aren't affected by 20+ Intel-only vulnerabilities like Meltdown
(for which the performance crippling patches are required and i.e.
even have to disable a hyper threading)
3) are perfectly suitable even for the demanding modern computing
(even able to handle the multiple virtual machines simultaneously
running, etc.)

So, if you'd like yourself a perfect opensource BIOS (and super-secure
PC in general) , and not ever be at mercy of corporations for those
BIOS updates - this is your chance ;-)

ср, 25 янв. 2023 г. в 18:33, Louis Santillan :
>
> This would be ideal if coreboot supported more machines 
> (https://coreboot.org/status/board-status.html).  I believe you did some work 
> some years back to prove out cooreboot+SeaBIOS+FreeDOS.  I’m not sure a 
> typical user or even experienced FreeDOS users would be keen to swapping out 
> their board’s firmware for a heavily customized solution that could also 
> brick their hardware.
>
> On Wed, Jan 25, 2023 at 2:32 AM Ivan Ivanov  wrote:
>>
>> Friends, the final solution to "UEFI problem" - is switching to the
>> opensource coreboot BIOS (although that may involve switching to the
>> worthy hardware compatible with coreboot). coreboot's default payload
>> - SeaBIOS - is a modern implementation of a classical BIOS, which is
>> written in C and is more refined in general. Moreover, you can even
>> take a FreeDOS virtual floppy and put it inside your coreboot+SeaBIOS
>> ROM's free place of a BIOS chip - and it will be permanently available
>> as a boot entry of your system. Efficient and simple, and don't have
>> to deal with the problems of UEFI crapware that has been coded for a
>> bowl of rice
>>
>> 2023-01-24 23:38 GMT+03:00, Steve Nickolas :
>> > On Tue, 24 Jan 2023, Bret Johnson wrote:
>> >
>> >> For purposes we're discussing here, I don't think DOSBox (or any of its
>> >> forks, including vDOS) is a viable solution.
>> >>
>> >> DOSBox really isn't DOS.  It's an environment designed to run certain
>> >> DOS applications.  A lot of stuff is missing in DOSBox that's needed to
>> >> make it a "real enough" DOS to be used for development and testing.
>> >> E.g., a lot of the internal structures that some DOS "extenders" need to
>> >> look at (like certain TSRs and Device Drivers) simply don't exist on
>> >> DOSBox.
>> >>
>> >> A perfect example of this are the "standard" DOS Devices: NUL, CON,
>> >> COM1-COM4, AUX, LPT1-LPT3, PRN, and CLOCK$.  In DOSBox, the only two
>> >> that exist in a form where other programs can "see" them using standard
>> >> methods (by scanning through the linked list of Device Driver addresses)
>> >> are NUL and CON.
>> >>
>> >> Things like that can cause lots of problems in certain situations.
>> >
>> > Though the hardware emulation may be useful, it would be better for such a
>> > situation to use that as a base to run an actual DOS on.
>> >
>> > -uso.
>> >
>> >
>> > ___
>> > Freedos-devel mailing list
>> > Freedos-devel@lists.sourceforge.net

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware

2023-01-25 Thread Aitor Santamaría 
Thanks, these work!

Aitor

On Wed, 25 Jan 2023 at 21:46, Robert Riebisch  wrote:

> Hi Aitor,
>
> > Both links give me a 404, maybe a problem with pasting?
>
> https://dosbox-x.com/wiki/Guide%3ADOS-Installation-in-DOSBox%E2%80%90X
> https://dosbox-x.com/wiki/Guide%3AManaging-image-files-in-DOSBox%E2%80%90X
>
> Cheers,
> Robert
> --
> BTTR Software   https://www.bttr-software.de/
> DOS ain't dead  https://www.bttr-software.de/forum/
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware

2023-01-25 Thread Robert Riebisch 
Hi Aitor,

> Both links give me a 404, maybe a problem with pasting?

https://dosbox-x.com/wiki/Guide%3ADOS-Installation-in-DOSBox%E2%80%90X
https://dosbox-x.com/wiki/Guide%3AManaging-image-files-in-DOSBox%E2%80%90X

Cheers,
Robert
-- 
BTTR Software   https://www.bttr-software.de/
DOS ain't dead  https://www.bttr-software.de/forum/


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

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware

2023-01-25 Thread Aitor Santamaría 
Hello Ben,

Both links give me a 404, maybe a problem with pasting?

Aitor


On Wed, 25 Jan 2023 at 18:21, Ben Collver  wrote:

> On Tue, 24 Jan 2023, Bret Johnson wrote:
>
>
>
> > For purposes we're discussing here, I don't think DOSBox (or any of its
>
> > forks, including vDOS) is a viable solution.
>
> >
>
> > DOSBox really isn't DOS.  It's an environment designed to run certain
>
> > DOS applications.  A lot of stuff is missing in DOSBox that's needed to
>
> > make it a "real enough" DOS to be used for development and testing.
>
> > E.g., a lot of the internal structures that some DOS "extenders" need to
>
> > look at (like certain TSRs and Device Drivers) simply don't exist on
>
> > DOSBox.
>
> You can install FreeDOS in DOSBox.  See the links below for more details.
> In my experience qemu and VirtualBox are not really geared toward
> supporting DOS and they have annoying BIOS bugs that are not present in
> DOSBox.  So while FreeDOS runs more quickly in qemu and VirtualBox, it runs
> more accurately in DOSBox-X.
>
>
> https://dosbox-x.com/wiki/Guide%253ADOS-Installation-in-DOSBox%25E2%2580%2590X
>
>
> https://dosbox-x.com/wiki/Guide%253AManaging-image-files-in-DOSBox%25E2%2580%2590X
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware

2023-01-25 Thread Bernd Boeckmann via Freedos-devel 
> You can install FreeDOS in DOSBox.  See the links below for more details.  In 
> my experience qemu and VirtualBox are not really geared toward supporting DOS 
> and they have annoying BIOS bugs that are not present in DOSBox.  So while 
> FreeDOS runs more quickly in qemu and VirtualBox, it runs more accurately in 
> DOSBox-X.

I can confirm that. At least VirtualBox 7.0.4 is dice rolling CHS values for my 
virtual disks. Reboot, and you get a different CHS geometry :-/

That said, BIOS INT 13h emulation of DosBox is also not complete. For example, 
INT13h, function 44h verify sectors,  is not implemented. But all in all seems 
to be less buggy than VirtualBox.

As a side note: I use DosBox hosted under Mac for hacking on Ranish (testing 
with different virtual disks, compiling with Watcom C) and so far it is working 
great. Then I copy program versions running stable on DosBox onto my physical 
machine running FreeDOS for further testing.

Bernd



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

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware

2023-01-25 Thread Ben Collver 
On Tue, 24 Jan 2023, Bret Johnson wrote:

> For purposes we're discussing here, I don't think DOSBox (or any of its
> forks, including vDOS) is a viable solution.
>
> DOSBox really isn't DOS.  It's an environment designed to run certain
> DOS applications.  A lot of stuff is missing in DOSBox that's needed to
> make it a "real enough" DOS to be used for development and testing.
> E.g., a lot of the internal structures that some DOS "extenders" need to
> look at (like certain TSRs and Device Drivers) simply don't exist on
> DOSBox.

You can install FreeDOS in DOSBox.  See the links below for more details.  In 
my experience qemu and VirtualBox are not really geared toward supporting DOS 
and they have annoying BIOS bugs that are not present in DOSBox.  So while 
FreeDOS runs more quickly in qemu and VirtualBox, it runs more accurately in 
DOSBox-X.

https://dosbox-x.com/wiki/Guide%253ADOS-Installation-in-DOSBox%25E2%2580%2590X

https://dosbox-x.com/wiki/Guide%253AManaging-image-files-in-DOSBox%25E2%2580%2590X
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

2023-01-25 Thread Louis Santillan 
This would be ideal if coreboot supported more machines (
https://coreboot.org/status/board-status.html).  I believe you did some
work some years back to prove out cooreboot+SeaBIOS+FreeDOS.  I’m not sure
a typical user or even experienced FreeDOS users would be keen to swapping
out their board’s firmware for a heavily customized solution that could
also brick their hardware.

On Wed, Jan 25, 2023 at 2:32 AM Ivan Ivanov  wrote:

> Friends, the final solution to "UEFI problem" - is switching to the
> opensource coreboot BIOS (although that may involve switching to the
> worthy hardware compatible with coreboot). coreboot's default payload
> - SeaBIOS - is a modern implementation of a classical BIOS, which is
> written in C and is more refined in general. Moreover, you can even
> take a FreeDOS virtual floppy and put it inside your coreboot+SeaBIOS
> ROM's free place of a BIOS chip - and it will be permanently available
> as a boot entry of your system. Efficient and simple, and don't have
> to deal with the problems of UEFI crapware that has been coded for a
> bowl of rice
>
> 2023-01-24 23:38 GMT+03:00, Steve Nickolas :
> > On Tue, 24 Jan 2023, Bret Johnson wrote:
> >
> >> For purposes we're discussing here, I don't think DOSBox (or any of its
> >> forks, including vDOS) is a viable solution.
> >>
> >> DOSBox really isn't DOS.  It's an environment designed to run certain
> >> DOS applications.  A lot of stuff is missing in DOSBox that's needed to
> >> make it a "real enough" DOS to be used for development and testing.
> >> E.g., a lot of the internal structures that some DOS "extenders" need to
> >> look at (like certain TSRs and Device Drivers) simply don't exist on
> >> DOSBox.
> >>
> >> A perfect example of this are the "standard" DOS Devices: NUL, CON,
> >> COM1-COM4, AUX, LPT1-LPT3, PRN, and CLOCK$.  In DOSBox, the only two
> >> that exist in a form where other programs can "see" them using standard
> >> methods (by scanning through the linked list of Device Driver addresses)
> >> are NUL and CON.
> >>
> >> Things like that can cause lots of problems in certain situations.
> >
> > Though the hardware emulation may be useful, it would be better for such
> a
> > situation to use that as a base to run an actual DOS on.
> >
> > -uso.
> >
> >
> > ___
> > Freedos-devel mailing list
> > Freedos-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-devel
> >
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

2023-01-25 Thread Ivan Ivanov 
Friends, the final solution to "UEFI problem" - is switching to the
opensource coreboot BIOS (although that may involve switching to the
worthy hardware compatible with coreboot). coreboot's default payload
- SeaBIOS - is a modern implementation of a classical BIOS, which is
written in C and is more refined in general. Moreover, you can even
take a FreeDOS virtual floppy and put it inside your coreboot+SeaBIOS
ROM's free place of a BIOS chip - and it will be permanently available
as a boot entry of your system. Efficient and simple, and don't have
to deal with the problems of UEFI crapware that has been coded for a
bowl of rice

2023-01-24 23:38 GMT+03:00, Steve Nickolas :
> On Tue, 24 Jan 2023, Bret Johnson wrote:
>
>> For purposes we're discussing here, I don't think DOSBox (or any of its
>> forks, including vDOS) is a viable solution.
>>
>> DOSBox really isn't DOS.  It's an environment designed to run certain
>> DOS applications.  A lot of stuff is missing in DOSBox that's needed to
>> make it a "real enough" DOS to be used for development and testing.
>> E.g., a lot of the internal structures that some DOS "extenders" need to
>> look at (like certain TSRs and Device Drivers) simply don't exist on
>> DOSBox.
>>
>> A perfect example of this are the "standard" DOS Devices: NUL, CON,
>> COM1-COM4, AUX, LPT1-LPT3, PRN, and CLOCK$.  In DOSBox, the only two
>> that exist in a form where other programs can "see" them using standard
>> methods (by scanning through the linked list of Device Driver addresses)
>> are NUL and CON.
>>
>> Things like that can cause lots of problems in certain situations.
>
> Though the hardware emulation may be useful, it would be better for such a
> situation to use that as a base to run an actual DOS on.
>
> -uso.
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>


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

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

2023-01-24 Thread Steve Nickolas 

On Tue, 24 Jan 2023, Bret Johnson wrote:

For purposes we're discussing here, I don't think DOSBox (or any of its 
forks, including vDOS) is a viable solution.


DOSBox really isn't DOS.  It's an environment designed to run certain 
DOS applications.  A lot of stuff is missing in DOSBox that's needed to 
make it a "real enough" DOS to be used for development and testing. 
E.g., a lot of the internal structures that some DOS "extenders" need to 
look at (like certain TSRs and Device Drivers) simply don't exist on 
DOSBox.


A perfect example of this are the "standard" DOS Devices: NUL, CON, 
COM1-COM4, AUX, LPT1-LPT3, PRN, and CLOCK$.  In DOSBox, the only two 
that exist in a form where other programs can "see" them using standard 
methods (by scanning through the linked list of Device Driver addresses) 
are NUL and CON.


Things like that can cause lots of problems in certain situations.


Though the hardware emulation may be useful, it would be better for such a 
situation to use that as a base to run an actual DOS on.


-uso.


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

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

2023-01-24 Thread Bret Johnson 
For purposes we're discussing here, I don't think DOSBox (or any of its forks, 
including vDOS) is a viable solution.

DOSBox really isn't DOS.  It's an environment designed to run certain DOS 
applications.  A lot of stuff is missing in DOSBox that's needed to make it a 
"real enough" DOS to be used for development and testing.  E.g., a lot of the 
internal structures that some DOS "extenders" need to look at (like certain 
TSRs and Device Drivers) simply don't exist on DOSBox.

A perfect example of this are the "standard" DOS Devices: NUL, CON, COM1-COM4, 
AUX, LPT1-LPT3, PRN, and CLOCK$.  In DOSBox, the only two that exist in a form 
where other programs can "see" them using standard methods (by scanning through 
the linked list of Device Driver addresses) are NUL and CON.

Things like that can cause lots of problems in certain situations.


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

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Google Summer of Code?

2023-01-23 Thread Louis Santillan 
Over the last couple years, DOSBox and DOSBoxPure in RetroPie and RetroArch
have become quite popular.

https://m.youtube.com/watch?v=LRy8brZ7DVc
https://m.youtube.com/watch?v=-mD2DnMVoLE

Consider standardizing on that.  RPis will have access via RetroPie.
There’s a version of DOSBox in the various Android stores as well.  Windows
support, Mac OS support.  For “real hardware” PCs including modern UEFI,
there’s RetroArch’s Lakka Linux distribution.  Even a lot of support for
less common SBCs.

https://www.lakka.tv/


On Mon, Jan 23, 2023 at 2:56 PM Steve Nickolas  wrote:

> On Mon, 23 Jan 2023, E. Auer wrote:
>
> 
>
> > Depending on how thin the glue and VM layer will be, you will be able
> > to run fewer or more DOS apps with it. You can run some DOS apps in
> > CTTY serial consoles if they only use int 21 for user I/O. There are
> > support modes for simple DOS apps in some boot managers which only
> > implement a few most popular bits of the DOS API to run apps directly
> > from the boot manager without an actual DOS. So why not use for example
> > real mode DOS apps without sound, with whatever is left in terms of
> > hardware text mode or maybe VGA as an already entertaining intermediate
> > milestone and keep more VGA, VESA, PC speaker, mouse, protected mode
> > apps etc. pp. for later? The "easy" solution will still be running a
> > DOS-friendly VM inside Linux or other host OS. But not the exciting
> > solution regarding technological challenge and "abstraction thinness".
> >
> > People have written hypervisors to hide malware. Porting an open BIOS
> > and some VM ingredients into a CSM and an open source "VMware ESXi"
> > competitor which runs DOS better than the commercial product does?
> > In other words, a Xen for DOS? To stay in the Xen terminology, would
> > one want a paravirtualized DOS for that? Or would one put some light
> > weight "BIOS setup" type menu into dom0 and run DOS only as client?
>
> This is kind-of what I was trying to hint at - a lightweight operating
> system that just manages the hardware and (if necessary) provides
> emulation for 16-bit apps.  I feel like even a stripped-down Linux kernel
> is extreme overkill since multitasking/multiuser isn't even useful for
> that purpose.
>
> But in this day and age where the solution to everything is "throw a
> 'Duino at it" or "throw a RasPi at it", I think too many people have lost
> the concept of simple, lightweight, minimalist software.  And that's why
> you have all the kids trying to turn FreeDOS into Linux, and Linux into
> Windows.
>
> The idea is this: provide a "volume manager"; a way to use the installed
> hardware to emulate VGA/SVGA, SB16, and the basic equipment used on DOS
> machines; and hooks to MS-DOS/FreeDOS to support stuff you're likely to
> have on a modern machine that wouldn't be supported.  And since it's quite
> possible that in the future 8086 and 80286 mode will finally get the axe,
> it might be necessary to move them to actual emulation (maintaining, if
> possible, virtualization for 32-bit software).
>
> I'm also kind-of thinking MacOS 7.x, that had the 68030 emulator to run
> parts of the OS on PowerPC systems...
>
> -uso.
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Google Summer of Code?

2023-01-23 Thread Steve Nickolas 

On Mon, 23 Jan 2023, E. Auer wrote:




Depending on how thin the glue and VM layer will be, you will be able
to run fewer or more DOS apps with it. You can run some DOS apps in
CTTY serial consoles if they only use int 21 for user I/O. There are
support modes for simple DOS apps in some boot managers which only
implement a few most popular bits of the DOS API to run apps directly
from the boot manager without an actual DOS. So why not use for example
real mode DOS apps without sound, with whatever is left in terms of
hardware text mode or maybe VGA as an already entertaining intermediate
milestone and keep more VGA, VESA, PC speaker, mouse, protected mode
apps etc. pp. for later? The "easy" solution will still be running a
DOS-friendly VM inside Linux or other host OS. But not the exciting
solution regarding technological challenge and "abstraction thinness".

People have written hypervisors to hide malware. Porting an open BIOS
and some VM ingredients into a CSM and an open source "VMware ESXi"
competitor which runs DOS better than the commercial product does?
In other words, a Xen for DOS? To stay in the Xen terminology, would
one want a paravirtualized DOS for that? Or would one put some light
weight "BIOS setup" type menu into dom0 and run DOS only as client?


This is kind-of what I was trying to hint at - a lightweight operating 
system that just manages the hardware and (if necessary) provides 
emulation for 16-bit apps.  I feel like even a stripped-down Linux kernel 
is extreme overkill since multitasking/multiuser isn't even useful for 
that purpose.


But in this day and age where the solution to everything is "throw a 
'Duino at it" or "throw a RasPi at it", I think too many people have lost 
the concept of simple, lightweight, minimalist software.  And that's why 
you have all the kids trying to turn FreeDOS into Linux, and Linux into 
Windows.


The idea is this: provide a "volume manager"; a way to use the installed 
hardware to emulate VGA/SVGA, SB16, and the basic equipment used on DOS 
machines; and hooks to MS-DOS/FreeDOS to support stuff you're likely to 
have on a modern machine that wouldn't be supported.  And since it's quite 
possible that in the future 8086 and 80286 mode will finally get the axe, 
it might be necessary to move them to actual emulation (maintaining, if 
possible, virtualization for 32-bit software).


I'm also kind-of thinking MacOS 7.x, that had the 68030 emulator to run 
parts of the OS on PowerPC systems...


-uso.


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

[Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Google Summer of Code?

2023-01-23 Thread E. Auer 



Hi Bret,

thanks for the great summary!


For awhile, the UEFI manufacturers provided a CSM (Compatibility
Support Module) as the "translation layer" so you didn't need a VM.
But they've even stopped doing that nowadays.  So, we'll either need
to come up with a "generic CSM" that doesn't need a VM but still
provides the needed level of hardware support both now and in the
future, or we'll need to do some kind of "thin VM" as Jerome is
suggesting.  I think the second option has a better chance of
long-term viability even though I would prefer the first.


My impression based on earlier discussions and/or BTTR forum threads
would be that there are "open source BIOS" initiatives which could be
a starting point for a large point of a "generic CSM" (BIOS module to
load on UEFI systems before booting DOS, with some magic glue needed)
at least for actually more aspects of the BIOS than normal DOS and DOS
apps will require :-) I can imagine that the dosemu2 people also have
interesting expert thoughts about that and those magic glue problems
involved.

Depending on how thin the glue and VM layer will be, you will be able
to run fewer or more DOS apps with it. You can run some DOS apps in
CTTY serial consoles if they only use int 21 for user I/O. There are
support modes for simple DOS apps in some boot managers which only
implement a few most popular bits of the DOS API to run apps directly
from the boot manager without an actual DOS. So why not use for example
real mode DOS apps without sound, with whatever is left in terms of
hardware text mode or maybe VGA as an already entertaining intermediate
milestone and keep more VGA, VESA, PC speaker, mouse, protected mode
apps etc. pp. for later? The "easy" solution will still be running a
DOS-friendly VM inside Linux or other host OS. But not the exciting
solution regarding technological challenge and "abstraction thinness".

People have written hypervisors to hide malware. Porting an open BIOS
and some VM ingredients into a CSM and an open source "VMware ESXi"
competitor which runs DOS better than the commercial product does?
In other words, a Xen for DOS? To stay in the Xen terminology, would
one want a paravirtualized DOS for that? Or would one put some light
weight "BIOS setup" type menu into dom0 and run DOS only as client?
Wikipedia mentions Alpine Linux offering a rather small Linux dom0.

https://en.wikipedia.org/wiki/Proxmox_Virtual_Environment and KVM may
also be an interesting combination to look at? Checking for others in
https://en.wikipedia.org/wiki/Comparison_of_platform_virtualization_software
my impression is that those Hypervisors which run on bare metal somehow
tend to be either Linux specific or commercial and proprietary things?

Regards, Eric



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