The Basix Fanzine
issue 11 july 1998


[ Basix Fanzine Main Index ]

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.




From the newsgroups

Final words




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 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

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 ]



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

PB/CC's RRP is $149 (not including shipping & handling). For more details, check their website at or email

[ Back to Contents ]



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 NOW! [The editor reserves the right to edit or omit articles]




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


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 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

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:


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: 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.

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 -

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!

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 -

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)

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 I will be using screen shots from the game in the next part also

- Hacker

[ Back to Contents ]



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.


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 ]



These articles appear in separate HTML files in the Basix Fanzine directory - click the links to read 'em:

[ Back to Contents ]




From: (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

PRINT "Press any key to begin test."

'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 col%

'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 col%

'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: 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: (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: (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 <>
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

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%
! ADD DI , x%
! MOV DX , &hA000
! MOV AL , col%

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: (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) 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

with 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.
3. LOAD the program you want to unprotect.
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: (Curt Bates)
Newsgroups: alt.lang.basic
Subject: Re: Sorting random numbers?
Date: Mon, 25 May 1998 23:23:57 GMT

"Retribution" <> 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@> wrote in article
>> 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]

DIM n(6)

' generate 6 randem numbers
FOR x = 1 TO 6
n(x) = INT(RND * 40)

' 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

FOR x = 1 TO 6
PRINT n(x)

Hope this helps.

[ Back to Contents ]



From: (Marc van den Dikkenberg)
Newsgroups: alt.lang.basic
Date: Tue, 12 May 1998 21:21:39 GMT

On Tue, 12 May 1998 18:17:15 +0200, Jellyfish <> 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...



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)
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
>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
'switch to BIOS data segment
'make the buffer head pointer
'equal then buffer tail pointer
'back to default data segment

[ Back to Contents ]



From: "Judson McClendon" <>
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:

[ Back to Contents ]



From: "Ali Afshar" <>
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

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.



[ Back to Contents ]



From: (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: [Ed: poss. anti-spam measure? Maybe ?] (Spag)
Newsgroups: comp.lang.basic.misc
Subject: Re: Qbasic Communications
Date: 29 Mar 1998 08:34:09 GMT

"Michael Beck" <> 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:



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 ]

[ Basix Fanzine Main Index ]