BRIEF GUIDE FOR SYSTEM PROGRAMMERS
A person who decides to write a system program faces many difficulties. This text is intended to help you, at least partially, make your program high-quality and user-friendly. Naturally, I could not take into account all the nuances, but still, if you use the advice outlined below, it will be easier for both you and the users of your programs. This is an extended version of an article once published in "Depth 1". We intend to continue this topic in subsequent issues of "RU(S)H".
WHAT TO CONSIDER FIRST WHEN CREATING A SYSTEM PROGRAM
1. Your work should take into account all the shortcomings and advantages of previous programs of this type. Learn from others' mistakes and use all the achievements of your predecessors.
2. The control in the program should be flexible and diverse. The standard set includes: SINCLAIR (right), KURSOR, KEMPSTON (with checking), KEYBOARD (O,P,Q,A, SPACE and M). Also KEMPSTON and AY mice. If you do not have a mouse, but want to implement its support, you can read about how to do it in the following editions: about KEMPSTON mouse - "SPECTROFON 20" in the "Constructor" section, about AY mouse - "ZX-POWER 1" in the "Hardware" section.
3. Always check for the presence of the KEMPSTON joystick and do not poll it if it is absent. Otherwise, your work will not function on all machines without this port. I remind you that if there is no KEMPSTON, bits 5-7 are set.
4. Your program should make maximum use of all the resources of the machine on which it operates. You need to test the available memory and work with it. I can recommend using the memory auto-configurator from "ZX-FORMAT5", written by CREATOR. It will allow your program to work with memory from 48k to a megabyte.
5. Copying utilities and other disk utilities should work with both one and two drives.
6. If your program has many changeable parameters (more than three), it is essential to save them to disk (SAVE SETUP). The saving should be done within the program itself, after checking for its presence and location on the disk.
7. If your program works with the second interrupt mode, you must connect them by creating a 257-byte table filled with one number, as in many machines, the bus reads not #FF but any number. This has been discussed many times, but still, sometimes programs appear that do not take this into account.
8. Naturally, segments (pages) should be switched not through port #FD but through the full port #7FFD (dec: 32765).
9. When accessing the disk, the first interrupt mode (IM 1) must be enabled. If for some reason you need IM 2, you can use the interrupt vector only within the fast memory areas (#8000-#BF00 (32768-49151) or in pages 0,1,2,3), with the interrupt vector located in slow memory, the entire computer, along with TR-DOS, will operate 25 percent slower, and disk operations will be disrupted. This is characteristic only for machines with separate memory fields; for others, such as Pentagon, this does not matter, but it still needs to be considered. Detailed information about separate memory fields is written in the Belarusian newspaper "ECHO 2", I recommend you read it. Also, when switching to the standard interrupt mode (IM 1), it is necessary to restore the value 63 dec in register I; otherwise, your program will not work on many machines, including branded ones.
A FEW MORE DETAILED TIPS FOR SPECIFIC TYPES OF PROGRAMS
14 TIPS FOR A PERSON WRITING A "boot":
1. First, you need to determine for which disks this "boot" will be used. For system purposes, simple but convenient shells are preferable, without various effects and unnecessary embellishments. If the "boot" is intended for games and demos, then it's a different matter; effects, graphics, and music are welcome.
2. Naturally, it should take up as little space on the disk as possible.
3. The faster your "boot" loads and starts, the better. In any case, do not attach effects with long DECRUNCHERs to it.
4. Try to display as many files on the screen simultaneously.
5. Program names should be easily readable. Choose an appropriate font and window color. Ideally, the file window should not move. Do whatever you want outside the window.
6. Control should be diverse and flexible, simultaneously from the maximum number of devices. If file selection occurs using arrows, provide support for KEMPSTON and AY mice. Personally, I mostly use cursor keys (extended keyboard) for file selection. When polling the keyboard, first check the CAPS SHIFT key; if it is pressed, keys 5,6,7,8 are polled as KURSOR joystick, otherwise as SINCLAIR. Disk change is usually done by pressing the SPACE key; this has already become a standard. It is also convenient to use the "ENTER" key as FIRE.
7. If your boot does not implement automatic disk change checking, before launching the program, it is necessary to re-read the directory, and if the required file is not found, display the directory of the new disk and, of course, do not launch anything.
8. Before launching the program, it is necessary to restore all system variables and everything required for the normal operation of Basic. The screen can remain black (the attribute area filled with code 0), but the standard attributes should be written into the system variables. It is also advisable to clear all the memory occupied by the "boot".
9. Programs using 128k ROM or 128k Basic are very few (to be honest, I couldn't recall a single one), while programs that do not work with connected 128k ROM are numerous. Therefore, it is advisable for the "boot" to immediately connect 48k ROM, but with active pages. If you do not know how to do this, take lines from the loaders of assemblers "TASM", "ALASM" or from any other. On a 48k computer, everything will still work fine.
10. In most boots, files named "boot" are not displayed, but sometimes this is inconvenient, so I recommend displaying this file, but if it is recorded first on the disk, then the pointer should immediately move to the next file. Also, when searching for the name "boot", it is necessary to check all eight letters, not just the first four.
11. Sometimes in the same program, there are several Basic blocks, only one of which is launched. This case can be anticipated, and certain Basic files should not be displayed. There is no single standard in this case. Sometimes, all files starting with a lowercase letter are not displayed, but this method is not always convenient. In my opinion, it is more convenient to filter out all files starting with a dot.
12. In some "boots," file sorting by alphabet is implemented, but usually, this only complicates work. Therefore, it is better to make sorting optional.
13. It is useful when, in addition to the file list, brief information about the disk is displayed on the screen. For example, its name, the number of free sectors, and the number of files.
14. It is advisable not to attach hard-coded music but to make it easily changeable. In this case, there are two ways: you can store a player from some music editor in memory and load a music file without the player. Alternatively, you can load a compiled block with the player from any editor, but it must be compiled for a specific address. In any case, you need to describe the process of attaching music in detail.
IF YOU DECIDED TO WRITE A COMPRESSOR...
First, it should allow writing compressed blocks without a decompressor so that one depacker can decompress many files. Second, you should attach a text version of the decompressor to the compressor so that anyone can modify it to their liking or try to speed it up. Compression time is not particularly important, but the decompression speed should be as fast as possible. The depacker should work correctly with interrupts enabled. When working with various compressors, it turned out that almost all existing "crunchers" (DSQ4, MS_PACK, LPC, etc.) do not always work correctly. Once, trying to compress a file, I tried 6 or 7 compressors, and none of them unpacked it correctly! Usually, errors manifest when the compressing file includes an already compressed block or screen. I am not an expert in this area, but I dare to express my opinion, slightly tinged with laymanship :-) ... Apparently, packers place their control codes, and upon re-compression, they may coincide, which will lead to incorrect decompression (just don't hit me if I said something stupid :-) )... Such glitches occur rarely, but try to ensure that your compressor has none at all. I am tired of writing loaders for programs. I would be glad to implement a multi-packing function for several files with attaching a standard loader that would distribute files across pages...
A FEW TIPS FOR A PERSON WRITING A MUSIC EDITOR
1. If you have decided to write it, you must surpass all existing editors; otherwise, why bother. In this case, it is essential to write a full-fledged converter from all editors to yours.
2. It is important that the player takes as few cycles as possible. Ideally, 2-3 thousand. Otherwise, the area of use for your editor will be greatly narrowed.
3. Attach the source version of the player in the format of some assembler (preferably "TASM", as it is easiest to convert the file to any other editor). You can also attach the text of the player in a regular text format.
4. First of all, I recommend familiarizing yourself with editors on other platforms. I can suggest looking at the editor "OCTAMED" on AMIGA. I think you will find a lot of useful ideas for service, and your editor will be much more convenient.
5. In addition to making life easier for the musician, you should also consider the coder who will use the music in their program. It would be very convenient if you implement a realtime timer. That is, a timer that will show the playback time of the music with interrupt accuracy. This will help synchronize music in the program with graphics.
6. Make it possible to change the volume of the melody during playback so that it is easy to implement music fading. You can introduce three variables in the player that will contain the maximum volume values for channels A, B, C.
7. Output in any of the three channels should be able to be cut off at any moment during playback so that sound FX can be played through that channel.
8. It would be nice to make it possible to jump to any position. This will allow quickly jumping to any part of the melody, storing several melodies in one, or, for example, using a melody as a set of sound effects.
9. Listening to music on Speccy, most people do not even realize that most melodies are heavily "out of tune" due to the programming features of some editors. However, one of my acquaintances from Kyiv - Sasha - a professional musician and tuner of musical instruments paid special attention to this. So, trusting his perfect musical ear :-), it can be said that neither "Sound Tracker", nor "ST-pro", nor "Pro Trackers" have correct sound generation from a musical point of view. Only the old "ASM" delights the ear with its tuning and sound accuracy. So, already modified versions of the 3rd "Pro Tracker" exist, which have sound generation tables borrowed from "ASM" by Sendetsky. I hope all authors of new editors and their versions will take this important nuance into account. After all, sound is the main thing in a music editor.
SPECIFIC RECOMMENDATIONS FOR AUTHORS OF SOME SYSTEM PROGRAMS
1. "ALASM" by ALEM
The assembler must understand the binary representation of numbers written after the % sign (for example, %00000001). When loading a WORK file, it is better to immediately set the cursor to the last recorded source. The ability to mark a part of the text with a different color or inversion. Also, mark lines with errors in a different color. By pressing a certain key combination, the assembler should remember the current position in the text, and then it should have the ability to quickly jump to that place. One-time compilation commands are very convenient, but there are often situations where several files are loaded one after another, and labels are located between them. In this case, during subsequent assembly, the addresses of the labels will be knocked off. For example, a fragment of the program: MUSIC +INCBIN "RAVE+" SPRITES +INCBIN "GFX_CODE" TABLE +INCBIN "DATA". During the first compilation, the values of the labels SPRITES and TABLE will depend on the length of the previous files, as it should be, but during subsequent assembly, when the marker "+" is replaced with "-", and files will not be loaded, all three labels will point to the same address. I think to avoid this, it is enough to remember the lengths of all the loaded files during assembly and then add them during each subsequent compilation. It is also useful to turn off sound on AY after returning from the launched program. You can also make the unused BREAK key in editing mode work like ENTER, but with the line break not in the label field, but in the command field. Disk work is better organized as in "TASM-4", that is, loading the disk directory into memory and taking file parameters directly from there, without unnecessarily moving the head to the zero track.
And a few more tips not only for ALEM but for all assembler creators:
It is advisable to provide for testing the launched procedures by time, ideally with an accuracy of up to a cycle, slightly worse with an accuracy of up to four, and at worst at least with an accuracy of up to an interrupt using the system counter (FRAMES). It is necessary that after exiting the launched program, without clearing the screen, one could enter a special mode for calculating screen addresses. Namely, a mode where a pointer the size of one byte or one point moves across the screen, and when FIRE is pressed, the address of this byte in the screen file, in the attribute area, and the coordinates in X and Y are displayed. A command that ties the next compilation address to a neat hexadecimal address would be useful. I would like assemblers to have commands like: SAVE 0 TRACK TO 159 and RESTORE 0 TRACK FROM 159. Also, it would be useful to have memory and page clearing functions.
2. STS by STALKER
If when writing a file to disk there is already a file with the same name at the end of the directory, it should be deleted and the new file written in its place, as the overwhelming majority of programs do. When entering numerical parameters for various functions, such as COPY, it is necessary to tie the entered numbers not to the right edge of the window but to the left so that you do not have to constantly move the cursor several characters to the right.
3. PERFECT COMMANDER by JAMES ADVENT
In my version of the commander, there is one minor but unpleasant glitch: when copying several files to a disk that has less than 256 sectors left, the commander sometimes "pretends" that the copying was successful, while in fact the last files are not overwritten. However, if the commander is restarted, everything will copy perfectly. Before viewing the screen, it is better to fill in the attributes with code 0, and it is better to always leave the border black, as the "intelligent detector" sometimes resembles a complete colorblind person; I say this as an artist...
It would also be nice to have an elementary player for compiled music, while the commander itself should "hide" in the pages and load music with the player at any address. It would be very timely to have the ability to view standard text files with 42 and 64 characters per line. I would like to have a standard function for saving a copy of the directory on track 159.
And please, also connect 48k ROM and clear all memory when launching programs. It would be just wonderful if you implemented direct and full-fledged work with MS-DOS in the commander. I'm tired of using a text editor to copy files... :-)
4. TOTAL COMMANDER by Dr. L0VE
Be sure to make "hot" keys, as working with windows is too slow. I recommend better color selection in the commander so that it does not look too gaudy; this only hinders the perception of information. It is necessary to implement the ability to launch code files. The ability to choose any mask for displayed files.
BEST VIEWER 2.5 by Ivan Roshin
Just a wonderful thing! I can't get enough of it! What is lacking for complete happiness:
Playback of non-compiled files from "ST-pro" (as in "X-player"). The ability to view texts in a format of 42 characters per line, and perhaps in various encodings (WORD, D.Mikhaylov (Amiga), etc.). Viewing sprite archives in the format "SprGen 5.1" from Real Software. Control from Kempston. The ability to enlarge the window with the file requester when the file lists will go in several rows. Displaying auxiliary system information on the screen (start address and length of the file, disk name, etc.). At the "urgent request of viewers," playback of loaded music in the background while viewing texts, for example. And in general, it would be best to combine "BV" and "Perfect" into a single whole, or supplement "BV" with all the attributes of commanders, focusing on "Perfect"...
In this article, I have covered only a few programs, but if you have any ideas or comments on system soft, write to us, and we will continue this topic in future issues of "RU(S)H". Program creators and their users must communicate and collaboratively make changes and improvements to new products.
We wish you creative success in the creation of system programs!!!
Contents of the publication: Rush #01
- AMIGA NEWS
Amiga Inc works on Amiga OS 3.5 with enhancements like CD drive and PowerPC support. Split development for M68K and PPC processors. Delayed release to late 1999 or early 2000.
- AMIGA NEWS
Description of the 'Fast JPEG 1.10' viewer for Amiga, focusing on its features, installation, and usage. It highlights advantages like fast processing without quality loss and provides user tips. Readers are encouraged to share their software experiences.
- AMIGA NEWS
Basic programming for classic Amiga, discussing challenges and sharing knowledge in Amiga coding. Overview of Amiga graphics capabilities and processor features. Introduction to Amiga assembly language specifics.
- AMIGA NEWS
Overview of events related to the Amiga platform from early to mid-1998. Highlights include new hardware, software releases, and notable company collaborations. Future updates and developments are scheduled for the next issue.
- AMIGA NEWS
Collection of cheats and secrets for classic Amiga games compiled by Postcard Man. Readers encouraged to share their findings on complex games. Selection of tips and level codes provided for various games.
- AMIGA NEWS
Discussion of Phase-5's graphics cards and Permedia 2 processor capabilities. Details on Permedia 2's 2D/3D acceleration and compatibility. Mention of GLINT Delta processors and comparison of prices and availability.
- AMIGA NEWS
Analysis of Amiga's survival in the 90s, highlighting community efforts and technological advancements. Discussion on hardware improvements and software development. Encouragement for further exploration and learning about the Amiga platform.
- Spectrum Programming
Explanation of a fast method for real-time 3D graphics on the ZX Spectrum. Introduces efficient rotation and deformation techniques for 3D objects. Emphasizes improvements over traditional methods with practical examples.
- Spectrum Programming - Ticklish Jim
Discussion of combining sound effects with music for Spectrum's AY chip. Examples from development of 'CSC: Deja Vu' and technical challenges faced. Contains practical guide and code examples.
- Spectrum Programming
Discussion on byte mirroring and background restoration in ZX Spectrum programming, with examples.
- Spectrum Programming
Comprehensive guide for system programmers with practical tips for creating efficient and user-friendly software, including coding techniques, device compatibility, and program testing strategies.
- Spectrum Programming
Advanced coding techniques and modern graphics methods for ZX Spectrum. Tips for optimizing graphical procedures and coding on assembly. Useful advice for programmers to improve performance and efficiency.
- The End
Reflections on the creation of the first issue of the magazine 'Rush', its goals, audience, and future development.
- ZX-SOFT - Вячеслав Медноногов
Development updates on Vyacheslav Mednoy's new game 'Black Raven II', including gameplay changes, new spell introductions, and performance improvements.
- ZX-SOFT
Overview of new features in the updated commander from REAL software for ZX Spectrum, including file management, autodetection, and media viewing. Improvements in text, font, and music handling. Questions addressed regarding future updates.
- ZX-SOFT
Debate on which demo deserved the top spot at Funtop'98: Forever by DR or Refresh by XTM. Discussions in the demoscene community highlight the clash between technical prowess and conceptual depth. Different opinions reflect on the evolution of demoscene preferences.
- Authors
Acknowledgment of contributors and partners in creating Rush magazine. Detailed roles of each author and collaboration insights. Recognition of technical support and media partnerships.
- Virtual Specky
Discussion on converting graphics from PC to Spectrum, featuring insights from various experts. Techniques for improving conversion quality and tools like Photoshop are detailed. Emphasis on post-conversion refinement in Spectrum graphics editors.
- Virtual Speccy
Discussion on the CBSpeccy emulator for ZX-Spectrum on Amiga, highlighting its features, community opinions, and technical performance. Criticisms and praises for its emulation capabilities, particularly compared to PC emulators. Examination of potential improvements and community debates around version updates.
- Virtual Speccy
FAQ on ZX-Spectrum emulation on PC, covering popular emulators and file formats. Instructions for using different emulators and managing file types like Hobeta and TR-DOS. Discussion on Russian ZX-oriented servers and resources for enthusiasts.
- Introduction
Introduction to the Rush magazine, emphasizing creativity, progressive scene, and the goal to create a superior information source. The magazine seeks to gather promising groups and offer a unique perspective. Focuses on content and atmosphere, welcoming creators to contribute.
- Introduction - Grunge
Introduction to Rush, a new scenemag for Speccy/Amiga enthusiasts, aims to provide quality content and news while encouraging reader feedback.
- Interview - Konex
Interview with ANTARES group after FUNTOP-98. Discussion on their demos, challenges, and future plans. Insight into the group's formation and dynamics.
- Interview - Kvazar, DUX
Interview with Alexander Seleznev (KVAZAR), discussing his history with computers, the state of the ZX Spectrum scene, and future plans.
- Interview - Kvazar
Interview with Vitebsk group POWER on demo 'Crazy Love', development experiences, and future projects.
- Informatorium
Exploration of a CD with emulators for various platforms, highlighting Spectrum. Details the content organization and diversity. Concludes with insights from the CD-ROM Project's Spectrum software collection.
- Informacrium
Compilation of interesting and useful Internet addresses related to Amiga resources, including magazines, hardware manufacturers, and software companies.
- Informacrium - Viator
Overview of existing and upcoming publications on the Amiga platform. Discussion of the availability and distribution challenges for Amiga literature. Appeal for collaboration with new publications.
- About the Magazine
Discussion on creating a multi-platform magazine focusing on Spectrum, Amiga, and PC. Emphasis on broader understanding of computer scene. Encourage professionalism and adaptation to changing technology.
- Parallel Worlds
Overview of the evolution of Windows OS and PC processors from 1981 to 2000. Development milestones of MS-DOS, Windows, Intel processors, and competition with AMD and Cyrix. Challenges in maintaining compatibility with new processor technologies.
- Parallel Worlds
Overview of Macintosh models and their relevance in design and graphics fields, covering prices and specifications from 1997-1998. Discussion includes the evolution of Apple's hardware, notably the PowerMac series, and compares new G3 processors with PC counterparts. It highlights the resurgence of Macintosh post-crisis and its ongoing influence in the market.
- Development of the Spectrum - Slider
The article discusses a new graphical extension for the ZX Spectrum that enhances color palettes without increasing resource demands. By using a modified flash signal, new colors are created without interfering with existing software compatibility. The article provides implementation details and addresses practical usage concerns.
- Development of Spectrum
Connecting a CDOS modem to the 'Compact-128' computer by addressing keyboard port conflicts. Description of hardware modifications to solve the issue. Solution includes automatic blocking using a transistor inverter.
- Development of Spectrum - Ars
Discussion on AZX-Monstrum 512K development, its hardware compatibility, processor options, and potential enhancements in graphics and OS.
- Development of SPECTRUM
Discussion of Clive Sinclair's new computer platform, the ZX2000, designed to outperform PCs with enhanced speed, affordability, and battery efficiency.
- Development of Spectrum - Андрей Савичев
Examination of the evolution and ongoing relevance of the Z80 processor, and its role in embedded systems. Comparison of Z80 with its successors, highlighting advantages like energy efficiency and command enhancements. Overview of integrated Z80-based CPUs and their peripherals.
- Advertisement
This article is an advertisement for Scorpion products including hardware for ZX Spectrum and Amiga software, along with pricing and ordering details.
- Advertising
Collection of advertisements for Amiga and ZX Spectrum hardware and software, with contact information for sellers and details about the new Amiga magazine subscription.
- Advertisement
Advertisement for X-TRADE's General Sound music board. Includes pricing, technical details, and purchase instructions. Features a FAQ section and compatibility info.
- Meaning Without Meaning - Viator
Philosophical reflections on existentialism, immortality, and human destiny. The narrative weaves through stories of ambition, the quest for eternal life, and a utopian downfall. A blend of introspection and speculative fiction.
- Scene vs Professionals
Exploration of the demoscene's creativity versus commercial game development. Discussion of potential for professional-quality programs by scene members. Call for collaboration with leading scene groups.
- Scene Chronicle - Андрей Савичев
Reflections on ZX Spectrum's enduring appeal, its community's resilience, and its potential resurgence in Russia.
- Scene Chronology
Overview of the Rush group's activities, including past projects, current endeavors, and future plans, with emphasis on software development and gaming.
- Scene Chronicles
The article discusses various ZX Spectrum scene news, including game releases, demoparties, and updates from developers and teams.
- Chronicles of the Scene
The article discusses the FUNTOP'98 international computer art festival held in Moscow, highlighting key events, notable attendees, and the various competitions held during the event.
- Scene Chronia
Discussion on Amiga scene development through collaboration, addressing user isolation and promoting network expansion.
- Shell Management
Статья описывает управление оболочкой для ZX Spectrum и Amiga, включая клавиши и функции для навигации. Упоминаются особенности работы на Amiga с PAL монитором и предоставляется контакт для поддержки. Также отмечено, что текстовые файлы имеют стандартную MS-DOS кодировку.
