[Freedos-user] Re: Re: Writing Utilities for FreeDOS
Hi Imre! SCANDISK - this should be implemented as an user interface to DOSFSCK Yes, for this you should strip down dosfsck (throw out delayed writing and I disagree: Delayed writing is perfectly useful because you can use the code to create an UNDO LOG before actually changing the disk, very similar to the MS SCANDISK feature of creating an undo floppy. the undelete feature). Then you should make it compile with turbo c++ [Imre suggests a 16bit version...] Disagree again: DOSFSCK can check FAT32 and uses lots of memory. There is no real need for an 8086 compatible SCANDISK, and a 15 year old 386 already has enough features to run a DJGPP/386 SCANDISK. After you can get this to run you could change all the input/output from the user to show up in dialogs, this should not be to difficult (might be a lot of work though?). Yes, that is mainly what creating SCANDISK from DOSFSCK would mean. I think code from Joes user interface for the old proof of concept SCANDISK can be re-used for this. Eric --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re: Printer Problems
Eric, Just wanted to update you. I downloaded the lastest version of FreeDOS but haven't had a chance to do much testing, but a quick test seemed to be successful, the printer was operational! I hope to test more thoroughly today. I'll let you know what happens. Matt -- original message - From: Eric Auer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Freedos-user] Re: Printer Problems Date: Thu, 22 Apr 2004 17:24:05 +0200 (MEST) Hi all, I contacted Matt and he wrote that he is using a very old FreeDOS which came with SuSE Linux 8.1 ... as far as I remember, even SuSE Linux 9.0 had quite old DOSEMU and FreeDOS versions included. Does somebody know about SuSE Linux 9.1? If not, we should probably remind people at SuSE to do an update...? Whatever. So his problem: During boot, BIOS leaves the printer port in some init state which freezes the printer. MS DOS kernel resets the printer port control lines to normal state during boot, it seems, and the old FreeDOS which Matt used fails to do that. I do not know if an update has helped, did not receive news about test results after an update to 2034 / 0.82pl3 from him yet. In the FAQ, there is a complaint about FreeDOS not initializing serial port modem control lines. Similar problem. MS MODE of Win9x seems to initialize those lines and therefore solves the problem of that FAQ reporter. Question: Does FreeDOS 2034 initialize COM/LPT ports? If not, are there any arguments against adding this feature? Should I add initialization features to MODE (either implicit in MODE port configuration commands or explicit: MODE COM1 INIT or MODE COM1 DTR=TRUE RTS=FALSE or something, see int 14.05) ...? Eric --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re: Printer Problems
Eric, The latest version of freedos fixed the problem! I downloaded odin07bin.zip, created a floopy from the image file, added my terminal emulation to it and everything seems to be working fine. The printer port seems to initialize during boot. Thank you very much for yoyur assistance! Matt -- Original Message -- From: Matt Stamm [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Fri, 23 Apr 2004 10:30:51 -0400 Eric, Just wanted to update you. I downloaded the lastest version of FreeDOS but haven't had a chance to do much testing, but a quick test seemed to be successful, the printer was operational! I hope to test more thoroughly today. I'll let you know what happens. Matt -- original message - From: Eric Auer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Freedos-user] Re: Printer Problems Date: Thu, 22 Apr 2004 17:24:05 +0200 (MEST) Hi all, I contacted Matt and he wrote that he is using a very old FreeDOS which came with SuSE Linux 8.1 ... as far as I remember, even SuSE Linux 9.0 had quite old DOSEMU and FreeDOS versions included. Does somebody know about SuSE Linux 9.1? If not, we should probably remind people at SuSE to do an update...? Whatever. So his problem: During boot, BIOS leaves the printer port in some init state which freezes the printer. MS DOS kernel resets the printer port control lines to normal state during boot, it seems, and the old FreeDOS which Matt used fails to do that. I do not know if an update has helped, did not receive news about test results after an update to 2034 / 0.82pl3 from him yet. In the FAQ, there is a complaint about FreeDOS not initializing serial port modem control lines. Similar problem. MS MODE of Win9x seems to initialize those lines and therefore solves the problem of that FAQ reporter. Question: Does FreeDOS 2034 initialize COM/LPT ports? If not, are there any arguments against adding this feature? Should I add initialization features to MODE (either implicit in MODE port configuration commands or explicit: MODE COM1 INIT or MODE COM1 DTR=TRUE RTS=FALSE or something, see int 14.05) ...? Eric --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] fdisk question..
I just downloaded fdbootcd.iso for freedos. What is the incantation of fdisk to overwrite MBR with default mbr? X fdisk c:/mbr does not do the trick :-( Thanks, -ishwar --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Writing Utilities for FreeDOS
Jay Maus schreef: This whole File Search Utility thread has gotten me thinking about DOS programming. I program mainly in either Win32 C++ for apps or Perl for scripts. However, I've played around with DOS C programming from time to time, and would like some 'real-world exercises', so to speak. So, is there a list of FreeDOS Utilities that need tweaking, or utilities that just don't exist? Whether they be MS-alikes, GNU-alikes, or something completely different? Jay, if you find it interesting I'd like to request for a utility which scans a dump of the bootsector for filenames and checks if they exist. The dump (a file on disk, exact duplicate of the bootsector) is 512 bytes long. you can generate an artificial one using the following command when using FreeDOS SYS (in the KERNEL 2034 package): SYS A: A: C:\BOOTSECT.BIN BOOTONLY which creates a bootsector intended for disk A:, but instead of writing it to disk A:, writes it to file C:\BOOTSECT.BIN there are also some Bootsector-dumping utilities like SAVEBS-A (from www.auersoft.org), and COPYBS (from syslinux.zytor.org) which could then be applied to a Win98 bootdisk from www.bootdisk.com for example. the challenge lies in analyzing what exactly a valid filename is. (minimum and maximum length, valid characters, valid sequence of characters, etc) a freedos bootsector for example refers to KERNEL__SYS and thus file KERNEL.SYS must exist on disk ( _ are spaces, unused). for Win98 bootsectors it might be more difficult, as they might not use all space (IOSYS instead of IO__SYS). another challenge might be to check 4KB blocks of upper memory if they can be used for EMM386, just like UMBPCI (specifically: the UMBCHK program) does. current EMM386 sticks to 16KB blocks, current UMBCHK also, UMBPCI can use 4KB blocks, but I'd like to find out which 4KB blocks :) I myself stick with batchfile programming. Results of that are in the FreeDOS distribution. Bernd --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Writing Utilities for FreeDOS
At 04:50 AM 4/24/2004 +0200, Bernd Blaauw wrote: smallest allowable blocksize seems to be 4KB, so I'd like a utility which can check each 4KB. UMBPCI can do this right now (and even use it), UMBCHK cannot (16KB only), Emm386 I'm not sure if it can check in 4KB blocks, but it can use no smaller than 16KB blocks. fine by me, but still I'd like to know which blocks are usable in theory. UMB-list would be a collection of 4KB blocks, and each 4 blocks that directly follow eachother can be a UMB for EMM386. DOS can deal with blocks down to 16 bytes, so you could probably run UMB size down that low, although the overhead there wouldn't be worth it. But 1K (or less) is feasible. It's a matter of how hard you want to squeeze memory and how much risk you're willing to accept in BIOS conflicts for the amount you're squeezing. 16K is a good risk balance. Is 4K? If 4K, why not 1K? The EMS page frame does require a 16K-aligned boundary (C000, C400..E000), and is typically 64K-aligned, but that's not a consideration for gathering small UMB blocks outside of the page frame. --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Writing Utilities for FreeDOS
Michael Devore schreef: DOS can deal with blocks down to 16 bytes, so you could probably run UMB size down that low, although the overhead there wouldn't be worth it. But 1K (or less) is feasible. It's a matter of how hard you want to squeeze memory and how much risk you're willing to accept in BIOS conflicts for the amount you're squeezing. 16K is a good risk balance. Is 4K? If 4K, why not 1K? whichever is easiest :) So you're saying collect all 1KB blocks, then turn into 16KB blocks in most optimal way? Bernd --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Writing Utilities for FreeDOS
At 05:26 AM 4/24/2004 +0200, Bernd Blaauw wrote: Michael Devore schreef: DOS can deal with blocks down to 16 bytes, so you could probably run UMB size down that low, although the overhead there wouldn't be worth it. But 1K (or less) is feasible. It's a matter of how hard you want to squeeze memory and how much risk you're willing to accept in BIOS conflicts for the amount you're squeezing. 16K is a good risk balance. Is 4K? If 4K, why not 1K? whichever is easiest :) So you're saying collect all 1KB blocks, then turn into 16KB blocks in most optimal way? No, you natively support 1K blocks. No need to turn them into anything, although contiguous blocks coalesce, as they do now with 16K blocks up to 160K+ blocks. 4K is the easiest 16K size since it is the smallest unit that doesn't require copying a ROM image block for partial shadowing, but with extra work you could support down to ridiculously small amounts. --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
