PC computer "Search". Electronmash

Today I would like to tell a little about the Soviet PC undeservedly deprived of attention on Habré. What distinguishes this computer from the numerous Bytes, Irish, Corvettes, BK0010, Radio-P86 and others is that it was semi-compatible with IBM XT / PC. The machine was based on the domestic analogue of the Intel i8088 processor - KM1810VM88, operating at a slightly higher frequency - ~ 5 MHz, compared to 4.7 MHz for the original XT. However, in general, the computer worked more slowly than the XT, because the Search did not implement a full-fledged CGA video card. In fact, the text modes were emulated - the video adapter always worked in graphical mode, and the letters on the screen were drawn by the system BIOS pixel by pixel. Naturally, this took up a lot of processor time. Another difference from the real XT was the lack of DMA, which also affected the speed of working with memory not for the better. And the memory itself was far from 640Kb, which of course would be enough for everyone, but less, and it was not enough for everyone. However, despite all the shortcomings, the PC Search could run MS-DOS, which was relevant at that time, and work with almost all popular applications and games at that time, starting from Norton Commander andDigger , ending with Windows and Office. And the price, of course ... If only organizations could afford a real XT-shku, then Search PC was more or less available for an ordinary Soviet engineer (monthly salary). But first things first…

Foreword

Generally speaking, strictly speaking, there have been several modifications to Searches. The main difference was the amount of onboard RAM. The first models of Searches had only 128 Kb, of which 32 Kb took away video memory. The user had only 96 Kb of free memory. The latest models already carried 512 Kb, 32 Kb also went under the video memory and the user had 480 Kb. This already gave a chance to launch something else besides DOS itself.

However, I spoke about DOS early, because the standard package included the all-in-one, a power supply and a couple of cassettes with system programs and games. And that’s all. Thus, any controller, be it a drive controller (and, of course, the drive itself) or a joystick controller, the user had to purchase separately. In the meantime, the user could work with a cassette recorder as a storage medium. The cassette interface was “copy-paste” from the bourgeois computer IBM PCjr. The cassette recording format was identical to PCjr and another Soviet “brother in spirit” - Electronics MC-1502 , also x86 compatible, and also like Search, not without a “twist” from the creators. And so, as long as we don’t have a drive controller, I’ll start with cassettes.

Recording format on tape and tape interface

The search is not so popular among fans of old computers, such as ZX-compatible and their clones, so there is simply no software for working with cassettes, and I decided to correct this injustice. So, the data is recorded in the form of zeros and ones. If the polarity manages to change from negative to positive in 1 millisecond, then this is a single bit. If not in time - then zero. So zero is about 0.5 milliseconds, one is 1 millisecond. Knowing this, you can easily decode the signal directly visually with your eyes. For example:

Here, “swinging” periods with a large interval are units, short ones are zeros. In total, the figure shows 1111 0000 1011 001. Each recording starts with a pilot tone, which consists of 256 bytes 0xFF, that is 256 * 8 = 2048 single bits, followed by the recorded bit '0', and then the sync byte 0x16 (00010110 ) All data is written in 256-byte blocks, followed by 2 bytes of the checksum. The checksum is calculated according to the CRC-16 algorithm with the polynomial 0x1201, the initial value = 0xFFFF, after calculating CRC = CRC xor 0xFFFF. After the pilot tone, zero bit, and 0x16 sync byte, there is a 256-byte header that contains important data such as the file name, file type, segment, and the offset where the program will be downloaded.

    Poisk_hdr     = Packed Record
      Magic       : Byte; // A5h
      FName       : Array [1..8] of Char;
      FType       : Byte;
      FLen        : Word;
      Seg         : Word;
      Ofs         : Word;
    End;

The header is padded with zeros up to 256 bytes. Next is its checksum - 2 bytes. The sequence ends with 4 bytes 0xFF. Then again comes the leader (pilot tone) with units, synchronization bit 0, synchronization byte 0x16, and here the data blocks already begin. At the end, the sequence also ends with 4 bytes 0xFF.

The result of picking with the recording format was two small utilities: CAS2WAV and WAV2CAS. The first allows you to create a .WAV file from a binary file, which can later be played on a regular mp3 player. The second, on the contrary, is trying to create a binary file from a cassette record. Therefore, if someone has cassettes from Search or from MS-1502, then digitize them, please, in WAV, for collection and history. Download the most complete set of cassette programs and games for Search at the moment here: vizersprojects.ru/archive/sannata/apps.zip

Cassette

Now that it is possible to create WAV files, convert the cassette software and record it on an mp3 player. We connect the player to the “RECORDER” connector and turn on the power.


In addition to the main functions of interrupt processing, a small program was recorded in the BIOS of the Search, a monitor that allowed you to enter a file name and load it from a tape recorder into memory:


Programs and games were mainly Russified versions of popular games and programs from IBM PC. For example, BASIC is nothing more than Microsoft Basic, which was wired into the ROM of an IBM PCjr computer. Find two differences:






However, in fairness, it is worth noting that they had their own games, for example chess or reversi.

Additional controllers (adapters)

Yes, as previously mentioned, it was possible to connect additional controllers or adapters to the Search, as stated in the instructions. To do this, Search had four expansion slots, where up to four controllers could be installed simultaneously. In fact, the bus is standard at that time ISA-8, but of course with a different connector and some one (or two) inverted signals. Search controllers were produced both at the factory, and so were made by cooperatives and even amateurs.

The first thing that was desired and necessary was the drive controller. With him, Search turned from a typewriter for BASIC and games into a serious DOS computer, opening the user with the whole set (well, almost all) of x86 software existing at that time. What they didn’t do with these controllers was turbocharged (increased read / write speed), laid in the firmware support for 800 Kb of diskette formats, instead of 360 Kb. In general, they were different, but in general they worked well and quickly with floppy disks. This is my controller:


And this is another drive controller:


For Search models with 128Kb of RAM, it was also necessary to purchase a “RAM Expander” to run something else besides DOS itself. The “RAM Expander” was inserted into the slot, like a regular controller. There were different models, at 256 Kb, 512 Kb and even rumored to be at 670Kb. Sometimes they were combined with something else, such as an LPT port. On the copy I have just done so.


And of course the hard disk drive controller with MFM interface. The beast is rare and expensive, as, however, is the hard drive itself. Allowed to connect to the search hard drive up to 68 Mb. No less unique was the loop itself, by which the controller connected to the hard drive.


I had to tinker a bit with it. First loop. It is not standard, and I had to whip up a rough outline of the scheme:


And solder such an adapter:


Next, I tried to get the controller to work with my existing Robotron K5504.20 hard drive for 20 MB. Low-level formatting ended without errors, but when I tried to start FDISK and partition the system partition, an error occurred: Error reading fixed drive. I sinned on the cable, tried all the combinations of jumpers on the controller, changed it by editing the parameters of the controller for this particular screw in the controller firmware - it is useless. Nevertheless, FDISK sometimes started up, but when it tried to write partitions to disk, it crashed. Moreover, I knew for sure that this Grobotron was completely working - it was formatted without problems, laid out and generally felt completely normal on my XT-shke. Hero of the occasion:


After “ringing” and checking the cable for the hundred thousandth time, I spat and still decided to connect my second Seagate ST-225 MFM hard drive, which was in my XT box. True, I had to pre-backup it with a null modem to the main computer. And, lo and behold, it was formatted without any problems and earned the first time. So I had to leave Seagate on the Search, and put the Grobotron in XT, although I wanted the opposite.

There was also a joystick controller and, accordingly, the joystick itself. A funny device that is not compatible with anything other than itself and does not look like anything. The driver program allowed you to set the correspondence of the slope of a key on the keyboard, thereby, when the joystick was tilted to the left, the left key was emulated, etc. Generally a good idea. All this allowed you to play games with the joystick, even if the game did not support the joystick.

Offal and repair

My search broke for a long time and was faulty. The malfunction was a periodic sudden freeze or even reboot. Logically assuming that it was all a matter of memory and running the CheckIT program with the test, I saw such a sad picture:


We pick up a screwdriver with a sledgehammer , unscrew a few screws from the bottom and remove the top cover with the keyboard. The whole motherboard opens to the eye:


In the center there is a ceramic processor, in the upper right corner on the BIOS ROM panel, and from the bottom 16 sealed K565RU7G microcircuits - this is the memory. I didn’t want to solder sixteen microcircuits, so I decided to try a method that I had heard somewhere before: put a new one on top of the legs of an old microcircuit and look at the memory test to see if the situation changes. If something changes, then replace the chip. Only one thing stopped me - every time I put on a new chip on the old one, connect the keyboard, load DOS, load CheckIT and run the test. And it would be okay with the time spent on downloading the program ... The keyboard also does not have a very reliable cable, and from frequent switching on it will definitely not be better off. In short, laziness is the engine of progress. Good old TASM (assembler) was pulled from the archives.
In general, writing a program in assembler instead of BIOS is slightly different from writing a program in assembler under DOS, for example, in that we do not have the usual BIOS interrupts (we write it) and DOS, and in order to display something on the screen need to draw characters by hand. On the other hand, all memory is at our disposal and you can do anything with it. Well, the truth is, you won’t save much data in registers alone, so still you have to store some variables in memory. Well, of course, the stack, too, because without a stack, you cannot call a subroutine or save a register value. In short, the stack is also a useful thing. Therefore, I first test the first kilobyte of memory - if there are errors, then we pick three times and hang the processor. If everything is fine, we set the stack in the first kilobyte, the variables, and the main test starts.

Total, a little shit tak_sebse_code (because on the knee and for yourself) and the test is ready. I stitch it in ROM, turn on the computer and see the same thing that CheckIT showed me, only in my test and instantly:


That's it, now gradually I begin to “push” a known-good microcircuit on top of the soldered ones. Quite quickly I found the first faulty one in the region of 152Kb, replaced it, then fiddled around for a long time with errors in the region of 264Kb, but gradually reduced, reduced and reduced it to zero. As a result, I replaced seven microcircuits (perhaps some in vain), at the same time I raised them to the sockets:


Seven though many, but not sixteen all the same. My test passes without errors, CheckIT without errors and in general, all conceivable and not conceivable memory tests are error-free. Victory!

Soft

With a drive, and even more so with a hard drive, Search literally “came to life” and became a big serious computer. Where were those cassette toys when you could play this:










And of course, Windows, just for lulz, as they say. Version 3.0, it does not work hastily (but what did you want from 480 Kb of RAM), but you can work.

Upgrade (half successful)

Last winter, two NEC V20 processors came to me from China . In theory, it is fully compatible with the i8088, works somewhat faster due to the improved hardware implementation of division and multiplication, contains a set of instructions for the processor 80186 (for example, shifts with an argument other than 1, saving all the registers onto the stack and td). Almost 80286, perhaps only without a protected mode. Well, as a pleasant bonus for retro lovers, it has hardware support for the i8080 processor commands, so you can run native software from CP / M for the i8080 through a special program on it.

Therefore, pick up a sledgehammer, a soldering iron with a desoldering pump, we stock up on patience and carefully solder the Soviet KM1810VM88. We put the DIP-40 socket on which the NEC V20 is snugly arranged:


As expected, the computer starts without problems. Now you can measure a little parrots. First, the tests of the original KM1810VM88. General performance:


Video subsystem with KM1810VM88


And then NEC V20:


CPU test with NEC V20:


And video subsystem:


It can be seen that the computer runs somewhat faster with the V20, especially in mathematics. The video subsystem also became somewhat faster due to the fact that in some BIOS functions of character rendering, in some places there are multiplication and division operations. Good processor, what to say. But then an unpleasant surprise awaited me further - when I tried after these tests to load the usual Volkov Commander, I saw the following:


It is noticeable that every second character on the screen is not drawn. For a long time I thoughtfully looked at the BIOS code responsible for everything related to character output, looked at int 10h processing programs. I thought it would be quite easy to patch the BIOS for incompatibility with the NEC V20, because I knew that even though the NEC V20 and i8088 use the same set of commands, there are still differences. I checked the code for the following things:

1) POP CS , and generally I didn’t see two-byte POPs in the listing. v20 does not eat them;
2) After MUL, v20 does not reset ZF if the result is 0. There are several MULs in the code, but ZF after operations is not checked anywhere;
3) Exotic AAD / AAMnot found anywhere. In Intel, instructions can take an argument; in V20, it is always = 0Ah;
4) The same goes for the SALC (D6 opcode) instruction , which v20 interprets as XLAT . There are no such instructions in the BIOS;

Fix the problem with a swoop failed. Further, at the prompt of one user from the ZX-PK.ru forum, I drew attention to the fact that programs that work with video memory in this way are buggy. The Search, as already mentioned, does not have a physical text mode, so when a program tries to write something to the 0xB800 text memory region, an unmaskable hardware interrupt is generated and control is transferred to the Int 2 handler. The NMI handler in turn reads the value from port 0x28, in which the offset is located at which the recording occurred in the memory, and begins to draw a pixel by pixel symbol in the graphic video memory 0xBC00. After the symbol is drawn in the video memory, the NMI handler exits. That's about such a simplified scheme and the visualization of characters from text mode to graphical mode. So, through trial and error, it turned out that when several characters are written to memory at onceREP STOSW , say two, the hardware address trap does not work and in port 0x28 instead of shifting to the last character sits the offset of the previous character. NMI is also not called. It can be assumed that V20 uses less clock cycles per REP STOSW cycle , and the circuit is designed for a larger number of clock cycles, so the circuit only works for every second cycle. Total, the problem turned out to be hardware, unfortunately. Of course, you can bypass it and programmatically, for example, as a crutch in the NMI handler, draw not only the current character, but immediately the neighbor, but this, as you know, is just a crutch. If you do not pay attention to this drawback, other programs work fine, including games.

Finally

Search PC - this is my first computer, probably because of this more attention is paid to it than to my other old pieces of iron. The forum ZK-PK.ru and its "Search" section are very helpful in technical matters. Now several enthusiasts are preparing for the release of a replica of the MFM disk controller, drive. In general, there are many plans, for example, the manufacture of an IDE controller (especially since such a controller existed at the time of the launch of the Quest), possibly an IDE-CF (compact flash) controller. If someone suddenly had tapes with a recording, or some rare controllers (adapters), I would be glad to discuss the possibility of receiving them (in personal messages). Good luck to all!