Architecture and programming RCA Studio II
"Finally, we came to the instruction, we were all waiting for - SEX!"
/from the article about the microprocessor CDP1802 /
In the early 1970s in the US were very popular simple electronic games type Pong (in the USSR their analogues appeared on sale in 5-10 years). As a rule, such games did not have a microprocessor and memory in the modern understanding of these words, but were based on rigid logic. Accordingly, replacement cartridges did not make much sense, and where they were - were just a set of jumpers, including the desired game.
In 197? two consoles were almost simultaneously released: Fairchild Channel F and RCA Studio II . These were the first game consoles in the form of full-fledged computers - with a microprocessor and programs on replaceable cartridges. The RCA Studio II accessory, which will be discussed, is not so much a development of RCA , how many a specific person - Joseph A. Weisbecker (like the entire architecture of COSMAC).
System 00 , also known as COSMAC FRED (1971) was a prototype and was not produced serially.
The processor in it was implemented on the usual logic (in FRED2 -on two chips called CDP1801 R and U, which appeared in 1973). RAM was around 256 bytes - 4 kb, in addition to FRED2 was built-in tape recorder.
The first commercial implementation of the COSMAC architecture was the device COSMAC ELF . In 197? ELF was positioned as a computer for radio amateurs (in Popular Electronics magazine it was
series of articles were published) and was a small board with tumblers, indicators, microprocessor CDP1802 (the same 180? but already in one chip) and 256 bytes of RAM . For him, there were additional expansion cards that allowed to display graphics on the monitor (using the CDP1861 chip), an external keyboard and a tape recorder were connected. On the basis of ELF with the extensions appeared ELF II and VIP. The COSMAC ROM had a virtual machine called CHIP-? primed for primitive games (commands for outputting and moving software sprites, generating random numbers, etc.) There were other primitive computers and terminals based on this architecture.
All these devices were direct predecessors of RCA Studio II and have extremely close both hardware and software architecture.
RCA Studio II was released in 1977 and was then sold at a price of $ 150 ($ 600 for current money). As often happens, the first one on the market is not necessarily the most successful one. In 200? the magazine PC World recognized this prefix is the worst game console of all time (which, in principle, not far from the truth). Black and white image of the squares, the lack of joysticks (instead of them two fields of 10 buttons) and a dozen games - to put it mildly did not please customers.
In addition, all games (both built-in and sold on the cartridges) were written in the pseudo-code of the virtual machine ST2 (the same idea as with CHIP-8 in COSMAC'ah), because of what is very slow.
RCA managed to release about 64 thousand pieces of RCA Studio II, not counting the later clones (Toshiba Visicom, Conic M-120? etc.) With the advent of Atari VCS , in an instant the outdated RCA Studio II and Fairchild Channel F dropped out of the fight.
As a chip manufacturer, RCA chose its own product as the processor of the set-top box - the microprocessor. RCA CDP1802 , operating at a frequency of ???MHz and manufactured using CMOS technology.
Its predecessor was CDP1801 - a processor of two chips (fully compatible with 1802):
CDP1802 is known for its radiation-resistant version (silicon on sapphire), in which it was used, for example, on the interplanetary station Galileo , flying to Jupiter in the 1990's (there were 6 such processors), as well as in MAGSAT .
The processor has a rather tricky scheme of using registers. It has one 8-bit accumulator D and sixteen 16-bit registers - R0RF (R0-R15), each of which can become a command pointer, depending on the contents of the 4-bit register P (indicating one of the R's), the variable team SEP Rn. In other words, there is no single PC in the processor!
In addition, any of R0 R15 can become index (address). The choice is determined based on the value in the 4-bit register X (modified by the SEX Rn command), after which the selected R is considered index for some commands.
As the address register for DMA, R0 is always used. Inside the interrupts, the command counter is R1.
There is an 8-bit T register that is used to automatically store the X and P registers in it when an interrupt occurs. Interrupts are enabled by setting the Interrupt Enable flag via the RET or DIS commands.
4-bit registers I and N contain the current instruction executable by the processor.
There is a register of flags - DF. More precisely, one flag, because it is single-bit and contains only the carry flag.
In addition, the processor has a one-bit output port Q, the state of which is changed by the commands SEQ and REQ.
As in many processors of that generation, the stack in the usual sense is missing (there are neither PUSH, POP commands, nor the stack pointer) and, if necessary, is implemented by the available instructions.
There are no traditional instructions for calling subroutines either. The transition to the subroutine is carried out using the SEP Rn instruction, which, I recall, makes the indicated Rn register the command counter. To return, the same SEP instruction is used, but with the register that was the counter of the commands before the call. Or (in a more universal, but slower version) uses MARK and RET.
In addition to traditional conditional and unconditional conversions (by the way - all of them are absolute), there are several SKIP instructions which, if the condition is met, skip the next instruction (two bytes) for SKIP. Provided and unconditional SKIP.
The processor 1802 is often referred to as one of the first RISC processors. However, in the same context, we mention, say, 650? as well as some others. Certainly, the architecture is not quite ordinary and, from the point of view of programming, causes mixed feelings. On the one hand, there are already sixteen 16-bit registers. On the other hand, their contents can only be reduced and increased by one. For example, putting a constant in Rn looks like this:
ldi $ 01; const -> D 3 r3r3843. plo r6; D -> R???r3r3843. ldi $ 02; const -> D 3 r3r3843. phi r6; D -> R???r3r3843.
Therefore, the lion's share of the code is the movement of bytes back and forth.
From transitions by condition, there is, in practice, only a transition to zero (only the situation is considered when 0 is in the accumulator D) and the transfer flag. Typical cycles have the following form:
dec r7; R7-
glo r7; R7 -> D
adi 2; D = D + const
xri $ 07; compare using XOR. (D = const) -> D
All arithmetic and logical instructions work only with the battery D.
In addition to the one-bit port controlled by SEQ /REQ, there is another four-bit, controlled by the OUT /INP commands. Unfortunately, in RCA Studio II it is not used.
There is: 2 KB ROM (BIOS + five built-in games) 512 bytes of RAM (half allocated for video)
000-2FF ROM RCA System ROM: Virtual machine SP2
300-3FF ROM RCA System ROM: BIOS
400-7FF ROM Built-in games (only available if there is no cartridge)
400-7FF ROM The cartridge (when inserted) 1024b
800-8FF RAM can be used (256 bytes)
900-9FF RAM Screen (256 bytes)
A00-BFF ROM Cartridge (not normally)
C00-DFF --- Same as 800-9FF
E00-FFF ROM Cartridge (not normally)
It should be specially stipulated that for games and programs on cartridges only part of the BIOS is available - one that contains SP2 (unnecessary, by and large), images of digits from 0 to ? and a standard interrupt handler for video.
For graphics, the chip is used. RCA CDP1861 - the so-called "Pixie".
The standard RCA Studio II has only an antenna (RF) output, but the people are remakes it's in composite, so that the quality was better (I almost wrote "for better color rendering" :))
Technically, the video controller provides a maximum resolution of 64x128 with two colors (black and white). However, this requires 1024 bytes of video memory, and in Studio II the total amount of RAM is 512 bytes. Therefore, the resolution is 64x32 (which requires 256 bytes). Horizontal resolution (64) is fixed. In a single line of 64 pixels, 8 bytes are always displayed and this occurs for 14 clock cycles.
To display memory ($ 900- $ 9ff) on the screen, the BIOS interrupt handler is used. The interrupt is initiated by the video controller and occurs 60 times per second (NTSC). The BIOS handler performs all the necessary operations - the executable program can only change the video memory, in which each bit directly corresponds to a black or white point (from left to right, from top to bottom).
However, nothing prevents writing your handler. The simplest case is the resolution of 64x12? because it is natural for the video controller. For him in the handler, it's enough just to write the address of the video memory in R0 (where the data will be taken for display) and the bytes will start through the DMA themselves to be displayed on the screen, filling the frame. The situation is more complicated with vertical resolutions other than 128. There you have to enter delays and duplicate data, changing R0 (see description of cdp1861 and the BIOS source).
In principle, you can even make an alternating vertical resolution, do not output anything to a part of the screen, and also specify ROM as the video memory, not RAM (or partially ROM, and partly RAM). You can also implement vertical scrolling by changing the initial The address from which data begins to be output to the controller.
Note that at the INT output of the video controller, a unit appears two lines before the beam reaches the visible area. Therefore, the interrupt handler usually starts with a delay that allows you to start displaying the memory in time.
The video controller also has an EFX output, on which 0 appears for 4 lines before the appearance of the ray in the visible area and then during the last 4 lines of this region. The EFX output is connected to the EF1 processor and its status can be checked by the command B1 (BN1).
Typical expectation of the reverse stroke of the beam along the frame is realized as follows:
bn1 delay; wait for EFX in video chip
As mentioned above, there are no images of letters and signs in the ROM. However, there are still numbers (after all, in embedded games you need to somehow show the points and the player's number). However, even here we managed to save:
As you can see, the figures are stitched so that from the several adjacent ones the remaining ones are obtained.
Let's just say - there is a sound. But not more. The only one-bit output port of the CDP1802 is attached to the NE555 with the harness and then it's all connected to the built-in speaker. When the unit is fed to the RST NE555 input (with the SEQ processor command), it starts to squeak at a frequency of 625Hz. When zero (command REQ) - the singer stops. Actually that's all. However, there is still a capacitor because of which, at the beginning of the peep, the frequency within 0.4 seconds is smoothly reduced by half (that is, there is some additional squealing).
In the standard BIOS interrupt handler, in addition to the part responsible for the video, there is a piece that checks the contents of a specific memory location and, if there is not zero, includes a squeak and the beginningTo cyclically reduce the contents of the cell $ 08CD (when the zero is reached, the squeak is turned off). Thus, you can not bother with self-recording in the port, but simply set the duration of the squeak and it will occur in the background, without stopping the program:
ldi $ 8cd & $ ff
ldi 250; the duration of Squeak
The same thing can be done manually (by disabling the interrupts):
; turn off interrupts
sex r3; set X to R3
dis; return X to R? P to R? 0-IE, R3 = R3 + 1
db 53h; forces X = 5 P = 3 - which is no change
; include a squeak
; empty cycle
ldi 250; delay
; turn off the squeak
; we turn on the interruptions back to
sex r3; set X to R3
ret; return X to R? P to R? 1-IE, R3 = R3 + 1
db 53h; forces X = 5 P = 3 - which is no change
In the 1970s, it was written (mostly RCA itself) a little more than a dozen games and several other programs. Almost all of them were written not in assembler, but in pseudo-code - in the prefix ROM is a special interpreter-virtual machine ST2. It is difficult to say exactly what was motivated by such a decision. Most likely, the idea was to save memory - the games really get significantly smaller in volume. In general, the ears of ST2 grow from a similar VM called CHIP-8 , used in COSMAC'ah. Although the two VMs are incompatible between each other, in the 2000s the CHIP-8 interpreter for RCA Studio II was written. Given the extreme similarity of architectures, it is not surprising that, as the author of the interpreter writes, games with COSMAC'ov that did not require a lot of memory, without problems started on RCA Studio II.
Alas, VM on such architecture works very slowly, which leaves an indelible imprint on the games themselves. Later, in 201? Paul Robson wrote about a dozen games - already in assembler and distributed them with the source.
Initially, as witnesses claim, the development for RCA Studio II was carried out even without assembler - on COSMAC ELF and FRED2.
At present, there is no need to be so tormented. There is a decent emulator under Windows - Emma , with a good debugger (by the way, it emulates not only RCA Studio II, but all COSMAC'i).
As an assembler, I first tried to use cross-assembler a18 but, for a number of reasons, eventually stopped at asmx , to which there is also scripts in Python to generate a ready-made image of the cartridge (it has the extension .st2).
A brief introduction to assembler 1802 can be found in here . The simplest test.asm for RCA Studio II with an infinite loop would look like this:
.db 4.2; SYS $ 402
br start; some code
Pay attention to the instruction ".db ?2". This is the address of the first executable instruction, i.e. ".db> (start), <(start)".
Implementation of a simple cycle:
ldi 50; we load in the register D purely iterations
plo r6; put the contents of register D in the low byte of register r6
dec r6; r6 = r6 -1
glo r6; place the lower byte of register r6 in register D
bnz loop; go to the loop label if the register D is not zero
Using the SKIP instructions:
; q = 0 for $ FF00 iterations, and q = 1 for $ FF iterations
ghi r1; hi (r1) → D
lsz; skip the next 2 bytes if in D zero (ie go to seq)
req; 0 -> Q
skp; skip the next 1 byte in any case (ie go to inc r1)
seq; 1 -> Q
inc r1; r1 = r1 + 1
br loop; repeat
To practice in the pure assembler CDP180? it is convenient to use the online assembler-emulator asm80 . The extension of the generated source file must be .a18
To start the finished application on a real iron in nature there is a cartridge RCA Studio II 40th Anniversary Multicart . I did not have it, but tnt23 remade one of the existing cartridges with the game for EEPROM AT28C16 (2k x 8) chip installed in the panel.
So, to run on the piece of iron, I inserted the chip every time into the programmer, stitched it, rearranged it into a converted cartridge, included a prefix. And so every time.
INTRO «NO SHADERS»
In order to master the platform, I wrote 256 bytes intro (presented at
? Chaos Constructions'2018 in the contest ) Tiny intro ).
In difference, say, from Vectrex , where you can get a spectacular picture, even just drawing a curve or from Videopac , where ROM already has a set of images of little men, here we have a sad situation - an ordinary, familiar, raster graphics, but it's black and white and there is nowhere to go (64x32). In the ROM there is not something that pictures, but even characters. Sound - and that is limited to a squeak frequency of 625 Hz.
Thus - music was canceled, all sorts of plasma, lights and anything else that involves non-square contours. The text in any form was also canceled - there would not be enough room for the letters.
As a result, it was decided a) scroll b) something repeating c) with different speeds. It turned out this way:
As mentioned above, there is no hardware scrolling in the video controller. However, low resolution and black-and-white has not only drawbacks, but also pluses - less overwriting bytes.
Scrolling I made a line by shlc (shift to the left with a carry) - when executed in a loop it turns out that the leftmost bit from the next byte shifts to the left and does not disappear, but is placed in the carry flag (DF). Accordingly, the next shlc in the loop picks it up and puts it in the byte to the left. It turns out a simple scrolling of the entire line, which in the cycle scrolls eight (because it is convenient to take the patterns of clouds and houses by byte)
sep r3; return from subroutine
; BEGINNING OF SUBPROGRAMME
; set lines counter
ldi LINES; const -> D 3 r3r3843. plo r10; D -> Rn.0
; set bytes counter
ldi BYTES_PER_LINE; const -> D 3 r3r3843. plo r7; D -> Rn.0
; set carry to scroll
glo r12; Rn -> D
shr; get one bit to set carry
plo r12; D -> Rn.0 (save shifted byte)
ldx; Rx -> D
shlc; D = D 1 (carry -> DF)
stxd; D -> M (Rx), Rx -
dec r7; Rn-
glo r7; Rn -> D
dec r10; Rn-
glo r10; Rn -> D
bnz nextline; one line (8 bytes) scrolled, let's scroll next
Note that the entry point to the subroutine is on the scroll mark, and to return, it is not just sep r? but first br scrollret and already from there sep r3.
This is done in order to leave r14 (which is the command counter inside the subroutine) in the correct state, then the subroutine can be called again and again (using sep r14).
Of course, no variables are stored here for calls - all the variable registers are global.
The subroutine scroll is called in the general loop twice - every second time for the houses and every fourth time for the clouds (they will be scrolled the slowest). The common cycle is synchronized on the back stroke (road, houses, clouds - have time to draw, stars are static). In the case of the road, only one line is scrolled: the edges of the road are simply drawn with lines.
I, for the sake of interest, tried to scroll the entire screen - in the reverse course of the ray in time a little does not fit.
Houses are set by patterns:
. db% 00000000
. db% 11111111
. db% 10101010
. db% 11111111
. db% 10101010
. db% 11111111
. db% 00000000
. db% 00000000
. db% 00011111
. db% 01110101
. db% 01011111
. db% 01110101
. db% 00011111
. db% 00000000
and a tablet with a link to each:
In the cycle, this plate is successively moved.
Unlike homes, both clouds, for simplicity, represent one pattern that simply scrolls.
A number of bytes could be won by deducing clouds on the same principle as houses, as well as by program gaps between patterns (now it's just repeating zeros in the data).
The problem is, however, that part of the registers are used by the interrupt handler - R? R? R? R? R? R11 can not be changed. And storing variables in memory is a lot of extra bytes for their writing and reading (not to mention the tacts).
Ideally, you should probably do scrolling in the interrupt handler. However, for this I would have to write my handler instead of the standard one. This would be more correct (and, incidentally, could release a couple of R registers), but most likely, in the end, all together would not have climbed into 256 bytes.
As for the stars, they are static, but to draw several points looking randomly located, it was unexpectedly not so simple:
ldn r4; M[Rn]-> D
ani% 00000010; D AND const -> D
bdf skip; jump if carry
ldi 0; const -> D 3 r3r3843. skip:
stxd; D -> M (Rx), Rx -
glo r4; Rn -> D
adi 47; D + const -> D
plo r4; Rn -> D
glo r15; Rn -> D
Here in the cycle, data from the BIOS is taken from the BIOS, which is thinned and the extra bits are masked. The mask (for ani) and the step (for adi) are hand picked.
As for the sound, the impossibility of changing the frequency is simply simulated by the "hooters" of the car.
By the way - I believe that this intra is the first demoscene work for RCA Studio II :)
After Studio II, RCA released several copies of RCA Studio III . Differences in two things - a color appeared (the resolution did not change) and the sound became better (you can give out more than 255 different frequencies).
It is interesting that both machines are compatible with each other in both directions, including using the same intermediate code with the interpreter.
It is also known that there were plans for RCA Studio IV. There had to increase the resolution to 64x128 and even a new pseudocode interpreter was already written.
As for CDP180? this microprocessor continues to be produced - first it was made by Hughes, then Intersil (Renesas)
Those wishing to learn more about this peculiar branch of the history of the development of computer technology, I recommend that we google the words " .COSMAC" and "CDP1802 ".
Technical information on RCA Studio II
Scheme RCA Studio II
Description of the microprocessor CDP1802
Description of the video controller CDP1861
Other my work for retrocomputers
My story about RCA Studio 2 on Chaos Constructions
It may be interesting
I am overwhelmed by your post with such a nice topic. Usually I visit your blogs and get updated through the information you include but today’s blog would be the most appreciable. Well done!
Took me time to understand all of the comments, but I seriously enjoyed the write-up. It proved being really helpful to me and Im positive to all of the commenters right here! Its constantly nice when you can not only be informed, but also entertained! I am certain you had enjoyable writing this write-up.