The MC6801 was a single-chip microcomputer (that today would also be called a microcontroller) incorporating a 6802 CPU with 128 bytes of RAM, a 2 KB ROM, a 16-bit timer, 31 programmable parallel I/O lines, and a serial port. (The MC6803 was the same except without the ROM and with fewer different bus configurations.) It could also use the I/O lines as data and address buses to connect to standard M6800 peripherals. The 6801 would execute 6800 code, but it had ten additional instructions, and the execution time of key instructions was reduced. The two 8-bit accumulators could act as a single 16-bit accumulator for double precision addition, subtraction and multiplication.[77][78] It was initially designed for automotive use, with General Motors as the lead customer. The first application was a trip computer for the 1978 Cadillac Seville.[79] This 35,000 transistor chip was too expensive for wide-scale adoption in automobiles, so a reduced function MC6805 single-chip microcomputer was designed.
The MC6801 was one of the first microprocessors with a multiply instruction.[78]: 4–45
The Hitachi HD6303 (not to be confused with the Hitachi 6309) is a second-source reimplementation of the Motorola MC6803, with a few additional instructions, and a slightly faster implementation of the 8x8 multiply instruction. The Hitachi HD6303 is used in the first PDA, the 1984 Psion Organiser.[80][81] The Hitachi HD6303 was also used in the 1983 "Pocket Telex".[82]
Translating a 6800 design to use a 6502 would be an interesting academic exercise but it certainly sounds like a roundabout way to make a working project.
We are told the main part of the code (the interrupt routine) is 840 bytes, so probably around 400 instructions.
The hardest thing is that the 6800 has two accumulators while the 6502 only has one. However in 6800 programs the B accumulator is often used for little more than increment, decrement, compare all of which can be handled by the 6502's extra "index" register. The 6800 data8,X addressing mode can be handled by using a zero-page pair XX to represent the 6800 X register and then "LDY #data8; FOO (XX),Y". That seems like more code, but 6800 programs often do a *lot* of loading different pointers into X in turn (and maybe incrementing and storing them), while on 6502 you can just use the pointers right from their home in ZP, so the code is often smaller (and faster).
It's probably no more than a day's work to convert an 840 byte interrupt routine to 6502. Or to AVR or ARM or RISC-V for that matter.
The 6809 is a no go, because the opcodes are different.
Translating a 6800 design to use a 6502 would be an interesting academic exercise but it certainly sounds like a roundabout way to make a working project.
We are told the main part of the code (the interrupt routine) is 840 bytes, so probably around 400 instructions.
The hardest thing is that the 6800 has two accumulators while the 6502 only has one. However in 6800 programs the B accumulator is often used for little more than increment, decrement, compare all of which can be handled by the 6502's extra "index" register. The 6800 data8,X addressing mode can be handled by using a zero-page pair XX to represent the 6800 X register and then "LDY #data8; FOO (XX),Y". That seems like more code, but 6800 programs often do a *lot* of loading different pointers into X in turn (and maybe incrementing and storing them), while on 6502 you can just use the pointers right from their home in ZP, so the code is often smaller (and faster).
It's probably no more than a day's work to convert an 840 byte interrupt routine to 6502. Or to AVR or ARM or RISC-V for that matter.
As much as I think it's fun to play with vintage CPUs, I really can't think of a good reason to use one for this instead of a modern (AVR or whatever) microcontroller, unless the goal is nostalgia, education or just one of those "because it's there" challenges.
Bruce: I did go through all the opcodes, and I remember now the complete lack of the ASL D / LSR D opcodes was the deal killer.
....
Instead of trying to scrape up another of the unobtainium SC44125 CPU or even a 6801, maybe I need to lower the bar an inch or two and start looking for a 68HC11 (preferably the memory-less version?).
Also, firmware dump and memory map are attached.
FDB M0000 ; FFF0: 00 00 '..'
FDB M0000 ; FFF2: 00 00 '..'
FDB M0000 ; FFF4: 00 00 '..'
FDB M0000 ; FFF6: 00 00 '..'
FDB vec_IRQ_EXT ; FFF8: F5 8F '..'
FDB vec_RST ; FFFA: E0 03 '..'
FDB vec_IRQ_EXT ; FFFC: F5 8F '..'
FDB vec_RST ; FFFE: E0 03 '..'
I wasn’t aware of the fact the standard 68xx MPUs reserved those specific locations; the SC44125 likely had those hard-wired internally to free up those addresses for external use.
./dasmfw -dasm 6801 -noaddr -nohex -noasc -cchar '*' -conv off -cref on -info S00060G.nfo -out S00060G.asm -offset E000 S00060G.bin
MAABA EQU $AABA
*
* Disassembler Missing labels to add to the source before assembling
*
MF0FF EQU $F0FF
MF61D EQU $F61D
MFB1E EQU $FB1E
MFFFF EQU $FFFF
*
* Disassembler Missing labels end
*
*****************************************************
* Program's Code Areas
*****************************************************
MFD43 FCB $FF,$00,$00,$01
FCC ":"
FCB $00,$C0,$03,$C0,$03,$C0
FCC "D"
FCB $0F,$FF,$FF,$FF,$FF,$FF,$FF,$FF
FCC "A"
FCB $02,$00,$0F,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
* Delete a "kazilion" FCB $00 lines here
ORG $FFF0
FDB M0000
FDB M0000
FDB M0000
FDB M0000
FDB vec_IRQ_EXT
FDB vec_RST
FDB vec_IRQ_EXT
FDB vec_RST
s:~/tmp/6802-bin/assemblers/a09/A09-master$ ./a09 -oM01 S00060G.asm -lS00060G-01.asm.lst -bS00060G-01.bin
s:~/tmp/6802-bin/assemblers/a09/A09-master$ ./a09 -oM09 S00060G.asm -lS00060G-09.asm.lst -bS00060G-09.bin
diff -b S00060G.bin S00060G-01.bin
v1.48 2021-02-22 additional PEMT capabilities
ASLD,ASRD,CLRD,DECD,INCD,LSLD,LSRD convenience mnemonics added
to all 6800-based assemblers
{ "ASRD", OPCAT_TWOBYTE, 0x4756 }, // ASRA RORB
Now you should have both a MC6801 bin and a MC6809 bin , built from an "Available source code"
Now you should have both a MC6801 bin and a MC6809 bin , built from an "Available source code"
What's the size difference?
Performance difference would be interesting too, but that's harder to estimate.
MC6801-bin
MC6801-bin
-rw-rw-r-- 1 bingo bingo 8192 Sep 27 21:09 S00060G-01.bin
MC6809-bin
-rw-rw-r-- 1 bingo bingo 8282 Sep 28 02:06 S00060Gx-09.bin
FFEE 00000000000000 FCB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$0
0,$00,$00
FFF5 000000000000
FFFB 00000000000000 FCB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$0
0,$00,$00
0002 000000000000
0008 00000000000000 FCB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$0
0,$00,$00
000F 000000000000
0015 00000000000000 FCB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$0
0,$00,$00
001C 000000000000
0022 00000000000000 FCB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$0
0,$00,$00
0029 000000000000
002F 00000000000000 FCB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$0
0,$00,$00
0036 000000000000
003C 00000000000000 FCB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$0
0,$00,$00
0043 000000000000
0049 00 FCB $00
004A 0000 FDB M0000
004C 0000 FDB M0000
004E 0000 FDB M0000
0050 0000 FDB M0000
0052 F58C FDB vec_IRQ_EXT
0054 E002 FDB vec_RST
0056 F58C FDB vec_IRQ_EXT
0058 E002 FDB vec_RST
See if the attached firmware checks out in the tools you have at hand.
I don't have the assembly tools you have on hand yet (I have a Mac, and I made the unfortunate decision to 'upgrade' to the newest model with the M1 chipset, losing the use of my Windows VM in the process), so am not sure how I can validate these files at the moment.
What's the point of even bringing up the 6809? It's just as obsolete as the 6801 and derivatives, and I don't see that the extra features have any value here. It would make a lot more sense to use some version of the HD6303, or maybe the 68HC11 as already mentioned.