At 01:59 PM 8/3/2011, Rugxulo wrote: >Hi, > >On Tue, Jul 26, 2011 at 11:36 PM, Ralf A. Quint <[email protected]> wrote: > > At 08:10 PM 7/26/2011, Steve Nickolas wrote: > >>On Tue, 26 Jul 2011, Ralf A. Quint wrote: > >> > >> > I would not call BWBASIC "weak" but including it would give users a > >> > "basic" scripting tool which goes beyond the DOS batch scripting. > >I've gone ahead and compiled BWBASIC 2.50 for FreeDOS. It's not in >"preferred" .ZIP layout / format, but I'm honestly not sure who (if >any) would care. (If needed, I can reorganize it. I'm not sure if >anybody wants to mirror this, though. And yes, it includes full >sources, binary, and my patch.) > >https://sites.google.com/site/rugxulo/bwbas250.zip?attredirects=0&d=1 > >I didn't heavily test it, but it does seem to work. It does come with >an OpenWatcom makefile, but it's for 386+ only (and apparently only >Windows console). I couldn't decide a decent 32-bit solution (DOS/32A? >Win32 w/ optional WDOSX STUBIT later if needed? Win32 only assuming >HX?) for us, so I didn't include that. Obviously the main goal (for >me) was to get 16-bit working (again). > >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!). There's probably a "better" way, but I'm no Japheth, so >I'd have to dig in to see how he did JWasmR to really know. (I don't >know what limitations are inherently present there. I've not done a >lot of work with DOS memory models in C.) > >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... :-( > >> > 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... > >> > Seeing that there is so little "respect" for the old tools that made > >> > out DOS, I am not sure if I should pick up one of my projects I had > >> > started a few years back, > >Anything is welcome, but some tools are more generic and useful than others. > > > 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... >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... 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... > > 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... >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.. > > 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. 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, 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... Ralf ------------------------------------------------------------------------------ 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
