Re: [Freedos-kernel] ke2042: nasm fails to assemble files during build time
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
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
On 08/26/16 14:12, H. Peter Anvin wrote: > > 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: > So, in case there is any interest whatsoever: I would suggest returning the desired drive letter in register AL when INT 13h AH=08h is invoked with the MEMDISK extensions. I can verify that all versions of MEMDISK that have been created return zero in register AL, so there wouldn't be a backwards compatibility issue. -hpa -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] EXT3 support
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
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
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
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