[Project Log] Python on the 6502/C64, 8080, 6800, 6809 and AVR

Off Topic Maker Matters
165

I will probably implement the shifts while thinking about how to do oct().

Shifting has to affect every byte of an integer. I am not wanting to have to shift a potentially long integer for each three bits oct() formats. Especially on the 6502 on which a byte has to be in the only accumulator to be shifted as seen in this particularly ugly piece of code to multiply a number by eight:

 43F5 A5 0C	      [3] 11272		lda	Int3			; Get maximum length of the result
 43F7 A4 0D	      [3] 11273		ldy	Int3+1			; Eight chars for each byte +
 43F9 0A	      [2] 11274		asl	A			;   two for the prefix and one sign
 43FA AA	      [2] 11275		tax
 43FB 98	      [2] 11276		tya
 43FC 2A	      [2] 11277		rol	A
 43FD A8	      [2] 11278		tay
 43FE 8A	      [2] 11279		txa
 43FF 0A	      [2] 11280		asl	A
 4400 AA	      [2] 11281		tax
 4401 98	      [2] 11282		tya
 4402 2A	      [2] 11283		rol	A
 4403 A8	      [2] 11284		tay
 4404 8A	      [2] 11285		txa
 4405 0A	      [2] 11286		asl	A
 4406 AA	      [2] 11287		tax
 4407 98	      [2] 11288		tya
 4408 2A	      [2] 11289		rol	A
 4409 86 0A	      [3] 11290		stx	Int2
 440B 85 0B	      [3] 11291		sta	Int2+1

Hmm, now that I look at it, it is a couple of cycles faster to do this:

	lda	Int3
	sta	Int2
	lda	Int3+1
	sta	Int2+2
	asl	Int2
	rol	Int2+1
	asl	Int2
	rol	Int2+1
	asl	Int2
	rol	Int2+1

I have never given the read/modify/write instructions much respect, but in this case, they are appropriate.

As they currently stand, hex() and bin() currently format the number “backward” from the low order byte to the high even though they do not have to. The reason is that one of the ways to do octal is to format three bits at a time starting at the low end until I run out of bits.

The other way is to take advantage of the fact that octal numbers resync to byte boundary every three bytes, so bytes & 3 gives the number of odd bytes at the upper end of the number. Handle that special case then do the rest of the number three bytes at a time.

2 Likes
166

I think I have settled on a way to do the octal formatting.

while ByteCount >= 3:
	Format lowest order three bytes into eight octits
	Advance pointer into the integer by three
	ByteCount = ByteCount - 3
if ByteCount > 0:
	Handle the left over one or two bytes

This will let me avoid dividing by three. I am glad I designed hex() to work from right to left…

1 Like
167

Oct() is working now. It still needs some more testing. I also need to look at all three and factor out some of the common code.

The test loop now looks like this:

Base = 10
Number = input('Number? ')
while Number != '':
	BaseIn = input('Base? ')
	if BaseIn != '':
		# Change base
		Base = int(BaseIn, 10)
	Value = int(Number, Base)
	print(Value, hex(Value), oct(Value), bin(Value), Base)
	Number = input('Another? ')

Then on to make the project stop appearing shiftless.

1 Like
168

In anticipation of this pending acquisition Altair 8800 mini-clone up for grabs, I have begun writing the run-time library code for the 8080.

This is a bit of 6502 code:

 039D AD 378C	      [4] 00373		lda	Zero_List		; Get list of variables to zero
 03A0 85 18	      [3] 00374		sta	Ptr0
 03A2 AD 378D	      [4] 00375		lda	Zero_List+1
 03A5 85 19	      [3] 00376		sta	Ptr0+1
 			  00377
 03A7			  00378	InitRTL1
 03A7 05 18	      [3] 00379		ora	Ptr0
 03A9 F0 18 (03C3)  [2/3] 00380		beq	InitRTL2		; No more uninitialized variables
 			  00381
 03AB A9 00	      [2] 00382		lda	#0			; Zero out this variable
 03AD A0 02	      [2] 00383		ldy	#2			; Point to the variable
 03AF 91 18	      [6] 00384		sta	(Ptr0),Y
 03B1 C8	      [2] 00385		iny
 03B2 91 18	      [6] 00386		sta	(Ptr0),Y
 			  00387
 03B4 A0 00	      [2] 00388		ldy	#0
 03B6 B1 18	    [5/6] 00389		lda	(Ptr0),Y
 03B8 AA	      [2] 00390		tax
 03B9 C8	      [2] 00391		iny
 03BA B1 18	    [5/6] 00392		lda	(Ptr0),y
 03BC 85 19	      [3] 00393		sta	Ptr0+1
 03BE 86 18	      [3] 00394		stx	Ptr0
 			  00395
 03C0 4C 03A7	      [3] 00396		jmp	InitRTL1
 			  00397
 03C3			  00398	InitRTL2
 03C3 AD 378E	      [4] 00399		lda	Init_List		; Get list of variables to initialize
 03C6 85 18	      [3] 00400		sta	Ptr0
 03C8 AD 378F	      [4] 00401		lda	Init_List+1
 03CB 85 19	      [3] 00402		sta	Ptr0+1
 			  00403
 03CD			  00404	InitRTL3
 03CD 05 18	      [3] 00405		ora	Ptr0
 03CF F0 1E (03EF)  [2/3] 00406		beq	InitRTL4		; No more initialized variables
 			  00407
 03D1 A0 02	      [2] 00408		ldy	#2			; Load variable value
 03D3 B1 18	    [5/6] 00409		lda	(Ptr0),Y
 03D5 AA	      [2] 00410		tax
 03D6 C8	      [2] 00411		iny
 03D7 B1 18	    [5/6] 00412		lda	(Ptr0),Y
 			  00413
 03D9 C8	      [2] 00414		iny				; Store variable value
 03DA 91 18	      [6] 00415		sta	(Ptr0),Y
 03DC C8	      [2] 00416		iny
 03DD 8A	      [2] 00417		txa
 03DE 91 18	      [6] 00418		sta	(Ptr0),Y
 			  00419
 03E0 A0 00	      [2] 00420		ldy	#0
 03E2 B1 18	    [5/6] 00421		lda	(Ptr0),Y
 03E4 AA	      [2] 00422		tax
 03E5 C8	      [2] 00423		iny
 03E6 B1 18	    [5/6] 00424		lda	(Ptr0),y
 03E8 85 19	      [3] 00425		sta	Ptr0+1
 03EA 86 18	      [3] 00426		stx	Ptr0
 			  00427
 03EC 4C 03CD	      [3] 00428		jmp	InitRTL3
 			  00429
 03EF			  00430	InitRTL4

and the corresponding 8080 code:

 0249 2A 02C1	     [16] 00295		lhld	Zero_List		; Get list of variables to zero
 			  00296
 024C			  00297	InitRTL1
 024C 7C	      [5] 00298		mov	A,H
 024D B5	      [4] 00299		ora	L
 024E CA 025E	     [10] 00300		jz	InitRTL2		; No more uninitialized variables
 			  00301
 0251 3E 00	      [7] 00302		mvi	A,0			; Zero out this variable
 0253 5E	      [7] 00303		mov	E,M			; Get low byte of next address
 0254 23	      [5] 00304		inx	H
 0255 56	      [7] 00305		mov	D,M			; Get high byte of next address
 0256 23	      [5] 00306		inx	H			; Point to the variable
 0257 77	      [7] 00307		mov	M,A
 0258 23	      [5] 00308		inx	H
 0259 77	      [7] 00309		mov	M,A
 			  00310
 025A EB	      [4] 00311		xchg				; Point HL to next
 			  00312
 025B C3 024C	     [10] 00313		jmp	InitRTL1
 			  00314
 025E			  00315	InitRTL2
 025E 2A 02C3	     [16] 00316		lhld	Init_List		; Get list of variables to initialize
 			  00317
 0261			  00318	InitRTL3
 0261 7C	      [5] 00319		mov	A,H
 0262 B5	      [4] 00320		ora	L
 0263 CA 0275	     [10] 00321		jz	InitRTL4		; No more initialized variables
 			  00322
 0266 5E	      [7] 00323		mov	E,M			; Get low byte of next address
 0267 23	      [5] 00324		inx	H
 0268 56	      [7] 00325		mov	D,M			; Get high byte of next address
 0269 23	      [5] 00326		inx	H			; Point to the value
 026A 4E	      [7] 00327		mov	C,M			; Get low byte of the value
 026B 23	      [5] 00328		inx	H
 026C 46	      [7] 00329		mov	B,M			; Get high byte of value
 026D 23	      [5] 00330		inx	H			; Point to the variable
 026E 71	      [7] 00331		mov	M,C			; Restore the value
 026F 23	      [5] 00332		inx	H
 0270 70	      [7] 00333		mov	M,B
 			  00334
 0271 EB	      [4] 00335		xchg				; Point HL to next
 			  00336
 0272 C3 0261	     [10] 00337		jmp	InitRTL3
 			  00338
 0275			  00339	InitRTL4

Note that a 2.5 MHz 8080 is roughly equivalent to a 1 MHz 6502.

Code for the 6800;

 020A 4F	      [2] 00299	         clra             ; The zero
 020B FE 025B	      [5] 00300	         ldx    Zero_List ; Get list of variables to zero
 			  00301
 020E 27 08 (0218)    [4] 00302	         beq    InitRTL2  ; No uninitialized variables
 			  00303
 0210			  00304	InitRTL1
 0210 A7 02	      [6] 00305	         staa   2,X       ; Zero out this variable
 0212 A7 03	      [6] 00306	         staa   3,X
 			  00307
 0214 EE 00	      [6] 00308	         ldx    ,X        ; Point to the next variable
 			  00309
 0216 26 F8 (0210)    [4] 00310	         bne    InitRTL1
 			  00311
 0218			  00312	InitRTL2
 0218 FE 025D	      [5] 00313	         ldx    Init_List ; Get list of variables to initialize
 021B 27 0D (022A)    [4] 00314	         beq    InitRTL4  ; No more initialized variables
 			  00315
 021D			  00316	InitRTL3
 021D A6 02	      [5] 00317	         ldaa   2,X       ; Load variable value
 021F A7 04	      [6] 00318	         staa   4,X       ; Store variable value
 0221 A6 03	      [5] 00319	         ldaa   3,X
 0223 A7 05	      [6] 00320	         staa   5,X
 			  00321
 0225 EE 00	      [6] 00322	         ldx    ,X        ; Point to the next variable
 0227 26 F4 (021D)    [4] 00323	         bne    InitRTL3
 			  00324
 0229			  00325	InitRTL4

and the 6809;

 0200 CC 0000		      [3] 00290	         ldd    #0        ; The zero
 0203 BE 0266		      [6] 00291	         ldx    Zero_List ; Get list of variables to zero
 				  00292
 0206 27 06 (020E)	      [3] 00293	         beq    InitRTL2  ; No uninitialized variables
 				  00294
 0208				  00295	InitRTL1
 0208 ED 02		      [6] 00296	         std    2,X       ; Zero out this variable
 				  00297
 020A AE 84		      [5] 00298	         ldx    ,X        ; Point to the next variable
 				  00299
 020C 26 FA (0208)	      [3] 00300	         bne    InitRTL1
 				  00301
 020E				  00302	InitRTL2
 020E BE 0268		      [6] 00303	         ldx    Init_List ; Get list of variables to initialize
 0211 27 21 (0234)	      [3] 00304	         beq    InitRTL4  ; No more initialized variables
 				  00305
 0213				  00306	InitRTL3
 0213 EC 02		      [6] 00307	         ldd    2,X       ; Load variable value
 0215 ED 04		      [6] 00308	         std    4,X       ; Store variable value
 				  00309
 0217 AE 84		      [5] 00310	         ldx    ,X        ; Point to the next variable
 0219 26 F8 (0213)	      [3] 00311	         bne    InitRTL3
 				  00312
 021B				  00313	InitRTL4
1 Like
169

I just finished the factoring of hex(), oct() and bin(). There was substantial savings due to the amount of common code between the three.

I’ll implement left and right shift, then consider doing another release.

As for retargeting, I am pushing forward on the run-time library for the 8080, 6800 and 6809. The AVR is going slowly because I am so rusty on that instruction set.

It has become obvious that it is much more efficient if I do the retargeting a subroutine at a time on all targets instead of doing one target at a time until it is done. So I will likely add 32-bit and 16-bit x86 and the 68000. And probably ARM; this is as good a time to learn ARM assembly language programming as any since Raspberry PIs are cheap and popular. Someone asked about the Z-80, so maybe that as well even though I do not currently have any Z-80 tools. And maybe the 1802 in Walter’s honor.

2 Likes
170

May I add a request for Texas Instruments TMS9900 processor. No stack, only 3 register, 16 ‘virtual’ registers in 16 consecutive 16-bit memory locations, allowing for fast context switches.

The hardware platform that would be the most popular TI 99/4A Home Computer. There is a huge following at atariage (http://atariage.com/forums/forum/119-ti-994a-development/), where folks are still developing new hardware and software for this platform. There are aftermarket BASIC compilers and several Forth implemenations.

Be advised that due to the architectural quirks of the TI 99/4A, there are only 256 bytes of CPU RAM resident on the standalone console. You would likely need to develop with the assumption that the 32K memory expansion was present.

I would volunteer to be a test candidate for your compiler efforts, although there are several avid folks at atariage that would likely salivate at the opportunity to try python on this platform.

Excellent TI 99/4A technical info website by Dr. Thierry Nouspikel, who started his TI 99/4A work as a student. Very rich source of info.
http://www.unige.ch/medecine/nouspikel/ti99/titechpages.htm

Complete TMS9900/TI 99/4A cross development too suite (written in python)

Some TMS9900 retro fun

1 Like
171

I’ll consider that though I have no experience with the 9900 instruction set beyond knowing what the workspace pointer is.

173

On the TMS9900, other than the Workspace Pointer, there are only two other registers, Status and Program Counter.

A hardware or software interrupt has a two-word vector, a new workspace pointer and program counter. The old workspace pointer, program counter, and status are stored in R13, R14, R15 of the new workspace (possibly not in that order).

The instruction set is quite rich and mostly orthogonal.

This is a two operand machine, the 2nd parameter and the destination are the same

Addressing modes are:

Register immediate: Load or operate with 16 bit source literal

Register indirect: Register has address of operand
Register indirect w/post increment: Register has address of operand, is increment after operation
Register indirect with immediate address offset: Immediate value is added to register contents, resulting value is address of operand. (R0 is a special case)
Absolute address: Immediate address of operand is specified

All of previous addressing modes (except for register immediate) can be used for both source and destination, in any combination.

Non-vectored subroutine calls keep the same workspace, but store the return address in current R11. User must manage temp storage of status or other registers.

Any register (or registers) may be used for a virtual stack pointer. Register indirect w/post-autoincrement can implement either push or pop (depending up which direction stack grows). Unfortunately there is no atomic register indirect w/pre-decrement. There are instructions to increment by two (INCT) or decrement by two (DECT), which when combined with the register indirect addressing mode, can increment a stack in any direction. Register indirect with immediate address offset could be used to access contents of a virtual stack frame.

A rich set of relative jumps (+128 words/-127 words displacement) is provided. A long (16-bit) direct branch is provided, which when combined with relative jumps, allows conditional branching to the full 64 KByte address space.

I learned to program assembly language on this processor, which was a blessing and a curse. Since there was no stack, that was a new thing to learn when moving to any other processor. OTOH, I was really spoiled by the rich instruction set and the availability of 16 16-bit registers, as opposed to the 8-bitters (Z80, 6502, 6800, 8051,…). It would have been relatively easy to move to assembly programming of a 68000 or even an MSP430.

1 Like
174

The TI 99/4A does something similar to the SWEET16, but carries it to an extreme. There is an byte-code language interpreter for a language called GPL (Graphics Programming Language) that is in the console ROMs.

The TI BASIC interpreter is also in the ROM, and the BASIC interpreter is almost wholly written in GPL. This is why TI BASIC is soooo slow - it’s double interpreted. Not only that, but GPL code isn’t stored in normal ROM, but instead in special PMOS (yep, that’s right, PMOS!) ROMs called GROMs (Graphics ROMS). These were basically cheap calculator style memories in 16-pin packages. The GROMS had an 8-bit data bus and 1-bit address bit, which determined whether the access was an address (to set or read a byte of the ROM address) or data (to read from the location pointed to by the internal 16-bit address). As long as data was read from sequential GROM addresses the internal counter would autoincrement after each read. But if data was needed from another non-sequential location, then two bytes of address would have to be written before the new data could be fetched.

As if the above wasn’t enough, the 16K RAM was on the ‘backside’ of the video controller and was accessed in a manner similar to the GROMs. And the tokenized BASIC code and data was stored in the 16K video RAM. So there were two levels of interpretation for lines of BASIC - first to interpret the BASIC token stream, an then each instruction that made up the BASIC interpreter was an interpreted GPL instruction.

According to one of the architects of the 99/4A system, when it was designed the plan was to design a GPL processor chip that would directly execute GPL code. Had this happened the 99/4A would have screamed. But those plans were scrapped very early on.

1 Like
175

And to make that even worse, you had to cross a 16 to 8 bit bus arbiter chip to get form the CPU to the video controller.

2 Likes
176

The story was that bottleneck was named after someone who worked at the Lubbock plant and taught evening classes at Tech. Supposedly, he designed it. The name escapes me. I’ll have to ask my brother.

177

It was really a shame that the world’s first commercial 16 bit processor achitecture in the 99/4 had that speed bottleneck designed into it. The guy’s name wasn’t Paul Cleveland, was it?

2 Likes
178

There were only two devices directly on the 16-bit bus - the system ROM and 128 words (256 bytes) of scratchpad RAM. This was the only directly addressable RAM available without the memory expansion board.

Thus, cartridge software modules, which were almost all required to run on an unexpanded console, only had 128 bytes of directly addressable RAM. This was really a challenge when speedy RAM buffers were needed. In addition to the limitation that the 16K VRAM (video RAM) was indirectly addressed, there were limits on how often the CPU could access the VRAM.

Reading a 16-bit value from the 16-bit bus required 2 clock cycles with no wait states. Reading the same 16-bit value on the 8-bit bus required 6 clock cycles, where 4 wait states were inserted to allow time for two psuedo 8-bit data accesses. When working on PARSEC as a TI intern, one of the techniques we used to increase the software horizontal scrolling speed was to move a small code loop into the 16-bit RAM so it would run faster.

A quirk of the 9900 was that while the data bus was 16 bits, there was no byte select for the case where byte accesses occurred. Consequently, even though a byte instruction might be executing, both psuedo 8-bit bus cycles had to be completed.

To make this even worse, any memory write was always preceded by a memory read to the same address. I was told that this was done to save microcode space in the 9900 by having reads and writes execute the same microcode, with the only difference that the data which was read during a destination write was ignored.

1 Like
179

I wasn’t aware of any name for the 16-to-8 bit bus converter or it being referenced to anyone in particular. My supervisor during my 2nd intern stint (was called a ‘co-op’ position back then) was Granville Ott, who was involved in the early architecture planning for the 99/4 and he did teach some classes at Tech. But no one called it the ‘Ott’ bus.

According to Granville and others, the original plan was not to have a TMS9900 (with 16-bit data bus) in the console. Instead, the CPU was supposed to be a TMS9985, which had an 8-bit bus. The reason for this was to keep the peripheral costs reasonable, as a 16-bit bus would require 2x of peripheral ROM chips and corresponding bus buffers. [ASIDE: the TMS9985 was to the TMS9900 as the 8088 was to the 8086 - architecturally the same but with 8-data buses]

When it became apparent that the 9985 would not be ready in time for the launch of the 99/4, a decision was made to drop in a 9900 with additional logic so that the cartridge interface, peripheral interface, and peripherals would not have to be changed. Otherwise the whole system would have to be redesigned and substantially delay entry into the market. This would have a profound effect later when TI got in a price war with Commodore. Although keeping the 8-bit interface allowed the cartridge and peripheral costs to be as low as possible, the console had much higher costs due the more costly 9900 + additional bus convert logic. The Commodore was using the cheapest CPU available, the 6502, which would still have had a cost advantage over even the 9985. You can guess who won the price wars.

There was an interesting story being told about why the 9985 was not ready. Supposedly the 9985 designer was a brilliant guy but had a very unconventional personality and work flow. His manager tried to make him conform and the designer up and quit on him. None of the other designers were able to take his work and finish it, as the way he had decomposed the problem was apparently too unconventional also.

The TMS9985 was never produced. However, a TMS 9995 was produced, which was similar to the what the 9985 would have been. Even though it also had an 8-bit bus, it had a faster clock, was pipelined, and all of the instructions took less time. As a result, it was considerably faster than the 9900 even though it was on an 8-bit bus. There was also 256 bytes of on-chip RAM, which essentially meant that all registers could be on-chip. The 9995 was used in the 99/4A follow-on console, the 99/8 (code-named Armadillo). To make the 99/8 compatible with 99/4A games which used software delays (no other choice for the software guys), there was a 99/4A emulation mode that introduced wait states in the external memory cycles to better match the slower 99/4A.

2 Likes
180

I’m pretty sure it was not him.

181

The name Ott is vaguely familiar; Granville is not. It would have been known derisively as the “Ott Bottleneck” or something like that.

Did you know a Steve Bell? He was a computer science student who worked part-time at TI testing the system in 82 or 83.

182

I am still looking into the TI 9900 and 99/4A. Some disturbing things are:

  • Incrementing and decrementing affects the carry flag unlike the behavior of most other processors. This wreaks havoc with multi-precision arithmetic code.
  • The TI assembler is brain-damaged with regard to the precedence of arithmetic operators. Multiplication and division are the same level as addition and subtraction. At least I can parenthesize 1+(2*3) but I should not have to.
183

99/4a

Would this one work?

https://www.ebay.com/itm/Texas-Instruments-TI-99-4a-Computer-with-supply-and-switch/263904383358?hash=item3d71ed517e:g:IEsAAOSwYelbhds4

184

A stock 99/4A without some kind of memory expansion will not have enough RAM.

185

Work continues on the run-time libraries for the other processors.

The AddRef subroutine increments the reference count for an object allocated on the heap. It is interesting to see the relative strengths and weaknesses of the several architectures.

The code for the 6502:

 05C3			  00852	AddRef
 05C3 A5 16	      [3] 00853		lda	PtrA			; Invalid if outside of the heap
 05C5 38	      [2] 00854		sec
 05C6 E9 13	      [2] 00855		sbc	#Heap&$FF
 05C8 A5 17	      [3] 00856		lda	PtrA+1
 05CA E9 3C	      [2] 00857		sbc	#Heap>>8
 05CC 90 17 (05E5)  [2/3] 00858		bcc	AddRef_Done		; Do not attempt to count if invalid
 			  00859
 05CE A5 16	      [3] 00860		lda	PtrA			; Point to arena header of the block
 			  00861	;	sec
 05D0 E9 05	      [2] 00862		sbc	#5
 05D2 85 1A	      [3] 00863		sta	Ptr1
 05D4 A5 17	      [3] 00864		lda	PtrA+1
 05D6 E9 00	      [2] 00865		sbc	#0
 05D8 85 1B	      [3] 00866		sta	Ptr1+1
 			  00867
 05DA A0 04	      [2] 00868		ldy	#4			; Get reference count
 05DC B1 1A	    [5/6] 00869		lda	(Ptr1),Y
 05DE 18	      [2] 00870		clc				; Increment the count
 05DF 69 01	      [2] 00871		adc	#1
 05E1 F0 02 (05E5)  [2/3] 00872		beq	AddRef_Done		; If it was the max, leave it there
 			  00873
 05E3 91 1A	      [6] 00874		sta	(Ptr1),Y
 			  00875
 05E5			  00876	AddRef_Done
 05E5 60	      [6] 00877		rts

The code for the 8080:

 02C6			  00757	AddRef
 02C6 2A 003E	     [16] 00758		lhld	PtrA			; Load address of the block
 			  00759
 02C9 7D	      [5] 00760		mov	A,L			; Invalid if outside of the heap
 02CA D6 03	      [7] 00761		sui	Heap and 0FFh
 02CC 7C	      [5] 00762		mov	A,H
 02CD DE 04	      [7] 00763		sbi	Heap shr 8
 			  00764
 02CF D8	   [5/11] 00765		rc				; Do not attempt to count if invalid
 			  00766
 02D0 2B	      [5] 00767		dcx	H			; Point to the reference count
 			  00768
 02D1 7E	      [7] 00769		mov	A,M			; Increment reference count
 02D2 3C	      [5] 00770		inr	A
 			  00771
 02D3 C8	   [5/11] 00772		rz				; If it was the max, leave it there
 			  00773
 02D4 77	      [7] 00774		mov	M,A			; Update reference count
 			  00775
 02D5 C9	     [10] 00776		ret

The code for the 6800:

 0261			  00437	AddRef
 			  00438	 ; Note: 6800 cpx instruction faulty!
 0261 96 15	      [3] 00439	         ldaa   PtrA+1    ; Invalid if outside of the heap
 0263 80 F7	      [2] 00440	         suba   #Heap&$FF
 0265 96 14	      [3] 00441	         ldaa   PtrA
 0267 82 02	      [2] 00442	         sbca   #Heap>>8
 			  00443
 0269 25 0A (0275)    [4] 00444	         bcs    AddRef_Done ; Do not attempt to count if invalid
 			  00445
 026B DE 14	      [4] 00446	         ldx    PtrA      ; Point to the reference count
 026D 09	      [4] 00447	         dex
 			  00448
 026E A6 00	      [5] 00449	         ldaa   ,X        ; Increment reference count
 0270 4C	      [2] 00450	         inca
 			  00451
 0271 27 02 (0275)    [4] 00452	         beq    AddRef_Done ; If it was the max, leave it there
 			  00453
 0273 A7 00	      [6] 00454	         staa   ,X
 			  00455
 0275			  00456	AddRef_Done
 0275 39	      [5] 00457	         rts

The code for the 6809:

 023F				  00406	AddRef
 023F 9E 14		      [5] 00407	         ldx    PtrA      ; Load address of the block
 				  00408
 0241 8C 02CF		      [4] 00409	         cmpx   #Heap     ; Invalid if outside of the heap
 0244 25 07 (024D)	      [3] 00410	         bcs    AddRef_Done ; Do not attempt to count if invalid
 				  00411
 0246 A6 1F		      [5] 00412	         ldaa   -1,X      ; Increment reference count
 0248 4C		      [2] 00413	         inca
 				  00414
 0249 27 02 (024D)	      [3] 00415	         beq    AddRef_Done ; If it was the max, leave it there
 				  00416
 024B A7 1F		      [5] 00417	         staa   -1,X
 				  00418
 024D				  00419	AddRef_Done
 024D 39		      [5] 00420	         rts

The code for the AVR:

 0000B4			  00158	AddRef:
 0000B4 91E0 0100     [2] 00159		lds	R30,PtrA		; Load address of the block
 0000B6 91F0 0101     [2] 00160		lds	R31,PtrA+1
 			  00161
 0000B8 E061	      [1] 00162		ldi	R22,high(Heap)		; Invalid if outside of the heap
 0000B9 30EC	      [1] 00163		cpi	R30,low(Heap)
 0000BA 07F6	      [1] 00164		cpc	R31,R22
 			  00165
 0000BB F428=0000C1 [1/2] 00166		brcc	AddRef_Done		; Do not attempt to count if invalid
 			  00167
 0000BC 9731	      [2] 00168		sbiw	R30,1			; Point to the reference count
 			  00169
 0000BD 8010	      [1] 00170		ld	R1,Z			; Increment reference count
 0000BE 9413	      [1] 00171		inc	R1
 			  00172
 0000BF F009=0000C1 [1/2] 00173		breq	AddRef_Done		; If it was the max, leave it there
 			  00174
 0000C0 8210	      [1] 00175		st	Z,R1			; Update reference count
 			  00176
 0000C1			  00177	AddRef_Done:
 0000C1 9508	      [2] 00178		ret
1 Like