Re: [Freedos-user] A few suggestions to improve debug
On 01/09/2020 04:16, Jon Brase wrote: it's also meant to be an alternative to MS-DOS for the very oldest PC hardware, all the way back to the original IBM 5150. The core software might therefore be expected to work in very little RAM. As I recall, the minimum configuration for the 5150 had only 16k of RAM. (...) So for FreeDOS to work on such machines, it has to (...) Sorry, but there is no chance that FreeDOS could possibly run on 16K RAM. It requires at least 10 times as much, only to load itself (kernel needs about 64K, command.com requires roughly another 64K, plus buffers and stack) - and more to run any application bigger than a COM-style hello world. Mateusz ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On Mon, Aug 31, 2020 at 09:16:54PM -0500, Jon Brase wrote: > Recall that FreeDOS isn't just about having a FOSS alternative to MS-DOS > for modern machines (where you're really better off just using Linux and > DOSBox), or for your early-90s 486 retrogaming machine, it's also meant > to be an alternative to MS-DOS for the very oldest PC hardware, all the > way back to the original IBM 5150. The core software might therefore be > expected to work in very little RAM. As I recall, the minimum configuration > for the 5150 had only 16k of RAM. Do you mean FreeDOS should be "alternative to PC-DOS V1.0"? And it should be kept in such (supposed) miserable state? I still have somewhere diskette with PC-DOS V2 - it wasn't interesting experience, compared to - say - DOS V3.34. No, I don't think FreeDOS should be "alternative to MS-DOS for the very oldest PC hardware, all the way back to the original IBM 5150". If it can be run on old XT with 256 KB RAM - then IMHO "it's compatible enough" -- regards, Zbigniew ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On Tue, Sep 1, 2020 at 1:35 AM Jon Brase wrote: > > > Not that convincing rationale considering rather modest overhead necessary. > > Recall that FreeDOS isn't just about having a FOSS alternative to MS-DOS for > modern machines (where you're really better off just using Linux and DOSBox), > or for your early-90s 486 retrogaming machine, it's also meant to be an > alternative to MS-DOS for the very oldest PC hardware, all the way back to > the original IBM 5150. The core software might therefore be expected to work > in very little RAM. As I recall, the minimum configuration for the 5150 had > only 16k of RAM. A decent laptop these days will have more 16k blocks of RAM > than a minimal 5150 had *bits* of RAM. So for FreeDOS to work on such > machines, it has to treat kilobytes like young whippersnappers like me treat > gigabytes. 500 or 800 bytes starts looking pretty expensive at that rate. And just who still *has* a working 5150 with 16KB RAM and doing what with it if they do? (For that matter, who is still running original ancient hardware that *hasn't* taken it to the full 640K of supported user memory?) The earliest 5150 model could take 64K on the motherboard, but later models increased that. (The 640KB limit for user accessible RAM was an IBM decision. The 8088 CPU has a 1MB address space.) The earliest versions of DOS looked a lot like CP/M under the hood, which is unsurprising. The previous range of machines the IBM PC was designed to replace were boxes from manufacturers like Osborne and used the Intel 8080 or Intel compatible Zilog Z80 and ran CP/M. Those earlier CPUs had a 64K address space (and some of the machines came with 48K of RAM.) A design goal for the earliest PC was to make it easy to port software originally developed on CP/M machines, like WordStar and VisiCalc, to the new architecture. While early PCs might have been released with as little as 64K of RAM, more was common. (A machine at a former employer had 256K.) Pretty much everything got extended to the full 640K main memory to accommodate RAM hungry applications. (Think Lotus 123, and larger and larger spreadsheets.) Complaints that changes like this make them harder to run on really old kit are only meaningful if someone is *trying* to. I think even the "pure DOS machines" folks here who *only* run DOS have machines with 640K, and possible expansion RAM in EMS or XMS flavors. __ Dennis ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
> I'm not sure, but probably a program can distinguish whether it's in > "interactive mode" or used for batch processing? It seems like this should be > possible, but I don't think it is. I've tried doing something similar > (though not quite the same), where I tried to automatically detect whether my > program was being run from the command-line or being "called" (via the DOS > EXEC function) from another program. I could never figure out a way to > automatically detect this. The closest I could come was figuring out the > name of the "parent" program and compare it to a list of known command-line > interpreters (from MS, FreeDOS, 4DOS, etc.). I abandoned the idea since it > was pretty unreliable. If there are some keystrokes you ALWAYS want to "type" > at the beginning of a particular program, you should start the program with a > batch file and use a "keyboard stuffing" utility (there are several of those > available, including my SCANCODE program). However, you should be able to > tell whether your input is coming from the keyboard or being redirected from > a file (which I believe is what is being meant by "batch processing"). With > some of my programs, I do something similar with the output. These programs > have an "automatic pause" feature that stops when the screen gets full > (similar to piping the output of the program to MORE). However, if the > program detects that the output has been redirected to something other than > STDOUT (the screen), the auto-pause is disabled so the entire output is > redirected with no pauses. Sponsored by https://www.newser.com/?utm_source=part&utm_medium=uol&utm_campaign=rss_taglines_more Suit: McDonald's 'Intentionally' Hurt Black Franchisees http://thirdpartyoffers.juno.com/TGL3141/5f4e725a866b9725a7d46st04vuc1 Cheater's NYT Wedding Story Gave Away a Little Too Much http://thirdpartyoffers.juno.com/TGL3141/5f4e725aa9c70725a7d46st04vuc2 Trump Mentions Plane Filled With 'Thugs' in Dark Uniforms http://thirdpartyoffers.juno.com/TGL3141/5f4e725acdaf4725a7d46st04vuc3___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On 8/31/2020 7:16 PM, Jon Brase wrote: > Not that convincing rationale considering rather modest overhead necessary. Recall that FreeDOS isn't just about having a FOSS alternative to MS-DOS for modern machines (where you're really better off just using Linux and DOSBox), or for your early-90s 486 retrogaming machine, it's also meant to be an alternative to MS-DOS for the very oldest PC hardware, all the way back to the original IBM 5150. The core software might therefore be expected to work in very little RAM. As I recall, the minimum configuration for the 5150 had only 16k of RAM. Well, yes and no. On a bare minimum PC with only 16KB of RAM, even PC-DOS 1.0 would not run, as this was just for the absolute minimum 14KB IIRC, DOS 2.0 was something in the order of 30KB already. So to run any PC with "DOS", you needed a machine with at least 64KB of RAM, or you could just work with the ROM BASIC... But in general, a lot of those simple command line tools, that in fact have a command line "line" input (right out of my head, I can only think of EDLIN and DEBUG), should be able to work in minimalistic environments. And as there aren't many tools where ZB's idea would make sense in his opinion, it seems a bit like brewing up a tempest in a teacup... ;-) And another reason why this might not be in general a good idea is if we take compatibility with old(er) DOS software/environments serious, one might want to consider that DOS (in its basic form) was able to run on non-memory mapped devices, like serial terminals, which might limit your ability to move the cursor quite a bit. Yes, a bit of a stretch nowadays, but something to keep in mind... :-P Ralf -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
