idea

=============================================================================== | Forwarded by Vyacheslav Mednonogov (500:812/1.30) | Area : ZX.SPECTRUM (Workers of all countries, unite!) | From : Denis Sotchenko, 2:5020/1301.70 (08 May 99 23:55) | Subj: idea =============================================================================== Subj is to put CP/M on the GS. Spec will be the terminal. B As a result, the performance will not be spent on working with the screen, and will be all the speed of the GS (that is, faster than the turbo Spec). __ __/ / Powered [ZX] [pepsi inside] ===========ReadMeAgain====================================================================== Warm greetings, Slava! [I.ZX] [ChV2=93%] [Free Nelson Mandela!]

Press RESET immediately, All! They wrote something here about inside programm design. And I had such a subject. After all, every program under tr-dos is really like an astronaut on the moon. It has its own functions for working with files, character generator with TTY type program, keyboard scanning functions, printer operation, with the mouse. Finally, there is its own bootloader, interrupt handling programs, memory allocation. Almost every program needs all this. Dems probably It’s worth eliminating right away so that later no one says that it’s slow and ugly. This is necessary primarily for application or system programs, maybe for games You can make a TR-DOS extender, which will provide all these functions of the program and will be connected itself either at the stage of assembling the program, or it will download the program itself. When using an external expander it will be possible not to worry about determining the computer configuration - the user can use an expander already configured on his computer. The basis will be the “core” which will ensure the interaction of different (sub)program distribution of memory and other (what?) system resources. The second part, important, but necessary only at the stage of loading the program into memory, will be a bootloader that will allocate memory in the system and load individualcomponents of the program. Everything else, in fact all the functions of the expander, will fall on many separate programs such as mouse, disk, screen drivers... It is quite possible that you will need a special bootloader format to boot. file, you need to store the necessary service information somewhere. The kernel should probably handle interrupts (for example, sending management of the corresponding driver), memory allocation, including and “can”, switching memory banks, interaction of the program with different drivers. I find it difficult to say what exactly will happen here. Be placed main part of the kernel will probably only be able to reach addresses 4000..bfff. What the bootloader will do depends very much on everything else, therefore For now it should be put aside. Required drivers... Exactly TTY (or a more advanced equivalent with graphics), a mouse tied to a coordinate output device, a keyboard, file functions TR-DOS, disk support at low level turbo and 3d13, can be printer, but there are many different interfaces... Of course it should be possible to replace existing drivers, even not quite drivers, or installation of more others (in the case of external expander). No, I didn’t plan a new super-OS for the spec, the planned volume of kernel codeno more than a few kilobytes, the listed drivers are also not many and large some, if not all, are already there. Only Open Source is assumed, otherwise just loses its meaning. Issues on the agenda: - Memory allocation main and above 128kb (see, for example, how it is done in CP/M or NEOS, both options have advantages and disadvantages) - Calling drivers from a program or other drivers, transfer of parameters, interface for interaction between different drivers. - List of required drivers, provided functions, interface for interaction with the program. - Separation of memory for the expander and the program, the program may require static allocation with absolute addresses. The same goes for drivers. It’s probably worth taking as a basis what is always available in memory The processor must have: Stack Interrupt vectors and programs for processing them Page switching program Variables storing the current configuration devices requiring access at any time Other The stack can of course move, but in the case of passing parameters through stack then you will have to copy part of it in place of the new stack. With another sides in the area of 4000..bfff there is not much space toallocate stack in all cases. (pioneers who do not know what recursion is, and those who claim that 256 bytes are enough for the stack, this is not a request comment). It seems clear with interrupt vectors, but NMI doesn’t go anywhere, Well, no big deal, this is an abnormal interruption... Switching pages with his own variable is understandable, the rest seems to be the same. The location of the resident part is probably under bfff and below - there it is does not slow down multi-field vehicles. And the memory that is higher is already bankable. There is probably a lot that is still forgotten and not listed. Well, if anyone is interested, then look at the questions (above)...