Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[Michael Brutman]

On Mon, Mar 20, 2023 at 3:05 PM Bret Johnson  wrote:

>
> Even though a 350 MHz K6-2 is WAY faster than my 3.3 GHz i5?  And again, I
> know it doesn't make any sense, but it's still true.
>
> As far as I can tell, the Emperor has no Clothes.
>
>
I'm confused by this.  You are claiming that a 350 Mhz K6-2 is "WAY" faster
than a 3.3 GHz i5?  In what respect?
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Ré : How to setup a compiler for FreePascal on Fedora Linux to FreeDOS 16 bit

[Paul Dufresne via Freedos-devel]

Yesterday I said:
>I'll show you the full file... even if I think I might have damage it a bit in 
>the long day:



Indeed fpc (the command lne one for Fedora x64) was not working anymore.

Here is the essential part (not copying back the full ~/.fpc.cfg [where ~ is 
your home directory in Linux]:

#IFDEF CPUI8086

# Must be the crosscompiler to FreeDOS

-Fu/usr/lib64/fpc/$fpcversion/units/msdos/80186-$fpcmemorymodel

-Fu/usr/lib64/fpc/$fpcversion/units/msdos/80186-$fpcmemorymodel/*

-Fu/usr/lib64/fpc/$fpcversion/units/msdos/80186-$fpcmemorymodel/rtl

#ELSE

# Must be the native Linux compiler

-Fu/usr/lib64/fpc/$fpcversion/units/$fpctarget

-Fu/usr/lib64/fpc/$fpcversion/units/$fpctarget/*

-Fu/usr/lib64/fpc/$fpcversion/units/$fpctarget/rtl

#ENDIF



In the #ELSE part, I change lib to lib64, because my Linux is 64 bits so the 
fpc units are there. [had copied verbatim from the website that part]



And now I can use the same config file for both (fpc for native x86-64 Linux 
target, and ppcross8086 for FreeDOS 16 bit target)



[paul@fedora mypas]$ whereis fp

fp: /usr/bin/fp /usr/share/man/man1/fp.1.gz



[paul@fedora mypas]$ dnf provides /usr/bin/fp

Dernière vérification de l’expiration des métadonnées effectuée il y a 1 day, 
3:44:52 le dim 19 mar 2023 16:30:32.

fpc-ide-3.2.2-10.fc38.x86_64 : Free Pascal Compiler - terminal-based IDE

Dépôt       : @System

Correspondances trouvées dans  :

Nom de fichier : /usr/bin/fp



So, fp, the IDE, use a fpc.cfg file in the directory, and create one if it does 
not exist.

So even before fixing my ~/.fpc.cfg file, fp IDE was working for me.___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] I wish I had a boot.log file

[Mercury Thirteen via Freedos-devel]

Right, same basic idea. I guess the main difference is using the spare video 
memory as a starting buffer, but regular ol' RAM would be fine too. :)

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Monday, March 20th, 2023 at 7:23 PM, jer...@shidel.net  
wrote:

> Hi,
>
>> On Mar 20, 2023, at 6:35 PM, Mercury Thirteen via Freedos-devel 
>>  wrote:
>>
>> I realize this may be more trouble than it's worth, but it's technically 
>> possible to write up a small "shim" program which simply hooks the character 
>> printing interrupts and copies any characters passed to a small memory 
>> buffer* before forwarding them to the regular printing interrupt. This shim 
>> would need to be named COMMAND.COM so that it is loaded first after the 
>> kernel, and once this hook is established the shim would then pass control 
>> on to the real COMMAND.COM.
>>
>> * As I recall, the basic text mode offers multiple - what is it, eight? - 
>> pages of text, and this extra video memory could possibly be used as amemory 
>> buffer to avoid cutting into the available memory which applications could 
>> otherwise use. Once an XMS driver is loaded, the contents could be copied to 
>> an XMS block, freeing up the video memory for use by applications who 
>> actually use it for its intended purpose.
>>
>> Ok, all done. Now you're all free to shoot that idea full of holes! haha
>
> Same basic Idea as what I was saying. :-)
>
> Although, I’d do it as a device driver that you could load first, then switch 
> from temp storage to XMS when the memory drivers have been loaded. Finally, 
> after the boot process is complete, you could turn off logging or switch to 
> StdErr only logging. But, most programs don’t use that device and just output 
> errors to StdOut.
>
> Anyhow, the driver method would also capture messages by other device drivers 
> before the command shell is even loaded.
>
> It is not actually very difficult to do. But, like everything, it still would 
> take at least some time to make and test.
>
> Maybe I’ll whip one up if I get bored or just want to work on something other 
> than my current project for a little while.
>
> :-)
>
> Jerome
>
>> Sent with [Proton Mail](https://proton.me/) secure email.
>>
>> --- Original Message ---
>> On Monday, March 20th, 2023 at 9:45 AM, jer...@shidel.net 
>>  wrote:
>>
>>> Hi Paul,
>>>
 On Mar 19, 2023, at 11:29 AM, Paul Dufresne via Freedos-devel 
  wrote:

 So many messages on boot I cannot scroll back.
 If only the boot process would also copy everything in a boot.log file!
>>>
>>> At present, that is not really practical. Actually for a lot of the boot 
>>> processes on the LiveCD, not currently even possible.
>>>
>>> When the LiveCD boots, the system is an unknown state. During the startup, 
>>> it needs to figure out a lot of different things. There is no known 
>>> location it could write any such messages that could be later viewed. 
>>> During the early stages of the boot process, it is simply not reliably 
>>> possible at present.
>>>
>>> As things progress and it works out some stuff, it “could” write such a log 
>>> to the a hard drive if present. But being a LiveCD, that would be a very 
>>> bad idea and counter to user expectations. It should not modify the 
>>> contents of any drive unless explicitly told to do so.
>>>
>>> Therefore, it tries to bring up a RAM drive for the purpose of having 
>>> temporary storage for things like I/O redirection and extracting software 
>>> packages. By this point, a “boot.Log” would be of little use, would 
>>> complicate the process and possibly eat up precious RAM disk space.
>>>
>>> All that being said, it would be possible to create fairly simple device 
>>> driver that could trap and log all displayed text to XMS memory (when 
>>> present). But, I’m very busy on other things for the moment.
>>>
>>> Maybe after I finish the next stage of my current project, I’ll whip one up.
>>>
>>> Jerome
>>>
 ___
 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] I wish I had a boot.log file

[jerome]

Hi, 

> On Mar 20, 2023, at 6:35 PM, Mercury Thirteen via Freedos-devel 
>  wrote:
> 
> I realize this may be more trouble than it's worth, but it's technically 
> possible to write up a small "shim" program which simply hooks the character 
> printing interrupts and copies any characters passed to a small memory 
> buffer* before forwarding them to the regular printing interrupt. This shim 
> would need to be named COMMAND.COM so that it is loaded first after the 
> kernel, and once this hook is established the shim would then pass control on 
> to the real COMMAND.COM.
> 
> * As I recall, the basic text mode offers multiple - what is it, eight? - 
> pages of text, and this extra video memory could possibly be used as a memory 
> buffer to avoid cutting into the available memory which applications could 
> otherwise use. Once an XMS driver is loaded, the contents could be copied to 
> an XMS block, freeing up the video memory for use by applications who 
> actually use it for its intended purpose.
> 
> Ok, all done. Now you're all free to shoot that idea full of holes! haha

Same basic Idea as what I was saying. :-)

Although, I’d do it as a device driver that you could load first, then switch 
from temp storage to XMS when the memory drivers have been loaded.  Finally, 
after the boot process is complete, you could turn off logging or switch to 
StdErr only logging. But, most programs don’t use that device and just output 
errors to StdOut. 

Anyhow, the driver method would also capture messages by other device drivers 
before the command shell is even loaded.

It is not actually very difficult to do. But, like everything, it still would 
take at least some time to make and test. 

Maybe I’ll whip one up if I get bored or just want to work on something other 
than my current project for a little while.

:-)

Jerome

> 
> Sent with Proton Mail  secure email.
> 
> --- Original Message ---
> On Monday, March 20th, 2023 at 9:45 AM, jer...@shidel.net  
> wrote:
> 
>> Hi Paul,
>> 
>>> On Mar 19, 2023, at 11:29 AM, Paul Dufresne via Freedos-devel 
>>> >> > wrote:
>>> 
>>> So many messages on boot I cannot scroll back.
>>> If only the boot process would also copy everything in a boot.log file!
>>> 
>> 
>> At present, that is not really practical. Actually for a lot of the boot 
>> processes on the LiveCD, not currently even possible. 
>> 
>> When the LiveCD boots, the system is an unknown state. During the startup, 
>> it needs to figure out a lot of different things. There is no known location 
>> it could write any such messages that could be later viewed. During the 
>> early stages of the boot process, it is simply not reliably possible at 
>> present. 
>> 
>> As things progress and it works out some stuff, it “could” write such a log 
>> to the a hard drive if present. But being a LiveCD, that would be a very bad 
>> idea and counter to user expectations. It should not modify the contents of 
>> any drive unless explicitly told to do so.
>> 
>> Therefore, it tries to bring up a RAM drive for the purpose of having 
>> temporary storage for things like I/O redirection and extracting software 
>> packages. By this point, a “boot.Log” would be of little use, would 
>> complicate the process and possibly eat up precious RAM disk space. 
>> 
>> All that being said, it would be possible to create fairly simple device 
>> driver that could trap and log all displayed text to XMS memory (when 
>> present). But, I’m very busy on other things for the moment. 
>> 
>> Maybe after I finish the next stage of my current project, I’ll whip one up. 
>> 
>> Jerome
>> 
>>> 
>>> ___
>>> 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] I wish I had a boot.log file

[Mercury Thirteen via Freedos-devel]

I realize this may be more trouble than it's worth, but it's technically 
possible to write up a small "shim" program which simply hooks the character 
printing interrupts and copies any characters passed to a small memory buffer* 
before forwarding them to the regular printing interrupt. This shim would need 
to be named COMMAND.COM so that it is loaded first after the kernel, and once 
this hook is established the shim would then pass control on to the real 
COMMAND.COM.

* As I recall, the basic text mode offers multiple - what is it, eight? - pages 
of text, and this extra video memory could possibly be used as amemory buffer 
to avoid cutting into the available memory which applications could otherwise 
use. Once an XMS driver is loaded, the contents could be copied to an XMS 
block, freeing up the video memory for use by applications who actually use it 
for its intended purpose.

Ok, all done. Now you're all free to shoot that idea full of holes! haha

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Monday, March 20th, 2023 at 9:45 AM, jer...@shidel.net  
wrote:

> Hi Paul,
>
>> On Mar 19, 2023, at 11:29 AM, Paul Dufresne via Freedos-devel 
>>  wrote:
>>
>> So many messages on boot I cannot scroll back.
>> If only the boot process would also copy everything in a boot.log file!
>
> At present, that is not really practical. Actually for a lot of the boot 
> processes on the LiveCD, not currently even possible.
>
> When the LiveCD boots, the system is an unknown state. During the startup, it 
> needs to figure out a lot of different things. There is no known location it 
> could write any such messages that could be later viewed. During the early 
> stages of the boot process, it is simply not reliably possible at present.
>
> As things progress and it works out some stuff, it “could” write such a log 
> to the a hard drive if present. But being a LiveCD, that would be a very bad 
> idea and counter to user expectations. It should not modify the contents of 
> any drive unless explicitly told to do so.
>
> Therefore, it tries to bring up a RAM drive for the purpose of having 
> temporary storage for things like I/O redirection and extracting software 
> packages. By this point, a “boot.Log” would be of little use, would 
> complicate the process and possibly eat up precious RAM disk space.
>
> All that being said, it would be possible to create fairly simple device 
> driver that could trap and log all displayed text to XMS memory (when 
> present). But, I’m very busy on other things for the moment.
>
> Maybe after I finish the next stage of my current project, I’ll whip one up.
>
> Jerome
>
>> ___
>> 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] DOS Swappable Data (SDA) Area

[Rugxulo]

Hi again,

On Mon, Mar 20, 2023 at 5:06 PM Bret Johnson  wrote:
>
> This is something much more serious than a "tradeoff" or a
> "regression".  My new i5 CPU appears to be spending _at least_ 99%
>  of its resources NOT processing OpCodes and NOT accessing the
>  cache (because there isn't one).  And the problem is blamed on
> "sub-optimal code".  I don't know what the CPU is doing with all
> those resources it has, but I do know what it's NOT doing.  I do know
> that what's going on inside a CPU is very complicated.  Call me naive,
> but I always thought the primary purpose of a CPU was to process
> OpCodes.  Silly me.
>
> >>  I think it probably
> >> would be -- I certainly think it would be WAY faster than my 3.3 GHz
> >> i5.
>
> > nope.
>
> Even though a 350 MHz K6-2 is WAY faster than my 3.3 GHz i5?
> And again, I know it doesn't make any sense, but it's still true.

Self-modifying code??

(joking) Or maybe you have FDAPM loaded?  ;-)


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[Bret Johnson]

Tom:

Often when you say something on this forum, I am reminded of a stanza from the 
Tom Petty song, "Into the Great Wide Open."  The stanza is "Rebel Without a 
Clue."  I'm sure you think the same of me.

>> In fact, the new 3.3 GHz i5 CPU runs about 10 times faster than the
>> 33 MHz 386 did, not more than 100 times like you would expect.
>
> this doesn't make sense AT ALL.
> even in your own source,

> Generic  AMDAM386DX 33   334
> Unknown  Intel  Pentium-3  650  4611
> Generic  AMDK6-2   350  4780

> you document that an AMD k6-2 350 MHz is 15 times faster then a 33
> MHz 386 CPU. And we all KNOW that an Intel i5-4590 running at 3.30
> GHz is faster then AMD K6-2.

Not true.  You just ASSUME it must be faster.  When you actually do a real-life 
test, it isn't.  And I'm fully aware that it doesn't make any sense -- which is 
exactly why I'm pointing it out.  And I will repeat my earlier statement -- 
there is something VERY wrong going on here.

The test I ran said that my 3.3 GHz i5 (with the Cache enabled) ran at about 
3400 Slowdown Units (SU's), which is about 10 times faster than the AMD 33 MHz 
386, and WAY SLOWER than the 350 MHz AMD K6-2.

I know you don't believe it and that you don't think anybody else should 
believe it either.  You think I must be doing something wrong, but I'm not.

> for those who want to search themself, search the source for
> 'WasteLoop'.
>
> it all boils down to some garbage (does nothing sensible) code,
> including
>
>  MOV  CX,2   ;Do two bits
>  REPE CMPSB  ;Compare the string to itself
>  ADD  AL,220 ;Give AL a number
>  ADD  AX,3456;Give AX a number
>  MOV  BX,DummyVar;BX=address of DummyVar
>  MOV  DummyVar,AX;Store it in DummyVar
>  SUB  AX,ES:DummyVar ;AX=0
>  XLATB   ;AL=[BX+(unsigned)AL]
>  SAL  BX,CL  ;Multiply BX by 2, CL times
>  MOV  CL,3   ;Divide by 3
>  SAR  DummyVar,CL;Signed divide DummyVar by 2, 3 times
>  SBB  AX,8   ;Subtract with borrow
>  AAM ;ASCII adjust after multiply
>   (AL/10:AH=Quo,AL=Rem)
>  DAS ;Decimal adjust after subtraction
>  MOV  DX,21h ;Do an
>  IN   AL,DX  ;  IN
>  POP  CX ;Restore the loop counter
>  DEC  CX ;Decrement it
>  JZ   WasteExit  ;If it's 0, we're done
>  JUMP WasteLoop  ;If it's not, do it all again
>
>  looks innocent enough. the problem child is
>  IN   AL,DX  ;  IN

Does the fact that it's called "WasteLoop" or what the documentation for 
SLOWDOWN says or what the comments in the source code says mean anything to you 
at all?  The code in nonsensical because it's sole purpose is to waste the 
CPU's resources by having it do something that provides no useful output -- it 
just wastes time so the CPU can't do anything truly useful.  THAT'S WHAT IT'S 
DESIGNED TO DO.  That's how it slows the computer down.  It performs its 
function perfectly well.

> and the fact that the 'IN'-bus doesn't run significant faster then it
> did in 386's days (there is a reason modern disks are accessed with
> (U)DMA, not IN). the speed depends on the chipset and the actual port
> address, but is more like 10 MHz then 3 GHz.

And I/O Port 21h has nothing to do with disk access or UDMA.  And the purpose 
of the code is to slow things down.  So, your point is ...?

>> I then ran a second test where I disabled the cache on the CPU (you
>> can do this with my CPUCACHE program which is included with
>> SLOWDOWN).  This is a more "apples-to-apples" comparison of the
>> _actual_ CPU speed than the original test with the cache enabled.
>
> it's not. almost EVERYBODY knows that GHz CPU's just don't make sense
> without cache, because it is always waiting for the next instruction
> coming from memory. and memory access times are basically unchanged
> for the last 30 years at 60-100 ns. so a modern CPU without cache
> spends all the time waiting for CPU instructions coming from memory.

All CPUs since the 486 have caches.  As my ACTUAL test results indicate above, 
a 350 MHz AMD K6-2 runs WAY faster than my 3.3 GHz i5, and they both have 
caches.

I KNOW you don't believe the results of my tests because they don't make any 
sense to you, and they don't make any sense to me either.  BUT THEY ARE STILL 
TRUE.  Denying real-life test results or just making excuses for why they don't 
make any sense or declaring the test algorithm to be "nonsense" isn't going to 
help your case.

>> When I did this test, the computer ran almost exactly the same speed
>> as the 33 MHz 386 (it was about 3% faster, not 10,000% faster as
>> "logic" would dictate).
>
> the is exactly no "logic" in your argument.

A 33 MHz AM386DX CPU (which doesn't have a cache) runs at 334 Slowdown Units, 
and a 3.3 GHz Intel i5 with the cache disabled runs at almost exactly the same 
speed.  That's

Re: [Freedos-devel] How to setup a compiler for FreePascal on Fedora Linux to FreeDOS 16 bit

[Rugxulo]

Hi,

On Sun, Mar 19, 2023 at 11:16 PM Paul Dufresne via Freedos-devel
 wrote:
>
> I am thinking about using FreePascal to write programs for DOS.
>
> Writing an "hello world" program in FreePascal for 32 bit DOS (Go32) is easy, 
> because the fpc package can be installed
> with fdimples from the Live installer.
>
> But there is no 16 bit FreePascal directly for DOS.
> So one have to used some other OS like Windows or Linux, and use a FreePascal 
> cross-compiler to 80186  16 bit DOS.

If you unpack / install the Windows version (ppcross8086), you can
then use it with HX DOS extender (so both DOS host and target):

* https://github.com/Baron-von-Riedesel/HX/releases

> I say 80186, because this is the precompiled version, you would have to 
> compile your own cross-compiler for like 386 16 bit DOS.
> And now I am realizing that 80186 is kind of too advanced for FreeDos that 
> prefer 8086... but I think the older
> FreePascal can do is 80186.

Like you later mentioned, it does also support 8086 (and 286, 386 ...
not sure how "improved" those are, though).

> Rather than using fpc to compile a .pas file, you use: ppcross8086
> as describe in:
> https://wiki.freepascal.org/DOS
> which is not too clear, that's why I am writing this.

The Wiki is a bit outdated (esp. now that it's not only a snapshot but
an official release). But generally you use a (separate) cross
compiler for anything other than 386 (i.e. ppc386). Even the 64-bit
compiler (ppcx64) is a cross compiler, IIRC.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Bug or Not

[jerome]

Hello,

> On Mar 19, 2023, at 10:27 PM, Prime Seal  wrote:
> 
> Mr J Hall here is the links to the video of FreeDOS after configuration.
> The errors after configuring fdauto.bat file
> YouTube: https://www.youtube.com/watch?v=h5_fXGL36yo 
> 
There a a couple problems with your additions. 

First, that is a lot of environment variables. 

As Willi suggested, you may want to increase you environment space. 

But, there is a more serious problem…

You have 11 variables with a minimum of 15 characters each. Which is over 150 
characters.  Which you then attempt to append into the PATH variable. This is 
not possible. Those variables are expanded before the set a new variable. This 
means toy are attempting to use a command line of well over the 125 character 
limitation in FreeCOM batch files. 

You need to go about this a different way. 

If you want easy access to all of those tools, here is what I suggest. 

1) return the FDAUTO.BAT back to its original state.
2) create a environment setting batch file under the C:\FREEDOS\LINKS\ 
directory to configure things for the different tools.
3) create an “unset” batch under that directory as well.

This would easily allow you to select or switch development environments.

Here is a quick example of files you could create under the links directory….


NODEVENV.BAT

@echo off

rem remove any development specific environment varaibles
set LUAC=
set WATC=
set FASM=
set BCC=
set DGP=
set DJGPP=
rem add more as needed to clean stuff up

rem Return the system path to it’s default setting.
if not “%DEFAULTPATH%” == “” set PATH=%DEFAULTPATH%
set DEFAULTPATH=%PATH%

FASM.BAT

@echo off

rem clear any existing development settings
call %DOSDIR%\LINKS\NODEVENV.BAT

set FASM=C:\DEVEL\FASM
set PATH=%FASM%;%PATH%
cd %FASM%
echo Switched to FASM development environment.


Then simply typing “FASM” will switch everything you need to work with FASM. 
Since, the C:\DEVEL\FASM directory would be first in the PATH setting, you do 
not need to worry about any file name collisions. For example, typing FASM 
again would now try to run the C:\DEVEL\FASM\FASM.EXE and not the FASM.BAT file.



> 
> Kind regards
> Seal Prime
> ___
> 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] Bug or Not

[Prime Seal]

The solution has worked.
Thanks Wilhelm Spiegl

On Mon, Mar 20, 2023 at 1:44 PM Wilhelm Spiegl 
wrote:

> Hi, I did not check the whole video, but there was a message: "Environment
> full?"
>
> Possible solution:
> edit fdconfig.sys, goto the last lines and search for: "/E:1024". Change
> 1024 to 2048 (maybe a little more higher).
>
> Did it help?
>
> Thx for response
>
> Willi
>
>
> *Sent:* Monday, March 20, 2023 at 3:27 AM
> *From:* "Prime Seal" 
> *To:* "Jim Hall" , Freedos-devel@lists.sourceforge.net
> *Subject:* [Freedos-devel] Bug or Not
> Mr J Hall here is the links to the video of FreeDOS after configuration.
> The errors after configuring fdauto.bat file
> YouTube: https://www.youtube.com/watch?v=h5_fXGL36yo
>
> Kind regards
> Seal Prime
> ___ 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] if exist %TEMP%\fdlive.dat goto CompletelyLoaded [not done]

[jerome]

Hi Paul, 

> On Mar 19, 2023, at 11:12 AM, Paul Dufresne via Freedos-devel 
>  wrote:
> 
> Testing FDT2303Live.iso in QEMU.
> Seems I always get:
> Cute mouse loaded
> then
> I think the line mentioned in title does not find fdlive.dat...
> So I always get the message:
> FDLIVE_ERROR: Unable to load all packages (probably need more ram) ... had 
> given 2Gb of ram to -m 2048M of Qemu
> part of A:\freedos\bin\fdlive.bat file.
> 
> Maybe too short email... sorry.
> 
> So what is this fdlive.dat file ... and from where should it come from?

FDLIVE.DAT is created by the batch during the boot process when certain 
prerequisites have been completed. Primarily, that is the existence of a RAM 
drive. 

Then the file acts as a “flag” during package extraction. As long as the file 
continues to exist, the boot process will continue to extract the default Live 
Environment packages from it’s list. 

If an error occurs, like there was insufficient RAM drive space for extraction, 
the FDLIVE.DAT file is deleted and it aborts extracting any more packages. 

After finishing the extraction process, it again check for FDLIVE.DAT. If it 
still exists, then everything was extracted successfully. Otherwise, something 
went wrong. There are a few uncommon reasons this could happen. But, the most 
likely issue is insufficient RAM disk space. Which is the reason for the 
message. 

Finally, since there is no longer a need for the flag file, it is deleted.

There is a known issue regarding QEMU. For whatever reason, it does not like 
the primary RAM disk driver, SHSURDRV. So, the boot process does not even try 
to load that one. Instead, it immediately falls back to the alternate driver 
SRDXMS.SYS.  At present when using the alternate driver, it limits the RAM 
DRIVE size from 32K to 8M and is intended only for temp I/O redirection 
storage. 

I do not recall the reason I limited it to 8M. Possibly there were issues on 
large sized RAM disks. Possibly, I just did not test anything larger because it 
only seems to happen on QEMU (which I rarely use). I don’t recall. 

So, what I will do is add a couple attempts for larger sizes to the alternative 
RAM disk driver for T2304. And, we will see what happens. It will require 
testing to insure the RAM drive functions correctly at larger sizes. 

128M, 96M, 64M, 48M, 32M, 24M, 16M, 12M have been added to the existing 8M, 4M, 
2M, 1M, 512K, 256K, 128K, 64K, 32K sizes already present for the alternate 
driver.

Jerome


> 
> ___
> 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] I wish I had a boot.log file

[jerome]

Hi Paul,

> On Mar 19, 2023, at 11:29 AM, Paul Dufresne via Freedos-devel 
>  wrote:
> 
> So many messages on boot I cannot scroll back.
> If only the boot process would also copy everything in a boot.log file!
> 

At present, that is not really practical. Actually for a lot of the boot 
processes on the LiveCD, not currently even possible. 

When the LiveCD boots, the system is an unknown state. During the startup, it 
needs to figure out a lot of different things. There is no known location it 
could write any such messages that could be later viewed. During the early 
stages of the boot process, it is simply not reliably possible at present. 

As things progress and it works out some stuff, it “could” write such a log to 
the a hard drive if present. But being a LiveCD, that would be a very bad idea 
and counter to user expectations. It should not modify the contents of any 
drive unless explicitly told to do so.

Therefore, it tries to bring up a RAM drive for the purpose of having temporary 
storage for things like I/O redirection and extracting software packages. By 
this point, a “boot.Log” would be of little use, would complicate the process 
and possibly eat up precious RAM disk space. 

All that being said, it would be possible to create fairly simple device driver 
that could trap and log all displayed text to XMS memory (when present). But, 
I’m very busy on other things for the moment. 

Maybe after I finish the next stage of my current project, I’ll whip one up. 

Jerome

> 
> ___
> 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] Bug or Not

[Wilhelm Spiegl]

Hi, I did not check the whole video, but there was a message: "Environment full?"

 

Possible solution:

edit fdconfig.sys, goto the last lines and search for: "/E:1024". Change 1024 to 2048 (maybe a little more higher).

 

Did it help?

 

Thx for response

 

Willi

 
 

Sent: Monday, March 20, 2023 at 3:27 AM
From: "Prime Seal" 
To: "Jim Hall" , Freedos-devel@lists.sourceforge.net
Subject: [Freedos-devel] Bug or Not



Mr J Hall here is the links to the video of FreeDOS after configuration.

The errors after configuring fdauto.bat file

YouTube: https://www.youtube.com/watch?v=h5_fXGL36yo

 

Kind regards

Seal Prime

___ 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