Hi!
21-Июн-2004 23:20 [EMAIL PROTECTED] (Alain) wrote to
[EMAIL PROTECTED]:
>> A> I remember one for instance: it was possible with a MDA to have 704k
>> A> lower memory. Not interesting anymore, after the advent of VGA.
>> Why? Expanding base memory over VGA graphics segment is a nice featu
Hi,
One more opinion on this topic. I don't think it's a good idea that the
UMBs are chained into the main MCB chain.
UMBs are different from other memory blocks. For instance, if you are
using EMM386 to provide UMBs, you may get troubles with DMA because of
the mismatch of linear and physical a
Hi!
22-Июн-2004 09:46 [EMAIL PROTECTED] (Aitor Santamarэa Merino) wrote to
[EMAIL PROTECTED]:
ASM> One more opinion on this topic. I don't think it's a good idea that the
ASM> UMBs are chained into the main MCB chain.
This is property of the EMM386. But you may do (and undo) this also
manua
(before someone, e.g. Eric complains, mind that I was forced to use webmail in this
message, so I have no control over the format of the message)
- Mensaje Original -
Remitente: "Arkady V.Belousov" [EMAIL PROTECTED]
Destinatario: [EMAIL PROTECTED]
Fecha: Martes, Junio 22, 2004 11:41a
Hi!
22-Июн-2004 13:00 [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote to
[EMAIL PROTECTED]:
>>ASM> using EMM386 to provide UMBs, you may get troubles with DMA because of
>>ASM> the mismatch of linear and physical addresses.
>>FD currently compares buffer address (in dsk.c and blockio.c) with
>>ex
>Hi!
>22-éÀÎ-2004 13:00 [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote to
>[EMAIL PROTECTED]:
>>>ASM> using EMM386 to provide UMBs, you may get troubles with DMA
>because of
>>>ASM> the mismatch of linear and physical addresses.
>>>FD currently compares buffer address (in dsk.c and blockio.c)
>w
Hi!
22-Июн-2004 14:40 [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote to
[EMAIL PROTECTED]:
>>Ha! First, I don't know such (useful) programs, which use DMA and load
>>itself into "uppermost position" (LAST_FIT).
ase> Well, LBACACHE could eventually be a good candidate.
Do you mean, that LBA
Hi!
New fixes fot config.c:
- config now parsed in 5 passes: SWITCHES=/F/N and MENUCOLOR/MENUDEFAULT
parsed before menu, INSTALL and SET after DEVICE.
Lucho tests kernel with all my patches and says that he satisfied. Updated
romd-bin.rar kernel package available on his site.
Hello All,
Can anybody tell me if there is something that prevents using the
_whole_ PSP as an storage area in a TSR? I mean within the TSR extension
itself, I know the limitations when executing a program.
I'm specifically interested in FreeDOS particularities, in case they
differ form MS-DOS.
Arkady V.Belousov wrote:
Hi!
Arkady, I'll try to compile your kernel tonight, as I experienced some
hardware upgrade glitches the last 2 days.
as someone asked (I lost about 35 emails) : Lucho's site is at:
http://linux.tu-varna.acad.bg/~lig/
it contains the Romdsk stuff and the UDMA DOS-driver.
Arkady V.Belousov escreveu:
? _Now_ behavior of FD is same as with MS-DOS (ie. it not hangs when
base memory size is more than 640k after loading some driver).
I must agree that he has a point here ;-)
---
This SF.Net email sponsored by Bla
Eduardo Casino escreveu:
Hello All,
Can anybody tell me if there is something that prevents using the
_whole_ PSP as an storage area in a TSR? I mean within the TSR extension
itself, I know the limitations when executing a program.
I remember that some TSR did a little of that in the old days, I
On Mon, 2004-06-21 at 16:37, Alain wrote:
> tom ehlert escreveu:
>
> >
> > if the a000 block is ever merged into the lower memory area,
> > interesting things might happen.
>
> I remember one for instance: it was possible with a MDA to have 704k
> lower memory. Not interesting anymore, after th
13 matches
Mail list logo
