256 color demo mode
Here is an assembly file (with included comments) explaining a 256 color mode on the CoCo3 that may be suitable for games. It needs some more work to determine how fast one can animate with this method. Here is a *.dsk file with the assembled program. LOAD"A and then EXEC. The program shows the 256 color image, and the assembly file can also do a 240 color mode using a different palette that may be better for gaming.
Here are two images of the resulting palettes as displayed in Mathematica (where I attempted, unsuccessfully, to determine optimal palette values). The 240 color one is on the left, and the 256 color one is on the right.
New Hardware Docs
I made a major update to my CoCo Hardware Docs (1MB, PDF), adding many new items, and creating hyperlinks between sections for easier navigation. Let me know of errors or changes needed!
I recently got curious about doing high precision computation on a CoCo3. As a kid, I wanted to compute pi to millions of digits, and even bought Knuth’s Seminumerical Programming book early in High School to assist in this. Now, after a PhD in math and a lot more numerical programming experience, I returned to trying high precision computation on a CoCo. The first program I wrote computes Euler’s constant e to 287273 digits, and should take about a month to finish. It implements an old 1968 algorithm of Sale. The beauty of this is a CoCo3 only has 131072 bytes of RAM (and this includes space for the screen and for the program!), but this computation delivers over twice that many decimal digits of accuracy.
It requires a 128K (or higher) CoCo3. Here is a picture of it running after computing 117 digits.
The program works by setting GIME memory page $30 to $8000-$A000, and then copying itself and the screen to address $8000. Then it jumps there, and initalizes memory, including overwriting most of the program (all the initialization stuff) to maximize the number of bytes available for workspace. There is still plenty of room to squeeze out, but the resulting program while running only uses a few hundred bytes of space for the screen and itself, leaving the remainder of the 128K for the statespace.
After this I was curious about how many digits of a non-repeating number could be computed in a fixed amount of RAM. After some thought I realized that the Thue-Morse constant is (almost provably) the best candidate for such work. The Thue-Morse constant is known to be a transcendental number and has an easy method to compute digits. It appears in places as diverse as Mandelbrot set properties and length of chess games.
I implemented the Thue-Morse digit program using a similar framework as the E program, but this time instead of getting 287273 digits (which is between 10^5 and 10^6 digits), I was able to create a program on a 128K CoCo3 that will compute a truly astronomical 10^314013 digits! I doubt anyone has a CoCo program with anywhere near this level of accuracy for a transcendental number. The output is the binary expansion of the TM constant, but even if viewed as a decimal number, it is still (as far as I can tell) transcendental, and is certainly irrational.
Note that with some work the number of digits could be extended to at most 10^315653 using these techniques.
To get an idea how big 10^314013 is, there are around 10^80 particles in the entire universe. If each particle was replaced with a copy of the universe, this would yield 10^160 particles. Now if this new universe had each particle replaced with a copy of the new universe, we’d get 10^320 particles. Repeat this process about 10 more times, and you’d have 10^327680 particles, which is the size of number this program (theoretically) will compute.
Of course your CoCo would burn out first, the Sun would explode, and the universe would die its ultimate heat death long before it finished.
Here is a picture of the running program, which computes a page (256 digits) at a time of the Thue-Morse constant.
Here is the assembly code for the computation of E, and the computation of TM. Both can be improved, but I only wanted to spend a day on them and move to other work. Here is a *.DSK image containing the programs E.BIN for computing E, and TM.BIN for the Thue-Morse constant (but is too fast to watch since it really moves!), and a slower TMSLOW.BIN to watch the digits move.
Perhaps someday I’ll return to computing Pi :)
Hitachi 6309 Chips for sale $20 each
I have recently obtained a bin of HD63C09EP chips from China. These are perfect replacement chips for the CoCo3 and for various arcade game repair. I selected one at random from the lot, and replaced a 68B09 in a Color Computer 3, booted it (and had to fix a missed address line I mis-soldered), and tested the chip for 6309 instructions. It worked!
These are the ‘C’ revision, which is the highest rated version (> 3MHZ operation). The only place I have found them for sale in the US is from Cloud9Tech, for $31+s/h US each, but they sell a "63x09" where x may be A, B, or C. Mine are the C revision.
I am selling them for $20 US each, and basic shipping (USPS) in the US will be $8. Any other deals must be negotiated. Email me 6309Sale at this domain (lomont.org) for purchasing.
I have a fairly limited quantity (and am keeping a few for my own nefarious purposes) so order today!
Here is a pic of one of the tubes. Click for a high res version.
A C/C++ Coco 6309 compiler? Part II
I updated my 6309⁄6809 assembler/disassembler, adding the assembler part. I also added the ability to make random instructions for testing the assembler/disassembler.
Also updated below is the programming documents, correcting some more errors.
A C/C++ Coco 6309 compiler? Part I
In my spare brain cycles (of which I have very few) I have been thinking about my Lemmings Port to the Coco. The amount of assembly needed would be a pain, especially for simple things that could be C/C++. So I looked around at the C/C++ options for the Coco, and was left wanting. No simple, cheap 6309 compiler, and most of the 6809 C compilers were still weak. Plus (having recently written around 40,000+ lines of C) I think C sucks compared to C++ for developing decent sized projects. So I want some features of C++ for any serious Coco development.
I also require a C compiler for other projects (my Hypnocube, for example). The supplied ones are generally crappy. Plus C is lacking in a lot of C++ niceties.
Not wanting to implement a full blown C++ compiler, I am increasingly of the opinion I should write a C compiler with many C++ features. To keep the runtime minimal and overhead small, I would NOT implement many complex and costly C++ features. Here are my current thoughts:
- Create a recursive descent parser (don’t need all the hassle of LALR(1) when LL(1) suffices).
- Add type bool.
- Add function overloading.
- Allow writing interrupts.
- Allow struct instead of requiring typedef struct.
- Operator overloading? Would allow adding types easily.
- // C++ style comments!
- Inline assembly for certain! (Nicer than GCC syntax!).
- Automatically make "naked" functions whenever possible.
- Caller cleans stack whenever possible.
- Drop float and double (for now).
- 8 bit char and short, 16 bit int (I know, not really C style to make int larger than optimal), 32 bit long.
- Force complete function prototypes for optimization reasons.
- Single pass from C files to binary to maximize branch sizing.
- PC compilation only (I am writing the compiler in C++).
- No library for now, in order to target a pure relocatable binary, only needing stack space to run.
- Local variables throughout scope.
- Need ability to also assemble asm files.
- Standard object and linker model?
- Local variables to for statements: for (int a = …)
- 6309 mode initially, perhaps a 6809 backend if I get inspired and have time.
- Implement modern code optimization techniques since we have the power.
- More to come as I organize notes.
I figure a basic C compiler would take a few weeks of straight programming time, which I don’t have right now, and which would be spread over many weeks at any rate. But it’s brewing.
In preparation for this, I wrote a nice 6309⁄6809 disassembler over a few days, with internals ready to add my (optimizing) assembler. The optimizing assembler will be part of my compiler suite. Here is the (dis)assembler for now (115K zip file). It was written in Visual Studio 2005, and is about 2500 lines of C++ code. Here are the features from the help:
In the process of testing my disassembler against CASM and CCASM (two common assemblers) I discovered errors and weirdness. FOr example, CASM incorrectly creates the same opcodes for LDQ and STQ, and CCASM uses multiple opcodes for the single TransFer Memory opcode TFM. This makes it a pain to test all the opcodes, since code does not cross-compile between them. I also discovered some mistakes in my assembly documents (PDF of the 6809⁄6309 Lomont_6809.pdf reference, and 4 up Lomont_6809_4.pdf version), which I have corrected and enhanced.
I also reread the (new version of) the Dragon book in my spare time on a recent cruise. This also was the time I used to make the disassembler and an Ataxx clone for the PC (coming soon to this website).
Also, I recently purchased a TI-55 off eBay, so I have a new one :)
Return of the TRS-80 Color Computer!!!
As a 6th grader in 1980 I got my first computer, a TRS-80 Color Computer, for $400. Before that the only programmable thing I owned was a TI-55 calculator (pictured below), so I already knew I loved programming. The Color Computer (CoCo) had 4K of RAM, a 0.8MHZ 8-bit CPU, good sound and graphics (for the time), and was based on the powerful Motorola 6809 CPU. For a good history, read the Wikipedia article.
For the next ten years as a kid, teen, and college student, I worked every job I could to buy computer hardware, software, and books. I mowed lawns, worked as a bag-boy, loaded ammo for my dad, sold books door-to-door, worked as a grease-tester and egg maintenance man, and tried everything I could to save for more items.
Around 1986 Tandy released the Color Computer 3, which also was quite powerful for it’s time: up to 512K of RAM (since expanded to 8MB and beyond), very nice graphics (through the custom and fabled GIME chip). Here is a picture:
I wrote many assembly programs, starting around 7th grade. I bought EDTASM (the cartridge version). I taught myself enough trigonometry to make 3D spinning shapes (I eventually got a PhD in math, so my early sloppy training was corrected). I taught myself data structures, and created an animation editor for the super-best-wonderful game that I never really did get finished. I think the game involved running over pedestrians and was going to be named Pizza-Man. Now Rockstar has made millions with their Grand Theft Auto games :)
I moved on to a PC around 1991, and shelved the CoCo and all the associated items, many of which were lost over the years.
In late July, 2006, I decided to return to the CoCo 3 and see what I can make it do with years programming experience I’ve gained since then. It turns out 0.8MHZ is a very slow CPU, especially since instructions back then were not pipelined, and require at least 2 cycles each, often more.
I set myself the task of creating a mandelbrot renderer, a simple task, but good for (re)learning the CoCo. For performance I decided to do it in assembly, which made it more difficult since the 6809 does not have floating point (or even a division instruction), so I also had to create fixed-point routines.
Fortunately, there is still a large CoCo community available, so I could track down hardware specs, an emulator, a development environment, and more. The best place to start is the site www.coco3.com.
Developing on the CoCo itself is much less friendly than using a PC-based environment, so the first thing I looked for was a way to do the work on a modern PC, using good tools, web information, and fast compilers. I found a CoCo IDE for the PC (Portal-9), and a CoCo (and many other systems) emulator M.E.S.S.
After a weekend of playing with the development environment Portal-9, the emulator M.E.S.S., and tracking down enough hardware specs, I created a simple fixed-point Mandelbrot renderer:
It is a 16-color, 320x200 pixel version, and operates reasonably fast. For an example of the speed increase, in college I wrote a mandelbrot renderer in BASIC, and if I recall, it took 10-20 hours for an image. This one takes about 10 minutes or so.
To test it, use the M.E.S.S. Emulator, and you’ll have to find the CoCo3 Disk Basic ROM (which I will not post here). Look through www.coco3.com to find this stuff. Run the CoCo3 emulator - it should look the the next image. Then download Lomont1.dsk (the disk image), and mount it under Devices, Floppy #0. Type LOADM"MAND1.BIN and press enter. Note the " mark on the emulator is really SHIFT-2, and that you don’t need the closing quote. Finally type EXEC, press enter, and watch it draw a mandelbrot.
Finally, here is the 750 line assembly sourcefile which can be compiled in Portal-9, or using CCASM or CASM, and here is a BIN-file of the program. Since this is my first 6809 assembly program in 20 years, it is not quite polished since I had to relearn a lot of opcodes (one annoying thing about CCASM - it compiles 6809 AND 6309 code, but there is no switch to force 6809 only. I ended up typing instructions such as "clrd" for Clear Register D, finding it compiled cleanly, and then hanging the emulator since it is a 6309 only opcode. CASM fixes this).
Next week I plan to soup it up, and add a lot more programming information. See below for results and CoCo3 programming information.
The TRS-80 CoCo3 Mandelbrot Renderer, Part II
Last time I created a simple mandelbrot renderer. This time I wanted to extend my understanding of the CoCo3 internals and improve on the single screen renderer. In particular, I wanted to add:
- An interactive select box used to zoom in
- Faster rendering
- as many other options (see bottom of page) as I had time to add
First off, I made the overall usage faster by rendering big blocks and then subdividing. Here is a picture generated after a few seconds. Notice the smaller pixels being filled in. This allows a fast preview, selecting a zoom, and starting anew. Pressing any key brings up the selection box.
The box is moved with the arrow keys, and SHIFT-arrow sizes it. Press ENTER to select, or ESC to continue the rendering. The fixed-point format is 8.24, so it supports quite deep zooming before numerical precision fails.
I also implemented an instruction cycle count profiler using the internal timer and fast interrupt, but did not use it to remove hot spots from code. That will be another day. Plus I figured out a much nicer way to implement a profiler which I will do before profiling code.
Using the M.E.S.S. Debugger
For developing this, I needed better tools than I had the first weekend. The first thing I found was that there was no integrated debugger, which makes development a real pain. I read you can compile M.E.S.S. with an integrated debugger, which after much searching and hassle I finally did. Here (15MB zipfile) is my development M.E.S.S. directory with the debugger-enabled version, which you will want for any serious work. The debug versions are messguid.exe and messd.exe.
Here is a picture of the debugger and a memory view. Click the picture for a larger version.
When you run M.E.S.S., it comes up with the debugger started. Press F12 to run the CoCo.
Some useful keystrokes:
~ (tilde) - stop a running program and enter the debugger,
F5-Run - run a stopped program, with debugger still open,
F10 - Step over a line of code (does not follow subroutine branches)
F11 - Step into a line (does follow subroutine branches)
Shift+F11 - step out of the current routine,
F12 - run and hide debugger,
Ctrl+M - open a new memory window, and
Ctrl+D - open a new disassembly window.
To get some some help in the debugger, type help in the console window.
To set a breakpoint enter "bp e00" (without quotes), where e00 is a hex address. To list breakpoints enter "bplist", which lists addresses and breakpoint numbers. To clear a breakpoint type "bpclear #" where # is the number from bplist. See the above image for an example.
Another useful M.E.S.S. feature is the "Save snapshot" under the file menu. When I expect I will have to step through a particular code release several times, I load the disk and binary file to the emulator, and save a snapshot. Then to rerun it I just load the snapshot.
Now I had a useable debugger.
Some CoCo Hardware References
Another thing I needed was a good reference for the 6809 opcodes with cycle counts. I could not find one document with everything I wanted, so I merged many documents into a brief yet very complete 6309⁄6809 reference. Here is a PDF of the 6809⁄6309 (Lomont_6809.pdf) reference, and here is a (Lomont_6809_4.pdf) (prints well double sided, giving a one sheet reference).
I also created comprehensive CoCo 1/2/3 hardware documentation, edited and merged into a single nice development resource. Here is a PDF file (Lomont_CoCo_Hardware.pdf), and here is a 2-UP version (Lomont_CoCo_Hardware_2.pdf).
From my earlier days I still have many, many magazines and CoCo assembly books, which I also raided for information.
Click these pictures for larger versions:
The source files are somewhat commented, but they need a lot of cleaning up. I wrote this over a week of spare evenings, and I haven’t made it publishing quality. It has grown from one file and 750 lines to many files and 2400 lines. Since there is such a shortage of easy to get and read CoCo 3 code on the web I decided to release all the code to help others that get the CoCo 3 bug. Here are the source files, and their contents:
Main.asm - initialization, main loop, some utility functions (memcpy, memset)
FixedPoint.asm - fixed point math routines
Graphics.asm - initializes 320x200x16 graphics mode, sets video pages, set/get pixel, more,
Interface.asm - handles the interface selection, drawing and repainting, getting commands,
Keyboard.asm - low level keyboard reading routines - gets keys from hardware,
Mandelbrot.asm - does mandelbrot point computation, handles scaling for zooms, etc.,
Profiler.asm - an instruction profiler using the timer and fast interrupt to profile code. Mostly works, but not used much yet.
To compile this, place them all in a directory, and use CCASM on Main.asm, which includes the rest of the files. M.E.S.S. has a tool (imgtool) to make disk files for the emulator, and you can load the binary to the disk. It would be nice to have an assembler that independently assembles files, and links them together. Perhaps CASM does this? There would be long/short branching issues, but this could be resolved.
Note: the code does not call any existing ROM routines. All needed functionality is directly in the code, making it easier to see how to use the CoCo hardware.
Here is a nice header I plan to use throughout the code under the next rewrite: ASMDefs.txt.
Finally, this program is untested on real CoCo 3. If someone out there runs it on real hardware, please tell me. Perhaps on my next pass I’ll build a transfer cable, test my old hard drives, and get everything connected to test it.
If I get back to this project, I will add the following features:
- More colors than 16 using palette and screen swapping tricks (I worked out some nice methods, giving arbitrary >= 256 colors per pixel. There are others that have done similar - Gault and Sockmaster - but it seems theirs requires a lot of processing time. Mine works as fast as you can set pixels, and would look great on this program).
- Timer to show elapsed time
- Save images to disk
- Exit back to BASIC
- Arbitrary iteration count - most of this code is in - only need a keyboard interface
- Location of mandelbrot position
- Sound for finish notification and interface feedback
- Better and animated palettes
Many of these features are in the code, but not yet polished enough for release, so are disabled in the code above.
Finally, I might get inspired to port Lemmings to the CoCo 3. I have notes on getting it to work, and have started writing a C++ port to Windows to get the algorithms and graphics right. Lemmings PC-DOS is a 320x200x16 color program, with horizontal side scrolling - a perfect fit for the CoCo.
TODO - hook up webring?