Jiffy DOS software implementation

Started by Hydrophilic, November 30, 2009, 08:24 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Diddl

#25
Quote from: Hydrophilic on January 09, 2010, 07:25 PMI will look at OPEN some more.  From what I am thinking (please note I have had many drinks tonight), OPEN will send Jiffy protocol request so that future commands, like Talk or Listen, will be with Jiffy speed.  This is not very important for programs that use small transfers with Open.  For example, a program that does OPEN then PRINT#15,"S0:FILENAME" will not have a good benefit...
No, - PRINT#15,"S0:FILENAME" is the ONLY thing will be speed up by supporting OPEN vector.


This Commodore vectors (open, chkin, chout, bsout, basin, clall, clrch) are at a higher level as IEC routines (TALK, TALKSA, LISTEN, LISTENSA, UNLISTEN, UNTALK, IEOUT, IECIN).

for example OPEN does a: LISTEN, LISTENSA, IEOUT ... , UNLISTEN

A PRINT# does same: LISTEN, LISTENSA, IEOUT ... , UNLISTEN

A INPUT# does: TALK, TALKSA, IECIN ... , UNTALK


Jiffy does automatically recognize if partner device could do Jiffy or not. This is done in TALK and LISTEN procedure by setting a flag.

You see, not to support OPEN vector has nothing to do with further PRINT# or INPUT# statements. Only sending the filename is speeded up by supporting the OPEN vector.

My measurements shows to supporting OPEN vector has nearly no benefit. So I decided to support neither the OPEN nor the CLOSE vector.

I agree your solution is cleaner than mine, but I want to hold the code so small as possible cause VIC has very less memory.