New project.

Hello All! Well, in my own words, I bought a computer, it’s not the same as I wanted, but still faster 386, therefore I am, in principle, ready to implement the subject. Who will be the kicker? At the moment there is a raw (founding text) of the project. Ready to discuss, correct, add. The team searches for and also solves all problems of the organizational plan. 560-18-98 Oleg Jr. 20-24 WBR, Light from DCG aka Oleg Dokuki

Let your enemies, Vladimir, die without sons! 26 October 2000 at 21:28, Vladimir Larkov => Oleg Dokukin: OD>> I discussed the project with a bunch of people, and damn everyone asked me what are you doing OD>> Oleg - decided to write an operating system. The answer is NO, NO, NO, NO. VL> Well then, good, otherwise everyone has rushed to write operating systems and no one has yet VL> added ;) and they won’t finish it. because there is no theoretical basis. I have a little - me and I haven’t been twitching in this direction for a long time. :) [WBR, Oleg. ] [ 13:50 7 November XXXV A.S. ]

Let your enemies, Wsewolod, die without sons! 29 October 2000 at 11:33, Wsewolod Shashkin => Vladimir Larkov: VL>> no one has finished writing yet ;) WS> Why is it so bad???? D. Tsikritais, F. Bernstein "Operating Systems" - for starters. there is the answer to your question. :) [WBR, Oleg. ] [ 13:54 7 November XXXV A.S. ]

Greetings, Oleg! November 7, 2000 (it was 1:53 pm then) Oleg Grigoriev in his letter to Vladimir Larkov wrote: OD>>> I discussed the project with a bunch of people, and damn everyone asked me, are you OD>>> that Oleg planned to write an operating system. The answer is NO, NO, OD>>> NO, NO. VL>> Well then, good, otherwise everyone rushed to write operating systems and no one else VL>> never finished writing ;) OG> and they won’t finish it. because there is no theoretical basis. I have OG> a little - I haven’t been twitching in this direction for a long time. :) and also because no one cares about the operating system. as personal experience has shown - they love just discuss how cool it will be....(insert the name), but you propose look at something that already exists and suggest what else should be placed there - deathly silence. We were able to make more than 40 versions of the kernel while we were bringing it to more or less working condition and were not shown to anyone and only 3 versions after, because it turned out that no one really needed this job. it remains that way about 200 kilos of kernel sources (1 year of work) and about 250 kilos for the compiler assembler, 97% ready - to timid remarks that he should soon appear (compiler) not a single response was received - they didn’t even notice!In this regard, enthusiasm has faded and will not appear again - why? not to anyone necessary... All the reviews were only about the interface (great, the graphics are poor :) - again, coders, without whom no system can live, were too lazy to look into the documentation and see that nothing is fixed... P.S. We were talking about MythOS. Best regards, Artem

Greetings, Ivan! November 09, 2000 (it was 09:21 then) Ivan Bogomolov in his letter to Artem O. Kozakov wrote: AK>> P.S. we were talking about MythOS. IB> Uh.... I understand that MythOS will not develop further? I hope IB> that I'm wrong... ps Abydna, dammit... :( unfortunately, you're right. due to the complete lack of even rudimentary interest in For this development, all work has been discontinued. and since this was the last project for our group has a Spectrum, nothing else is expected, although Graphic was planned Station 2.0 for MythOS, RAD system for it. If anyone is interested, I can give you the assembler sources and the MythOS kernel version 0.4 Best regards, Artem

Greetings, Kirill! November 09, 2000 (it was 10:10 then) Kirill Frolov in his letter to Artem O. Kozakov wrote: AK>> and also because everyone doesn’t give a damn about the operating system. as shown by personal AK>> experience - they only like to discuss how cool it will be....(name AK>> substitute), KF> So. It took almost 10 years for iS-DOS to be perfected. And here we played and KF> tired. And I’m not entirely right about the OG base, when Linus started his KF> I was also a student who wrote the operating system. no, I'm not tired of it. That’s not why they put all their experience working with Spectrum (and not only with Spectrum) so that you get “tired”. the reason (IMHO) is friend - it’s just that the train has already left and no one needs the OS for the Spectrum. It looks like no more or less intelligent developer will take on software for the Spectrum anymore will not happen, too much effort is required, and the return is too low (more Moreover, there is no return, sometimes they won’t even say thank you :( We tried, nothing were not shown until some code quality acceptable to us was achieved, and when they reached it, alas, it was too late. Apparently about 5 years ago this work might have been in demand. AK>> All reviews were only about the interface (great, about the graphics AK>> pathetic :) - again, coders, without which no system can live AK>> were too lazy to look at the documentation and see that there is nothing AK>> fixed... AK>> P.S. we were talking about MythOS. KF> But I wasn’t too lazy - they created something inappropriately reminiscent KF> everyone's facked up Pink Floyd. Doesn't suit the operating system. I KF> of course (small digression) as the author, I cannot agree that MythOS compared to Pink Floyd. IMHO, I guess (as far as documentation for Pink Floyd allowed me to form my own opinion) the level of complexity of MythOS structures is much higher and offers significantly more opportunities for the programmer, and glitches a little smaller :) KF> I don’t understand anything about operating systems with a capital letter, but tell me, KF> what program can be downloaded in 16kb? Cool, of course, something KF> they came up with something like dll-ok, I’ve never seen anything like this on spec anywhere else. for this purpose, shared libraries, which can house everything from code and program data to system objects, fonts, resident programs, etc. and etc., in order to get as far away from the 16 kilobyte limit as possible.The experimental version of the assembler for MythOS in my experiments took for my code several pages (along with some service data) and used arbitrary number of pages for user data (tags, processed text) and there are no inconveniences - all compiler modules are in separate libraries, which, when the head starts, are dynamically placed in free memory areas and are connected to the head module by pointer tables and your own (honestly borrowed from the kernel) message numbers. where 16 kilo limit? It is much more difficult to write a large program under tr-dos... Again, the restriction on a continuous code section of 16K is partially lifted code reuse - and an unfinished text editor (done in as an object inside the library) could be built into any application, running in the system - from a primitive settings editor to an IDE assembler, with this is the same code, the next copy of the editor consumes memory only for it variables and user data. IS-DOS can divide its modules between programs? or maybe Pink Floyd maybe? A good example of kernel extensibility and MythOS graphics subsystem in particular is a collapsing support library windows winman.lib - written completely without connection with the kernel, it simply exports to any program that wants to support collapsing the collapse button. AndAll! There is no need to add code to the program itself. library uses only documented kernel functions, no gags that are known only for developers (I specifically made the library so that they would look at object capabilities of the kernel), they gave all the sources - the screams continued anyway - Masdai design :) it seems difficult to redraw the system graphics (regular font), use the dock to stick it in the right place and enjoy the new look :) or write your own library of primitives and use it, who forbids it? Therefore, we concluded that unfortunately the project was late, by and large not necessary and therefore does not require further development. Actually, I personally may I would like to continue again, but I don’t understand the internal structure at all kernels... KF> Yes, and here the problem is in *HARDWARE* for the most part... unfortunately, yes. Best regards, Artem

Greetings, Denis! November 10, 2000 (it was 5:26 pm then) Denis Ognewsky in his letter to Artem O. Kozakov wrote: AOK>> @PID: GEDW32 3.0.1-asa9.1 DO> well, everything is clear. so? what is clear? yes, emulator. Have I ever argued otherwise? Sorry, Then I don’t understand this expression of irony. AOK>> expected, although Graphic Station 2.0 for MythOS was planned, AOK>> system DO> but this is especially pathetic. :~( the author gave up on this. I didn’t see that anyone was interested in such work. AOK>> RAD for the same. DO> what is this? is it really an analogue of the Amiga RAD? By RAD I mean Rapid Application Development, something like the same Delphi for Spectrum. (specifically for MythOS) AOK>> If anyone is interested, I can give you the assembler sources, yes AOK>> and MythOS kernel version 0.4 DO> understanding other people's sources is difficult. It's easier to write again. a DO> here is a description of the architecture and other things that would be very useful to read. everything went through ZX.SPECTRUM in decent quantities, including source codes almost all applications and libraries with comments, documentation onfunctions, etc. If you haven’t seen it, I can send it, but if you have seen it and something is not clear, I could tell. But why is this necessary... Best regards, Artem

Glad to see you Artem! Once, namely 12 Nov 00 Artem O. Kozakov wrote to me: AOK>>> @PID: GEDW32 3.0.1-asa9.1 DO>> well, everything is clear. AOK> so what? what is clear? yes, emulator. Have I ever argued otherwise? AOK> Sorry, then I don’t understand this expression of irony. a person who buys a pussy is initially convinced that it will only enhance his productivity. well, it’s a pisyuk - access to networks, a source of graphics, information carrier. Gradually all the floppy disks are moving there. this is really very convenient. then emulators start. thus the man smoothly moves onto the pussy. sooner or later the emulator starts less and less often. time is spent listening to mpegs, reading mail and installation of all sorts of rubbish downloaded from the Internet or companies. then follows increasingly rare appearance at Spectrum-themed conferences and finally a statement to the people about the cessation of all activities on the ZX.SPECTRUM platform. At the same time, all activity on the new platform will soon cease as well. you begin to understand that everything you do is unnecessary to anyone. people like you a huge number and this crowd already has its own leaders. go to pisyuk should have been done earlier (early 90s). those who left then, now are considered the best. what is the story with Khonich worth... AOK>>> expected, although Graphic Station 2.0 for MythOS was planned, AOK>>> system DO>> but this is especially pathetic. :~( AOK> the author gave up on this. I didn’t see that anyone was interested in such work. strange. I have observed the opposite. Yes, even I myself enthusiastically shouted about the rules this editor. AOK>>> RAD for the same. DO>> what is this? is it really an analogue of the Amiga RAD? AOK> by RAD I mean Rapid Application Development, something like the same AOK> Delphi for Spectrum. (Specifically for MythOS) I must say, a very useful thing, even in the absence of an OS as such. interface development is a big brand. AOK> everything passed through ZX.SPECTRUM in decent quantities, including AOK> sources of almost all applications and libraries with comments, AOK> documentation for functions, etc. If you haven’t seen it, I can send it, and if AOK> I saw it, and something is not clear, I could tell you. Although why is this necessary... if you are talking about these files, then I have them: >>> Begin Clipboard ... <<< MOS0_1SE.ZIP 51937 MOS_A01.ZIP 5605MOS_A02.ZIP 62939 MOS_A03.ZIP 52984 MOS_DOCS.ZIP 21657 MOS_GID.ZIP 6468 MOS_SRC.ZIP 22053 >>> End Clipboard ..... <<< I started reading the first files, but soon stopped and decided to wait full version. I couldn't wait :( WBR, Denis Ognewsky EmP^A1C // ALLiANCE [AMiGA]

Greetings, Denis! November 13, 2000 (it was 02:10 then) Denis Ognewsky in his letter to Artem O. Kozakov wrote: AOK>>>> @PID: GEDW32 3.0.1-asa9.1 DO>>> well, everything is clear. AOK>> so what? what is clear? yes, emulator. I have ever stated AOK>> reverse? DO> a person who buys a pussy is initially convinced that it will only increase DO> its performance. well, it's a pissyuk - access to networks, source DO> graphics, information carrier. Gradually all the floppy disks are moving there. DO> this is really very convenient. then emulators start. like this I also forgot to add that a pussy is usually less than a glitch. unfortunately in in our city you can’t buy a normally assembled Spectrum, everything is assembled at MGTF-e, Accordingly, it works like this, but I personally don’t know how to configure it. DO> in this way the person smoothly moves onto the pussy. sooner or later the emulator DO> is launched less and less often. time spent listening DO> mpegs, reading mail and installing all sorts of junk downloaded from the internet DO> or groups. followed by increasingly rare appearances at conferences DO> Spectrum themes and finally a statement to the people about the termination DO> any activity on the ZX.SPECTRUM platform. at the same time every DO> activities on the new platform will also cease soon because you DO> you begin to understand that everything you do is unnecessary for anyone. such as DO> you are a huge number and this crowd already has its own leaders. go DO> it was necessary to get a pussy earlier (early 90s). those who left then DO> are now considered the best. what is the story with Khonich worth... I don't argue, maybe. We are still at the stage of transition and first enthusiasm :) AOK>>>> expected, although Graphic Station 2.0 for MythOS was planned, DO>>> but this is especially pathetic. :~( AOK>> the author gave up on this. I didn’t see that someone had such a job AOK>> interesting. DO> strange. I have observed the opposite. Yes, even I myself shouted enthusiastically about DO> the usefulness of this editor. Rulez then he rules, but are there people now who make graphics entirely on Spectrum? If there is, then IMHO it is very rare. AOK>>>> RAD for the same. DO>>> what is this? is it really an analogue of the Amiga RAD? AOK>> by RAD I mean Rapid Application Development, something like those AOK>> Delphi for Spectrum. (Specifically for MythOS) DO> I must say, a very useful thing, even in the absence of an OS DO> such. interface development is a big brand. Use it to develop MythOS interfaces. quite a decent interface collect. AOK>> everything passed through ZX.SPECTRUM in decent quantities, including AOK>> sources of almost all applications and libraries with comments, AOK>> documentation for functions, etc. If you haven’t seen it, I can send it, but AOK>> if I saw it and something is not clear, I could tell you. Although why is this AOK>> need... DO> if you are talking about these files, then I have them: >>>> Begin Clipboard ... <<< [skip] >>>> End Clipboard ..... <<< DO> I started reading the first files, but soon stopped and decided to wait DO> full version. I couldn't wait :( I wonder why the full version number is always expected to be 1.x and higher? I'll reveallittle secret - already starting from 0.1 it was a full version, which is not was called solely so that they would not just shout - suck and mazday :) - but also gave sensible advice for improvement. Still waiting for advice, only one person really helped, sent a picture to the desktop and tips for improving the design (for which Many thanks to him) yes, they wrote an upper memory driver for the pros, and a little bit wrong :) Best regards, Artem

Greetings, Kirill! November 13, 2000 (it was 08:58 then) Kirill Frolov in his letter to Artem O. Kozakov wrote: AK>> Spectrum (and not only with Spectrum) so that you get “bored.” AK>> the reason (IMHO) is different - the train has simply already left and the OS is for the Spectrum AK>> is not needed by anyone. KF> Maybe two dozen users in the next 5 years she would like KF> used. Well, if such users were found, it would be possible to finish it. AK>> Apparently 5 years ago this work could have been done AK>> to be in demand. KF> 5 years ago this work could not have been done. And the question why? What, then there were no 128 Spectrums? I used this myself. KF> Spectrum may no longer be in demand for a long time. If something KF> you do it, but probably more for yourself. yes :) to realize how cool you are :) AK>> for this purpose, shared libraries in which everything can be located AK>> from program code and data to system objects, fonts, AK>> resident programs, etc. etc., in order to get as far away from as possible AK>> 16 kilobyte limits. KF> A... Well, what if my program requires a data array of kilobytes in KF> 100 (assume that the computer has 512kb of memory)? Functions need to work KF> with this memory put into lib? IMHO it would be wiser to divide everything why? where does this conclusion come from? you can ask the kernel for a buffer in lower memory and upload there the part of the code responsible for the exchange, although this is not entirely correct for the current kernel version. while I used a different approach - selecting the top memory for data and placement of the most speed-critical part of the code on the same page, next to the data. KF> memory for permanently present in the address space and KF> "can". And the program could simply store part of its code in KF> permanently present segment sharing it with other programs and KF> system. The result is the same thing, it just looks a little different KF> simpler. Unfortunately, quite a lot of the lower memory is initially occupied by the kernel. what about constantly present part - this is possible only as long as it is done lightly through, um, one place :) AK>> settings editor to assembler IDE, with the same code for AK>> the next copy of the editor consumes memory only for it AK>> variables and user data. IS-DOS can divide its own in this way AK>> modules between programs? or maybe Pink Floyd maybe? Good example AK>> extensibility of the kernel and the MythOS graphics subsystem in particular AK>> library for minimizing windows winman.lib - written AK>> completely without connection with the kernel, just exports to any AK>> program that wants KF> Okay, I convinced you, it’s incredibly cool. But it’s still difficult with banks -- :) I'm glad. :) KF> it will not work to transfer a pointer from jar to jar, but to lower memory KF> everything won’t fit. Why is it impossible to transfer a pointer between banks? I can think of a bunch ways to do this completely legally - starting from shared memory areas and ending with pointer manager libraries, driving past transfer events pointers, calling functions directly to another bank, etc. For programs MythOS doesn't care where they sit. memory management ideology does not provide banks and addresses in them, but a 24-bit address. Best regards, Artem

I am very glad to meet you Artem! And the reason for this was Thursday November 09 2000, 23:16, appeal from Artem O. Kozakov (500:562/1) to Ivan Bogomolov AK>>> P.S. we were talking about MythOS. IB>> Uh.... I understand that MythOS will not develop further? I hope IB>> that I'm wrong... ps Abydna, dammit... :( AOK> unfortunately, I'm right. due to the complete absence of at least rudimentary AOK> interest in this development, all work has been curtailed. and since it was AOK> our group's last project for the Spectrum, nothing else is expected AOK> although Graphic Station 2.0 was planned for MythOS, the RAD system was for it. AOK> If anyone is interested, I can give you the assembler sources, and the kernel as well AOK> MythOS version 0.4 You guys are doing stupid things... In terms of the fact that the snot, I apologize, was dissolved :( No one needs it, lack interest and stuff like that... I don’t know what anyone thinks, but I think that in specs, you write something for yourself, but then he throws himself into the masses, where everyone can figure out for themselves what they need and what they don’t. I don’t know what you expected from the people, or universal recognition and triumph, or something else any reward from an ordinary user. In any case, you did not write the OS formyself :( That’s why the case stalled. Why do you think ChV was published, but ChV2 died during ripening? Because when writing ChV, Slava asserted himself, trying to write high-quality realtime for specs. And first of all (I believe) he wrote it for myself (in the sense of whether I can do this). Well, the second one, he had already decided to create for grateful user (for us). And who, as they say, cares about someone else’s grief? Naturally no one. Now his desire burned out, because he achieved his goal having released the ChV, and what the people want to “continue the banquet” (c) is theirs problems. And slowly, in small steps, ChV2 left for that world. (2Slava: If I'm wrong, then forgive me and correct me) So, first decide who needs your project first. If you, then sit down and finish writing, do it so that it is convenient for you, so that you could happily use it. Well, then, if you want, then you can go to the masses quit, then the indifference of the people will not bother you, they don’t need to please, you wrote it for your convenience in your work, you just decided will share. Then the project will live and, moreover, it will be modified and flourish. There will be people who will be interested in this. Well, if you sit down at ASMM with the thoughts “does anyone need this?”, then it’s better not start. Believe me, nothing good will come of this. The law of the human soul is “The best for myself, but for my uncle it will do.” 2all I am addressing you!!!!IF YOU DECIDE TO WRITE SOMETHING, WRITE FOR YOURSELF! FORGET ABOUT US AT THIS MOMENT! After all, how many projects have been ruined because the author thinks “does anyone need this?" or when the author stops thinking about himself and starts thinking about everyone, after what does it put on everyone and everything:(((( Think about it. [ZX] Always with you -=SMONT/AIS=- [SCORPION ZS-256 Turbo] [FIDO: 2:451/19.5] [ZXNet: 500:152/5]

Greetings, Denis! November 16, 2000 (it was 03:03 then) Denis Ognewsky in his letter to Artem O. Kozakov wrote: AOK>> I also forgot to add that a pissyuk is usually less than a glitch. to DO> just don’t tell me about the reliability of the pussy. I'm this shit DO> seen a lot. All sorts of Chinese stuff was probably on the computer :) you can’t skimp on hardware. DO>>> are now considered the best. what is the story with Khonich worth? AOK>> I don’t argue, maybe. we are still at the stage of transition and the first AOK>> enthusiasm :) DO> this won't last long. Now you are swimming in an abundance of software, but soon DO> you will understand that there is very little valuable software. 90% rare crap. I already knew this. valuable software is selected carefully and for a long time, I don’t like change the software when a new super-duper version is released. AOK>> it rules, it rules, but are there people now who do AOK>> graphics entirely on the Spectrum? if there is, then it is imho very much AOK>> very rare. DO> is. and I even know people who are nothing like DO> are artists, but nevertheless they just like to draw.convinced. OK. DO>>> such. interface development is a big brand. AOK>> use for developing MythOS interfaces. quite decent AOK>> the interface can be assembled. DO> do you think someone will download a forgotten OS in order to launch it DO> my program? but I don’t feel like understanding other people’s sources. easier DO> write your own. why forgotten? If we have stopped development for now, this does not mean that if errors are found, they will not be corrected. while there are Spectrums in address, MythOS will be supported. AOK>> I'll tell you a little secret - already starting from 0.1 it was complete AOK>> version that was not called as such solely for the sake of simplicity AOK>> they shouted - suck and mazday :) - and they gave sensible advice on AOK>> improvement. Until now DO> and in vain. For example, I didn’t even read the documentation to the end. what if you DO> they said that this is the full version, then I would take action. attempts DO> there were a lot of cool OS creations on the Spectrum. Unfortunately, not a single one DO> reached the end except MythOS. we just found out all about it when already DO> everything is bent :( nothing was bent. the day before yesterday the chief coder and I decided that if at least if there are five people willing, then things will move on, albeit not at the old pace, but will do. AOK>> we are waiting for advice, only one person really helped, sent AOK>> a picture for the desktop and tips for improving the design (why should he AOK>> thank you very much) yes, they wrote a high memory driver for the pros, AOK>> with a little bit of an error :) DO> how could I help you? only by writing software. unfortunately DO> late. :( What prevents you from writing software? I’ve already said it many times, if anything is unclear, Contact us, we’ll tell you/correct/finish it. DO> p.s. can we finish this conversation? I didn't convince you... why? on the contrary, I wanted to continue... DO> ... *Uptime*: 0 /months/ 0 /days/ 1:40 /hours/ ^^^^ why so little? :) Best regards, Artem

Greetings, Kirill! November 17, 2000 (it was 16:33 then) Kirill Frolov in his letter to Artem O. Kozakov wrote: KF>>> Maybe two dozen users in the next 5 years she would need KF>>> used. AK>> well, if such users were found, it would be possible to finish it. KF> To have users, we first need to finish... ok. Let's put the question differently: what we have, the final version is 1.0.3 Users, hey! What is missing/buggy/needs improvement? KF>>> 5 years ago this work could not have been done. And the question AK>> why? What, then there were no 128 Spectrums? like this myself AK>> used. KF> There were Spectrums, but then no one thought about it and few could KF> do. maybe. AK>> why? where does this conclusion come from? you can request a buffer from the kernel in the lower ones AK>> memory and load there the part of the code responsible for the exchange, although this AK>> is not entirely correct for the current kernel version. KF> Well, it begins, incorrectly, not implemented, being tested... so what? I know this is incorrect, not implemented, and is being tested. Who,Does he know about this except us? no one, because I didn’t try/didn’t read the doc/didn’t test. AK>> while I used a different approach - allocating top memory for AK>> data and placement of the most speed-critical part of the code AK>> on the same page, next to the data. KF> What if I have a lot of this data, more than 100kb? That's it, game over... divide by pages. There is no data that cannot be divided into pieces. AK>> unfortunately, quite a lot of lower memory is initially occupied AK>> core. KF> Is it really busy or like in iS-DOS? After all, half can be done what about is-dos? :) KF> throw it out altogether, and stuff the second half into jars. Third Can't throw it up. Almost everything that is possible has already been thrown away. The chief coder specifically struggled with this for a month. more precisely, you can throw it away, but this will slow down the work by 3-4 times and the minimum requirements will increase somewhere up to 7-10 MHz processor. KF> half will take only 16kb and fit under ROM. By the way, opportunity doubtful. although if you think about it, the kernel itself will probably fit into the ROM. here libraries that are loaded at kernel startup are not. KF> Is it possible to work without ROM? Probably not. But if you move the screen to yes. the only thing that needs to be replaced is the keyboard driver. it even exists, but not inserted into the system. KF> the jar is already 7kb and the ROM is another 16kb. There are as many as 23kb extra! yes, but does everyone have a cache? And about the screen - you can’t move it either. firstly, the kernel uses both screens, secondly, this is again a catastrophic slowdown graphical operations, thirdly - see the doc. there is a kernel function that instructs him not to use the bottom screen.[ OpenBuffer(36), RestoreBuffer(37)] AK>> and about the constantly present part - this is only possible AK>> for now it’s done slightly through, um, one place :) KF> You need a special format for downloaded binaries so that there KF> described which segment to load where and how to configure addresses. And why? it is not really known where the file will be loaded (for libraries), exe files download address is fixed, setting - libraries automatically are configured, exe - do not need configuration. KF> overlays are also desperately needed. why? Why are libraries not suitable? overlay is the same library, only stripped down version. in any case there is no need for a second copy of the programload the overlay a second time - if libraries are used, the code will be the same and the same for both copies of the program. For special cases you can copy library to another memory area and configure it. KF>>> it will not work to pass a pointer from one jar to another, but to the bottom one KF>>> the memory won’t fit. AK>> why is it impossible to transfer a pointer between banks? I can AK>> come up with KF> If the function sitting in the bank was given a pointer in another bank that it is KF> will do? use it. what problems? there are functions for working with memory in others pages. These are functions 23, 24, 35, 38, 40, 50, 57, 58. Moreover, the kernel itself always works with 24-bit addresses internally. Does this stop him from working? IMHO it turns out quite successfully, although parts of the kernel are scattered across the pages, plus piece below. Best regards, Artem

Greetings, Mikhail! November 17, 2000 (it was 10:12 pm then) Mikhail Zharov in his letter to Artem O. Kozakov wrote: AO>> why forgotten? if we stopped for now AO>> development, this does not mean that when errors are found AO>> will not be corrected. as long as there are Spectrums in circulation AO>> MythOS will be supported. MZ> Already making me happy. :) will you be the third? :) AOK>>>> I’ll tell you a little secret - already since 0.1 it was AOK>>>> full version, which was not called as such only DO>>> and in vain. For example, I didn’t even read the documentation to the end. a DO>>> if you had said that this was the full version, then I would have started MZ> He's right: "v0.*" stopped many from studying in detail... bad. will have to release MythOS Millenium Edition (ME 1.0) :) We already know that we need to change some things, we’ll redesign the shell. yes artists willing to help? wishes for changes? compatible with all the cores of the 0.x series will remain, ME 1.0 itself will not be thrown to the masses and trimmed 0.4 AO>> nothing was bent. the day before yesterday the main coder and I AO>> we decided that if there are at least five willing people, then things will work out AO>> further, although not at the same pace, but it will go. MZ> Guys, continue with the software. She is needed, really needed! MZ> It's just that everyone is very lazy and there are still a lot of excuses for silence... ;) yes, unfortunately. AOK>>>> We are still waiting for advice, only one person really AOK>>>> helped, sent a picture to the desktop and tips for improvement AOK>>>> design (for which I thank him very much) and wrote the driver AOK>>>> top memory for the pros, with a little bit of an error :) DO>>> how could I help you? only by writing software. to DO>>> unfortunately it’s too late. :( AO>> what prevents you from writing software? I've already said how many times - if anything AO>> it’s not clear, please contact us, we’ll tell/correct/finish it. MZ> Sorry, I already killed all the files - I thought it was a demo... I can’t read the help. MZ> Tell me, what dos software is it designed for? for now the file system is tr-dos. if we have enough time, we are going to add support for ms-dos(fat12, fat16) - in already written (and future) programsnothing will have to be redone - there is no initial rigid orientation towards tr-dos, therefore, no program will notice where it is running. (Unless it will analyze the path to your executable file :) DO>>> p.s. can we finish this conversation? I didn't convince you... AO>> why? on the contrary, I wanted to continue... MZ> Speck has long needed another dossier. MZ> I personally don’t like Is-dos because of its limitations, in many ways, not MZ> I will. IMHO, although ms-dos is not the best in the world, it is more often MZ> everything you need in life. All old software is fine inside .trd MZ> will live and work. I don't understand something here. any suggestions to port ms-dos? or how to understand that the old software inside TRD will live and work? Best regards, Artem

Press RESET immediately, Artem! 19 Nov 00 11:48, Artem O. Kozakov wrote to Kirill Frolov: KF>>>> Maybe two dozen users in the next 5 years KF>>>> used. AK>>> well, if such users were found, it would be possible to finish it. KF>> So that users first need to be completed... AK> good. Let's put the question differently: what we have, final version 1.0.3 AK> Users, ah! what is missing/buggy/needs improvement? I want: tear off the whole guy to hell, text console (several pieces), use all 64kb of memory without ROM, use the opportunity connect any jar to any 16kb window, have at least a minimum set libraries for C compiler, human I/O functions and support drivers and file system are approximately the same as in Unix - so that there are no ABCDs, something like a driver table, how it’s done there. How are you doing now? It shouldn't work at all, just holes for potential glitches. Examples? They did something clever with “block devices”, they separated them into a separate group - why? Function 0 of the file system can easily destroy the entire system, it’s not clear how to view long names, file times, etc.extended attributes. What for byte-by-byte reading should I use DOUBLE buffering is probably only bad because it's slow. Or at You don't have a disk cache at all? It can't be! The length of the file for some reason fixed under 65536*block, how much is a block? The file is accessed by name - this means that during each operation she lays it out for a long time and tediously components to calculate the physical address of the descriptor? That's where the brakes are rummaged around! Or does the system support all sorts of modems, serial ports, printers... ? And through what place? Through the library? And no one there is no interface. :-( AK>>> lower memory and load there the part of the code responsible for the exchange AK>>> although this is not entirely correct for the current kernel version. KF>> Well, here it begins, incorrectly, not implemented, being tested... AK> so what? I know this is incorrect, not implemented, AK> is being tested. who besides us knows about this? no one, because no AK> tried/didn't read the doc/didn't test. But I still can’t use it. AK>>> data and placement of the most speed-critical part AK>>> code on the same page, next to the data. KF>> What if I have a lot of this data, more than 100kb? That's it, game KF>> over... AK> divide by pages. there is no data that cannot be divided into AK> pieces. char x[500000]; for (y=0; y<500000; y++) x[rand(500000)]+=x[rand(500000)]; How to do it? KF>> Is it really busy or like in iS-DOS? It's supposed to be half KF>> possible AK> what about is-dos? :) Everything unnecessary is collected in one big pile and placed directly in jar 0. As a result, the system itself takes up more than half of the computer's memory and Machines cannot work with banks of 128kb. KF>> is it possible to work without ROM? Probably not. But if the screen KF>> move to AK> is. the only thing that needs to be replaced is the keyboard driver. he even AK> exists, but is not inserted into the system. How is this? :-/ KF>> the jar is already 7kb and the ROM is another 16kb. There are as many as 23kb extra! AK> yes, but does everyone have a cache? Is it possible to make 2 versions of the kernel? And one is probably enough, Only some drivers are needed. AK> and about the screen - you can’t move it either. firstly, the kernel uses AK> both screens, secondly, this is again a catastrophic slowdown AK> graphical operations, What if I don’t need either graphics or a second screen? And it turns out that Has everything graphically been stuffed into banks? AK> thirdly - see the doc. there is a kernel function that tells it AK> do not use the bottom screen.[ OpenBuffer(36), RestoreBuffer(37)] Will there be one free piece after this? No. One will be above the ROM, and the second one is under the can, and between them there is a system. Very inconvenient. KF>> You need a special format for downloaded binaries so that there KF>> described which segment to load where and how to configure addresses. KF>> AND AK> why? it is not really known where the file will be loaded (for libraries), AK> for exe files the download address is fixed, the setting is libraries AK> are automatically configured, exe does not require configuration. How is it not needed? For example, I have 3 segments in my program -- one code and can be in the bank, another code and wants to be constantly presentmemory, and the third data wants to go to the same place as the 2nd segment. When loading and after allocating memory, you need to configure segment 2, and if 1 segment works with segment 2 or segment 3, then it also needs to be configured. Do things like this in the program itself is very _VERY_ difficult. KF>> overlays are also desperately needed. AK> why? Why are libraries not suitable? overlay is the same library AK> only a stripped down version. at least for the second copy of the program AK> there is no need to load the overlay a second time - in case AK> using libraries, the code will be the same for both copies AK> programs. For special cases, you can copy the library to another AK> memory area and configure. You don't understand. For example, I have a program and it has 1000 different functions. Have you seen DOS turbo-pascal? He cannot fit everything into his memory at once, Therefore, some functions are placed in the overlay and loaded only if they are call. These are functions of the program itself; it does not apply to shared libraries no relation. This is for statically linked programs. This is also possible libs, but the first option is sometimes needed too. KF>> If the function sitting in the bank was given a pointer in another bank KF>> what will she do? AK> use it. what problems? there are functions for working with memory AK> other pages. I gave you an example above in C. Rewrite it in Asma... Well, if a function sits in a jar and does, for example, strlen. How will she get bytes from another jar? Copying piece by piece or get 1 byte through system calls? You wrote above that if you do graphics in bank 7, then it will be very slows down. And then the brakes will be even stronger.

Greetings, Kirill! November 21, 2000 (it was 12:01 then) Kirill Frolov in his letter to Artem O. Kozakov wrote: AK>> good. we pose the question differently: what is, the final version AK>> 1.0.3 Users, ah! what is missing/buggy/needs improvement? KF> I want: to tear off the whole guy to hell, not possible in the current kernel. I myself suggested doing this (so that when necessary the program launched itself) but the main coder did not agree - this is practically necessary to plow everything, the core is too strongly tailored for working with windows, it is for removing the GUI needs to be completely rewritten. although you can try. KF> text console (several pieces), *nix ears are clearly visible. what to switch? neither alt nor F? not on the keyboard :) KF> use all 64kb of memory without ROM, quite real. KF> use the ability to connect any jar to any 16kb window, this is for the iron workers. reworking the kernel for this, IMHO, doesn’t require much. KF> have at least a minimum set of libraries for the C compiler it's unclear. there is no compiler itself. KF> human I/O functions and driver and file support I/O stream library in development. again :) KF> systems are similar to those in Unix - no ABCD, something like Yeah, the letters annoy me too :) already suggested. KF> driver tables how it is done there. I don't know how it was done. need to figure it out. KF> The way you have it done now should not be possible at all KF> work, only holes for potential glitches. there is no driver model as such - everything is supported like god per soul positive KF> Examples? :) KF> Something was done with “block devices”, they were allocated in KF> a separate group - why? Function 0 of the file system can easily KF> destroy the entire system, it is not clear how to look at long names, times KF> file and other extended attributes. What for byte-by-byte reading I I don't know. when I started participating, it already happened. KF> should use DOUBLE buffering, this is probably just bad KF> because it's slow. Or do you not have a disk cache at all? why is it in the emulator? KF> It can’t be! hmm, maybe. more precisely, it exists, but within extremely limited limits. full-fledged, with Read/write caching of any files is planned in the near future. KF> For some reason the file length was fixed at 65536*block, block KF> how much is this? 256 bytes. one page Z80 KF> The file is accessed by name - that means every time KF> operations she takes a long time and tediously breaks it down into components so that KF> calculate the physical address of the descriptor? This is where the brakes went wrong! hmm, I somehow didn’t think about that. I used it and that’s it... (fast on the screw :) KF> Or the system supports all sorts of modems, serial KF> ports, printers... ? And through what place? Through the library? A KF> there is no single interface. :-( I wanted to do it like in Unix - the structure /dev/???? which you work with. and how it looks like it is in hardware - the program should not worry. but again - it came up against stupid letters. IMHO the designation of drives by letters and FS for devices is not compatible, except to highlight a separate letter. but this is perversion. AK>>>> lower memory and load there the part of the code responsible for the exchange AK>>>> although this is not entirely correct for the current kernel version. KF>>> Well, here it begins, incorrectly, not implemented, being tested... AK>> so what? I know this is incorrect, not implemented, AK>> is being tested. who besides us knows about this? no one, because no AK>> tried/didn't read the doc/didn't test. KF> A still can’t be used. maybe. There haven’t been any major programs for mythos yet (my unfinished asm is general the size of 10 kopecks kilo code does not count) KF>>> What if I have a lot of this data, more than 100kb? That's it, game KF>>> over... AK>> divided into pages. there is no data that is impossible AK>> split into pieces. KF> char x[500000]; KF> for (y=0; y<500000; y++) KF> x[rand(500000)]+=x[rand(500000)]; KF> How to do? hmm, it’s a long time to write on ASMA :) in short - I made a thread support library I/O, including mapping the file to memory (cache, actually). here with its help you need to do this. (file size - up to the amount of free memory plus free space on external storage) But, of course, such a thing will It's very cool to slow down - one memory display window has not been canceled. Truthif you dodge, you can throw the array search into lower memory - then it will turn out a little faster, but still - a continuous piece of more than 16K is legal you won't get it. therefore the brakes with shifting are applied brakes with translation of the logical address in the array to the physical address in memory. KF>>> Is it really busy or like in iS-DOS? It's supposed to be half AK>> what about is-dos? :) KF> Everything unnecessary is collected in one big pile and placed directly in 0 KF> jar. As a result, the system itself takes up more than half of the memory KF> computer and cannot work with banks of 128kb machines. I don’t even know what to answer here. you need to ask the boss to draw up a map, what, where and why lies. KF>>> is it possible to work without ROM? Probably not. But if the screen KF>>> move to AK>> is. the only thing that needs to be replaced is the keyboard driver. he AK>> even exists, but is not inserted into the system. KF> How is this? :-/ and like this. an alternative has been developed, without ROM, but the driver is now in use, which crawls into ROM when needed. KF>>> the jar is already 7kb and the ROM is another 16kb. There are as many as 23kb extra! AK>> yes, but does everyone have a cache? KF> 2 versions of the kernel can be made, right? And one is probably enough KF> only some drivers are needed, others are needed. possible. AK>> and about the screen - you can’t move it either. first, the core AK>> uses both screens, secondly - this is again catastrophic AK>> slowdown of graphical operations, KF> What if I don’t need either graphics or a second screen? And it turns out KF> that everything graphic has already been stuffed into banks? There's a lot of graphics at the bottom - it doesn't fit into the jars. :) (in terms of influence on speed does not fit) AK>> thirdly - see the document. there is a kernel function that specifies AK>> he should not use the bottom screen.[ OpenBuffer(36), AK>> RestoreBuffer(37)] KF> Will there be one free piece after this? No. One will be above KF> ROM, and the second one is under the can, and between them is the system. Very inconvenient. unfortunately yes. if you make it possible to include each jar in any place address space - it would be easier. and so what we have is what we have KF>>> You need a special format for downloaded binaries so that there KF>>> described which segment to load where and how to configure addresses. AK>> why? it is not really known where the file will be downloaded (for AK>> libraries), exe files have a fixed download address, setting - AK>> libraries are automatically configured, exe is not configured AK>> need. KF> How is this not needed? For example, I have 3 segments in my program -- KF> one code and can be in the bank, library KF> another code and wants it permanently KF> present memory, You can’t go there right away. KF> and the third one wants the data and wants to go to the same place as 2 KF> segment. why the data below? KF> When loading and after memory allocation, you must configure 2 KF> segment, one system call - setting up links to the library. at the same time she will automatically loaded, configured, initialized and addresses the functions exported by it are entered into the corresponding table of the calling programs. as an example - importing the code of the object "window minimization button" from the library.=== Quoting the Windows Clipboard file === RunApp > ld a,(PageN) > ld (Lblb1),a > ld hl,LibTable > call CallFn: db 47 quoted - loading of all libraries used by the program (according to the table) and customizing the table for their functions. ld a,(PageN) ld ix,MainWnd call CallFn db 15 ; open the main window. jp Return CloseApp ; unload all used libraries. ld a,(PageN) ld hl,LibTable call CallFn: db 92 ret LibTable ; table of imported functions. db "winman" db 0 db 3 MinimBtn ds 3 db #ff,0 TestStr db "Test app",0 ===End quote === KF> and if 1 segment works with 2 segment or 3, then it KF> also needs to be configured. Doing things like this in the program yourself is very good KF> _VERY_ difficult. I don't think it's very difficult. KF>>> overlays are also desperately needed. AK>> why? Why are libraries not suitable? overlay is the same AK>> library, only a stripped-down version. at least for the second AK>> copies of the program do not need to download the overlay a second time - in AK>> if libraries are used, the code will be the same for both copies AK>> programs. For special cases, you can copy the library to AK>> another memory area and configure. KF> You don't understand. For example, I have a program and there are 1000 different ones in it KF> functions. Have you seen DOS turbo-pascal? He can't do everything at once KF> memory capacity, so some functions are placed in the overlay and KF> are loaded only if they are called. These are the functions of the program itself, to KF> it has nothing to do with shared libraries. This is for KF> statically linked programs. This can also be done using libs, but the first option KF> sometimes needed too. anyway. firstly, you can use libraries, since they can be dynamically load/unload. secondly, load the code into any memory area and setting the corresponding system call (BitMap, 93) after use - discard. but in general: === I quote the file overlay.msm === ; module for working with overlay. ;Allocate a memory page for the overlay ;The number of the selected page is placed in (OverlayPg), or #FF if there is no memory ; - if memory is already allocated nothing happens AllocMemory ld a,(OverlayPg):inc a ret nz ;memory already allocated LD A,#FF LD B,64 CALL CallFn DB 28 jr nz,AllocMemory1 ;Okld a,#FF AllocMemory1 ld(OverlayPg),a ret ;Load an overlay named in (AHL) into memory and initialize LoadOverlay ;Transfer the file name to the buffer LD C,A CALL CallDos DB 14 ;InpName ;Check whether memory is allocated ld a,(OverlayPg):inc a:jr nz,LoadOverlay ;memory allocated ;Attempting to allocate memory call AllocMemory inc a:ret z ;exit if failed LoadOverlay1 ;UPLOAD FILE LD A,(OverlayPg) LD HL,#C000 CALL CallDos DB 2;LoadFile RET NZ ;FileNotFound ld a,(OverlayPg) ld(LoadOverlay2),a call CallPg LoadOverlay2 db 0: dw #c000 ret ;Free up used memory ; - if no memory was allocated > exit FreeOverlay ld a,(OverlayPg):inc a ret z ;No memory allocated ;free up memory ld b,64 ld a,(OverlayPg) ld hl,#C000 call CallFn db 46 ld a,#FF:ld (OverlayPg),a ;Memory freed ret ; call the overlay function at the address from BC CallOvl ld (OverlayFn),bc call CallPg OverlayPg db #ff OverlayFn dw 0 ret ===End quote === this is a piece from my assembler. (block for working with an array of label definitions - overlay, and multiple - more than one can be loaded, for overcome the size of label definitions of 16KB) ripped off almost one into one from the background music player (sources rushed) KF>>> If the function sitting in the bank was given a pointer in another bank KF>>> what will she do? AK>> use it. what problems? there are functions for working with memory AK>> other pages. KF> I gave you an example above in C. Rewrite it in ASMA... broke :) KF> Well, if a function sits in a jar and does, for example, strlen. KF> How will she get bytes from another jar? By copying KF> piecewise or get 1 byte through system calls? it is possible both ways. KF> You wrote above that if you do graphics in bank 7, then it will be very strong KF> slows down. And then the braking will be even stronger. I don't argue. but there is no other method. Best regards, Artem

Greetings, Andrey! November 16, 2000 (and it was then 16:45) Andrey Eismont in his letter to Artem O. Kozakov wrote: AOK>> although Graphic Station 2.0 was planned for MythOS, the RAD system for AOK>> same. If anyone is interested, I can give you the sources AOK>> assembler, and the MythOS kernel version 0.4 AE> You guys are doing nonsense... AE> In terms of the fact that the snot, I apologize, was dissolved :( No one needs it AE> lack of interest and stuff like that... I don’t know what anyone thinks, but I AE> I think that in specs you write something for yourself, and then for the masses AE> rushes, where everyone can figure out for themselves what they need and what they don’t. AE> another reward from an ordinary user. In any case, you AE> they didn’t write the OS for themselves :( That’s why the business stalled. no, why not? first for myself. AE> So, first decide who needs your project first. AE> If you, then sit down and finish writing, make it comfortable AE> to you so that you can use it with joy. Well, then, if you hmm. in fact, this project was written exclusively, as noted above (byfor another reason) for self-affirmation - but can we? as it turned out - something we can. but - the architecture turned out (in my personal opinion) unsuccessful, although how graphical shell, IMHO, there was nothing like it before. AE> if you want, then you can throw it at the masses, then the indifference of the people will come to you AE> won't worry, they don't need it, and please, you have it for your own AE> I wrote about the conveniences in work, I just decided to share. That's when the project AE> will live and, moreover, will be modified and prosper. Will be found Well, as far as convenience is concerned, hardly. as a desktop, to work with the Spectrum I already I haven’t used it for a long time - all my programs are successful (both in terms of reliability and in terms of commercial success) work (to this day) on a machine without any display. so convenience is a priority for me, the main thing is reliability and decent means of controlling the entire range of programs without a mouse or screen at all :) . The focus on GUI went only because initially MythOS did not was going to be an OS, but only a graphics library for creating interface Graphic Station 2. Actually under my pressure (for my tasks) libraries appeared and movement towards the OS began - it turned out to be a kind of hybrid :) graphics library with some OS capabilities. AE> people who will be interested in this. Well, what if you sit down to study with thoughts AE> “does anyone need this?”, then it’s better not to start. Believe me, it’s no big deal AE> this won't work. The law of the human soul - “The best for yourself, and for your uncle and AE> that will do." :) AE> Think about it. necessarily. Best regards, Artem

Press RESET immediately, Artem! 22 Nov 00 19:41, Artem O. Kozakov wrote to Kirill Frolov: KF>> I want: to tear off the whole guy to hell, AK> is not possible in the current kernel. I myself suggested doing this (so that the guy AK> needed the program to launch itself) but the main coder did not agree - this AK> it is necessary to plow almost everything, the core is sharpened too much AK> work with windows, to remove the GUI you need to completely rewrite it. AK> although you can try. Yes, I just don’t understand why it is needed at all. Needed, of course, maybe for 10% programs. For example, I haven’t turned on Spec’s monitor lately, there the MMD and the modem emulator spin, I watch the whole process occasionally on PC screen... What the hell do I care about? KF>> text console (several pieces), AK> *nix ears are clearly visible. what to switch? neither alt nor F? not on the keyboard :) There is an EXT key. EXT+1, EXT+2... And EXT+letter can be understood as CTRL+letter. KF>> use the ability to connect any jar to any window KF>> 16kb, AK> this is for the hardware people. reworking the kernel for this, IMHO, doesn’t require much.I've done this for a very long time. Everything on one chip. KF>> have at least a minimum set of libraries for the C compiler AK> this is unclear. there is no compiler itself. Yes. Only on the pussy. :-( There is a CP/M analogue, you can if you really want to disassemble it, but The devil will break his leg inside and he needs a lot of memory. At the code generator the amount of pure code is > 40kb. It is in CP/M with less than ~55kb of memory and does not work. Again it all comes down to memory... KF>> human input/output and driver support functions KF>> file AK> I/O stream library in development. again :) So the process has already begun? KF>> The way you have it done now should not be possible at all KF>> work, only holes for potential glitches. AK> so there is no driver model as such - everything is supported like god on AK> lay down your soul. On the Spectrum everything leads to colored squares and the inscription (C) 1982... KF>> should use DOUBLE buffering, this is probably only KF>> is bad because it’s slow. Or do you have no disk cache at all KF>> provided? AK> why is it in the emulator? In which emulator? It doesn’t happen that he doesn’t exist! He is there. KF>> It can’t be! AK> hmm, maybe. more precisely, it exists, but within extremely limited limits. AK> full-fledged, with caching for reading/writing any files is planned in AK> soon. Ahhh... KF>> operations she takes a long time and tediously breaks it down into components KF>> to calculate the physical address of the handle? That's where the brakes are KF>> rummaged around! AK> hmm, I somehow didn’t think about that. I used it and that’s it...(fast on the screw :) It's fast, but what if I read 1 byte at a time? Faster from tape It will be possible to download. AK> worry. but again - it ran into stupid letters. IMHO designation AK> drive letters and FS for devices are not compatible, unless you select I didn’t understand anything, but IMHO the letters belong somewhere in the ABC book, not here... AK> maybe. There have been no major programs for mythos yet (my unfinished asm AK> the total size of 10 kopecks does not count) Is it on there? I keep thinking - 16kb and even in the bank. Normal asm underZetnik takes up ~40kb. There isn't that much memory. :-/ KF>> char x[500000]; KF>> for (y=0; y<500000; y++) KF>> x[rand(500000)]+=x[rand(500000)]; KF>> How to do? AK> hmm, it's a long time to write in Asma :) in short - I made a support library [...] AK> is faster, but still - a continuous piece of more than 16K is not legal AK> you'll get it. therefore the brakes are applied with switching AK> brakes with translation of the logical address in the array to the physical address AK> memory. What I mean is that even if it’s slow, it’s much faster if the program will not sit in the bank. AK> and like this. an alternative has been developed, without ROM, but is in use now AK> driver that crawls into ROM when needed. Yes, forget about this ROM, there is nothing useful there, not even a calculator with bugs... AK> unfortunately yes. if you make it possible to include each jar in any AK> address space location - it would be easier. and so what we have is AK> and we have I don't think it would be much easier. Then I would just run into moreother problems. And with what we have, we need a more efficient mechanism loading programs into the desired memory. AK>>> libraries are automatically configured, exe is not configured AK>>> need. KF>> How is this not needed? For example, I have 3 segments in my program KF>> - one code and can be in the bank, AK> library KF>> different code and wants it permanently KF>> present memory AK> You can’t go there right away. KF>> and the third one wants the data in the same place as 2 KF>> segment. AK> why the data below? Well, what's the difference? To be constantly available. KF>> When loading and after memory allocation, you must configure 2 KF>> segment, AK> one system call - setting up links to the library. at the same time she AK> will be automatically loaded, configured, initialized and AK> the addresses of the functions exported by it are entered in the corresponding table AK> of the calling program. as an example - importing the code of the "button object AK> window minimization" from the library.In the example that I gave, you need to set addresses in all 3 segments. And only once when loading. So why not do it to the bootloader? KF>> You wrote above that if you do graphics in bank 7, then it will be very good KF>> slows down a lot. And then the braking will be even stronger. AK> I don’t argue. but there is no other method. Yes - if possible, load as much as possible into the lower memory.

Press RESET immediately, Artem! 24 Nov 00 21:33, Artem O. Kozakov wrote to Kirill Frolov: KF>> Yes, I just don’t understand why it is needed at all. Needed, of course KF>> may be for 10% of programs. And I, for example, have a monitor in KF>> I haven’t turned it on lately, the MMD and modem emulator are spinning there, KF>> I watch the whole process occasionally on the desktop screen... What the hell do I care about? AK> to you - yes. you have a guy on your PC :) Not always. Of course, it can be available by default, but I use it rarely, basically everything is limited to console programs in windows. And in a system where there is little memory, the default is to load a gigantic size guy this is stupidity. KF>>>> use the ability to connect any jar to any window KF>>>> 16kb, AK>>> this is for the iron workers. reworking the kernel for this, IMHO there is not much AK>>> necessary. KF>> I have done this for a very long time. On one chip KF>> total. AK> more details please. so that you can use it. The proposed modification can be easily carried out on computers KAY, PENTAGON, SCORPION and others not assembled on PLM.It allows you to use the spectrum memory much more efficiently, than just through one 16kb page in the address space of the processor. The number of pages has been increased to four and they cover all 64kb of memory addressed to Z80. Any memory bank within the first 256kb can be included in any processor memory window. The rest of the memory is addressed as before. Within the first 256kb programs can be located operating with large volumes of data and frequently used data. in memory more than 256kb can accommodate programs content a 16kb code and data segment (for example, device drivers) or disk cache, Ramdisk... All of these computers with RAM capacity of 128kb and above have port 7FFD controls switching memory pages in the window with address C000. The circuit design of the memory manager in different computers is small What is the difference: there is a port decoder, a 555TM9 register and a multiplexer 555KP11. The presence of the 555KP11 microcircuit makes it easy to implement finalized, often only 1 microcircuit may be required. You will need to disconnect pin 15 of the 555KP11 microcircuit from the board, it will used to switch modes. You also need a control port configuration (for example, in Scorpio or Kai you can use 1FFD, only 1 bit will be needed, set when resetting to 0 and nevernot installed in 1 TR-DOS programs. You will also need one inverter. You may need a circuit to disable the ROM, which is found in KAY and SCORPION already available. SCHEME: D47 is a 555KP11 computer memory manager chip SCORPION, "yellow board". For other computers you need according to the scheme clarify the correspondence between the contacts of the 555KP11 microcircuit and the signals D0, D1, D2, D4 data buses. D48 pin 9 -- write signal to port 7FFD on the “yellow scorpion”, available on all computers on pin 9 microcircuits 555TM9... SPECTRUM BUS ┌──┬──────┐ connects to D47 D4 >──────15──┤D0│ RG │ output: D2 >───────1──┤D1│ Q0├─10───> 12 D0 >───────2──┤D2│ Q1├─9────> 9 D1 >───────3──┤D3│ Q2├─7────> 7 ├──┤ Q3├─6────> 4 A10 >──────14──┤W0│ │ A11 >──────13──┤W1│ │ wr7FFD >──────12──┤WR│ │ (D48/9) ├──┤ │ A14 >───────5──┤R0│ │ A15 >───────4──┤R1│ │ ┌──11──┤OE│ │ │ └──┴──────┘ │ 555ИР26 │ └──────────────────┐│ switching on ┌──┐ │ ext. >──────┬───────┤1 o────┘ addressing │ └──┘ according to log. 1 │ ЛH1 └────────────────> D47 pin 15 (CS) PROGRAMMING VIA PORTS ┌──────────┬────────────┬────── ─────┬───────────┬────────────┐ │ PORT │ 73FD │ 77FD │ 7BFD │ 7FFD │ ├──────────┼────────────┼────── ─────┼───────────┼────────────┤ │ BITS │ │ │ │ │ │ 0 │ R0-0000 │ R0-4000 │ R0-8000 │ R0-C000 │ │ │ │ │ │ │ │ 1 │ R1-0000 │ R1-4000 │ R1-8000 │ R1-C000 │ │ │ │ │ │ │ │ 2 │ R2-0000 │ R2-4000 │ R2-8000 │ R2-C000 │ │ │ │ │ │ │ │ 3 │ screen 5/7 │ screen 5/7 │ screen 5/7 │ screen 5/7 │ │ │ │ │ │ │ │ 4 │ R3-0000 │ R3-4000 │ R3-8000 │ R3-C000 │ │ │ │ │ │ │ │ 5 │ LOCK │ LOCK │ LOCK │ LOCK │ │ │ │ │ │ │ │ * 6 │ R3-C000 │ R3-C000 │ R3-C000 │ R3-C000 │ │ │ │ │ │ ││ ** 7 │ R4-C000 │ R4-C000 │ R4-C000 │ R4-C000 │ │ │ │ │ │ │ └──────────┴────────────┴────── ─────┴───────────┴────────────┘ * Bit 6 is only used in PENTAGON computers with the capacity RAM more than 128kb ** Bit 7 is used only in KAY or PENTAGON computers with more than 256kb of RAM. The number of the addressed memory bank is calculated using the formula: n ___ \n /__ (Rx)*(2^x) ; n=2..8 (depending on the type of computer). x=0 ( 128..8192kb ) Setting the LOCK bit to 1 locks the 7xFD ports for writing. Ports 73FD, 77FD, 7BFD, 7FFD are used to install recorded they contain a memory bank at addresses 0000, 4000, 8000, C000, respectively. The selected ports are decrypted identically in all common Soviet clones of ZX-SPECTRUM as a port of 7FFD. All possible conflicts are associated only with switching to the extended mode, which on different on computers can be implemented in different ways. In most cases, modification is useless for TR-DOS programs. The benefits will be enormous when used in the operating system which can distribute memory between different programs or parts of the program, it also becomes possible to implement real multitasking with programs of real (>64kb) size,but again, you need an appropriate operating system, but not tape recorder emulator. If something is unclear or you have suggestions, write: Kirill Frolov 2:5030/827.2@fidonet.org 500:812/1.507@zxnet P.S.: Everything is already done and working. Buy 555IR26 on the radio market in St. Petersburg problem. === Cut === You can do it on 4Mb, but on different computers it will be different and The scheme will be complicated. And almost everything will fit into 256kb, especially since Most Spectrum clones in the USSR have exactly this amount of memory. KF>> Nihren, it’s fast, but what if I read 1 byte at a time? From tape KF>> it will be possible to load faster. AK> what about bytes? file name? :) The file itself. AK> and the content is of course buffered by at least 256 bytes. Not enough. And there should be read-ahead and delayed write. Especially necessary for disk drives. And the cache size is probably at least 16kb. KF>> I didn’t understand anything, but IMHO the letters have a place somewhere in the primer, huh KF>> not here... AK> tell this to Stealth :) I can’t convince you yet that there were no letters AK> would be more convenient. A classic example: Fido on my screw began to take up a lot of spaceand generally ceased to fit there. I bought myself another screw for Fido. I thought now I’d copy everything there and an extraordinary flow would ensue... But it’s a bummer sneaked up unnoticed - the paths are written in the configs of all fidosh programs like C:FIDOBLABLABLA. I have been setting up this software for 1.5 years and need to reconfigure There is no desire to do it again, and you can make a lot of mistakes. And so simple I would have mounted everything fidosh in the right directory, if not for these letters... KF>> I don't think it would be much easier. Then I would just run into KF>> more other problems. And with what we have, we need a more efficient one KF>> mechanism for loading programs into the required memory. AK> what if this necessary memory is not free now? complete program AK> breaks off or keep an alternative allocation table? If nothing is written to the swap, then a significant problem arises in the system. lack of resources and a blue screen of death appears. KF>> Well, what's the difference? To be constantly available. AK> so if we can connect any page to an arbitrary window - that’s it AK> equals the data is obtained at the top :) NO! There will always be at least one permanently accessible memory area. Or where will you have interrupt vectors? Stack? KF>> In the example that I gave, you need to set up addresses in all KF>> 3 segments. And only once when loading. So why not KF>> can't be done by the loader? AK> and then throw out the bootloader? On i dlq drugih program will be needed, no need to throw anything away. AK> format complications. not good, it will start slowly. But work quickly. AK> and if you do it manually, you can load something at any time AK> is necessary, while giving a table like wait. Have you decided what the program is for - for the computer or for the user? No need to show all sorts of signs there, the monitor is turned off. KF>> Yes - if possible, load as much as possible into the bottom KF>> memory. AK> the lower memory is not rubber. But it will fit into it to some extent.

Hello, Kirill! Thu 09-Nov-2000 10:10, you (500:812/23.25) wrote a letter to Artem O. Kozakov: KF> So. It took almost 10 years for iS-DOS to be perfected. The very first “sales” version from the bag with the book was already working. Next there was optimization and cleaning of rare bugs. I have something five years old on the screw old - it works, doesn’t ask for food, doesn’t freeze. With best wishes, Vladimir.

Hello, Artem! Tue 21-Nov-2000 21:40, you (500:562/1) wrote a letter to Denis Ognewsky: AOK> wow. then we'll measure uptime a little later :) when I'm finally under AOK> I’ll crawl over Linux. at the current 98th record, it seems there was something like 20 AOK> hours... What crap, even now I have: ─ NetMail: VL pPERSONALLY (2:5030/675) ──────────────────────────── NETMAIL_VL ─ Msg : 248 of 248 Rcv Uns Pvt Loc K/s From : UpTime Info 2:5030/675 Sun 26-Nov-2000 08:15 To: Vladimir Larkov 2:5030/675 Subj:\486 ─────────────────── ──────────────────── ──────────────────── ──────────────────── localhost: uptime is 24 days, 21:58 hours and 16 seconds Before this there was more (in the summer I got stuck), but I had to reboot - the winch died. With best wishes, Vladimir.

Greetings, Vladimir! November 26, 2000 (it was 1:29 pm then) Vladimir Larkov in his letter to Artem O. Kozakov wrote: AOK>> wow. then we'll measure uptime a little later :) when I AOK>> I’ll finally crawl under Linux. at the current 98th record, it seems AOK>> it was something like 20 o'clock... VL> What a crap I have even now: [skip] VL> ───────── localhost: uptime is 24 days, 21:58 hours and 16 seconds VL> Before this there was more (I got stuck in the summer), but I had to reboot - VL> Vinch died. Well, this is OS/2, it’s a little more stable than the entire Win9x series :) or you already something like *nix? Best regards, Artem

Hello, Vladimir! Saturday 25 Nov 2000 22:23:27, Vladimir Klymus -> Denis Ognewsky: VK> A small clarification: I’m not hiding this. And people who VK> no - they will fight for the purity of the ranks, instead of VK> do at least something. You, SS, KF caused me to be frank VK> nausea from Spectrum and everything connected with it. In two VK> years, such people have vulgarized and trampled all ideas into the dirt VK> spektrumism. You just disgust me. It's better to be VK> the last lamer on the PC than such a spektrumist. You know what, honey, shouldn't we go to your ass? If everything is here for you it’s disgusting if “people who don’t have a PC” only do what’s wrong with you the unfortunate person is being offended, well then maybe you can just tell us: “Bye!” ? And we to you Let us _sincerely_ wish you a good journey into the wonderful world of PC? And write your attacks on piece of paper, crumple it up and put it in the place for which such pieces of paper intended. I was silent for a long time, but you seem to be just trying... :-((( Best regards, Dmitriy.