Re: [Freedos-user] FreeDOS on the Ultimate Boot Cd
I tried to download the 3.3 .ISO but couldn't find it, could you? Maybe you have to download the zip file? btw: I have only 8k internet access at home, i have to wait until i am at the university (in 1 or two weeks). Bye, Flo -- Unofficial Dr-DOS page http://www.drdos.org --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] re: FreeDOS kicks some serious Ass!
Hi, to get plain boot disks (the ones on the ISO image download area are indeed meant only as helpers with the install-from-CD-ROM process) you should try ODIN or the bootdisks on fdos.org (fdos.org/kernel/ also has the newest kernel and shell versions, but avoid the 386-optimized and experimental ones...). One caveat for ODIN: You either have to delete fdconfig sys or edit it - normally FreeDOS first looks at fdconfig sys, and only if none is found, config sys is processed. Plus the ODIN fdconfig sys has a SHELL line which selects no autoexec. In short, ODIN has the very strange property of defaulting to F5 style boot. But it has lots of software included, while the fdos.org boot- disks are very bare :-). You can also check the NwDsk bootdisk on veder.com, of which FreeDOS-based versions are available as well. Eric PS: You should try emm386 instead of umbpci - both can have DMA issues with UMBs, but emm386 works on all 386+ systems while umbpci does not support all hardware and can sometimes create slow (uncached) UMBs. Get it at ftp://ftp.devoresoftware.com/ (newest is emmx204, contains EMM386 2.04 and HIMEM 3.11). PPS: DOS will just ignore RAM above 4 GB and 2nd CPUs and hyperthreading. And the partitioning scheme is limited to 2 TeraBytes. Try UDMA2 sys :-). (of course you can also work without any UMBPCI/EMM386... I prefer the usbaspi4 and aspidisk drivers for USB, by the way, even DEVLOADable well) --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] re: DEVLOAD / ramdisk troubles - or kernel problems?
Hi Bernd... Hi, I got some strange problems with DEVLOAD: If I use it to load any of my ramdisks, FreeDOS becomes unable to cd .. or cd \... Which kernel, shell, himem and emm386 versions, Newest himem / emm386 and two of the 2035* kernels tested... contents of config.sys and autoexec.bat, MEM /C, MEM /D... Lots of things - but the problem already happens with minimal drivers loaded as far as I can tell (tested in F8 mode). Which ramdisks? *xsmdsk.exe commandline, *xmsdsk.exe config.sys (DEVICE=), *xmsdsk.exe config.sys (INSTALL=) *xmsdsk.exe devload, As told, only DEVLOAD is affected. I usually load XMSDSK as DEVICE with the /t option, but found that this causes troubles with MS Win3.1 EMM386 (4.44), while loading XMSDSK from commandline does not cause those troubles. Anyway, the I can no longer do cd .. problem ONLY happens for DEVLOAD. Did not test with INSTALL but I assume same results as for commandline there. If you have time, please test all four styles both with and without FreeDOS EMM386. Thanks... *MS RAMDRIVE.SYS which of above mentioned loading methods? Don't have it. *TDSK, which methods? Not sure if I tested DEVLOAD, but the problem does NOT show up with the normal commandline and DEVICE= loading styles for sure. *Deskwork ramdisk, which methods? This ramdisk is a sys file, so you can only use DEVLOAD (and work- alikes) or DEVICE=, and the cd .. problem only happened with DEVLOAD. *SHSHUfdrv.exe, which methods? Did not test. If you have time, test. Same for SRDISK. How is the behaviour on MSDOS? I only own Windows 3.1, not MS DOS. How is the behaviour on DRDOS? Don't have that installed, sorry. Just the EMM386 of it - but I should make clear that all the DEVLOAD tests focus on FD EMM386 and on no-EMM386 environment. It may or may not help to use other EMM386, but it would be VERY interesting to hear whether DEVLOAD works better with non-FreeDOS kernels for ramdisks. By the way, I never noticed cd .. problems after DEVLOADing USB-stick drivers. other commandline devicedriver loaders, like CTLOAD or DEVICE.COM (from Qemm) or DYNALOAD If you have time and have those loaders, please test. size of 15000k, which should default to 468 clusters fat12, 32kb per cluster, 1 fat, 512 root dir entries. should ? what's the actual geometry then? Ramdisks do not technically have a geometry, but yes, I did use the syntax DEVLOAD filename 15000. EMM386 is not a factor in the problem? or is it? I assume it is not, although there is a separate problem: AuGoS reboots when you ask it to play against itself if a ramdisk is loaded as DEVICE= and the EMM= option of EMM386 is used. All other combinations now work with AuGoS :-). (e.g. no ramdisk, commandline ramdisk, no EMM= option, no EMM386) I hope this helps with testing. If you multiply all factors, you would get far too many test-runs, but you can do a linear test: Use FD kernel / himem / emm386, DW ramdisk, but use something else than DEVLOAD. If that helps, good to know. Use non-FD kernel, FD himem / emm386, DW ramdisk, devload. If that helps, the problem is kernel. Otherwise probably devload. Use newest fdos.org kernels and apart from that, the usual stuff. If that helps, we should probably release an improved kernel on SF.net, as most people (me neither) do not do weekly kernel sys updates from fdos.org... Newest can mean either stable or devel. The debug-kernels do not seem to work, as you said (too big in RAM, too many messages?) and the 386-kernels might still be emm386-incompatible (please test if you have time - it MIGHT also be yet another 32bit register changed during init or some xms/a20/umb function problem caused by emm386, but my gut feeling blames the kernel ;-)). You should get the idea - keep most factors constant and change one at a time until the cd .. problem stops happening. Then check if using the seems to cause cd .. problems component can work properly in non-FreeDOS environment - if so, more than one component is involved. But the change things until problem goes away test would already be very useful even if you do not do the test whether the component gets more stable outside FreeDOS. Eric PS: Make sure to take notes on paper to avoid double-testing ;-). --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] re: DEVLOAD / ramdisk troubles - or kernel problems?
Hi, as the KERNEL.dbgdev from fdos.org/kernel works for me in
DOSEmu, I could do some DEVLOAD CD .. problem debugging:
Unfortunately the debug output is very verbose and multi-line, so
I replaced media_check: no change by MC:ok and replaced
get_near_f_node and got near fnode by getfnode and got: below:
D:\TEMPcd ..
MC:ok getfnode: fnp is 0108:0CE0 got: fnp-f_count=1 MC:ok
truename(..)
CDS entry: #3 @C430:0108 (2) 'D:\TEMP'
[At this point you get CHDIR failed from FreeCOM after DEVLOADing
the Deskwork RAMDISK or another RAMDISK... Does not happen with
DEVICE= loaded RAMDISKs or drivers which can be loaded from prompt
without devload, nor does it happen with usbaspi or aspidisk devload!]
SUBSTing from: D:\TEMP
MC:ok getfnode: fnp is 0108:0CE0 got: fnp-f_count=1 MC:ok
Absolute logical path: D:\
Physical path: D:\
MC:ok getfnode: fnp is 0108:0CE0 got: fnp-f_count=1 MC:ok
MC:ok getfnode: fnp is 0108:0CE0 got: fnp-f_count=1 MC:ok
D:\
Given the code flow in COUNT truename(...) and the (missing) debug
messages before the failure, I think that
struct dhdr FAR *IsDevice(const char FAR * fname)
has a problem here. But why does that only happen with DEVLOAD?
Other candidates are drNrToLetter() and DosGetCuDir()...
But IsDevice looks like the one: It walks the device chain
starting from nul_dev to check if (the part before the dot of)
the provided filename matches the name of any device.
In the first place, file names like ., .. or \ should
always return is not a device name at once without even
walking the device chain.
Second, device chain entries ONLY have names for CHAR devices,
so the is the name the same as the name of the device? part
should be SKIPPED for BLOCK devices.
The problem happens in real DOS, in DOSEmu for diskimage drives,
and even in DOSEmu for lredir drives, and it looks like the
kernel is to blame here...
I hope there are still some readers on the kernel list and we
can move the further discussion to that list. A fix should be
quite straightforward: 1. . .. \ are all no device names and
2. dhp-dh_attr should be tested for ATTR_CHAR before comparing
the IsDevice input to dhp-dh_name.
struct dhdr { struct dhdr FAR *dh_next; UWORD dh_attr;
VOID(*dh_strategy) (void); VOID(*dh_interrupt) (void); UBYTE dh_name[8]; };
By the way, init_device drops devices which either take no memory
(endaddr same as device header location) or are 0 drive block devices.
Eric
---
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] announce: devload 3.14
Hi, I have updated DEVLOAD: http://www.coli.uni-sb.de/~eric/stuff/soft/by-others/devload-3.14.zip This version now initializes the block device unit count in the device header. Most drivers do this themselves already, but as the DOS kernel has the feature of copying the value returned by the init call to the device header, DEVLOAD now has the same feature. Please test if your devices can still be loaded with the new DEVLOAD version (DEVLOAD allows you to load devices from the prompt which otherwise would be loaded with DEVICE= or DEVICEHIGH=, but note that UMB support is limited, memory drivers like HIMEM / EMM386 should not be loaded with DEVLOAD and that using DEVICE= is still the official way while DEVLOAD is just a convenient cheat to load drivers later). The update also features somewhat shorter / better-to-compress text strings, which makes the compressed binary DEVLOAD.COM a bit smaller. Note that the update is also a WORKAROUND for a bug in the current FreeDOS kernel IsDevice function: When walking the device chain, IsDevice must only check names for CHAR devices. For BLOCK devices, the 8 name bytes have the different meaning of 1 number-of-units (drive letters) byte followed by 7 OPTIONAL name bytes. Padding can be with spaces or 00 bytes. The flaw in devload made it possible to have all-zero names for block devices which in turn matched the zero size name of the \ and . / .. directories (for IsDevice, only the size up to but excluding the first dot counts). In other words, DEVLOADing a block device driver which did not initialize the unit count itself resulted in . .. and the root directory all being treated as char devices because of the bad IsDevice implementation in FreeDOS kernel. Eric --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] problems with OpenWatcom debugger + FreeCOM + Win98
Michael Devore wrote: WD is plain old goofy. It has had a slightly unstable reputation under DOS for over ten years. You could be seeing nothing more than the OS memory image having different byte values at a particular location(s), or slightly varied free memory values, or an internal operation delta which isn't part of the DOS documented interface. Or WD could be unhappy with the memory drivers. Check with and without HIMEM and EMM386 or try Microsoft versions of same under FreeDOS, see if it makes any difference. I think maybe you misunderstood what I said. I can't test with and without HIMEM and EMM386 because the problems with WD only occur when using FreeCOM (not FreeDOS, i.e. the kernel) on Win98. There are no problems when using any of the following combinations: - Microsoft COMMAND.COM on Win98 - Microsoft COMMAND.COM on MS-DOS (the version shipped with Win98) - FreeCOM on FreeDOS --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] problems with OpenWatcom debugger + FreeCOM + Win98
At 03:29 PM 7/9/2005 -0800, Brolin wrote: Michael Devore wrote: WD is plain old goofy. It has had a slightly unstable reputation under DOS for over ten years. You could be seeing nothing more than the OS memory image having different byte values at a particular location(s), or slightly varied free memory values, or an internal operation delta which isn't part of the DOS documented interface. Or WD could be unhappy with the memory drivers. Check with and without HIMEM and EMM386 or try Microsoft versions of same under FreeDOS, see if it makes any difference. I think maybe you misunderstood what I said. I can't test with and without HIMEM and EMM386 because the problems with WD only occur when using FreeCOM (not FreeDOS, i.e. the kernel) on Win98. I don't think it's an officially supported configuration and FreeCOM development and support seem moribund nowadays, so not sure you're going to have much luck. I would ask why you'd want to bother using FreeCOM under Win98, since it's a rather strange mix prone to a number of potential pitfalls, but it's not really any of my business so I won't. WD is still slightly goofy, though. --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] problems with OpenWatcom debugger + FreeCOM + Win98
Brolin schreef: I think maybe you misunderstood what I said. I can't test with and without HIMEM and EMM386 because the problems with WD only occur when using FreeCOM (not FreeDOS, i.e. the kernel) on Win98. There are no problems when using any of the following combinations: - Microsoft COMMAND.COM on Win98 - Microsoft COMMAND.COM on MS-DOS (the version shipped with Win98) - FreeCOM on FreeDOS Maybe loading FreeCOM permanently would work better. in CONFIG.SYS this would be a line SHELL=C:\FREEDOS\COMMAND.COM C:\FREEDOS\ /E:1024 /D /P remove the /D if you want autoexec.bat executed. no idea if this would be ANY help at all, but it's all I can suggest. You then won't be able to bootup win98, I'm afraid..no LFN/VFAT awareness in FreeCOM. Bernd --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] re: DEVLOAD / ramdisk troubles - or kernel problems?
On Sat, 9 Jul 2005 18:11:53 +0200 (MEST), you wrote: Hi Eric, Sorry for skipping all the text, your personal style a bit too long. As I know TDSK easily causing hang up or crash if the size is too large. So I've change to SRDISK, I've use this over 6 years, very stable. And I'm sure FreeDOS Kernel or FreeCOM have XMS access problem. I have a Chinese System which store fonts in XMS but never get to work properly, when I disable the XMS it can display correctly but since not enough memory (loading low), not enough memory for all characters. If you interested, I can send you a copy. Rgds, Johnson. --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
