At 01:18 AM 8/11/2006 +0400, Arkady V.Belousov wrote:
>MD> I suppose it could be an artifact of GDB breaking into the program, but
>MD> since Stargunner is an infinite loop at that point, and this would
>qualify,
>MD> I'm thinking it's real.
>
> This may mean only that port emulator code is
Hi!
10--2006 14:49 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
MD> The loop routine is ANDing the IN DX value with 9 and then looking for bit
MD> 0 (1) match, or reloop. Guess that's an out of vertical, out of horizontal
MD> status check.
No - this is c
At 10:55 PM 8/10/2006 +0400, Arkady V.Belousov wrote:
>Hi! 10-á×Ç-2006 13:28 [EMAIL PROTECTED] (Michael Devore)
>wrote to freedos-devel@lists.sourceforge.net: MD> GDB remoted to Qemu
>shows Stargunner in an infinite loop reading from port MD> 3DAh, Just
>interesting, what it expects there?
Hi!
10-Авг-2006 13:28 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
MD> GDB remoted to Qemu shows Stargunner in an infinite loop reading from port
MD> 3DAh,
Just interesting, what it expects there? I suggest, bits 3 and 0
(vertical and horizontal retrace)?
At 06:35 PM 8/8/2006 -0500, I wrote:
>And sadly, it appears that while DOOM works in VPC and Qemu, Stargunner
>remains problematic in virtual environments, though works here in real
>DOS.
GDB remoted to Qemu shows Stargunner in an infinite loop reading from port
3DAh, so looks like it's a video
Hi!
9-Авг-2006 12:11 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
>>The current implementation seems very simple, for example, the XMS functions
>>to enable disable A20 usually increase/decrease a counter
MD> It is simple, deliberately so since its whole purpos
At 08:39 PM 8/9/2006 +0200, Eric Auer wrote:
>... and yes, the "local" enable/disable can be quite dummy:
>Apps call local-off when they no longer need that a20 on, but
>they that does not mean that it has to be actually off after
>the call :-). Of course, calling local-on has to have the
>"effect
At 07:35 PM 8/9/2006 +0200, you wrote:
> > I didn't know if you were still working on it or whether it was just an
> > example patch. If an example, it wasn't worth your time (or mine,
> frankly)
> > to go into further detail. If you're interested, the removal of the
> 16-bit
> > stack check an
> Any passing kernel people know which of the A20 control calls are
> used? Is it all global function 3 and 4? Local 5 and 6? Or must both
> type of calls be supported.
kernel.asm, 882
global _ENABLEA20
_ENABLEA20:
mov ah,5
UsingXMSdriver:
push bx
call far [cs:_XMSDriverAddr
> I didn't know if you were still working on it or whether it was just an
> example patch. If an example, it wasn't worth your time (or mine, frankly)
> to go into further detail. If you're interested, the removal of the 16-bit
> stack check and adjustment for PM_Entry "appears" to expose cer
At 11:54 AM 8/9/2006 +0200, Japheth wrote:
>I meant the first, but also think this option should be implemented pre-1.0.
>The current implementation seems very simple, for example, the XMS functions
>to enable disable A20 usually increase/decrease a counter
It is simple, deliberately so since its
At 11:54 AM 8/9/2006 +0200, Japheth wrote:
>This may be true, but I dont know what you mean with "it appears", possibly
>you should be more specific.
I didn't know if you were still working on it or whether it was just an
example patch. If an example, it wasn't worth your time (or mine, frankly
Hi!
9-Авг-2006 11:54 [EMAIL PROTECTED] (Japheth) wrote to
freedos-devel@lists.sourceforge.net:
>> If you mean "optional" in that there should an option added (post-1.0) to
>> control A20 for potentially complex machinations (e.g. directly accessing
J> I meant the first, but also think this option
> If you mean "optional" in that there should an option added (post-1.0) to
> control A20 for potentially complex machinations (e.g. directly accessing
> DOS structures at a time where HMA is mapped out), then most should agree
> that an A20 handler inhibit option should be on the to-do list. I
Hi,
he is also "working" on DPMIONE. Just contact him.
Bye
On Wed, 09 Aug 2006 09:48:40 +0200, Michael Devore
<[EMAIL PROTECTED]> wrote:
> Didn't know he was still working on it. Last version dates back more
> than
> three years ago, right? I can't lend out the machine and whatever is
> h
Michael Devore wrote:
> Didn't know he was still working on it. Last version dates back more than
He told so to me some month ago.
> three years ago, right? I can't lend out the machine and whatever is
386SWAT Version 6.06 from end of March 2004.
Robert Riebisch
--
BTTR Software
http://www.
At 09:36 AM 8/9/2006 +0200, Robert Riebisch wrote:
>Michael Devore wrote:
>
> > DOS. Given that the best protected mode debugger, 386SWAT, is fatally
> > incompatible with my FreeDOS development machine, I'm afraid that leaves me
>
>Did you report these problems to Bob Smith already?
Didn't know
Michael Devore wrote:
> DOS. Given that the best protected mode debugger, 386SWAT, is fatally
> incompatible with my FreeDOS development machine, I'm afraid that leaves me
Did you report these problems to Bob Smith already?
Robert Riebisch
--
BTTR Software
http://www.bttr-software.de/
---
At 03:50 PM 8/8/2006 +0200, Japheth wrote:
>And I disabled this feature temporarily not because of speed reasons, but
>because there are situations thinkable where this "feature" may cause a crash.
>
>Such situations may be rare and almost impossible if DOS is loaded in the
>HMA,
>but they exist.
Hi!
8-Авг-2006 06:45 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
>>So, BL should be modified only in case of error. Not a big deal, I suggest
MD> No, I think it is proper to ensure that BL should be set to a nonerror code
MD> condition. I won't change the exi
Hello Eric,
> In summary, I would say it might be nice to have a command
> line option "lock a20 to on" for emm386, for example after
> FreeDOS 1.0 is done. You should do some benchmarks on a slow
> 386sx PC in the meantime ;-). By the way, it also might be
> nice to have an option "turn a20 on n
Eric Auer wrote:
>> Also the call to INT67/3F was also commented out just temporarily
>> and reactivated later. It's a feature!!! :)
>
> As this means "you temporarily locked the real and virtual A20
> to on", and as you call it a "feature", I have two comments...
I called the current implementat
> Also the call to INT67/3F was also commented out just temporarily
> and reactivated later. It's a feature!!! :)
As this means "you temporarily locked the real and virtual A20
to on", and as you call it a "feature", I have two comments...
1. toggling the virtual A20 by remapping a few pages is
I also read this in RBIL and changed it temporarily to find the "/NOX2MAX32"
bug and somehow this version has found the way in the Emm386 being uploaded.
But even MS Himem clears BL if it returns AX=1, so there should be no need to
modify anything.
Also the call to INT67/3F was also commented o
At 03:25 PM 8/8/2006 +0400, Arkady V.Belousov wrote:
> MD> No, doesn't look right. A20 handling was turned off,
> Japhet not tun off A20 handling, he just comment out call to INT67/3F.
Which turns off A20 handling enable/disable, unless it's resupported
elsewhere. It's straight-forward l
Hi!
8-Авг-2006 05:29 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
>> > What about fix for issue with DOOM, which you found under VPC?
>>MD> 2) (hopefully) the protected mode
>>MD> stack fix or whatever's going on with certain DOS-extended stuff under VPC
Hi!
8-Авг-2006 05:11 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
>>If you wish, I extract for you from Japhet' work fix for "sti/ret 2" bug
>>(in new15 proc)
MD> I already revectored that to the new IRET handling routine when you
MD> mentioned it earlier on li
At 05:11 AM 8/8/2006 -0500, I wrote:
> > What about fix for issue with DOOM, which you found under VPC?
>
>MD> 2) (hopefully) the protected mode
>MD> stack fix or whatever's going on with certain DOS-extended stuff under VPC
>^^^
>T
At 01:32 PM 8/8/2006 +0400, you wrote:
>If you wish, I extract for you from Japhet' work fix for "sti/ret 2" bug
>(in new15 proc)
I already revectored that to the new IRET handling routine when you
mentioned it earlier on list. CMC is slightly neater code, but not enough
to go back in and goo
Hi!
8-Авг-2006 02:50 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
>> Fine. Archive with build subsystem I re-send you again in next
>> letter. There also will be (again) present patch, to fix compatibility
>> with TC/BC (and it fixes bug in useful.c).
MD>
At 03:49 AM 8/8/2006 +0400, Arkady V.Belousov wrote, and I reconstituted:
>MD> Here's my final offer: I'll split off a new subdirectory on the source
>MD> tree, call it TCBUILD or somesuch (but avoiding the temptation to call it
>MD> ARKADY), and you can put all your shiny new C source changes in
Hi!
7--2006 13:14 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
>>MD> to "EMM386 may never get build subsystem".
>> Yes, I fear, it may never get _working_ build subsystem.
MD> You mean working for Arkady?
For me too.
MD> Ok, if you're sure that you
At 11:07 PM 8/5/2006 +0400, Arkady V.Belousov wrote:
>MD> I still can't read your list mails very well,
>
> In this letter, there shouldn't be 8-bit characters, so recoding
>through base64 shouldn't happen. Is it readable to you?
Yes.
>MD> to "EMM386 may never get build subsystem".
>
>
... and somehow I accidentally hit a keyboard shortcut for Send. :)
Anyway, continuing my previous message:
On the first boot, I got a lot of "No package found: owatcomx"-like
messages. It would be nice if these would not show up (>NUL or similar)
since those packages are not even on the base
Blair Campbell wrote:
> Uploaded to
> www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0-Testing/fdbasecd.iso
> is an updated BASE CD-ROM ISO. Hopefully, the bugs that plagued users
> of the last distribution should be gone, and I would greatly
> appreciate testing from ones where
Thank you very much!
> - XFdisk is now the default partitioner due to Fdisk bugs not being
> fixed. Fdisk is still available as an option however.
Good idea, I like XFdisk much more and it includes a good boot loader.
> - DOSLFN is now in the BASE diskset since long filenames are becoming
> inc
Uploaded to
www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0-Testing/fdbasecd.iso
is an updated BASE CD-ROM ISO. Hopefully, the bugs that plagued users
of the last distribution should be gone, and I would greatly
appreciate testing from ones where it mangled the former contents
37 matches
Mail list logo
