Oberon #04: About Everything: Reflections and Techniques

M.M.A/SPEED CO. 

There was once a good printing magazine "ZX-REVUE" ..... It was, but sadly, it has completely ceased to exist! And on the ashes of its last issue, there remained an unpublished article written by me and Max Vasiliev specifically for this publication.

And although the following text was typed in the early days of 1997, it has not lost its relevance and sharpness. So I decided to include this material in the fresh issue of OBERON. Good things shouldn't go to waste!

However, there was one small problem....... The text of the article was written in the language of "ZX-REVUE" and for the readers of "ZX-REVUE". Naturally, everything needed to be redone. However, since the prospect of completely rewriting the article did not entice me at all, I decided to leave everything as it is.

So, let us "mourn" for the untimely departed TRUE Spectrum magazine - "ZX-REVUE"!

(C) MAXSOFT / SPEED CO.
(C) M.M.A / SPEED CO.
Samara 1997 a.d.

BOOT program in one sector.

Since the days of the first computers with the TR-DOS system that appeared in our country, hackers and programmers have not ceased to solve the greatest problem of modernity: why, how, and what boot loader to write??? Those interested in the question of modern boot construction, I will allow myself to refer to the article dedicated to this very topic, which was published in the third issue of the Samara electronic magazine "OBERON". In this article, using the example of writing a boot program, we will consider the implementation of ultra-short programs in assembly language, as well as the possibility of rational use of standard ROM and TR-DOS procedures in such programs.

It is worth noting that attempts to create ultra-short boot loaders have already been made, and quite successfully. For example, the boot written by Shi-soft in 1992 occupied two sectors and worked quite well. I fundamentally do not speak of length in bytes, as due to the use of non-cassette information carriers (floppy disks and consequently, disk OSs, such as TR-DOS), the concept of program length in bytes is unambiguously replaced by the concept of length in sectors. And in the case that your procedure has a size of 260 bytes, and if it occupies 460 bytes, still, when written to disk, a file with a volume of two sectors will be organized. Thus, if your program is closely related to DOS, it makes sense to choose its maximum size, which is a multiple of the size of the standard TR-DOS sector, and subsequently try to use every byte (bit) of that memory volume.

We have somewhat digressed from the topic, let us return to our boots! Another example of a two-sector boot loader is the program by D.Pyankov SMALL BOOT, distributed by INFORKOM. As stated in the description of this program: "The main feature is the small volume (2 sectors), which ensures fast loading." It is quite obvious that with a size of one sector, the loading will be even faster, and such a boot occupies virtually no space on the disk. The embodiment of this seemingly absolutely mad idea was taken up by two Samara programmers.

Since the inception of this idea in my (M.M.A) head, about a year and a half has passed. At that time, I was not sufficiently experienced in programming, so I simply shared the thought of writing such a masterpiece with other Samara programmers. As a result, in fierce competitive struggle, the one-sector boot was not just written, but written so optimally that I fear that the readers of "ZX-REVUE" will not be able to optimize anything further. Although, if one does not look at the listing provided below, and tries to implement this idea, so to speak, from a "clean slate," perhaps, dear readers, you will find some new, unconventional solutions. Another matter is the change of functional features...

The complete disassembler of the boot with comments on almost every command can be found at the end of the article. There, you will also find a dump of the boot and notes on merging the code block and BASIC. We will continue the topic of changes and see what and how can be changed in this (base) version of the boot.

In this version, program control is carried out using the SINCLAIR JOYSTICK and the keys "Q", "A", "O", "P". File selection - "0", "ENTER", reading a new directory - "SPACE". As you can see, control from the SINCLAIR joystick is somewhat excessive, and if desired, you can throw it out and insert something else.

For example, a bold font would give a good effect!

Storing an additional character set in memory is already three sectors (768 bytes), and using the methods of creating fonts with the use of the standard ROM font, which have been described many times in ZX-REVUE, is also not possible - too many bytes! The solution must be unconventional and simultaneously simple. What if we first print everything on the screen with the normal font, and then perform the following operation on the screen:

ORG 30000

LD HL,#4000
In HL - the starting address of the screen
LOOP1 LD A,(HL)
Open the loop, load the content of (HL) into A
SRL A
Shift A right (or SLA A - left)
OR (HL)
Overlay A on the original byte on the screen
LD (HL),A
Place the result on the screen
INC HL
Increase the address on the screen by one
LD A,H
Load the value of H into A,
SR #58
and check if it has reached the upper byte of the attribute area (#5800)
JR NZ,LOOP1
Repeat the loop if HL < #5800
RET

In principle, the procedure in listing 1 is operational, and occupies only 14 bytes. But for an ultra-short boot, even this is too much! Further refinement of the procedure can be carried out by changing the principle of determining the end of the screen area. The algorithm for thickening is already optimal.

ORG 30000

LD HL,#57FF
In HL - the very last byte of the screen
LOOP1 LD A,(HL)
Load the content of (HL) into A
RRCA
Shift through RRCA (shorter by one byte!)
OR (HL)
Overlay on the original
LD (HL),A
Copy back to the screen
DEC HL
Decrease HL
LD A,H
Check the content of H for 0
OR A
JR NZ,LOOP1
If HL > #OOFF, then repeat the loop

RET

In this case, the byte counting goes "upwards," and does not end at #4000, but passes through the entire ROM (there, of course, nothing is changed) and reaches address #0100. Using this method, we save another two victorious bytes and obtain a procedure with a length of 12 bytes.

Some inconvenience lies in the fact that while the program "goes" through the ROM, a fairly large number of processor cycles are spent and the user begins to notice how you are thickening the characters. On the one hand, this is not bad - it creates a very interesting effect, but if you fundamentally dislike it, then try the following:

Immediately after the DEC HL command marked in the previous listing, type:

BIT 6,H
Check if the sixth bit is set in the address recorded in HL. If set, continue the loop, otherwise - exit.

JR NZ,LOOP1
RET

To understand how this condition works, let me explain that all those addresses that can be in the HL register when working with the screen have the sixth bit set (#40 = %01000000), and starting from address #3FFF (#3F = %00111111), this bit is reset. This principle is how the end of the screen area is determined. We did not save any bytes on this, but it works faster than the version with checking H for 0. But can we save even more? Naturally, we can! Look at the comments to the boot listing. Everything is built on the fact that the subsequent procedure uses the data from the previous one.

If before calling the thickening procedure, the value #FF is in register L, then we simply need to load the remaining half of the register - H.

Replace LD HL,#57FF in listing 2 with LD H,#57 and do not forget that register L should have the value #FF left over from the previous procedure. And now we have a procedure of 11 bytes - quite normal for our one-sector offspring. Only the situation with register L is unclear. Is it necessary to load it at all? If we assume that at the moment the procedure starts, register L contains a completely random number, then by the end of the work we will simply have unthickened bytes from one to #FF in the lower third of the screen in the lower part of each character cell! But in the ROM font, as far as I remember, only the comma and some symbols use the lower line of the character cell. And since these symbols are rarely found in file names, we can safely leave only register H loaded.

ORG 30000
LD H,#57
LOOP1 LD A,(HL)
RRCA
OR (HL)
LD (HL),A
DEC HL
BIT 6,H
JR NZ,LOOP1
RET

Here it is - the optimized version of thickening the entire screen, which you, dear readers, can insert into our one-sector boot instead of additional control from the SINCLAIR joystick.

Our main goal was to show you how to think when writing ultra-compact code. Moreover, we want to throw the idea of a one-sector boot into a brainstorming session for the entire country. In our heads, this idea has already reached full optimization. But we would be very happy if any of the readers suggested something new, interesting, that would make one want to say, as in the famous advertisement: "FRESH...."!

And here is the boot loader with a length of one sector:

ORG #5D3B

AUTHOR EQU #5D52
FILE_R EQU #5D52

;BASIC LINE FOR LAUNCH

DEFB #00,#01,#F8,#00,#E7,#C3,#A7,#3A

DEFB #F9,#C0,#B0,#22,#32,#33,#39,#30

DEFB #35,#22,#3A,#EA,#3A,#F7,#22

;AUTHOR INFORMATION (AT LEAST 8 CHARACTERS)

DEFB 23,11,32,"MAXSOFT'96"

DEFB #22 ;END OF BASIC LINE
DEFB #D ;"FREE" BYTE

;1 SECTOR BOOT
;IDEA BY M.M.A SOFT/SPEED CO.
;CODED BY MAXSOFT/SPEED CO.
LD (IY+#53),#5
;SETTING PAPER COLOR IN CELL (#SC8D)
;BORDER ALREADY SET FROM BASIC
NEW_DISK ;READING DISK
CALL #D6B ;CLEAR SCREEN
;ON EXIT DE=#0000,HL=#50E0,BC=#1721
;LOAD DISK CATALOG FROM ADDRESS #6801
ADD HL,BC
LD BC,#905
PUSH HL
CALL #3D13
;PRINTING AUTHOR INFORMATION
LD DE,AUTHOR
LD C,#D
CALL #203C
LD A,2
;OPENING PRINT STREAM TO SCREEN
CALL #1601
POP HL
LD D,H
LD E,L
SORT ;SORTING CATALOG
LD BC,8
DEC (HL)
JR Z,NEXT_F ;DELETED FILE
INC (HL)
JR Z,END_SORT ;END OF CATALOG
PUSH HL
ADD HL,BC
LD A,(HL)
POP HL
CP "B" ;FILE TYPE
JR NZ,NEXT_F
PUSH HL
LD A,#20 ;PRINT "SPACE"
RST #10
MAKE_FILE
LD A,(HL) ;PRINT
RST #10 ;LETTERS
LDI ;AND ITS CARRIAGE
JP RE,MAKE_FILE
;(FOR DENSIFYING CATALOG)
LD HL,#70D1 ;FILE COUNTER
INC (HL)
LD A,(HL)
FILE_C
SUB 3
;CALCULATE IF
;THREE FILE NAMES ARE PRINTED IN ONE LINE
JR Z,FILE_C1
JR NC,FILE_C
LD A,#20 ;NO, NOT PRINTED
RST #10 ;-PRINT "SPACE"
FILE_C1 ;YES, PRINTED
LD A,#20
RST #10
POP HL
NEXT_F
LD C,#10 ;MOVE TO NEXT
ADD HL,BC ;TO NEXT FILE
JR SORT
END_SORT ;END OF SORTING
NEW_CUR ;REGISTER B=0
LD C,B
;REGISTER C - FILE COUNTER
MOVE_CUR
LD HL,#57F5
LD DE,#B
XOR A
;REGISTER A - TEMPORARY COUNTER
MOVE_C1
LD B,3
MOVE_C2
ADD HL,DE
;CALCULATE CURSOR POSITION
CP C
JR Z,CURSOR
INC A
DJNZ MOVE_C2
DEC HL
JR MOVE_C1
CURSOR ;DRAW CURSOR
LD B,#A
LD DE,(#70D3)
LD (#70D3),HL
LD A,5
CURSOR1
LD (DE),A
;ERASE OLD CURSOR
INC DE
LD (HL),#16
;DRAW NEW CURSOR
INC HL
DJNZ CURSOR1
LD HL,#5C08
;RESET SYSTEM VARIABLE (LAST-KEY)
LD (HL),B
KEYS ;KEY QUERY
LD A,(HL)
CP " "
;SPACE - RELOAD DISK
JR Z,NEW_DISK
CP #D
;ENTER - START PROGRAM
JR Z,START_F
CP "0"
;0 - START PROGRAM
JR Z,START_F
CP "7"
JR Z,L_RIGHT
CP "6"
JR Z,L__LEFT
CP "8"
JR Z,L__DOWN
CP "9"
JR Z,L____UP
OR #20
;ENABLE UPPER REGISTER FOR LETTERS
;KEY QUERY INDEPENDENT OF
;"CAPS" MODE
CP "p"
JR Z,L_RIGHT
CP "o"
JR Z,L__LEFT
CP "a"
JR Z,L__DOWN
CP "q"
JR NZ,KEYS
L____UP ;CURSOR UP
DEC C
DEC C
L__LEFT ;CURSOR LEFT
DEC C
JP R,MOVE_CUR
;CURSOR HAS NOT REACHED THE START OF CATALOG
LD BC,(#70D1)
;CURSOR - AT END OF CATALOG
DEC C
JR MOVE_CUR
L__DOWN ;CURSOR DOWN
INC C
INC C
L_RIGHT ;CURSOR RIGHT
INC C
LD A,(#70D1)
DEC A
CP C
JR NC,MOVE_CUR
;CURSOR HAS NOT REACHED THE END OF CATALOG
JR NEW_CUR
;CURSOR - AT START OF CATALOG
START_F ;START FILE
LD A,C
INC A
LD C,L ;REGISTER L=8
LD HL,#67F9
;ADDRESS OF CATALOG START MINUS 8
ST_F1
ADD HL,BC
;CALCULATE POSITION OF FILE NAME IN CATALOG
DEC A
JR NZ,ST_F1
LD DE,FILE_R
;COPY FILE NAME TO BASIC
LDIR
JP #3D03
;EXIT TO BASIC WITH STARTING FILE
Listing 4
1. TYPE THE TEXT BOOT'A IN ASSEMBLER.
2. EXIT TO BASIC. DELETE ALL BASIC LINES RELATED TO ASSEMBLER AND CREATE
YOUR LINE OF LENGTH 248 BYTES, I.E. COMMAND PRINT REEK 23869 SHOULD SHOW
248. IN THIS CASE, IT IS UNDESIRABLE TO USE BASIC 128 EDITOR.
3. RETURN TO ASSEMBLER AND PERFORM
ASSEMBLY.
4. EXIT TO BASIC AND SAVE BASIC-PROGRAM-
MING :

Regarding improvements and changes.
In the basic version of the boot provided in listing 4, there is 1 free byte. Its use for additional service
capabilities is practically unrealistic. However,
it is realistic to try to print files
not in three columns, but in two, and then new and
new freed bytes will open up
the possibility for all kinds of new features
within the same one sector of disk space.
In general, if it turns out that we have sufficiently optimized the idea of one-sector
boots, and readers cannot even carve out
an extra byte, then we suggest holding
a competition for the most convenient and powerful seven-sector loader. Such a boot is very convenient
because it can be located in unused sectors of the zero track. In this
case, it turns out that the boot does not occupy
any sector on the disk.
Moreover, if in one/two-sector
boot loaders it is only about providing minimal service, then in seven-sector
boots one can use
auto-loading disks, beautiful effects in the background (stars, snow) and much
more.
P.S. And most importantly, remember: "Any procedure
can be optimized to such an extent
that it will consist of a single NOP command and still perform everything required of it."
Such a good article it was..... However,
since we publish it in electronic, and
not paper magazine, there is an opportunity
to make your life a little easier!
In the appendix to the magazine, you will find two ready-to-use versions of the "one-sector" boot:
1SBOOT_M (version by MAXSOFT)
and
1SBOOT_R (version by POLTERGEIST)
The version from MAXSOFT was described in detail
in the article you read, while the version from
POLTERGEIST is approximately the same, but with
different functional features. Moreover, this version appeared a little
earlier and is therefore programmed a bit differently. How? You will figure it out yourself when
you disassemble it!
And for the most inquisitive minds, two files are recorded on the disk
in the format of the ZX-WORD editor:
1S_boot+. (listing with comments)
and
1S_boot-. (listing without comments)
The first file is convenient for converting to
assemblers with an editor of 64 characters per
line and supporting Russian font in
alternative encoding. An example of such an assembler is the ALASM4X8 version,
while TASM x.xx, although it supports 64 characters per line, but "breaks" on Russian comments.
For all those who do not use ALASM,
the second listing is intended. It lacks comments in Russian and the line length does not exceed 42 characters.
This file can be loaded directly into
TASM 2.0, and with the Import option
TASM 2.0 and into assemblers TASM 3.XX, TASM
4.0 (XLD), TASM 4.XX (RST#7).
How to convert text into other types
of assemblers, I hope you will figure it out
yourself.
Good luck!
-════════════════════════════════════════ * * * * *
MUSIC BY: VISUAL/MS/XTM

Contents of the publication: Oberon #04

  • From the Editorial
    This editorial discusses the legal 'charges' against the creators of Oberon #4 as a humorous narrative, highlights the challenges faced in publishing this issue, and announces a potential hiatus for the magazine.
  • Scroll
    Analysis of the game 'Chaos' by Julian Gollop. Simplified gameplay mechanics and strategic elements. Description of creatures, spells, and tactics.
  • Scroll - Unbeliever
    Description of a mathematical game for ZX Spectrum where players collect formula symbols while navigating gears.
  • Scroll - M.M.A
    Discussion of 'Doc the Destroyer', a unique fighting and adventure game for ZX Spectrum. The article covers controls, character customization, and game mechanics. Compatibility issues on different ZX Spectrum models are also addressed.
  • Overview - M.M.A
    The article provides a review of games for ZX Spectrum, including KOMANDO 2, WRESTLING SUPERSTARS, TAG TEAM WRESTLING, and CAPTAIN PLANET. It highlights the features, graphics, and gameplay of each game, noting both strengths and weaknesses. The review concludes with recommendations and comparisons to other platforms and games.
  • Overview
    Overview of various ZX Spectrum games, highlighting their unique features, gameplay mechanics, and design elements. Includes critique on sound effects, graphics, and technical issues. Discusses games like 'Stryker in the Crypts of Trogan', 'Phileas Fogg's Balloon Battles', and 'Survival'.
  • Overview - Alex Noman
    The article reviews games for the ZX Spectrum, including BOOVIE, MOTOR MASSACRE, SOCCER PINBALL, and HUXLEY PIG 1 & 2. Each game is detailed in terms of gameplay, graphics, and unique features. The discussion includes comparisons to other games and highlights specific technical aspects.
  • Review
    A review of various games, including Little Computer People and Lost Caves, highlighting their features and versions. It also discusses 75Occ Grand Prix by Codemasters with its limitations. The article provides insights into game mechanics and versions.
  • Review
    Detailed review of various assemblers like Alasm 3.8, TASM 4.12, and others, highlighting their features and shortcomings.
  • About Everything
    Announcement of the creation of the SamZxNet network in Samara and the challenges of setting it up with HAYES modems. Explanation of the modems' power requirements and potential difficulties. Invitation for technical advice from experienced readers.
  • About Everything
    Description of travel to ENLIGHT'97 and meeting various demoscene participants. Observations of event organization and issues. Insights into participant experiences and scene discussions.
  • About Everything
    Report on the second day of ENLIGHT'97: events, challenges, and reflections. Describes voting results and organizational difficulties. Highlights future prospects for Spectrum demo parties.
  • About Everything
    The article features reader feedback on Oberon #04, critiquing design and content choices and discussing issues with software protection and game enhancements.
  • About Everything
    Discussion of the adventure game KAYLETH with gameplay tips and advice. Includes a game dictionary and suggestions from the author and their team. Calls for a local artist for future RPG development.
  • About Everything
    Reflection on the closure of the 'ZX-REVIEW' magazine and the adaptation of its article for 'Oberon'. Discussion on the development of ultra-short boot loaders. Optimization techniques for writing one-sector boot loaders on ZX Spectrum.
  • About Everything
    Exploration of amateur contributions to electronics, music, and computing history, highlighting figures like Faraday and Babbage. The evolution from handmade instruments to personal computers. Discussion on jazz, blues, and rock'n'roll's informal origins.
  • About Everything
    The story of Lieutenant Edward Roberts' journey from radio kits to creating the first PC, the Altair 8800, overcoming skepticism and challenges.
  • About Everything
    The article explores the rise and evolution of the computer industry, highlighting the transformation from passionate hobbyists to corporate dominance by giants like IBM and Microsoft.
  • About Everything
    An exploration of Sir Clive Sinclair's project after selling the Sinclair brand, detailing the features of the Cambridge Computers Z88 laptop.
  • About Everything
    Discussion of software market problems in 1997 for ZX Spectrum, highlighting lack of new software and user reluctance to pay.
  • Announcement - M.M.A
    Announcement of 'Black Raven' game by V. Mednonogov, focusing on gameplay, technical challenges, and upcoming features.
  • Announcement
    Discussion of the decline in ZX Spectrum development, reviews of new games and utilities, and announcements of future projects.
  • Educational Program
    The article provides an overview of FidoNet, a non-commercial computer network often considered the predecessor of the Internet, detailing its origins, growth, and unique cultural aspects.
  • Hardware
    Instructions for connecting the 'ALEGRO' modem to computers with normal port #FF, detailing hardware modifications required for proper signal handling.
  • Hardware
    Connecting Hayes-compatible modems to ZX Spectrum, focusing on Scorpion and Pentagon models, detailing hardware modifications. Specific instructions for internal port blocking and signal alignment provided. Step-by-step process and technical intricacies explained.
  • Hardware
    Discussion of the transition from 5.25' to 3.5' floppy disks for ZX Spectrum, including installation issues and solutions for compatibility with existing software.
  • Let's Feast
    A satirical story about a Rabbit who lost his house to a cunning Fox and how a Rooster helped him reclaim it.
  • Let's Gourmet
    A humorous tale about Malysh and Karlson's adventures with technology, drawing parallels between computers and everyday life, culminating in a comic mishap with an AMIGA computer.
  • Advertising
    Article discusses free advertising policy of Oberon, catalog of programs and hardware for ZX Spectrum, and adventure game engagement.
  • Advertisement - Kano
    Promotional campaign by Magic Soft and RPSG in Russia for Amiga multimedia computers, offering exhibitions, sales, and consultations. They highlight Amiga's advantages over other systems, describe various models, and provide price lists. Collaboration with 'Computers for Population' for distribution and services.