Re: [Freedos-kernel] ke2042: nasm fails to assemble files during build time

[H. Peter Anvin]

On 11/29/16 12:50, Travis Siegel wrote:
>
> Because, apparently the nasm being called isn't in c:\devel\nasm, so 
> change the path in the nasm.bat file to point to the proper place, and 
> the problem should be solved.  Either solution will work.
> 

But why the batch file in the first place?  It truly makes no sense: it
pollutes the namespace equally, and can just cause problems (e.g. in the
case of more than 9 arguments.)  Not to mention slowing down a make.

-hpa



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

Re: [Freedos-kernel] ke2042: nasm fails to assemble files during build time

[H. Peter Anvin]

On 11/24/16 00:59, Mateusz Viste wrote:
> 
> Hi,
> 
> Your problem is related to the fact that your "nasm" command doesn't call 
> nasm.exe directly. Instead, it calls a batch file named nasm.bat which 
> has been placed in your %PATH% by the FDNPKG installer. This nasm.bat 
> file is pretty straight-forward:
> 
>   @ECHO OFF
>   C:\DEVEL\NASM\NASM.EXE %1 %2 %3 %4 %5 %6 %7 %8 %9
> 
> While in theory such trick should work (and it does work with most other 
> utilities out there), somehow it doesn't play out right with nasm. Simply 
> edit your CONFIG.BAT to set its XNASM variable to the full path to your 
> copy of nasm.exe, and you're done. Enjoy!
> 

And pray tell, why?

-hpa



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

Re: [Freedos-kernel] EXT3 support

[H. Peter Anvin]

On August 26, 2016 12:26:52 AM PDT, Eric Auer  wrote:
>
>Hi HPA! The boot sector takes a BIOS drive number of the
>to-be-booted drive from the MBR, which can take it from
>the BIOS. There also are patches to take the MBR item by
>pointer from the MBR, but those are not used by default.
>
>So I guess the kernel could take the drive number from a
>boot sector, which at the moment is easy because the boot
>sector stores the value from the MBR in the drive byte of
>the boot sector loaded into RAM, which is a predictable
>location in general. Might be fun for booting from 0x81.
>
>>> support for EXT3 in the kernel would indeed be large/complex.
>
>Would not do that, but would boot DOS by MEMDISK and load a
>full EXT3 driver from there later :-) Same for ISO9660, but
>there "read files from ISO root dir" might be quite small,
>so boot without MEMDISK might be interesting as well...
>
>>> Regarding the idea to have the kernel "natively boot from a
>>> RAMDISK in HIGH MEMORY which would NOT be A: or C: ... Well,
>>> on modern computers it should not be a problem to "hog" the
>>> drive letter of the A: floppy drive - you probably have at
>>> most ONE real floppy next to that ramdisk anyway and letter
>>> B: is still free :-) So in that sense, MEMDISK is ok for me.
>
>Exactly :-)
>
>> So this is a horribly stale discussion, but it seems that all that is
>> needed is the ability to hide somewhere a preferred drive letter for
>the
>> FreeDOS kernel to pick up and use.  It is trivial to add support for
>> passing such information along in MEMDISK.
>> 
>>  -hpa

Hi!

Memdisk already supports being a disk number other than 0x00 or 0x80, and the 
DL register will reflect that.  However, I was thinking of provided a more 
explicit hint, so that scripts can reply on the ramdisk being, say, R:
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

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

Re: [Freedos-kernel] EXT3 support

[H. Peter Anvin]

On 01/13/16 08:33, Eric Auer wrote:
> 
> Hi HPA and Joao,
> 
> support for EXT3 in the kernel would indeed be large/complex.
> 
> Only supporting EXT3 READS already would take circa 10 kB of
> code, taking the size of the EXT2/3/4 GRUB module as example.
> 
> I like MEMDISK bootable ramdisk style: MEMDISK can be booted
> by boot loaders which are able to boot Linux, and it can use
> any diskimage accessible by such boot loaders, including an
> image on EXT3 disks. Boot loaders either pre-compute a list
> of sectors to read files or load extra driver modules, which
> only have to support reading and which are not kept in RAM.
> 
> Regarding the idea to have the kernel "natively boot from a
> RAMDISK in HIGH MEMORY which would NOT be A: or C: ... Well,
> on modern computers it should not be a problem to "hog" the
> drive letter of the A: floppy drive - you probably have at
> most ONE real floppy next to that ramdisk anyway and letter
> B: is still free :-) So in that sense, MEMDISK is ok for me.
> 

So this is a horribly stale discussion, but it seems that all that is
needed is the ability to hide somewhere a preferred drive letter for the
FreeDOS kernel to pick up and use.  It is trivial to add support for
passing such information along in MEMDISK.

-hpa


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

Re: [Freedos-kernel] EXT3 support

[H. Peter Anvin]

On 08/14/15 15:00, Till wrote:
> 
> Quoting João Jerónimo :
> 
>> Wouldn't it be better to use a redirector? This can be done with a TSR.
>>
>> João Jerónimo
>>
> 
> 
> A TSR redirector would be great for assigning an EXT3 drive to a drive  
> letter for standard I/O operations.  However a kernel driver would  
> allow freeDOS to boot and run from an EXT3 journaling partition, I can  
> only imagine that the benefits from this would be huge.
> 

You can do this anyway by using an auxiliary bootloader, e.g. Syslinux
or Grub.  The idea is that you load the basic DOS into a ramdisk from
the bootloader (e.g. via memdisk) and then you can load your TSR.

What *might* be useful could be a way to have some way for the FreeDOS
kernel to natively boot from a ramdisk in high memory, or at least have
a way to not have the ramdisk become drive A or C.

-hpa



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

[Freedos-kernel] FreeDOS and redirectors

[H. Peter Anvin]

I wanted to ask: to what degree does FreeDOS implement the redirector
interface?  Are there any known incompatibilities?

The reason I am asking is that I started a project that I was never able
to find time finish (and don't expect to have any more for the
forseeable future) to write a 9pfs redirector for DOS, which would let
DOS access a filesystem (as opposed to a disk image) using Qemu.

If there is interest, the code so far is at:

http://git.zytor.com/dos/virtio9p.git/

It contains a lot of infrastructure work done (tested under MS-DOS 6.22)
but not much of the actual file operations.

This also requires that any protected mode memory manager (EMM386 etc)
implements the DOS VDS (Virtual DMA Service, INT 4Bh AH=81h) API.

-hpa

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