Awhile back, the Internet led me to a wondrous thing: an online 6809 emulator, complete with compiler, debugger, and text/graphical output!
This website, “designed and coded” by Gwilym Thomas, is amazing. If has a spot where you can enter 6809 assembly source code, then you can compile and run it!
It even has a few sample programs you can select and try out.
While it runs, you see the registers update, as well as a source-level debugger showing what op codes are currently executing. You can set break points, and memory watch points, too.
It also provides text output in the form of the MC6847 VDG chip (used by the CoCo, and a few other systems). The graphics mode is different VDG. While it supports some similar resolutions, it also adds a 16-color display.
The screen memory is mapped to $400 (1024) just like the CoCo, so you can run stuff like this:
start ldx #1024 loop inc ,x+ cmpx #1536 bne loop bra start
If you past that in to the Assembly language input window and then click Assemble source code, you will see the text characters in the Text screen preview window cycling through values. Neat!
The graphics screen starts just past the text screen at $600 (1536). I think that might be where it started on a non-Disk Extended Color BASIC system. (See my article about memory on the CoCo for more details.)
The documentation notes this about the modes:
The graphics screen is a memory-mapped display of 6144 bytes of RAM beginning at address $0600. There are 3 graphics colour modes, in which either 1, 2, or 4 bits represent a single pixel in 2, 4, or 16 colours respectively. Addresses increase left to right, top to bottom as for the text screen.
Columns and rows are zero-base with (0, 0) at the (left, top). Sequences of bits (1, 2, or 4) from high to low represent pixels from left to right. The 2 colour mode has 256 pixels by 192, the 4 colour 128 by 192, each line being 32 bytes. The 16 colour mode has 128 pixels by 96, each line being 64 bytes.
Example: in 4 colour (2 bit) mode pixel (93, 38) would be in byte $0600+(3832)+trunc (93/4), because there are 4 pixels in a byte. The colour value (0..3) would be stored in bits 5 & 4, ie. shifted left ((4-1)2)-((93 mod 4)*2 times).
http://6809.uk/doc/doku.php?id=interactive_6809_emulator
Changing screen modes is NOT done via simulated VDG registers. Instead, it has code that looks like this:
ldd #$0204 ; select 4 colour graphics mode
swi3
I have not been able to find details on what values represent what mode. Also, the documentation says there is keyboard input:
Click the text screen panel then start typing for the emulator to receive keyboard input. Remember that (due to limitations of the emulated hardware) when lower case characters are printed to the screen they will appear in inverse video.
http://6809.uk/doc/doku.php?id=interactive_6809_emulator
I have not figured out how this works, yet.
As far as the 6809 assembler goes, it does not parse all of the extensions that the LWTOOLS’ lwasm assembler supports, so I have been modifying my projects to be compatible with the emulator’s assembler. This has let me, with minor changes for things like ROM calls, test and debug my code in a way that is impossible on actual hardware.
Here is the documentation:
http://6809.uk/doc/doku.php?id=interactive_6809_emulator
If you create anything interesting in it, please let everyone know in the comments.
In an Internet full of so much garbage, it’s wonderful to find such a gem.
Until next time…
I am writing code for this very nice emulator, but found some boring bugs or missing features.
The FCB & FDB do not recognize labels. For example :
lab1 equ $25
lab2 fcb lab1
does not work, memory contains zero
There is no easy way apart modifying the X register to display memory content.
it has been awhile since I looked at that website – does it say what assembler the syntax was based on? Does FCB work itself? Maybe not supporting EQU?
None of the directives work with labels.
lab1 equ $25 works.
If I then write LDA #lab1, I have the 25
But if I write :
lab2 fcb lab1
nothing happens.
On EDTASM (using the JS Mocha HTML5 online emulator, find EDTASM under “Load Bin”) I tried this:
LAB1 EQU $25
LAB2 EQU LAB1
START LDA #LAB2
SWI
END
Running that and looking at registers shows A=25 (shows hex).
While using this to test a 6809 emulator I am writing, I think I might have found a bug. Or it could be my lack of understanding of the 6809. If I assemble this program:
LDA #$85
RORA
Running this program correctly results in the A accumulator being set to $C2. However, it sets the negative flag of the CC register to 0. My understanding is that if RORA produces a result greater than $80 then the negative flag should be set to 1. Can anyone confirm if this is true?
I do not know the answer to this, but you could pop over to the JS Mocha HTML5 online CoCo emulator, and mount the EDTASM cartridge (under “Load Bin”) and compare. It has the ZBUG debugger which will show register values, though I never used it for anything other than the “G”o command. However, I may have figured this out as I type this. Try this, there:
(use space between codes, or right arrow for tab)
*I (for Input)
00100 START LDA #$85
00110 (space) RORA
00120 (space) SWI (this is how you escape in EDTASM)
00130 (space) END
00140 (ESC key for break)
*A/IM/WE (assemble, in memory, wait for errors)
(compiler output)
*Z (enter ZBUG)
#G START (go to start)
8 BRK @ START+3
(it is now at the SWI)
#R (to show registers)
A=42 B=00 DP=00 CC=81 =EC
X=0000 Y=0000 U=0000 S=0777
PC=0835
I do not know the bits of the CC register. Is bit 7 or bit 1 (81=10000001?) the CC?
If A contains $85, RORA will give 42 (as Allen shows) not C2 !! So it is normal that the N flag (bit 3) is zero.
81 in CC means E (bit 7) entire ON, C (carry) bit 0 ON because bit 0 of $85 has been push into it by RORA.
About my EQU problem, it is not working in the
https://cosc204.cspages.otago.ac.nz/online6809/
emulator.
I am ashamed to admit that when I got my EDTASM assembly cartridge for my Color Computer back around 84 or 85, I skipped many chapters of the William Barden assembly book because they made my head hurt. I am sure if someone looks at the assembly space invaders game I wrote, they’d have a field day with “why did you do it THAT way?” There are some things in it, like using the direct page, that came from others who were helping me out. So anything good, probably was from them ;)
I am sorry. In my example, if A contains $85 AND the carry flag is set, then RORA should rotate that carry flag into bit 7, thus producing a value of $C2. That’s where I got that value. I would think the negative flag should be set since the result is greater than $80, but it’s not being set.
Would doing an LDA #$80 or higher set CC as well?
Bit 7 of the CC is ‘entire’, bit 0 is carry
My problem of directives not working with labels is with
https://cosc204.cspages.otago.ac.nz/online6809/
Did I know about that one? I think the one I was playing with was a different site. I’ll have to check this out.
Allen,
Did you have a look ?
oh! Thanks for the reminder… no, not yet.