Hi, On Wed, Aug 3, 2011 at 10:48 PM, Ralf A. Quint <[email protected]> wrote: > At 01:59 PM 8/3/2011, Rugxulo wrote: >> >>Hence I had to basically tweak my own makefile *and* spend a long time >>trying to pretend I understand all the 16-bit memory models >>(confusing!). >> >>Anyways, the main problem was actually that somebody (Paul Edwards??) >>changed MAXSTRINGLEN to 4000 instead of (old 2.20's) 255, which easily >>overflowed something somewhere (again, confusing!). So by switching >>back to 255, it at least compiles and works again in 16-bit. :-)) > > That's exactly what I was referring to when I mentioned in a previous > reply that nobody these days knows a thing about DOS anymore... :-(
In fairness, this is my fault (or maybe you meant them too? Clearly they didn't target DOS with the makefile, at least not 16-bit). I'm not hugely familiar with C nor with the various memory models nor what is best for when, workarounds, etc. It was just a quick attempt to compile (more or less). I wanted to at least match the functionality of the "old" 2.20 16-bit compile Jim made for FD 1.0. In my defense, I maybe? should've just taken the easy way out and used DJGPP (which is 20+ years old, and that's as DOS as it gets, almost ...). But I didn't see a huge need or advantage. And BTW, "portable" C is really hard to find, esp. these days when "All the world's a VAX!" [32-bit / 64-bit Linux or Windows]. >> >> > Don't know what AWK has to do with either BWBASIC, EXE2BIN or DEBUG, >> >> > but awk is certainly not DOS and therefor should IMHO not be included >> >> > in any "base" package... >> >>I'm still of the opinion that "something" should be included by >>default. Debug is better than nothing, but not much (by itself) .... >>That will probably have to wait until after FD 1.1 is out (2.0 ??). > > I still don't see how those tools are related (to awk or to each > other). Each one is a tool in it's own right and for it's own purpose... FreeDOS "BASE" is strictly mimicking MS-DOS core stuff they included. But it lacks DOSSHELL or QBASIC, at least in "BASE". So, for average scripting, while *nix has sh and awk, all we have is Debug! We don't even have BWBASIC to fully rely upon. That was my point, we're at a small disadvantage since we can't assume everyone has BWBASIC installed (whereas QBASIC was common enough to be occasionally utilized in Timo Salmi's .BAT FAQ). This was all related to my commentary on that, nothing more. >> > a GW-BASIC clone, looks like there won't be much interest for >> this at least in here. >> >>Not true! > > Maybe I need to dig out some email from this list from a backup tape > from a years back... Why? If you want to write it, write it! :-) >>And BTW, I just read about this recently (since having never >>seen it first-hand): >> >>http://en.wikipedia.org/wiki/Donkey.bas >>http://www.youtube.com/watch?v=kymzTlqi1SY&feature=related >> >>Notice the (co)author! ;-) > > And? Ok, big deal if you buy into the blabber from yapper mouth Jobs, > who himself has yet to write a single line of code to begin with. > He and Apple wouldn't gotten even off the ground if he would not have > take advantage of the genius of Woz... I just meant, "Look, even Gates wrote some real BASIC for public consumption", so it has some historic value to some people, if not (also) technical or nostalgic. > But then DONKEY.BAS was never meant to be an epitome of BASIC > graphics programming (which as far as the original IBM PC was > concerned was limited to 320x200 pixel in 4 (fixed)colors (black, > white, purple, cyan) on a CGA... No, of course not, but it's far from embarrassing. I'm sure we've all seen and written worse. It's just a (semi-) famous example that I thought was interesting, esp. since the IBM PC turns 30 next week (Aug. 12). >> > I got a bit stuck at implementing routines for the floating point >> math in MBF >> > (which is what BASICA/GW-BASIC and the early MS BASIC compiler use). >> > I have some old routines for most of the single precision stuff but doing >> > double precision with only 16bit registers at hand is a bit tough. > > I was thinking at times about taking a shortcut, doing the actual > math using IEEE 754 of the C compiler's library and just convert from > and to the MBF. But that would result in a loss of precision (MBF has > one or two bits more in the mantissa but a smaller exponent/range > than a IEEE 8 byte float) and that would create a possible > compatibility issue... BWBASIC just uses doubles for everything, I think. I'm not sure much code really relies on MBF, so I wouldn't let it hold you up, IMO. But hey, knock yourself out. ;-) >>It can't be *that* impossible. Still, I'm not sure I'd be able to help >>much. (What language are you writing in? Assembly? C?) > > A mix of C and assembler. I am/was aiming for "working like" more > than for creating a "binary copy", so most interpreter logic and > line/screen editor function is in C, most "runtime library" stuff > would be linked-in assembler. I also started to maintain an a memory > array which holds all those known PEEK and POKE addresses that where > widely used, which isn't without a challenge either in terms of > staying compatible.. Okay, I wasn't sure if you were writing it all in pure ASM or not! >> > And without MBF (Microsoft Binary Format), it can't work like GWBASIC. >> >>I recently read that there are routines out there that can convert >>this (oddball) format. One text online said check Borland's FTP (!), >>which of course is long gone, but that means it's probably mirrored >>somewhere and well-documented. I'm sure somebody on FreeBASIC's forum >>would know more. > > Conversions routine are around plenty, but not actually doing math in > that format. And the reference to Borland probably referred to > conversion of a different, Borland specific format. > As mentioned before, there are differences/loss in the precision to > the standard which is used nowadays and didn't exist when the > different Microsoft BASIC interpreters and compilers where created. Did even QBASIC support MBF? I haven't used it but barely recently, but I seem to remember that even it lacked some (minor?) compatibility to GW-BASIC. > Most float capable programming languages had their own float formats > back in the early days, which at least for anything above 4 byte > floats (single precision) where not compatible with each other. Like > Turbo Pascal 1.0-3.0's 6 byte Real format for example, Right, but even GPC can convert to/from that. However, I don't see a huge need unless you had lots of external data files with that format. Of course, FPUs were slow and expensive back in the day, whereas every Pentium 1 cpu on up has had one (except some embedded chips). So they probably just took the easy / fast way out by "inventing" their own (limited?) format. I'm not sure even "standard" Pascal had any specific range for floating point values. (Note that because FPUs are everywhere nowadays, there is less incentive for people like FBC to cater to older cpus, e.g. their runtime always assumes an FPU, sadly. I had to patch it for DOS386's FBMD5 just so it wouldn't need a "bloaty" emulator lib, heh.) > or those from DR's CBASIC. Or such main staples of early computing > like Commodore's C64/VC-20, CBM's or Trash-80s and clones, Sinclair's, > BBC, etc... That requires quite a bit of reverse-engineering and testing to > say > the least... Good luck! I just can't imagine it would be that hard (or crucial), but what do I know? ;-) To be honest, FBC gets a lot of praise for being QB compatible, but it's really not. It could still use some cleanups regarding that syntax. But I guess so far it's "good enough" for most people (or maybe not a priority). Annoying when you find old code that you can't rebuild. :-/ ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
