SoundTrack: SECTOR OF SSG WAS HERE (RLZ98)
Edition: Dan!!l/PGC/BD
Ze Pagan/PGC/BD
Programming from the bottom up diagonally. /SVN/
I. Where to start.
Many Western programmers claim that before starting to write a program, one needs time to think about the algorithm, and some even urge to delve into the essence of the task at hand. It is categorically inadvisable to be interested in the formulation of the problem until the object module of the program is obtained. Remember that programming is an art, so any unnecessary knowledge only restricts your imagination. Start writing the program text long before you are given the technical specifications, and you will have a wonderful opportunity to make the life of your supervisor (and yours) much more diverse and interesting (for example, at the moment of receiving the specifications, you can exclaim: "Can you imagine how much we will have to redo?!"). Never create a flowchart of the program in advance. First, it is easier and faster to do when the program is already written; second, a carelessly left flowchart on the table will give your enemies and envious colleagues the opportunity to understand what you are planning to do. Remember that no one but you should understand your program. And if you cannot rid yourself of the bad habit of drawing flowcharts, then carve this into your nose: The more the structure of the program corresponds to its logic, the less you are worth as a programmer.
II. Style. This trendy little word is given a special, almost mystical meaning by many Western adepts and apologists. Undoubtedly, every programmer or composer has the right to write in their own manner; however, considering the volume of software development, it is necessary to reckon with reality. Like everything else, programming must be economical! Spending up to 50% of the listing volume on comments, spaces, empty statements, asterisks, and other embellishments is completely unacceptable wastefulness. Write from the 2nd to the 71st position, avoiding spaces as much as possible. If a comment is unavoidable, strive to write it as specifically as possible. For example:
Dо J=1 to N; /* сYсL ро N*/ IF J>0 then Goto m; /*реRехоD то м*/ else Goto L; /*реRехоD к L*/ x=x+1; /* рRIваWIтх 1 к х/* eND; m: X=x-1; /* так надо федя! */ IF a then Goto L; L: /* ВозVеSтY х Sтер. Два*/ x=x**2; ... and so on.
Give all variables names of your acquaintances, favorite dishes, pop bands, cigarettes, drinks, etc. It is easy to see that fragments like:
IF катJа >= 18 then Do; call GаSтRоNом; call тахI; Goto хата; eND; else Goto VеRа; /* рL/1 */
GLорING сSест ... МаRINа еQU DURа ... L ан,маRUSJа Sт Uн,аNJUта вхLе LетS,IRINа,DRINк(аGDам) /* аSSемвLеR */
are striking in their elegance, wit, and refined taste. Upon careful examination, it is easy to find that bourgeois authors of books, discussing the subject they call "structured programming," drown in their own contradictions. For example, [Meyers], p. 63: "Modestly aimed working programs are better than untested grandiose projects," and on p. 58: "If a minor addition makes your program suitable for another case, never disregard it." We are ready to agree with the latter statement, as its skillful application will allow you to stretch the development of the program for any conceivable duration. Moreover, the same author recalls the infamous principle of KISS (Keep It Simple, Stupid!). Can you imagine, one fine day your supervisor tells you: "It seems you are making everything too simple!" These structurally extremist tendencies ultimately lead to the complete degeneration of programming as a creative activity. The extreme degree of degradation gives rise to methods like Ashcroft-Manna [Yodan], reducing the programmer's activity to Chaplin's work on the assembly line in the movie "Modern Times."
III. Gо Tо
The problem of unconditional jumps, fortunately, has not yet found a definitive solution. Among the programming Western youth, there is a misconception that the use of the Gо Tо operator is highly undesirable. The practice of leading programmers in our laboratory shows that the use of the unconditional jump operator in conjunction with arrays of labels increases program efficiency by an average of 4.2%. While increasing debugging time by 350-400%. If you need to jump from a given point in the program, you should jump as far as possible. If there is nowhere to jump to, the program should be reconsidered. Very successful are jumps into the body of a Dо loop, especially from other modules. Although translators usually prohibit this, they can easily be outsmarted by using label-type variables. Transferring control to the called procedure bypassing the header will bring you long hours of happy contemplation over the exit code 0с5. All insertions into the program should be done as follows: after the last operator, place a new label, write the text of the insertion, increase the dimension of the label array by 2, transfer control to this label from the necessary point (or from somewhere else), mark the operator following the Gо Tо with a new label, boldly change the value of the label variable, and return. Generally speaking, no matter what language you write programs in, it is better if each operator has its own label (as is provided in Fortran). Your qualification as a programmer in the style of SVN is determined by the ratio:
N
SIGма ( V(I)+W(I) )
I=1
к = ------------------- , where ( 1 )
N
N - the number of operators, V(I) - the number of control transfers to the I-th operator; W(I) - the number of possible transitions from the I-th operator.
With к < 0.5, you, as a programmer, are worthless. An acceptable coefficient is 3-4, and some superprogrammers have K no lower than 12.
IV. Modularity. N o m o d u l a r i t y! In general...
V. Efficiency.
Disputes about what constitutes an efficient program have not ceased since the M-20 computer started operating in the gym. Nowadays, it has come to the emergence of casuistic assertions like: "Readability of the program is more significant than its efficiency" [Meyers]. We believe that the efficiency of a program is a completely objective and quantitatively measurable quantity. One should not spare time or effort in the fight for efficiency - when your program eventually runs, all your costs will be compensated by a saving of 15 microseconds and 0.73 KB. To allow a programmer to assess the efficiency of their product in advance, a simple formula is proposed:
Э = т/т1 + I*т/т2, where (2)
т1 - the time required for the CPU to execute your program (if the program is not yet running on Gо, т1 = т);
т - the time needed to output a pre-prepared text to the ADC, identical to what your program will print when it runs on Gо;
т2 - the time your program will run when you have completely debugged it.
I = SQRт (-1)
The efficiency of the program, as you can see, is a complex quantity, reflecting the systemic approach to programming characteristic of the SVN method. Thus, as follows from expression (2), the time taken to write and debug the program in no way affects its efficiency. Many programmers, apparently, have intuitively come to understand this fact and have been improving their program for years, making it increasingly efficient by reducing the parameter т2. By the way, one of the apologists of "structured programming" [Meyers] allowed himself the following: "No one, being in their right mind and solid memory, will program in assembly language." And this is about the favorite language of SVN supporters! On the contrary! Studying assembly language is a great way to reach the heights of knowledge of OS ES of computers. By following this path, you will gain a wealth of useful knowledge that will help you solve a number of crucial problems:
1). How to capture the CPU for at least 1.5 hours by obtaining a one-minute coupon in a package, eliminate the tasks of all other users (for example, with code S422), stall the job queue, deprive the operator of the ability to remove your task, effortlessly obtain results (regardless of the established paper consumption limit), and at the same time direct all complaints of the operator service OVT to some department of the "F" faculty?
2). How to spoil (without erasing) all other ND on your package 5050/5061, leaving no traces in рRINтLоG?
3). How to erase the kernel? (Or IрL?)
In general, there is a rich spectrum of ways to increase program efficiency. The authors are well acquainted with one programmer who recently won a case of beer by doubling the performance of three randomly selected Fortran programs from the trash can of one of the "T" faculty departments after 40 minutes of superficial analysis. Since this fact is completely unknown to the management, programmers in the style of SVN face long years of cloudless existence and happy programming.
VI. Again modularity.
Still, no modularity!
(Since modularity cannot be understood otherwise than as the presence of a certain built-in function. Everything else is from the devil.) Consider yourself worse than others if you cannot write a program (if you wish, call it a module) longer than 1000 operators. If for a number of objective reasons (they always exist) you still have to face the problem of interfacing, remember one single rule of the SVN method:
No agreements on connections!
Especially if you have to deal with programmers of the opposite sex. According to Article 94 of the procedural code, when examining cases of establishing paternity, the protocol of the agreement on connections is taken into account along with the evidence of joint management of the household. Moreover, as has already been emphasized, any restrictions on your imagination as a programmer will bring nothing but a reduction in the project development time and, consequently, a decrease in the efficiency of the final product. Delight your supervisor by hanging a poster over your desk: "Programming is too complex an intellectual activity to hope to impose on it the bonds of an administrative system that stifles any initiative." [van Tassel]. If the response from management turns out to be more restrained than you expected, repaint the door of your laboratory with the green paint of the most toxic color and disappear for three days, having first disconnected your home phone [Meyer, Bodewin].
VII. Debugging.
The first commandment of a programmer who has successfully overcome the barrier of syntactic control is not to rush. Remember that a poorly debugged program is always less efficient than a completely untested one. Do not print more than one variable per run. Immediately destroy the obtained listings (printouts) (to avoid! See V). On the other hand, it is useful to keep, in a single copy, the compiler's log with the worst (this is not difficult) print quality so that when the supervisor unexpectedly appears, you can say: "See what conditions I have to work in!" Of course, diagnostic messages should be cut off, or better - carelessly torn off. (For those who program in Fortran or assembly, we recommend acquiring some skills in working with scissors and glue). If you store the source text on NMД, never check the IевUрDте card, and do not deprive yourself of pleasant surprises! Moreover, checking for punching is bad form and a sign of vile disrespect for the sweet and charming girls who spend the best years of their youth punching holes in your punch cards. When debugging ends, operation begins! No self-respecting programmer will allow their beloved offspring, the fruit of their many years of labor and suffering, to be exploited by some outsiders. A few words about testing. No one knows exactly what testing entails, what the ultimate goal is, and what results should be obtained. In the SVN method, it is customary to consider testing complete if execution ends with a return code of 0000, even if the input data differ by at least one number (or all - if you are a maximalist). After the testing phase is over, destroy the source text. Only in this case can you be absolutely sure that no one will harm your program and it will remain as efficient as it has always been.
-----------------------------------------******************************************
-----------------------------------------
+---------------------+
| Life and Extraordinary |
| Adventures |
| of Kirill - the Hacker. |
+---------------------+
Once, in a math class, Kirill couldn't multiply 200 by 400 - the result exceeded 65535. His head rang: "Overflow!"
Once, Kirill was walking along a brick wall. Suddenly he saw a bulldozer coming towards him. "Packager!" - Kirill thought.
Once, when Kirill was 6 years old, his dad took him to work. There he sat him down at a computer - to play Goody. When Kirill was done playing, he disassembled the computer - just like all the toys he had played with before.
Once, Kirill stood for 3 hours in front of a traffic light - he couldn't understand what video adapter was there: Hercules has 2 colors, CGA has 4, EGA has 16, VGA has 256, XGA has 65535, and 3 - well, no one has that!
Do you know what Kirill does when he is hot? He turns the computer upside down - with the fan towards him.
Do you know what Kirill does when he is cold? He turns off the AT-486 and turns on the EC-1840. In 5 minutes it heats up like a stove.
Once, in a physics class, Kirill received speed in joules. "Type error!" - he thought.
Once, Kirill got a haircut. "Formatted!" - he thought.
Once, Kirill saw a brick falling on his head. "Looks like Tetris!" - he thought.
Once, Kirill was given a gun for his birthday. "What do I need this for!?" - Kirill was surprised. He was answered with a question: "But you asked for a 'Winchester'!?"
Do you know what Kirill says instead of "Hello" when he picks up the phone? "Connect 2400!"
Do you know how Kirill dials a phone number? First, he tries to dial ATDP, and when he realizes that this is impossible, he changes all 1s to 7s, 2s to 8s, and 3s to 9s. And only then does he dial the resulting number - blindly, like on a computer.
Do you know how Kirill writes? Odd lines - left to right, and even lines - right to left, like a printer.
Once, Kirill needed to type on a typewriter. He couldn't understand for a long time why, when he pressed "Return," the last entered character wasn't erased.
Once, when short beeps sounded in the receiver, Kirill searched for ESC on the phone for a long time. Eventually, he found it - inside the device.
Kirill respects sorting only by bubble sort and quicksort.
Once, Kirill was sent for a pine tree. Instead of the pharmacy, he started calling BorLand. At first, they didn't understand anything. Then they decided - it was some kind of organization to help Russians.
Once, Kirill was called a brake. He thought for a long time about what kind of brake he was - working or parking. Then he decided - working, with a computer control system.
Do you know why teachers check Kirill's math papers much longer than others? They don't understand what he does to reduce zeros.
Do you know why Kirill carefully inspects a sandwich before eating it? He is afraid that a gray mouse might be inside, as it happened once. He broke two teeth on its plastic case then.
Once, when Kirill first saw the starry sky, he was surprised that the stars hardly twinkled. Moreover, when they disappear, they somehow don't change color, like in Norton Commander.
Once, Kirill was walking down the street and saw something dropped on the asphalt. "Floppy disk!" - he thought happily, bent down, and picked it up. But it turned out to be a chubby wallet. "What a pity!" - Kirill thought and, without even looking inside, tossed it away. (A few hundred bills fell out during the flight).
Once, Kirill was asked to bring a guitar. He brought 5, and also a piano - on a disk for "Streem Tracker."
Once, Kirill accidentally inserted a floppy disk into the gap between two drives. Then he turned the computer upside down and shook it for a long time, banging on it until the disk popped out.
Do you know why Kirill can only shoot with a revolver? He releases the hammer with his thumb, like on a joystick.
Do you know what Kirill does when the floppy disk is so bad that it can't even be formatted on the computer? He takes a microscope, a magnet, and a hammer, and... formats it manually - sometimes with the magnet, and sometimes with the hammer.
Once, Kirill looked at his classmate with pity, who couldn't count in his head that 256 squared would be 65536. "Poor guy, he forgot his mathematical coprocessor at home!" - he thought.
Once, when in history class, Kirill's classmate said that the Great October Socialist Revolution occurred in 1918, Kirill thought: "The poor guy has a memory parity error!"
Once, in a math class, Kirill calculated the sum of an infinite convergent series. He counted, looked at the answer - it didn't match. "Checksum error!" - Kirill thought. He recounted and got the same result. Then he looked at the condition again and realized that he had copied it incorrectly. "Read error" - it dawned on Kirill. Then he started counting anew, but suddenly ran out of notebook. "Overflow error!" - Kirill decided and didn't continue solving - he thought that a decision about the overflow error would be quite enough.
Once, Kirill, as a hacker, was asked to "hack" Arcanoid. He did it - all the walls in Arcanoid became "hacked" - he drew cracks on them.
Do you know how Kirill distinguishes High Density disks from Double and Single Density? He brings a match to the magnetic coating - so that the flame touches it, and then looks from the other side. If it shines through - then it's High Density.
Once, Kirill was asked how a computer works. He replied: "Depending on which one. IBM - silently, DVK - Rrrr-bum-bum-rzzzz, and SM - doesn't work at all - always hangs."
Do you know how Kirill takes pictures? He sets a manual shutter speed, presses "Release," and then moves the lens along the object being photographed - like a scanner, then releases the shutter and starts looking for the screen on the camera -- to see what he got.
Once Kirill decided to make an antivirus against all viruses and did! Rather, he found it - it was an autoclave with a temperature of up to 300 degrees Celsius.
Do you know how Kirill plays volleyball? With his head! (In the literal sense.) In fact, only with his head and nose - like in Arcade Volleyball.
Do you know how Kirill opens doors? He tries to type in the air, like on a keyboard, "Open Door," and then wonders why the door doesn't open.
Do you know what Kirill puts on chairs instead of buttons? Microchips - legs up.
Once, when Kirill was listening to a tape recorder, it suddenly started "chewing" the tape. Kirill jerked and poked around the front panel for a long time - in search of Reset.
Once, Kirill dreamed of a computer. He didn't want to wake up so much that he fell into a lethargic sleep.
Once, Kirill was asked for the key to the suitcase to open and unpack it, he replied: "-e - Extract."
Do you know why Kirill doesn't like ice? He likes 3.5 floppy disks more than 5.25.
Do you know what Kirill did with the floppy disks after he accidentally left them under a 500-candle lamp? He threw away the melted plastic cases and inserted the disks into ordinary postal envelopes, not forgetting to stick on stamps.
Once, when Kirill first saw a painting by Rembrandt, he thought: "If I had a computer like his, I could paint even better!"
----------------------------------------------------------------------------------
FоR SYSтем аNаLISISт оNLY
"Imagine that you are buying furniture ..."
February 24 ---------Finally! I exchanged my cramped room for a new, two-room apartment of an improved design: "SVS 6.1/M9". I really liked it: beautiful, convenient for living and working.
March 1 ------I started moving in. A bit puzzled. The door is too narrow, part of our furniture doesn't fit. I threw out the wardrobe, the cabinet, the table. No matter, I will buy new ones. I managed to drag the sofa, but a strange thing turned out: as soon as I sit on it, the light goes out in the whole apartment. I will have to replace it too. What a pity, it was a very comfortable sofa, now they don't make such anymore. Part of the bathroom turned out to be occupied by a clever device. The neighbor said it was needed for predicting earthquakes. The device looks like a box with two angry snakes with sensors on their tails inside. I think they are poisonous. To allow my wife to use the bathroom, I had to lower the apparatus into the garbage chute. The neighbor said he did the same. In the kitchen, there is a huge niche with a poorly plastered inscription: "ноR кIтsнеN сомвINе". I'm starting to suspect that the house was designed not for our area at all. We don't have earthquakes. In general, it is livable. The only drawback is that the bathtub is leaking and the phone doesn't work. The TV shows only one program: by some signs, Indian.
March 14 ---------I struggled for a long time with the sockets. To avoid electric shock, all of them are fixed under the ceiling. I asked the in-house electrician to supply power to the socket of the radio network, which I completely don't need, but he said that the house is arranged this way: if you disconnect the radio network, the fire alarm starts howling, so it's better to endure; in 7-8 months they should receive sockets of type 02, which can be attached to the wall anywhere with special glue. However, the glue is still bad and the sockets won't hold anyway. It turned out why the TV doesn't work. Apparently, there is an antenna of an improved design installed on the house, and TVs with corresponding modifications have not yet started being produced. I walk around the apartment cautiously. I constantly bump into sharp corners, occasionally a piece of parquet flies out with a clang, I threw out the sofa, but the light still often goes out.
April 19 --------Thank God, at least they fixed the phone. The technician said it was connected to the TV cable. But now the TV doesn't receive anything at all, not even India. The neighbor said that there should be a third room in my apartment. It is not on the plan because the plan is old, a new one will appear in about a year and a half. Now it is clear why there is a door at the end of the corridor. Where to find the key for it? I contacted the housing office, but as usual, they know nothing. I looked at the exchange announcements.
May 26 ------
Still, I'm lucky! I exchanged this lousy apartment. Tomorrow I'm moving. A wonderful house, project svm2.0. The most modern conveniences, spacious, automation. The layout is free, easily convertible. For example, on my floor, there are an Indian wigwam, a bamboo hut, and two smoky huts. You are allowed to do whatever you want, for example, to light fires right in the corridor. The sound insulation is absolute.
May 29 ------
I'm gradually settling into my new place. The neighbors are peaceful. One, who lives in the distant hut, keeps a cow and a goat. It's a bit dirty and uncomfortable. The electricity situation is bad: the inhabitant of the hut is very cold and keeps a huge fireplace constantly on, which consumes almost all the energy, so it is completely dark for us. One thing bothers me: even when the fireplace goes out, the lamps glow at half power. The smoky huts are outrageously smoky, it's hard to breathe at all. However, there are no problems with furniture, although the rooms are empty. As soon as you need a chair or a wardrobe, the duty operator immediately sends you the required item from the available stock. This is called "virtual furniture."
May 30 --------
An opportunity came up, I moved to another floor. There are no wigwams here, and the neighbors are very decent. However, there is a huge cave by the elevator, inside which something large snores in complete darkness. The superintendent said it will sleep until the end of the quarter, so nothing dangerous, just in the last decade it's better not to leave the apartment. It seems that virtual beds are not as good as I thought. Most people sleep simultaneously; they need real beds, and there aren't enough for everyone. Furthermore, the operator constantly confuses and takes the bed before it is vacated. There have been awkward cases. However, the superintendent says we are lucky. In the first series of svm, there were virtual toilets. It's hard with the garbage chute. There is only one for everyone, so on each floor, there is an intermediate bunker for temporary storage of garbage. Sometimes the garbage stays there for a week. The smell around is like from a cave.
June 16
-------
The end of the quarter is approaching. The snoring in the cave has become restless, occasionally mixed with indistinct words. I stocked up on food for two weeks. Today I had a dream and got upset. I dreamed that I was living in my old personal apartment, where all my things are, not virtual ones, and all the equipment works as it should. Tomorrow I will go to look at exchange advertisements...
Contents of the publication: Deja Vu #05
- Аперативчик - Max
Detailed instructions on managing the DEJA VU interface, highlighting different input methods and navigation commands. Explanation of the new and old interfaces for enhanced user experience. Discussion on additional features like frame scrolling and music management.
- Аперативчик - Max
Discussion on supporting machines with more than 128k memory, leading to separate shells for 128k and 256k systems. Testing was mainly done on Scorpion and Profi, with functionality on other models anticipated. Article includes guidance on unpacking source files and insights on using improved algorithms.
- Тема - M.M.A
This article explores the theory behind digitizing sound on ZX Spectrum, focusing on sampling and quantization processes. It provides practical insights into converting sound files using specific hardware and software. Additionally, it offers methods to enhance sound quality while working within the hardware limitations.
- Theme
The article discusses the Save Our Scene initiative aimed at uniting Spectrum users and developers to promote software distribution and enhance the scene's development.
- Charter of the Amazing Soft Making Association
Discussion of the founding charter of the Amazing Soft Making association, detailing its goals, membership criteria, and operational principles.
- Theory of Magazine Creation
The article provides a detailed guide for aspiring magazine creators, focusing on technical aspects such as interface design, memory management, text formatting, and music integration for ZX Spectrum publications.
- Solder Drop
The article provides a personal account of purchasing and using the General Sound device for ZX Spectrum, detailing installation and sound performance. It discusses the initial issues encountered and praises the enhanced audio experience in compatible games. The author encourages further software adaptation for the device and reflects on multimedia capabilities with simultaneous hardware use.
- Solder Drop
The article discusses the capabilities of Sound Forge 4.0c for professional audio processing on PCs, highlighting its extensive features such as sound editing, effects, and restoration tools.
- SOFTWARE
The article reviews the latest software developments for the ZX Spectrum from Samara, including updates to MAXSOFT SCREEN PACKER, File Commander, and new applications like S-Terminal.
- SOFTWARE - Card!nal
Review and walkthrough of the logical graphic adventure game 'Operation R.R.' with detailed level instructions. Discussion on game elements like music choice and graphic design. Mentions new coder MAX/CYBERAX/BINARY DIMENSION's involvement.
- SOFTWARE
Discussion on the current state and evolution of the demoscene, highlighting the rise of 4K intros and upcoming competitions like FUNTOP'98.
- CODING
Article discusses assembly language coding techniques for optimizing screen scrolling on ZX Spectrum, featuring example code and performance analysis.
- CODING - RLA
The article explores stack manipulation techniques during second type interrupts for graphical effects on ZX Spectrum. It discusses solutions for preserving data integrity when interrupts disrupt graphical operations. Practical examples are provided to handle stack issues efficiently.
- CODING
The article describes the MS-PACK packer and its DEPACKER, detailing usage scenarios and providing BASIC and assembly code examples for handling packed files. It emphasizes optimizing performance by allowing unpacking with interrupts enabled and separating the DEPACKER from packed files. Additionally, it includes insights on programming techniques for loading and executing BASIC files on ZX Spectrum.
- CODING
The article discusses various coding techniques for ZX Spectrum, focusing on sprite rendering, rotation algorithms, and optimization methods to enhance performance.
- ANOTHER WORLD
Discussion on the evolution of multimedia technologies and their impact on various fields, including education and entertainment. It covers advances in computer hardware and software that have facilitated the integration of audio, video, and text. The article reflects on past developments and speculates on the future of multimedia systems.
- ANOTHER WORLD
Comparison of PC and Amiga systems highlighting performance, software costs, and user experience with multimedia capabilities.
- Honor Roll
Interview with PROGRESS discusses their creative journey on ZX Spectrum and AMIGA, addressing challenges in demomaking and the current state of the scene.
- Honor Roll
The article details the activities and future projects of the Eternity Industry team, based in Kovrov, including successful releases and collaborations with other groups.
- Honor Roll
Discussion of the Artcomp'98 festival, focusing on its mail-in format and guidelines for various competitions, including demo, graphics, and music categories.
- Honor Roll
The article provides a glossary of terms used in the demo scene, explaining roles such as musician, coder, and graphician, as well as different types of demos and effects. It serves as a useful resource for understanding the terminology and dynamics of the community. This is a descriptive piece aimed at educating readers about the jargon of the demo scene.
- Honor Roll
The article discusses the issues with mouse support in various ZX Spectrum magazines and the frustrations of users when encountering compatibility problems. It critiques developers for not adhering to standards, leading to poor user experiences. The author expresses the importance of consistent improvements in software for the ZX Spectrum community.
- Honor Board
The article discusses the process of creating tricolor images for ZX Spectrum using Photoshop and a simplified approach. It outlines how to divide an image into RGB channels and convert them for use on the Spectrum. Additionally, it provides tips on how to manage the files for optimal results.
- Honor Roll
The article discusses the comparison and perspectives on various computer systems, particularly emphasizing the strengths of AMIGA over PC and advocating for appreciation of all machines.
- Seven and a Half
Article discusses the humorous absurdities and peculiarities of military training and academia, blending satire with real anecdotes and witty observations.
- Seven and a Half
The article provides a satirical manual on programming methodologies, mocking the rigidity of formal programming practices and advocating for a more creative approach to coding.
- Seven and a Half
Instructions on safe sex practices, including guidelines on eligibility, preparation, and actions during and after the sexual session, along with handling emergency situations.
- Seven and a Half
The article discusses a call for a talented artist in Krasnodar for a ZX Spectrum group, raises concerns about the unethical practices of Scorpion regarding software rights, and critiques a video review of E'97.
- Seven and a Half
The article 'Семь и 1/2' narrates a humorous picnic adventure involving the editorial team of Deja Vu, highlighting their camaraderie and mishaps while preparing a barbecue.
- Trial of the Pen
The article is a humorous take on the fictional adventures of Winnie the Pooh as he interacts with computers and friends, discussing the absurdities of technology and daily life.
- First Pen
The article discusses the new section in Deja Vu dedicated to fantasy and science fiction literature, featuring book reviews and reader participation in content creation.
- Advertisement
The article is an advertisement section from Deja Vu #05, promoting collaborations with designers and musicians for future issues, and offering various software and hardware for ZX Spectrum.
- News
The article announces the launch of a new magazine, AMIGA RULES, focused on the AMIGA computer, addressing the lack of quality Russian-language publications. It aims to provide information on programming, hardware, software, and gaming, while fostering a community among AMIGA enthusiasts. The magazine will include contributions from readers and regular updates on the AMIGA scene.
