| |
(This article was first published in the ICPUG
Journal MAY /JUNE 1989 issue.
Permission from Joe Griffin to republish on the Internet has been
received.)
8 bit support
There have been a few voices raised in protest recently over the amount of
Amiga content in the ICPUG newsletter and the relative scarcity of support
for the 8 bit Commodores. I am an 8-bitter, I have no desire to obtain an
Amiga, as I am not interested in games, music, graphics or outdoing the
neighbours by having the latest technology! Now for the benefit of the two
remaining ICPUG members that I haven't just upset, I'll return to the
point.
Within the group, we have a wide range of talents. At the
upper (?) end of the range, we have people like Arnot , Cranstoun,
Grainger, Todd & Tranmer some of whom work professionally in computing and
who are pushing the boundaries of knowledge on the machine. In 1982, when 1
first joined ICPUG, they and their predecessors were running 8096's and
were starling to play with ViC20's. The moan from the membership in those
days was what about all of us with 3032's, we aren't getting support any
more. When the 64 appeared, that was the new ground and attracted the bulk
of the interest. Then came the ill fated C16 and Plus/4; these never
attracted the same monopoly as the 64, possibly because they were perceived
within the group as over-priced games machines. With the arrival of the
128, there was again a burst of monomania within the newsletter which was
followed in short order by the advent of Commodore's ultimate games
machine, the Amiga. Those few people who are really out in front (as
opposed to the many who would like to think they are) are breaking new
ground. They can't find much new ground to break on the 8096 or the 64, it
was done 5 or more years ago but the Amiga is new and relatively
unexplored.
In the second rank, so to speak, come the vast majority of
those who write for the newsletter. I class myself in this group. We are
knowledgeable about our respective machines but are not in the expert
category. Below this (in terms of knowledge, not importance) come degrees
of expertise right down to the member who has a machine but knows little of
it other than how to run specific programs and has joined ICPUG mainly
because we are the only people who write about that machine, other than in
terms of games software. I don't bother to count those people who join only
for the free software or the discount scheme.
As a librarian and a fairly frequent contributor to our
Journal, I attract a fair number of letters with queries. Some of these
queries are trivially simple (to me, but not to the poor unfortunate who
does not understand that you can slow a PET listing, rather than have it
rush up the' screen like an express train). However, now and again I get a
real humdinger (usually from a novice) which leads me off on a voyage of
discovery for myself. Then, of course, there is the glow of satisfaction
when I sort out a problem for one of our members.
No, everybody in ICPUG has a role to play, whether they are
a 'C' and Assembler programmer for the Amiga, or a 'on a good day I can
find the power switch' type. However, I accept that for many of the more
novice members, to say " if you don't like what's in the newsletter, give
us a contribution" will frighten them off, rather than encourage them to
write. BUT not so long ago we were all novices and the only way to become a
writer of international repute, like me, [what? -Ed] is by actually doing
some writing (on second thoughts maybe that should be 'ill repute'). It was
pleasing to see a number of new names in the March/April newsletter.
To return to the original theme of 8 bit info; some time
ago it was suggested in the National Committee that we should put together
another 'Compendium'. The original IPUG Compendium' came out in November
1980 and contained most of the material of value for Original and Upgrade
ROM PET's. We thought that a single publication, containing the words of
wisdom of the past 8 or 9 years would be of value to many members. We got a
response of about 10, only. I hope that an article on back numbers will
appear in this issue, directing 8 bit users to previous magazines of
particular merit for specific machines. [sorry, maybe next issue - Ed
]
This column 'Seven-and-a-half bits' is part of my own
attempt to ensure that every issue contains something for the 8-bitters. I
would like your feedback; ideas for future rantings will be gratefully
received and considered and your help is immediately requested.
Disk Drive Identification
Many of you will know that I have a 'thing' about disk drives. A number of
the programs I have written or developed use a short routine to identify
the disk drive in use, from Its ROM code. Recently, it was pointed out to
me by a member that his 1571 claims to run DOS 3.0, whereas my routine
identified it as a 1571 running DOS 3.1. My 1571 (which as you know from
the last issue contains the 'latest' Commodore ROM) is identified as DOS
3.1. So the way to tell if your drive Is, for the moment (but see below),
insolubly bug ridden, is to look at the DOS version.
The routine I use is essentially this:
OPEN 1,8,15:PRINT#1, "M-R"CHR$(a1)CHR$(ah)
:GET#1,A$:A$=A$+CHR$(0):CLOSE1
Printing the ASCII value of A$ will then give the value read from ROM.
The drives and values I know about are listed below, if anyone finds a
drive which does not conform, I would be pleased to hear about it and
investigate further.
Initially, I interrogate the high byte of the reset vector,
to obtain drive identity. In a few cases further investigation is
required.
| al | ah | a$ | drive type |
|---|
|
|---|
| 255 | 255 | 255 | 1581 or d90xx hard
drive |
|---|
| | 254 | 1541, 2031 or 1571 |
| | 242 | 8050, dos 2.5 |
| | 241 | 1551 |
| | 226 | 3040 |
| | 213 | 4040,dos 2.1 |
| | 198 | dos 2.7, 4040, 8050 or 8250 |
To distinguish between drives having the same hi-reset value, a second
location is read:
| 3 | 164 | 117 | 1581 |
| | 0 | d90xx hard
drive |
| 21 | 255 | 141 | 1541 |
| | 81 | 2031 |
| | 76 | 1571 (dos 3.0 &
3.1) |
| 234 | 16 | 0 | dos 2.7 4040 |
| 172 | 16 | 1 | dos 2.7 8050 |
| | 2 | dos 2.7 8250 |
If you have a drive which doesn't conform. please let me know. At the
moment, I would like data on 1570, 1540 (Vic) and 2020 drives. I'd also
like ROM dumps from these drives and the 1551, original (metal cased) 2031
and SFD 1001. I can supply a program to obtain a ROM dump, if anyone would
like to assist.
1571 Bug Saga
Following on from my article in Vol 11, Issue 2, I have had feedback from a
few members with metal 128D's, confirming my findings. In particular, I
sent a copy of the test program to Tim Harris of Financial Systems. Having
found the bug on his machines, Tim tested the 1571 with Jiffy Dos fitted.
Sadly, it failed but when Tim spoke to the authors, they admitted that they
were unaware of the bug and promised to fix it. I have written direct to
them and hope that we will see a fix for our machines. As before, I will
keep you updated through this column.
Super Diskdoc
I have mentioned Precision's SDD in many articles. Its one major failing,
in my opinion, is that it does not cater for the 1581 3.5 inch drive (which
was introduced after the program was written). Some time ago, I did offer
Precision my services in producing a new version of the program to cope,
but received no response. I suspect that this is because they are not
willing to invest effort in promoting a product for machines at the end of
their life.
In order to use SDD with the 1581, I have hacked the code,
to replace the data for the 8050 (which I don't have) with the details for
the 1581. At the moment, the BAM functions do not work, but everything else
does . They are very simple to carry out and only about 25 bytes of the
data table need to be changed.
If anyone else has already done this, please let me know,
so that we can compare notes.
|
