This column will answer questions of general interest about the Oliger 2068 Disk I/F and JLO SAFE DOS. If you have questions you feel other users of this system would like to see answered, send them to me at: 11601 Whidbey Dr. Cumberland, IN 46229. Because my schedule can at times be simply too demanding to always find the time, I cannot promise to ALWAYS have this column ready for each new issue of Safe Disk Up-date. I will only do the best I can…
-John L. Oliger
What is the latest version of SAFE and what new features does it provide?
The current version of SAFE as of today (1/25/88) is V2.41. The last commands added to SAFE were the MERGE command, the SAVE //”Filename” command, and the NMI “N”EW key function. The MERGE command is a simplified but very fast merge that appends additional Basic code and variables onto an existing Basic program. The SAVE //”filename” command is an alternate method of saving to disk that by-passes the “FILE EXISTS!! 5 SECONDS TO ABORT” warning message. It is intended for use where a file overwrite is expected and the delays caused by the warning message are not desired. The NMI “N” key function allows a complete reset of the computer very easily w/o having to turn off your computer. It is like adding a reset switch without physically installing the hardware.
How much does it cost to update my SAFE V2 eprom?
I charge $5.00 if you return a SAFE eprom to be recycled or $10.00 if you do not. This is for all lawful owners of SAFE V2. SAFE V1 owners can upgrade to the latest SAFE V2 by sending $10.00 in addition to the above. This is a one time payment for the V2 software. I feel the $5.00 or $10.00 is about the cost for post/pack/handling and possibly the cost of another eprom. Thus, once you have SAFE V2, you are NOT charged for it again. All prices listed above include postage. If you wish defaults of other than 40 track, double sided, 6ms head step, ASCII COPY /, then you need to specify when ordering.
I own the Oliger 2068 Disk Interface W/JLO SAFE and use an AERCO printer interface with the Olivetti PR2300 ink jet printer. I have tried to use the built in SAFE printer driver and screen copy routines with my set-up without success. Can you help?
The Olivetti PR2300 printer and Aerco printer interface, used together, are NOT directly compatible with the printer driver and screen copy routines built into SAFE. The Oliger 2068 Printer I/F and Olivetti or most other combinations of Aerco I/F and printer work without a hitch. The trouble with the Olivetti/Aerco/Oliger Printer driver combination is caused by the way the Aerco I/F itself requires the software to finish toggling the printer’s STROBE NOT line by reading the port again immediately after writing something to it, which the Oliger software does not do. The Oliger I/F does not require the software STROBE NOT read toggle. The fix for this is a simple modification to the Aerco I/F board itself, which will make it self-toggle and as such cause it to work with any combination of driver/printer you may have.
To perform this modification to your Aerco Printer I/F:
1)Cut the pc board trace going to pin 11 of the 74LS10 chip, right by pin 11.
2)Install a jumper wire from the 74LS10 pin 11 to the 74LS02 pin 5.
I have the latest version of SAFE (V2.41) and find that sometimes the new “N”ew NMI reset function does not work, but other times it does. It seems it usually won’t work after it has previously been used. Is something wrong with my board or new SAFE eprom?
There is nothing at all wrong with your hardware or firmware. This is just a peculiarity in using this function in the way the hardware is designed. It is caused by holding the NMI button down too long when pressing it for the new reset. The correct procedure for using the new reset function is to hold down the “N” key and then to give the NMI button a short press (just a tap) to cause the reset. If the NMI button is held too long, the reset function will simply not work the next time it is tried, unless an error or anything that activates SAFE happens before then. When “locked-out” like this, no harm other than it not working again will occur.
After a <BREAK> key press during disk operations, I find the only way to get back to default settings is to turn both the 2068 and disk drive off then back on again. We need a way to clear SAFE and anything the 1770 is doing without losing everything. Any ideas?
You’re assuming incorrectly here. If you BREAK during a disk operation and a return to Basic is made, SAFE has already taken care of all this as much as it can! SAFE is in good shape to do whatever you want, and has sent a command to the 1770 disk controller to abort whatever it is doing. What you are seing happen is that the 1770 chip itself HAS stopped everything it was doing, EXCEPT that it will keep the drive motor turned on until it sees several rotations of the disk. If the drive selected does not contain a disk or has its door open, the 1770 will leave the motor on forever because it hasn’t seen the disk turn its allotted number of times. All you need to do is insert ANY disk into the drive or use the <LET /D=n> command to select a drive that IS on-line with a disk installed. Then the 1770 will see the disk turn a few times and stop the motor. Any write operations you might have started and broke into WILL NOT OCCUR because SAFE aborted them and told the 1770 to abort too. ALL disk systems that use the motor control function of the 1770 have this same quirk, because this is how the 1770 itself does it. There is NO software command to stop the motor, just let it see the disk turn and it will stop itself!
I get occasional “TOOTS” when using the MOVE/ command within a Basic program, but I don’t seem to when I use it in direct mode. It appears to toot when the source light is on, as if SAFE is trying to read before the head has fully settled. What’s wrong?
Your disk set up is marginal if you get these warning toots, period. Try relocating your drives and/or rerouting the disk controller cable. If you tried the slowest head step speed and it STILL does this, then the problem is NOT in SAFE trying before it should. Most problems of this sort are found to be caused by interference and are usually cured by rearranging the drive and cable’s placement. The problem occurring within a program rather than in immediate mode is coincidental. SAFE has no idea if the statement is immediate or within a program and the exact same code is executed either way. More likely you do the move more often using the program you mention so the odds of the error occuring is greater.
You say SAFE will allow from 10 to 255 tracks per side of the disk? What kind of drive, if any, allows more than 82 tracks per side?
None of them do, at least right now. But if tomorrow the drive manufacturers doubled the amount of tracks allowed per side from 80 to 160, SAFE would be able to use the extra space immediately! It happened before when they went from 40 track to 80 track drives. It is VERY possible it will happen again in the future as drive manufacturers become better at making the disk stepper motors and heads. As far as I know, SAFE is the ONLY DOS around that is flexible enough to allow this. Most others would require substantial revisions if it would be possible at all!
I see no real benefit in having the variables load in along with the MERGEd program, and I think it would be better if the LOAD /”name” VAL command cleared out the old variables before loading in the new. Any comments on this?
Because of the way MERGE was added to the SAFE code in the eprom, and because a regular Basic program DOES contain variables in a normal SAVE on the 2068, it used MUCH less eprom code space to have MERGE load in the variables too, rather than just the program. Any subroutine saved to disk to later be merged into a master program should have its variables removed by using the CLEAR command before saving to disk, unless these variables will be needed by the main program. The reason LOAD /”name” VAL doesn’t erase existing variables is to make the command more flexible. Use can always CLEAR and the load a VAL type file to get only the new variables the way it was implemented. If it always cleared the old variables you would HAVE NO CHOICE and flags used by a running program that might be needed would be lost.
SAFE supports several different printers with its COPY/ command. I feel that we don’t need several different copy routines, but only one. Why don’t you remove these routines to open up more code space to implement new commands?
Most users of this disk interface feel that only one or maybe two of the several copy routines are needed in SAFE. Only trouble is, each feels that the one that supports his printer is the one that’s needed, not the other. The next guy thinks it should be a different one. It would be much too complex to install a different copy routine in each different SAFE eprom I program. This would waste more time than if I devoted the same energy to making portions of the code more efficient and opened up a little room this way. The simple fact is that most people LIKE the ease of using the COPY / command or the NMI copy function. I do myself! If I took it out, I feel there would be a definite loss…
What is the purpose of the slide switch (SW1) right next to the NMI button on Disk Board B? Only reference I have come across is step 5 on page 4 of the Oliger Disk I/F User’s Manual.
This switch is only on the “REV A” disk board B. It was intended to be used to switch between the two 8K “halfs” of a 27128 eprom. The idea was to have my own JLO SAFE DOS on one half (active when switched in the right “SA” position) of a 27128 eprom and Ray Kingsley‘s OKDOS (active when switched to the left “OK” position) in the other half. If switched into SAFE from OKDOS, you were to use the RESTORE /S command to initialise SAFE without a reset. Ray was going to have a similar command to initialise OKDOS when going from SAFE. Only trouble with all this is that Ray never did finish his OKDOS, and its been a year and a half since I’ve heard from Ray at all. I am sure now we will NEVER get a complete OKDOS from RAY, which is really a shame because he had most of the core of the DOS complete, needing only to tie in the DOS to Basic. Oh well, we all go on. I believe Ray didn’t think he would get back financially what he would have needed to put into the DOS in his time, to make it worthwhile. He may NOT have…
SAFE BUGS that are not BUGS- ed
Seems that I have a blank page to fill, so will give this gem to the SAFE SDOS section. Ole John must dread getting letters from my house, but he’s right prompt on answering them. Some of the questions that he has answered in this section came from you know who. And you know what? John does have answers! The rest of this will outline a problem that 80 track disk user may have encountered as I did. What happend was, I got a Disk back that had several files glitched up. Checking the balance of my pre-recorded disks, I found all of the 40 track disks were OK, but ALL of the 80 track disks had the same glitched files. Now that aint good for me reputation! Thankfully only one of them 80 track buggers had been sent out. This sneaky bug only occurs when the 80 track disk “is more than half filled”.
I got my Master 80 track disk out and began to copy it. Now my drive set up is Three 80 Track disks as drive 0, 1, and 2, with a 40 track as drive 3. So it is easy to use drive 0 and 1 for copying with the MOVE/ function. How do I copy 40 track disks? Well I just remove the DATA cable from the SAFE controller, and plug on the data cable of another drive system that has 4 40 track drives and use MOVE/.
But, using the Master 80 track disk, the first MOVE/ resulted in the same files being glitched. Funny thing, when I LOADED a program from the Master disk and did this number: LET/d=1: SAVE/”title”, the warning toot would sound, then the program would SAVE A-OK. So, your scribe did MANUAL transfers of programs to about 10 disks. Ah Ha! I figgers, I got ole John now! So I packed up a copy of the master and a glitched up disk and sent them off to him. John’s reply came bouncing back. Now I’ll quote:
1. The trouble you are having with MOVE/ is caused by how this command itself works. MOVE/ is a carry over from SAFE V1. It depends upon the Number of Tracks to be MOVED and the Number of Sides to be MOVED “as set with the LET/t=n and LET/s=n commands”. The MOVE/ is using the DEFAULT value of 40 as is set in the SAFE EPROM. So, it is moving only the first 40 tracks to the destination drive. But, the entire Catalog, and the Pointers are being moved “because they are stored on track zero”. But the DATA that is being pointed to will not be there after track 40.
2. The cure is easy. Just preceed your MOVE/ command with LET/t=80 when MOVING/ between your 80 track drives. You can think of the MOVE/ command as being dumb because you have to tell it to disregard the default parameters (40 track and 2 sides), while MOVE/”file name” is smart and can figure this out. I need to explain this better when I revise the manual. END QUOTE.
Durn! I thought I had him! But ain’t John nice? He could have just told me I was dumb instead of saying his MOVE/ was dumb. Oh well! Funny thing is, I had made a DISK COPY program that repeatedly uses MOVE/ to copy disks between any track combination of drives AND I INCLUDED the LET/t= and LET/s= commands. Then when doing the MOVE/ in the direct mode the LET/ was left out. I didn’t think I needed the LET when operating with two drives having te same number of tracks.
I have some more space to fill so will do it with programming. Here is a way of using the disk catalog as a MENU to select a program to load. <100 CAT/: INPUT “Key in TITLE of Basic Program”;a$: LOAD/a$ >. You can embellish this with optional selection of a different drive, as: 100 INPUT “Enter drive number”;a: LET/d=a: CAT : INPUT “<1> Basic or <2> Code Program?”;b: INPUT “Enter Title only”;a$: If b=1 THEN LOAD/a$ > <110 IF b=2 THEN LOAD/a$ CODE: GO TO menu >. In both examples, a INPUT prompt is printed to the Catalog Screen at the bottom area and you are using the catalog data for information.
Here’s another bug that ain’t a bug. Quite often I’ll FORMAT a 40 track disk to 41 tracks in order to cram more programs or data into the disk. Once I tried MOVE/ to copy such a disk, and it didn’t work. The reason was that the destination disk was formatted to 40 track. Thats like trying to walk on two straight lines at the same time. Incidentally, you CAN FORMAT a 40 track disk to more than 42 tracks, say 50. The disk directory will show the DISK FREE space as if you have 50 tracks, but the figure will be erroneous. All that I have ever been able to stuff into a 40 track disk is the contents of 42 tracks. The diskette manufacturers only guarantee the space for 40 tracks. On 80 track disks one can usually format 82 tracks (80 guaranteed). The practice of formatting extra tracks isn’t advised because the read – write head is extending beyond the disk drive mechanical range as well. 41 and 82 might be safe enough, but beyond that is pushing it for a little bit more data space. Why not wait until one of them new 250 track disks comes out. Then we can use the range of SAFE that John provided, though the disk capability did not exist.