Re: [Freedos-devel] segment override prefix for XLAT instruction
(I copied this mail to the pushbx blog in which the links can be written
as proper hyperlinks. You may want to read it there [0].)
On at 2024-06-30 23:04 +0200, Bernd Böckmann via Freedos-devel wrote:
Hello,
I have a question our assembly people: I stumbled upon an unusual instruction
in the EDR-DOS source [1]. In RASM86 this is expressed as
XLAT CS:AL
which gets encoded as 2E D7.
So this is a CS segment override prefix for an otherwise usual XLAT
instruction. I found no way to reproduce this instruction in JWasm other than
doing the following:
DB 2eh
XLAT
The Intel documentation for XLAT explains that the value to be added to AL is
fetched from DS:BX, so probably the DS gets replaced by the CS override. But is
the override prefix valid at this point, and does this work on all common CPUs?
Intel documentation is silent about this.
Thanks,
Bernd
[1]
https://github.com/SvarDOS/edrdos/blob/d579db43a97554dcac35becf510d7be8f5a85aae/drdos/header.a86#L1250
Hello Bernd,
A simple web search for "segment override xlatb" without the quote marks
[1] does find some relevant results, in particular this retrocomputing
stackexchange thread [2]. Quoting part of the question:
> XLAT with a segment override prefix: Manuals for 8086 and 80286 only
mention that it uses the DS register. It was first mentioned in the
80386 manual that it accepts segment prefixes.
One of the answers [3] has this to say:
> XLAT with segment override - works the same as 8088, segment override
for base address can be CS:[BX] or ES:[BX]. ... segment overrides for
XLAT on a V20 do seem to work consistent with the 808x.
I just fired up my HP 95LX which runs a NEC V20 as well. I can confirm
that cs xlatb, es xlatb, and ss xlatb all work as expected.
Another answer [4] claims that MAME does not support XLATB with a
segment override:
> MAME's 8086/88/186/188/286 emulator here [5], V20/V30/V33/V33A
emulator here [6], and V30MZ emulator here [7] all support 83/1, 83/4,
and 83/6, and they all don't support a segment override for XLAT (the
prefix is allowed but ignored). Search for 0x83 and 0xd7 to find the
implementations.
>
> The fact that they all agree doesn't necessarily mean they're
correct, since they all seem to have been forked from common code at
some point. But I suppose that whoever implemented 83/x with no
CPU-version test and put an explicit DS in the XLAT implementation
probably knew what they were doing.
Consequently, I added a remark on this to my NASM v2.05 based
instruction reference [8]:
> On 386 or higher level machines, the segment register used to load
from [BX+AL] or [EBX+AL] can be overridden by using a segment register
name as a prefix (for example, ES XLATB). It is reported that a segment
override may be ignored by CPUs of a lower level than a 386.
I added this remark on 2022-03-18 [9]. On 2021-06-06 I replaced a use of
cs xlatb in inicomp's lzd.asm [10], most directly by a sequence that
costs 3 bytes more than cs xlatb, like so:
push ds
push cs
pop ds
xlatb
pop ds
Later [11] I replaced the use of xlatb by code that branches to get the
next state number.
---
However, looking at the current source of MAME
(mame/src/devices/cpu/i86/i86.cpp [12] and .../cpu/nec/necinstr.hxx
[13]) it appears as if XLATB was changed to use a segment override
prefix since this answer [4] was written (2021-06-04).
i86.cpp has [12]:
case 0xd7: // i_trans
m_regs.b[AL] = GetMemB( DS, m_regs.w[BX] + m_regs.b[AL] );
CLK(XLAT);
break;
This calls GetMemB in i86inline.h [14]:
inline uint8_t i8086_common_cpu_device::GetMemB(int seg, uint16_t offset)
{
return read_byte(calc_addr(seg, offset, 1, I8086_READ));
}
This calls calc_addr [15]:
uint32_t i8086_common_cpu_device::calc_addr(int seg, uint16_t offset,
int size, int op, bool override)
{
if ( m_seg_prefix && (seg==DS || seg==SS) && override )
{
m_easeg = m_seg_prefix;
return (m_sregs[m_prefix_seg] << 4) + offset;
}
else
calc_addr with only 4 parameters [16] uses the default for the override
parameter, which is equal to true:
virtual uint32_t calc_addr(int seg, uint16_t offset, int size, int op,
bool override = true);
So the 8086 sources for current MAME actually do support segment
overrides for XLATB.
necinstr.hxx [13] uses this line to implement XLATB:
OP( 0xd7, i_trans ) { uint32_t dest = (Wreg(BW)+Breg(AL))&0x;
Breg(AL) = GetMemB(DS0, dest); CLKS(9,9,5); }
I'm unsure which GetMemB definition is used here, but it uses "DS0"
which looking at eg the A0h to A3h opcodes [17] is what is known as DS
on the 8086 and in a way that allows a segment override:
OP( 0xa0, i_mov_aldisp ) { uint32_t addr; addr = fetchword(); Breg(AL) =
GetMemB(DS0, addr); CLKS(10,10,5); }
OP( 0xa1, i_mov_axdisp ) { uint32_t addr; addr = fetchword(); Wreg(AW) =
GetMemW(DS0, addr); CLKW(14,14,7,14,10,5,addr); }
OP(
Re: [Freedos-devel] FreeDOS on Pocket386
On at 2024-06-02 13:31 +0200, Bernd Böckmann via Freedos-devel wrote: If the 10MB partition can be booted from, we have to take into account that this is a FAT16 partition, and accordingly the FAT12/16 volume boot code is installed. This supports both LBA and non-LBA access. Jim, can you upload the non-working image and the working 10MB test image, so I can have a look at the relevant data structures (MBR etc.)? https://nextcloud.iww.rwth-aachen.de/index.php/s/BRXqZDGasw74NN9 What BIOS is this machine using? As Jerome said, the FreeDOS installer will re-use an existing partition layout. So what you can try (not 100% sure you already did that): start with an empty 1.9G image and install FreeDOS onto it via QEMU. The installer will create and format a partition. Then, try to boot it with your 386. Thinking of this LBA, non-LBA thing we might investigate if it is possible to merge the LBA and non-LBA FAT32 VBR code into one. But that is for another topic. We also might replace the loaders with some other one. If I remember correctly ECMs lDOS loaders have the capability... As we say, speak the devil's name and here she is! I prepared an overview of the lDOS FAT32 + FSIBOOT4 loaders on my blog: https://pushbx.org/ecm/dokuwiki/blog/pushbx/2024/0602_barely_any_work_in_the_may_june_week#ldos_fat32_boot_sector_loader_for_freedos Comments and additional questions are welcome both in this thread or in the comment thread of the blog. Not listed in the article is the lDOS boot.asm (FAT12/FAT16) loader. This one also supports the _COMPAT_FREEDOS set but it requires disabling some of the loader's features to make the relocation code fit in the allowed space. That is why I mention in the article that none of the loader's features need to be disabled to use _COMPAT_FREEDOS for my boot32.asm as a consequence of the two-stage approach. As usual, my code is FLOSS and in the case of lDOS boot + instsect + lmacros it builds with only NASM (a recent-ish version of the assembler may be required). Regards, ecm ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS on Pocket386
On at 2024-06-02 18:19 +0200, Bernd Böckmann via Freedos-devel wrote: 5. SYS C: /FORCE:CHS And that boots without problem on the Pocket386! Also: you asked about FDISK /XO output. It reports "W95B INT LBA FAT32" in the upper left corner. This is running FDISK 1.3.15. To Jim: Are you sure you ran FDISK /XO on the Pocket386 system? If FDISK says it detects LBA there but the LBA loader from FreeDOS doesn't work that'd be quite the bug. Well, this is good on the one hand, but bad on the other. It means that the system (supposedly) supports LBA access, but the FAT32 LBA loader for a reason yet unknown to me fails to boot the thing. LBA in general seems to be working. Otherwise FDISK would also fail in one way or another. Have to think about what might be the cause. Looking at the source of FAT32 LBA loader, it passes the disk access packet to the BIOS by pushing it onto the stack and setting SI=SP, instead of reserving some space for it in its data area. Not exactly sure that this is a good idea, as it makes this susceptible to stack corruption, depending on how the BIOS mishandles the packet. The packet on the stack trick is used by some lDOS MBR/boot loaders as well, and it generally works. https://github.com/FDOS/kernel/blob/c0127001908405d30d90f1755ad10c1b59ea8c90/boot/boot32lb.asm#L384 The BIOS may also trash some registers... Anyone a suggestion? If it really turns out that FDISK /XO detected LBA support *on the Pocket386* but the LBA loader fails, I could cough up some debugging hints as to how to install bootable lDebug on the system then debug the failing loader. For instance: 1. Rename kernel.sys to fdkernel.sys (exact name doesn't matter) 2. Copy ldebug.com to working drive (using CHS loader) as kernel.sys 3. Boot lDebug 4. Boot FreeDOS using "BOOT PROTOCOL FREEDOS fdkernel.sys" then "Q" 5. Write loader to file: "SYS C: /BOOTONLY /FORCE:LBA BOOTSECT.DOS" 6. Reboot into lDebug 7. Try "BOOT PROTOCOL CHAIN" and then trace the loader You could install the FAT32+FSIBOOT loader for lDebug as well but when you already have a working boot loader then this would just be the possible cause of more headaches. Not impossible, but not worth it probably. As I have oft repeated lDebug can be loaded as a number of kernel formats, most recently including the FreeDOS and the original Enhanced DR-DOS (v7.01.07) kernel load formats. I will advertise the lDOS FAT32 loader more in another subsequent email. Regards, ecm ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS on Pocket386
On at 2024-06-02 19:16 +0200, Eric Auer via Freedos-devel wrote: Hi! It would be possible to add an additional screen to the installer (probably only advanced mode) to use the /FORCE:CHS option. That would be a good option to have, but I'd like to fix sys bootcode so lba code works and maybe make a multi sector fat32 version that supports both chs & lba... If you SYS on the same system where you work later, SYS will detect whether or not there is FAT32 support. I think you meant "LBA support" in this line. And indeed it does, but this doesn't work as intended if the target system doesn't support LBA but the installer system does. I think it would be overkill to have a multi-sector boot loader which supports all options on FAT32. Today, LBA support is widespread enough and our FAT12 / FAT16 boot sector already supports CHS and LBA in one combined (also somewhat over-engineered) boot sector :-) I will write more on this in a subsequent mail. Regards, ecm ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] zoo
On at 2024-05-23 11:42 +0100, Liam Proven via Freedos-devel wrote: On Tue, 21 May 2024 at 19:22, E. C. Masloch via Freedos-devel wrote: 64 Ki * 16 KiB = 1024 MiB. (The actual maximum amount of clusters is of course slightly less than 64 Ki, to be exacting.) So you're off-by-one, a "2 GB" file system cannot possibly be fully utilised with FAT16 at a 16 KiB per cluster size. Ah, OK. My apologies. Off-by-one errors are of course one of the two hardest problems in computer science, along with cache invalidation and naming things. Ha! Hence tom's suggestion of FAT17. Clearly there's a joke here but I don't see it or get it. Ah well. Perhaps mine above will meet a similar reception. It's simple. FAT16 has 16 (significant) bits per FAT entry, so it can address a FAT of nearly 64 Ki entries. If there was a FAT variant with 17 (significant) bits per FAT entry, the available space for FAT entries would double to nearly 128 Ki, so your initial numbers (2 GiB FS at 16 KiB / cluster) would be correct. (Because FAT32 actually has only 28 significant bits in its FAT entries some have called it "FAT28".) So, 1GB-2GB FAT16 partitions used 32kB clusters, and it was the orginally-NT-only 64kB clusters that were for 2-4GB drives. Precisely. (Except for how you're using SI base 1000 prefixes in the JEDEC base 1024 meaning. I think that "KB" should be all-caps in the JEDEC use.) Regards, ecm ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] zoo
On at 2024-05-19 00:37 +0100, Liam Proven via Freedos-devel wrote: On Fri, 17 May 2024 at 17:14, tom ehlert via Freedos-devel wrote: Below 1GB FAT16 uses 8kB clusters. From 1GB-2GB it uses 16kB ones. (Below ½GB it uses 4kB.) That would require FAT17. (?) Not at all. 64 Ki * 16 KiB = 1024 MiB. (The actual maximum amount of clusters is of course slightly less than 64 Ki, to be exacting.) So you're off-by-one, a "2 GB" file system cannot possibly be fully utilised with FAT16 at a 16 KiB per cluster size. Hence tom's suggestion of FAT17. Here is the full list: FAT12 Drive size Secs/cluster Cluster size < 16 MB 8 4 KiB FAT16 Drive size Secs/cluster Cluster size < 128 MB 4 2 KiB < 256 MB 8 4 KiB < 512 MB 16 8 KiB < 1 GB 3216 KiB < 2 GB 6432 KiB This supports what tom and I wrote: up to (nearly) "2 GB" you need 32 KiB per cluster. < 4 GB 12864 KiB (Windows NT only) I agree with this. Enhanced DR-DOS, FreeDOS, and my MS-DOS v4 fork also support 64 KiB per cluster now. < 8 GB 256 128 KiB (Windows NT 4.0 only) < 16 GB 512 256 KiB (Windows NT 4.0 only) EDR-DOS, FreeDOS, and lMS-DOS also support 128 KiB clusters, using 256 Sectors per Cluster. For further comment see below. FAT32 Drive size Secs/cluster Cluster size < 260 MB 1 512 bytes < 8 GB 8 4 KiB < 16 GB 16 8 KiB < 32 GB 3216 KiB < 2 TB 6432 KiB It seems that a 2 TiB file system could actually use 8 KiB per cluster if you were willing to tolerate a FAT size of 1 GiB each. (1 GiB is the maximum size of a FAT's usable data in FAT32.) 2 * 1024 * 1024 * 1024 * 1024 / (2 ** 28) = 8192. Not claiming any formatting tool does this, but the numbers check out. (If anyone is confused about 2 to the power 28, this is because FAT32 actually reserves the top 4 bits of every 32-bit FAT entry. They're masked off by drivers and never set by anyone AFAIK. So the usable amount of entries is 2 ** 28, not 2 ** 32.) Source: https://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html Confirmation: https://www.researchgate.net/figure/Default-cluster-size-for-FAT-compatible-OS_tbl1_261851917 To get to the "Windows NT 4.0 only" entries: I'd never heard of any MSW supporting 256 Sectors per Cluster. Let alone 512. I didn't find any other source that confirms this or even explains how such large SpC values are to be encoded in the file system in order for a driver to use them. I was also under the impression that EDR-DOS was the first implementation of FAT FS with 256 SpC. The only other source I found that supports the possibility of 256 KiB clusters is in the English Wikipedia page for FAT, in the FAT16B info box: > Max volume size > >2 GB (with 32 KB clusters) >4 GB (with 64 KB clusters) (NT 4, PTS-DOS, EDR-DOS) >8 GB (with 128 KB clusters and 1 or 2 KB sectors) (NT 4 and EDR-DOS only) >8 GB (with 128 KB clusters and 512 byte sectors) (EDR-DOS only) >16 GB (with 256 KB clusters and 2 or 4 KB sectors) (NT 4 only) https://en.wikipedia.org/wiki/File_Allocation_Table#Final_FAT16 You will note that the "8 GB" limits listed use 512 BpS only for the EDR-DOS 256 SpC extension, only. The other "8 GB" and the "16 GB" specify larger sector sizes. That would explain how to get to a 256 KiB cluster, without even the 256 SpC extension. Regards, ecm ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01
On at 2024-05-03 23:54 -0400, Steve Nickolas via Freedos-devel wrote: So I've had some thoughts regarding the MS-DOS 4 source drop, regarding things I'd like to do with the code. I'm not really that good of a coder and probably would only be able to do some of them myself. (I'd kill for a 3.3 drop - would obviate a lot of these things! And 5 and 6.2 even more.) First big issue, and one I can only partially resolve. I'm taking a strict approach to the contents of the TOOLS folder - want to get rid of it and replace it with open-source equivalents. That means, most practically, OpenWatcom 1.9 (there's prolly other options but the more like MSC it is the less torturous porting is going to be). And the code's going to need to be dinked as far as possible to roll in Watcom instead of MSC - that's going to be a major pain in the neck. As mentioned before, JWasm is probably going to be useful to replace the MASM v5.10 for this. Me, I'm working with the original toolchain for now even though it is (free but) closed source. Some of the code's pretty braindead, too. Especially what looks to have come from IBM. I mean...house styles vary, but Algolization is still just hideous-looking. But it goes beyond that - think some of the utilities are going to need major rewrites. I'm thinking of writing a new front-end around the FDISK code, but I haven't really been able to take the code and sort through everything to figure out what parts I'll need in order for FDISK to...fdisk (and don't know enough about int13, MBR or FAT to do it my damnself). I was looking into D-Flat, but my brain melted - might have to write bespoke UI code. Additionally, the whole "Message Server" thing. (I think the broken TYPE command when COMMAND.COM is run under FreeDOS is related to this.) I'd like to have the feature reduced to compatibility only and use good old-fashioned AH=9 like older DOS versions. It'll probably also iron out some of the compile issues I've had trying to port the C stuff to Watcom! The broken TYPE (and COPY) command in the shell is actually due to the Extended Attributes functions that the MS-DOS v4.01 kernel "supports". In fact, these functions are just placeholders that return an empty list and ignore all writes. I wrote about this to dosemu2 [1], as the TYPE and COPY commands were broken on dosemu2 redirector drives (even when running both command.com and the kernel from the MS-DOS release). The error is the command will (on FreeDOS) display "Extended Error 1" when trying to display a file using TYPE, or (on MS-DOS on a redirector drive) "Invalid function - ". I patched command.com in my fork to not require these functions [2]. Writing of which, I also identicalised the binaries to both MS-DOS v4.00 (matching the original release minus build fixes and encoding problems) [3] as well as the MS-DOS v4.01 release [4]. I compared the files to the content of disks found at the Internet Archive [5]. The v4.01 patch comes from hharte's fork on github [6], but I verified that it matches the v4.01 release. I also wrote about the process (regarding the v4.00 work) on our forum [7]. The most difficult part involved creating a small unpacker utility for the select.dat files [8], to allow comparing the binary differences in the uncompressed data rather than being stuck with the compressed files. An error that remains is that on the FreeDOS kernel, commands like "ver /r" and "mem /p" (using unsupported switches) will not display "Invalid switch" or "Invalid switch - /p" but rather "Parse Error 3". After these things are ironed out, I guess the next phase would be, unless another code drop obviates the effort, to recreate features of later versions. I've actually done this with some apps. (The obvious question: Why not use what FreeDOS already has? A: Because I'd like to have the entirety of the project under a single license - that being the X license Microsoft and IBM are already using.) High memory support - big feature of 5.0 - that's a big part of why 5 was considered a _good_ version of DOS and 4 wasn't. I already added one MS-DOS v5 feature: Device drivers are passed the maximum valid address that they may allocate [9]. This allows loading lDebug as a device driver, albeit an lDebug bugfix is also needed [10]. Regards, ecm [1]: https://github.com/dosemu2/dosemu2/issues/2206 [2]: https://hg.pushbx.org/ecm/msdos4/rev/cf97c97c1d9b [3]: https://hg.pushbx.org/ecm/msdos4/shortlog/63a05668c5f3 [4]: https://hg.pushbx.org/ecm/msdos4/rev/51ad27d225a8 [5]: https://archive.org/details/ms-dos-4.00-and-4.01 [6]: https://github.com/hharte/MS-DOS/commit/7e51e4249ee0e6185b4e3eed9902c5cf786f052a#comments [7]: https://www.bttr-software.de/forum/forum_entry.php?id=21755 [8]: https://hg.pushbx.org/ecm/msdos4/rev/9a0f75e8c341 [9]: https://hg.pushbx.org/ecm/msdos4/rev/814a8eb71ce4 [10]: https://hg.pushbx.org/ecm/ldebug/rev/6c4bbd544091
Re: [Freedos-devel] MS-DOS 4.0 source released as open source under MIT license
On at 2024-04-26 14:28 -0500, Jim Hall via Freedos-devel wrote: On Fri, 26 Apr 2024, Bernd Böckmann via Freedos-devel wrote: Microsoft and IBM released the source code of MS-DOS 4.0 under MIT license [1]. To me, it looks fairly complete. On Fri, Apr 26, 2024 at 2:25 AM Steve Nickolas via Freedos-devel wrote: Everything but himem, dosshell, gwbasic, and parts of xmaem/xma2ems, apparently. I got most of it compiled using the tools in the archive. How did you compile it? I'm having trouble getting the compile to work. Here's what I'm doing: I've booted my system using FreeDOS but using their tools. My C: drive is FreeDOS, and my D: drive is empty except for the SRC directory from the MS-DOS 4.0 release on GitHub. I set up my environment by editing the SETENV.BAT and running it: @echo off echo setting up system to build the MS-DOS 4.01 SOURCE BAK... set COUNTRY=usa-ms set BAKROOT=D: rem BAKROOT points to the home drive/directory of the sources. set LIB=%BAKROOT%\src\lib set INIT=%BAKROOT%\src\tools set INCLUDE=%BAKROOT%\src\inc set PATH=%BAKROOT%\src\tools;C:\freedos\bin set CL=%INIT%\CL.EXE set LINK=%INIT%\LINK.EXE set MASM=%INIT%\MASM.EXE This is my PATH: D:\>path PATH=D:\src\tools;C:\freedos\bin Yes, I'm really running the Microsoft NMAKE from their tree: D:\>nmake Microsoft (R) Program Maintenance Utility Version 1.00.05 Copyright (c) Microsoft Corp 1987, 1988. All rights reserved. NMAKE : fatal error U1051: usage : 'NMAKE' [-bcdeinpqrst -f makefile -x stderrfi le] [macrodefs] [targets] Stop. But when I try to build it, it fails in the MAPPER directory with "line too long": D:\>cd src D:\SRC>nmake I had similar errors, in mapper/getmsg.asm, select/select2.asm, and select/usa.inf For me these turned out to be errors involving a single-byte character being expanded to a three-byte UTF-8 encoded value. When nearly a whole line (of 80 columns) is filled with these EF BF BD strings then MASM (the version shipped with the repo) doesn't like the total line length in bytes. I eventually fixed this by running: (After manually deleting a few lines to work around the problem.) > sed -i -re 's/\xEF\xBF\xBD|\xC4\xBF|\xC4\xB4/#/g' FILENAMES... I had many more errors, starting with nosrvbld.exe running on eg boot/boot.skl complaining it couldn't find something. The something was named as a bunch of gibberish text however. This, and some other problems, turned out to be because git and/or Microsoft spat out text files with LF line endings whereas many of the DOS tools expect CR LF line endings. The following command worked for me: > find -iname '*.bat' -o -iname '*.asm' -o -iname '*.skl' -o -iname 'zero.dat' -o -iname 'locscr' | xargs unix2dos -f (The zero.dat and locscr files are used to redirect numbers into exe2bin's relocation number prompt. Failure to unix2dos those ended up hanging dosemu2 and/or ConnectBot, and spamming notifications to ConnectBot. Likely related to the old problem of int 21h service 0Ah not properly detecting and handling an EOF.) To successfully compile the C program parts, I had to fix the setenv.bat script (apart from using another drive) to point to the headers and libraries that actually ship with the repo: $ cat src/e.bat @echo off echo setting up system to build the MS-DOS 4.01 SOURCE BAK... set CL= set LINK= set MASM= set COUNTRY=usa-ms set BAKROOT=e: rem BAKROOT points to the home drive/directory of the sources. set LIB=%BAKROOT%\src\tools\bld\lib set INIT=%BAKROOT%\src\tools set INCLUDE=%BAKROOT%\src\tools\bld\inc set PATH=%BAKROOT%\src\tools;%PATH% To boot the kernel, I used lDebug's command BOOT PROTOCOL MSDOS6 hda1/ to boot off a file system that I created using my bootimg.asm script. I had to set -D_OEM_NAME="'IBM 3.1'" to make the kernel accept my file system; with my default it calculated a wrong (at least) Sectors per Cluster value of 4 and failed to load the DOS module. This is my command line to create the image: > nasm -I ../../lmacros/ -I ../../bootimg/ ../../bootimg/bootimg.asm -D_PAYLOADFILE="io.sys,msdos.sys,mem.exe,sys.com,../../ldebug/bin/callver.com,::rename,../../../.dosemu/drive_c/command.com,freecom.exe,command.com" -o disk.img -D_MEDIAID=0F8h -D_BPE=16 -D_ERROR_SMALL32=0 -D_SPF=256 -D_SPI=128000 -D_SPC=2 -D_MBR -D_MBR_PART_TYPE=fat16_chs -D_CHS_HEADS=128 -D_CHS_SECTORS=32 -D_OEM_NAME="'IBM 3.1'" Regards, ecm ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
