Replicating a 'custom' 6800 in FPGA

[bingo600]

Wouldn't this guy solve it ??

https://www.ebay.com/itm/133559825921

https://www.scribd.com/document/311751238/HLN062-Microcomputer-Data-Book

Or the HD6803
https://www.ebay.com/itm/361788716735
https://www.ebay.com/itm/363345251235

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]

Or scrap this board , and get 6821's too
https://www.ebay.com/itm/194361823959

Edit:
This guy made a (i think cycle accurate 6801) in a BeagleBone Black
http://www.jks.com/5370/5370.html
https://github.com/jks-prv/5370_proc

I have one in my HP5370B   


/Bingo

[brucehoult]

Wow, "new old" stock.

And there's someone in Australia selling 6809s!

https://www.ebay.com/itm/202326008513

I think I want one. I don't know why. Other than I helped build a wire-wrapped 6809 designed with a couple of my fellow students in 1983. And it's the ultimate CISCy 8 bit. But an AVR will kick its butt.

[SiliconWizard]

To be fair, the ultimate would be the 6309 then. https://en.wikipedia.org/wiki/Hitachi_6309
It's relatively easy to find on eBay, in particular the 63C09E variant.

[james_s]

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.

[metertech58761]

The 'original recipe' 6800 is a no-go because of no D register and missing opcodes.

The 6809 is a no go, because the opcodes are different.

The 6801 / 6803 stock version would probably work, but I would need to know how to configure the ports to be address / data pins.

I saw a mention of a 68xx emulator for ARM, and that would be of interest...

Hopefully I can have the ROM dump cleaned up and a list made of addresses and their functions so I can post a PDF of both within a couple days.

[brucehoult]

The 6809 is a no go, because the opcodes are different.

But it's probably an easy disassemble-reassemble job, if you can disassemble.

[metertech58761]

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.

I did double-check the 68HC11, and I realize that one IS an option after all, since it does have every. single. opcode. that I need from the 6801 opcode set.

I would not need to make any coding changes or allowances for it to be able to run on the HC11 (but I do see a bunch of stuff that could / should be optimized or made consistent in the code).

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.

[AaronLee]

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.

I agree. If you just want to copy an old board, then, by all means, just get the original components and make a copy of it. If you're not making a copy / repair, go with a modern MCU, and study the code of the original and learn a lot in the process. There's a lot to learn / challenges either way (using a different chip be it modern or vintage), but if you port the old design to a modern design, there's a good chance that you can reuse some of it at a later point for a different project, and even if not, at least knowledge on a modern chip that's always useful when making new projects.

[brucehoult]

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.

But ASL D is exactly the same as ASL B;ASL A isn't it?

[joeqsmith]

....

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.

Doing a quick Google search, it seems you've been at it for a while.   I am curious if you have any other hobbies as I knew a person who used that same name?   

I'll have a look at the code you provided.

https://www.reddit.com/r/AskElectronics/comments/mlwgeh/68hc11_successor/
https://community.nxp.com/t5/8-bit-Microcontrollers/Seeking-info-Motorola-SC44125P-microcontroller/m-p/1079203
https://forum.arduino.cc/t/general-question-mc680x-code-arduino/697190

https://forum.allaboutcircuits.com/threads/circuit-comparison.174667/

[joeqsmith]

Check the attached S19 record against your original PROMs and make sure it matches.  If not, upload the original images.

[metertech58761]

I guess I have been at it a while, haven't I?
It's mostly been in brief bursts, however - not continuously.

Here's the original dump.
There is one change I made when I started analyzing the firmware, however.
In the original dump the display RAM range will be at 0x0C69-0x0C78, whereas my analysis moved it up to 0x0C30-0x0C3F.
(better allocation of available RAM and makes it easier to understand the display RAM at a glance)

[bingo600]

Just had a quick glance at your Schematic
https://www.eevblog.com/forum/fpga/replicating-a-custom-6800-in-fpga/?action=dlattach;attach=1271020

 MemoryMap & the ROM code


I noticed 2 things

1:
There's no "External IRQ2" on a MC6801/MC6803  , in fact i haven't seen more than 2  IRQ's  - NMI + IRQ1 on the 6800/01/02/03 series ... except the additional FIRQ for the 09'.
Your schematic has a IRQ2 pin.

2:
The 6801 internal registers ($00 - $1F) will overlap the MC6840 Timer and the MC6821 PIA in ALL modes , even 03.
If you want to use the 6801 , and can live with "One IRQ" , i suggest you use mode 3 , and move the 6840 & 6821 to another address range



According to your ROM , you are only having 2 active "Vector routines"  RST and NMI (IRQ_EXT)  , seems like NMI & IRQ1 use the same handler

Code: [Select]

        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 see IRQ2 is used by the PIA , and NMI used by the Timer  , what is using IRQ1 ? 
Is that the 8279 ?

Edit: IRQ1 Seems to be the Max706 watchdog in lower right of schem. ... correct ?
https://datasheets.maximintegrated.com/en/ds/MAX705-MAX813L.pdf
But Pin4 on that is a Max706 input , what am i missing ??


The schematic is "small" my pdf reader won't zoom enough in , to make things easy readable

 
You could maybe "OR" the Timer & the watchdog to NMI , i would expect you could query if the timer generated  the NMI , ... Else it must have been the "Dog"




/Bingo

[bingo600]

Back in ancient time my first real MCU system was a 6809 FLEX system.

And it just hit me ....  From
https://www.cpu-world.com/CPUs/6809/index.html
 
Motorola 6809 (MC6809) is an enhanced version of the 6800 microprocessor. The 6809 is not object-code compatible with the 6800, but it is source-code compatible.
You might just assemble the disassembled 68xx source code for the 6809 , and use a MC6809.

There could be electrical/pinout incompabilities , and there was also something with an "E Clock" on one of the MC6809's   - ISTR the one ending in 6809E

But the 09' has no internal stuff in the $00-$1F range , and you wouldn't have to move the Timer & PIA.
Maybe worth a try.

I'm not en EE , so the electrical pinout , has to bee looked into.
But you would have to make an adapter print even if you chose the FPGA way.
Btw: I'm not sure the 6809 has a multiplexed addr/data bus.

And maybe the E-Clock has to be looked into.
I think the 6809E or was it 68B09E could run 2MHz , and needed that E-Clock, for running pheripal 1MHZ devices w. the 2MHz MCU clock.
I would avoid an E' MCU , unless you already have the E-Clock on your board, you said you needed 1MHz.


/Bingo

[metertech58761]

Regarding the IRQ / IRQ2 lines, I’m not entirely convinced they are needed at all, as there is NO IRQ handler in this code, only the NMI line.

The pulse train that drives the NMI line is derived from the 6840 PTM’s IRQ line.

Perhaps the IRQ / IRQ2 lines could be tied off completely, and the MAX706 would only be needed to give a reset pulse on power-up.
I just adapted the circuit from the originals that I reverse-engineered; I did recently find those schematics again and could post if needed.

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.

I want to tweak the address decoding anyway so I can combine the two separate blocks of RAM into a single chip.

As for the odd doubling of vector addresses at the end of the ROM, I did notice that as well, and  I think only the last two really matter anyway.

[bingo600]

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.

It's not all of them that has Internal stuff at $00-$1F , but the 6801 & 6803 does

/Bingo

[bingo600]

I just toyed a bit more 


Build 6801 Disassembler - My choice was dasmfw (Seems to be a newer version of f9dasm)
https://github.com/Arakula/dasmfw


Disassembling the provided ROM Binary , using dasmfw
-
#Convenience macros off , and comment = '*'  * makes as01 happy

Code: [Select]

./dasmfw -dasm 6801 -noaddr -nohex -noasc -cchar '*' -conv off -cref on -info S00060G.nfo -out S00060G.asm -offset E000 S00060G.bin

Now code is in : S00060G.asm

Fixup a few disassembly quirks ... I have no idea why the below 4 Labels are referred to ,  but not created.

Add the below labels somewhere in the S00060G.asm , i chose just before "Program's Code areas"

It will look like this when you are done

Code: [Select]

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
*****************************************************



Clean a lot of the FCB $00 lines , near the end of the program.
No worries , the aseembler will fill the area with $00's when creating the binary. And it is neded for a "MC6809 trick comming in a while"


Near the "Label MFD43" , you will see the last line that contains anything but $00 - The line containing : FCB     $02,$00,$0F,$00 .......

Delete all Lines , until the first line containing :         FDB     M0000

Just above the line containing :         FDB     M0000 
Insert an : ORG     $FFF0  - To put the vectors back in place


It will look like this when you are done

Code: [Select]

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


Now the soure should be ready for the assembler

I tried the below first , works fine for mc6801 & mc6809 , but can't generate mc6809 code from mc6801 source , the Aracula A09 can do that.
https://github.com/JimInCA/motorola-6800-assembler


Build the Arakula A09 68xx assembler
https://github.com/Arakula/A09

Copy your "modified" disassembler source code (S00060G.asm) to the Aracule "Binary dir"

Build both MC6801 & MC6809 binaries from the source

M6801

Code: [Select]

s:~/tmp/6802-bin/assemblers/a09/A09-master$ ./a09 -oM01 S00060G.asm -lS00060G-01.asm.lst -bS00060G-01.bin

M6809

Code: [Select]

s:~/tmp/6802-bin/assemblers/a09/A09-master$ ./a09 -oM09 S00060G.asm -lS00060G-09.asm.lst -bS00060G-09.bin


Verify that the MC6801 binary is equal to the original binary , diff in "-b" binary mode will only output something if the files are different

Code: [Select]

diff -b S00060G.bin S00060G-01.bin

Now you should have both a MC6801 bin and a MC6809 bin , built from an "Available source code"

For the MC6809 - You might want to correct the FIRQ Vector at the end , or make it Reset the beast...
Read up on FIRQ, if you ever use it. It won't save any registers for you , in IRQ entry or restore on exit.
That ought to be the only thing to observe on the MC6809.

The attached A09-Sources , is not A09 related (that's on github)
It is  the disassembled  source , and the listings + bins from the A09 assembler.

Edit: Added the missing disassembler "definition nfo file" - copy to the dasmfw dir

Edit2: I hope you use linux 

/Bingo

[bingo600]

Btw:
RE : https://www.eevblog.com/forum/fpga/replicating-a-custom-6800-in-fpga/msg3703185/#msg3703185

The disassembled ASRD is a "convenience mnemonic" , that can be replaced with the two instructions
ASRA
RORB

See :
https://github.com/Arakula/A09/blob/master/a09.c

   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

I specifically disabled those macros , to make the source "more compatible" with the simple assemblers found.

conv on|off
noconv
Quite some assemblers know "convenience mnemonics"; these are evaluated to a combination of

#Convenience macros off
s:~/tmp/6802-bin/dasmfw-master$ ./dasmfw -dasm 6801 -noaddr -nohex -noasc -conv off -cref on -info S00060G.nfo -out S00060G.asm -offset E000 S00060G.bin

[brucehoult]

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.

[metertech58761]

You had me a bit confused when you mentioned the ASRD macro, but I just had a peek at the source code and do remember one of the test segments has multiple ASR A / ROR B instructions.

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.

Anyway, using a more manual process, I went through the code with a fine-tooth comb to try and make it a bit more clear and where possible, a bit more consistent / efficient (especially initialization, displaying the current test number, and especially the relay pass / fail evaluation code sections). See if the attached firmware checks out in the tools you have at hand.

[bingo600]

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.

Code: [Select]

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
Seems like the MC6809 code increases by 90 bytes  (and wraps , if we don't delete some of the FCB $00 lines)

Here the 09' list file , that shows the wraparound

Code: [Select]


 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



/Bingo

[bingo600]

See if the attached firmware checks out in the tools you have at hand.

I'm not sure what you want me to do with that bin file ??
I have no way of doing much but to disassemble it , and why ... You apparently have the source.

/Bingo

[brucehoult]

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.

I'm not sure why you'd want to run Windows, that just seems like unnecessary pain.

I love my M1 Mac Mini. Great machine!

Most Linux'y stuff compiles and runs fine on either x86 Mac or ARM Linux so if no one has quite gotten around to tweaking it for ARM Mac then you have two options:

- type "arch -x86_64 bash" in a Terminal.app window to compile and use x86 software in Rosetta

- run ARM Linux in a VM. I've been doing that since November. e.g. see this which I last updated on Nov 23 2020 https://hoult.org/arm64_mini.html

[bingo600]

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.

I have no prefs. , and thought it was a "One off"
The HD6303 seems to fit the bill too (as a 6801/03) replacement , but still have periphs at $00..$1F , overlapping with the current Timer & PIA mapping.
The 6809 doesn't have those.

/Bingo

[metertech58761]

Definitely a one-off / hobby project.

Since the HC11 is far more available than the 6801/6803, that would be my preference, especially since it uses the exact same opcodes etc.