DAVE HUNT’S RAMBLINGS
NED REORDER EOE RE REO REO REE
Correction to the last issue.
FRE REINS EERE EINE BE OD ID EE OE INE OD READ RE ERI ROBE NORE ROE RE
Regular readers will be well aware of my tendency to muck things about,
and may well remember I had a go at a simple database handler by Mike Trim in
the last issue. I made a note at the time that I thought my mods would do no
harm, simply drawing a number of duplicated routines into a common subroutine.
However, as is the luck of these things I forgot to change a line number and as
I could not test it, being written using the extension to Nascom BASIC provided
by Polydos, we published it as it was. Now the fact that I didn’t know it was
written for the Polydos extension BASIC was pointed out by a couple of readers –
well I can’t be expected to know everything now can I -- Polydos is just one of
those things that has passed my by and I’ve never tried it. Anyway, by
publishing we seem to have caused Mr. Trim quite some trouble, as it would seem
that a number of more resourceful readers have gone to the trouble of
discovering his address (which was not published) and asking for corrections.
This is of course something of an embarrassment to everyone, not the least Mr.
Trim who has spent some sum on stamps putting right my mistake. To make ammends,
I include Mr. Trims’ database handler again in full (hopefully correct this
time) and hope by so doing the "powers that be’ will see fit to make him a
payment for the republication of his contribution. See program 1 on an adjacent
Non-returned disks and cassettes.
This brings me to other matters. My having the opportunity to play
around with Mr. Trims’ program came about because it was provided as hard copy,
and the lot fell to me to type it in. In doing so I mentally rearranged it and
then affected the mods. Now the reason it was supplied as hard copy was simply
that the cost of a disk would have been equal to the payment made for the
contribution, and this was good reason for not sending a disk. Point taken. In
future we will try to ensure that when we receive copy on any sort of media we
will try our best to return it to its rightful owner. This point has also been
demonstrated by Chris (Dr. Dark) whose most recent contribution has arrived as
hard copy for the same reasons. I only hope I don’t get landed with the job of
typing his lot in, he’s almost as prolific as me when it comes to footage of
printer paper. I know I haven’t always returned media in the past because I have
several tapes and a couple of disks belonging to other people. The only snag is
that I don’t know who they came from, as the names and addresses have either got
lost or were not supplied in the first place.
Why we go on about CP/M.
Paul received a letter recently complaining bitterly that the magazine
was becoming more and more CP/M and disk orientated and people like standard
Nascom 1 owners were being left out in the cold. True. I know I’ve said it
before, and I’m sure others have said it as well. We publish a fair balance of
what we receive, and if contributions are tending in the direction of disks et
al, then the magazine content goes that way as well. If you want more articles
on the basic Nascom 1 then write them!!!
Machine code delays (with the 2X81?)
Which neatly brings me to the next two points. The first concerns a 2X81
owner (what’s that I hear you ask). However, this person had got hold of a
simple BASIC program which when loaded allowed the user to type in Z80 opcodes
to any address above itself and then jump to the program. It sounded very like a
stripped down NAS-SYS with no debugging facility. Here arose his problem. As
there were no debugging facilities it was extremely difficult to understand what