2018-02-17 15:22 UTC
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.
2017-11-11 12:39 UTC
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.
2017-10-10 20:10 UTC
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 editorBefore 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
AssemblerThis 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 -t4000Without 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
2017-07-10 18:37 UTC
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!
2017-07-04 09:03 UTC
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.[show older articles]
Change Directory commandThis 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.2The 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)
CompilingThe 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.asmExample 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.asmCare 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