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.