Programming under BC 0010 in 2019

What for?

If you are an enthusiast of retro computers, then you can safely skip the motivational speech and go to the next section.



All of August 2018, I and my 13-year-old son Ivanq spent writing a Good Apple demo. At the Chaos Constructions festival, our work took second place, for which we received a cash prize of 35 thousand rubles, which we honestly divided equally. For a child, this is a good income, although by creating sites he earned the same amount in less time. Obviously, I could spend my time with greater economic benefit ... But not August! One must once rest from work. Programming for your own pleasure is a luxury that you can only afford on vacation.







Material reward, of course, does not serve as motivation, but reinforces positive emotions. Surprisingly, the demo for a forgotten Soviet computer collected thousands of views on youtube and ended up in a playlist with almost a hundred thousand views. But even more surprisingly, in 2018, a cash prize is awarded for her! Perhaps the very improbability of what is happening gives rise to such an emotional upsurge.



However, there is something more important.



When creating “Good Apple” we had to work with real hardware, since we used the capabilities of the computer, which emulators do not reproduce correctly. First of all, I wanted to achieve equally stable work with IDE format hard disks and with their modern substitutes in the form of Compact Flash.



It was on this project that my 13-year-old son gained invaluable experience in industrial development. Defective iron. Good hardware that does not behave as described in the documentation. Documentation that is drafted with errors. Lack of documentation on a number of issues. Writing your own tests to identify problems with iron. Outgoing deadlines. Testing on different machines and configurations. Writing your own cross-assembler (when it became clear that existing solutions hinder the development process). And finally, after a short celebration of success - the mandatory release of the final version, correcting a number of bugs.



At first glance, it seems that a similar experience could be obtained with some modern Arduino. In fact, we had to plunge into the very jungle of circuitry. We calculated the number of measures for which the instructions are executed. In different types of memory, this time is different. The memory controller and processor operate at different frequencies, so the same commands can be executed at different times, even in the same type of memory. The duration of the subprogram execution is not equal to the sum of the durations of the instructions of this subprogram. We had to write our own tools for testing and optimizing code on real hardware.







It ended up that my son was studying the BK 0011 circuitry (which signal edges are coming to when RPLY is triggered, etc. - I don’t understand anything about this anymore). So he came up with the idea of ​​creating his own emulator BK, compatible with real hardware accurate to the beat, and even wrote the kernel ... However, this is another story.



In total, in a month - from studying assembler to creating your own development tools, from hard tests to the finished multimedia work. All this would be impossible without the main thing: Planning. Perhaps the most valuable lesson learned. You take an impossible task. You understand that you will encounter insurmountable difficulties. Are planning You do. The result amazes everyone so much that even experts are accused of cheating (“you overclocked the processor!”).

Why not the ZX Spectrum?

Again, I’ll start with a strange one: finance. Judging by the ads on Avito, on average the BC 0010 costs several times more than the ZX Spectrum. It is clear that for a rare instance of the native Spectrum in perfect condition they will ask for a round sum. But the BC 0011m fully loaded will still come out more expensive. If at all able to find. Prices speak for themselves: the collection value of BC 0010 is higher. And BK 0011m - and even more so. To have such a computer at home is very nice.



The second argument is 16-bit. There is nothing 8-bit in BC 0010. The processor does not even know how to add 8-bit numbers; it does not have an ADDB command. 16-bit in everything. The reason for this is the DEC PDP-11 architecture. Many call the PDP-11 processor command system the most successful and most convenient ever created. Of course, there are those who want to argue with this statement. But here is one fact: at the Yandex Demodulation Festival, three seminars were devoted to processor architectures, and two of them were about PDP-11. This, indeed, is a legend, a milestone in the history of computer technology, which still continues to excite the minds of enthusiasts. BK 0010 makes it possible to touch this legend. And not just to touch, but to understand it to the smallest detail, to feel all the beauty and grace of the DEC assembler: absolutely equal registers, eight addressing methods, linear memory - beauty!



The third argument: many demos have been written for the ZX Spectrum. For BC 0010 - less than fifty , counting small 256-byte and 4-kilobyte ones. The place on the demoscene is almost free, there is where even a beginner can show himself!



And the last consideration, purely subjective. I have been watching the Russian demoscene since 1994. Party spektrumistov seems to me, unfortunately, more toxic and hostile. Of course, there are wonderful friendly people! I have great respect for them and their work. But in general - probably because of its mass character - the Spectrum scene was filled with conflicts, clarification of relations and even intrigues such as name-voting (when they vote only for “their own” at contests). While on the small BK-shnoy stage they do not pose questions like “who is cooler” and are glad to every new participant. I repeat: this is my purely personal impression, which you can ignore.

Real iron

20 years passed before I returned to writing programs for BC. Over the 20 years, much has changed. For me personally, a major shift occurred in the mind: “Think Different”. This slogan is placed in the final credits of our demo “Good Apple”.



We used to load games from a tape recorder for 5 minutes. Then came the drive controllers. Behind them are the hard drives. Then newfound replicas of controllers with Compact Flash on board. Now it’s customary to emulate flash drives on the retro scene ... But wait, in 2019 we have a high-quality portable sound source - iPhone. So let's take a standard DIN-5 audio cord - a mini jack (you won’t even have to re-solder) and load the BK from the iPhone at high speed.



I went through the ROM trace, revealed how I could slightly outsmart the boot algorithm from the tape recorder and make the BC read data 4 times faster.



The next step was to write a micro-bootloader that read data in a specially designed turbo format . Both the loader and the data were placed one after another in a single WAV file (the converter was written by Lenar Zakirov ). BK 0010 reads and automatically starts the microloader, which, in turn, reads the rest of the data from the file. Frequencies in turbo format reach 22 KHz, so the requirements for the quality of the sound source are high. iPhone is coping. A good music player all the more. Computer sound card too.



Then it was the turn of the cross assembler . It added options for saving the program in WAV (both in standard and in turbo format). Moreover, cross-assembler can immediately play WAV through a sound card. Just imagine how accelerated the development! No need to bother with writing a disk image to a CF card after each compilation. Just make changes to the code, click “Build”, the sound flows into the BC and after a few seconds the program is already running on real hardware. To receive sound in a standard format, simply press the L (Load) and Enter keys (load the first program encountered) on the BC 0011. To transmit sound in turbo format, you must first run the micro-bootloader (for me it automatically starts from the hard drive when the BC is turned on; at any time you can log into the system by pressing the STOP key).







It is easiest to connect the BK to the TV in monochrome mode, in the usual composite AV input. It is necessary to solder the cable with a “tulip” at one end and DIN-5 at the other. A monochrome signal comes from the 4th pin of DIN-5 of the BK connector, designated “TV”. The ground is traditionally associated with the 2nd pin of DIN-5.



Personally, I am a fan of monochrome CRT displays - they provide image clarity unattainable on color monitors with their aperture grille. But most games and all demos are preferable to watch in color. To do this, use the “TVC” BK output and connect to the TV via RGB SCART. Contacts 3, 4, 5 on DIN-5 - respectively red, blue, green. Pin 1 - Sync. Pin 2 is ground. When connected to an LCD TV, it’s useful to apply +5 volts to the 16th pin of the SCART (via a 200 ohm resistor or so). 5 volts are usually taken from the adjacent “TV” connector (pin 1).



You can use a SCART-HDMI converter. I’ll immediately warn you that BC displays an image with a frequency of not 48 frames per second, but 48.83, so instead of smooth scrolling on the LCD monitors, a periodic twitch will be noticeable. I solved this problem by replacing the 12 megahertz quartz crystal resonator at 12.288 MHz. However, twitching was noticeable only in some demos. Most BC programs do not use frame rate synchronization.



Why not be content with the emulator, for which a real computer may be needed at all? I found four things that are poorly emulated:

1. Behavior of the speaker at high frequencies.
2. Synchronization of the image and palettes with the beam.
3. Exact time of execution of commands (important for music through Covox).
4. Work with IDE hard drives at high speeds.

If you do not plan to do any of the above, the emulator is enough for you.

Emulation

On MacOS, I use the BK2010 emulator. It is not very accurate, but suitable for most tasks.



The most advanced GID emulator to date runs on Windows. It also runs on CrossOver for MacOS and Wine for Linux. The emulator has a good debugger, a memory page viewer and the like.



To write disk images to Compact Flash I use the multi-platform utility Etcher . But more often I transmit data through the audio channel.

Development tools

The guys from the Excess Team demo group prompted the cross-assembler Alexei Morozov. At first we used it, but soon Ivanq wrote his own - multi-platform, in Python. It works slower, but much richer in functionality. This includes support for multi-file projects, and complex arithmetic expressions, double word data types, integration with Sublime Text and extended support for compilation errors, saving the result in a sound file format, compilation not only for BC, but also for UKSC, and much more. You can read about all this in the official documentation.



Cross assembler is called PDPy11 .



Some veterans complain that PDPy11 lacks macros from the classic DEC macro assembler (Macro-11). Macro assembler is, in a sense, a different language. It is probably good for writing system programs, but serious games and demos for BC were written, as far as I know, in ordinary classical assembler. Ironically: for the source code of BK programs, it is customary to use the .mac file extension (from “macro”) even in those assemblers that do not support macros. In any case, the capabilities of PDPy11 are enough to write programs of any complexity.



The debugger is built into the GID emulator. It allows you to set the addresses of breakpoints, interrupt or continue program execution at any time, look at the contents of registers and memory, execute the program step by step, change the contents of memory, etc.



To convert graphics to BC format, we wrote an online converter . Resolution BK - 256x256 pixels in color mode or 512x256 in monochrome. Larger pictures are best not to be input to the converter.

Documentation

An excellent tutorial on assembly language programming was written by Yuri Zaltsman. The differences between BC 0011m and BC 0010 are written here . There was also the BK 0011 model (without the “m”), but it was quickly taken out of production, recognizing it as unsuccessful.



Despite the fact that the BC 0011m has great capabilities (color palettes, additional memory pages), at first I advise you to program for the BC 0010 - this model is simpler and more understandable. Any program correctly written for BC 0010 will also run on BC 0011m.



The processor device and instruction set are well described on Wikipedia .



For the most courageous - programming in codes .

Hello world!

The area of ​​screen memory in BC 0010 begins with the address 40000 (upper left corner) and ends with address 77777 (lower right corner of the screen). As you might guess, the PDP-11 architecture uses an 8-decimal number system. But the PDPy11 cross-assembler, of course, allows you to write numbers also in binary, decimal, and hexadecimal systems - do as you like.



To put a dot on the screen , you need to write some number in the area of ​​screen memory. Arguments in the DEC assembler are written from left to right: source, then receiver. For example:

MOV #100000,@#60040 ;     
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

The # sign means that the argument is just a number (not an address). The @ # sign means that the argument is an absolute address (that is, it will not change when the program is moved to another memory location).

Screen cleaning looks like this:

    MOV #40000,R1 ;     MOV #20000,R0 ;   1: CLR (R1)+ ;    ,   R1   SOB R0,1 ;  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Indirect addressing (R1) uses the R1 register as an address pointer. The memory in the BC is addressed byte by byte, but the CLR instruction clears immediately two adjacent bytes: first 40000 and 40001, at the next step of the cycle 40002 and 40003, and so on. The notation (R1) + means that after using the argument you need to increase it. In this case, by 2, because the command processes 2 bytes. The loop counter can be any register. SOB subtracts a unit from the register and goes to label 1. Local labels are indicated by numbers and a colon, their scope between two global labels. Global labels must begin with a letter and also end with a colon.



The CLR instruction can be made to work with bytes by appending the letter “B”. Then CLRB (R1) + will increase the register R1 not by 2, but by 1.

    MOV #40000,R1   MOV R1,R0 ;        1: CLRB (R1)+   SOB R0,1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

You can do the same thing shorter. We clear the screen from bottom to top using the indexing addressing method:

    MOV #40000,R0 1: CLRB 37777(R0) ;    (37777+R0)   SOB R0,1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

If high speed is needed, then it is better to clear the memory not by bytes, but immediately with words. It will be twice as fast. But you can accelerate more than that: for some reason, the CLR command is slower than MOV. Therefore:

    CLR R2 ;     R2   MOV #40000,R1 ;     MOV #20000,R0 ;   1: MOV R2,(R1)+ ;    ,   R1   SOB R0,1 ;  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Now, choosing one of the four ways to clear the screen, you can already set points. In color mode, each point corresponds to two bits. In monochrome, one bit. BC does not have a program switch of screen modes. To which output the monitor was connected, I received such an image.

For clarity, we write the colors of the dots in the binary number system:

    MOVB #0b00001100,@#50010   MOVB #0b00110000,@#50112   MOVB #0b11000000,@#50313
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

The colors in each pair of bits are encoded as follows: if only an even bit is set - a green dot, only an odd bit - blue, both bits are set - red, both bits are reset - black. Well, a monochrome monitor shows each bit as a separate point.

The MOVB command writes 4 points to the on-screen memory at once, and the MOV command writes 8 points. If you do not want to affect neighboring points, use the BIC (Bit Clear) and BIS (Bit Set) commands, for example:

    BICB #0b00001100,@#50112 ;     BISB #0b00000100,@#50112 ;   
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

An interesting point: in the text we write the least significant bits to the right of the most significant ones. And on the screen, on the contrary: points corresponding to the least significant bits appear to the left.

That, in fact, is all about the on-screen memory device BK 0010.



But what about text output ?

       MOV #Text,R1 ;         EMT 20 ;             HALT ;   Text: .ASCII “Hello, World!”      .BYTE 0 ;     
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Show the source!

It will be easiest to start by looking at the source code of the finished demos:



In Your Space - demo for Covox, sources in the archive.

Good Apple - sources on GitLab (a complex multi-file project).

EIS is an emulator of extended arithmetic instructions with source codes.

Sources of three 256-byte demos.

In the 28th issue of Downgrade magazine , a large article on the evolution of tracker music algorithms on BC 0010, with program fragments and detailed explanations. A nostalgic tale of an early demoscene to boot.

When to start?

Right now. After 4 weeks in Kazan will be held demopati CAFe 2019 . The festival program has a competition BK 0010 - 512 bytes . This size will fit from 85 to 256 instructions - ideal for beginners. Two weeks is enough for you to deal with the tools and write the first simple demo. After that, there will still be a week and a half to write a second, more serious work.



Go ahead, you can! Telegram chat , zx-pk forum - they will help you everywhere. send work to the contest, and better yet come yourself. Scene is alive !