wAx: Wedge Assembler/Disassembler

[chysn]

Thanks! I'll start working on an addendum to the table.

Are there differences between undocumented opcodes for the original 6502 versus the 65C02?

It's on the preface of that paper

Noizer, I appreciate your guidance on this. Please see the following one-minute demo:

https://youtu.be/DYRWQkK7uWc

[Kweepa]

This looks amazing!
Great work making it operate seamlessly in BASIC!
I was especially impressed by the breakpoint features.

[chysn]

This looks amazing!
Great work making it operate seamlessly in BASIC!
I was especially impressed by the breakpoint features.

Breakpoints are super-important to me, so I spent a ton of time thinking about what I wanted in a functional and considerate breakpoint management system. I'm happy that you noticed it. I'll be writing the documentation this weekend, and I expect that more than half the document is going to be dedicated to the BRK handler.

On a related note, if I have only one word of advice for anybody who wants to write a direct assembler or language in the future: Make the breakpoint system the first system you do! For me, it was the third system. Once I got to the memory dump feature, and was using wAx to debug issues in wAx, I was like, "Oh, yeah, I totally did that in the wrong order."

[Noizer]

Noizer, I appreciate your guidance on this. Please see the following one-minute demo:

https://youtu.be/DYRWQkK7uWc

Wow! Never saw before undocumented opcodes assembled so easy - on vic 20 screen. Master skills, Respect!

[chysn]

Noizer, I appreciate your guidance on this. Please see the following one-minute demo:

https://youtu.be/DYRWQkK7uWc

Wow! Never saw before undocumented opcodes assembled so easy - on vic 20 screen. Master skills, Respect!

Thanks. I think it's just that most on-screen assemblers were written before anybody cared about undocumented instructions, rather than any particular skill on my part.

[chysn]

Here's a new video demonstrating the use of wAx with BASIC to generate unit tests for a machine language subroutine.

https://www.youtube.com/watch?v=ej9Uhqg ... e=youtu.be

The subroutine in question is from Leo J. Scanlon's 6502 book, and is below. I've modified it to take the X and Y registers as the low and high address, and the Accumulator as the list size, in order to demonstrate how registers are set within a BASIC unit test. After the test is done, wAx can be used to create and test assertions with the = command.

Code: Select all

; 8-Bit Bubble Sort Subroutine
; Ascending
; 
; Adapted from Example 4-4, 6502 Software Design, Leo J. Scanlon, 1980
;
; Preparations:
;   X = List low byte
;   Y = List high byte
;   A = List length

* = 1800
List        = $00               ; Location of list (2 bytes)
Size        = $02               ; Size of list
Exchange    = $03               ; Swap flag, indicates at least one swap

SortAsc:    stx List
            sty List+1
            sta Size
sort8:      ldy #$00
            sty Exchange
            ldx Size
            dex
nxtel:      lda (List),y
            iny
            cmp (List),y
            bcc chkend
            beq chkend
            pha
            lda (List),y
            dey
            sta (List),y
            pla
            iny
            sta (List),y
            lda #$ff
            sta Exchange
chkend:     dex
            bne nxtel
            bit Exchange
            bmi sort8            
            rts

[chysn]

I thought I had posted the link to the repo, but maybe not: https://github.com/Chysn/wAx

[Mike]

Even I am guilty of having provided a Bubblesort to sort fixed-length strings, which then went into nbla000's file browser.

Nowadays, I only would want to implement an Insertion Sort anymore, even though I then always need to refer to a blueprint:

Code: Select all

10 N=100:DIMA(N)
11 FORI=1TON:A(I)=RND(1):NEXT
12 :
13 T1=TI
14 :
15 FORI=2TON:A=A(I)
16 FORJ=I-1TO1STEP-1:IFA(J)>ATHENA(J+1)=A(J):NEXT
17 A(J+1)=A:NEXTI
18 :
19 T2=TI
20 :
21 FORI=1TON:PRINTA(I):NEXT
22 PRINT:PRINTT2-T1

(... note the NEXTI in line 17 pops the dangling NEXT in line 16 in case the IF statement isn't executed ...)

Not much difference in code size, but it's generally faster at least by a factor of 2, as the swapping action to place elements is replaced by a shift action in the array, which generally halves the number of array accesses. However, getting the indexing right is slightly more complicated.

Of course, both algorithms share the run-time complexity of O(n²), but Insertion Sort is certainly o.k. for arrays less than 20 elements. For anything bigger, there's also an implementation of Quicksort available in the drawer.

[chysn]

Nowadays, I only would want to implement an Insertion Sort anymore, even though I then always need to refer to a blueprint:

I pretty much turned to a random page in Scanlon's book to grab a subroutine to write a unit test for. I've been asking myself the question, What can you do with a machine language monitor that can run its commands in BASIC programs? Data loading was one answer, as the Hex Editor is way, way faster than DATA statements. And so assertions were a natural next step.

And often, I just need to know if my pointer got set right, or if a flag is set, and something like

Code: Select all

=00fa 80

will tell me that quickly.

The tricky thing is that addresses of routines are constantly changing. So with every build, I have xa output a symbol table, which I can grep. Real unit tests will involve INPUT A for SYS A later.

[Mike]

I've been asking myself the question, What can you do with a machine language monitor that can run its commands in BASIC programs?

This is what I am doing with the inline assembler of BBC BASIC all the time, and how it also already was implemented with pretty much any symbolic assembler that used the BASIC editor of a CBM 8-bit machine in those times: they just took your wedge assembler a step forward and endowed the operands with symbolic addressing.

With the relatively simple method of two-pass assembly, the first pass establishes all labeled addresses, and the second pass then assembles the code with the correct addresses. Fixed addresses outside your code, especially those in ZP, are assumed to be assigned to before the code body starts. This needs just a minimum effort in the expression parser: '+' and '-' to calculate offsets and '<' and '>' to derive low- and high-byte of an address are sufficient for 99% of most cases.

Data loading was one answer, as the Hex Editor is way, way faster than DATA statements.

Hmm... I don't think a DATA loader would be sooo slow. Having somewhat plain-text assembly code in a BASIC listing is a more reasonable achievement (compared to a DATA number desert). But then, off-line documentation serves a similar purpose.

The tricky thing is that addresses of routines are constantly changing. So with every build, I have xa output a symbol table, which I can grep.

Now imagine you don't have the luxury of a cross-assembler at hand, and are just sitting with your VIC-20 + native tool on a party. Then you need to organize your work flow in a way addresses are *not* constantly changing (or, at least, only once and then, when doing major changes).

[chysn]

Now imagine you don't have the luxury of a cross-assembler at hand, and are just sitting with your VIC-20 + native tool on a party. Then you need to organize your work flow in a way addresses are *not* constantly changing (or, at least, only once and then, when doing major changes).

It took me a while to be convinced (by you, as it happens) that a cross-assembler was the way to go, and I can't imagine going back for anything bigger than a few hundred bytes. I honestly don't even remember how I wrote machine language code when I was a kid. Somehow I got things done, but it must have been miserable and I've blocked out all memory of it.

But I do know that when I'm dealing with code on the VIC, that the symbol table is in my head, and I know where everything is.

wAx is a partner for a cross-assembler, not an alternative to one. It doesn't even natively save to disk, because that's outside its scope. I need something to help find the bugs, and I need to make sure that I don't break things trying to fix things.

[Mike]

It took me a while to be convinced (by you, as it happens) that a cross-assembler was the way to go, and I can't imagine going back for anything bigger than a few hundred bytes.

That's why I followed up my last remark with a wink smiley.

I honestly don't even remember how I wrote machine language code when I was a kid. Somehow I got things done, but it must have been miserable and I've blocked out all memory of it.

By hand, on paper. Working out the branch offsets manually. Transferring the opcodes into decimal numbers. Into DATA lines. The size of the resulting code I wrote this way topped out at probably ~100 bytes.

With TEDMON (on the C116 and C128), I would write small utility routines to speed up BASIC programs with a size of around 1 KB each. Kicking my butt when I forgot an instruction and had to insert it later. Sometimes I was lucky and the relevant code snippet did fit on one screenpage, then TEDMON's auto-incrementing A prompt would do a great deal of the job. Otherwise, I'd use the T command to open the necessary space for the new instruction(s) and fix operands and branches in a second step.

As alternative, one could align sub-routines (and tables) at, say, 64 byte boundaries and pad them with NOPs. Or use knapsacks. These two methods are a tell-tale sign of code written in a monitor.

But I do know that when I'm dealing with code on the VIC, that the symbol table is in my head, and I know where everything is.

The nice thing is, the RAM size of the unexpanded VIC-20 roughly corresponds to the size of the 'scratchpad memory' of the human brain. Means, one can keep the equivalent of a written page of paper up and active while working on suchalike stuff. Anything beyond that requires one to keep notes on paper.

wAx is a partner for a cross-assembler, not an alternative to one. It doesn't even natively save to disk, because that's outside its scope. I need to find the bugs, and I need to make sure that I don't break things trying to fix things.

O.K.

[chysn]

The nice thing is, the RAM size of the unexpanded VIC-20 roughly corresponds to the size of the 'scratchpad memory' of the human brain. Means, one can keep the equivalent of a written page of paper up and active while working on suchalike stuff. Anything beyond that requires one to keep notes on paper.

That's interesting. That's probably why it seems like I'm psychologically hard-wired to love the VIC.

[chysn]

I freed up some memory this weekend by shaving a some bytes off the 6502 table, and rebuilding the assembler to be smaller and faster. I used most of the reclaimed bytes to make better error messages and better error handling. When I was done, I had enough left over to add a text editor tool:

https://youtu.be/-_hOUeXsGiE
https://github.com/Chysn/wAx/wiki/4-Memory-Editor

The value of a text editor for a debugging tool is that you can more easily fill buffers with data you need for testing. I always thought the lack of such a thing in VICmon was a bewildering oversight. I guess you put in the tools you value. I had a code search system, but I scrapped it when I realized that the text editor would be a better use of 50 bytes.

[Noizer]

...

PM sent - I guess ... sometimes the outbox gets stuck here, is that normal?