Improved MENSCH™ Microcomputer Software

[Martin_H]

BigDumbDinosaur wrote:

Refer to subsection 6.3.3.6 in the 65C816 data sheet for an explanation.

Thanks. After reading that in makes more sense. I suddenly remembered your post above that the Kowalski assembler also supports this syntax.

The CA65 assembler docs say it tries to infer the addressing mode based upon the context but can't always do that. In that case the address size of a symbol can be specified with a prefix:

Code: Select all

z: zeropage addressing (8 bits).
a: absolute addressing (16 bits).
f: far addressing (24 bits).

These don't align with the w65c816 datasheet's recommended assembler syntax standards. They're honestly more C-like which makes sense as CA65 was written to act as the backend for CC65.

[Martin_H]

After reading the WDC monitor source code I learned how to control the w65c265's built-in tone generators. Naturally this required a music demo with one classical and one video game piece. The player is written in 65816 assembly, and it is data driven, but rudimentary. It can handle two note polyphonic scores, but the notes must be the same duration. Currently repeats are handled by repeating blocks rather than metadata within the score.

Fixing those limitations should be simple additions for the future, along with reading scores from removable media like an SD card. Here's a video of it:
https://www.youtube.com/watch?v=OAjmP7LRrgI

I have only one function left in my library to debug pbCount which I don't need in the near term. It will be useful in the future when reading shaft encoders to keep a motor turning at a desired velocity. So, I will need to build a physical test rig for it. Next steps for this project are building out the interface board with servo headers, a motor driver IC, a motor power supply connection, and a header for a Bluetooth serial adapter.

[Martin_H]

This is a 65816-coding efficiency question about the working code at the bottom of this post. My 65816 code assumes 16-bit wide accumulator and index registers, but I switch to 8-bit wide registers as needed. While porting the accumulator print function from the 6502, I found two ways to do it:

1) Maintain a 16-bit wide accumulator and in the @print_nybble function extended three 8-bit constants from $0f to $000f, $90 to $9990, and $40 to $9940.

2) Retain the 8-bit constants but switch to an 8-bit wide accumulator.

The synchronous serial I/O is the bottleneck, so this isn't significant in this code block. But loading 16-bit constants and ANDing and ADDing them to a 16-bit accumulator when only 8-bit wide is relevant seems wasteful. I read the 65816 documentation, and it says add one cycle for 16-bit wide operations. So that's three cycles per call, a total of six for the 8-bit accumulator and twelve for a 16-bit wide accumulator. But that savings is offset by the six cycles required for the SEP and REP instructions.

Am I doing this accounting correctly? If so, it seems like switching to an 8-bit wide accumulator in a tight loop of some sort is worth it, but otherwise is not.

Code: Select all

; f_printa - prints lower eight bits of the accumulator in hex to the console.
; Inputs:
;   A - byte to print
; Outputs:
;   A - retained
PUBLIC f_printa
	pha
	pha
	lsr
	lsr
	lsr
	lsr
	jsr @print_nybble
	pla
	jsr @print_nybble
	pla
	rts

@print_nybble:
	and #LOWNIB
	sed
	clc
	adc #$9990	        	; Produce $90-$99 or $00-$05
	adc #$9940			; Produce $30-$39 or $41-$46
	cld
	jmp f_putch
ENDPUBLIC

; f_printc - prints C as a 16 bit hex number to the console.
; Inputs:
;   C - number
; Outputs:
;   C - preserved
PUBLIC f_printc
	pha
	pha
	xba
	jsr f_printa
	pla
	jsr f_printa
	pla
	rts
ENDPUBLIC

[Martin_H]

I spent two days soldering a SN754410 to my prototype control board along with the headers required to connect motors and batteries to it. I then tweaked my PWM_LED sample into a motor control sample that ramps two motors up to full speed, runs them at full for a second, then ramps them down to a stop.

I'm pleased with my success, but I can hear the high-pitched whine of the PWM frequency. It's probably an artifact of bit banging PWM on a 3.6864 MHz CPU. With faster microcontrollers running at 16 MHz or hardware PWM circuits it's usually ultrasonic.

Update: I found a way to do PWM to multiple pins concurrently. This let me ramp both motors simultaneously increasing the refresh frequency. The whine is still present, but much attenuated. Probably because its higher in the audio spectrum but still not ultrasonic.

As an aside, I've seen music demos using PWM whine to intentionally hit desired frequencies.