Re: [Freedos-devel] Re: Where to start and continue?
I am sure that you can find older people that still have old laptops with ide hds for giving away. If not, "Amazon is your friend" as a former colleague said and thought.In most cases only the BIOS battery is empty. CR2032.Willi--Diese Nachricht wurde von meinem Android Mobiltelefon mit mail.com Mail gesendet.Am 10.01.23, 11:53 schrieb Jerome Shidel : Hi, > On Jan 10, 2023, at 4:14 AM, Knedlik wrote: > > Hello all again, > thanks for all the responses. Definitely useful stuff. I’d just like to respond to the concerns regarding the VM - I’m afraid I don’t have any silicon able to run FreeDOS. My main computer is not only an overkill (Ryzen 5 3600X, SSD, RTX 2060, 32 gigs of RAM), but I don’t think it supports legacy BIOS. And the secondary I’m on right now is a MacBook with an M1 CPU, so even if I had bootcamp, that option wouldn’t be possible. > -Knedlik > Don’t worry about the VM issues too much. I just wanted to point out they exist. Depending on what you may write, you could make something that is done 100% perfect that doesn’t work in a VM. I generally use on older Intel based Mac. I have several workflows for creating stuff for DOS. When making stuff in assembly, I do my writing in BBEdit. Then compile in a terminal on the Mac. Then switch over to one of a couple VMs or Real Hardware and test. The testing part can vary based on the know limitations for the VMs. Generally, that testing happens under DOSBox. Here I run FreeCOM on top of the DOSBox kernel. It is a sort-of hybrid install that the FreeDOS installer can perform. This permits the DOS VM easy access to the host file system. However, there are some issues. Most have to do with the disk and file system. For example, updating a files time stamp in DOS gets completely ignored. There are other issues as well. But, I usually find this the easiest workflow. Sometimes the DOS part of my workflow includes a VirtualBox instance. In the early days, getting files to and from the VM was more work. I would copy them onto a diskette image file (which is easy on a Mac). Dismount the image file. Then mount the image in VirtualBox. Test and Dismount it in the VM. And repeat. Needing to make sure I did not mount the image in both places at the same time or the image file would be trashed. Nowadays. I have a Linux server with a Samba share mounted by the Mac. The server also shares the directory over EtherDFS to the VirtualBox DOS instance running an EtherDFS client. It works well except EtherDFS does not support long file names. Which is fine because you should avoid those in DOS development. As for VirtualBox itself, first there is no PC Speaker support. The VGA limitations mostly crop up with more advanced things like using features that require talking to the card. The basic BIOS calls work fine. Then there is real hardware. It’s the ultimate test and nothing is better. I use both real floppies and EtherDFS to get files onto that machine. While the different limitations of the various VMs do exist, they are issues to just avoid. You just need to be aware and able to spot them when/if they crop up. Then figure out how to avoid the problem when possible in your code. After all, a large number of users will not have real hardware either. Like you, they will be limited to running the program in a VM. It wouldn’t make much sense to create something that neither the users or yourself can actually run. Even if it would work fine on real hardware. :-) When it comes down to avoiding the VM issues, sometimes you can and sometimes you can not. For example, let’s say you want to make a better file copy program. One that copies file time stamps and verifies everything. You test it on real hardware and it works great. Try it under VirtualBox and it is incredibly cool. You jump into your DOSBox hybrid install and… Error: Copied file failed verification. What? Why? It worked fine on my test machine under VirtualBox! So after some debugging and head banging and more debugging, you realize the program was fine and DOSBox just ignores the timestamps. Not much you can do about that. Maybe you test to see if you’re running under DOSBox and warn the user that this occur. Maybe some other or even no solution. It’s up to you. :-) > ___ > 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] Where to start and continue?
Hi, > On Jan 10, 2023, at 4:14 AM, Knedlik wrote: > > Hello all again, > thanks for all the responses. Definitely useful stuff. I’d just like to > respond to the concerns regarding the VM - I’m afraid I don’t have any > silicon able to run FreeDOS. My main computer is not only an overkill (Ryzen > 5 3600X, SSD, RTX 2060, 32 gigs of RAM), but I don’t think it supports legacy > BIOS. And the secondary I’m on right now is a MacBook with an M1 CPU, so even > if I had bootcamp, that option wouldn’t be possible. > -Knedlik > Don’t worry about the VM issues too much. I just wanted to point out they exist. Depending on what you may write, you could make something that is done 100% perfect that doesn’t work in a VM. I generally use on older Intel based Mac. I have several workflows for creating stuff for DOS. When making stuff in assembly, I do my writing in BBEdit. Then compile in a terminal on the Mac. Then switch over to one of a couple VMs or Real Hardware and test. The testing part can vary based on the know limitations for the VMs. Generally, that testing happens under DOSBox. Here I run FreeCOM on top of the DOSBox kernel. It is a sort-of hybrid install that the FreeDOS installer can perform. This permits the DOS VM easy access to the host file system. However, there are some issues. Most have to do with the disk and file system. For example, updating a files time stamp in DOS gets completely ignored. There are other issues as well. But, I usually find this the easiest workflow. Sometimes the DOS part of my workflow includes a VirtualBox instance. In the early days, getting files to and from the VM was more work. I would copy them onto a diskette image file (which is easy on a Mac). Dismount the image file. Then mount the image in VirtualBox. Test and Dismount it in the VM. And repeat. Needing to make sure I did not mount the image in both places at the same time or the image file would be trashed. Nowadays. I have a Linux server with a Samba share mounted by the Mac. The server also shares the directory over EtherDFS to the VirtualBox DOS instance running an EtherDFS client. It works well except EtherDFS does not support long file names. Which is fine because you should avoid those in DOS development. As for VirtualBox itself, first there is no PC Speaker support. The VGA limitations mostly crop up with more advanced things like using features that require talking to the card. The basic BIOS calls work fine. Then there is real hardware. It’s the ultimate test and nothing is better. I use both real floppies and EtherDFS to get files onto that machine. While the different limitations of the various VMs do exist, they are issues to just avoid. You just need to be aware and able to spot them when/if they crop up. Then figure out how to avoid the problem when possible in your code. After all, a large number of users will not have real hardware either. Like you, they will be limited to running the program in a VM. It wouldn’t make much sense to create something that neither the users or yourself can actually run. Even if it would work fine on real hardware. :-) When it comes down to avoiding the VM issues, sometimes you can and sometimes you can not. For example, let’s say you want to make a better file copy program. One that copies file time stamps and verifies everything. You test it on real hardware and it works great. Try it under VirtualBox and it is incredibly cool. You jump into your DOSBox hybrid install and… Error: Copied file failed verification. What? Why? It worked fine on my test machine under VirtualBox! So after some debugging and head banging and more debugging, you realize the program was fine and DOSBox just ignores the timestamps. Not much you can do about that. Maybe you test to see if you’re running under DOSBox and warn the user that this occur. Maybe some other or even no solution. It’s up to you. :-) > ___ > 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] Where to start and continue?
One reference, HelpPC might also be useful (https://stanislavs.org/helppc/). On Tue, Jan 10, 2023 at 1:32 AM Carsten Strotmann via Freedos-devel wrote: > > Hi, > > On 10 Jan 2023, at 10:13, Knedlik wrote: > > > Hello all again, > > thanks for all the responses. Definitely useful stuff. I’d just like to > > respond to the concerns regarding the VM - I’m afraid I don’t have any > > silicon able to run FreeDOS. My main computer is not only an overkill > > (Ryzen 5 3600X, SSD, RTX 2060, 32 gigs of RAM), but I don’t think it > > supports legacy BIOS. And the secondary I’m on right now is a MacBook with > > an M1 CPU, so even if I had bootcamp, that option wouldn’t be possible. > > -Knedlik > > > a dedicated PC emulator might be a better option than an VM > > * PCem https://www.pcem-emulator.co.uk/ > * DOSBOX https://dosbox-x.com/ > * PCE http://www.hampa.ch/pce/ > * PCEjs https://github.com/jsdf/pce > > Greetings > > Carsten > > > ___ > 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] Where to start and continue?
Hi, On 10 Jan 2023, at 10:13, Knedlik wrote: > Hello all again, > thanks for all the responses. Definitely useful stuff. I’d just like to > respond to the concerns regarding the VM - I’m afraid I don’t have any > silicon able to run FreeDOS. My main computer is not only an overkill (Ryzen > 5 3600X, SSD, RTX 2060, 32 gigs of RAM), but I don’t think it supports legacy > BIOS. And the secondary I’m on right now is a MacBook with an M1 CPU, so even > if I had bootcamp, that option wouldn’t be possible. > -Knedlik a dedicated PC emulator might be a better option than an VM * PCem https://www.pcem-emulator.co.uk/ * DOSBOX https://dosbox-x.com/ * PCE http://www.hampa.ch/pce/ * PCEjs https://github.com/jsdf/pce Greetings Carsten ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Where to start and continue?
Hello all again, thanks for all the responses. Definitely useful stuff. I’d just like to respond to the concerns regarding the VM - I’m afraid I don’t have any silicon able to run FreeDOS. My main computer is not only an overkill (Ryzen 5 3600X, SSD, RTX 2060, 32 gigs of RAM), but I don’t think it supports legacy BIOS. And the secondary I’m on right now is a MacBook with an M1 CPU, so even if I had bootcamp, that option wouldn’t be possible. -Knedlik ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
