On at 2024-05-03 23:54 -0400, Steve Nickolas via Freedos-devel wrote:
So I've had some thoughts regarding the MS-DOS 4 source drop, regarding
things I'd like to do with the code. I'm not really that good of a
coder and probably would only be able to do some of them myself. (I'd
kill for a
On at 2024-04-26 14:28 -0500, Jim Hall via Freedos-devel wrote:
On Fri, 26 Apr 2024, Bernd Böckmann via Freedos-devel wrote:
Microsoft and IBM released the source code of MS-DOS 4.0 under MIT
license [1]. To me, it looks fairly complete.
On Fri, Apr 26, 2024 at 2:25 AM Steve Nickolas via
On at 2024-01-04 17:46 +0100, Bernd Böckmann via Freedos-devel wrote:
Hi Eric,
I would assume the kernel parameter is neither meant to be queried
at runtime nor is it used by a significant number of people at all.
There is no external API, but you may pull it from RAM, possibly.
No, the
On at 2023-09-01 19:03 +0200, Bernd Böckmann via Freedos-devel wrote:
Well, I think it's me to blame ;-)
I will try to build some compression mechanism into AMB, so that the
help files get smaller. The main FreeDOS help file would also benefit
from that, I think.
Bernd
I recently added
On at 2023-08-02 15:27 +0800, Paul Edwards via Freedos-devel wrote:
> FreeDOS should run on 8086, both kernel and shell. If it doesn't,
> that's a bug or omission.
Are you sure? I thought I was told that the standard
distribution relied on an 80386.
> ke20xx_32.zip : binaries for 8086,
On at 2023-07-31 08:44 -0500, Jim Hall via Freedos-devel wrote:
FYI: Your post was 104 lines and 618 words. How-to articles on
websites are between 500 and 800 words, so this email was a bit long.
:-/
The point is you have released a new microemacs?
There is some more context to all of this
On at 2023-05-09 21:02 -0500, rehsd.i...@gmail.com wrote:
Thanks again, Eric, for the previous info. I've done a bit more digging but
haven't found the root cause of the issue yet. I have tried forcing LBA
(using sys & sys config). I have also added a bit more debugging info on
boot. I added
On at 2023-05-13 18:09 -0500, rehsd.i...@gmail.com wrote:
I am working to get FreeDOS running on my 286 system. As part of this, I am
trying to improve my BIOS code. As I look at the stack setup when the system
initializes, I am using the following.
; org 0x
xor
On at 2023-05-02 17:50 -0400, jer...@shidel.net wrote:
Hi,
On May 2, 2023, at 2:15 PM, C. Masloch wrote:
On at 2023-05-01 23:55 -0400, jer...@shidel.net wrote:
Hi All,
Yesterday, I released the new version of Logger. It has come a long way since
the first Alpha release and works great. I
On at 2023-05-01 23:55 -0400, jer...@shidel.net wrote:
Hi All,
Yesterday, I released the new version of Logger. It has come a long way
since the first Alpha release and works great. I made some final
decisions on a couple aspects and it is now in the Beta stage. Other
than some probable byte
A few additions to my prior mail:
On at 2023-05-01 13:04 +0200, C. Masloch wrote:
On at 2023-04-28 13:51 -0400, jer...@shidel.net wrote:
Hi All,
Logger is coming along great and I’m currently working on the final
ALPHA-8 version. Once that is done, it will be time for a BETA or two
On at 2023-04-28 13:51 -0400, jer...@shidel.net wrote:
Hi All,
Logger is coming along great and I’m currently working on the final ALPHA-8
version. Once that is done, it will be time for a BETA or two. Then finally
version 1.0.
Your IISP headers could store the required retf at a place
On at 2023-05-01 01:45 -0500, Rugxulo wrote:
Hi,
On Sun, Apr 30, 2023 at 4:54 PM wrote:
In, kernel/pcb.h, I see some notes about “offsets must match the assembly
process”
and a couple of different layouts for the offsets. Could this be related to the
issue I am having?
I am using NASM
On at 2023-04-30 17:19 -0500, rehsd.i...@gmail.com wrote:
Not sure if it’s bad etiquette to reply to your own post, but… I may
just need to change out my “iret” with “ret 2”. I’m doing some testing…
Rich
In NASM you can indeed use this as an alternative, but you need *far*
return, that is
(Replying to multiple mails again.)
On at 2023-04-21 19:03 -0400, jer...@shidel.net wrote:
Hi Tom,
On Apr 21, 2023, at 2:01 PM, tom ehlert wrote:
Hi ecm,
[1]:
https://gitlab.com/DOSx86/logger/-/blob/aae3dfddcdacfea18950a96ce9449767c20b2d66/source/logger/common.inc#L267
this got me
I'm responding to all of your mails (Jerome's) so far.
On at 2023-04-21 06:55 -0400, jer...@shidel.net wrote:
Hi All,
At present, the interface program for Logger just performs a slightly
optimized brute force search for the Logger device driver. Although
reliable, it is very slow compared
On at 2023-04-05 03:32 +, Bret Johnson wrote:
The article is found at
https://pushbx.org/ecm/dokuwiki
/doku.php?id=blog:pushbx:2023:0321_cpu_performance_comparison
I mostly agree with you and your article, but:
fine that you agree, but at most 50% of the article is even close to
On at 2023-04-04 21:09 +0200, tom ehlert wrote:
Dear Bret,
The article is found at
https://pushbx.org/ecm/dokuwiki/doku.php?id=blog:pushbx:2023:0321_cpu_performance_comparison
I mostly agree with you and your article, but:
fine that you agree, but at most 50% of the article is even
Hello!
Inspired by recent discussions on the list I prepared an article about
Bret's SLOWDOWN, its Slowdown-Units rating, and a comparison of two
different depackers on three different machines. I believe that the
depackers are a better test case for how fast a CPU actually is, because
they
On at 2023-02-22 01:05 +, Yll Buzoku wrote:
Hi Aitor,
Preface:
The following holds true for PC-DOS 3.3, though I have no reason to
suspect anything I say holds any different for any DOS version from 3.1
onwards.
The LoL, SDA, CDS, and SFT layouts differ somewhat between MS-DOS
On at 2023-02-21 22:39 +0100, Aitor Santamaría wrote:
Thanks!!
Just a 5-min check so I may be wrong, but it seems to hook int13h and
issue some Iomega ZIP HPFS driver SCSI calls to do the work.
Which is just another way to accede other filesystems. :)
iHPFS proper (not iHPFSOM which I do
On at 2023-02-20 22:03 +0100, Eric Auer wrote:
Hi! As we have various drivers which use the network redirector API,
CD/DVD redirector API or both,
There is no distinction between those, that's the same file system
redirector interface. It can be used for optical storage, for networked
file
Hello tom ehlert,
On at 2022-08-01 15:11 +0200, tom ehlert wrote:
> Hallo Herr C. Masloch,
> am Sonntag, 31. Juli 2022 um 22:25 schrieben Sie:
I would appreciate if you did not refer to me wrongly.
>> On at 2022-07-31 15:49 +0800, TK Chia wrote:
>>> Hello Jerome,
>>
On at 2022-07-31 22:44 +0200, Eric Auer wrote:
Hi!
(I started looking into it to support loading lDebug in device-driver
mode using DEVLOAD, which requires an allocation to the device that's
larger than 64 KiB. I uploaded my experimental patch [1] ...
However, I believe that DEVLOAD will
On at 2022-07-31 15:49 +0800, TK Chia wrote:
Hello Jerome,
Generally, I would not include an attachment. However, this is a
tiny zip and includes the test source, build scripts and the compiled
version.
Well... I found that your ansitest.com still works with the FreeDOS 1.3
kernel +
On at 2022-07-12 21:59 +0200, C. Masloch wrote:
On at 2022-07-12 15:45 -0400, Steve Nickolas wrote:
The new "new2F":
new2F: cmp ah, 0xB0 ; is it ours?
je .2
.1: jmp 0:0
.2: cmp al, 1
ja .1
On at 2022-07-12 15:45 -0400, Steve Nickolas wrote:
I haven't uploaded a copy of the new source anywhere yet - it'll
probably be in the next DOSLITE source batch along with my work on a few
other DOS commands, but I don't want to replace the copy I've already
uploaded, and DOSLITE isn't ready
On at 2022-07-12 15:15 -0400, Steve Nickolas wrote:
You do not use an IBM Interrupt Sharing Protocol (IISP) [11] header
for your interrupt hook. Therefore, you could optimise this part a
bit, from:
old2F: dd 0x
...
.1: jmp far [cs:old2F]
Into this:
.1: jmp
On at 2022-07-12 20:01 +0200, Jose Senna wrote:
Bret Johnson said:
> The way it works is to make a "copy" of
> itself at the top of conventional memory,
> terminates itself (using a normal DOS
> terminate process, which includes deleting
> the original PSP), and then continues
>
Hi list,
On at 2022-07-12 16:29 +, Bret Johnson wrote:
For TSR's, there are additional things you can do to reduce memory. You can
look at the source code for my PRTSCR program (available at
http://bretjohnson.us) that uses a BUNCH of tricks. For example, it doesn't
even use the DOS
Hello list,
The recent thread on freedos-user reminded me that my debugger [1] (and
also the serial comms test application I wrote prior [2]) has an IRQ
handler for serial port communications [3] that doesn't allow sharing
the IRQ with other handlers -- at least, not any installed before it.
Hello FreeDOS developers and users,
Another 3 months have gone by and here's the next release of the
advanced Debug re-implementation, lDebug, based on FreeDOS Debug. It is
free/libre and builds from source using a toolchain including NASM and a
C compiler.
Like before, there are 5
Hello Eric,
On at 2021-06-17 17:26 +0200, Eric Auer wrote:
while it is great to hear that you are doing a lot of
reading about EGA/VGA programming, I would suggest
that you use DEBUG to try a few things until you find
the first type of palette manipulation which works in
another virtual window
Hello Eric,
On at 2021-05-27 12:38 +0200, Eric Auer wrote:
Sorry but given that my best guess is that you have misunderstood
the problem, you are not yet an experienced JEMMEX programmer.
Again, I ask you to use the "do not load EMM386" workaround for
now. If the topic is REALLY exciting for
On at 2021-05-06 01:10 +0200, Eric Auer wrote:
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.
On at 2021-05-03 11:05 +0200, Eric Auer wrote:
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
CPU brand is GenuineIntel / CPU is family 5 model 2 revision c
Hello FreeDOS developers and users,
I decided to push out release 2 of my FreeDOS Debug fork today, nearly 3
months after release 1. It is based on 2008's FreeDOS Debug 1.13 first,
staying with the Netwide Assembler source, though with many of the
changes added to FreeDOS Debug since ported
On at 2021-03-04 11:06 -0600, Jim Hall wrote:
On Thu, Mar 4, 2021 at 11:02 AM C. Masloch wrote:
On at 2021-03-03 17:20 -0600, Jim Hall wrote:
Thanks. I also noticed that you have a "draft 3" file there as of
today, so I mirrored all of the "drafts" to the ibiblio site
On at 2021-03-04 11:06 -0600, Jim Hall wrote:
On Thu, Mar 4, 2021 at 11:02 AM C. Masloch wrote:
On at 2021-03-03 17:20 -0600, Jim Hall wrote:
Thanks. I also noticed that you have a "draft 3" file there as of
today, so I mirrored all of the "drafts" to the ibiblio site
On at 2021-03-03 17:20 -0600, Jim Hall wrote:
Thanks. I also noticed that you have a "draft 3" file there as of
today, so I mirrored all of the "drafts" to the ibiblio site as a
backup.
Just added draft 4 today. Changes in draft 3:
- Deleted SOURCE/LDEBUG/ldebug/doc/*.info* files to avoid
On at 2021-02-22 09:32 -0600, Jim Hall wrote:
Do you mean this link [1]?
Yes that will be fine.
Done.
By the way, I just noticed that someone uploaded (presumably) my draft
FreeDOS zip package to [2]. I'd rather fix it first with all the
sources
as discussed. No harm
Accidentally replied off-list instead of to the list. Here's what I
meant to send.
Regards,
ecm
Forwarded Message
Subject: Re: [Freedos-devel] Announcement: lDebug release 1
Date: 2021-02-22 12:12:01 +0100 Feb Mon
From: C. Masloch
To: Jim Hall
On at 2021-02-21 17:41 -0600
On at 2021-02-20 16:40 +0100, tom ehlert wrote:
Hallo Herr C. Masloch,
Not a Herr. But hello to you too,
am Samstag, 20. Februar 2021 um 12:49 schrieben Sie:
On at 2021-02-19 20:39 +0800, TK Chia wrote:
Hello Masloch,
1. Is this the right amount of sources? The macro collection
On at 2021-02-19 20:39 +0800, TK Chia wrote:
Hello Masloch,
1. Is this the right amount of sources? The macro collection, ldosboot,
instsect, and scanptab repos' contents are not included, but they are
required to rebuild everything. The tellsize tool is another component
not included. (As
: lDebug
Version: release 1
Entered-date: 2021-02-15
Description: advanced debugger based on FreeDOS Debug
Keywords: debug, debugger, DPMI debugger, bootable debugger
Author: Paul Vojta
Andreas "Japheth" Grech
Maintained-by: C. Masloch
Primary-site: https://ulukai.org/ecm/web/#proje
Hello list,
I just recently answered a question about this, it is at
https://stackoverflow.com/questions/22409680/interrupt-21-h-function-31-h-dx-value/57762787#57762787
Quoting the relevant part not mentioned in this thread yet:
> Another issue is that the calculation can be done at build
>
On at 2018-11-05 18:01 +, Bret Johnson wrote:
> Being the author of two of the items mentioned (USBDOS & SLOWDOWN), I can say
> that there is no problem in including them with FreeDOS. SLOWDOWN is a much
> older program than USBDOS, and the licensing and even my opinions of what the
>
On 2018-08-21 22:23 +0800, TK Chia wrote:
> However, both the intr ( ) implementation in Open Watcom, and the intr (
> ) implementation in suppl/src/intr.asm used when compiling with
> gcc-ia16, will _not_ try to load any flags --- including CF --- from
> reg.x.flags, so int 0x21 basically gets
Hello,
there seems to be an error in this commit, see below.
On at 2018-01-25 16:16 +, bartoldeman--- via Freedos-cvs wrote:
> Revision: 1781
> http://sourceforge.net/p/freedos/svn/1781
> Author: bartoldeman
> Date: 2018-01-25 16:16:21 + (Thu, 25 Jan 2018)
> Log Message:
That depends on whether you'd consider MSW 3.x or 4.x respectively to
constitute a complete new and different OS on top of MS-DOS =P
What is MSW?
Does this help?:
http://www.google.com/search?q=MSW+4.x+%22MS-DOS%22+DOS+kernel
Basically an abbreviation that doesn't suggest some sort of Win.
what are the chances of seeing a FreeDOS driver for the BtrFS
filesystem anytime soon?
I don't think it will happen.
As many of you may already know, BtrFS is poised to become the next
Linux standard filesystem very soon, replacing the ext family of
filesystems.
I don't even know of any
I think the big limitation will be addressable filesystem space. Btrfs
can support 2^64 files, and 16EB volumes. That's a wee bit too much
for DOS to handle.
Even if you have a Btrfs that's fairly small, say small enough to be
addressable by DOS,
Assuming the driver has enough space for its
it would be one of the best ways, to get panasonic USBASPI.SYS 2.27
(only!)
and matsushita
DI1000DD.SYS (motto hairu)
going on a usb drive, say a 1/2 terabyte one, like i've got,
then adapt everything over to the 4k-sector standard with
everyone thought of the lower interface
as to a block device driver that presents 4 KiB sectors.
regards,
C. Masloch
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library
Another additional note, as I went thinking about this a bit. Only
cluster values are stored in the FS (think FAT contents, FSINFO, and
start cluster fields of directory entries) apart from what is in the
*BPB, so a runtime upwards sector size transformation (say, from 512 B
to 4 KiB,
thanks
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style
Refer to a forum posting I made regarding this:
http://www.bttr-software.de/forum/forum_entry.php?id=10397
It discusses idling via Int28, Int2F.1680, and by issuing hlt
instructions. As explained I only use the latter two.
Regards,
(1) I'm talking about pure realmode, so 2Fh 1680h is what I need.
Yes, as I mentioned, if you're in real or V86 mode (not protected mode)
then attempting 2F.1680 via 31.0300 is of course impossible and not
necessary.
(2) HLT could be another option, but it is not what I am looking for,
as
Hi,
This doesn't seem to have received any answers yet.
I see the MBR code essentially loads the boot sector of the active
partition and puts it at address :7c00. Then the boot code is
executed by jumping to that address.
This is correct.
1. INT 0x13 with AH=0x42 does extended read
59 matches
Mail list logo
