Pertec PCC-2000

 

Berlin in summer 2018. On vacation I see this interesting machine in the WEB and, how shall I say, I fall in love with it. Pertec PCC-2000, little I found on the web to the machine. No technical documents or other papers. Only mentions in old newspaper articles. It is noticeable, the machine was not successful, although as medium data technology in Germany also sold by the company RUF. A multi-user Basic or MTX was used as the operating system in accounting. CP/M was available as a single-user system.

And as it is like that, you want to be considered rarely make yourself. The wish to get the machine is fulfilled. On 18 August 2018 the time has come. I get my Pertec PCC-2000. 

 

I picked up the device together with a not quite complete replacement device and the station wagon was full with it. After the journey I started to carry it up to the 4th floor. Fortunately my neighbour ran into me, which he probably regretted. The 45 kg bring then nevertheless some sweat on the forehead.

Fortunately the Pertec worked and I had a running CP/M system. The previous owner had found the image for the disk in the WEB. In the Don Maslin archive (prtc2000.td0) and written on an eight inch floppy disk.

As you can see on the DIR, a CP/M 2.2 adapted by Pertec. Pertec has two nice tools: ASSIGN.COM and CONFIG.COM. This allows you to configure the hardware a bit. The settings are patched directly into the BIOS and are anchored in the boot disk. Unfortunately, Pertec didn't want to support the I/O byte, which brings with it some features. For many things you have to address the interfaces and devices directly without BIOS support. A detailed documentation would be helpful here, but unfortunately this is not available. Weeks of searching the web has not collected much.

What the hell, the device is running. First of all make familiar with it. Accompanying I loaded documents from Digital Research to the CP/M and had a lot of reading fun.

 

24 August 2018

The A: floppy disk drive suddenly stops working. No clack during access. What can it be?

Fortunately, the hood is easy to open and then you have a pretty unobstructed view of the innards:

 

So it was easy to discover that the floppy disk was not properly taken along. The head brakes harder than the drive turns it. Obviously the drive pressure of the insertion mechanism is missing here.

So the drive was first removed and examined. The screws to be adjusted were found, but no matching Allen key. Not to be found in any ratchet box or existing set of spanners. Therefore measured exactly and ordered online.

Fortunately the spare machine is still there and I could exchange the drive and continue.

The CP/M was now explored and it became very clear, every user software is missing! What to do? The internet is full of archives with software, but how do I get them on the Pertec? There are two possibilities: By diskette or by serial transfer. Due to the current lack of further 8 inch floppies, or computers with a suitable connection, the way over the floppies was set at the back.

So somehow this had to be done with the serial cable, because the connection is there. A null modem cable was available, as was the adapter. And on the other side a Minicom under Linux waited for connection.

In CONFIG.COM a "Remote Terminal" can be configured. If you do this, the local console is gone after booting and on the terminal side in the Minicom the CP/M prompt welcomes you.

The first step done, console on Linux computer successful! But how to transfer the data now? With PIP.COM:

PIP FILE.NAM=CON:

This causes PIP to write the input of the console into a file. Then it is terminated with Control-Z.

Since you can send files in the Minicom, as in most terminal programs, this works. BUT: This only works with ASCII files!

If I want to transfer a binary program, there are two possibilities. As ASM Assembler source code, or as HEX file (Intel Hex). Then the file to be transferred as ASCII. The HEX transmission is supported by PIP through the H option (line check).

So far so good, next BUT: The transmission is very unreliable. The serial transmission is not secured. From several attempts to transfer a text file, only Murks arrives. You need a terminal that can be told to pause after characters or lines. That's possible with Minicom, and the transmission has improved discreetly, unfortunately still not great. Because as soon as the buffer is full, PIP writes the buffer to the floppy and loses everything received in the meantime....

So you can only send files that fit into the buffer. For this you have to cut the files into pieces. Then the pieces are transferred individually and then reassembled.

 

How do I get a BINARY transferred? Therefore I have to make a HEX file out of the binary. More precisely, the INTEL-HEX format (DOS Tool: bin2hex -o256 file.nam). Then split the file in buffer size (DOS: split file.nam 20k file). Transfer the single files (CP/M: pip file.00n=CON:[H]) and assemble them afterwards (CP/M: pip file.hex=file.000,file.001...)

If now a complete Intel Hex file is available, a executable program can be created under CP/M with LOAD file (no file extension, LOAD expects HEX as extension!).

Done! In this way a MBASIC.COM came to the Pertec! 2 hours for 34kb! Wow!

 

28 August 2018

The Pertec has an "S" weakness. The sign just doesn't come. All right, the reverb sensor on the keyboard.

 

Take the keyboard out of the case, fiddle out the S mimic upwards. That goes badly because you have to press 4 plastic clamps at the same time, but it works. Replace and reassemble the sensor.

 

 

 

1st September 2018

The Pertec suddenly throws smoke and smells terribly. Quickly remove the plug, nothing works anymore. Burnt down! The smell comes from the power supply during disassembly. A short burnt transistor, but unfortunately it was not alone. So I don't get it right and the power supply goes to a friend who gets everything fixed. Unfortunately it takes some time.

 

22nd September 2018

The power supplies are back and the open circuit voltages are correct. After installation the Pertec works again. Pooh! Thank you!

The time device has now also a repaired power supply, there was a voltage reference. But after switching on no picture shows up. During the search for the cause I also found the potentiometer under the front housing, where the screen can be dimmed.... So everything beautiful. I would never have found it if I hadn't placed it so well.

 

Did I already mention, there were probably several salesmen of the device in Germany, who attached their own type plate?

 

The screen of the RUF 2000 looks funny, spotty? This is because there is a thick layer of a rubber-like material between the actual picture tube and the front glass pane. This rubber changes over the years and the visibility is quite patchy and foggy! So it has to get out. For this I took a stable braided nylon cord and very carefully "sawed through" the rubber layer. Looks terrible, is also no fun, lasts much too long and crumbles everything fully. After the separation it can be pushed halfway away and cleaned. If you now mount the glass plate with a small spacer, it looks almost like before. Only the oblique view is not soo great.

 

4th October 2018

XMODEM. Since the binary transfer is so laborious, I have looked a little further to improve that. Unfortunately the Pertec does not support the I/O byte convention of CP/M. Therefore I can't get the program Kermit to run.

On the web I find a lot of PCGET and PCPUT programs that can transfer files serially with the Xmodem protocol. Unfortunately, the properties of the serial interfaces of the devices are usually programmed here or use the interface names of the I/O byte.

My assembler skills are only sufficient for rudimentary tests. So I cannot adapt these programs. Because of the missing documentation to the Pertec I have looked times, how this was done then with the mental Vormodell, the Altair 8800. With the hope, the apple doesn't fall far from the horse I looked at the documents to the S2IO, the serial interface of MITS. Then a few small tests written in assembler and lo and behold, I can read and write characters! It's just the IO address different, initialization and baudrate coding like on the S2IO. For the Altair 8800 I also find a PCGET and PCPUT in assembler. Finally only the address has to be adjusted and ready.

Since then the serial transmission with the XMODEM protocol works as well.

Now it just bubbles with software from the internet onto the Pertec....