Post - Forum - Plus/4 World



	Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum	Login

Forum Help

Post Your Message

Previous Messages

Posted By

SVS
on 2002-12-29

Thank U 4 the info!

Even if I've not test recently, I can assure you that with a 1551 things are even better: in fact more operations allow the continuing Plus4 processing, while they are going to complete on the drive unit.
I remember the initializating routine for example: on 1541 you have to wait for its completion to send another disk command (i.e. DIR); on 1551 you can quitly write it *while* the drive is self initializating; the command is stored in the buffer, and then executed when unit is ready.

Bye

Posted By

JamesC
on 2002-12-27

SVS --> (Re Diskette access times)

I did some experimenting tonight with my 1570 and Plus/4. The 1570 should power on to 1541 mode when connected to a non-burst machine (128/128D are burst machines).

HEADER takes 74 seconds, a 15% improvement over the 1541, but that wasn't my experiment.

HEADER a scratch diskette and notice that the READY prompt does not come back until the header is complete on the disk drive. Playing with TI$ shows that this takes 4 jiffies.

Then run this short program and notice the difference:

10 TI$="000000"
20 OPEN 15,8,15,"N0:HEADER TEST,WM"
30 PRINT "[SHIFT-HOME]"TI
40 PRINT "[HOME]"TI
50 GOTO 40

Press the STOP key when the 1541 light goes out. My 1570 took 45xx jiffies.

But this program proves that the computer can and will continue with a program while the disk drive does something else. This is the whole point of an intelligent disk drive with its own processor.

COPY will issue a command to the disk drive and then move on, but the other disk commands SCRATCH, etc will wait for the disk drive to complete. Not so with printing to the command channel.....

The system has to wait when you do a PRINT DS$ also, so if you are sure that the files exist and there is nothing that can go wrong, you can skip that step and move your program right along.

Obviously when you are doing direct-access commands like block-read, etc, you will want the program to wait for the disk drive, so this example does not apply to advanced disk drive programming.