Hi Bernd, > Only KERNEL2.SYS works for me, better than the Fastboot supporting > kernel I downloaded (I think) a while ago. > KERNEL.SYS in your zip hangs my machine at the HMA/BUFFERS message.
Yes, I have the same problem :-(. What I did to create kernel2 is to undo the changes of SVN revision 1325: http://freedos.svn.sourceforge.net/viewvc/freedos?view=rev&revision=1325 This change adds FASTBOOT support but also moves irqstack into another segment. I have no idea why, but this and all later revisions crash when the kernel tries to load the shell and/or tries to move into the HMA (it even happens when no HIMEM is loaded, though) in Bochs. It never crashes in Dosemu, though! The only relevant difference I could find is that the DOS_PSP at 60:0 shows that int 22..24 vectors moved from d1:xx to d4:xx (and that JFT and SS:SP differ, of course). I did a binary search to find where the crash got introduced, starting at 1315 and 1333 (1334 is fcbfns.c int 21.29, 1335 is initial lastdrive, 1336/1337 are 8086 compatibility and "cli in int19", 1338-1340 are by me). It is possible that some OTHER version in 1326-1332 range works. Bart, as you did most changes in that range, could you please test and comment? I did not know whether you are on the kernel list, so I CCed you, just in case... So what went wrong here? The new IRQ handling / FASTBOOT support? Or maybe a later revision fixed that and introduced some other issue, related to the new UPX / exeflat style added there? > > 1. This should make Robert happy. The kernel now produces messages > > as "UMBs unavailable!" instead of ("Dutch") "UMB's unavailable!" > > Dutch is the only language where "plural's" are correct, I think. > > > Depends, normally the [s] is added, but some english terms like 'baby' > are plural with ['s]. > Also depends what the kernel is trying to say: > *UMB ['s/is] unavailable > *UMBs unavailable > *UMBs are unavailable I would not shorten the "is" into "'s" in any other context than "it's nice" and similar. Other sounds, hmm, very "spoken language". But baby never has a plural with 's outside the Dutch language :-p. Merriam Webster: www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=baby > > 3. Usage: keybuf=n[,m] > > Relocate keyboard buffer from the default location at > > 0x40:0x1e-0x3e to 0x40:n-m... > what's the benefit of this? a larger keyboard input buffer like > Dos 7.10 (1024chars) ? Yes! I did not know MS DOS 7.10 has this, details? Rugxulo uses a device driver which allocates 0.5k (256 chars) and moves the buffer there (only works if device ends up in first 65 kB of RAM). I found out that Bochs uses 40:b9 for VBE, so if I move the buffer there, I break FDAPM's Bochs-detection, so it crashes in APMDOS mode again as the Bochs APM BIOS has a bug. Plus VBE stops working ;-). As you can see, KEYBUF is not super tame. However, 0x120-0x1d0 (maybe even 0x108-0x1e0) works perfectly in all tested contexts, 108 chars is already much better than the default 16 chars :-). > offtopic questions: are Japheth's drivers compressed by UPX or I can gzip them to 2/3 of their normal size, so I would say they are not compressed at all. You should ask Japheth if this is by design (cannot be UPXed) or just because he did not compress them. > A single binary '286 XMS driver' + '386 XMS driver' + '386 > EMS/UMB/VCPI/VDS driver' + '386 XMS/EMS' driver would be fun :) As said several times, I dislike the "XMS+EMS combined" style of JEMMEX because you cannot test the XMS/HMA and EMS/UMB part separately any more. But that may be a question of taste. If you had a "XMS only" mode in JEMMEX, then it would probably be a very different implementation compared to a classic HIMEM. Having built-in 286 drivers does not sound useful to me. The few people with a 286 should better use special 286 drivers. Eric ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
