🚀 go-pugleaf

In <1992Sep1.052408.12646@julian.uwo.ca> wlsmith@valve.heart.rri.uwo.ca (Wayne Smith) writes:

>I have VB (version 1 I guess, it doesn't say on the box) and I don't
>like 
>a) won't do peeks/pokes/in's/out's
>b) can't do a CALL ABSOLUTE

I've never *personally* found a need for that stuff myself but I can see
why they didn't included that stuff in VB/Windows. Someone could go about
indiscriminately poking/peeking in/out-ing and possibly crash Windows
without realizing it. Not good for Microsoft's image of Windows being 
the perfect (sic) OS. [Shell, dammit, shell. :)]

>(I do heavy duty data aquisition from custom hardware, and use debug
>to write high speed aquisition/storage routines.  I then use bload
>and bsave to move the routines into 'unused' memory areas (&h6000 to
>&h9000), where they can be called from QB.  I use peek's and poke's to
>set/alter the routines and to retrieve collected data.  Hey, it's fast,
>painless, it works, no assembler to mess with, etc).

And, I'm sure, takes a helluva lot of patience. :) I'm pretty handy
with assembler code and couldn't see writing anything more than a
"hello, world" program with debug. [Fwiw, I consider debug to be
just one minor step up from cp/m-80's ddt.com]

>If there are no mouse functions in VB/DOS then it's a crock
>(ie, let's say you've got a bit-map and you want to do image
>analysis, so you want to display the coordinates of the mouse on the 
>screen regardless of wheather or not you click any buttons).
>like can you do this: x = MOUSEX : y = MOUSEY  ???

I don't know if it has that or not. I sure would like to see that
kind of thing though. What I'd really like to see, though, is direct
DOS calls for the rodent rather than the 0x33 Interrupt (mouse driver).
Your thought of x=MOUSEX:y=MOUSEY just gave me an idea. :)

>I've got a cheap ($70) 1 meg Trident based card that I can set to
>132 X 66 (jeeze what small letters!), but when I go
>qb /h, it goes into 80 x 50 (why can't it stay in 132 x 66?)

Considering that QB is at least four years old, I suspect we're very
lucky that we get 80x50 support. I'm sure there's a program out there
that can "lock" the video mode to whatever you like. Only problem is in
finding (and distributing! :) it. :)

>>>- support for in-line machine language code? (Wow, that would be cool)
>>Uh, I dunno if I like that idea. Much prefer external asm routines.
>I'd rather not mess with external libraries and junk.

I couldn't live without my external libraries. But then I'm not into
the environment mode of QB anyway. (I have PDS but the idea is the same)
Adding inline asm might be ok *if* they leave it as an option rather
than a requirement. (i.e. if the user wants to use external asm functions
they can or they can use the internal/inline asm)

>If I wanted to do that, I'd also slide down the sharp end of a razor
>blade on my balls, or learn C.

Learning C is fine. I make my living working in C++ but, at home, use
a combo of BASIC and ASM (Microsoft all the way! :)

Jeff

-- 
Jeffery Foy -- Either: jfoy@glia.biostr.washington.edu -or-
                       foysys!jeffery@cs.washington.edu
             *** FREE BILL & KATHY SWAN ***
-*- Happy as a clam to be using Professional YAM -*-  :)