M.M.A/SPEED CO.'97
The problem of launching files from disk has always interested both ordinary users and programmers. It would seem that there is no problem at all - found the file and launched it with the command RUN "GLUK". But no, even this seemingly primitive process has been automated!
Some cunning programmer at TECHNOLOGY RESEARCH implemented a function in TR-DOS, thanks to which the command LOAD or RUN (as well as POKE and PEEK) without an operand launches a basic file named "boot". Apparently, with this action, he wanted to atone for his guilt over the extremely left coding of the disk system itself. Thus, programs began to emerge that allowed to facilitate the selection and launching of files from the directory in one way or another.
Below, I want to present a number of my (and not only my) thoughts on the development of BOOT construction and some of its modern trends. It is especially recommended for reading to those novice programmers who have already outgrown modifying someone else's loaders and want to try to write something unique - boot-like!
To begin with, let's take a look at what has already been done in this area during the time that SPECTRUM has existed in the vastness of our boundless ZX-USSR. But first, it is necessary to draw a clear line between a boot program and a file commander. Let's consider that any program that allows launching files from disk will be called a boot. If this program has a hint of copying information, then it is already a commander. The topic of the ideal file commander is also very interesting, but we will leave its discussion for the next issue of the magazine. And now: "Back - to the future!".
So, the history of boot construction in Russia began with the appearance of the first samples of BETA DISK INTERFACE. I, and probably no one else, have seen any Western boot. And the only branded program designed for TR-DOS was DISK DOCTOR.
As soon as domestic programmers woke up from their slumber, the first homemade creations on the topic of boots began to emerge. The first such programs were written according to the following principle: a collection of games was compiled, the names of the programs were embedded in the DATA line in BASIC, and then, by entering the program number or selecting it with a wildly twitching cursor (also naturally from BASIC), one could finally launch the beloved file. This method was interesting also because often programs on such disks were protected in the following way. All BASIC and CODE files were renamed to an alphanumeric combination. Then the files on the disk were shuffled intensively, and it was difficult for the ordinary user to understand which file was which game and what code blocks it needed to work. The output of the directory was prohibited by entering non-printable characters into the disk name.
As you can see, the boot became not just a means of automation but the only way to achieve the goal in the fight for launching a file. Moreover, the user could not use such a boot for their own purposes by rewriting it to another disk, as all the names of the launched files were initially stored in the boot.
But time passed, and the first samples of real boot programs began to appear. Their emergence was also hampered by the fact that traditional BASIC means could not read the zero track containing file information into memory. Having mastered the basics of TR-DOS, the first programmers brought the first real boots to life! Most of them still consisted of 80-90 percent BASIC and several machine code procedures for working with the disk. This stage of development is characterized by the emergence of one of the fundamental principles - file selection is made by the cursor, which requires only 5 keys or one joystick to control.
The next key step was the writing of 
fully assembler 
boot programs. One of the 
most famous such boots was written in 1991. 
The author was most likely someone M.RUSALOV, 
and since this boot 
was very much liked by our hackers, only the laziest among them did not create their own version of it. It is worth noting that when there were more than 20 BASIC files in the directory, this program did not work and displayed the message "No more 20 files". This seemingly purely technical limitation later turned into the theory of game boots (i.e., special boots for disks with games).
An interesting idea was proposed in the boot from 
TOLLYSOFT'92,where the selection 
of files occurs 
in a window, very 
similar (actually a copy) to the menu window in machines with 
128KB of memory. Moreover, 
this boot took only 5 sectors! Thus began another epic in the creation of boots - minimizing program sizes.
In the same 1992, Shi-Soft released a quite convenient boot sized at two sectors. In fact, this program set a record that was impossible to surpass. And only in 1995/96 did our Samara hackers POLTERGEIST and MAXSOFT manage to implement a initially primitive, and then a fully functional version of a one-sector boot!
The situation in the boot construction market experienced some stagnation until the truly epoch-making creation - ZYX BOOT appeared. This program effectively laid the foundation for the modern concept of BOOT-DEMO. Here was everything that an ordinary user could dream of!
Like any other similar program, ZYX-BOOT was subjected to an unimaginable number of hacks, modifications, and mutations. I even recall a disk that contained about 60 different types and subtypes of this boot with different music and sprites.
For a long time, the programming community remained inactive, as there were practically no new ideas for even greater automation and simplification of program launches. And then a new miracle appeared, CODEBUSTERS BOOT by RST#7.
For the first time (for boot construction), the technology of disk swapping applied in this programming masterpiece simply breathed new life into the very idea! Hundreds of programmers tore out the procedure of polling the disk drive, rushing to storm the peaks of automation and design. And when another brilliant person from Kharkov - COBRA - figured out to support the method of changing music proposed by RST#7, a new interest awakened among the common people. Now the disks began to record the newest and trendiest boots, and the music in them became the coolest and most prestigious.
The final touch to this story was the emergence of boot programs that require 128K of memory to operate! It is hard to say who was the first to "think" of this, but there are two contenders: ROM BOOT (BY ROM/S.B.U.H.G.) and BOOT by SILICON BRAINS. Both of these programs were released in 96 and use the 128KB mode only to implement cooler visual effects.
So what should the ideal boot be from the perspective of the modern user?
First, it is important to understand that a boot can be either game or system. For the former, the scrolling window principle is very convenient, while for the latter, it is simply necessary to display as many files on the screen simultaneously as possible. On system disks, there can be from 30 to 60 launchable files, and navigating through them in a small window is very inconvenient. That is why I record ZYX-BOOT on all my system disks! On the other hand, lately, such system boot programs are appearing less and less frequently. And this is quite understandable! Now a new boot is written not so much out of necessity, but for the visual effect that the newly minted RST#7 intends to impress you with. And if the entire screen displays the disk directory, then where will that very hyper-cool effect be? Thus, our programmers are spawning a huge mass of game boots, while system ones are nowhere to be seen! Many of my acquaintances have even come to the point of keeping a commander instead of a boot on their system disks. But this is unnatural!
So, let's continue. Since it is difficult to come up with a standard for system boots due to their absence, let's consider game ones.
File selection in such a program is usually made by the cursor from a window where scrolling occurs. The window size should be no less than 6-8 characters in height; otherwise, it is difficult to grasp the contents of the disk at a glance.
Scrolling in the window should be controlled by the maximum number of possible key and joystick combinations. It is reasonable to support the following options:
┌----------------------┬-----------------┐
│up pixel by pixel │ Q,S,9,up │
├----------------------┼-----------------┤
│down pixel by pixel │ A,X,8,down │
├----------------------┼-----------------┤
│up one file │ O,6,left │
├----------------------┼-----------------┤
│down one file │ P,7,right │
├----------------------┼-----------------┤
│select file │ ENTER,SPACE,0,M │
└----------------------┴-----------------┘
If you have devices such as KEMPSTON MOUSE or AY-MOUSE at hand, no one forbids (and even recommends) supporting them as well.
I want to warn novice programmers about a common mistake. If your "SPACE" key is polled asfile selection, the following situation may occur: the user points the cursor at the desired file, presses the BREAK key (CAPS SHIFT + SPACE), and the program starts. But in the next milliseconds, everything stops and you are thrown back to BASIC. It is not difficult to understand why this happens and how to combat it. It is important to avoid such errors in your creations.
Disk swapping is also an important element in a modern boot. On the one hand, this process should be handled automatically, but on the other hand, not all drives operate without problems with this method. On some machines, due to a poorly assembled controller or a malfunction of the drive itself, automatic disk re-reading generates a wild crackling, threatening to completely disable the system. Naturally, there are also programs that function quite normally even on such drives, although disks are re-read automatically. It all comes down to how correctly the assembler algorithm is implemented. Perhaps, in the upcoming issues of the magazine, we will provide the text of a correctly working disk polling procedure. But for now, let's try to solve the problem at its root - how to determine disk swapping, automatically or manually?
The Samara programmer MAXSOFT approached the solution of this question radically. He was absolutely not satisfied with automatic disk reading in any form, as this method leads to terrible glitches on the SPECTRUM emulator on IBM. Here is a small disassembler of the program MAXBOOT 11:
LD A,(#5DбE) : Check
CP #31 : number
CALL Z,#CEDB : MODE
LD A,(#5DбE)
CP #32
CALL Z,#CEDЧ
......................
#CEC8 LD C,#13
CALL #3D13
LD A,(#SCDD) : Check
CP #49 : emulator
RET NZ : UKV-DEBUGGER
#CEDЧ POP HL : Disable
LD HL,#C9AF : auto-reading
LD (START_OF_AUTOCHECK),HL
RET
#CEDB LD HL,#801 : Check
CALL #CEC8 : emulator
CP #1C : Z80
JR Z,#CEDЧ : (LUNTER)
LD HL,#ЗDAD
CALL #CEC8
LD HL,#ЗEB5
CALL #CEC8
LD HL,#1FFD
CALL #CEC8
RET
The idea is as follows. In the BASIC loader, there is a line of text "MODE 1", where one is one of three operating modes:
1 - test for the SPECTRUM emulator, and if yes, then disable auto-reading. 2 - auto-reading is always off. 3 - auto-reading is always on. Thus, if you are not satisfied that your disk drive hums from auto-reading, you just need to change one number in BASIC with the help of a disk doctor, and the program will work as needed. Manual re-reading is most conveniently assigned to the SPACE key (naturally, if it is not used by you as SELECT), and duplicated by the R key. When creating an auto-reading procedure, it is important to pay attention to the algorithm's operation. Often, a poorly written algorithm leads to errors when working with write-protected disks. Moreover, the disk reading should only begin when the user has already removed the old disk and started inserting the new one (see MAXBOOT#11).
During the time of reading the new disk, it is necessary to completely stop the work of all visual effects and music playback. The hacker UNWINDER/CODERS ACADEMY radically solved this program. In his boot, a quasi-multitasking disk reading driver was implemented (as in BATTLE COMMAND and INSULT). Therefore, when swapping disks, the screen goes dark, but the music continues to play, creating an unparalleled sense of liveliness. In general, if this boot did not require 128K of memory, it could be considered the best to date in terms of both service and design.
Literally after the very first boot written in the world, people realized the unnecessary nature of displaying the boot file itself in the file selection window. This was motivated by the fact that the boot is always recorded on the disk first and will only interfere with file selection. Some "hotheads" even called for completely ignoring not only this file but any other starting with a lowercase letter. Indeed, this proposal was relevant at a time when disk versions existed by the "Rodionov method", that is, containing not one but two BASIC blocks. Only the first was launched, and when attempting to launch the second, at best, the user would only experience a light fright.
Today, there are practically no such disk versions left, but new formats of games and magazines - disk size - have appeared. Such a game or electronic magazine occupies an entire disk and naturally has the name boot. If such a disk is inserted into a boot-ignoring program, you will not be able to launch the game or magazine, as the file named "boot" does not display on the screen. I hope I have convinced you of the necessity of displaying the boot file itself? And for those who are disgusted by constantly seeing the word boot in the first item of the directory, I can suggest the following method. After reading the disk, the first file displayed in the selection window is boot, followed by the names of all other programs. At this point, the cursor is immediately set to the second program. Thus, even if you press the SELECT key immediately after loading, it will not launch boot, but actually the first program on the disk (after boot).
Naturally, a modern boot should be able to switch from one drive to another by pressing the keys 1 (drive A), 2 (drive B), 3 (drive C), and 4 (drive D). Of course, one might argue - most ordinary users do not even have a second drive, and a third or fourth is generally superfluous. But it should not be forgotten about the emerging trend of transitioning to 3.5' disks and drives, and in this case, a configuration with two 5.25' and one 3.5' drives may become an objective reality. And returning to the notorious emulators, it should be noted that in the latest version of UKV, it is possible to create images of floppy disks on the hard drive and then work with them as with drives "C" and "D".
Naturally, there may arise a situation where the user tries to select drive "D", although they only have drive "A". In this case, the most effective way is to make 5-10 cycles of attempts to switch to another drive, and if they fail, return to the original drive. Music is an integral part of a modern boot, and the programmer's task is to make it as easy as possible for the user to replace it. The most common method is to record the music in a separate file immediately after the boot itself. The music should be compiled with the appropriate editor, without a player. Thus, the player itself should be standard and located within the body of the program. Usually, one boot plays music created only in one of the editors (ASM, ST, PT, STP). Supporting all known music formats at once is difficult also because storing 3-4 players in memory is quite wasteful, and again, there is a lack of memory to implement super-hyper-video effects.
As a way out of this situation, I can suggest the following. After loading the boot containing all players into memory, the melody itself is loaded and tested for belonging to a particular editor. Then all other players not needed for operation are destroyed, and the boot itself is decompressed in their place. This way, memory can be saved, and all existing music formats can be supported. Although in principle, it is enough to include two players in the boot - from PRO TRACKER and SOUND TRACKER PRO. Nowadays, not many people write music in ASM, and any melody from a regular SOUND TRACKER can be easily converted to the STP format.
It is also worth remembering that the user may accidentally or intentionally record something other than music after the boot. In this case, it is enough to conduct a melody test for belonging to the editor, and if there is a suspicion that it is not music at all, then simply do not play it!
By the way, the question of unambiguous determination of a compiled melody's belonging to a particular editor is very complex! Of course, one can break a program like VIRTUAL PLAYER (by DISMASTER) and remove all checks, but we would like the authors of music editors (in particular KSA) to provide official ways to unambiguously determine the belonging of compiled music to a particular editor. Our magazine will gladly publish such information. That's all I wanted to tell you today about what boot'ы have been, are, and will be. Naturally, my opinion may be subjective. Therefore, I ask everyone who is interested in this topic to write letters with advice, comments, and suggestions. We will definitely publish everything.
-════════════════════════════════════════
* * * * *
Contents of the publication: Oberon #03
- From the Authors
The editorial of the third issue of Oberon reflects on its wide distribution across Russia and nearby countries, overcoming production challenges, and its aim to cater to various readers, including gamers, programmers, and hackers.
- How to Write in Oberon - M.M.A
Guide on submitting articles to Oberon using ZX-WINWORD. Detailed format and process explanations for text, graphics, and music. Insight into editorial practices and preferences.
- Scroll - M.M.A
A historical overview of the game THE EIDOLON on ZX Spectrum, covering its restoration process and gameplay mechanics, including level challenges and story background.
- Scroll
Dark Star is a space shooter game where players pilot a ship against a tyrannical alien race. Players customize settings, navigate space, and combat enemy forces on various difficulty levels. Strategic planning and skill are vital for successful gameplay.
- Scroll - M.M.A
Detailed gameplay mechanics for the game with Mechnotech klp2. Strategy involves disarming reactors and managing droid transformations. Insight into different droid types and weapons available.
- About Everything - M.M.A
Discussion of reader interactions with the 'Oberon' editorial team, including feedback on previous issues and commentary on game compatibility and magazine content improvements.
- About Everything - M.M.A
The autobiographical article explores the author's role in Samara's ZX Spectrum scene, detailing his contributions and aspirations. M.M.A positions himself as a leader and innovator in the community. It highlights the importance of local distribution and cultural impact.
- Amiga rulez? - M.M.A
Critical essay on contemporary computer culture, contrasting IBM and Amiga platforms. Discusses societal impact of IBM standardization and advocates Amiga as a symbol of creativity and individuality. Reflects on the evolution of computer usage and preferences since the ZX Spectrum era.
- What Should 'Boot' Be - Unbeliever
The article explores the evolution of boot programs for ZX Spectrum, discussing early developments and key innovations over time. It highlights significant breakthroughs in automation and design, including fully assembler-written boots and the introduction of modern features. The text concludes with reflections on ideal boot characteristics from a contemporary user's perspective.
- Letter from Queen Software
An open letter from Queen Software criticizes ZX-WINWORD's design and Russian keyboard layout, denounces 'Mortal Compot' and the degradation of games, and shares views on demoscene events and computer emulation.
- Review - Unbeliever
The review provides insights into various 128K exclusive games for the ZX Spectrum, highlighting titles like 'Space Gun', 'World Championship Soccer', and 'Night Breed'. Special attention is given to their graphical prowess and gameplay mechanics. Furthermore, the article addresses the acquisition of Spectrum software via the Internet.
- Review of Assemblers - Maxsoft
Review of various assemblers for ZX Spectrum, highlighting their strengths and weaknesses. Focus on EDAS 3.3, AFS, XAS, ZX-ASM, ALASM, MASM, and TASM 4.1. Each assembler is evaluated on performance, features, and usability.
- Our Answer - M.M.A
Critical analysis of the electronic journal FAULTLESS, highlighting plagiarism issues and content quality. Discussion on the comparison with OBERON and other journals. Suggestions for improving FAULTLESS are provided.
- Our Response - Alex Noman
Debate over the compatibility and capabilities of Scorpion and Profi computers with the ZX Spectrum. Critique of programming claims by Chung Software regarding outdated languages and methods. Discussion on operating systems like CP/M and iS-DOS in the context of their utility in modern computing.
- Our Response
Exploring the varied interpretations of the term 'hacker' in Russian, highlighting distinctions and misconceptions.
- Hardware - Dr.Death
Connection instructions for AY-3-8910 on Spectrum-compatible machines. Solutions for common audio issues in Russian computers. Advice for improving digital sound compatibility.
- Hardware - Dr.Death
Discussion on modifying SCORPION ZS 256 for better performance, focusing on timing issues and TURBO mode. Explanation of improvements and potential problems with multicolors. Suggestions for further upgrades.
- Hardware - Poltergeist Corp.
Analysis of hardware issues with Profi, a ZX Spectrum clone, focusing on INT signal problems causing graphic flickering. A solution is proposed involving a simple hardware modification. The author shares their success and the widespread adoption in Samara.
- Let's Gurm
A microdrama illustrating the chaotic interaction between computer components during a printing task.
- Let's Feast
Satirical story depicting an alternate reality where American culture and symbols are humorously twisted by Soviet influences.
- Let's Feast
The story humorously describes Popov's efforts to help Papuans progress, amid desert struggles, political intrigue, and personal challenges.
- Let's Discuss
Overview of military jargon known as 'Army Absurdities' collected by students, highlighting unique language and instructions used in military training and communications.
- Let's Feast
Satirical article describing military humor and fictional military equipment.
- Literacy Campaign - Paul Atrides
Analysis of hacker misconceptions and societal attitudes, exploring hacker culture's roots and ethical dilemmas.
- Primer - Paul Atrides
Article discusses the role and activities of Russian hackers in the late 1990s, highlighting notable cases and categorizing different types of hackers. It covers the operations, risks, and impacts of hacking on international and local levels. The text also examines the societal perception of hackers and their portrayal in media.
- Contest - M.M.A
A contest involving identifying songs from poorly translated lyrics, inspired by a radio segment. Participants guess the song and artist. No specific prize yet, but a free journal issue is promised.
- Contest
A poetic reflection on personal struggle, misunderstood communication, and the burden of saving the world.
- Contest
A poetic reflection on isolation and inner dreams, contrasting with harsh reality.
- Contest
The article presents a poetic tribute to the community, emphasizing themes of unity, immortality, and strength through metal music.
- Advertisement
Advertisement in Oberon magazine offers free publication and discusses available software, hardware, and stores related to ZX Spectrum.
- Advertisement
Advertisement of computer repair and upgrades with pricing for various services. Options include drive connection, signal normalization, and memory upgrades. Specific services for different computer models like Pentagon and ATM.
