Hi!
> That will be my point too. Problem on developing for DOS is usually
> you are not allow to debug, unless in DOS. Exception is OpenWatcom,
> which will be my choice.
What do you mean by that? You can debug everything everywhere,
but if you have cross-compiled a DOS program using a compiler
Hi kernel readers :-)
Looking at the development of dosemu2, I find that the
many changes there have moved away from freedos SO far
that backporting became hard, without me ever noticing.
There was the announcement of fdpp in 9/2018, one year
after development started, which morphs the kernel i
Hi!
In short, your FreeCOM beeps are infinitely long.
As you saym beep_l.c and beep_n.c implements them
as beep_low() and beep() as follows:
void beep_low(void)
{
sound(900);
delay(200); /* 400 */
nosound();
delay(100);
}
void beep(void)
{
sound(900);
delay(200); /* 400 */
nosoun
Hi Rugxulo,
Thank you for your binary patch but...
> 1). 2016-May-6: "[Freedos-devel] Beep command can't stop sounding when
> run in Intel Skylelake platorm."
> * https://sourceforge.net/p/freedos/mailman/message/35068370/
>
> 2). 2017-Jun-9: "#189 Beep function freezes on recently intel platfor
Hi Tom,
>>> 2). 2017-Jun-9: "#189 Beep function freezes on recently intel platform
>>> (skylake/kabylake)"
>>> * https://sourceforge.net/p/freedos/bugs/189/
> Bart added this function as it seems to be missing from ia16_gcc
Okay so it is only fixed when you cross-compile from Linux?
> because
Hi Rugxulo (and Jim!)
>> https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/ ...
> AFAIK, the maintainer is Jeremy Davis, ...
> https://github.com/PerditionC/fdkernel
I hope there is sufficient advertisement of the github link, Jim?
>>> Is kernel development officially dead? How about fre
Hi Jim, glad to hear from you about this :-)
> But mostly it's because I hadn't *removed* lesser-used communication
> channels from the website. So we have all these places linked from
> the "Forums" page, but some places are not very populated.
People already *on* the lesser-used channels are
Hi Jeremy and everybody,
I would only suggest any form of automated infrastructure,
central storage, distribution or conversion of translations
if you expect translations to happen frequently, which I do
not, or if you like tinkering with such infrastructures :-)
In the normal situation, I woul
Hi Thraex,
> Er, may I ask why you don't want to normalize into a single file format?
Simply because somebody has to create and maintain the infrastructure.
Jerome seems to be motivated to do that, at the moment...
- extract package specific translation files from packages
- convert to unifo
Hi!
As experienced user of portable standard file formats, I would like
to say that CSV, with a clear definition of which style you should
use, is much better than "I just send you the ODS and you tweak it
in whatever way works for your conversion to translation data" ;-)
> I saw your new csv and
Hi Jerome,
let me summarize: You can fdisk, format and use 100 GB FAT32 LBA
partitions using a certain (which?) version of a non-8086, e.g.
386 optimized kernel of FreeDOS. However, doing the same on some
(which?) kernel which is trying to support 8086, you fail to use
FORMAT on said, probably F
Hi Jerome,
> Current shipping kernels 2042, not modified nor recompiled.
Shipping from where?
> FreeDOS LiveCD 1.3-RC3 (Kernel386)
> FreeDOS 1.3-RC3 x86-Floppy Edition (Kernel86)
>
> Issue occurred on real hardware, but is easily reproducible
> using VirtualBox (latest 6.1)
>
> All other dat
Hi Jerome,
>> You are welcome to buy me a new harddisk so I can test your
>> 100 GB partitions of unspecified geometry,
> Wish I could. But, I’m on a budget.
I was just trying to emphasize that it is more work for
me to recreate your bug context than it would be for you
to provide more details
>> The 8086 kernel can be compiled with FAT32.
The question is whether the floppy installer should use
an 8086 FAT32 kernel. Pro: It works with FAT32 partitions
which people may create even for 250 MB drives because
they believe smaller clusters would always be great. And
almost everybody has h
Hi!
>> You already mention the functionality on the floppy distro to
>> INSTALL the 386 kernel on 386, but it does not USE the same
>> kernel. Which is a big problem, because the user will still
>> be RUNNING the 8086 kernel from the floppy while they FDISK
>> and FORMAT while preparing to insta
Hi Jerome,
> not everything required by the installer quite fits on a 360k.
> (Although, I must admit, with a little more pruning and juggling
> by the installer and dropping the 386 kernel, It may just squeeze
> onto a 360)
Sounds like a great solution :-)
Found something interesting in my arch
Hi Thomas,
> I just had the thought of whether FreeDOS could be installed
> from a floppy image not written to an actual floppy disk.
Sure, we have been using memdisk before as the boot stage of
our ISO, but you can also mount ISO without burning an actual
CD or DVD in FreeDOS :-) It works with
Hi experts :-)
http://wiki.freedos.org/wiki/index.php/Releases/1.3/Packages
lists udvd2 in context of "xmgr, rdisk and uide", but that
should be UHDD, not uide, nor udma. Also, looking at
http://mercurycoding.com/downloads.html#DOS
our Wiki does not yet mention UHDD, XMGR, RDISK or UIDE as
pa
Hi Tom,
> most of the size increase (~3,5 K) is because a CLUSTER is no longer
> 16 bit, but 32 bit as required for FAT32, so the code can be used for
> both FAT16 and FAT32.
>
> some size increase (~1,5 K) comes from actual FAT32 specifics, that
> at least theoretically could be unloaded.
Qui
Hi!
First, I have to say I am impressed by Jerome's 486 tinkering :-)
And I can confirm that Brix with PC Speaker sound works on my
actual modern hardware. I just rarely boot into raw FreeDOS :-)
> Instead of an official FreeDOS graphics card, perhaps a standard
> FreeDOS graphics API and/or W
> FAT implementions arent "just swappable" - they are more a adapter between
> the OS interface (FCBs/DOS 2.0 file descriptors in FreeDOS) and the
> blockdev driver.
Yes back in the times DOS was not much more than a BIOS
which helped apps to work with files, hence the D in DOS.
A good idea wou
Hi Jim, good to think about the package list :-)
If you ask me, the distro has grown large because a SMALL
number of packages are rather LARGE. Even then, when you
do not install all sources, it uses a lot less space: It
would be fine to keep the sources zipped until one wants
to work on a speci
Hi Jim, a few short additional thoughts:
> But CAB files? No DOS system distributed files in CAB format
I remember DOS drivers for stuff like soundcards shipping
as part of some Windows installers. So it helps to be able
to dig into files meant for Windows, without needing any
Windows or Wine, bu
Hi Jerome,
> The more I think about it. The more I like a having a separate EXTRAS disc.
>
> Possibly even dropping the FULL/BASE choice and having just a BASE.
We did have a separate BASE ISO at some point in the past, but given
your earlier hint that FPC and DJGPP are 70 MB each, I think w
Hi Flamengo, welcome :-)
Can you give more details about the Wing game crash?
As we already have some EMACS and EMACS has a thing with
LISP, maybe we already have some LISP hidden in EMACS?
I vaguely remember some thread topics exist in DOS forums,
but somebody else would have to provide links
Hi!
> This is interrupt calls for using PCI devices.
Well you normally do not have to do anything special
to just USE them in DOS, but the interrupts help to
FIND and CONFIGURE them, in case they do not provide
compatibility to standard devices such as VGA :-)
You probably want to configure yo
By the way, if you want to know which PCI devices you
have, either real or virtual, you may want to try out
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/pcisleep.html
;-)
Regards, Eric
___
Freedos-devel
Hoi Volkert!
While you are creating that very promising VBE/AI AC97
driver, do you have a list of games which support that
interface or which support miles / ail / digipak / midipak
replaceable sound drivers or docs about the driver format?
Thank you :-)
> https://github.com/volkertb/ich2playe
Hi Paul,
> I now realize it is still an IDE driver, not an AHCI driver like I thought.
> Anyway, I wonder if the kernel itself would be needed to support AHCI mode
The DOS kernel has nothing to do at all with your drive controllers.
DOS either asks the BIOS to read or write sectors (for hardd
Hi Paul,
> That's because on a AHCI only computer (without PATA or SATA IDE),
> you cannot access the sectors with INT 13h.
Yes you can. For harddisk/SSD. Unless you configure the
computer to disable BIOS completely and boot only UEFI
operating systems.
But in that case, you get plenty of othe
Hi Volkert,
> A few months ago, I opened a feature request to have support for GEMMIS
> added to JEMM386: https://github.com/Baron-von-Riedesel/Jemm/issues/5
>
> GEMMIS stands for *Global EMM Import Specification* and is a mechanism
> for handing over memory management control from EMM managers
Hi Charles, welcome to FreeDOS!
> Should I use Borland C or Turbo C++ or what. What version?
http://www.freedos.org/contribute/ recommends OpenWatcom C.
I suggest any current version, but preferably the DOS one.
You can use Borland / Turbo if you happen to have it or if
you want to compile thi
(Reply to a mail in "New Old-Timer Reporting")
Hi!
Actually the 32 or 64 MB limit only affects EMS. If you
use XMS or a 32-bit protected mode DOS extender / DPMI,
you can easily use 2-4 GB of RAM, depending on how much
is reserved for 32-bit access to your graphics card etc.
Recently, Japheth
Danilo,
> First of all, if the idea of an 80x25 single file editor frightens you,
> you're either a wimp or too young to have done any programming when that
> was the norm. May I introduce you to Turbo Pascal 3.0? 80x25 text is the
> best there is.
Tom is neither, but you could argue that he co
Hi!
> laptop is 15 years old, and even that has hardware that is 'too new'
You mean wireless?
> I think you're asking two implicit questions here: a) Should we abandon
> 16 bit hardware as nobody has any, which would mean FreeDOS goes 32bit.
No. Things which work well with 640k can AND should
Hi!
Two thoughts inspired by the package survey:
Doszip EMM or DZEMM is a tiny SYS and a small DLL,
I suspect that it only works with Windows?
And while we have several MP3 related packages,
I miss an oggenc package in the survey ;-)
Cheers, Eric
___
Hi Jerome!
> Mostly, you can easily see the size of each package without hopping out to my
> repo.
Cool idea, but that seems to include source code.
If FreeCOM itself would be 4.8 MB, you could not
even make a boot floppy with it ;-)
There are 64 packages with megabyte sizes, and
the followi
Hi Jerome,
I suggest to measure package sizes ONLY excluding the source
directories: The binary packages usually still include lots of
accessories and documentation, which are actually useful :-)
You could even do something evil such as making a copy of your
repository, doing a clever one-liner
Hi people,
Zbigniew has found a problem with "open" which turns out to
be a buffer overflow in several FreeDOS kernel functions :-o
In short, when you open "textfile.txtgarbage", the garbage
is suspiciously silently ignored and "textfile.txt" opens.
Looking at the FreeDOS kernel source code, d
Hi Tom,
I think Zbigniew should state which version of the FreeDOS kernel
he is using, but because you have asked me so *cough* politely,
I hereby present some test results for a FreeDOS FAT32 enabled
Watcom C compiled Kernel 2038 (2009-05-16) in DOSEMU2...
1. switch to a diskimage-based drive,
Hoi Bart, nice to hear from you!
> Tom is right. The truncation is standard documented behaviour.
> It all goes via the internal implementation of TRUENAME
> ( http://www.delorie.com/djgpp/doc/rbinter/id/50/31.html )
> where the path is converted to its fully qualified version.
> quote: "lette
Hi Aniket!
> Like shall I read Minix book etc. or something
> like that to get into OS dev?
Apps for FreeDOS are just apps, not operating system
development. If you want to develop for the KERNEL or
DRIVERS, you probably want to download a copy of RBIL,
Ralf Brown's Interrupt List. Online versi
Hi Jerome, thanks for your RBIL-HTML version :-)
https://fd.lod.bz/rbil/interrup/index.html
I have not remembered that it contains an Assembly / Machine
Language Opcode List :-) Of course less verbose than Sandpile,
but still interesting that RBIL has one at all:
https://fd.lod.bz/rbil/opcode/
Hi Danilo,
> It happens on both Virtualbox and my ancient Compaq NX-8220. And
> indeed, as hinted by several folks, it seems to be connected to fdapm.
I hope using the FDAPM ADV:REG setting instead of
the FDAPM APMDOS setting solves the speed issue?
See the readme ;-)
Regards, Eric
___
Hi Danilo and merry holidays to everybody :-)
> So here's the question: Is there a process to pitch new packages
Just pitch them here. And if they are cool pitch them for our
ibiblio or other repositories of other people on the list :-)
>From there, distro inclusion would be a possible next ste
Hi :-)
> Just a bit of FYI despite the project being nowhere near ready to go
> as of yet: there is a small group of us working on moving DOS into
> the 32-bit realm in the form of the [Night
> Kernel](https://groups.google.com/g/night-dos-kernel). As part of
> that journey, we eventually want a
Hi! In case anybody has a FreeCOM toolchain and write
access to the FDOS github, here is a list of bugs and
fixes stolen from the web ;-)
https://github.com/FDOS/freecom/issues
* Russian translations have spelling errors
* line-wrapping when using up-arrow history
* internal commands do not set
Hi Robert,
> * High CPU usage in FreeDOS EDIT 0.9a
> https://sourceforge.net/p/freedos/bugs/264/
It says the clock prevents EDIT from going idle,
can you check which older versions are affected?
My copy of 0.9a does not include the dflat source
code, while version 0.82 still does. Version 0.
Hi Mercury & everybody,
> I noticed a while back that Japheth updated his HiMemX driver, and
> I've finally gotten around to packaging it up for use in FreeDOS.
>
> Also, he's made a new driver which can do what that HiMemX does, and
> more... way more. HiMemSX can access memory above the 4 GiB
hi tom,
> there is simply no DOS application needing even 100 MB.
> making more than 4 GB available won't change this.
i beg to differ: jack's cache can be configured to cache
huge fractions of your partition (which may or may not be
good for performance) and that ramdisk modification by
japheth
Hi Andreas,
how do you manage to receive gigabytes of data from a
few dozen peers with mere megahertz of CPU clock rate?
What are the chances to reduce server RAM footprint?
Regards, Eric
> I still use DOS to this day in an industrial setting...
> hundreds of remote machines with tens of embed
Hi!
> I don't receive gigabytes at once. I have multiple serial lines using a
> RS485 similar communications method (Master - Slave). The peers can be
> up to 1KM away. Each line can have up to 50 peers. Each peer is
> interrupted when it's 9-bit address is called and it starts
> communicating.
Hi!
> However, the reason I answered in the first place was to show Tom that
> DOS programs exist that use more then 100MB. I don't think I will ever
> need more then 4GB - or even that much, but it is good to know that it
> is possible. On the other hand, I never imagined I would end up using
>
Hi!
To whom it may concern: Current issues with HTMLHELP from Fritz :-)
a) If there is a language set in environment variables, e.g.
"set LANG=ID" and there is NO "htmlhelp.ID"
help hangs instead of working and falling back to english language,
b) help.exe often crashes when moving around fro
Hi Tom,
Of course I meant Fritz Mueller who does have a lot
of experience in using HTMLHELP and working with help
texts for it. So I trust him that those bugs do exist.
He just is not on the mailing list, so I am forwarding.
You wondered whether bugs depend on configuration: One
of the bugs is
Hi Andy,
nice to hear that you are working on improving HTMLHELP.
If you ask me, it would be great to keep a working HTML
based help viewer around. The format has the advantage
that people already know HTML and can contribute content
and translations easily. AMB converted versions are nice
to h
Hi!
> FDISK 1.3.2 would not find volume labels, if the partition doesn't
> start on a cylinder boundary. fixed in
> www.drivesnapshot.de/freedos/fdisk133.zip
>
> BUT: at least in my environment, the most recent FORMAT91W is not able
> to format logical partitions, but aborts with error.
Accor
Hi Ralf,
>>> The problem seems to be in the part of the code when you
>> sorry, not me. FDISK, and the original author may be blamed,
>> but definitively not me.
> Well Tom, you need to seriously chill out.
While it is not often the case, I agree with the harsh tone
in this case: Also accordi
Hi! I remember that some of our SYS versions have some
extra options to make them more flexible to load other
kernels. I would like to know HOW flexible. In particular,
ECM mentions some special requirements for MS DOS / PC DOS:
https://www.bttr-software.de/forum/forum_entry.php?id=17725
It mig
Hi PAP,
I assume unikernel means replacing hardware I/O by
calls to a suitable hypervisor interface? In a way,
DOS already does that by using BIOS. So you could
make a BIOS-Unikernel and then run FreeDOS as app
on that. But how do you deal with the fact that a
DOS kernel and DOS apps will prefer
Hi Volkert,
> By the way, the dosemu2 developers are also developing fdpp, a 64-bit DOS
> kernel that aims to provide a DOS-compatible userspace and that can run in
> Dosemu2. (Not sure if it always uses fdpp by default.) Since it's a 64-bit
> process, I'm not sure how fdpp and dosemu2 handle th
Hi Jim, making the package versions number a part of the
directory structure seems like a marginal improvement to
me in most cases. For packages which have a stable style
of version numbering, it can even make the structure worse,
as people can no longer see which version came out when?
A remedy
Hi! Looking at
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/user/lptlink/
I have noticed that
1. the URL mentioned in the source no longer works and
2. https://sourceforge.net/projects/lptransfer/ which
is the current location of the source contains some
ITALIAN documentation
Hi Jim and Robert,
indeed I have slowly moved to more "sorted directory listing
friendly" date formats, but it would not be a problem for me
if you decided to rename all files lbacache_-mm-dd.zip
style and put them all in ONE directory. Then one can see
at one glance what is available, witho
> On Sat, 1 May 2021 at 21:13, Wilhelm Spiegl wrote:
>>
>> hi jim,
>> i think you should feel free to rename filenames to a unique system e.g.
>> program_-mm--dd -at least within a single command. creating
>> subdirectories is nice but not absolutely necessary if the user knows that
>> th
Hi Jim,
my argument was not that search engines should help us
to advertise specific apps. My point is that it should
be possible to find anything on ibiblio. If I google
freedos kernel 2042 i386 and google returns a HTML of
the LSM which in turn points me to 5fc559f6.zip this
would still help m
DAPM is built with UPX --8086 by default.
https://github.com/shidel/FDI/tree/master/FDISETUP/SETUP
Also, you can use the 2 kB "CPULEVEL" tool instead of
VINFO but I guess you install VINFO everywhere anyway.
> C:\>cpulevel
> CPULEVEL - public domain by Eric Auer 2004-2007
>
Good day Jerome,
> As for RC4, it is coming very very soon.
>
> Excluding anything absolutely critical,
Well, having four times slower install than
possible, when installing on real hardware,
does sound like something which *is* worth
fixing ASAP and in rc4, unless you plan to
release rc5 onl
Hi Jerome,
>> Well, having four times slower install than
>> possible, when installing on real hardware,
>> does sound like something which *is* worth
>> fixing ASAP and in rc4, unless you plan to
>> release rc5 only a week later ;-)
> RC4 is no slower than RC3 or RC2.
Which is too slow, given
Hi Jerome! That list which packages are on which medium
of course asks for a number of critical remarks now ;-)
> Be sure and check out the new Report file generated by the RBE.
>
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/previews/1.3-rc4/report.html
Nice tha
Hi!
> Look for AUTOEXEC.* and CONFIG.* in that subdirectory.
I have commented those, too, in some cases. In cases where
they had the same bugs as commented for other files, I have
not repeated the bug description in my mail each time.
>> 2. use IDLEHALT=1 in config.sys to lower CPU usage on
>>
>> Why are PAINT2, LHA, UNRAR, ELTORITO, XMGR and RDISK on
Thanks for explaining ELTORITO, but as it is easier to find
using the name ELTORITO and as you may not have SYSLINUX on
all media, I think you can still add ELTORITO to all, too.
How about the other 5? I guess UNRAR or LHA = license issu
Hi!
>> Apparently the algorithm is to first try VIDE-CDD, OAKCDROM,
>> GSCDROM, then UDVD2, ELTORITO, GCDROM, UIDE in that order,
>> in spite of the first few not even being included? Why?
My point is that if I am ancient enough to download OAKCDROM
somewhere, I will just say "gasp, what does th
Hi Ralf,
>>> RC4 is no slower than RC3 or RC2.
>> Which is too slow, given that easy solutions
>> have been available for several years, which
>> could speed up the process by a factor four.
> Does it really matter? It is not that it takes hours,
> nor is the average user doing this rather fre
Hi Jerome,
> Install reliability and stability are of prime importance.
No worries here. The advertised items are well-established.
> After that comes luxuries, like improved performance.
Or a large maze of batch scripts & ASM tools ;-)
> Now that RC4 is done.
Thanks!
> I’m probably going t
Hi Robert,
>> Why are PAINT2, LHA, UNRAR, ELTORITO, XMGR and RDISK on
>> none of the media? How about DRMIND, KILOBLAS, LINCRAWL
>> and PRSINVAD? Who managed to make a minesweeper 8 MB and
>> a tetris version 3 MB large? Why no TAIL and UPTIME, or
>> BLWCBC blowfish cbc?
>
> Most is explained h
Hi!
> * Always made instantly available to the Live Environment of the LiveCD?
> - RAREAD
> - RAWRITE
> - XFDISK
> - UNRTF
>
> * Always installed with a FULL install?
> - RAREAD
> - RAWRITE
> - XFDISK
> - UNRTF
> - SQLITE
>
>> I also suggest doing the FreeDOS Release Media sur
Hi!
>> Also, you can use the 2 kB "CPULEVEL" tool instead of
>> VINFO but I guess you install VINFO everywhere anyway.
> I added a bunch of things to your cpulevel and callver tools. cpulevel
> now will detect NEC V20/V30 processors as 186-class too. The commit is
Exotic but nice :-) With upx
Hi developers!
It seems that our XCOPY (rxcopy, updated to compile not only in
Turbo C++ 3, but also in Turbo C 2 and OpenWatcom, around 2005,
using Pat's light and fast PRF printf, KITTEN localization etc.)
is noticeably slower than MS DOS XCOPY. Actually, it also makes
a noticeable difference
Hi Jerome,
>> PS: I can confirm that GCDROM is a modified old fork from
>> what has become UDVD2 and XDVD2. We should remove GCDROM
>> from the distro to avoid confusion. We already have UDVD2.
To be more exact: GCDROM was a third-party fork of XCDROM
which had some constraints about searching
Hello Jerome,
> As you may have noticed in RC4, we decided to reduce the size of the LiteUSB
> stick.
Who are "we"?
> Since that edition only contains BASE, it can be squeezed onto a 16mb flash
> drive
> or memory car with about 0.5mb of free space leftover.
That is unnecessarily small. It
Hi Jerome,
>>> ... in RC4, we decided to reduce the size of the LiteUSB stick.
>> Who are "we”?
...
> I do not and will not speak for others. When I say “we", it
> simply means that it is not something I arbitrarily decided.
The way you describe it, it does sound arbitrary. It gives the
impres
Hi Jerome,
Glad you agree to have a discussion about a larger
partition size for the lite USB image.
>> In addition, there could be dozens of nice little things while
> Are you suggesting that the LiteUSB image should have two install
> options? Something like BASE & BASE+? And the FullUSB hav
Hi Jerome,
indeed there are many possibilities for automated
and manual package selection :-)
> The package survey is ongoing and self-adjusting.
Do you suggest that people cast multiple votes, or
generally cast fresh votes because context changed?
> However, I do need to add support for the
Hi Bret,
> I also have a USB disk set up with GPT instead of MBR with some
> DOS-compatible partitions (FAT12/16/32) and others as non-DOS compatible
> (NTFS, exFAT, etc.). I also use this for testing my USB drivers to make
> sure drive letters get assigned when needed to the DOS-compatible
> p
Hi Paul,
thanks for all the tests of various apps on your hardware!
> I'd like to report that the livecd.iso works for me on my hardware:
> Prime H310M-C R2.0, with I3-8100 CPU.
> I am impress and surprise, because it have a SATA chip that does not emulate
> IDE.
> It does fail on first cdrom d
Hi Paul,
> i3-8100 ... E6300 computer.
>
> All the games ... worked on ... E6300 CPU (with default option 1).
>
> So, must be something with the newer CPU that is incompatible.
I think it is more likely that the default JEMMEX options
(e.g. UMB regions I=TEST) are not compatible with the BIOS
Hi Paul,
> No I cannot access DVD on installed system.
So you can only access it using ELTORITO after booting?
If you cannot enable some SATA legacy mode, you could
use the AHCICD driver here:
https://rloewelectronics.com/distribute/AHCICD/1.1/
It is now freely available, as the author has, a
Hi!
> Reboot: make a D exception after, saying it called int 28 or 28h...
> and after saying it was ... cleaning DOS filesystems?...
It probably uses FDAPM to perform the reboot, which first
signals DOS and caches to prepare for the upcoming reboot.
Messages are a bit different from what you say
Hi Tom and Paul
> any EMM386 will redirect ANY interrupt because protected mode.
>
> while I didn't try this, I doubt you will be able to trace ANY
> interrupt with debug.
It COULD probably be debugged (by experts) with
https://ulukai.org/ecm/web/#projects-ldebug
or with 386SWAT
http://www.
Hi Paul,
> It may be the case with other drivers than hard disk too...
Apparently at least keyboard and graphics work without
problems, so I think it is more related to drivers with
block I/O such as disk and maybe network or USB. Which
leads to the question how your system behaves after you
ha
Hi Paul,
> I have try to stubify games program, to redo the COFF loader.
> It does not seems to change anything however.
You can do that, but as said, you can also load another DPMI
provider as TSR or with your app as argument to run the app
with another DPMI, without having to re-stubify. You
Bonsoir Paul,
> There is a bug in the web page: there is only 3 bytes reserved at offset 5
Sorry I have not paid attention to that, but as you can see
in my mail, I have written that you can ignore 3 bytes :-)
> Also you seems to have closed your eyes at a bug in FreeDOS:
>
> yes, 1c0 is the
Hi Paul,
yes, EMM386 could switch the entire system back to
real mode for certain things, but that would make
the performance loss significantly worse than what
you get with any EMM386 anyway unless you use the
VME (V86 mode extensions, enable with command line
option "VME", requires at least 48
Bonjour Paul,
> But I am mostly here for testing FreeDOS and help others not
> to encounters the problem I encounter.
I do not understand that sentence.
> In my opinion, instructions for turning off and on protected mode,
> and storing, restoring registers value are pretty cheap in time.
Poss
Hi Tom,
>> PS: I am busy checking Bret's GPT code for making a version which
>> kernel developers can read (it is NASM) to write a C version of the
>> algorithm and add that to the FreeDOS kernel.
> pretty much waste of time.
It is always nice to have some example code for things.
> reading t
Hello TK and Paul,
> FreeDOS (and other MS-DOS compatibles) will ask the BIOS --- via int
> 0x12, or [0:0x413] --- how much memory is available, rather than always
> assuming 640 KiB.
Yes. Which is still more simplistic that processing the full BIOS
reported list of which areas are for what. Onl
Hi John,
> A few days ago I did a short experiment, benchmarking raw framebuffer
> drawing performance on some old computers, under DOS, and GNU/Linux with
> X11 (Xshm) and fbdev. My objective was to test how much overhead...
> http://nuclear.mutantstargoat.com/blog/100-fbperf_experiments.html
Hi Jerome,
> Basically, it is the HD image of the x86 installer.
Interesting that it scrolls through a bit of text about
FreeDOS to keep the user entertained while installing.
I see that it ends up creating a 386+ install, which
makes me wonder whether SHSUCDX and UDVD2 actually
recommend load
Hi all,
as announced earlier, Bret Johnson has donated excerpts from
his USB drivers written in (NASM style) assembly language as
examples of how to process GPT partitioned drives. This can
be useful as reference when adding some GPT support in C for
the FreeDOS kernel. Our MBR partition table h
301 - 400 of 1242 matches
Mail list logo
