MULTITASKING. A LITTLE THEORY.
(C) DENIS TOKARCHUK
A LITTLE INTRODUCTION. HOW MUCH I ASKED THE VERY RESPECTED CITIZEN KILLEGHAM
QUICKLY WRITE AN ARTICLE WITH YOUR IDEAS ABOUT IMPLEMENTATION
MULTITASKING ON THE SPECTRUM - ALL WITHOUT RESULTS. TODAY ALREADY
IT'S THE 19TH, THE TIME IS 10 PM, AND THE MEMORY KILLER IS STILL NOT AVAILABLE AND, UNFORTUNATELY,
WILL NOT BE. WELL, KOLYA, YOU ASKED FOR IT - NOW READ MY
AN ARTICLE WITH VIEWS THAT YOU KNOW YOU DON'T LIKE VERY MUCH
SOUL :))). YES, READERS, THE THING IS THAT I HAVE MORE
TRADITIONAL VIEW ON THE IMPLEMENTATION OF THE LITTLE REALIZABLE (!), AND AT
KOLYANA HAS MORE EXOTIC THINKING ON THIS POINT. ONE ZERO IN MY
BENEFIT. KILLEGAM, WILL YOU EVEN THE SCORE?..
ACTUALLY THE THEORY... I DON'T KNOW WHY, BUT ABOUT THIS THING AS MULTITASKING,
SPECTRUMTHE MEDIA PREFERRED TO KEEP SILENT. IT IS NOT
IT IS WISE - MORE OR LESS NORMAL OPERATION OF THIS, SO SAY,
CONVENIENCE IS DIFFICULT TO ACHIEVE WITH THE POWER OF THE SPECTRUM. IT'S GOOD
IF THERE ARE 7 MEGAHERTS, CACHE AND RAM AT LEAST S12 KILOBYTES - HERE STILL
WE CAN ACHIEVE SOMETHING, BUT UNFORTUNATELY WE STILL HAVE
NOW THE MOST SITT ON 128-X PENTAGONS WITH 3.S MEGAHERTS,
A MUSICAL, WELL MAYBE ALSO A KOVOX. BUT EVEN IF PRESENT
HYPER ADVANCED SPECTRUM WITH HOUR METERS OF RAM, WITH THE FASTEST
WITH A TURBO UPGRADE AND WITH A 128 KILO CACHE, WE ARE COMING WITH MORE
THE BIGGER PROBLEM IS THE SOFTWARE, OR MORE PRACTICALLY THE OS,
WHICH COULD PROVIDE MULTITASKING... BUT THIS
THEN, AND NOW LET'S CONSIDER THE 'MULTITASKING' OPTIONS THAT
WE WOULD BE ABLE TO BE INcarnated ON SPECKY.
'NON-PARALLEL' (CO-OPERATIVE) MULTI-TASKING. SO,
IMAGINE A BUNDLE OF PROGRAMS THAT YOU CAN QUICKLY ACCESS
CONTACT THROUGH SOME MENU, TRANSFER BLOCKS OF DATA FROM ONE
PROGRAMS TO ANOTHER WITHOUT ARISING CONFLICTS
STANDARDS. THIS IS NON-PARALLEL MULTI-TASKING - ON
MY HUMBLE VIEW IS THE MOST LIKELY TO BE IMPLEMENTED ON OUR
SPECKY, BUT WITH THE CONDITION THAT THE MEMORY IS AT LEAST A LITTLE EXTENDED. EXCEPT
YOU NEED TO WRITE 'MOVABLE' PROGRAMS, BUT NOT HERE
DOING WITHOUT LANGUAGEHIGH LEVEL, LIKE ASSEMBLY
IT IS DIFFICULT TO WRITE A RELOCABLE LARGE PROGRAM
(THE PROGRAM IS AT LEAST A TEEN IN COMPLEXITY). ALTHOUGH THERE IS
ANOTHER EXIT - SINCE THE PROGRAM IS STILL PASSIVE WHEN WORKING
OTHER, YOU CAN 'EXCHANGE' THEM BETWEEN ACTIVE AND PASSIVE MEMORY
(BUFFERS) DURING ACTIVATION OF ONE OR THE OTHER; HOWEVER, WITH THIS
IN THE SCHEDULE, A HIGH DATA EXCHANGE SPEED IS REQUIRED (HERE
AND THE CACHE WILL BE USEFUL, WHERE, AS IS KNOWN, 7 MEGAHERZ (IN THE TURB)
FULL).
'PARALLEL' MULTI-TASKING. AND HERE IMAGINE THIS
PICTURE - A FLOppy DISKET IS FORMATTED, WHILE MUSIC PLAYS,
THE PRINTER IS PRINTING, A CARTOON IS PLAYING ON THE MONITOR IN A LARGE WINDOW,
MEMORY CALCULATES THE SINE FOR THE NEW DEMO (AND ALSO DISPLAYS
FORMULA OF ABSOLUTE FUEL :)))), YET YOU ARE IN SMALL
IN THE WINDOW, JUST BELOW THE CARTOON WINDOW, YOU PROGRAM SOMETHING IN
ALASME. AND ALL THIS AT THE SAME TIME AND WITHOUT BRAKES! FOR SPECTRUM
THE PICTURE IS ABSOLUTELY UNREAL (WHAT IT IS TRYING TO REFUTE
KILLEGAM). IN PRINCIPLE, AS FOR THE SAME PUSS. FOR IMPLEMENTATION
THIS WONDERFUL MULTITASKING MODE IS NEEDED AS A MINIMUM
MULTIPROCESSORITY. WITHOUT HARDWARE 'SUPPORT', IMPLEMENTING
(SO MUCH WORD FORMS CAN YOU IMAGINE! :) ) ALL ONLY ON
SOFTWARE LEVEL,FREAKS TYPE SHIPDOSHS COME OUT WHERE
THIS IS ONLY A PATHETIC AND SCARY PARODY OF MULTITASKING.
'MIXED' (NOT FUNNY, BUT MIXED :)) MULTI-TASKING. AND THIS
SOME COMPROMISE. IT SEES LIKE THIS TO ME:
TWO TYPES OF PROGRAMS ARE WRITTEN (UNDER A SPECIAL OS, NATURALLY) -
ONE 'FAST', DOES NOT REQUIRE LARGE TIME EXPENDITURE AND
FEATURED IN ONE INTERRUPTION (KEYBOARD POLLING (OF ITSELF),
ALL OTHER MANIPULATOR DRIVERS, AU MUSIC, OUTPUT
ARROWS, SOMETHING ON THE SCREEN, ETC.). THE MAIN FEATURE OF THESE
PROGRAMS, LET'S CALL THEM PROGRAMS OF THE FIRST KIND - THIS IS WHAT THEY ARE
WORK ALL THE TIME, REGARDLESS OF WHAT YOU DO
(YOU CAN ALSO CALL THEM 'BACKGROUND' PROGRAMS). SECOND PROGRAMS
KINDS ARE BULKY PROGRAMS WRITTEN TO BE EXECUTED
ANY LARGE AND COMPLEX TASK, BUT WHICH IS AT ANY TIME
YOU CAN STOP (EXACTLY WITH THE HELP OF A 'BACKGROUND' PROGRAM,
WHICH, SITTING IN INTERRUPTION, CAN EASILY MANIPULATE
QUICKLY TAKE CONTROL). ADVANTAGES OF SUCH IMPLEMENTATION
MULTI-TASKING IN FACE - WE GET A LOT OF CONVENIENCE: FAST
TRANSITION TO ANY OF THE ACTIVATED (INSTALLED) PROGRAMS
SECOND TYPE (MAIN), POSSIBILITY TO INCLUDE INTO 'BACKGROUND'
HAND WRITTEN PROGRAMS (E.G. SCREEN OUTPUT
TIME, LOGO ROTATIONCOMPANIES, ETC.). HOWEVER, THERE ARE ALSO DISADVANTAGES.
THE MOST BASIC, IN MY VIEW, IS THE APPEARANCE OF HIGH DEPENDENCE
THESE PROGRAMS FROM THE OS, WHICH, AS IS KNOWN, WAS NOT ESPECIALLY INHERENT
SPECTRUM - AFTER OUR PROGRAMMERS ARE CHASING FOR SPEED AND THEIR
IT IS NOT IN THE HABITS OF DEPENDING ON THE OS, WHICH IS NOT WISDOM AT LOW
THE CLOCK CHARACTERISTICS OF Z8O, AND THE WRITTEN OS' PROCEDURES ARE NOT
THEY CAN BRAG OF HIGH SPEEDS... BUT IF YOU WRITE AN OS
WEIZED AND THOUGHTIFUL, THEN IT IS COMPLETELY POSSIBLE TO BYPASS THESE 'SPICY'
ANGLES'...
I (DShT) TAKE THE STARTING POINT IN SEARCH OF COMPROMISE
EXACTLY THE LAST TYPE OF MULTI-TASKING. LET'S TALK ABOUT THE OS.
OF NATURALLY, YOU WILL HAVE TO WRITE A NEW ONE. IT'S BETTER THAT SHE (OR
PART OF IT WAS SWITCHED INTO ROM. OLD SAME OS AND DOS (VASICH8+TG-DOS)
YOU WILL HAVE TO LEAVE AND REPLACE BASIC128 WITH A NEW SYSTEM. YES WHAT
I'M WRITING ABOUT THIS - A DOZEN OF FIRMWARE ALREADY WRITTEN IN BASIC128
(GLUK, PEOS, ETC.) AND PROGRAMS ALMOST NEVER FEEL
THE ABSENCE OF 128TH BASIC, WHICH IS TO OUR HANDS.
NEW OS (MULTITASKING OS - HERE WILL BE SHORTENED
ITS MOS SHOULD BE FLEXIBLE, SMALL IN VOLUME AND WITH MAXIMUM
OPPORTUNITIES. IT WILL BE VERY GOOD IF THERE IS A SETUP - OR REMOTE (ON
EXTERNAL STORAGE DISK), ORWIRED INTO ROM (THEN PRODUCED)
THE AUTHOR MUST CUSTOMIZE SET FOR EACH SPECIFIC USER
IR WHERE 'UNIDENTIFIED' DEVICES WILL BE INDICATED - COVOX,
SOIPDHIVE, AND POSSIBLY MEMORY). IF THE SECOND METHOD IS CHOSEN, THEN
THE OS MANUFACTURER WILL RECEIVE SOME GUARANTEE OF THE PAYBACK OF ITS
PRODUCT, BECAUSE THE SETUP INFORMATION IS POSSIBLE SOME WAY
ENCODING WITH USER NUMBER AND THEN RELEASED
MAINTENANCE PROGRAMS (WHICH, AS IS KNOWN, ARE THE MOST
REQUIRED) CHECK THIS INFORMATION AND, IN CASE OF 'INCONSISTENCES',
SEND AN UNREGISTERED USER TO SUCH MOTHER :).
NATURALLY, THIS WILL NOT SOLVE THE PROBLEM OF PIRACY IN
ITS ALL-ENCOMPASSING SUPER SCALE (HOW IT’S TWISTED!!!), BUT
AT LEAST FOR A SOME TIME IT WILL COOL THE DUST OF HANDMADE HACKERS.
MOS FLEXIBILITY SHOULD BE THE CAPABILITY TO 'TURN OFF'
SYSTEM COMPONENTS, UP TO POLLING THE KEYBOARD AND CALLS TO
DISC. THIS IS NECESSARY TO 'ADJUST' THE SYSTEM TO THE PROGRAM SO THAT
EVERYONE WAS COMFORTABLE. BUT THERE IS A DANGER OF POWERFUL
A FLOW OF VIRUSES THAT CAN COMPLETELY CONTROL THE SYSTEM
(THEY WILL BECOME VERY SMART, BECAUSE THEN THERE WILL BE NO DICTATE ANYMORE
TG-DOS'A AND VASISCH8).
IN ADDITION, IT SEEMES TO ME IT IS NECESSARY TO 'SEW' INTO THE ROM
LANGUAGE COMPILER, BUT NOT BASIC ORSI, NO PASCAL, BUT NEW
(I HAVE MY OWN THOUGHTS ON THIS THING) WHICH WOULD BE
OPTIMAL, ADJUSTED TO THE FEATURES OF IRON (SPECKY). And
IT IS OPTIONAL THAT THIS COMPILER READ ENTIRE COMMANDS (THIS
SLOWS ITS WORK), AND PERCEIVED A SPECIAL CODE (SUPPOSE,
RGIPT TEAM - #OO,#OO,...TECHT...,#OO). AND THE EDITOR OF SUCH A LANGUAGE
(WHICH, NATURALLY, WILL BE EXTERNAL) WILL ALSO BE DONE
COMPILING, BUT INTO THIS SPECIAL CODE. AGAIN, NECESSARY
POSSIBILITY OF 'DISABLE' AND 'REPLACE' LANGUAGE COMPONENTS (COMMANDS) AND
ASSIGNING THEM NEW QUALITIES. ALL THIS KOTAVASIA IS NECESSARY FOR
WRITING RELOCABLE PROGRAMS AND DRIVERS (FOR
MULTI-TASKING, NATURALLY)...
(TO BE CONTINUED POSSIBLY TO FOLLOW...)
YOU CAN WRITE TO MOS ACCOUNT FOR A VERY LONG TIME, BUT WHY WHEN THESE IDEAS
THEY ARE NOT IMPLEMENTED, AND IF THEY APPEAR, THEY WILL NOT BE IN DEMAND? :(.
IN GENERAL, IF YOU ARE INTERESTED, YOU CAN WRITE TO THE EDITORIAL AND
EXPRESS YOUR THOUGHTS ABOUT THE NEW MOS. MAYBE SOME OF THE
PROGRAMMERS AND ARE INTERESTED (KILLEGAM, AU-AU-AU!!!).
* * *
Share your thoughts about the article