from HC11 to 6809

[DiTBho]

hi
every now and then I program in assembly for HC11, in particular I'm working on a VGA/PS/2keyboard terminal "similar" to the famous VT100&C but with a protocol rewritten from scratch to be as flexible and linear as possible.

However, I would like to redesign the mobo with an m68B09@2Mhz(2), as my protocol can have compression, and HC11 It's starting to make me think that it doesn't make sense to also implement this extension, while, by judging the datasheet, the 09 seems better promising!

Of course it would be even better to migrate to 68k, even better to forced 68020 with 8bit bus, I have an evaluation 68020@25Mhz board, and my terminal (C/89 code, recompiled from HC11 to m68k) runs like a rocket(1), the 020 is literally too fast for it, so I would like to stay at 8bit for the terminal, if anything uses the 020 to implement things which require more CPU power.

How tiring is it to migrate from HC11 to 09?
The various problems are:
gcc-3.4.6 is the latest to support HC11, and if you don't exaggerate, it generates decent machine code
G/AS from binutils supports HC11, but it doesn't support Motorola assembly

if Gcc is not enough I have the commercial icc/11 compiler, whereas for the 09 I don't have any commercial compiler, and I've never investigated the real status of the opensource support.

I know there is an experimental branch for Gcc/09, but his author wrote me it's still in beta-stage 


(1) gcc-v3.4.6 for HC11 seems to produce much less performant machine code than gcc v7.* for m68k, and I sometimes get the impression that gcc v4.1.2 produces even better machine code for 020! Anyway, for HC11 I already manually rewrote my software in assembly.
(2) Motorola made different speed grades of 6809:
6809@1.0MHz
68A09@1.5MHz
68B09@2.0MHz <----- my target

6809E, also, the datasheet reports a "/E" (suffix), which has no on-board oscillator and expects to receive an external clock.

[DiTBho]

For those who have never read Wikipedia, here is the main article 

[pqass]

I've been looking for resources for 6809 too.
So far, I've found a cross assembler and ASSIST09 monitor but no C compiler yet.
It may be worthwhile to go with the 68008; same 8-bit width, slightly newer, faster probably same performance (both 8MHz xtals; ÷4 vs 8-Tstates), cheaper than 68020, and better software support but only if you're porting C.

... 6809E, also, the datasheet reports a "/E" (suffix), which has no on-board oscillator and expects to receive an external clock.

FYI: /E has new pins to support multi-cpu designs (pins 39,38,36,33) and Q,E are now inputs.
Also, a clock generator can be made with a 74HC74 dual D-FF (needs to be HC as output needs to be close to Vcc) fed from can oscillator 4x expected output (8MHz for 2MHz Q+E clocks).

[bingo600]

6809E, also, the datasheet reports a "/E" (suffix), which has no on-board oscillator and expects to receive an external clock.

The MC6800/09 was the MCU's in my first PC 
I loved that MCU


The E want's a dualphase clock

You could also look at the Hitachi HD6309 , a 09' with some extensions.
It might have better availabiiity.

I have only used Introl C for the 09' , on a TSC Flex system

A few resources i quickly found.
https://www.aslak.net/index.php/2018/03/07/exploring-c-compilers-for-the-6809/
https://sourceforge.net/projects/cmoc-win32/

But why a '09 ?
If you have C code you can port to the 68K , then it wouldn't be hard to port to an Arm.
Ie. a blackpill  would give you 96K Ram , and lot's of processing power.

Are you using a 6845 or some other external "CRT Display Chip", needing the external/shared Ram ?

/Bingo

[DiTBho]

If you have C code you can port to the 68K , then it wouldn't be hard to port to an Arm.

For 32bit stuff, I am already happy with my MIPS32 and MIPS2 boards.

[DiTBho]

For the C compiler, have you tried GCC6809?
https://code.google.com/archive/p/gcc6809

As I wrote above, its author said it's still in alpha state.
Any feedbacks from users here?

gcc6809 is based on GCC v4.3.6
using
- AS v5.1.1
- newlib v1.15.0
- GDB v7.6.2

[DiTBho]

Since I've already written my application in assembly for HC11, I might as well try "porting" it to 6809, and then adding the compress extension.

6811 and 6809 don't look "too" different 

[pqass]

Since I've already written my application in assembly for HC11, I might as well try "porting" it to 6809, and then adding the compress extension.

6811 and 6809 don't look "too" different 

Note,
"The M68HC11 CPU can execute all M6800 and M6801 instructions (source and object-code compatible) and more than 90 new instruction opcodes. Since more than 256 instruction opcodes exist, a multiple-page opcode map is used in which some new instructions are specified by a page-select prebyte before the opcode byte."  From here, section 6.2, page 198.

However,
"The instruction set of the MC6809E* is similar to that of the MC6800 and is upward compatible at source code level. The number of opcodes has been reduced from 72 to 59, but because of the expanded architecture and additional addressing modes, the number of available opcodes (with different addressing modes) has risen from 197 to 1464."   From here, page19.      note: * typo? in a 6809 non-E datasheet.   

I guess it's like the 8086 being source compatible with 8080 assembly.

i.e. 6809 is NOT object code compatible with 6800 nor 68HC11. If your code is just using 6800 opcodes, then you should be able to re-assemble for 6809 BUT if you went off the reservation with 68HC11-specific opcodes, well you're going to have a harder time porting.

See here for a detailed look at opcode differences between 6809 and 6800. Sorry for the non-authoritative source.

[DiTBho]

source level

yes, I was talking about the source-level.
term_HC11.asm -> term_6809.asm.

[DiTBho]

I haven't had time yet, it seems that it is not easy to find the sources of a "decent" assembly compiler with Motorola syntax.

[DiTBho]

The MC6800/09 was the MCU's in my first PC 

Which computer was?

You could also look at the Hitachi HD6309 , a 09' with some extensions.
It might have better availabiiity.

It seems to 68B09 and 63B09 are pin-to-pin compatible, unfortunately it also seems that there are chips that are actually not 6309 but 6809, sold on ebay mistakenly, i.e. as "fake".

Code: [Select]

   PSHS D    ; Save D register
   FDB $1043 ; 6309 COMD instruction, COMA on 6809
   CMPB 1,S  ; not equal if 6309
   PULS D    ; restore D
   ; Z clear if 6309
   ; Z set if 6809
I found a way to verify that it is indeed a 6309, so I can think about sending a chip, check and send it back if defective.

[DiTBho]

Since the HD63C09 is CMOS, you just have to look at the output high voltage or supply current. 
No software test required.

Unfortunately buying 6309 on eBay doesn’t always net a 6309, sometimes it’s a 6809, and that's what "fake 6309" means: "6309" written on the chip (wrong picture?), or listed as "6309" (just a mistake?), and you get a chip that actually does not have any additional 6309 functionality.



By Googling I found that some other users have complained about it, some of whom wrote this test script, which is much easier to run with any ROM containing Microsoft basic.

So, I am going to place at least a couple of orders from different sellers (both with 100% positive feedbacks) to maximize the chance of getting at least one of the genuines chip.

[DiTBho]

So, 6309 has a MD register, which is a mode and error register and works much in the same way as the CC register.

The bit definitions are as follows:

Code: [Select]

Write bits
 Bit 0 - Execution mode of the 6309.
 If clear ( 0 ), the cpu is in 6809 emulation mode.
 If set ( 1 ), the cpu is in 6309 native mode.

 Bit 1 - FIRQ mode
 If clear ( 0 ), the FIRQ will occur normally.
 If set ( 1 ) , the FIRQ will operate the same as the IRQ

 Bits 2 to 5 are unused

Very nice!

[Kjelt]

Brings back nightmares from the 90s on my university where they had 6809's running OS9.
Have fun guys but I am staying away from the old scool eprom erasing and programming now modern uCs have flash and incircuit debugging build in 

[pqass]

It's not so bad if you use a monitor that can upload Motorola S-record formatted file to RAM (like ASSIST09).
No moving of ROM between programmer and target PCB. And especially no wasted 20 mins for UV erase.

On your dev machine, just edit your asm file, make, make install (which uploads the generated hex file to the target PCB via serial; bracketed with monitor commands like "L" for load and "G <addr> to run). Done.  I'm doing this now with my breadboard 8085 running MON85 monitor.  Soon I'll be doing this with a breadboard 6809 with ASSIST09, and then a 68008 in the future).  Fun stuff.

[DiTBho]

comparing 8085 with 6809?

[DiTBho]

make upload
- bracketed with monitor "load" command
- uploads the generated { hex, srec, brec } file to the target, via { serial/hw_handshake, ethernet/udp-ip, ... }

make run
- bracketed with monitor "go <addr>" command

[pqass]

comparing 8085 with 6809?

From what I've been reading of the 6809, it's a much nicer instruction set than the 8085 [for the programmer]. More orthogonal, less awkward.   
I just happen to have a breadboarded 8085 setup and was describing my fast dev process.
So far, I've got my 6809e to freerun. Once I patch the ASSIST09 monitor asm for the 16550 UART, I'll explore that environment too.

[pqass]

make upload
- bracketed with monitor "load" command
- uploads the generated { hex, srec, brec } file to the target, via { serial/hw_handshake, ethernet/udp-ip, ... }

make run
- bracketed with monitor "go <addr>" command

Sure, why not.

Here's mine:

Code: [Select]

[z80_bb]$ more Makefile
PROGTTY="/dev/ttyUSB0"

all: mo.hex

mo.bin: mo.asm
z80asm $< -o $@ --list=mo.lst -vv

mo.hex: mo.bin
echo generating $@ from $<
$(shell cat $< |./bin2hex.sh >$@)

install: mo.hex
echo writing $< to $(PROGTTY)
echo -e "l\r" >>$(PROGTTY)
sleep 1
cat $< | ./upload.sh $(PROGTTY)
sleep 1
echo -e "g 8000\r" >>$(PROGTTY)

clean:
rm -f *.bin *.hex *.lst


[z80_bb]$   more upload.sh
#!/bin/bash
fn="$1"
if [ -z "$fn" ]; then
fn="/dev/ttyUSB0"
fi
dly="0.1"
while IFS= read -r line
do
  echo "$line"
  echo -e "$line\r" >> "$fn"
  sleep "$dly"
done   


[z80_bb]$ more bin2hex.sh
#!/bin/sh

# MON85: remove/change first awk on new line below to alter the address+offset rewrite
# MON85: optional trailing :00 to exit the monitor's L command

od -A x -t x1 -v -w12 | awk '{ if (NF > 1) print; }' \
| awk '{printf "%06x %s\n", strtonum("0x" $1)+0x8000, substr($0,index($0," ")+1);}' \
| awk '{ if(NF>1) printf "%0.2x %s %s 00 %s\n", NF-1, substr($0,3,2), substr($0,5,2), substr($0,length($1)+1);}' \
| awk '{crc=0; for(i=1; i<=NF; i++) {printf "%s ", $i; n=strtonum("0x" $i); crc=and((crc+n),255);} printf "%0.2x\n",and(compl(crc)+1,255);}' \
| awk '{print ":" $0;}' \
| sed 's/ //g' \
| ( tr '[:lower:]' '[:upper:]'; echo ":00" )


[DiTBho]

I prefer the 68B50, which is designed to run with a 2MHz 680x/68HC11 part using the Motorola bus not the rather messier Intel/Zilog one.

However, 6850 is NMOS, so I really like the HD6350 variant:
- CMOS
- lower power
- up tp 1MBps
- compatible with 6850

[DiTBho]

Sure, why not.

Better to keep "upload" separate from "run", also because you would like to use a simulator, and in the middle a debugger, therefore wanting to load a symbol table before sending the code to execution.

[pqass]

I have two 16550s and zero 6850s. That is my motivation for using the former.
For me, this exploration is a trip into the past. 

My breadboard 8085 consumes 260mA@5V and takes up 4, 63-column breadboard strips with:
NEC 80C85AHC-2 @5MHz, Harris CP82C55A, NS16550, RCA CDM62256, AMD AM29F010B, TI ADC0808N,
HP HDSP-6508 16-seg LED bubble display, 16x2 LCD, 4x4 keypad,  plus 12 more glue.
Today's equivalent is a $3 MCU consuming 10 times less energy.

I'm old-fashioned and use print to LCD/UART for debugging.
If I want to optimize, I can just upload the diff between the latest generated hex and the previous hex uploaded.

[DiTBho]

For me, this exploration is a trip into the past. 

me too, in a way; however, I have a couple of concrete projects to create.

One of them is a terminal similar to the vt100 but with a custom protocol. it must consume as little as possible mWatt because it must be integrated into a more complex project, and the power supply can only deliver 5A@12V=60Watt, which seems like a lot to me but in that case not I am sure 60Watt will be enough to power all the five boards X___X

Therefore: all C-MOS components, if it's possibile, and they are available 

I'm old-fashioned and use print to LCD/UART for debugging.
If I want to optimize, I can just upload the diff between the latest generated hex and the previous hex uploaded.

Optimize? well, the problem is when you find your code is buggy 

yes, you can also debug manually on the serial port and patch the code manually with the monitor (memory edit, in hex form), in the end it's just a question of how long does it take to ferret out the bug, so ... I have nothing against using a software emulator and ICEs (attached to a simulator, in this case), just to reduce development time and be able to develop even when I'm on the train or plane.

I have two 16550s and zero 6850s. That is my motivation for using the former.

I didn't have a chip either, I am buying everything on eBay and Aliexpress.

if I imagine a possible concern: no doubt on Alixepress there is a risk, fake or damaged material often arrives, sold as NOS, but it must be said that on rare and niche components... the probability of a rip-off tends to be at least 3 orders of magnitude lower.

I don't like eBay, but in this case it's useful 


edit:
bought on Aliexpress, just right now, qty=10, PCF8584, i2c-HBA

[DiTBho]

For me, this exploration is a trip into the past. 

Hackaday, today: Programming 1949 Style (If you want to try your hand with the EDSAC ...), enjoy here the article 

[pqass]

"Optimize", as in, the uploading of just the code changed during your debug session so you're not re-uploading multiple KB hex every time. But you'd have to organize the parts you're working on to be closer to the end of your generated hex.  eg.  make minor code change, reset into monitor, make, make install (the diff), verify if the change worked, if not loop back to top.
On second thought, it's easier/wiser to just dial up the baud rate.

Emulators won't reveal timing issues. eg. slow/missed LCD module response.  The blinkenlights are never as nice as the real thing.

I'd like to add PATA and SPI (SD card) interfaces, maybe even DRAM SIMMs. I don't really care for BASIC but maybe a FORTH instead.

I managed to find my obsolete parts source via eBay locally (same country) so I didn't have to wait months for the slow boat.  No duds so far.

My nostalgia doesn't go pre-solid-state.  Nor do I pine for flicking switches.  That's too painful.