LAST ARCHIVE

ARCHIVES INDEX

NEXT ARCHIVE

SEVEN-AND-A-HALF BITS (Left after reassembly!)

Joe Griffin

Matters Arising

Firstly, a big thank-you to the various members who have sent me ROM dumps from their disk drives, or who have offered to provide me with a dump. Secondly, another thank you to those members who have dropped me a line of approval for this column (the '(of a bus??)' was an addition by Tim) [Remember the John Cleese '386 chips & 32 bits of a bus' Compaq ad? - Ed] or who have made suggestions, direct or indirect about what they would like to see in ft.

In the last column, I was foolish enough to mention slowing down a PET listing, without actually telling you how to do it. For any 40 column PET, holding down the <RVS> key while a program is being listed (or any other output is being printed to the screen) will introduce a half-second delay between each line. On the 80 column PETs, this is achieved by holding down the <left-arrow> key (the one at the top left of the keyboard). On the C-64, the <control> key has the same function. Additionally on the 80 column machines, a listing can be paused by pressing the <colon / asterisk> key. The listing is resumed by pressing the <left-arrow> key or 3,6 or 9 on the upper row of keys. On BASIC 4 PETs (40 & 80 col) the display of a disk directory can be paused by pressing the space bar. Pressing it a second time resumes the display. So now you all know!

My means of identifying disk drives caused confusion for some people. The wording I used was 'The routine I use is essentially this:' and I then gave a line of BASIC. The line included a GET# statement. There are a few BASIC keywords which cannot be issued as direct mode commands, but only as instructions within a program. The main ones are GET, INPUT, GET# and INPUT# so that any attempt to type in the line given and press return would give the famous helpful response 'SYNTAX ERROR' - I know I'm VICE chairman, but a SIN tax! To h elp those who want to try the routine, we need a short program, thus:

10 AL=255:AH=255 : REM reset vector hi-byte
20 OPEN 1,8,15 : PRINT#1,"M-R"CHR$(AL)CHR$(AH)
30 GET#1,A$:A$=A$+CHR$(0):CLOSE 1
40 PRINT ASC(A$)
50 END

By altering the values of AL and AH in line 10, you will be able to look at various addresses in the disk drive ROM.

Peripheral Devices

One of the questions I am frequently asked is whether a particular disk drive or printer can be used in conjunction with a particular computer. When Commodore bought out the PET (but maybe not the original 'small keyboard' version) they chose to equip it with a bastardised form of the IEEE-488 bus. In simple terms, this bus has 8 data fines which each transmit one bit of a byte in parallel at the same time. Additionally, lEEE peripherals in general contain some level of intelligence (Commodore ones can be very thick' at times [but they sure know when you haven't made a backup! - Ed]). The main peripheral devices introduced with these machines were disk drives and printers. At that time Commodore were chasing the small business and advanced hobbyist markets and relatively expensive peripherals were the order of the day. When CBM entered the consumer markets with the VIC and C-64, they accepted that the expensive lEEE parallel devices would not sell and devised a 'Serial lEEE' bus. This uses lEEE level signals but has only a single data line; thus a byte is transmitted one bit at a time - hey presto, slow peripherals!

In. general serial devices cannot be used on PETs. The one exception is the 700 (or B) series where a serial adapter has been produced by members of the Chicago B Users Group (C-BUG). In contrast parallel devices can be used with serial computers (Vic, 64, 128) if a suitable interface is used. I personally use a Brain-Box lEEE interface which fits into the cartridge port of my 128 and gives true parallel speed. An alternative which is probably now only available second hand is the Interpod which is a stand-alone box with serial input and parallel output. Its biggest disadvantage was that h worked at serial speed, that is SLOWLY. The other method of interfacing which I have used involved a similar system to the Interpod but with a far better interface - a PET! Mick Bignall of Microport developed 'Sipod' a serial to parallel interface which used a PET as the intelligence. A simple cable connected the serial port of the VIC/64/etc. to the User port of the PET. Software in the PET read signals from the user port and transferred them to the normal lEEE bus of the PET. It worked well and was cheap. The 64 saw only a standard serial device while the PET did all the clever stuff.

Types of Printer

As I have mentioned above the PET range used lEEE parallel printers. The disadvantages of this were mainly that Commodore's range was pretty basic and expensive. Fortunately a number of printer manufacturers provided optional lEEE interfaces for their products and indeed Epson made a 'PET' interface which did code conversion. When I set up my PET system, I chose an Epson FX-80 with lEEE card as this gave far more features than any CBM printer. An alternative route which many people chose was to buy a standard 'Centronics' printer and add an external interface to convert from lEEE to Centronics parallel. The Aculab interface was fairly common for this duty. It sat on the back of the PET and intercepted signals sent to device 4 (the normal printer address). These interfaces, whether internal to the printer, or external did not require any changes to the PET. It was also possible to drive a parallel printer directly from the User port of the PET, but this required special programming or a ROM modification inside the PET.

When the cheaper machines, came along, Commodore introduced serial printers and a few manufacturers also produced printers with built-in CBM emulation, so these were fully 'plug compatible'. However, with these computers it also became easier to intercept output vectors and diversion of printer output to the user port became a simple matter. Various manufacturers produced simple cables to connect from the user port to a centronics port. It is worth remembering that one of the two standard methods of wiring these interfaces is not fully compatible with the user port software built into such programs as SuperScript and Superbase. ( I had to take a soldering iron to my Stack interface, to avoid loss of characters with SuperScript.) At the same time a small number of interfaces appeared which convert serial to centronics. These often have a number of special features built in (my Xetec interface allows me to obtain near-letter-quality output from the Epson).

In response to Paul Blair's query (Vol 11, No 3, P 261) I have tried to use an Epson FX-80 (fitted with an lEEE interface) with both Micro-Swift and Timeworks' Swift-Calc. Using the Brain-Box to drive the printer gave continual problems, similar to those Paul describes. In the end I gave up, disconnected the lEEE card in the Epson and bought a Xetec serial to Centronics interface which solved all the problems. In Paul's case, h is not possible to convert the 136 I to Centronics, so I would advocate using either a PET with Sipod or (if he can find one) an Interpod. For both of these systems, the computer sees only a standard serial output, there is no additional code wedged in as would be the case with the Brain-Box.

Printing Lower Case

The earliest PETs powered up set to produce upper case letters and graphics symbols (graphics mode). They could be switched to display upper and lower case (text mode) by executing the statement POKE 59468,14 (this works on all PETs). The 80 column machines were recognised as being business machines and therefore powered up already set in text mode. The home computers went back to the style of the earlier machines, powering up in graphics mode. They can be toggled between graphics and text mode by holding down the shift key and pressing the CBM key. The Commodore dot matrix printers, both parallel and serial also power up in graphics mode. However both character sets are available simultaneously as in the 128.

To set the printer into text mode, use is made of a secondary address. For once Commodore almost standardised - both parallel and serial printers use secondary address 7 to get normal text. However, I did say almost!

For parallel printers the switch to text mode is made by printing to sa 7, then printing the text to the normal channel; thus:

10 poke 59468,12:rem this is for pets
20 open 1,4,7: rem sa=7 controls text mode
30 print#1: rem print to the sa to activate it
40 close 1: rem now finished with the sa
50 rem now ready to print
60 open 2,4: rem actual printing does not use an sa
70 print#2,"Hello, This is UPPER and lower Case!"
80 close 2: rem all done
90 end

OK, so it's a trivial example but it shows the method. The printer will remain in text mode until the printer is powered down, reset (use of sa=10) or set into graphics mode (use of sa=8). Use of sa=7 is the mode I always used with an 8023 printer, the only problem area is output of square brackets and the backslash when some trickery is required.

The alternative method is to leave the printer in graphics mode and prefix every line sent to the printer with a cursor down character. This works well but does mean that there is a difference in printing to the screen or printer.

Serial printers again use sa=7 but in a slightly different way. Characters sent to sa 7 are printed in text mode. The following simple example demonstrates this:

10 print chr$(14): rem this is for vic/64/128
20 open 1,4,7: rem sa=7 controls text mode
30 print#1,"Hello, This is UPPER and lower Case on Channel 7 !"
40 close 1: rem all done
50 end

I hope this has enabled those of you who have acquired PETs and printers without manuals to get a bit more out of your equipment. If you have specific queries, I will try to answer them and they may feature in this column.

Disk Recovery - Disk Discovery

I recently received a request for a copy of the PET Library Catalogue disk. In with it was a Commodore WordPro 3 disk, which the sender said would not work on his 3032 though the machine did have the WordPro ROM installed. He asked if I would check the disk and let him have a new copy if needed. WordPro was, of course, a commercial program but in circumstances like these where the member sends in a faulty master disk, I am prepared to supply a copy 9 I have one. In this case I could not provide a copy as I have never owned this program.

On looking at the disk, I discovered that the first block of the directory was corrupt, giving a #24 error. I tried the disk on both the 4040 and 157 I (with half track stepping) but neither would read the sector. The next stage was to load Precision's Super Disk Doc.

The first thing I found was that R was a DOS I disk, for the 204013040 drives. The sure way to wreck these disks is to write to them in a 4040, so I knew that attempting to re-write the faulty block (which often works) would lead to total ruination. SDD would read the disk header block (18,0) but failed to access the directory. From experience, I know that the order of sectors in the directory is 18,1; 18,4; 18,7; etc. By using SDD I was able to read 18,4 without problem and trace through the rest of the directory. A screen dump of each sector provided me with a list of the files, their starting track and sector and the length in blocks. I then tried again to read in sector 18, I and got the read error. Again from experience I knew that often it is just the last few bytes, or even the checksum which causes the problem and that the disk drive has taken the contents of the sector into its RAM but has failed to release it to the computer. By using the 'Disk Memory Read' feature of SDD I was able to scan through the RAM until I found a block which looked like the first sector of the directory. What I found was that R was complete apart from the last 22 bytes. These represented much of the eighth filename and the length of the file. From

the pattern of filenames both before and after it, I could predict the missing name and by tracing the file from the starting block I could count the length. I wrote this extra information onto the printed screen dump and was ready to start the recovery.

Normally one would recover the files by copying them to a fresh disk but with the first block of the directory corrupted, it is impossible to access flies. Instead I wrote a simple program to read a given block into disk RAM, extract the bytes one by one and write them to a sequential file on another disk. When all the bytes from one block had been read, the track & sector link pointers (first two bytes in the block ) would be used to obtain the next block. To make the program as automatic as possible I used data statements to store all the filenames and starting track & sector information from the screen dumps. By this means, I was able to recover the WordPro 3 program and 28 flies of text for the manual. However there is a difference between DOS I and DOS 2 disks. Because of minor reliability problems with the 204013040 disks, when Commodore bought out the 4040 with DOS 2, they slightly changed the disk format by reducing the number of sectors on tracks 18 to 24 by one. It is generally stated that these disks are read compatible between the drives. This is not strictly true.

What I found was that using direct access programming ( ie: block reads) I could not access sector 19 on tracks 18 - 24. On both the 4040 and 157 I drives I got a #66 'Illegal track or Sector' error at every attempt to access them. Five of the text files used these unobtainable sectors and hence I could not recover these files. The solution was obvious - use a 3040 to read these files. Problem I don't have a 3040. By coincidence I had just had a request for a Library Catalogue for a 3040 drive from someone a few miles away. A quick phone call arranged for the loan of the 3040 for an evening.

Only when I got the drive home did I discover that it, like my own drive, bore a label on the outside which said it was a 3040 but the ROM set had been upgraded to 4040. Desperation was now setting in! A phone call to Mick Bignall secured the loan of a set of 3040 ROMs. Within a couple of days these arrived and my 4040 was duely downgraded back to a 3040.

At this point a further problem arose. There is a bug (only one!) in the 3040 ROM. Using block-read and then GET corrupts the first byte of the block. The first byte is the track link, so is important for tracing through the file. Mick later recommended using a direct memory read of the disk RAM to extract the information once it has been read in by the block read. A further investigation with SDD and a bit of guess work allowed me to obtain a list of the file chains for the five files. It was then simple enough to modify the program to allow the track link to be ignored in favour of one put in from my list. Finally I had all the
flies transferred to another disk.

Having consistently failed to read the extra sector on my drives, I made up a 3040 disk with files extending into these sectors. To my surprise I could read all the files on both 4040 and 1571. It appears that there is some very clever coding in the ROMs. Although direct access will not work, file reading does not check whether the required sector is in range, it just goes ahead and reads ft.

Throughout this article I have referred to Block-Read of the disk. I should point out that the 'B-R' direct access command has odd effects and to perform a block read the 'U1' command should be used on all drives.

Keyboard Lock-ups

Mike Kingsley wrote to me sharing his recent keyboard lockup problem. He writes:

"Over the years my set up has grown to include a C128, 1570, Excelerator Plus, DPS1101, 'MPS801, 1520, MPS1200, a C64, 154 I and a Tandy Monochrome Monitor wired to 40 or 80 columns (another story in itself ).

" I have been using my 128, 1570, Exelerator + C2N cassette, MPS1200, Tandy monitor and two joysticks (one with an extension lead) for some time now and every now and again certain keys would not work with Superscript but ft was intermittent. Computer getting past it I thought.

"Then I found some commercial programs and games played up but would work on the C641154 I combination (keyboard hanging up usually on the 128). I then found that some games ie. 'Gunship' that used to be ok. now would hang up the keyboard.

"First step was to check disk drive alignment - no problem found. Then a process of disconnecting the drives not in use, the monitor going back to using the TV. Disconnecting the printer, using the 154 I - no change found.

" Only when I disconnected the Joystick extension lead after reading a comment about 110 problems affecting the keyboard in the magazine was the problem solved.

" My 128 now behaves perfectly with both joysticks connected and everything else re-connected provided the joystick extension is not used even though there is no fault on it that I can find.

*The only problem is I no longer have an excuse to buy a replacement ie. an Amiga.

" I hope this may be of use to some members who are having similar problems."

Texas Trip

Readers of Betty Clay's `Texas Tales' may have noticed that last time she referred to a forthcoming trip of mine. My brother Chris and I spent a fortnight in the USA at the end of May (hence my non-appearance at The Show) including four delightful days in the company of Betty and Richard Clay. Although Betty is our correspondent on things Amigan, Richard is the real power computer user in the household - his machine is a Super PET (SP9000).

Computers took a fairly low profile throughout the trip but we were glad to meet Don Kassebaum at Austin and have a brief tour of the Computer Centre of the University of Texas, though we didn't get to see the Cray. Later on at San Antonio, we were unable to visit La Villita (a craft village) while it was open. This was unfortunate as I had particularly hoped to get to see the glass blower. Not so much because of the glass-blowing but more because he is Larry Williams - a PET man, who if I recall correctly used to write for Compute.

I must take up a couple of points raised by Tim Arnot in his piece "Tim's Trip to Texas" Vol 10, No 6. Like Tim we found Tex-Mex food addictive and we discovered that as Tim reported they do put limes into their beer. But think about it; American beer is very like lager; Lager & Lime is quite a common drink here. OK, so the Mexicans use real limes, not lime juice. [Ah, yes, but the Mexicans have a beer which is very close to Bitter, & this is what I had with limes in! - Edl

Whilst talking of drink I must mention the beverage which we found totally addictive but which Tim tried once and would not touch again. I refer to iced tea. We were introduced to it by Betty and Richard and trying it first unsweetened were not impressed. However once sweetened it was delightful and became number one choice with all meals. In fact later in the holiday I was quite put out when a cafe did not have iced tea and we had to make do with beer.

TOP