This is the documentation for an improved version over v.0, which I called "Version 0.2". I meant it as a test version. For this version, I drew two different revisions (rev.3.16a and rev.3.17e). Rev.3.16a was drawn first, and while physically building it I stumbled into a few extra requirements which had to be wired in "loose". As a result, later on I also drew rev.3.17e, which includes these extras directly on the circuit board. While drawing rev.3.17e of the mainboard, I also revised a little bit the modifications module, the result being rev.0.4a of it. Functionally it is 100% unchanged, the only differences being some circuit tracks moved over for a more uniform distribution and the ICs renumbered from U01 to U07. Any of the two mainboard revisions will work absolutely the same with any of the two revisions of the modifications module board.
I will describe next a few features common to both revisions of v.0.2:
It can work with any version of the floppy disk interface (1.0 or 1.1). The memories used are DRAM 4164 (64K x 1 bit) chips, using one voltage, placed the same as in the original version (instead of 4116 chips having 16K x 1 bit), in 4 banks of 8 chips each. (The next step will be an identical mainboard, but using 41464 chips (64K x 8 bit). At this moment it's not designed, but I'll get to that too). The ROM memory consists of a 2-16 KB chip as BOOT EPROM and a 64KB chip as BASIC EPROM. The four 16 KB sections of BASIC EPROM can be manually selected by switches or by software through signals SO and TO. This mainboard allows changing the computer configuration by jumpers (when powered off). One of the following configurations can be chosen:
Basic configuration, with a total of 64 KB RAM addressable (4 banks DRAM of 16KB each).
The "64KB modified" configuration, where banks #0, #2 and #3 having 16KB each are replaced by a single 64 KB bank of which only 48 KB are addressed.
The "80KB modified" configuration, which includes the "64KB modification" plus the capability to fully address the 80 KB total RAM installed (in CP/M).
The "80 chars/line in CP/M" configuration, which includes the "80KB modification" plus it extends the displayable text area în CP/M by using parts of the border areas to the left and right. With this hardware modification and a modified CP/M operating system, using characters half as wide as the standard, 80 characters per text line in CP/M can be simultaneously displayed.
The "80 chars/line in CP/M" modification circuit, the NMI signal generator as well as an alternative version of interrupt generator are built on a separate small board which is connected to the mainboard through two connectors (J12 and J13) placed on the lower right side of the mainboard. Schematics for this module are found at page 15 in the mainboard schematics:
Mainboard - rev.3.16a
Schematics - v.0.2 (rev.3.16a)
256KB total RAM installed (max. 80K usable) in the form of 4 banks (#0, #1, #2, #3) of 8 chips each (4164, 64Kx1bit). Each bank has 64KB but is only used at 1/4 capacity (16KB), because 16Kx1bit RAM chips are quite impossible to find nowadays. Nevertheless if they are somehow available, they can be installed in banks #0, #1, #2 as long as they use one single voltage (5V) like for instance do the russian chips KP565РУ6. Bank #3 requires 4164 chips (64Kx1bit) in order to work with the 80K RAM modification. If only the 80K RAM configuration is used, banks #0 and #2 can be left completely uninstalled.
2-16KB BOOT ROM as one EPROM chip (2716-27128). Actually a 27256 can also be used (containing two different BOOT areas) or 27512 (containing four different BOOT areas) in which case selection of the BOOT area used can be made by JP22 and JP23 and selection of the EPROM type is done with JP7 and JP8.
64KB BASIC ROM as one EPROM chip (27512)
Selecting one of the 4 operating systems that can fit in BASIC ROM can be done by a routine in BOOT ROM through signals SO and TO on the mainboard (conditioned by JP3 and JP4). Also manual selection is possible by jumpers JP1 and JP2.
A reset button was added by which the computer can be brought in the startup configuration (COBRA RESET)
A NMI button was added to activate the NMI signal to CPU
A switch was added (JP9) which can change the access mode to bank #0 RAM (BASIC RAM area) from R/O to R/W
A connector was added (J11) to attach a separate module containing a PAL coder
Two connectors were added (J12 and J13) to attach a separate module containing the 80 char/line modification, the NMI circuit and extra versions of the interrupt signal to the CPU.
Board layout - v.0.2 (rev.3.16a)
The component layer (above) is drawn in red and the opposite layer in blue. The last two pages of this document show the outlines of the PAL coder board, floppy interface board (v.1.0 on the page before the last and v.1.1 on the last page) and modifications board, overlayed on the placement of the mainboard components. The associated Gerber files for this mainboard, can be downloaded as a ZIP archive.
Board layout for the modifications module (NMI + 80 characters/line) rev.0.4
This mainboard contains a total of 23 configuration jumpers. Most are used for choosing one of the 4 hardware configurations described at the beginning of this page. The rest provide other functions. A full setting description for all jumpers - together with the number of the page in the v.0.2 schematics showing each of the jumpers - is given below:
Building the mainboard
Next I will make a few comments regarding the actual assembly of the mainboard, illustrated with some snapshots saved with the TV tuner in my PC. I have used the TV Tuner with CoBra successfully, 20 years ago in Europe (PAL TV Tuner) as well as presently (NTSC TV Tuner). The TV standard of the Tuner is not relevant, as long as the composite video output (b/w or color) from CoBra is connected to the tuner through the video in connector (usually RCA), and the TV standard is set to PAL (in the TV software used, eg. I used tvtime). Images below are b/w because at the time I took the snapshot I didn't have a PAL coder assembled yet.
I began with the idea of using TTL integrated circuits in LS technology everywhere, in order to homogenize the construction "recipe" and minimize the power consumption, except for cases where a faster signal propagation is needed. Experimenting I noticed the following:
For the video memory (VRAM, bank #1) I used both 120 ns and 200 ns access time memories, In both cases the video memory worked correctly. For the DRAM memory (banks #0, #2, #3) I noticed while experimenting that only the chips with an access time of (minimum) 200 ns allow a correct operation. Also the chips must allow maintaining data at their outputs indefinitely when their CAS inputs are held at "0" (the majority of DRAM chips have this feature).
For a correct operation, the video memory (memory bank #1) required the use of 74ALS153 for U03, U20, U22, U39. When using 74LS153 I couldn't get it to operate correctly, the image being corrupted from the startup configuration.
Multiplexer U51 (74157) - also part of the video address multiplexer circuit, can be either 74LS157 or 74S157, operation is correct in both cases.
The type of multiplexers U41 and U58 (74157) in the DRAM memory circuit depends on the access time of memories used in banks #0, #2 and #3. Thus, for memories with a high access time (200 ns) I had to use 74S157, and for memories with a low access time (120 ns) I had to use 74LS157. Yet the 120 ns memories DID NOT WORK CORRECTLY even with 74LS157. Using LS ICs improved their behaviour considerably but did not allow a 100% correct operation. My conclusion is that the system memory requires DRAM memories with a high access time (at least 200 ns).
In order to minimize the (extra) propagation time through the 80K RAM modification circuit, I used 74AS00 for U18 and U42 and 74AS20 for U23. Also, in order to minimize the difference between propagation times of NCS0, NCS1, NCS2 and NCS3 I decided to use 74AS00 for U55 too. I have to say though I did not notice any difference between using AS and LS integrated circuits in these two cases, but since logically it seemed more correct, I used AS anyway.
Regarding the delay capacitors used, the only ones who really proved necessary were these:
CCC with a value of 560 pF (pag.1 - Memory access prioritizer and command logic),
C49 with a value of 330 pF (pag.3 - Configurator and selector circuit, the 80K RAM modification)
The absence of this capacitor causes behaviours (in Basic and Devil) the kind of those in the snapshots below:
A capacitor not prescribed by the schematics but whose necessity was experimentally determined, with a value of 150 pF, connected directly to pins 4 of dynamic memories (banks #0, #2 and #3) in order to add a delay to RAS (and as a side effect to CAS too) for the system memory. (pag.8 - "Dynamic memory circuit - pag.1/2"). Basically a capacitor to adjust the timing for RAS and/or CAS to memory in order to correctly access the dynamic memory (system memory). This capacitor was required when using MMN4164-3 chips for the system memory (manufactured at Microelectronica). I don't know for sure what is their access time, but the catalogue says it's between 200 and 300 ns. Afterwards I also did tests using TMS4164-20 DRAM memories for the system memory. Well, with these I did not have to use any kind of delay capacitors on RAS or CAS to the system memory. Hence I concluded that 200 ns access time memories are the ideal DRAM memories for CoBra. I will open a little bracket here in order to show the screenshot below, depicting what will be shown on the screen when access to the system memory is not properly tuned and loading Basic, Devil, Opus or anything like that is attempted using the "B" key from the startup configuration:
A 150 pF capacitor (also not prescribed by the schematics), connected to 3 of U36 (pag.3 - "Configurator and selector circuit"). This was required to delay the RFSH signal so that the falling edge of BNRFSH from the CPU would get to the clock input U36/3 (negated through U53/2) AFTER bit 7 of register R in the CPU became available and stable on the BA7 address line. To explain in more detail, I will quote what the CoBra hardware manual says: at power up, in the startup configuration, register R in the CPU has bit 7 set to 1. Then, when a key is pressed indicating the operating system chosen next, this bit is reset to 0 and appears on address line BA7 of the address bus during the first refresh cycle after the instruction who reset it. The moment is marked by the activation (transition to "0") of the RFSH signal generated by the CPU. This falling edge of BNRFSH is negated by U53/2 and transformed in rising edge for the clock input of flip-flop U36 (7474 uses rising clock edges). So the falling edge of BNRFSH should load flip-flop U36/5+6 with the data bit supplied on the address line BA7. The problem is that if we check the official documentation of Z80, we learn that (see the image below extracted from the manual, last half of the M1 cycle) the refresh addresses (BA0-BA7) are not guaranteed to be stable except during MREQ activation time. MREQ is activated half a CPU clock period after RFSH is activated, and RFSH is activated simultaneously with refresh addresses becoming available on the address bus.
In other words, the falling edge of RFSH occurs too early to sample the refresh address on the address bus because this address is only guaranteed to be stable half a CPU clock period later. The truth is, the CoBra schematics have inverter U53 inserted on BNRFSH before U36, and BA7 is takedn directly to U36, so BNRFSH already has some delay from BA7, which in the case of both mainboards assembled by me back in the 90's was sufficient to ensure a correct operation. But now, when I built this prototype, for some reason this delay was not sufficient anymore, and my practical problem was that when pressing the "D" key in the startup configuration in order to load CP/M from disk, the border would only flash once briefly to blue, come back to black and then the computer would freeze, not reading any more keys and the disk drive would not spin the disk to read it. That because signal LO6, instead of staying at "1" for the CP/M configuration, would go to "0", which was visualized with the logical probe. Fortunately, on the forum I met YO3GHM who had the patience and kindness to analyze my problem and came up with the delivering solution, a delay capacitor on U36/3 (experientia docet...). As soon as I applied it, the mainboard started loading the disk operating system correctly. The interesting fact is that in DEVIL (BASIC using floppy disk for CoBra) disk operations would take place perfectly, commands CAT and LOAD had no problems. That's because LO6 had no problems switching to "0" (for the BASIC/DEVIL hardware configuration) but only had problems staying at "1" (for the CP/M hardware configuration).
Problems encountered during actual assembly:
1. The problem of noise over long circuit tracks
After I finished assembling the prototype, while doing tests on it, I noticed on several occasions a symptom like the one in the screenshot below:
I had seen things like that before, years ago when I built the two CoBra mainboards, around 1990-92, but I never had a precise idea what the cause was. Now, after building this new version and seeing this kind of symptoms again, the problem became a real concern. The parasitic effect became really persistent and annoying after assembling the PAL coder too, with which the image was distorted this way especially with the whole screen white, after loading Basic.
What actually happened is that I was trying to adjust the access timing to the system memory using a capacitor of various values applied to RAS (pin 4 of the 4164 memories). Well, having the PAL coder attached to the mainboard, when attaching this capacitor to pins 4 of the memories, the completely white background in the startup Basic screen would start bouncing (loss of sync). The capacitor did not even have a big value, just 56 pF.
The really crazy part is this: I thought, let me check with the logic probe the input signals to the PAL coder, and see what the deal is. Well, surprize: as soon as I would touch signals HB or HS with the tip of the logic probe at their entry on the coder board, the display would come back to normal (with the capacitor applied to 4164/4). Any other input signal to the PAL coder, when touched with the logic probe, had no effect on the video output...
I squeezed my brains a lot but couldn't find any logical connection between BNMREQ (which is actually RAS to the system memory) and video synchronization on the screen, HS and HB (??!!??).
Without the PAL coder attached to CoBra, this nuissance did not manifest. The image stayed stable no matter what delay capacitors I would stick to RAS and no matter what the background color on the screen was, white, black, all the same.
Since no idea would cross my mind, I threw the question on the forum (RomanianHomeComputer) and some answers from YO3GHM and YO7HLQ gave me a suspicion about the phenomenon: parasitic perturbations captured by the circuit tracks carrying signals NVS, NHB and HS all the way to the video circuit and especially the tracks carrying HB and HS all the way to the PAL coder, especially considering that the contact with the logic probe had a beneficial effect. So I resorted to terminating the circuit tracks of HB and HS by attaching, directly on the PAL coder, some 750 ohm resistors between these two input signals and GND. I chose GND and not Vcc due to the nature of these two signals (HB si HS), which are "0" most of the time, with short pulses of "1". As a result the loss of video sync dissapeared. Problem solved!
As a little comment, the v.0.2 mainboard newly built by me includes an extra track for HB which is basically taken to the opposite corner of the board (over a great distance), to the PAL coder connector. This track goes through the middle of the memory block, which is a pretty "noisy" area. Aside from this, both in the original version (Version 0) and in the v.0.2 newly built, signals NHB and HS going to the video circuit also pass through the middle of the memory block. NVS does not go through there, but through the upper side, above 8255 and under the BOOT EPROM. So even in the case of an original CoBra mainboard (factory-made back then) this kind of perturbations can occur. And if it does, the solution is terminating the tracks carying the sync signals to the video circuit, using resistors to Vcc for NHB (U87/9) and NVS (U87/10) and a resistor to GND for HS (U88/13).
2. The problem of refreshing the dynamic memories
Another problem I encountered while experimenting with this mainboard version (v.0.2) came up when I tried to replace the MMN4164-3 chips in bank #3. (system memory) with TMS4164-20 memories (200 ns access time), of which I had ordered a bunch, to last me for about 10 computers.
Well, after installing TMS4164-20 chips in the sockets of bank #3, I noticed a strange phenomenon: after loading Basic and taking a 15-20 second break (no key pressed), any key press would cause a Basic reset or even a total system corruption. A similar phenomenon would happen in Devil, CP/M or Opus, where after a certain point a corruption would occur. If, instead, right after loading Basic I would continuously press keys entering commands like BORDER x, PAPER y etc. without breaks bigger than 5-10 secunde, all commands would execute correctly without any error and the system would not reset anymore or get corrupted.
I squeezed my brains quite a while trying to figure this out (a few weeks) with no success. I did a test replacing the video memory (where I had 120 ns NEC memories) with TMS4164-20 memories, and I noticed that these chips would work perfectly as video memory, without errors. So the memories themselves were not defective... Eventually, trying to think logically, I pondered the fact that if the MMN4164-3 memories worked correctly (even though they needed a 150 pF delay cap on RAS) and the TMS4164-20 memories did not (as system memory), then that means there must be a difference in the manufacturing processes of the two. So I started browsing the Microelectronica catalogue showing the datasheet for these memories, in parallel with the datasheet for the TMS4164 memories (manufactured by Texas Instruments). And so, in the 14th hour, I figured that the Texas Instruments memories require an 8 bit refresh address (256 refresh cycles) unlike the Microelectronica memories (and also unlike most of the 4164 memories made by other manufacturers) which are designed for 128 refresh cycles.
Once I realized what the trouble was, I started thinking how I could "generate" the 8th bit for the refresh address on-the-fly, so I can still use this memory stock I had already wasted a lot of money on. And I designed the circuit below, which I basically built "in the air" using wires and attached to the mainboard also with wires. I installed it and then powered up the mainboard, and this time the problem vanished completely. Everything was working perfectly, Basic, Devil, OPUS, CP/M, and the interesting part is no delay capacitors were required anymore for RAS or CAS to the system memory. These 200 ns memories fit CoBra like a glove! My conclusion is that for CoBra, the best dynamic memories are those with 200 ns access time. That at least for the combination of TTLs I used (LS everywhere, except the 4 video address multiplexers which are Schottky (S), the circuits U23 (74AS20), U18 and U42 (74AS00) in the 80K modification and the circuit U55 (74AS00) in the configurator and selector circuit).
Next, a few photos of the assembled mainboard:
A few comments are needed regarding these images:
Compared with the schematics and the board layout presented above, I had to make a few changes / improvements at the time of the actual assembly. They are visible in these images on the right side of the mainboard, in the free space between the two TTL blocks where, in the original 1986 mainboard version, the 2KB EPROM column used to be.
When assembling the mainboard, the 3-input diode AND gate in the 80KB RAM Modification did not behave correctly, so I decided at the last moment to replace it with a gate from a 7411. I put this 7411 in a socket, 6 leads of which I stuck in the mounting holes originally meant for the 3 diodes in the AND gate. The rest of the socket leads are bent sideways horizontally, being left completely above the circuit board, but in between the leads and the board I slipped some pieces of white paper, visible in these images, to make sure the leads stay fully separated electrically from the circuit board tracks.
I used a second gate of this 7411 for the 8-bit DRAM refresh circuit, since in my particular case I needed this, because the DRAM chips I got were made by Texas Instruments, and this manufacturer, at that time, made them with an 8-bit refresh. I was not aware of this until I physically put them on the board and I noticed they don't work correctly (see the comment a little further above). But here, the extra 7411 IC mentioned above came in handy, I used a second gate from it for the 8-bit DRAM refresh circuit. The other two ICs in this circuit (7474 and 74S157) are mounted in sockets too, but the sockets are turned upside down, as seen in these images, in order to wire everything up easier. That's pretty much the story with the wiry mess visible in the middle of the mainboard.
But these changes were only needed in my particular case. As far as I know, most of those who assembled this mainboard using the schematics above had no issues with the diode gate and neither used 8-bit refresh memories, so these changes are shown here only for reference. They are not part of the "official" rev.3.16a mainboard schematics.