Eh
ZXNet echo conference «code.zx»
From Valery Grigoriev → To All 17 October 2006
Hello Vitamin
I overpowered myself, once again
I immediately understood the vitamin, but the majority of the participants apparently didn’t get it
the spirit of the idea - as the sophists say, “before rejecting an idea, one must penetrate it
spirit"
Vitamin asked - what is the idea anyway?
I think the idea is great and I give the idea 5 points.
Next, what’s bad about the idea.
As already noted, inertia of thinking and, as a result, inertia in creation methods
software products on Speck. But that's not what this is about.
It seems to me that most of the misunderstandings stem from the fact that there is not enough vitamin
clearly explained what this would do. And I will try to do this.
Here's the general idea.
Each of us has encountered, when writing our programs, the need to draw
1 single character in a given familiarity from a given font (located
in memory). Standard RST 8 seems to me only at the dawn of programming
used - everyone now uses their own code for this. Even if
you need to draw a symbol with 8x8 dots (which is not always true). Here's the first one
challenger - the procedure for drawing characters. (don’t rush to write here
"refutation", be patient and read the thread to the end). Call - in the program -
to the external point Call Scr.PrintChar8x8 (the first part of the function name indicates
its module is Scr module)
Each of us has faced the fact that there is no effective procedure for working withdisk (again, the standard #3D13 is too slow, and even the
opportunities are sometimes significantly limited). Here I rule out this kind of
problems such as (full) hard disk support, working with extended file
TRDOS Directory System, etc. Therefore, the second contender is a binary for
working with media, including files. Call Disc.FileRead,
Disc.SectorRead, Disc.SectorWrite. By the way, it is not a fact that even those procedures that
now available for download they work well - I wrote it specifically for myself
a very cunning disco-chewing procedure that works not sector by sector but track by track,
which reduces the time required to resolve read errors and reduces
"fucking" of disk drives, saving their resource, among other things, but again not about
this is speech. Module - Disc.
Keyboard polling module.
It's no secret that the keyboard manager hangs on Speck interrupts again
leaves much to be desired - there is no buffering of pressed characters, there is no possibility
(through it) determine the pressing of function keys - such as SymShift,
CapsShift; Russian-language support is generally from the realm of fantasy. KB.ReadKey
- reads the key pressed by the user. KB.Clear - clears the buffer. Module
respectively - KB.
Module for drawing various frames - Window. Window.Show - draws
window There may even be a whole system that takes into account the mutual closure of windows(i.e. when one window is partially covered by another, and then this is the rear window
pops up).
Arithm arithmetic module - works with fast integer
arithmetic (the speed of the SOS ROM calculator leaves much to be desired, although
There is certainly a lot of functionality there). Arithm.16mul16 - multiplies two 16-bit
numbers. Arithm.16div16 - makes one 16-bit to another.
Memory module - RAM. RAM.ChangePh - change the memory page to the specified one
physical. RAM.ChangeLog - change the memory page to the specified logical one.
And so, I want to write a boot, I want to write a text editor, I want to write
viewer, I want to write a toy. Which of these treatments will I use?
That's right - all of them. And yet, in the current environment, each of the programs
uses his cart and cart - where all this stuff is stored, and what’s more - according to
due to the closedness of the outcomes, the reluctance of the author to engage with the program, etc. and
etc. there are glitches in the programs, which (90%) are a consequence of crooked
written listed procedures. Those. a disk full of programs
Spekkov's disk de facto repeats itself almost 90%. In addition, often
these procedures are attached to the text in the form of a kind of addition to each of
launched programs - as a result, the already limited number of valid
file-cells in TRDOS are used ineffectively.And now let's see how it can be - there is 1 pak file on the disk, there is 1 boot.B
and a piece of code for it and there are a bunch of starters - files, say, with the extension R
(taken arbitrarily, by the way they can also be in the form of one file, and in general
here the file structure is not so critical). These starters can also be BASIC
programs and just code - this is not so important. It is important that boot.b will load when
start the linker (or compiler, if you like), which will already work with
the specified modules lying in the pak file.
I would like to emphasize such an important point from my point of view - modules
are actually complete Z80 machine code with the only difference being that
it is accompanied by a relocation header in order to be able to merge these
modules with a head program. However, it is better to read the documentation for the modules and
It will become clear that accusations of pissyukanism and Amigaism are meaningless here.
And so, I launch my favorite viewer - and what? in fact, MY will load
logic implemented in the Z80 code - my code (I’ll call it individual code) -
i.e. only that, in general, that’s what had to be written in order to have a bunch of
libraries turned into a viewer [the bulk of existing software
zoo is imperfect due to the fact that the coder, having implemented his logic,
which is actually the highlight of the program, I should also writeprocedures for practicing the specified actions - working with disks, keyboards,
arithsetics, memory, etc.] - the code will simply pull the necessary functions and I will not
I will think about implementing a universal memory driver (except in the case
when it's too slow for me, but that's about 1% of the time
code descriptions), I won’t think about where to go for a keyboard survey,
I won’t even think about what device I’m working on now - because
the driver will already do this because it is included in the program - and so on.
Now, I pressed reset. I got tired of the viewer, I wanted to type text - and that’s all
the same thing - only MY individual code and all other modules were loaded
picked it up yourself.
By the way, there is a very interesting option here: the modules will not even be located on the
disk, but let's say on a hard drive, or for example in the second drive there will be a disk with
modules - i.e. There will even be no need to write libraries to the target disk.
The general idea of the vitamin is this: behind each of the programs there is a huge trail
re-written procedures (it's really time to do away with
invention is great), which can and should be used in a standard form and
thus tightening and increasing overall efficiency
software production.
Finally, I want to compare two approaches - which, it seems to me, are somewhatin the sense of competing - 1) when there are SOURCES of all procedures used and
during the compilation process everything is collected into one final file 2) when available
modular structure and only individual code is actually compiled.
1) possibility of expansion 100% due to third-party code; possibility of substitution
source possibly buggy libraries - only when recompiling all the code;
the number of required files (in kilobytes and in pieces) is large
2) there is no possibility of extension, this is a ready-made code - only when
recompilation; possibility of replacing libraries - 100% due to modularity
organizations; The number of required files (in pieces and kilobytes) is small.