Transceiver build - part 3
I know these updates are far apart but the project is slowly progressing. This update is about two of the main boards of the transceiver. I decided to make this transceiver a modular design where functions are separated into modules that can be tested and verified separately. This makes it possible for me to experiment with different designs and improve the construction piece by piece. Lets bring back the original block diagram of the transceiver. The shadowed areas are the ones I'm describing here. Mixer and amplifier board on the left and product detector and modulator board on the right.

Mixer and amplifier board

This board contains the double balanced mixer and four identical amplifier stages. Two stages for RX and two stages for TX so that for both RX and TX there are one amplifier of each side of the mixer. Which of the stages than are activated is controlled by their respective supply voltage. One supply for RX and one supply for TX. Also between every stage there is a diode switch, also controlled by the supply voltage. The board layout is more or less the same as the schematic so it should be relatively easy to follow. Input and output signals are connected using PCB edge SMA connectors. Top left connector is RF in/out, right is the IF in/out and bottom left is the mixer frequency input directly from the Adafruit Si5351 board. For simplicity I have left out the amplifier schematics in the schematic above. Contents of every amplifier block is seen below. It's the same as the amplifier that I designed in part one of this transceiver project. This amplifier could be substituted to some other 50 ohm amplifier such as an MMIC.

Product detector and modulator board

This board contains two more of the previous amplifier stages. One in each direction in the left side of the board. They too are switched in and out depending on the RX/TX supply voltage. The product detector in the top right quadrant of the board is unchanged from my initial design. It's working very good and has a very high dynamic range. Left SMA connector is the IF in/out and the bottom right SMA connector is the BFO input from the Adafruit Si5351 board. The latest addition to the transceiver is on this board. It's the DSB modulator in the lower right quadrant of the board. (Now my transceiver can finally transmit!) The DSB signal is passed through the crystal filter (between this board and the mixer board) to filter out either the upper or lover sideband depending on the placement of the BFO frequency in regards to the filter pass band. I decided to use an NE602 for the DSB modulator. It's a very common IC for this purpose. The MC1496 may be better performing but I wanted to give the NE602 a try. I mentioned earlier that I did not want to use the NE602 in the product detector because of it's limited dynamic range. That limitation still apply here but in this case it's okay, I want the SSB transmission to be processed with controlled dynamics anyway to give high output a readability on the receiving end. My use of the NE602 is however a bit different from most designs I've seen. The output side is simple. It's just a matching transformer to match the NE602 output with the 50 ohm input of the amplifier. The input is a bit unusual and requires some explanation. I've been disappointed with the NE602 as a DSB modulator in the past because of it's relatively bad carrier suppression. This design tries to mitigate this a bit. One big reason for carrier leakage is bad biasing within the NE602. When used as an RF mixing stage this is not very critical but when used as a DSB modulator this is a big problem. My idea to mitigate this is to add external biasing adjustment and feed the NE602 with balanced audio to keep everything as symmetric as possible. It is also VERY important not to drive the OSC input to hard (I use a 470k series resistor in this design). VR1 sets the bias balance by adjusting the DC levels of IN_A and IN_B of the NE602. DC levels should be equal on both inputs for minimum carrier output. Starting off by centering VR1 and then slowly adjusting to find the spot where the carrier is as low as possible. A multi-turn potentiometer really helps here. Two TL072 op-amps creates the balanced signal for the NE602. The modulation input can take a condenser microphone directly (just need a bias resistor) for a complete modulator. I need to add some kind of speech processor also but that's a future update. The inside is a bit bit messy right now but it works! Controller board has been re-designed and the headphone amplifier is just temporary. I will add another analog board to contain the audio processing and filtration along with a proper headphone/speaker amplifier. Next up is filtering. I need some suitable band pass filtering and RF power amplifier. Right now using just the IF amplifiers the output power peaks at around 1mW. Not much but enough to be picked up on a nearby receiver. One thing I also added was a regulated power supply with RX TX switching. I decided to use linear regulators since they are generally quieter and doesn't generate spurs. They are ineffective and will require cooling but to me it's an okay trade-off.
Amiga 600 video encoder upgrade
For those of you who, just as me, are bothered with the bad composite video output of the Amiga 600/1200 I may have found a very effective upgrade. For some time I have wondered why the output lately seemed to be getting significantly worse as years went by. At first I thought it was just never monitors that had bad analog video circuitry compared to older ones but recently I definitely noticed a significant degrading in video output on my machines. The big plague that is tormenting all of these machines are the leaking electrolytic capacitors. They have come to an age now where generally all of hem are affected and must be dealt with as soon as possible to no be destroyed from within! The replacement of capacitors are an absolute necessity but it's something I won't cover in this article. There are plenty of existing guides out there already. At first a thought that this whole capacitor situation was to blame for the picture degradation but after re-capping two PAL Amiga 600 machines without any obvious improvement in the video output, in fact the re-capping actually made things worse, I began to wonder what was really going on. Both machines eventually started having problem with the reg/green color phase and color flickering. A common problem when the color delay is acting up. Remember, PAL inverts the color phase on every other line and if that phase is unstable it will result in color flickering. This red/green flickering situation got me wondering about how the video encoder chip in the Amiga 600 actually worked. It uses the CXA1145 chip by Sony. The same chip is used in many other consumer equipment and video game consoles from around that time. The CXA1145 design relies on two specifically delicate external components. One delay line and one band pass filter. Those were my primary suspects. In the Amiga 600 design they are called Z221 and Z222. The datasheet is pretty vague regarding these components. It mentions that the BPF should be centered around 4.43MHz for PAL and 3.58 MHz for NTSC, the color carrier frequencies, and the delay line should be 180ns in both cases. This is a picture over the area covering the video encoder circuit of an Amiga 600. Commodore did not use the filter and delay line mentioned in the CXA1145 datasheet but instead some other ones (the rectangular shaped RF cans on the left side of the picture). Actually the delay line consists of three cans connected together in serial and the band pass filter is a single can. I have not managed to properly identify them nor source new ones and they are pretty tricky to de-solder so I would rather avoid that. On both the Amiga 600 I recently restored I had to clean the area around Z221 and Z222 thoroughly to get rid of the leaked-out and corrosive capacitor electrolyte. In the picture above the area has been cleaned and all electrolytic capacitors replaced. I suspect my thorough cleaning is part of what quickly worsened my video problems. My theory is that Z221 and Z222 cans are sensitive to various cleaning detergents. In my case I think my use of isopropyl alcohol in the area is to blame. I could clearly see the picture degrading after cleaning. The components Commodore used for Z221 and Z222 filter and delay line may not be aging gracefully and are not robust enough to survive a leaky capacitor and cleanup. In fact I suspect the leaking capacitor electrolyte itself may even deteriorate the Z221 and Z222. They have a typical RF can style construction with an open bottom against the PCB. Any fluids on the PCB will effectively move up into the can because of the capillary force. This got me thinking about a possible replacement for the Amiga 600/1200 analog video section. Preferably a solution that would fit inside the case and one that also had to be fully reversible. This turned out to be easier than I initially thought! The diagram above is taken from the CXA1145 datasheet and shows the example circuit suggested by Sony and is basically the same design used by Commodore in the Amiga 600/1200. The bandpass filter and delay line are marked with red. Sony made an updated video encoder chip named CXA1645 that is almost pin-compatible with the CXA1145 and it does not depend on external bandpass filter and delay line! Instead those pins are used to provide a real S-video output. This is the suggested CXA1645 circuit from the datasheet. Very similar to the CXA1145. I have color coded the main differences. Red - pins with new function compared to existing circuit Blue - new or altered components Green - S-video output The changes required compared to the original circuit is pretty small. What I did was to remove the old CXA1145, replace it with a new CXA1645 and piggy-back the new and changed components around it. Worth mentioning in this case is that the CXA1145 has an audio buffer between pins 8 and 9. Those pins have other functions on the CXA1645, thus the audio to the RF modulator is lost by doing this mod. To me that was no issue but if you really want to keep the RF modulator audio working you could probably just bridge pins 8 and 9 together on the back of the PCB in order to restore that function. DISCLAIMER: This is NOT a beginners modification. It requires proper equipment and good surface mounted soldering skills. Make sure you know what you are doing and if in any doubt, leave it to someone who have the proper skills and tools. These computers are not made any more and are only getting fewer and fewer. Do not take any chances. This is only a documentation of what I did. I can not be held responsible for any eventual damages you may cause by performing this modification yourself. Step one - Removal of the CXA1145. Step two - Isolate changed pins with kapton tape. Placement of tape marked in red. Step three - Solder the new CXA1645 on top. Step four - Add components. The 1% 16k resistor between pin 18 and ground sets the color signal amplitude. I only had 5% resistors so I used one 15k and one 1k i series and measured a few samples using a calibrated LCR mater until I got well within the 1% mark. Step five - Annoy cat with fine picture and colorful mouse pointer. This has been a very successful modification. The picture is really good now. Better than I can remember it ever was and this is only composite video. Next step is to explore the possibilities with the CXA1645 S-video output. This modification was performed on an Amiga 600 but should be more or less the same for Amiga 1200 as well.
Native assembler and line editor
To me, a big milestone when designing a computer is that very moment when the computer is capable of editing and compiling its very own source code. One might ague that a BASIC interpreter is a way to do this but I wanted to take this even further. This is a big event in my MC3 development. After completing the first really usable version of my file system MCFS2 I began working on two crucial accompanying applications, a line editor and an assembler. These two have now reached a level where they are actually usable.

Line editor

Before there were video terminals the only real teminal-like way of interacting with a computer was through a paper teleprinter, commonly known as a "teletype". Without a video terminal there is no way to move a cursor around. You can only enter commands one line at a time and the result will be printed line by line on a roll of paper. A line editor is a way to edit a text file using this environment. It's a bit like writing a BASIC program actually. Every line of the text file has a number and lines are altered by replacing the entire line. I'm not using a teleprinter but the principle is quite easy to implement and the neat thing is that it will work regardless of the terminal used since no special control codes are needed (unlike a modern editor like emacs or vim). My line editor is very simple. The editor can be started without arguments to create an empty file or with a file name argument to load a file into memory for editing. The editor have two modes. A command mode and a text entry mode. When started it enters the command mode indicated by a "::" prompt. Typing "help" and <enter> shows the available commands. Commands are not case sensitive and can be shortened by typing only its first letter. For example the command "s" is the same as "save". At any point, pressing ESC ($1b) will put the editor back in command mode ("::" prompt). /devel/ # edit myfile.asm :: help Insert <line number> Delete <line number> Print <starting line number> Save Help Numbers (on/off) Quit :: There are currently two ways of manipulating text. By inserting a line and by deleting a line. Below is an example of entering a few lines of text. For clarity, I have also typed in the line-ending key strokes. :: insert 0000 : This is a line of text <enter> 0001 : This is another line of text <enter> 0002 : Third line of text <ESC> :: The insert command can also be followed by a line number to insert a line number to insert lines at a specific place in the file. :: insert 2 0002 : Text squeezed in between existing lines <enter> 0003 : Another line <ESC> :: The print command will print the current file to screen. It's somewhat like the "list" command in BASIC. :: print 0000 : This is a line of text 0001 : This is another line of text 0002 : Text squeezed in between existing lines 0003 : Another line 0004 : Third line of text :: It will print a page of up to 20 lines at once and pressing <enter> will print another 20 line page of text. Pressing <ESC> will abort printout and return to command input. The print command can be followed by a line number to begin printing at a specific point of the file. The save command will prompt the user for a filename and save he file to the current directory. If the editor was used edit an existing file, the suggested filename will be the same as the opened file. Saving will always overwrites existing files so some care must be taken when naming files. The number command will turn line number display on and off. Also, line numbers are entered and displayed in HEX format. I may change that in the future. Download the MC3 line editor: - source - listing - s19


This really is a core piece of software in the MC3 project. I tried to make the code simple to follow rather than effective so it will not win any prizes for speed but it works really well. I wanted to make an assembler that I could use instead of the cross assembler on my PC. It had to be useful and reliable and I think I managed to achieve that. The assembler is made for 6301/6303 CPUs but can be used for the 6800 as well if only 6800 opcodes are used. This is the quick help that the assembler prints out if no arguments are given. /devel/ # asm 6301/6303 assembler v1.0 Daniel Tufvesson 2017 Syntax: asm [files] [-l] [-e] [-d] [-tXXXX] Options: -l Generate listing -e Hide errors -d Assemble directly to memory -tXXXX Move symbol table to address $XXXX (default $0100) /devel/ # The basic principle of operation of the assembler is that it sequentially assembles the files given on the command line in two passes. Only a small part of the source is kept in memory at once to make room for as much generated program code as possible. This results in a lot of small file system reads and slows down the process substantially but enables assembly of large source files that would not normally fit in memory, I think it's a reasonable compromise. The first pass identifies all labels and builds up the symbol table in memory. The second pass completes the final assembly. Source files must be defined before any options. Example:/devel/ # asm file1.asm file2.asm file3.asm -l -d -t4000 Without any options the assembler only builds up the symbol table and verifies the assembly. No program listing or machine code is generated. Good for verifying source code without using up unnecessary memory. Errors are reported and printed to the screen. To actually generate anything, an option must be given. See explanation of options below. Generate listing (option -l) This option prints out the program listing. It will show the filename, line number, assembly line and generated data. When the assembly is complete it will end with printing the symbol table. Assemble directly to memory (option -d) This option will tell the assembler to write the generated machine code and data directly to memory. Move symbol table (option -tXXXX) When assembling code to memory there is a risk that the symbol table will collide with the generated data. Therefore this option allows for moving the start of the symbol table to another place in memory rather than the default $0100. This is the only option that takes an argument. A four character 16 bit hexadecimal address must follow directly after the "-t". Hide errors (option -e) This option will hide all errors from the printout. They will however still show up in the error counter. As you see from the options, the assembler generates machine code directly to memory. Right now it was the easiest and yet most flexible method to implement. It leaves the program directly executable in memory directly after assembly for fast turn-around time when developing. In the future I will probably extend the functionality to generate S19 files directly. Right now the easiest way to save an executable program back to the file system is to assemble to memory and then save the generated memory range to file. This method also memory efficient since S19 data takes up a lot of space.

Assembler specifications

- Source file size limited only by the file system - Number of source files limited only by the command line length - Length of labels is limited only by memory space (longer labels consumes more memory) - Machine code generated and written directly to memory - Symbol tale can be moved to any unused memory area - Direct memory addressing can be controlled by the "<" character as in 6809 assembler I hope you find this interesting. I've never seen a native 6303/6301 assembler out there in the wild before. This is probably my most serious software project for the MC3 and I will keep improving it in the future. Download the MC3 native assembler: - source - listing - s19
Calixto Island Adventure
In my ever ongoing hunt for 6800 software I came across an old FLEX disk with this program on it that looked interesting. adventur.cmd An executable file and by the name it looked like some kind of adventure. It immediately caught my attention but it crashed when I tried running it on my MC3 computer. Still, I was curious about it. Using my cmd2bin converter I was able to extract one continuous chunk of binary data from the CMD file. adventur.bin - load address $0100-$32F1 A quick look with a hex editor revealed ASCII contents that definitely looked like a classic text based adventure game. Now this was getting exciting. Further digging and disassembly revealed a quite elaborate program that definitely was a game. A game called "Calixto Island Adventure" made by Mark Data Products in 1981. The text only version of the game was created by Ron Krebs. I believe that may be the one I'm having here. The 6809 and 8086/8088 source has been released to the public by Bob Withers and Steve O'Dea, creators of the CoCo and IBM/PC versions of the game, so I figured it would be okay to distribute this one as well. This is the first and only 6800 release of the game I've ever seen. Below is my disassembled version. I've translated the external FLEX labels. The program relies heavily on jump tables that I have not translated to proper labels so the code can not be re-located as it is right now but I did not need to do that. The code loads and begins at $0100 which is pretty standard for most 6800 programs. Digging into the code too much might also spoil the game play for me so I did not want to risk that! adventur_disasm.asm The use of the zero page made it clear why the code did not run on my MC3. The 6303 CPU I use have the first 32 bytes of zero page reserved by internal registers and the Calixto Island code had variables starting at $0000 and up. Relocating them 32 ($20) bytes up was the only thing needed to get the game running on my system! I'M IN PROFESSOR LAGARTO'S COMFORTABLE STUDY. VISIBLE ITEMS HERE ARE: A FLIGHT OF STAIRS. A ROLLTOP DESK. AN ORIENTAL RUG. AN ANTIQUE TABLE. WELCOME TO THE CALIXTO ISLAND ADVENTURE TELL ME WHAT TO DO ! The game it self is a classic VERB+NOUN text adventure. User give commands like "OPEN DOOR", "GO PASSAGE", "GET RUG" or "PRESS BUTTON". There is also the possibility to save the current progress to a FLEX file which is a really nice feature given the age of the program. The user can choose the file name of the saved game to load or save. It's also possible to change the save file name during the game. To save a game simply give the command "SAVE GAME". To stop playing say "QUIT". To see what items you are carrying use the command "TAKE INVENTORY". The file access is based on FLEX 2.0 routines so I have converted my MC3 version of the game to use my MCFS2 instead for file access. It was a good practice run for this type of conversion. adventure_mc3.asm Above is the MC3 version of Calixto Island Adventure. I have located the FLEX LOAD and SAVE routines and added new ones. This file should be a good start if you want to convert the game for your own system. Happy adventuring!
MCFS 2.0.2
Not long ago MCFS 2.0.1 was released and it's time for an upgrade. This is version 2.0.2 with fixes for the built-in "cd" command and separation of the source code into multiple files for easier read and conversion to other hardware.

Change Directory command

This command now behaves more like it's UNIX equivalent. It's now possible to enter paths with multiple directories like "cd games/adventure". Paths starting with "/" refers to an absolute path beginning from the root. It's also now possible to go up one directory by "cd .." as commonly available on other systems.

Source code for MCFS 2.0.2

The source is now a little more structured than the previous version and has been divided into four files. mcfs2.asm - main code mcfs2_rtc.asm - driver for the real-time clock mcfs2_storage.asm - driver for flash card storage mcfs2_ram.asm - variables in RAM format.asm - flash card format routine (use with caution)


The source files need to be combined in order to compile MCFS2. Either the assembler have the ability to read all files sequentially or they can simply be concatenated before compiling. Example 1 - all files at once # as1h mcfs2.asm mcfs2_rtc.asm mcfs2_storage.asm mcfs2_ram.asm # as1h format.asm mcfs2_storage.asm Example 2 - concatenation # cat mcfs2.asm mcfs2_rtc.asm mcfs2_storage.asm mcfs2_ram.asm > combined_mcfs2.asm # as1h combined_mcfs2.asm # cat format.asm mcfs2_storage.asm > combined_format.asm # as1h combined_format.asm Care must be taken to read the files in the right order. As a reference I have included my resulting S19-files. mcfs2.s19 format.s19
[show older articles]