DOS ain't dead

Hello everyone, I assembled a single board computer based on i80188 CPU.

https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:sbc-188:start

This SBC has no VGA, but serial VT100 terminal provided by BIOS, MS-DOS 6.22 works fine, instead with freedos I'm having problems...


All official versions of the freedos floppy when they start crash like this:



Then I found the image of this floppy at this url:
https://github.com/alblue/8086tiny/blob/master/fd.img

This freedos starts and seems to work even though it dates back to 2012 ...



the only thing I notice different is that the official versions of freedos start by writing dots on the video during loading, while the version that works starts by writing FreeDOS immediately ... is the bootloader different? can anyone explain to me how I can get an updated freedos working on my SBC188?

be sure to select a bootable image that has an 8086 kernel. Other kernels may include instructions that your 186 cpu does not understand.

> be sure to select a bootable image that has an 8086 kernel. Other kernels
> may include instructions that your 186 cpu does not understand.

I think the default kernel uses 386 instructions, IIRC.

This distro would be better, more complete.


http://svarog86.sourceforge.net/

> > be sure to select a bootable image that has an 8086 kernel. Other
> kernels
> > may include instructions that your 186 cpu does not understand.
>
> I think the default kernel uses 386 instructions, IIRC.
>
> This distro would be better, more complete.
>
>
> http://svarog86.sourceforge.net/


I've already tried this, it doesn't work at all ... Same mistake as the official fdboot.img

> > be sure to select a bootable image that has an 8086 kernel. Other
> kernels
> > may include instructions that your 186 cpu does not understand.
>
> I think the default kernel uses 386 instructions, IIRC.
>
> This distro would be better, more complete.
>
>
> http://svarog86.sourceforge.net/


I tried them all:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/

the only one I found by chance and that works seems to have a different boot loader. Do i have to recompile freedos for 186?

> I tried them all:
>
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/

What about MetaDOS? I rebuilt the kernel (2041, slightly patched) atop itself (OpenWatcom, NASM, UPX), and it should be 8086-friendly (even if many other tools aren't).

> the only one I found by chance and that works seems to have a different
> boot loader. Do i have to recompile freedos for 186?

SYS.COM is what installs your boot sector. Maybe try the latest one (from 2042 kernel)? Or try 2041? There shouldn't be any problems.

Also, my old BARE_DOS from 2008 was (mostly) 8086-friendly and works under 8086tiny.

Joris (for his Retro emulator) also had some 8086 floppy images. Similarly, Balder was meant to be an unofficial replacement to ODIN (one-disk installer).

> > I tried them all:
> >
> > http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/
>
> What about
> MetaDOS?
> I rebuilt the kernel (2041, slightly patched) atop itself (OpenWatcom,
> NASM, UPX), and it should be 8086-friendly (even if many other tools
> aren't).
>
> > the only one I found by chance and that works seems to have a different
> > boot loader. Do i have to recompile freedos for 186?
>
> SYS.COM is what installs your boot sector. Maybe try the latest one (from
> 2042 kernel)? Or try 2041? There shouldn't be any problems.
>
> Also, my old
> BARE_DOS
> from 2008 was (mostly) 8086-friendly and works under 8086tiny.
>
> Joris (for his Retro emulator) also had some
> 8086 floppy images. Similarly,
> Balder was meant to be an
> unofficial replacement to
> ODIN
> (one-disk installer).


I tried now metados 0.7 but it always crashes the same way, the boot loader makes the dots and does not start immediately with the word freedos ...

> > I tried them all:
> >
> > http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/
>
> What about
> MetaDOS?
> I rebuilt the kernel (2041, slightly patched) atop itself (OpenWatcom,
> NASM, UPX), and it should be 8086-friendly (even if many other tools
> aren't).
>
> > the only one I found by chance and that works seems to have a different
> > boot loader. Do i have to recompile freedos for 186?
>
> SYS.COM is what installs your boot sector. Maybe try the latest one (from
> 2042 kernel)? Or try 2041? There shouldn't be any problems.
>
> Also, my old
> BARE_DOS
> from 2008 was (mostly) 8086-friendly and works under 8086tiny.
>
> Joris (for his Retro emulator) also had some
> 8086 floppy images. Similarly,
> Balder was meant to be an
> unofficial replacement to
> ODIN
> (one-disk installer).

baredos boot ok
freedos1_20061018.img boot ok


both when they start they show the word FreeDOS, instead odin doesn't work, when it starts it shows the dots ... what's the difference from startup with "freedos" to startup with dots?

I partitioned and formatted a 1Gb compact flash with baredos and I did sys C: it told me "system transferred" but when I reset SBC188 it tells me: "Master boot loader not found"

Interesting results. What is the cost to buy the BOM?

writing of the master boot record seems to be a bug of the sbc188 bios with 1Gb compact flash. I managed to get freedos 1.2 to work ... I first installed bare_dos, then I booted from compactflash ... then I inserted floppy of freedos 1.2 and did sys c: from there ... the problem is bootstrap from the floppies that load the kernel writing dots, it is confirmed. While the floppies I boot write "FreeDOS Kernel -" They always work. So can anyone explain the difference between the 2 different bootloaders to me?

> Interesting results. What is the cost to buy the BOM?

do you want to build a sbc188?

> the problem is
> bootstrap from the floppies that load the kernel writing dots, it is
> confirmed. While the floppies I boot write "FreeDOS Kernel -" They always
> work. So can anyone explain the difference between the 2 different
> bootloaders to me?

Here is the old svn history of the FAT12/FAT16 boot sector loader. Revision 481 appears to be the last that displays "FreeDOS Kernel". (ETA: This should also display " FAT" and " GO!" though. So it is unclear whether this is actually what displays "FreeDOS Kernel" for you.) Revision 751 is the last one that displays "FreeDOS" (but without " Kernel"). Revision 1482 and newer display the dots whenever reading a sector (directory, FAT, kernel file data).

I have not yet examined the differences in detail. With a recent kernel's SYS you can try sys /FORCE:CHS and /FORCEDRV (with /B 00 or /B 80) to see whether any of these make a difference though.

---
l

> then I inserted
> floppy of freedos 1.2 and did sys c: from there ... the problem is
> bootstrap from the floppies that load the kernel writing dots, it is
> confirmed. While the floppies I boot write "FreeDOS Kernel -" They always
> work. So can anyone explain the difference between the 2 different
> bootloaders to me?

I packed up several files to test in https://ulukai.org/ecm/test/2020-09-12--fd12test.zip. Each of the .com files in this zip's root directory has a different boot sector loader for a FAT12 (diskette) file system. You can use xxx.com A: to write the corresponding loader with automatic unit usage, or xxx.com A: /U 00 to write that loader but forcing to 00h the ROM-BIOS unit to boot.

You can also use ifd12org.com A: /BO /B=boot.bin to dump the current boot sector to disk (the /B= option takes any valid DOS pathname). If you dump the boot sector that originally worked for you and one that doesn't, then upload them for us to inspect, we can be certain which loader you're actually using. (Per my other reply it isn't entirely clear.)

---
l

Correction: The loaders with U as the second letter (NUC, QUC, NUL) should not differ from those with N when booting off a diskette. You may try them anyway if you have the time but the difference is unlikely to matter.

---
l

This is all assuming it actually was the boot sector loader that causes the difference. Perhaps the difference is in the kernel but the older boot sector (that doesn't display dots) just happened to be used by the images of kernel files that worked. Did you already try copying a KERNEL.SYS off an image that works to overwrite the file on one of the dot-displaying images? Perhaps that way you could have an image that displays dots and works.

---
l

> > then I inserted
> > floppy of freedos 1.2 and did sys c: from there ... the problem is
> > bootstrap from the floppies that load the kernel writing dots, it is
> > confirmed. While the floppies I boot write "FreeDOS Kernel -" They
> always
> > work. So can anyone explain the difference between the 2 different
> > bootloaders to me?
>
> I packed up several files to test in
> https://ulukai.org/ecm/test/2020-09-12--fd12test.zip. Each of
> the .com files in this zip's root directory has a different boot sector
> loader for a FAT12 (diskette) file system. You can use xxx.com
> A: to write the corresponding loader with automatic unit usage, or
> xxx.com A: /U 00 to write that loader but forcing to 00h the
> ROM-BIOS unit to boot.
>
> You can also use ifd12org.com A: /BO /B=boot.bin to dump the
> current boot sector to disk (the /B= option takes any valid
> DOS pathname). If you dump the boot sector that originally worked for you
> and one that doesn't, then upload them for us to inspect, we can be certain
> which loader you're actually using. (Per my other reply it isn't entirely
> clear.)


I did the tests like this:

1) I formatted floppy

2) I copied kernel.sys and command.com into the floppy

3) I applied the various bootloaders you gave me with these results:

ifd12nnc boot OK !
ifd12nnl print "R" and freeze
ifd12nuc boot ok !
ifd12nul print "R" and freeze
ifd12qnc boot ok !
ifd12quc boot ok !
ifd12org whrite dot and crash.


what other tests should i do?

I made it work fine :) I created a boot and installation floppy dedicated to the SBC188, are you interested in having the image?

> I made it work fine :) I created a boot and installation floppy dedicated
> to the SBC188, are you interested in having the image?

I'm interested in how you built it and which files you used! Like what KERNEL.SYS file, what SYS or boot sector loader, etc.

(Working on a longer answer to your other post right now.)

---
l

> > I made it work fine :) I created a boot and installation floppy
> dedicated
> > to the SBC188, are you interested in having the image?
>
> I'm interested in how you built it and which files you used! Like what
> KERNEL.SYS file, what SYS or boot sector loader, etc.
>
> (Working on a longer answer to your other post right now.)


I used the files extracted from the floppy and the official freedos 1.2 ISO to build my system


I used the files extracted from the floppy and the official freedos 1.2 ISO to build my system and ifd12quc.com renamed as SYSA.COM, to make the floppy bootable, the normal SYS.COM seems to work for harddisk booting, only on floppy fails.

I haven't found the "setver" utility to run programs that require a specific version of msdos.

> I did the tests like this:
>
> 1) I formatted floppy
>
> 2) I copied kernel.sys and command.com into the floppy
>
> 3) I applied the various bootloaders you gave me with these results:
>
> ifd12nnc boot OK !
> ifd12nnl print "R" and freeze
> ifd12nuc boot ok !
> ifd12nul print "R" and freeze
> ifd12qnc boot ok !
> ifd12quc boot ok !
> ifd12org whrite dot and crash.
>
> what other tests should i do?

I uploaded a new archive to https://ulukai.org/ecm/test/2020-09-13--fd12test.zip with some additional files.

1. You can try ifd12NNA.com from this (it is likely to work).

2. You can also try to boot the test payload. To do this, copy testpl.com from the archive to a diskette then run "ifd12QUC.com A: /F1=TESTPL.COM" then try to boot that. It should work. Upon success, pressing any key after its register and status dump will reboot the machine.

(By the way, the "R" displaying results with NNL and NUL loaders also are not supposed to freeze; pressing a key like Enter should restart the boot process.)

3. You can try booting the test payload using "ifd12org.com A: /F1=TESTPL.COM" to make certain it is the boot sector loader that is at fault. If so, it should act the same way as trying to boot KERNEL.SYS using this loader.

4. If you want, I can give you further instructions on how to debug the failing loader. The files i12debug.com (run with "A:") and ldebug.com (copy to the diskette) in this archive can be used to set up my bootable debugger. Then "ifd12org.com A: /F1=TESTPL.COM /B=A:\b12test.bin" can be used to generate a chainloadable boot sector dump with the failing loader. Next, boot the debugger, and try running the BOOT command "boot protocol chain b12test.bin" then "q". If this displays the test payload status dump something strange is going on. If it hangs the same way as that loader otherwise does, we can actually debug it. (If you want to do this, tell me and I'll get around to it within the week.)

---
l

> 4. If you want, I can give you further instructions on how to debug the
> failing loader. The files i12debug.com (run with "A:") and ldebug.com (copy
> to the diskette) in this archive can be used to set up my bootable
> debugger. Then "ifd12org.com A: /F1=TESTPL.COM
> /B=A:\b12test.bin" can be used to generate a chainloadable boot
> sector dump with the failing loader. Next, boot the debugger, and try
> running the BOOT
> command "boot protocol chain b12test.bin" then
> "q". If this displays the test payload status dump something
> strange is going on. If it hangs the same way as that loader otherwise
> does, we can actually debug it. (If you want to do this, tell me and I'll
> get around to it within the week.)

I got around to a very simple test right away. Here's what I did (using dosemu2):

$ dd if=/dev/zero of=../diskette.img bs=1 count=$((1440 * 1024))
$ touch autoexec.bat
$ dosemu -dumb -quiet -K "$PWD" -I "floppy { threeinch device ../diskette.img }" -E "format A:"; dosemu -dumb -quiet -K "$PWD" -I "floppy { threeinch device ../diskette.img }" -E "ifd12quc.com A: /F1=TESTPL.COM"; dosemu -dumb -quiet -K "$PWD" -I "floppy { threeinch device ../diskette.img }" -E "copy testpl.com A:"; dosemu -dumb -quiet -K "$PWD" -I "floppy { threeinch device ../diskette.img }" -E "copy C:kernel.sys A:"; dosemu -dumb -quiet -K "$PWD" -I "floppy { threeinch device ../diskette.img }" -E "copy D:\\dosemu\\exitemu.com A:"; dosemu -dumb -quiet -K "$PWD" -I "floppy { threeinch device ../diskette.img }" -E "copy C:command.com A:"; dosemu -dumb -quiet -K "$PWD" -I "floppy { threeinch device ../diskette.img }" -E "copy autoexec.bat A:"

{press Enter each time for the format application's prompts}

$ dosemu -dumb -quiet -K "$PWD" -I "floppy { threeinch device ../diskette.img }" -E "ifd12org.com A: /F1=TESTPL.COM /B=A:\b12test.bin"; dosemu -dumb -quiet -K "$PWD" -I "floppy { threeinch device ../diskette.img }" -E "i12debug.com A:"; dosemu -dumb -quiet -K "$PWD" -I "floppy { threeinch device ../diskette.img }" -E "copy ldebug.com A:"; dosemu -dumb -K "$PWD" -I "floppy { threeinch device ../diskette.img }" -A

How to set up the diskette:

1. Format it, leave the volume label empty.

2. Copy testpl.com to the file system. Important: This should be the very first file to copy onto it. (Not needed to boot it generally, but important to make the cluster numbers the same as those I got.)

3. Copy other files, such as the debugger, the FreeDOS kernel, FreeCOM (FreeDOS command.com), etc.

4. Create empty autoexec.bat for FreeCOM. (Otherwise it will prompt for date and time during startup.)

5. ifd12org.com A: /F1=TESTPL.COM /B=A:\b12test.bin

6. i12debug.com A:

7. Boot it.

Next, to debug the loader in a very basic way, we can tell the debugger to step through it until execution leaves the boot loader. I uploaded a recording of the debugger I/O for this in https://ulukai.org/ecm/test/20200913.txt

First you need to enter boot protocol chain b12test.bin and then the following: tp fffff while !( cs != 7C0 && cs != 0 && cs != 1FE0 || ip < 7C00 || ip > 7C00+#512 ) silent

This may not be sufficient to debug the loader but it will probably tell us something about how it fails.

---
l

By the way, how much memory is installed on this system and available to DOS?

---
l

> By the way, how much memory is installed on this system and available to
> DOS?

1Mb

> > 4. If you want, I can give you further instructions on how to debug the
> > failing loader. The files i12debug.com (run with "A:") and ldebug.com
> (copy
> > to the diskette) in this archive can be used to set up my bootable
> > debugger. Then "ifd12org.com A: /F1=TESTPL.COM
> > /B=A:\b12test.bin" can be used to generate a chainloadable boot
> > sector dump with the failing loader. Next, boot the debugger, and try
> > running the BOOT
> > command "boot protocol chain b12test.bin" then
> > "q". If this displays the test payload status dump
> something
> > strange is going on. If it hangs the same way as that loader otherwise
> > does, we can actually debug it. (If you want to do this, tell me and
> I'll
> > get around to it within the week.)
>
> I got around to a very simple test right away. Here's what I did (using
> dosemu2):
>
> $ dd if=/dev/zero of=../diskette.img bs=1 count=$((1440 * 1024))
> $ touch autoexec.bat
> $ dosemu -dumb -quiet -K "$PWD" -I "floppy { threeinch device
> ../diskette.img }" -E "format A:"; dosemu -dumb -quiet -K "$PWD" -I "floppy
> { threeinch device ../diskette.img }" -E "ifd12quc.com A: /F1=TESTPL.COM";
> dosemu -dumb -quiet -K "$PWD" -I "floppy { threeinch device ../diskette.img
> }" -E "copy testpl.com A:"; dosemu -dumb -quiet -K "$PWD" -I "floppy {
> threeinch device ../diskette.img }" -E "copy C:kernel.sys A:"; dosemu -dumb
> -quiet -K "$PWD" -I "floppy { threeinch device ../diskette.img }" -E "copy
> D:\\dosemu\\exitemu.com A:"; dosemu -dumb -quiet -K "$PWD" -I "floppy {
> threeinch device ../diskette.img }" -E "copy C:command.com A:"; dosemu
> -dumb -quiet -K "$PWD" -I "floppy { threeinch device ../diskette.img }" -E
> "copy autoexec.bat A:"
>
> {press Enter each time for the format application's prompts}
>
> $ dosemu -dumb -quiet -K "$PWD" -I "floppy { threeinch device
> ../diskette.img }" -E "ifd12org.com A: /F1=TESTPL.COM /B=A:\b12test.bin";
> dosemu -dumb -quiet -K "$PWD" -I "floppy { threeinch device ../diskette.img
> }" -E "i12debug.com A:"; dosemu -dumb -quiet -K "$PWD" -I "floppy {
> threeinch device ../diskette.img }" -E "copy ldebug.com A:"; dosemu -dumb
> -K "$PWD" -I "floppy { threeinch device ../diskette.img }" -A
>
> How to set up the diskette:
>
> 1. Format it, leave the volume label empty.
>
> 2. Copy testpl.com to the file system. Important: This should be the very
> first file to copy onto it. (Not needed to boot it generally, but important
> to make the cluster numbers the same as those I got.)
>
> 3. Copy other files, such as the debugger, the FreeDOS kernel, FreeCOM
> (FreeDOS command.com), etc.
>
> 4. Create empty autoexec.bat for FreeCOM. (Otherwise it will prompt for
> date and time during startup.)
>
> 5. ifd12org.com A: /F1=TESTPL.COM /B=A:\b12test.bin
>
> 6. i12debug.com A:
>
> 7. Boot it.
>
> Next, to debug the loader in a very basic way, we can tell the debugger to
> step through it until execution leaves the boot loader. I uploaded a
> recording of the debugger I/O for this in
> https://ulukai.org/ecm/test/20200913.txt
>
> First you need to enter boot protocol chain b12test.bin and
> then the following: tp fffff while !( cs != 7C0 && cs != 0 && cs !=
> 1FE0 || ip < 7C00 || ip > 7C00+#512 ) silent
>
> This may not be sufficient to debug the loader but it will probably tell us
> something about how it fails.


where can i find testpl.com?

> > By the way, how much memory is installed on this system and available to
> > DOS?
>
> 1Mb

It is unlikely that the entire MiB is available to DOS, which expects at most 640 KiB generally. (It can be higher, but not a full MiB.) Try running ldebug /C="a;int 12;;t;h ax * #1024;q" (You can use the executable in the second archive I posted.)

---
l

> I haven't found the "setver" utility to run programs that require a
> specific version of msdos.

CALLVER (see help or download) or VERSION, in FDCONFIG.SYS, is probably what you want. (N.B. DJGPP 2.04/2.05 tools, e.g. *nix df, will not use the appropriate FAT32 APIs (7303h) without seeing version 7. Caveat emptor.)

http://help.fdos.org has the online help. (Offline help is also available.)

P.S. BTW, not sure, don't use SYS that much, but perhaps you were using it incorrectly? Normally I think you're supposed to do "sys a: c:", not just "sys c:". But I could be wrong (or maybe it varies).

> where can i find testpl.com?

It is in https://ulukai.org/ecm/test/2020-09-13--fd12test.zip that I linked in the other post. It also contains an updated mak.sh which contains the commands to create testpl.com from lmacros, scanptab, and ldosboot.

---
l

> > By the way, how much memory is installed on this system and available to
> > DOS?
>

1Mb total, 502k free...

maybe dos is not loaded in the high 384?

Resident FreeDOS guru Eric Auer writes via private email:

> The BTTR thread about that self-designed PC needs more
> details... For example, the PC designer could post the
> version numbers, md5sums, binaries, sources of the used
> kernels and boot sectors. The self-designed BIOS could
> show error messages on attempts to call unimplemented
> interrupts or functions of interrupts.
>
> The LBA version of our boot sector for FAT32 only works
> with 386, but I assume we talk about FAT16 or FAT12?
>
> How much RAM is available? FreeDOS probably needs 256k
> or more to even boot.
>
> A FAT16/FAT12 boot sector could show, using int 10 ah=0e
>
> FreeDOS
>
> err (then call int 16 ah=0, then int 19 to reboot)
>
> It would use int 13, ah=41, bx=55aa to check for LBA
> support (if carry set or bx not aa55: none?) and use
> int 13 ah=42 or int 13 ah=2 to read sectors. Also
> int 13 ah=0 after errors.
>
> The BTTR thread mentions a boot process showing ".", so
> it probably refers to the newer boot sector version here:
>
> https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/boot/boot.asm
>
> If I am not mistaken, that one needs MORE than 256k RAM.
>
> There also is Jeremy's flexible OEM boot sector:
>
> https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/boot/oemboot.asm
>
> That one would only use "):" and "." as messages while
> the normal boot sector would use "Error!" and "." so
> either of the two could be in use.
>
> An easy test for the PC builder on BTTR would be to swap
> only the KERNEL SYS files. If this fails to solve the boot
> crash, then the problem is probably in the boot sector and
> easily fixed by using another SYS, but we should also check
> whether our newest SYS has the bug
>
> If swapping KERNEL SYS however breaks the case which works
> (print FreeDOS, then load kernel) then the kernel itself is
> not working on 80186 in one of the tested kernel versions.
>
> The screenshots show that the boot sector which says "..."
> eventually proceeds to print itself and crash, while the
> boot sector which says "FreeDOS" proceeds to successfully
> löad and boot FreeDOS kernel 2040 with FAT32, Apr 7 2012,
> "C: HD1 Pri 1 CHS 0 1 1 start 0 MB size 122 MB", FreeCOM
> version 0.82 pl 3 XMS Swap Dec 10 2003 version but after
> booting from A: not C: interestingly?

> P.S. BTW, not sure, don't use
> SYS that much, but
> perhaps you were using it incorrectly? Normally I think you're supposed to
> do "sys a: c:", not just "sys c:". But I could be wrong (or maybe it
> varies).

Note that the page you linked lists sys {{d:}path} d: {bootsect {BOTH}} {BOOTONLY} {switches} (I replaced the brackets by curly braces so as not to confuse the forum's bb code parsing.)

That means it is valid to specify only one drive letter (the target). This usage is the same as allowed by MS-DOS's SYS.

Also, this page is not up to date with modern FreeDOS SYS's options and all.

---
l

> > > By the way, how much memory is installed on this system and available
> to
> > > DOS?
> >
>
> 1Mb total, 502k free...
>
> maybe dos is not loaded in the high 384?

On pre-286 cpus, there is no XMS, so no XMS_Swap FreeCOM is suitable. BARE_DOS had KSSF (or VSPAWN, I forget) which allowed "call /s" to save about 100 kb of RAM, IIRC (but resets aliases). Somewhat inconvenient but better than nothing. IIRC, you're using "old" 0.82pl3 anyways (lacking some minor stuff, e.g. DESCRIPT.ION or LFN support).

> > > By the way, how much memory is installed on this system and available
> to
> > > DOS?
> >
> > 1Mb
>
> It is unlikely that the entire MiB is available to DOS, which expects at
> most 640 KiB generally. (It can be higher, but not a full MiB.) Try running
> ldebug /C="a;int 12;;t;h ax * #1024;q" (You can use the
> executable in the second archive I posted.)


i can't, this is my fdconfig.sys ... in msdos the ram used was only 60k of command.com ... maybe i need to load drivers for high memory?

SWITCHES=/F /N

VERSION=6.22

DOS=HIGH,UMB
DOSDATA=HIGH,UMB
!FILES=80
!FCBS=8,8
!BUFFERS=10
!LASTDRIVE=G

> SWITCHES=/F /N

Don't use /F (fast) if you're still debugging things.

> VERSION=6.22

Make sure this is truly needed globally. CALLVER is better for occasional use.

> !FILES=80
> !FCBS=8,8

Skip FCBS and only use FILES=40, see if that helps.

> !BUFFERS=10

BUFFERS=2 is probably okay here, too.

Not sure if that truly saves you much, though. (Are you using KSSF or VSPAWN like in BARE_DOS?)

> > SWITCHES=/F /N
>
> Don't use /F (fast) if you're still debugging things.
>
> > VERSION=6.22
>
> Make sure this is truly needed globally. CALLVER is better for occasional
> use.
>
> > !FILES=80
> > !FCBS=8,8
>
> Skip FCBS and only use FILES=40, see if that helps.
>
> > !BUFFERS=10
>
> BUFFERS=2 is probably okay here, too.
>
> Not sure if that truly saves you much, though. (Are you using KSSF or
> VSPAWN like in BARE_DOS?)

Used 136k 504 free

i tried to load himemx.exe but it says it wants a 386+

> > > > By the way, how much memory is installed on this system and
> available
> > to
> > > > DOS?
> > >
> >
> > 1Mb total, 502k free...
> >
> > maybe dos is not loaded in the high 384?
>
> On pre-286 cpus, there is no XMS, so no XMS_Swap FreeCOM is suitable.
> BARE_DOS had KSSF (or VSPAWN, I forget) which allowed "call /s" to save
> about 100 kb of RAM, IIRC (but resets aliases). Somewhat inconvenient but
> better than nothing. IIRC, you're using "old" 0.82pl3 anyways (lacking some
> minor stuff, e.g. DESCRIPT.ION or LFN support).


but the dos kernel should load in the high 384 though? or am I wrong?

> "old" 0.82pl3

freecom 0.84-pre2 ... do i have to change it?

> 1. You can try ifd12NNA.com from this (it is likely to work).

Boot correctly

> > 4. If you want, I can give you further instructions on how to debug the
> > failing loader. The files i12debug.com (run with "A:") and ldebug.com
> (copy
> > to the diskette) in this archive can be used to set up my bootable
> > debugger. Then "ifd12org.com A: /F1=TESTPL.COM
> > /B=A:\b12test.bin" can be used to generate a chainloadable boot
> > sector dump with the failing loader. Next, boot the debugger, and try
> > running the BOOT
> > command "boot protocol chain b12test.bin" then
> > "q". If this displays the test payload status dump
> something
> > strange is going on. If it hangs the same way as that loader otherwise
> > does, we can actually debug it. (If you want to do this, tell me and
> I'll
> > get around to it within the week.)
>
> I got around to a very simple test right away. Here's what I did (using
> dosemu2):
>
> $ dd if=/dev/zero of=../diskette.img bs=1 count=$((1440 * 1024))
> $ touch autoexec.bat
> $ dosemu -dumb -quiet -K "$PWD" -I "floppy { threeinch device
> ../diskette.img }" -E "format A:"; dosemu -dumb -quiet -K "$PWD" -I "floppy
> { threeinch device ../diskette.img }" -E "ifd12quc.com A: /F1=TESTPL.COM";
> dosemu -dumb -quiet -K "$PWD" -I "floppy { threeinch device ../diskette.img
> }" -E "copy testpl.com A:"; dosemu -dumb -quiet -K "$PWD" -I "floppy {
> threeinch device ../diskette.img }" -E "copy C:kernel.sys A:"; dosemu -dumb
> -quiet -K "$PWD" -I "floppy { threeinch device ../diskette.img }" -E "copy
> D:\\dosemu\\exitemu.com A:"; dosemu -dumb -quiet -K "$PWD" -I "floppy {
> threeinch device ../diskette.img }" -E "copy C:command.com A:"; dosemu
> -dumb -quiet -K "$PWD" -I "floppy { threeinch device ../diskette.img }" -E
> "copy autoexec.bat A:"
>
> {press Enter each time for the format application's prompts}
>
> $ dosemu -dumb -quiet -K "$PWD" -I "floppy { threeinch device
> ../diskette.img }" -E "ifd12org.com A: /F1=TESTPL.COM /B=A:\b12test.bin";
> dosemu -dumb -quiet -K "$PWD" -I "floppy { threeinch device ../diskette.img
> }" -E "i12debug.com A:"; dosemu -dumb -quiet -K "$PWD" -I "floppy {
> threeinch device ../diskette.img }" -E "copy ldebug.com A:"; dosemu -dumb
> -K "$PWD" -I "floppy { threeinch device ../diskette.img }" -A
>
> How to set up the diskette:
>
> 1. Format it, leave the volume label empty.
>
> 2. Copy testpl.com to the file system. Important: This should be the very
> first file to copy onto it. (Not needed to boot it generally, but important
> to make the cluster numbers the same as those I got.)
>
> 3. Copy other files, such as the debugger, the FreeDOS kernel, FreeCOM
> (FreeDOS command.com), etc.
>
> 4. Create empty autoexec.bat for FreeCOM. (Otherwise it will prompt for
> date and time during startup.)
>
> 5. ifd12org.com A: /F1=TESTPL.COM /B=A:\b12test.bin
>
> 6. i12debug.com A:
>
> 7. Boot it.


I tried, tries to start, writes "F" and stops there, by pressing enter the bios post LEDs flash as if it wanted to restart but nothing happens to the monitor

> I tried, tries to start, writes "F" and stops there, by pressing enter the
> bios post LEDs flash as if it wanted to restart but nothing happens to the
> monitor

Are you sure you did copy ldebug.com to the diskette?

---
l

> > I tried, tries to start, writes "F" and stops there, by pressing enter
> the
> > bios post LEDs flash as if it wanted to restart but nothing happens to
> the
> > monitor
>
> Are you sure you did copy ldebug.com to the diskette?

no

> > I tried, tries to start, writes "F" and stops there, by pressing enter
> the
> > bios post LEDs flash as if it wanted to restart but nothing happens to
> the
> > monitor
>
> Are you sure you did copy ldebug.com to the diskette?


I redid also posting ldebug.com, a message appears "[more]" if I try to write something it doesn't make me write, any key I try to press messes with the writing [more] but I don't seem to be able to do anything ... I don't know if it's important but SBC188 has no keyboard and real monitor, I am connected in terminal via putty.

> > > By the way, how much memory is installed on this system and available
> to
> > > DOS?
> >
> > 1Mb
>
> It is unlikely that the entire MiB is available to DOS, which expects at
> most 640 KiB generally. (It can be higher, but not a full MiB.) Try running
> ldebug /C="a;int 12;;t;h ax * #1024;q" (You can use the
> executable in the second archive I posted.)

> I redid also posting ldebug.com, a message appears "[more]" if I try to
> write something it doesn't make me write, any key I try to press messes
> with the writing [more] but I don't seem to be able to do anything ... I
> don't know if it's important but SBC188 has no keyboard and real monitor, I
> am connected in terminal via putty.

Hmm I have an idea what might cause this. The problem likely is not with the keyboard input and screen output; the debugger uses the ROM-BIOS interfaces for those (int 16h and int 10h). These seem to be supported by the SBC188.

I will provide you with an adjusted binary later today. For now, you can run the following command from DOS to help me determine whether I am right: ldebug.com /C="h byte [40:84];q" (This byte is used by the debugger's pagination mechanism to determine how many rows to display before paging. I expect it might be initialised to zero or not initialised at all by the SBC188 ROM-BIOS.)

And by the way, to make the debugger usable as a DOS application right now you can start it like ldebug.com /C="r dco |= 10" (which sets the "disallow paged output to StdOut" option flag). Unfortunately this does not directly translate to the bootable mode of the debugger because it would require passing a kernel command line according to the lDOS / RxDOS.3 load protocol. It happens to be the case that the debugger itself is currently the only way to pass such a command line. That's why I'll have to fix the debugger's paging handling or disable it by default to help you use it on the SBC188.

---
l

> > I redid also posting ldebug.com, a message appears "[more]" if I try to
> > write something it doesn't make me write, any key I try to press messes
> > with the writing [more] but I don't seem to be able to do anything ... I
> > don't know if it's important but SBC188 has no keyboard and real monitor,
> I
> > am connected in terminal via putty.
>
> Hmm I have an idea what might cause this. The problem likely is not with
> the keyboard input and screen output; the debugger uses the ROM-BIOS
> interfaces for those (int 16h and int 10h). These seem to be supported by
> the SBC188.
>
> I will provide you with an adjusted binary later today. For now, you can
> run the following command from DOS to help me determine whether I am right:
> ldebug.com /C="h byte [40:84];q" (This byte is used by the
> debugger's pagination mechanism to determine how many rows to display
> before paging. I expect it might be initialised to zero or not initialised
> at all by the SBC188 ROM-BIOS.)

> And by the way, to make the debugger usable as a DOS application right now
> you can start it like ldebug.com /C="r dco |= 10" (which sets
> the "disallow paged output
> to StdOut" option flag). Unfortunately this does not directly
> translate to the bootable mode of the debugger because it would require
> passing a kernel command line according to the lDOS / RxDOS.3 load
> protocol. It happens to be the case that the debugger itself is currently
> the only way to pass such a command line. That's why I'll have to fix the
> debugger's paging handling or disable it by default to help you use it on
> tne SBC188.

> > > > By the way, how much memory is installed on this system and
> available
> > to
> > > > DOS?
> > >
> > > 1Mb
> >
> > It is unlikely that the entire MiB is available to DOS, which expects at
> > most 640 KiB generally. (It can be higher, but not a full MiB.) Try
> running
> > ldebug /C="a;int 12;;t;h ax * #1024;q" (You can use the
> > executable in the second archive I posted.)
>
>

As expected there's 640 KiB of low memory available to DOS. It is highly likely that this is the same as available to the dot-displaying boot sector loader, which means that a lack of memory is not a cause for its failure.

By the way, it might be possible to have a special driver offer some additional memory (between 640 KiB and 1024 KiB) to DOS as upper memory. If so then your DOS=UMB setting could take effect and DOS could link such memory as UMBs into its memory chain.

Perhaps such a driver already exists for the SBC188. I created such a driver for the 8086tiny environment. However, it would have to be adjusted to work with the SBC188. And it would be crucial to know exactly which memory areas are both backed by actual RAM and available for us to use. As I stated in the readme: "the UMB area is assumed by the DOS driver. (This is 128 KiB (2000h paragraphs) between segments D000h and EFFFh.)"

---
l

> > > > > By the way, how much memory is installed on this system and
> > available
> > > to
> > > > > DOS?
> > > >
> > > > 1Mb
> > >
> > > It is unlikely that the entire MiB is available to DOS, which expects
> at
> > > most 640 KiB generally. (It can be higher, but not a full MiB.) Try
> > running
> > > ldebug /C="a;int 12;;t;h ax * #1024;q" (You can use the
> > > executable in the second archive I posted.)
> >
> >
>
> As expected there's 640 KiB of low memory available to DOS. It is highly
> likely that this is the same as available to the dot-displaying boot sector
> loader, which means that a lack of memory is not a cause for its failure.
>
> By the way, it might be possible to have a special driver offer some
> additional memory (between 640 KiB and 1024 KiB) to DOS as upper memory. If
> so then your DOS=UMB setting could take effect and DOS could link such
> memory as UMBs into its memory chain.
>
> Perhaps such a driver already exists for the SBC188. I created
> such
> a driver for the 8086tiny environment. However, it would have to be
> adjusted to work with the SBC188. And it would be crucial to know exactly
> which memory areas are both backed by actual RAM and available for us to
> use. As I stated
> in
> the readme: "the UMB area is assumed by the DOS driver. (This is 128
> KiB (2000h paragraphs) between segments D000h and EFFFh.)"

how do i know these things? i don't know exactly how SBC188's RAM is mapped,
is there any way to find out? however with ms dos 6.22 the ram occupied was only 60k (command.com) freedos consumes almost 140k

> how do i know these things? i don't know exactly how SBC188's RAM is
> mapped,
> is there any way to find out? however with ms dos 6.22 the ram occupied was
> only 60k (command.com) freedos consumes almost 140k

The memory usage of FreeDOS is probably due to FreeCOM (their command.com) not swapping itself away when you run another program. I think (as per Rugxulo's comments) that this is only implemented one way per build, and the default build requires XMS for its swap method.

About how to know that, I cannot tell you. This thread is the first I've ever heard of the SBC188 so I don't know the details either. Perhaps someone else who works with these boards knows more. Anyway, it isn't that important.

---
l

> I redid also posting ldebug.com, a message appears "[more]" if I try to
> write something it doesn't make me write, any key I try to press messes
> with the writing [more] but I don't seem to be able to do anything

(Nitpick: Technically you can enter commands in this state but it is a pain, involving several (three?) key presses for every one character you want to enter. This is not exactly usable.)

I uploaded a new revision of the debugger to https://ulukai.org/ecm/test/2020-09-14--ldebug-3a05abfb3dac.zip (in the bin/ subdirectory). You can copy that to a diskette and prepare it with the i12debug.com instsect application I uploaded previously.

Next you can try the remaining tests I listed in one of the earlier posts as well as the test run I proposed after that.

---
l

"boot protocol chain b12test.bin" then
> "q". If this displays the test payload status dump something
> strange is going on. If it hangs the same way as that loader otherwise
> does, we can actually debug it. (If you want to do this, tell me and I'll
> get around to it within the week.)

> First you need to enter boot protocol chain b12test.bin and
> then the following: tp fffff while !( cs != 7C0 && cs != 0 && cs !=
> 1FE0 || ip < 7C00 || ip > 7C00+#512 ) silent
>
> This may not be sufficient to debug the loader but it will probably tell us
> something about how it fails.


the dots were moving very slowly, then he wrote a lot of code and ended up like that.