DOS ain't dead - FreeDOS on SBC188

GizMo79

12.09.2020, 01:26

FreeDOS on SBC188 (Announce)

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:
[image]

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 ...
[image]

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?

Oso2k 12.09.2020, 01:59 @ GizMo79	FreeDOS on SBC188 Post reply
	be sure to select a bootable image that has an 8086 kernel. Other kernels may include instructions that your 186 cpu does not understand.

Oso2k 12.09.2020, 02:03 @ Oso2k	FreeDOS on SBC188 Post reply
	> 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/

GizMo79 12.09.2020, 02:12 @ Oso2k	FreeDOS on SBC188 Post reply
	> > 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

GizMo79

12.09.2020, 02:16

@ Oso2k

FreeDOS on SBC188

Post reply

> > 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?

Rugxulo

Usono,
12.09.2020, 02:36

@ GizMo79

FreeDOS on SBC188

Post reply

> 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).

GizMo79

12.09.2020, 03:00

@ Rugxulo

FreeDOS on SBC188

Post reply

> > 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 ...

GizMo79

12.09.2020, 03:42

@ Rugxulo

FreeDOS on SBC188

Post reply

> > 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"

Oso2k 12.09.2020, 06:30 @ GizMo79	FreeDOS on SBC188 Post reply
	Interesting results. What is the cost to buy the BOM?

GizMo79 12.09.2020, 11:59 @ Oso2k	FreeDOS on SBC188 Post reply
	> Interesting results. What is the cost to buy the BOM? do you want to build a sbc188?

GizMo79

12.09.2020, 11:58

@ Rugxulo

FreeDOS on SBC188

Post reply

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?

ecm

Düsseldorf, Germany,
12.09.2020, 13:06

@ GizMo79

FreeDOS on SBC188

Post reply

> 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

ecm

Düsseldorf, Germany,
12.09.2020, 14:56

@ GizMo79

FreeDOS on SBC188

Post reply

> 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

ecm

Düsseldorf, Germany,
12.09.2020, 15:06

@ ecm

FreeDOS on SBC188

Post reply

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

ecm

Düsseldorf, Germany,
12.09.2020, 15:21

@ ecm

FreeDOS on SBC188

Post reply

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

GizMo79 13.09.2020, 15:19 @ ecm	FreeDOS on SBC188 Post reply
	I made it work fine :) I created a boot and installation floppy dedicated to the SBC188, are you interested in having the image?

ecm

Düsseldorf, Germany,
13.09.2020, 19:36

@ GizMo79

FreeDOS on SBC188

Post reply

> 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

GizMo79

13.09.2020, 20:14

@ ecm

FreeDOS on SBC188

Post reply

> > 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.

Rugxulo

Usono,
13.09.2020, 22:11

@ GizMo79

FreeDOS on SBC188

Post reply

> 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).

ecm

Düsseldorf, Germany,
13.09.2020, 22:19

@ Rugxulo

FreeDOS on SBC188

Post reply

> 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

GizMo79

12.09.2020, 22:06

@ ecm

FreeDOS on SBC188

Post reply

> > 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?

ecm

Düsseldorf, Germany,
13.09.2020, 21:07

@ GizMo79

FreeDOS on SBC188

Post reply

> 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

ecm

Düsseldorf, Germany,
13.09.2020, 21:39

@ ecm

FreeDOS on SBC188

Post reply

> 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

GizMo79

13.09.2020, 22:09

@ ecm

FreeDOS on SBC188

Post reply

> > 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?

ecm

Düsseldorf, Germany,
13.09.2020, 22:12

@ GizMo79

FreeDOS on SBC188

Post reply

> 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

GizMo79

14.09.2020, 00:48

@ ecm

FreeDOS on SBC188

Post reply

> > 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

ecm

Düsseldorf, Germany,
14.09.2020, 04:48

@ GizMo79

FreeDOS on SBC188

Post reply

> 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

GizMo79 14.09.2020, 11:53 @ ecm	FreeDOS on SBC188 Post reply
	> > 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

GizMo79

14.09.2020, 12:05

@ ecm

FreeDOS on SBC188

Post reply

> > 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.

ecm

Düsseldorf, Germany,
14.09.2020, 13:22

@ GizMo79

FreeDOS on SBC188

Post reply

> 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

GizMo79

14.09.2020, 13:31

@ ecm

FreeDOS on SBC188

Post reply

> > 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.)

[image]

GizMo79

14.09.2020, 13:34

@ ecm

FreeDOS on SBC188

Post reply

> 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.

[image]

ecm

Düsseldorf, Germany,
14.09.2020, 23:31

@ GizMo79

FreeDOS on SBC188

Post reply

> 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

GizMo79 15.09.2020, 00:26 @ ecm	FreeDOS on SBC188 Post reply
	> 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.

ecm

Düsseldorf, Germany,
15.09.2020, 10:03

@ GizMo79

FreeDOS on SBC188

Post reply

Next try the following:

1. Boot into the debugger.

2. boot protocol chain b12test.bin

3. tp fffff while cs != 1FE0

4. tp fffff while cs == 1FE0 && (ip != 7D41 || al == 2E) silent

5. Show us what is visible after the prior step.

6. d ds:si - 10 length 20

7. Again show us what is visible.

It would be helpful for step 5 if you could resize your window to have more rows if that is possible. The silent buffer is nearly 8 KiB large and it may help to see more of the traces leading up to the while condition mismatch.

---
l

GizMo79

15.09.2020, 13:52

@ ecm

FreeDOS on SBC188

Post reply

> Next try the following:
>
> 1. Boot into the debugger.
>
> 2. boot protocol chain b12test.bin
>
> 3. tp fffff while cs != 1FE0

[image]

>
> 4. tp fffff while cs == 1FE0 && (ip != 7D41 || al == 2E)> silent
>
> 5. Show us what is visible after the prior step.

[image]

>
> 6. d ds:si - 10 length 20
>
> 7. Again show us what is visible.

[image]

>
> It would be helpful for step 5 if you could resize your window to have more
> rows if that is possible. The silent buffer is nearly 8 KiB large and it
> may help to see more of the traces leading up to the while condition
> mismatch.

sbc 188 has VGA emulation over serial, putty is configured to display fixed 80x25 to work, I can scroll through it but as soon as I let go of the window it comes down it is difficult to take so many screenshots.

ecm

Düsseldorf, Germany,
15.09.2020, 15:15

@ GizMo79

FreeDOS on SBC188

Post reply

> > Next try the following:
> >
> > 1. Boot into the debugger.
> >
> > 2. boot protocol chain b12test.bin
> >
> > 3. tp fffff while cs != 1FE0
>
> [image]

As expected.

> > 6. d ds:si - 10 length 20
> >
> > 7. Again show us what is visible.
>
> [image]

This confirms that the memory was not corrupted: The dot is still in memory after the call instruction where it belongs.

> > 4. tp fffff while cs == 1FE0 && (ip != 7D41 || al == 2E)> > silent
> >
> > 5. Show us what is visible after the prior step.
>
> [image]

Ah, now everything is clear. The SBC188 ROM-BIOS that you use appears to modify the value in the al register when called for interrupt 10h service 0Eh and the cursor is at the end of the line. In that case it returns with al equal to 0Ah (the Line Feed codepoint). The modern FAT12/FAT16 FreeDOS boot sector loader expects the register to remain unchanged, so that it can check whether it finished displaying.

On your hard disk either you're using the (CHS) FAT32 loader, or it might be the case that you're using the FAT16 loader but it doesn't display as many dots as needed to fill the line width. If you have a cluster size larger than 1 sector (512 bytes), then the sector reading code will only display one dot per cluster. It will loop to read_next for the subsequent sectors in the cluster, which doesn't display another dot.

If you're already in contact with the maintainers of the SBC188 board's firmware, can you please point them to this? The int 10.0E service is expected to preserve the contents of the al register. I will prepare a patch for the FreeDOS boot sector loader regardless, but it is better to fix the bug on both sides, so that current FreeDOS loaders will also work on this board after a ROM-BIOS update.

---
l

ecm

Düsseldorf, Germany,
15.09.2020, 15:48

@ ecm

FreeDOS on SBC188

Post reply

> I will
> prepare a patch for the FreeDOS boot sector loader regardless, but it is
> better to fix the bug on both sides, so that current FreeDOS loaders will
> also work on this board after a ROM-BIOS update.

Pull request created at https://github.com/FDOS/kernel/pull/25

---
l

GizMo79

15.09.2020, 21:19

@ ecm

FreeDOS on SBC188

Post reply

> > > Next try the following:
> > >
> > > 1. Boot into the debugger.
> > >
> > > 2. boot protocol chain b12test.bin
> > >
> > > 3. tp fffff while cs != 1FE0
> >
> > [image]
>
> As expected.
>
> > > 6. d ds:si - 10 length 20
> > >
> > > 7. Again show us what is visible.
> >
> > [image]
>
> This confirms that the memory was not corrupted: The dot is still in memory
> after the call instruction where it belongs.
>
> > > 4. tp fffff while cs == 1FE0 && (ip != 7D41 || al == 2E)> > > silent
> > >
> > > 5. Show us what is visible after the prior step.
> >
> > [image]
>
> Ah, now everything is clear. The SBC188 ROM-BIOS that you use appears to
> modify the value in the al register when called for interrupt
> 10h service 0Eh and the cursor is at the end of the line. In that case it
> returns with al equal to 0Ah (the Line Feed codepoint). The
> modern FAT12/FAT16 FreeDOS boot sector loader expects the register to
> remain unchanged, so that
> it
> can check whether it finished displaying.
>
> On your hard disk either you're using the (CHS) FAT32 loader, or it might
> be the case that you're using the FAT16 loader but it doesn't display as
> many dots as needed to fill the line width. If you have a cluster size
> larger than 1 sector (512 bytes), then the sector reading code will only
> display one dot per cluster. It will
> loop
> to read_next for the subsequent sectors in the cluster, which doesn't
> display another dot.
>
> If you're already in contact with the maintainers of the SBC188 board's
> firmware, can you please point them to this? The int 10.0E service is
> expected to preserve the contents of the al register. I will
> prepare a patch for the FreeDOS boot sector loader regardless, but it is
> better to fix the bug on both sides, so that current FreeDOS loaders will
> also work on this board after a ROM-BIOS update.

I use FAT16 for compact flash

ecm

Düsseldorf, Germany,
15.09.2020, 15:54

@ GizMo79

FreeDOS on SBC188

Post reply

Please retry booting KERNEL.SYS with ifd12new.com from the file https://ulukai.org/ecm/test/2020-09-15--fd12test.zip

---
l

GizMo79 15.09.2020, 21:25 @ ecm	FreeDOS on SBC188 Post reply
	> Please retry booting KERNEL.SYS with ifd12new.com from the file > https://ulukai.org/ecm/test/2020-09-15--fd12test.zip it works, started! makes more than 1 a line of dots ... a line and a little more. I inform the creator of SBC188 One thing, however, I do not understand, what does the new bootloader do that the old ones that already work don't? why not keep the old bootloaders working?

ecm

Düsseldorf, Germany,
15.09.2020, 23:18

@ GizMo79

FreeDOS on SBC188 - Differences of loaders

Post reply

> One thing, however, I do not understand, what does the new bootloader do
> that the old ones that already work don't? why not keep the old bootloaders
> working?

I haven't studied the exact differences between the older and more recent original FreeDOS loaders.

As for my (lDOS boot) loaders, the _COMPAT_FREEDOS variants relocate differently than FreeDOS's originals. That means the kernel file to load can be larger. However, I had to disable the RPL support for things to fit into the loader. The FreeDOS originals do not exactly support RPLs but their fixed relocation is unlikely to corrupt any RPL of reasonable size.

The "L" in my loader instsect names stands for "LBA only". The "C" stands for "CHS only". The "A" stands for "Automatically try LBA and if it returns error 1 then try CHS". Using "C" or "L" loaders may be needed to override a wrong detection decision. As opposed to our "A" variants, FreeDOS original loaders assume a diskette is always CHS, and otherwise do a proper LBA detection callout to determine whether to try LBA or CHS. (There is an option for ours to use the detection callout but it is disabled by default because it needs more space.)

The "U" in my loader names stands for "Use partition information". This means that, when booting a hard disk (unit >= 128), the load partition offset from a prior MBR stage is used, if a simple detection scheme suggests it is there. This is useful in that the "hidden sectors" field in the boot sector's BPB need not be maintained. On the other hand, the detection can yield a false positive and trash the hidden sectors to use, so an "N" variant may be better in some cases. On diskettes the "U" detection always yields negative so the hidden sectors are used as stored on disk (generally holding a value of zero). FreeDOS's original loaders always act like my loaders without "U".

The "Q" stands for "Query Geometry" which means the loader will try to ask the ROM-BIOS for the CHS geometry. This again means that the Heads and Sectors fields of the boot sector need not be maintained. (Crucially, when moving a disk from one system to another, the systems may disagree about the geometry to use.) The detection is unlikely to turn up any false positives. If the detection result is negative, the values stored on disk in the BPB are used. Diskettes usually don't support the call (int 13.08) used for the detection. The "L" variants of the loaders do not come in "Q" variants because L means that the CHS geometry is never used so the Q option would only waste space. FreeDOS's originals always act like the non-"Q" loaders.

Other than that, my loaders support uncommon sector, cluster, and root directory sizes. Specifically, sector sizes 32 to 8192 bytes, cluster sizes 32 bytes to about 128 KiB, and root directory sizes that do not match to a sector size boundary as well as root directory sizes exceeding 64 KiB. (The 128 KiB cluster size limitation is because of limitations of a simple FreeDOS load protocol implementation. Other protocols allow cluster sizes up to 2 MiB.)

My loaders will detect and error out on file too large situations. They will also retry CHS reads if interrupt 13h calls return failure.

The FAT16 loader will only load a single sector of the FAT per call, if and when it is needed; FreeDOS's FAT16 loader always loads the entire FAT. (In pathological cases my approach may actually read FAT sectors more often than theirs, but realistically mine is better.)

My loaders will load root directory sectors one by one too, so they won't read the entire root directory if the load file is found before the last directory sector. FreeDOS FAT12 and FAT16 loaders always load the entire root directory.

My loaders only display a single letter in error conditions, but it differs which letter it is depending on the cause. ("R"ead error, "F"ile not found, Out of "M"emory, Check "V"alue mismatch.) I also send a codepoint 7 (Bell). Other than their longer error message, FreeDOS original loaders of course have the dots display for each sectors read call.

This comparison is all about the FAT12 and FAT16 loaders, and only the FreeDOS load protocol ones. The FAT32 loaders are a little different. Comparing my FAT32 loader to theirs, they also made different decisions. My native (lDOS load protocol) loaders also differ in more ways.

---
l

GizMo79 18.09.2020, 00:55 @ ecm	FreeDOS on SBC188 - Differences of loaders Post reply
	The creator of SBC188 sent me a beta bios that solves the problem, now the official version of freedos also starts without modifications.

GizMo79 14.09.2020, 00:29 @ ecm	FreeDOS on SBC188 Post reply
	> 1. You can try ifd12NNA.com from this (it is likely to work). Boot correctly

GizMo79 15.09.2020, 00:14 @ ecm	FreeDOS on SBC188 Post reply
	"`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.)

ecm

Düsseldorf, Germany,
13.09.2020, 21:39

@ GizMo79

FreeDOS on SBC188

Post reply

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

---
l

GizMo79 13.09.2020, 22:04 @ ecm	FreeDOS on SBC188 Post reply
	> By the way, how much memory is installed on this system and available to > DOS? 1Mb

ecm

Düsseldorf, Germany,
13.09.2020, 22:10

@ GizMo79

FreeDOS on SBC188

Post reply

> > 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

GizMo79

13.09.2020, 22:27

@ ecm

FreeDOS on SBC188

Post reply

> > > 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

Rugxulo Usono, 13.09.2020, 22:32 @ GizMo79	FreeDOS on SBC188 Post reply
	> 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?)

GizMo79

13.09.2020, 22:42

@ Rugxulo

FreeDOS on SBC188

Post reply

> > 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+

GizMo79 14.09.2020, 12:12 @ ecm	FreeDOS on SBC188 Post reply
	> > > 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.)

ecm

Düsseldorf, Germany,
14.09.2020, 13:35

@ GizMo79

FreeDOS on SBC188

Post reply

> > > > 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.)
>
> [image]

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

GizMo79

14.09.2020, 21:46

@ ecm

FreeDOS on SBC188

Post reply

> > > > > 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.)
> >
> > [image]
>
> 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

ecm

Düsseldorf, Germany,
14.09.2020, 23:22

@ GizMo79

FreeDOS on SBC188

Post reply

> 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

GizMo79

15.09.2020, 13:40

@ GizMo79

FreeDOS on SBC188

Post reply

> > 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

I asked the creator of sbc188 he replied:

RAM mapping:

All RAM maps to address space 00000..FFFFF, except

1. Upper memory block maps to ROM, and is excluded from the above. ROM is currently 64K.

2. Middle memory block maps to off-board (VGA) memory and Expanded Memory (4MEM board): A0000..BFFFF. It likewise is excluded from the RAM area.

Thus C0000..EFFFF regions are available as Upper Memory Blocks.

B0000.BFFFF are the MDA and VGA a/n regions. A0000..AFFFF would normally be Graphic memory. But with no graphics cards for the ECB bus, this is the area for use by EMM. This is a somewhat odd arrangement, but is dictated by the 80C188 on-board memory mapping hardware. Consult the datasheet for the chip, and note especially the restrictions on use of the Middle Memory Map: its location must be an exact multiple of its size.

Making use of the UMB's is a good idea.

ecm

Düsseldorf, Germany,
15.09.2020, 13:53

@ GizMo79

FreeDOS on SBC188

Post reply

> Thus C0000..EFFFF regions are available as Upper Memory Blocks.
>
> B0000.BFFFF are the MDA and VGA a/n regions. A0000..AFFFF would normally
> be Graphic memory. But with no graphics cards for the ECB bus, this is the
> area for use by EMM. This is a somewhat odd arrangement, but is dictated
> by the 80C188 on-board memory mapping hardware. Consult the datasheet for
> the chip, and note especially the restrictions on use of the Middle Memory
> Map: its location must be an exact multiple of its size.
>
> Making use of the UMB's is a good idea.

Do you know a way to detect the SBC188 system? If so I could adapt the UMB driver.

---
l

GizMo79 13.09.2020, 22:13 @ GizMo79	FreeDOS on SBC188 Post reply
	> > 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?

Rugxulo

Usono,
13.09.2020, 22:21

@ GizMo79

FreeDOS on SBC188

Post reply

> > > 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).

GizMo79

13.09.2020, 22:44

@ Rugxulo

FreeDOS on SBC188

Post reply

> > > > 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?

GizMo79 13.09.2020, 22:47 @ Rugxulo	FreeDOS on SBC188 Post reply
	> "old" 0.82pl3 freecom 0.84-pre2 ... do i have to change it?

GizMo79

01.10.2020, 13:35

@ Rugxulo

FreeDOS on SBC188

Post reply

> > > > 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).

explain me this thing of having to be able to use the high memory with freedos above 188?

Rugxulo

Usono,
13.09.2020, 22:16

@ GizMo79

FreeDOS on SBC188

Post reply

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?