The Basix
Fanzine
issue 11 ·
july 1998
email: basix@dewarr.globalnet.co.uk
www: http://come.to/basixfanzine
Welcome to the first HTML version of the Basix Fanzine!
The switch to HTML means the Basix Fanzine is now able to offer you a more sophisticated, easier-to-use and nicer-looking fanzine than ever before!
So, what's in your new, brighter, more colourful fanzine in this issue? Here's the rundown: Get the info on the new PB/CC from PowerBasic Inc.... read how to do long filenames in your programs.... find out about your copyright rights.... find out why most online tutorials suck in Rude John's new regular editorial column.... read PCX files.... use the modem.... speed up input and output.... and more besides. Enjoy!
Levels are represented in bold by B, I or A for Beginner, Intermediate and Advanced respectively, or a combination. They aren't clear-cut definitions though, so you might find something useful labelled (B) even though you've been programming for 10 years, for example. Unless otherwise stated, the articles apply to all major breeds of BASIC.
Note that Internet Resources now has its own page - click here
Most of these links point to parts of this HTML document, although some may point to other HTML files in the Basix Fanzine directory. Each article has a link back to this contents section to save you the bother of scrolling back.
- NEW! Rude John's editorial: WHY (MOST) ON-LINE PROGRAMMING TUTORIALS SUCK!
- LONG FILENAMES FROM DOS by Alex Warren (I/A) (not QBasic)
- GRAPHICS IN QBASIC TUTORIAL (PART 2) by "Hacker" aka Damian Nikodem (I)
- TESTING MATRIX SOFTWARE, by Rude John (A)
- HIT-OR-MISS INTEGRATION, by Rude John (A)
- YOUR PROGRAMS - YOUR RIGHTS, by Alex Warren
Do you have a good BASIC website? Or have you seen one recently? If so, why not nominate the site for an award?
To nominate a site for an award, just send an email to basixawards98@dewarr.globalnet.co.uk and include the name of the site and the URL. If you want to suggest a category the site could go in, include that as well.
Alternatively, you could fill in the form at http://www.users.globalnet.co.uk/~dewarr/basix-awards98.htm
The deadline for nominations has been moved back again (in the original Usenet post I wrote about this, I suggested the end of May 1998 I think, and recieved about five nominations) to the end of September 1998.
After the deadline, I will post a complete list of nominations the the BASIC newsgroups and also include the list in the issue of the Basix Fanzine which will be released after that date. Votes will be taken in and the winning site will recieve a prominent position on the Internet Resources page, much publicity in the Basix Fanzine, a lovely-looking GIF file to display on the site, and much praise and other nice-ness.
Good luck!
Nominations accepted for all non-commercial DOS BASIC-oriented websites. The editor reserves the right to disallow a nomination, for example if adult content appears on a nominated site.
[ Back to Contents ]
POWERBASIC CONSOLE COMPILER FOR WINDOWS
In a recent newsgroup post Dave Navarro hollered the following (slightly edited for size, as tragically, I'm not paid for this kind of thing):
"Ever wished for a 32-bit BASIC compiler? One with the straightforward DOS interface but megabytes and megabytes of memory? Ever wished for a 32-bit Windows compiler that's truly easy to use? Well, now it's here. Today. The PowerBASIC Console Compiler for Windows. With PB/CC, it's a whole new Windows! Text mode for Win95, Win98, and WinNT!
The Console is a text mode interface connected right to the heart of 32-bit Windows. With a console application, there's no fluff, no animated puppets, just intense computing power. Port existing Basic code from DOS to Windows today! Access a flat memory model that's practically unlimited. Boost performance with true 32-bit code...
PB/CC supports PRINT, LOCATE, LINE INPUT, INKEY$, INSTAT, CLS, COLOR, and LPRINT... then we added more. CURSOR, INSHIFT, PAGE, PCOPY, WAITKEY$ and WAITSTAT... mouse handling routines... All the text tools you'll ever need...
PB/CC's high degree of compatibility with PowerBASIC, QuickBasic, GW-BASIC and BASICA means that you can port existing DOS applications to Win32 with ease... creating an array that uses 50 megabytes of RAM is as simple as:
DIM x%(0 to 26214400)
Create CGI applications for your web server... Get complete executables as small as 10K! With no run-time requirements of any kind...
Access to the Win32 API, or any 32-bit DLL, is a breeze! Including ODBC, Winsock, and the Internet controls. There's an inline assembler, support for threads...
PB/CC Features:
System Requirements
Personal computer with a 386
or higher processor
Windows 95/98 or Windows NT 3.51 or later
2 MB of available memory
One 3.5" high-density disk drive
A hard disk with 3.0 MB available for installation"
Dave Navarro replied to a later post from Ernie Deel that:
"PB/CC is much more than "PB/DLL plus console support". I'm saddened that you have no faith. The console compiler is the start of a new "genre" of compilers.
...Wouldn't you like to write your program on a single platform and simply re-compile it for other platforms? Without having to spend hours (or days or months or years) converting between API calls, calling conventions, etc...
With the console compiler, we provide a BASIC language which will work on all platforms supported in the future. PRINT, LOCATE, COLOR, CLS, LPRINT, etc. can be supported on all platforms and we will do all of the low-level work so that you can concentrate on just writing code.
Of course, if you *WANT* to take advantage of platform specific features (such as linking to DLLs in Windows) we don't prevent you from doing that. It's your choice.
Certainly with PB/DLL you can never write code which will work on Linux, DOS, or other platforms because the API/OS calls won't be the same on each platform...
As for PB/DLL itself, we're certainly not done with that. We've been collecting suggestions from thousands of users and together with some of our own ideas, we'll certainly be updating it."
Later support for OS/2 is a "possibility" but they're "not going to commit to it."
Apparently PowerBasic "plan to release many new BASIC compilers and BASIC programming products over the next 6 to 7 months". So watch this space.
A demo of PB/CC is available at ftp://ftp.powerbasic.com/pub/pbcc/
PB/CC's RRP is $149 (not including shipping & handling). For more details, check their website at http://www.powerbasic.com/products/pbcc/ or email sales@powerbasic.com
[ Back to Contents ]
PROPOSAL FOR NEW POWERBASIC NEWSGROUP
Marc van den Dikkenberg sent a formal Request For Discussion (RFD) to the news.announce.newgroups newsgroup, proposing a new PowerBasic newsgroup in the comp.lang.basic.* hierarchy, to be called comp.lang.basic.powerbasic - this would be carried by more news servers and be more "official" than the existing alt.lang.powerbasic. Marc said in the RFD that: "By now, well over a hundred people have already expressed their desire for a widespread newsgroup specifically aimed at PowerBasic products. Newsgroups in the comp.* hierarchy are carried by most newsservers, as opposed to a lot of alt.* newsgroups. As such, the comp.* hierarchy is preferable since it guarantees a much wider distribution or your questions / answers." If you want to join in the discussion, or read the full RFD including the proposed charter for the group, visit the news.groups newsgroup.
After the discussion phase, a Call For Votes (CFV) will be issued if there is enough support (judging by the response so far, there seems to be plenty). This will be your chance to vote for the creation of the new group - 100 more "yes" than "no" votes will be needed and more than two thirds of the votes need to be in favour. So, keep your eyes peeled for the CFV - it will be posted in the news.groups newsgroup as well as the regular BASIC ones, with full instructions for what to do.
While I'm on the subject, the editor of this fanzine recently sent out an RFD for some more Visual Basic newsgroups to split up the current mess of comp.lang.basic.visual.misc - the discussion can be found in the news.groups newsgroup. At the moment, there doesn't seem to be much interest though... :(
[ Back to Contents ]
Got a BASIC news article? Want to announce a new product that will benefit BASIC programmers? Then send it to basix@dewarr.globalnet.co.uk NOW! [The editor reserves the right to edit or omit articles]
LONG FILENAMES FROM DOS, by Alex Warren · alexwarren@writeme.com
One of the very nice things that Microsoft did for us with Windows 95 was add support for ridiculously long filenames, up to 256 characters in length, if I remember correctly. No longer do we have to put up with cryptic filenames such as "LETMRB01.DOC" - instead we be can more creative and save files with names like "Letter to Mr Brown draft 1 about the boiler that exploded last March which still hasn't ruddy well been fixed yet even though I've phoned them three times I mean I despair I really really do something ought to be done about it.doc" and other such silly things.
At least... almost. We can use long filenames from our Windows apps, but what if we want to use long filenames from our QuickBasic programs? If we try
OPEN "THE SILLY LONG FILENAME.TXT" FOR INPUT AS #1
we get a "Bad Filename" error. But if you look at the version of EDIT included with DOS 7, it's clearly a DOS program... but look! Look at all those lovely long filenames! Isn't it amazing! Isn't it? Oh well...
Yes, it is possible - we can access long filename functions from DOS (well, a Windows 95 DOS session anyway). But it's not very easy to do in QuickBasic - though it can be done. Really. If you look in the ABC Packets you'll hopefully see that I posted some code a few months back which will do just that, from QB. A newer version of the program (v1.5) is contained within this fanzine, in 11lfndos.bas
If you run this rather un-user-friendly program from Windows 95 (it won't work with QBasic, you'll need QB4.5 or better loaded with /L) you'll see that it works.
How? Well, it's all quite simple really, though it took me a while to figure it out - maybe because I'm stupid, I dunno... anyway: basically, all each subroutine does is call interrupt 21h (that means the hexadecimal number 21) with the required service (specified by inregs.ax) and the required tags (specified by the other inregs thingies). Usually these tags include a string, and to pass a string to an interrupt you need to use a pointer to that string. A pointer is basically a number referring to a specific part of the computer's memory, and is a concept that will familiar to the C++ programmers amongst us, though it's not often used in BASIC unless you're writing more complex programs using C++ libraries and such. If you look at the information for interrupts you see in books and on Ralf Brown's list, you'll see things such as "DS:DX - ASCIZ pathname". This means a string where DS (i.e, inregs.ds) specifies the segment in memory of the string, and DX specifies the string's location within that segment. ASCIZ just means a string with a null character at the end - you can get one of these in BASIC by using CHR$(0).
In QB, we can get the segment of the string using VARSEG and the string's location within that segment with VARPTR. This appears to work for fixed-length strings only - if you want to do the same with a variable length string you must use SADD in place of VARPTR.
For example, if pathname is a string containing a pathname, we can pass it to the interrupt using this:
inregs.ds = VARSEG(pathname)
inregs.dx = VARPTR(pathname)
Note that other services may want the pathname/filename to be in other places instead of DS:DX, so check your documentation. (If you have the time you can download the entire of Ralf Brown's interrupts list from his website - it's about 8mb).
So, this program should be enough to get you started using long filenames from QB. It wouldn't be too hard to make a library from it if you wanted to, and it would be quite a useful library to have. However, these long filename functions obviously won't work in anything less than Windows 95. There are equivalent functions though, that work with short filenames. It would be a good idea to make a library that detected whether LFN functions were available, and if not then replace the LFN services with the equivalent SFN service. This is (almost) really easy - the equivalent of an LFN service 71xxh is xx00h, so all you would need to do hopefully would be to add that to the int21 subroutine. (To detect whether LFN functions are available, look at the program - this detects for LFN functions when it starts). That would keep users of Windows and users of DOS (however rare they are these days) happy. Also, bear in mind that LFN functions require Windows to be running - if you are running in MS-DOS mode (not in an MS-DOS window from Win95) then the LFN functions won't work.
Have fun!
[ Back to Contents ]
GRAPHICS IN QBASIC TUTORIAL (PART 2), by "Hacker" aka Damian Nikodem · Hacker@alphalink.com.au
For todays lesson we will be covering PCX images! Now because we are covering a FILE FORMAT I will split the Tutorial into Diffrent Sections. The sections needed for PCX images are:
| HEADER IMAGE DATA PALETTE |
HEADER:
The header is ALWAYS 128 bytes and most of the data you will not
even use so I will not cover it here. But if you really want it
you can goto: www.alphalink.com.au/~hacker/pcxinfo.htm for all of the information but trust me
its not really worth the download time but there is a slight bit
of information that is very useful and that is the X and Y sizes
of the image. But that would make the program a LOT larger than I
would want to send (I have a VERY slow conection to my mail
server) but here is the formula for figuring out the size of the
image - 11pcxsiz.bas
All of that just to see what the size of the image is. This wouldnt be to hard to implement into a normal pcx loader but the problem is that my loader writes to memory (like I explained in part 1) and because it is only designed to handle 320x200 it works a LOT faster.
IMAGE DATA:
The data in the image is easy to handle A pcx image is almost a
direct screen to memory dump with 1 single execption. If the
number that is read is over 192 and under or equal to 255 then it
starts a small loop and this lets us get a small compression
ratio (1/1.2) on the average image without much work being done.
Well heres the code to load a 320x200 image - 11pcxvie.bas
Now what have you notaiced about that code apart from you cant make heads or tails of it??? If you run it the colors off. Do you remember what I said in part one about the palette and how you can redefine the colors well you can now put it into action!
PALETTE:
The palette in a PCX file is not all ways the exact same palette
as the standard so the last 768 bytes of a pcx image are just
palette data. The format for the pallete data is quite simple. it
contains 256 * 3 ascii charecters. Each charecter is one part of
the color so the first charecter is the red value for color 0 the
second is the Green value for the color 0, the third charecter is
the blue value for color 0,and so on this is repeated until color
255 is reached. Here is the final piece of code for the PCX
loader - 11pcxvi2.bas
Now you know how to load PCX images in basic! Keep this code (The entire loader) because next issue I will be discussing RANDOMIC GRAPHICS. The jpg loader is being postponed until I fully understand the format this may be a few months ( or years have you seen the size of the DOCS)
NOTE:
Also go down to the store and BUY quake 2 it is well worth it! if
you dont have the money at least download the shareware (11 Mb)
from www.quake2.com I will be using screen shots from the game in the
next part also
- Hacker hacker@alphalink.com.au
[ Back to Contents ]
YOUR PROGRAMS - YOUR RIGHTS, by Alex Warren · alexwarren@writeme.com
I've written this article to explain to you about copyright laws and how they affect you and your programs - I hope it will be of help to some of you. I'm not an expert on this subject - all information has been gathered from various copyright FAQs I've researched. If you require more information I suggest you visit one of the copyright newsgroups, or better, consult your lawyer.
Copyright:
EVERY program you have already written yourself is copyrighted - to you. You do not need to register it with anyone - you already own the rights to it. Copyright registration is unneccessary and is only a good idea in circumstances where you're likely to need to prove copyright ownership, which isn't often. So, the quick and easy step to ensure that your software is copyrighted in all countries of the world is to do nothing! OK, so a sentence such as "Copyright © 1998 Whatever Software" isn't going to hurt - in fact, it's a good idea to add a statement as it reinforces the applicable laws by demonstrating copyright ownership.
Most countries in the world share copyright laws. If you're a resident of the US, your software is still protected even when used in the UK, or France, for example.
So, the message is: Your software, and in fact anything that you write or compose or draw, is already your own intellectual property. You have rights to it already.
Public domain and Freeware:
Just because you distribute something as freeware does not mean that you've abandoned your rights to it. If you give away your applications for free, it is still illegal for others to distribute them without permission. This makes it technically illegal to distribute even a freely distributed piece of software such as QBasic, if Microsoft has not given permission for you to do so (permission could take the form of a letter to you, or a statement in the help file giving permission to distribute the software free of charge, etc.) If you want your application to be distributed freely by others then it's usually a good idea to put in a phrase such as "This software may be distributed freely on provision that no charge is made for it", etc.
"Public domain" software is different. You can release something into the public domain by saying something like "This software is hereby released into the public domain" somewhere in the software or in its documentation. If you put something in the public domain then you abandon all your copyright rights to it. So, don't say "public domain" when you really mean "freeware" - you won't be able to stop people selling it, giving it away, etc. - other people will have just the same copying rights to it as you do. If you ever see a notice on some software you've downloaded saying "This software is released into the public domain for non-commercial use", then don't believe it. That sentence contradicts itself. By donating the software to the public domain, the programmer has abandoned all rights to the software, making it theoretically possible for anybody to sell it on for trillions of dollars/pounds/etc. (not that anybody is neccessarily going to buy it, though). So, always remember - there is a massive difference between "public domain" and "freeware". The two terms are not inter-changable. So, even though QBasic is given away freely, it is not "Public domain".
Copyright expiration:
Copyright doesn't last forever. In the case of individuals, it expires 75 years after the death of the creator (I think - though I did read somewhere that it was only 70 years within the EC so I may well be completely wrong). This means that, in 1998, anything written by anybody who died before 1923 is now in the public domain, and anything written by anybody who died after 1923, or is still alive, is still under copyright. The case is different with computer programs, however - this expires 50 years from the date of creation, if my sources are correct. This means that you will be able to distribute QuickBasic freely and legally any time after the year 2038, whether or not Mr. Gates is still around... still, I'm sure you'll be able to find a way to pass the time.
[ Back to Contents ]
MORE ARTICLES:
These articles appear in separate HTML files in the Basix Fanzine directory - click the links to read 'em:
[ Back to Contents ]
INACCURACY IN GRAPHICS TUTORIAL IN ISSUE 10
From: kraken@mbox3.singnet.com.sg (Rory)
Newsgroups: alt.lang.basic
Subject: inaccuracy in Graphics Tutorial BASIX
fanzine #10
Date: Mon, 30 Mar 1998 16:54:38 GMT
in the aforementioned tutorial by 'Hacker' aka Damian Nikodem, he claims that POKEing straight to video memory is faster than Qbasic's PSET routine. he said, quote, "a LOT faster". hearing everyone say Qbasic's PSET is way slow for setting pixels, and that writing direct to the video memory is faster, i decided to investigate this myself. i came up with this code [ 11ng1.bas ]
'code to benchmark speed of PSET and
'POKEing straight to video memory
SCREEN 13
PRINT "Press any key to begin test."
SLEEP
'fill screen pixel by pixel with PSET
startPSET# = TIMER
FOR col% = 0 to 15
FOR y% = 0 to 199
FOR x% = 0 to 319
PSET(x%, y%), col%
NEXT x%
NEXT y%
NEXT col%
endPSET# = TIMER
'fill screen pixel by pixel with POKE
DEF SEG = &HA000
startPOKE# = TIMER
FOR col% = 0 to 15
FOR y% = 0 to 199
FOR x% = 0 to 319
POKE 320& * y% + x%, col%
NEXT x%
NEXT y%
NEXT col%
endPOKE# = TIMER
DEF SEG = 0
'print results
PRINT "Time taken with PSET:"; endPSET# - startPSET#
PRINT "Time taken with POKE:"; endPOKE# - startPOKE#
ok, the times i got on my P100
for the POKE routine were never more than 1.5 seconds faster than
the PSET routine. most of the time it was only 0.2 seconds
faster. so POKEing direct to the video memory isn't "a LOT
faster" than using PSET. what annoys me more about the
article is that he never specified his variables to be of any
type, therefore Qbasic defaults to type double i think, which
makes the POKE routine run ridiculously slow. it took about 2.5s
for the PSET routine with everything specified as short integer,
and 30s for the POKE with no specifier!! does ayone see something
wrong about my test code? are my conclusions correct? the only
thing i see wrong is that POKE is not as fast as it can be,
because i have to put an ampersand after the 320 in
this line POKE 320& * y% + x%, col% otherwise Qbasic spews
out an overflow error. because of the long, it's not as fast as
if i was able to keep everything short. if it was possible to do
this, then i believe that POKEing would be much faster the PSET.
comments anyone?
From: SimpleSi
<NewsGroups@phillips1.demon.co.uk>
Newsgroups: alt.lang.basic
Subject: Re: inaccuracy in Graphics Tutorial
BASIX fanzine #10
Date: Mon, 30 Mar 1998 18:46:09 +0100
It all depends on the processor and graphics card that you have. With a fast processor, the multiplication is quicker, so poke is not slowed down. On my lowly P90, poke was twice as fast as pset.
From: pb@excelsior.xs4all.nl (Marc van den Dikkenberg)
Newsgroups: alt.lang.basic
Subject: Re: inaccuracy in Graphics Tutorial
BASIX fanzine #10
Date: Mon, 30 Mar 1998 19:48:11 GMT
On my P200, the code you nclosed here takes 2.5 seconds for PSET, and 1.6 seconds for POKE. That's more then 1.5 times as fast... I think that qualifies as 'a lot', when things are time-critical...
From: kraken@mbox3.singnet.com.sg (Rory)
Newsgroups: alt.lang.basic
Subject: Re: inaccuracy in Graphics Tutorial
BASIX fanzine #10
Date: Tue, 31 Mar 1998 15:05:30 GMT
ok, another run today gave me 7.367s for PSET and 6.695s for POKE. that's a difference of about 1.1 for me. well, since my code is just filing the screen, i shall take your word for it now, that 1.5 times is significant enough to be a LOT faster. i will try out both methods in a real world program (probably a game of some sort) and post results when i have time. unless someone would like to beat me to it.
From: Krogg
<krogg@inspace.net>
Newsgroups: alt.lang.basic
Subject: Re: inaccuracy in Graphics Tutorial
BASIX fanzine #10
Date: Mon, 30 Mar 1998 17:28:13 -0500
in qbasic on my p75 under win95
12.30 for pset
9.77 for poke
in powerbasic 3.5 on my p75 under win95
Note:i used screen 7 in pb3.5 for pset
and mode 13h for the poke part.
Time taken with PSET: 13.2370438659709
Time taken with POKE: 1.48298831693683
looks damn faster
here is a test using dim absolute scrn(319,199) as byte at
&ha000
for a video buffer overlay
ploting a point ="scrn(%x,%y)=%col"
Time taken with PSET: 13.0722673863129
Time taken with POKE: 2.85612564742769
still faster than pset
but
with some inline asm code instead of the poking like
! mov ax, &ha000
! mov es, ax
! mov ax, 320
! mul y%
! mov bx, x%
! add bx, ax
! mov al, col%
! mov es:[bx], al
ya get
Time taken with PSET: 12.5230124541195
Time taken with ASM: .823882398297428
Now thats fast!
now with another asm code for the poking
not much diff but uses byte for color insteat of integer
! MOV AX , 320
! MUL y%
! MOV DI , AX
! ADD DI , x%
! MOV DX , &hA000
! MOV ES , DX
! MOV AL , col%
! STOSB
Time taken with PSET:
12.4680869608928
Time taken with ASM: .823882398290152
as you can see,its allmost the same.
I hope this helps someone
By the way,the asm routines i got from Robert Seidel. I havent
got the code handy but a faster asm code uses shifts instead of
muls somehow but i will leave that for someone else to test.
[ Back to Contents ]
From: pb@excelsior.xs4all.nl (Marc van den Dikkenberg)
Newsgroups: alt.lang.basic
Subject: Re: Unlocking old BASIC programs
Date: Mon, 30 Mar 1998 19:48:09 GMT
On 30 Mar 1998 15:13:32 GMT, eppersond@aol.com (EppersonD) wrote:
>Does anyone know how to unlock old BASIC programs. Seems
like it used BLOAD
>and BSAVE to do it. I have it in a manual somewhere but I
moved recently and
>have not been able to find it. When you try to list a program
it says "Illegal
>Function Call".
If you're talking about protected GW-Basic programs, here are two
ways to do it. It's something I found on the internet quite some
time ago...
Here's a trick that often works:-
1. run GWBASIC.
2. LOAD the protected program.
3. type NEW and hit return.
4. type 0'* (The * is a placeholder for CHR$(15) - so that's zero,apostrophe, ALT+15) and hit return.
5. you can now LIST and SAVE the file normally.
6. don't ask ME why it works.
Failing that write your own UNPROT.BAS program as follows:-
1.Run DEBUG and type in the following
E100 FF 1B
RCX
2
NUNPROT.BAS
W
Qwith a carriage return at the end of each line of course.
There will be some responses from DEBUG which can be ignored except that RCX will present you with a colon input prompt instead of the usual hyphen.
That gets you a file which contains only two bytes, FF and 1B.
Now...
2. Run GWBASIC.
3. LOAD the program you want to unprotect.
4. LOAD UNPROT.BAS.
5. You will now find you can LIST (etc.) the original program.
6. Don't ask me why that works either.
I take no credit (or blame) for either. Both are old, old tricks which have been around for so long that, it seems, they may have been forgotten.
[ Back to Contents ]
From: crbates@cdmnet.com (Curt Bates)
Newsgroups: alt.lang.basic
Subject: Re: Sorting random numbers?
Date: Mon, 25 May 1998 23:23:57 GMT
"Retribution" <saturn@29.net> wrote:
>Thanks Ian but the problem lies in the generation of the
numbers. I'm
>generating them one at a time so no two are the same. The
numbers have
>already been generated by the time I need to sort them rather
than
>generated in a DIM statement.
>So I have six numbers, no two alike that need to be sorted.
The routine you
>sent was however handy...thanks!
>
>Ian Blakeley <root@127.0.0.1> wrote in article
><35632d1a.18028890@news.btinternet.com>...
>> Hope the attached helps, some of its from a book can't
remeber which
>> and some I probably modified. 100 random nubers are
generated, sorted
>> and displayed.
For six number you can use a
simple bubble sort. Like this: [ 11ng2.bas ]
[Ed's note - I've modified this slightly to work properly in QB,
and to print the results at the end]
RANDOMIZE TIMER
DIM n(6)
CLS
' generate 6 randem numbers
FOR x = 1 TO 6
n(x) = INT(RND * 40)
NEXT
' sort the numbers
s = 1
WHILE s = 1
s = 0
FOR x = 1 TO 5
IF n(x) > n(x + 1) THEN
t = n(x)
n(x) = n(x + 1)
n(x + 1) = t
s = 1
END IF
NEXT
WEND
FOR x = 1 TO 6
PRINT n(x)
NEXT x
Hope this helps.
[ Back to Contents ]
From: pb@excelsior.xs4all.nl (Marc van den Dikkenberg)
Newsgroups: alt.lang.basic
Subject: Re: HOW CAN I MAKE FAST KEYBOARD INPUT
??
Date: Tue, 12 May 1998 21:21:39 GMT
On Tue, 12 May 1998 18:17:15
+0200, Jellyfish <jelle@casema.net> wrote:
>I was wandering how I could get fast keyboard input for a
game in
>GW-Basic ??
I'm not sure if GW-BASIC supports this too, but...
Try:
A=INP(&H60)
This will read a character
directly from the in-port, and is a LOT faster then inkey$. It
will take you some time to figure out the values it returns,
though, since it's a lot less 'friendly' then INKEY$.
you may need to insert A$=INKEY$ in your loop as well, though,
since the method shown above won't delete the characters from the
keyboard buffer. If you don't do this yourself, your computer
will be beeping continuously because the buffer is full...
Advantages: no delays whatsoever, extremely fast repeat rate,
detect key press, and key release -- keep track of multiple keys
hold down simultaneously.
Disadvantages: more difficult to keep track off, and you have to
find the scancodes/release codes of the various keys somewhere
first.
[ Back to Contents ]
From: c1284j@aol.com (C1284J)
Newsgroups: alt.lang.basic
Subject: Re: Annoying beeps
Date: 22 Apr 1998 23:36:24 GMT
>>anyone know how to
be rid of that annoying beeping
>>when one holds down a key too long in qbasic?
>
>That's not QBasic, it's the operating system complaining that
the
>keyboard
>buffer is full, and all those extra keystrokes are being
lost. Just let go of
>the key when you hear the first beep.
And here's the code to clear the keyboard buffer:
| DEF SEG = &H40 POKE &H1A, PEEK(&H1C) POKE &H1B, PEEK(&H1D) DEF SEG |
'switch to BIOS
data segment 'make the buffer head pointer 'equal then buffer tail pointer 'back to default data segment |
[ Back to Contents ]
POKE-ING CHARACTERS TO THE SCREEN
From:
"Judson McClendon" <judmc@mindspring.com>
Newsgroups: alt.lang.basic,comp.lang.basic.misc
Subject: Re: POKE to screen?
Date: Wed, 22 Apr 1998 08:33:36 -0500
KKJOHN2 wrote:
>A while back someone posted code to POKE and PEEK
characters to the
>screen. I want to sqeeze the last bit of speed out of my text
boxes
>without using alot of advanced programing.
>If you can help, please email me below, I sometimes can't
follow these
>groups. THANKX
Don't know if this is faster than PRINT, but here are routines to
POKE characters and strings to the screen: 11ng3.bas
[ Back to Contents ]
From: "Ali
Afshar" <afshar@easynet.co.uk>
Newsgroups: comp.lang.basic.misc
Subject: Re: DRAW for plants in fishtank program
Date: Fri, 24 Apr 1998 02:27:40 +0100
Steve Rush wrote in message
>It's been a while since I saw any code, but search for
"fractal" and "plant".
>There are iterative processes that can create very realistic
shapes with a few
>equations.
Dear Gloria
I'm not sure whether this will meet your needs but here's a
simple iterative SUB for creating a different number of
tree/plant fractals using different initial input parameters. Any
problems with the code, get in touch.
Cheers,
Ali
[ Back to Contents ]
From: steverush@aol.com (Steve Rush)
Newsgroups: comp.lang.basic.misc
Subject: Re: Mouse in Qbasic?
Date: 10 Apr 1998 00:42:30 GMT
>In QBasic (not QB45),
the ONLY way to call an interrupt is to
>write a little machine language program and then:
>
> 1) call ABSOLUTE to
> 2) call the machine language program, which
> 3) calls the interrupt, which
> 4) sends your message to the mouse driver.
I use QuickBasic 4.5, but I a have experimented with the CALL
ABSOLUTE method of calling the mouse driver. You don't need a
machine-language program. You can call the mouse driver directly
with CALL ABSOLUTE if you know where to call. You can PEEK this
address out of the interrupt table at 0000:(&H33 * 4). The
first two bytes at this address are the segment, followed by the
offset. It takes a little fiddling to combine the two one-byte
PEEK values if the segment or the offset is greater than
&H7FFF, because the obvious
MouseSeg% = PEEK(TablePtr%) + PEEK(TablePtr% + 1) * 256
MouseDvr% = PEEK(TablePtr% + 2) + PEEK(TablePtr% + 3) * 256
will produce an integer
overflow. It should work if MouseSeg and MouseDvr are LONG
integers, but I think you have to convert them to 16-bit integers
for use by DEF SEG and ABSOLUTE.
You then use
DEF SEG MouseSeg
CALL ABSOLUTE (m1, m2, m3, m4, MouseDvr)
Where m1..m4 are the four parameters to the mouse driver. You always have to supply all four, and they should be variables, not runtime expressions, because many mouse functions return data by overwriting the parameters.
[ Back to Contents ]
From: xxx.spagtime@compuserve.com [Ed: poss. anti-spam measure? Maybe spagtime@compuserve.com ?] (Spag)
Newsgroups: comp.lang.basic.misc
Subject: Re: Qbasic Communications
Date: 29 Mar 1998 08:34:09 GMT
"Michael Beck" <dbeck@wesnet.com> wrote:
> I've just spent 5 hours trying to get two computers some
what talking
> to each other. I would really like to know how to write
modem or
> serial games in qbasic. If anyone would please direct me to
a good
> communications tutorial, I would greatly appreciate it.
> Thanks for anything.
Have a go with this, hope it helps
Plumb the 2 machines together with a 'null modem' cable, then run
the following Qbasic prog on each. (it helps if you can see both
monitors!!)
[ Back to Contents ]
Thanks to the following for contributing articles and source code for this issue:
...and to the following for their newsgroup posts that I've reproduced here:
NEXT ISSUE:
Well, who can tell... Rude John's column will be back... more informative posts from the newsgroups... plus the latest news - all in a new, brighter, more enlightening form guaranteed to bring you ever-lasting joy and happiness. Probably.
I hope to release the next issue as soon as I get enough contributions - hopefully before October 1998. If you'd like to see it sooner, why not contribute an article? Go on - you know you want to.
I hope you've enjoyed the issue and have found it useful. Hopefully the new HTML format has made the issue easier to read and easier to use code from.
Until next time... goodbye!
Alex Warren,
27th June 1998
[ Back to Contents ]