I was writing a mechanical simulation with graphics this weekend & flailed a bit getting around WinXP's support of VGA graphics under Microsoft QuickBasic 4.0 (circa 1987, I think). (*Great* product)
Anyway, John Larkin's raved about PowerBasic--it does all that graphics / menu / GUI jazz--under Windows 95-through-Win7, makes tight code, it's anti-bloatware, and the old version (Classic PowerBasic 8.0 for Windows) is on sale for $49 (for the next few days).
I'm not a fan of the PB-Win thing, because I don't like Windows programming... the user interface crud dominates the application code. The Console Compiler is a lot easier to drive. It does all sorts of cool stuff like TCP/IP.
If you want a starting point for some PB-Console Compiler graphics stuff, I can furnish the source code for this:
ftp://jjlarkin.lmi.net/GR8.jpg
Its functionality is obscure (it simulates a vector heads-up display for a C130) but it does most of the tricky graphics stuff.
I really liked QB and the PDS ("professional") version. Great stuff in its day. But it wasn't a true compiler so was slow. You can do useful FOR loops at 30 MHz in PowerBasic. One of my guys coded a 64 M point signal averaging thing in C, and I was surprised how slow it ran, almost a second. I whipped up the dumbest possible PBCC version, klutzy FOR loop with subscripts, and it ran in under 0.25 seconds. He want back and played with his code and compiler settings and eventually got close.
Something like that. They're switching the Win compiler from version
8 to version 9, so version 8's on sale.
Version 8's plenty good enough for me--heck I'm still using MS QuickBasic, and like it. But this'll let me use graphics under WinXX with the confidence my programs won't crash other people's computers.
I'm totally /not/ into all that Monkeysoft gooey stuff -- they change it too often, and I can't be bothered keeping up with their hamster wheel. By providing its own interface PB might fix that. (I'll learn an interface, if it's worth it.)
Anyway, this PB Win 8.0 is just for my personal engineering hacks...I've written a couple circuit simulators, mechanical design gizmos, data processing stuff, and what-nots.
Sounds like the Console version is more my style--it also supports graphics, which I hadn't noticed--but it isn't the one that was on sale!
So, I'll try this one and see how it goes. I haven't been writing all that much.
Nice display, and sure, I'd love some of your handiwork. You won't mind if I lowercase it, will you?
My weekend program was a lark, a feasibility-thing--it did a rough-cut design of an improved rollernut configuration that came to me. The program takes the design parameters, roughs the component dimensions, then draws the assembled parts & overlaps, to scale, so you can check for interferences.
I was really tempted to do a 3-D wireframe animation and computer- generate all the machining info--it wouldn't take that long--but that's way overkill. If / when it comes to it I'll probably just pencil it up and cut a proto on the lathe. Right now I'm just evaluating design options, blah blah blah, and wanted to see if this idea would work. It does. Animation sure would be fun though.
QB does true compilation if you ask it to, can output a .ASM source file, and even lets you cobble in assembly code (in 8086!). I did that for faster graphics and FFTs, back in the day.
The compiled code isn't great--lots of subroutine calls and stacked parameters to do even the simplest things, like add two integers--but it's more convenient than programming in Intel assembly (which I've done more than my share of).
That's good stuff. I hope the Win version lets me do that basic hard work without a bunch of gooey clutter.
I'll email you the source of the heads-up thing, and whatever else looks useful.
I didn't much like the PB-Win thing because it was too much work to do simple user interfaces. I did use PB-Forms, which is a Visual-Basic sort of thing... you drag-drop design a Windows screen with all the buttons and boxes and gadgets, and it generates the PB-Win source code for the skeleton application. Then you have to get at all the variables and do the real application. I thought the resulting code was clumsy and ugly. The old LOCATE...INPUT...PRINT...COLOR paradigm, in PBCC, suits me better for hacking engineering apps.
Hmm, possible "yuck." I bought several versions of Visual Basic, but I never used them--too messy.
I'm more willing to try with PB. It compiles better object code, is generally tighter, and more worth the trouble. But I won't be programming lots of WinGUI cr$p -- not unless absolutely necessary.
If the GUI stuff gets in the way, I'll use something else.
Me too. I want results, not menus.
Perfectly reasonable. Hopefully the Win version's reasonable too.
I have PDS and it will compile to binary code (if you do not compile, it runs p-code). If you want either p-code or compiled code to run faster, use integers as much as possible. A bunch of code fiddling inside a integer FOR..Next loop will compile to ASM code that cannot be hand optimised any better - as long as that fiddling is not TOO complicated. Even array access is ASM tight. Now it ain't too hot in making a loop inside a loop efficient, but slight tweaking of the ASM can fix that.
I thought it compiled to p-code. May be wrong about that. Maybe that was Qbasic. But the DOS version of PowerBasic was 3x to 10x faster than PDS, running on the same machine.
QB's pretty fast, especially for the programmer. It's really a joy. It gives instant feedback in interactive mode, interpreting P-code, yet will compile down to machine code if you want.
And, an old compiler flies on a more modern machine. That's my secret sauce. The QB compiler I use from 1987--made to run on an 4.77MHz
8088 with two 360k floppies--absolutely screams on the '486-66 I run it on. An LED modulation experiment managed 30KHz pwm loops to the parallel port in P-code.
...was going to compile it for speed, but never had to.
You bet. As John indicates, this is their "VisualBasic". The Console version's probably my fave option--that's more my style--but for $49 I'm more than willing to take a chance on this version.
I still own and use several different incarnations of GW-BASIC and QB, including QB v4.0, v4.5 (this last one is roughly what QBASIC is, without the ability to compile) and PDS 6.0, 7.0 and 7.1, and finally VBDOS 1.0.
I also have snarfed a copy of the complete source code in asm for QB v4.5, laying about somewhere.
Most of these do compile and generate what amounts to assembly code. Their assembly listing capability had a lot to be desired, though.
I don't have any doubt that PB is faster than PDS, but I'd be interested in comparing some code generation just for the fun of it. If you (or someone) is interested in trying that.
There is a nifty feature in VBDOS, which is the ability to create DOS programs which support text-based Windows, with file drop down boxes, text boxes, and a host of other familiar Windows widgets -- with event call-backs and very very easy to use coding for them. The advantage here is that VBDOS programs work on DOS-only systems, such as the PC/104 units often are set up to run with ancient CGA, EGA, and VGA operating mode boards in them. The output does not require
32-bit or protected-mode drivers to run.
I still have use for the boxed sets of DOS I keep on the shelf, full retail distributions, picked up for $5 each some time ago. And PDS both compiles fine on such systems as well as generating code that also runs fine on them.
Jon
P.S. For QBASIC, which does not compile, I also wrote (and if you want it, I've no problem passing it on) some short QBASIC programs that allow you to write assembly code to interface with it -- they will invoke the assembler, generate object code, generate DATA statements automatically, and set up routines that will load the data and execute it as a subroutine. So even when compilation isn't available, it was possible to still link with your own assembly code.
OK; the way QBX and PDS (and almost all older versions of BASIC) is that each line as it is entered (or modified) is parsed and converted to p-code. When the program is run, it is the pcode that is interpreted by the program in the background. If all was integer, i do not think a substantial difference in speed would be seen between QBX and PowerBasic. If that code was compiled in both cases, there should be no speed difference; QBX compiles to ASM that cannot be refined for greater speed (i have seen this) assuming only one loop and not loop inside a loop. Now for code using floating point - that is where the men will be separated from the boys (so to speak). QBX / PDS uses what seems to me clunky calls to a library for each and every FP action and the library routines (at least the few i looked at) are not exactly optimum (but then again, i am not a programmer - i just do a bit of programming on occasion). Perhaps PowerBasic uses a more efficient call (which can save at least 50 percent of the time WRT QB), and maybe even the library routines are more efficient (i will make a crude guesstimate) by a factor of 20% more or less. Even at 10%, for 10 calls on a given line, the time savings add up and can be astounding (have seen this when improving Fourier transform routines).
Yeah, I traced a simple operation once, might've been division. It had something like 20 floating point operations, spread through nearly as many subroutines. I don't even know what it was checking -- QB always checks bounds of course, but sheesh, even with that, I just wanted a divide, I wasn't expecting the Spanish Inquisition (...).
Tim
--
Deep Friar: a very philosophical monk.
Website: http://webpages.charter.net/dawill/tmoranwms
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.