Introduction
Computer architecture
ZX Spectrum is an 8-bit computer based on the Z80 processor. It differs from other similar computers in that instead of a specialized video controller it has just a combination of counters and multiplexers (originally assembled in BMK , but easily translated into "loose" - small logic microcircuits). Due to this, the computer first won the price race and became the default car for "bedroom programming", and then easily escaped from the original manufacturer and won an important place in the computerization of many countries of the world. Including - the countries that were part of the USSR, where Spectrum-compatible cars were produced in about a million copies (in any case, more than BC, DVK and UKNTs combined).
A stunning list of famous clones - here... The "openness" of the architecture (from the point of view of a soldering iron - and without a soldering iron, our clones were even problematic to connect to a TV) turned the ZX Spectrum into a very sophisticated platform, with atypical for other 8-bit platforms (which are already dead or alcohol-based) megabytes, megahertz, hard drives and network cards.
ZX Spectrum still works as a platform for indie games (see the currently ongoing Yandex Retro game battle and Your Game 6 contests , the deadline for which has been extended until December 1 ), but development is rarely done in the original format, because. e. on the Spectrum itself. This is due, among other things, to the fact that native development environments written under TR-DOS in the 90s and 2000s, they lagged behind life, and nothing new came to replace them.
The need for an operating system
Operating systems for the Spectrum have been written for a long time. The operating system, which sits in the ROM, allows you to write in BASIC and tinker with magnetic tape. Disk operating systems TR-DOS, GDOS, + 3DOS, etc. added commands to work with a floppy disk in BASIC, but only TR-DOS acquired serious utilities, and not due to a rather awkward BASIC interface, but due to the documented (and not so) points of entry into the TR-DOS ROM.
Apart from several versions of CP / M (which was originally written not for the Spectrum and does not use its capabilities at its true worth), the first serious Spectrum OS was single-tasking iS-DOS ( one , two , three , archive), developed in St. Petersburg at the very beginning of the 90s. It "out of the box" provided a commander and a file system with subdirectories (incompatible with anything), a text editor of arbitrary size, many utility disks and the ability to expand with its residents. Unfortunately - extensions are only within the 48K RAM window. The first versions of iS-DOS were content with 41K for the entire system, residents and user program, the rest of the RAM space was occupied by a 6912-byte screen.
iS-DOS in natural habitat
The latest versions, still released under the name TASiS ( one , two ) and sharpened under the ATM-Turbo 2+ clone, allow you to expand to the entire 64K address space, remove the screen from memory and switch RAM pages, but the kernel of the system still remains in the address space. (The same applies to CP / M - in all known versions the system occupies the top addresses and is indestructible.)
Other attempts have been made to write an OS. Unfortunately, none of these operating systems received noticeable distribution, and many were not finished at all.
The already mentioned iS-DOS has spread in St. Petersburg and Moscow. An approximate functional analogue of iS-DOS on TR-DOS disk - X-DOS - stayed within Kirov.
X-DOS and its command line The
multi-window system DOMEN OS / Pink Floyd , also from St. Petersburg, did not live up to a usable state. In particular, it did not support hard drives, and there were no development tools in it.
OS DOMAIN and its documentation in HTML
Kharkiv DNA OS system , mainly sharpened for copying files, brought some benefit to the owners of "screws", but "software for screws" did not appear in it.
DNA OS and its file manager
Moscow NK-DOS , brotherly NeOS , Grodno DOORS \ AQUA and Saransk ZX-OS / ZXRTK did not live to see viable releases . Of the multitasking operating systems, the closest to the user came the multi-window MythOS (Dnepropetrovsk) and ChaOS (Taganrog), but they also ended their lives in source - also without the support of hard drives and without development tools.
MythOS and its console
ChaOS and its chaos
Why were there so many failures?
Hardware requirements for a multitasking operating system
The problem with all early operating systems for the Spectrum was that the developers tried to ensure their creation maximum compatibility. For example, on iS-DOS - with machines starting from ZX Spectrum 48K (with a floppy drive or HDD), and on most subsequent systems - with ZX Spectrum 128K. This left an indelible mark on memory allocation.
The fact is that on 48K machines, the total Z80 address space of 65536 bytes was divided into 2 parts: 48K of RAM (of which 6912 bytes were consumed by the screen, which left 41 kilobytes for everything else) and 16K of BASIC ROM, which is of real benefit to the OS no. Things fared better at 128K, but not much. The screen from the Z80 address space can be removed there (by selecting the second video buffer), but you can switch RAM pages only in the upper quarter (from address 0xc000) of the address space. The remaining 32K of RAM is not switchable. And the lower 16K and continue to contain ROM unnecessary for the operating system. Of course the proprietary 128K allows external devices (such as LEC Memory Extension , DISCiPLE / + D , MB-02) replace the lower 16K, and its descendants, starting from +3 , usually have one or another built-in port for this (most often only one page of RAM is available there), but half of the addressable memory still cannot change with task switching.
Imagine that you are writing a text or graphics editor for the operating system for the ZX Spectrum 128K. Obviously, the upper 16K is too small for text or illustrations (we are not talking about the standard "screens" of 6912 bytes), and you either have to constantly load the file from disk (which is slow and inconvenient), or scatter the document over the pages. Where, in this case, will the code of the editor itself, its variables and stack be located? Not in the top 16K of RAM, because that's where the document is. Not in the lower 16K, because there is most likely a ROM. It turns out that all tasks will have to share one common block of 32K RAM. The relocated residents, split, say, 256 bytes each, call procedures from the upper RAM, separate residents - buffers for working with data, the stack is also limited to 256 bytes ...This is very inconvenient for developers. Result: only the authors themselves wrote for such systems, and they only had enough fuse for a year or two, which is not enough even to create a development environment.
Thus, for a convenient multitasking system on the Spectrum, it is vital to have switchable pages of RAM in each of the quarters (the choice of 16K quarters is traditional for the Speccy) of the Z80 address space. There are few Spectrum circuits that can do this: these are the little-known "ZX-MMU" from fk0 (2000) and the more or less common ATM-Turbo 2 (+) (1992, 1993):
From the documentation. Set bit 6 enables control through port # 7ffd (ROM TR-DOS automatically replaces ROM 48 BASIC when executing code in # 3dxx), otherwise bit 7 simply turns on the specified ROM page. "ROM2" is bit 4 of port # 7ffd, it always works.
Many operating system authors believed that this requirement for a memory subsystem to be able to switch everything would severely limit the number of users, and did not accept it. As a result, they got about 0 users - due to the lack of software.
Development of
Background; what is NedoPC
In 2002-2003, the NedoPC movement was born on the vastness of three continents, which can be briefly described as ... um ... the development of computers from improvised means. And NedoPC started with what others had finished at that time - to produce Spectrum and devices for them. And as the Spectrum they took the same Turbo 2+ (1993) - a descendant of ATM-Turbo 2 (1992), which is a descendant of ATM-Turbo (1991), which is a descendant of Pentagon 128 (1990), known in narrow circles as ATM 128 (history of the struggle firms in the dashing 90s can be found in the description of the Honey Commander'y). At one time, Turbo 2+ (to which the ATM designation was already automatically stuck, as in previous versions) almost intended to replace the IBM PC of early configurations - with an HDD (later a CD-ROM), an analogue of an EGA, an XT keyboard (later AT), a COM port, a DAC, an ADC (which also played the role of a modem) and the games "Prince of Persia" and " Gobliiins ", which were absolutely correct from the PC version (I do not mention all the software, there is a lot of it). But part of the ingenious scheme was hidden in the PLM, which is why very few people could copy it. In the vastness of Ukraine, rumors were heard about replacing the PLM with ROM and about copying a separate HDD controller, but in general, a computer in the 90s was much less common than the Pentagon. Fortunately, then the developers of Turbo 2+ - MicroART company - donated all the documentation for free use.
Almost immediately, several software developers were drawn into the orbit of NedoPC, and they talked about operating systems. Otherwise, the answer to the question "where should we sail" did not work. The first fruit of hard thought in 2005 was the already mentioned TASiS system, for the sake of which the iS-DOS sources were acquired.
In parallel, in 2007, one of the authors of this article created a virtual character SMAN, who was developing a multitasking operating system. And yes, it also went through the Resident in Lower RAM phase. This stage dragged on for years; in 2016-2017, a C-like language compiler NedoLang was even written , which fits into 48K (also compiles for ARM Thumb). The Gordian knot was cut only with the appearance of the graphic editor Scratch (2018).
Scratch and its menu
The choice in 2018 was already easy: compatibility with ATM-Turbo 2+ was available to all users - if not on the original hardware and not on the NedoPC's ZX Evo and Pentagon 2.666LE, then on the ATM3 from Zorel or at least in an emulator (Unreal Speccy, Xpeccy, ZXMAK2, Es.pectrum, etc.).
Turbo 2+ (1993, but the board is clearly newer)
Pentagon 2.666LE (2009), a very rare car
ZX Evolution (2009), can be bought at any bakery
ATM3 (2017), you can get it only by acquaintance or make it yourself.
From that moment on, the system was named NedoOS and began to develop explosively.
It should be noted that in order to curb fantasies at the initial stage of this explosion, the system was built mainly on commands compatible with CP / M and MSX-DOS. Until now, the list of commands is divided into three sections: compatible with CP / M (now there are 13 of them, their use is not recommended due to the inconvenient FCB system), compatible with MSX-DOS (there are 11, there the file name is already in text, and instead FCB structures use numbers - handles) and incompatible (mostly non-file, there are 48 of them now, but some are planned to be dropped).
Development system at the moment
The NedoOS source code is still not adapted for the compilers available on the system (NedoLang and its assembler NedoAsm, Turbo Pascal and BDS C). So far only 5 utilities are compiled internally. And the main part of the package is built on a PC using SjASMPlus (main code) and Z80 IAR C (FatFs file system and some utilities).
The files are hosted on a dedicated SVN server and consist of sources, a binary release, and a collection of tools for building on a PC.
The system is assembled with one button (batch file or Makefile - two build systems). You can also separately assemble one of the targets (for HDD, SD-card, etc.) with one button and immediately start the emulator. You can separately collect each utility with a lower-level body shirt. The two build systems happened because some of the NedoOS developers are on Windows and some on Linux.
In addition to compilers, there is also the cmd.com command processor (can execute * .bat) and the NedoBasic interpreter written from scratch with graphical capabilities.
NedoLang compiles itself
System architecture
Kernel device
The part of NedoOS visible to the user program is a series of calls in the memory area 0x0000..0x0038, the so-called kernel. The last of these calls is a 50 Hz interrupt handler, followed by a command line with parameters for the program with 0x0080. The kernel device is still compatible with CP / M (call via 0x0005), but we are slowly moving away from this (CP / M calls are used only in 4 programs out of 58). All system calls are organized as macros (programs use the /src/_sdk/sys_h.asm module with these macros and constants) and can be significantly modified as the OS evolves. The consequence of this is the need to rebuild the entire system and application software in case of any changes in these macros - but, as we have seen, this is done with one button.
The interior of NedoOS is tucked away in pages of RAM and contains:
- ;
- ();
- , , โ , , ยซยป (. ), ;
- (BDOS), call 0x0005, CP/M MSX-DOS;
- (SD- Z-Controller, SD- NeoGS, IDE HDD, , USB flash ZXNetUSB);
- ( 40- PS/2- ZX Evo);
- (Kempston mouse );
- ( Mr. Gluk), 50- ;
- (Wiznet W5300 ZXNetUSB);
- FatFs FAT-16 FAT-32;
- TRDOSFS TR-DOS RAM-;
- ;
- FatFs, TR-DOS ();
- .
All drivers are compiled into the kernel, so there are several different "targets" for building the system ( ATM2 , ATM2 + HDD , ATM3 , ZX Evo , Pentagon 2.666LE ).
The interrupt handler, which is located in user space, looks like this:
push af
push bc
push de
user_fdvalue6=$+1
ld a,fd_system ;
out (0xfd),a ; ( ),
;---------
; :
;bc=memport0000
;d=pgmain
out (c),d ;may switch this code page
curpg16k=$+1
ld a,0
ld b,memport4000/256
out (c),a
curpg32klow=$+1
ld a,0
ld b,memport8000/256
out (c),a
curpg32khigh=$+1
ld a,0
ld b,memportc000/256
out (c),a
pop de
pop bc
pop af
ei
ret
Task switching occurs in a circle (frozen tasks are skipped), there are no priorities yet. But the idle task is executed only when everyone else is either frozen, or in the current frame they themselves called YIELD (the YIELD system macro - to give time to the system until the next interrupt, the YIELDKEEP system macro - to give time to the system with the ability to return control at any time).
The task can change the interrupt handler, it is possible with a return to it and arbitrary code after it. There are certain recommendations and examples for this.
Terminal system
Tasks are divided into three types:
- those who don't need a screen at all,
- those for which a text terminal is sufficient,
- graphic - with its own screen of the required resolution and its own palette.
In NedoOS, in addition to the concept of the current task, there is the concept of "focus" (access to the keyboard, mouse and screen). The focus between tasks is switched manually (by a combination of Symbol Shift + Enter) or automatically (when you turn on graphics, turn off graphics or close a task).
Tasks like (1) never get focus. Moreover, tasks of type (2) also do not receive focus; instead, the focus is on the text terminal to which they are attached. And they are tied through the stdin and stdout streams, along which letters, numbers, squiggles and codes of the VT-100 terminal walk with some additions. Stdin and stdout are implemented through the stdio.asm library as queues (pipes). In the kernel, the queue has a 255 byte buffer. The write and read functions from the queue return how much is actually read or written (as for files) and whether the queue is closed at the other end. These streams are inherited from father to son. But in the end everything is displayed by the term.com terminal, which can be scrolled and even copied and pasted. There is also a network Telnet server netterm.com. This netterm.com does not need to be started, but term.com starts automatically at system startup.
Nedovigator in the terminal, and the terminal is scrolled with the mouse wheel
For tasks like (3), of course, there is no question of drawing pixels through the system - there are not enough Z80 megahertz for this (most users have only 14 of them). Therefore, it is necessary to draw through memory. And since there are only two screen areas on ATM (as on 128K), only one task can have its own screen pages. The pages of the screen are intercepted when the focus is changed, and instead of them the loser task is given a fake page number - a page that can simply be spoiled. When a task receives focus, it receives a separate message about it, as if from the keyboard, but does not correspond to any real button. This allows the task to restore the screen in time. Another task can turn on the mode when the system itself stores the screen for it and restores it.
Command line
Command line functions are implemented by the cmd utility, which is automatically launched at system startup. More precisely, the first idle task runs term with parameters cmd.com autoexec.bat. This means that cmd will execute the specified batch file. The commands written there are executed in order. By default, commands are executed waiting for the end, but if the command is the start of the program, then you can put start in front of it - the program will run in the background (only this is not compatible with the concept of inheritance of stdin and stdout - data in queues can be mixed).
After the end of the operation specified in the parameter (if there was a parameter at all), cmd usually exits. An exception is left only for autoexec.bat, so that after it ends, you will not be left with a broken trough. However, in which case idle waits for the simultaneous pressing of C + M + D and can restart term with cmd.
The command line is similar to MS-DOS. You can redirect the output of a running operation to a file (for example, dir> filename) or to another program (for example, dir | more.com), you can redirect input (for example, more.com <filename). But chaining is not yet supported.
For more convenient work with files, the Nedovigator commander (nv.com) is used.
Kitty, because you've already seen the Nedovigator
System placement
It should be clarified that each file system we have is mounted to a specific letter, so the paths look like m: /bin/filename.txt. The queues have the z: mount letter, but so far they are opened without a name - the connection between tasks is by passing the queue number (handle).
To avoid specialized bootloaders like GRUB, NedoOS hopes that the computer's ROM has the ability to launch the trunk file (*. $ C) from the desired device - for example, in the ZX Evo with a file browser or by pressing the 5 button in the main menu, and on the Pentagon 2.666 LE - via built-in copier Fatall... Otherwise, you will have to boot the OS from TR-DOS floppy disks. System files are located in the / bin directory of the system disk, games are in / nedogame. Additional game files are usually located in a subdirectory of the game of the same name: for example, a NedoOS-colored game /nedogame/br.com ( Black Raven ) also has a / nedogame / br directory with graphics, music and levels.
Colored Raven
Current opportunities
Memory: up to 4M RAM is supported (configurable in the build system), memory is allocated to tasks on demand in 16K pages, tasks can return them to the system themselves. Due to the lack of memory protection in hardware, all memory can be considered shared. By default, pages are allocated from the beginning of memory, not counting a few system pages. Swap is not supported (it was considered in the early stages, but requires page renumbering, which will greatly reduce the performance of common tasks).
Multitasking:displacing (by interruption of 50 Hz) and cooperative; up to 16 tasks can be run simultaneously (one of them is idle, it can be removed, but then YIELD does not give guarantees); you can substitute your music player into the system interrupt handler - it will be executed in the context of the kernel with three user pages (you cannot switch them on the fly yet). Tasks can be frozen (if they have just been created, deleted, or awaiting a child). You can view the list of tasks in cmd, their activity and the presence of a graphical mode, remove from execution (this frees up their pages, FatFs file records and network sockets).
Files:up to 16 FAT files, 8 TR-DOS files and 8 queues can be opened simultaneously. You can read and write multiple files at the same time (important for the compiler) - even on a floppy disk! You can read file parameters, a pointer to the current position, change this position, create and rename directories. Queues assume two user tasks, they need to be opened once (when created), but closed twice. File operations are performed in the context of the kernel, at this time the task scheduler does not work, but the system music processor is running.
Networking:ICMP, TCP, UDP protocols, up to 8 sockets simultaneously. There are utilities ping, time, telnet, netterm (Telnet server), dmirc (IRC client), dmftp (FTP client) 3ws (Web server for copying and remotely launching files), NedoBrowser (text browser with the ability to view pictures separately jpg, gif, png, bmp and svg - the last two formats with restrictions; supports the protocols http and gopher, https through a proxy), wget (background file download, runs from the browser, can automatically start viewing graphics and a music player).
NedoBrowser is looking for something on the Internet
Working with archives: .tar and .rar are available for reading and writing (ZXRar is a stripped-down analogue of Rar 2.x for DOS - without a number of codes, solid archives, multimedia format and encryption, ZXUnRar supports all codes and solid archives, but also does not support multimedia and encryption), .gz and .zip are read-only. So far, everything is only through command line utilities.
Document types: file associations are registered for the built-in Nedovigator commander in the nv.ext file. Now this file looks like this:
bmp:scratch.com
bat:cmd.com
txt,new,ext,ini,nfo,diz:texted.com
gif,jpg,png,htm,svg:browser.com
tfc,pt2,pt3,mt3,m :player.com (pt3 Pro Tracker NedoOS)
bas:basic.com
zip,gz :pkunzip.com
trd,scl,fdi,tap:dmm.com ( TR-DOS โ ZX Evo , , Magic; , , )
16c,scr,fnt,img,3 ,888,y ,+ ,- ,plc,mc ,mcx,grf,ch$,mg1,mg2,mg4,mg8,rm ,mlt:view.com
mod:modplay.com
tar:tar.com
sna,b ,z80:nmisvc.com
rar:unrar.comThere are also a dozen games available, including a Super Mario emulator (requires a cartridge dump to work), a painted by Eric and the Floaters, a partial port of Endless Summer, and a networked Snake.
Plans
- Expansion of the functionality of batch files (parameters are already being transferred)
- IDE and self-hosting
- Layers in the graphics editor
- ...
Conclusion
At the moment, NedoOS implements all the necessary backbone of functions, so if you have the necessary hardware, the system is more convenient to use than not to use.
But there is still a lot of work ahead. The more developers join the project, the closer the ideal.
Most of the NedoOS developers live in the #mhm IRC channel at irc.forestnet.org (also available through http://chat.forestnet.org/ ). There is an evening Twitch channel (with a YouTube mirror ). From the NedoOS website you can download the stable version and the latest sources .