[NLRS] Who's the computer programmer in the bunch?

John P. Toscano tosca005 at tc.umn.edu
Sat Jul 1 17:15:23 EDT 2006


Scott wrote:
> 
> 
> I wrote my own logging program, but I'm running into a bit of a snag. 
> It's written in qbasic.  I'm trying to dimension an array A$(x,y,z) and 
> the largest number I can get to work for x is 99...so it can only log 
> 100 calls (zero to 99) and then the subscript goes out of range.  After 
> the June contest, it is inadequate to only be able to log (and 
> automatically dupe check) 100 calls!  :)  Ideas???

Scott:

I don't have a user manual for QBASIC around here, but I dug up a little 
info by GOOGLEing for it.

It *SHOULD* be possible for an array dimension to exceed 100, based on 
some tutorials I found that dimensioned an array to 3000 elements.  I 
didn't find anything that spelled out limits on mult-dimensional array 
subscript size.

How big are "y" and "z" ?  Since QBasic is an old DOS program, its 
memory capacity is going to be limited to 640K total, and there are 
other limits as well.  The critical thing is (most likely) the total 
amount of memory that the array requires.  This will be x * y * z * the 
number of bytes per array element.  Since this is an array of strings, I 
believe that the minimum size per array element is 5.  If the product of 
x, y, z, and 5 exceeds 64K (i.e., 65,536), there is a high likelihood of 
failure.  The following quote from a web site suggests a possible 
work-around...

<------ begin quote ------

The huge memory model is nearly identical to the large model, the only 
significant difference being that the huge model permits individual 
arrays to exceed 64K in size. Although the huge model lifts the limits 
on arrays, some size restrictions do apply. To maintain efficient 
addressing, no individual array element is allowed to cross a segment 
boundary. This has the following implications:
* No single element of an array can be larger than 64K. An array can
   be larger than 64K, but its individual elements cannot.

* For any array larger than 128K, all elements must have a size in
   bytes equal to a power of 2. If the array is 128K or less, its
   elements can be any size, up to and including 64K.

...QuickBasic uses the medium memory model within conventional memory. 
Huge arrays are enabled by the /AH option which permits both the IDE and 
the compiler to use far addressing.

------ end quote ------>

I'm curious on what aspect of a logging program requires or benefits 
from a 3-dimensional array.  I suppose callsign, band, and gridsquare 
could be the three dimensions, because any particular call could have 
multiple occurrences in the log from different grids and on different 
bands.  But I'm not sure why you'd need to store that 3-dimensionally in 
an array except possibly for rapid lookup of dupes.  The waste of memory 
probably doesn't justify the extra speed.  Even if a particular station 
appeared in your log 64 times (8 bands x 8 grids), for example, a search 
of 64 records should be pretty quick, especially if the data were 
organized properly.

You might therefore be better off using the TYPE construct (similar to 
the C language's typedef of a struct)...

TYPE LogEntryType
   LogDateAndTime as double
   LogBand as string
   LogMode as string
   LogFromGrid as string
   LogToGrid as string
END TYPE

DIM ContestLog(1000) AS LogEntryType

I chose a double for the date and time because I would probably convert 
the calendar & clock on-the-fly to a double-precision floating point 
number in the fashion of Microsoft Excel, where the integer portion 
counts the number of days since January 1, 1900, and the fractional part 
counts the fraction of a day (e.g., 12:00 Noon = 0.5, 6:00 AM = 0.25, 
etc.)  This makes it real easy to compare one date&time to another, or 
to compute elapsed time.

Good luck on the project.  I fear that QBasic might not be up to the 
task you have in mind, but I've often been amazed by the programs that 
some really skilled programmers have managed to turn out.  You might 
want to try converting the program to Visual Basic, since that's a true 
Windows program and can be compiled into pretty efficient machine code, 
not just interpreted P-code.

73 de W0JT


More information about the NLRS mailing list