wAx: Wedge Assembler/Disassembler

[chysn]

I actually used the TOP instruction in the latest wAx release. When I first went through my JSR/RTS optimizations, I had several subroutines like this:

Code: Select all

Space:      lda #" "
            jmp CharOut
            

A five-byte subroutine like this needs to be used three times before realizing any savings, and then, it's only one byte. But this weekend, I used TOP for characters in the same way that the KERNAL uses BIT for I/O errors:

Code: Select all

; Commonly-Used Characters
CloseParen: lda #")"
            .byte $0c           ; TOP (skip word)
Comma:      lda #","
            .byte $0c           ; TOP (skip word)
Space:      lda #" "
            .byte $0c           ; TOP (skip word)
HexPrefix:  lda #"$"
            jmp CharOut

Each character routine is 3.5 bytes (14 bytes to handle 4 characters), so this can be effectively used for any character that needs to be added more than once in the code (which turns out to be the four characters above).

I can see myself doing this a lot.

[Mike]

I can see myself doing this a lot.

I can't see where the function this construct critically depends on the use of $0C instead of BIT, and users of a 65C02 in their VIC-20s will probably be unhappy about this.

[chysn]

I can see myself doing this a lot.

I can't see where the function this construct critically depends on the use of $0C instead of BIT, and users of a 65C02 in their VIC-20s will probably be unhappy about this.

Indeed, I don't want to go randomly sniping at memory. Although the Venn diagram of 65C02 users and wAx users will surely look like Bette Davis's face in low light--two circles separated by vast space--I think that $3c is going to be the better bet. For regular 6502, $3c is another TOP (Absolute,X). For 65C02, $3c is BIT (Absolute,X). It should fit in quite nicely.

Likewise, $34 is the "skip byte" version, being DOP (Zeropage,X) for 6502 and BIT (Zeropage,X) for 65C02.

My reason for planning to use these, incidentally, is purely aesthetic, allowing the disassembly of memory to more closely match the source code. I spend quite a bit of time looking at disassembly of my code in memory.

[Noizer]

@ chysn and Mike: Could the Wax image fit into Minimon eprom?

[chysn]

@ chysn and Mike: Could the Wax image fit into Minimon eprom?

I have it on 2716 EPROMs. I've got two 3K (VIC-1210) carts where it's located at $6000, and an 8K cart (VIC-1110) where it's located at $5800*. My understanding is that Minimon is at $9800, so you'd just need to re-assemble with *=$9800 at the top and burn that image onto a 2716.

However, you can only use the extended opcode table if wAx is in RAM, because the 6502X table needs to overwrite the "end-of-table" marker and add another couple hundred bytes.

I'm working on a 4K version (for either 1x2732 or 2x2716) that will have the illegal opcode support built in (you use , instead of . to disassemble those opcodes), as well as more flexible Immediate mode operands (lda #"c" for characters or ldy %11111111 for binary), 8-bit binary editor, search tool (hex, text, and code), tri-directional (hex, base-10, binary) converter, etc. But I'm in no hurry for this, as the 2K version is working for me right now.

* This was an error; I soldered my socket into U8 instead of U5 and decided to just run with it.

[Mike]

@ chysn and Mike: Could the Wax image fit into Minimon eprom?

The ZIF socket of the VIC-2020 MINIMON cartridge accepts a 2716 EPROM (or equivalent), or a 6116 SRAM.

You can use any other tool in place of the original firmware (i.e. MINIMON), as long as it doesn't exceed a size of 2 KB and resides in the $9800..$9FFF address range, because that's where the cartridge hardware maps in the memory chip.

That being said, MINIMON and wAx are separate projects. I can though easily imagine chysn would also like to use wAx with this cartridge, by assembling wAx to $9800 and burning it into an EPROM.

[chysn]

That being said, MINIMON and wAx are separate projects. I can though easily imagine chysn would also like to use wAx with this cartridge, by assembling wAx to $9800 and burning it into an EPROM.

I'm still hoping to get a Minimon cartridge one day. For one thing, I plan to make other wedges, and wAx really can't be used effectively to develop wedges. And I'm sure as hell not dusting off VICMon any time soon.

[chysn]

Here are a couple of the upcoming features for wAx 4K. I'll have space for 4K in the ROM slots (either a single 2732, or across a pair of 2716s on the 8K cartridge). I don't plan on going crazy with new tools, but I want to kind of flesh out the existing ones with useful features. For example:

Binary Dump. There's something fun about watching huge characters scroll by: https://youtu.be/QOxLhADteb0

Binary Editor. I struggle as an artist, and it'll be nice to edit characters on the fly: https://youtu.be/lmffw64FcbA

Immediate Mode Operands. It takes me out of my zone when I have to look stuff up: https://youtu.be/ufFYmJqARYg

Illegal Opcode Disassembly (optional). See the world with a new perspective! https://youtu.be/vqe5_8SvIKs

[chysn]

I'm working on the 4K version of wAx, with the idea that it will be a "somewhat-symbolic assembler." I thought it would be cool if you could write code with BASIC without needing to always know the address. After all, BASIC lets you just insert lines (provided you left yourself numerical space).

The idea here is that the current program counter can always be expanded into your code with the asterisk. You can set the PC up front, as you would with a cross-assembler. And then, because you may no longer know your addresses, you can use labels for bi-directional resolution. In the proof-of-concept you're limited to ten labels (&0 - &9), and only one forward reference address per label*. But for typing in short routines, it'll be helpful.

See the screenshot below for an example.

And then, oh no! We've left out some lines. No need to slog through every line fixing addresses now, though!

I've also added the base-10/binary/hex converters and a memory copy utility. I have 1K left.

* You can overcome this limitation by doing two passes with the assembler.

[Noizer]

As I said before, master skills! I hope sometime to replace that moody horse of vicmon with an honor successor.

[chysn]

I've spent a lot of time thinking about the form that label definitions would take. I considered everything from staying with the original concept (ten labels 0-9, with each having one address and one forward reference), all the way up to dynamic labels of up to four characters. I considered single-character label names as aliases for 0-9, and a whole bunch of other things. Ultimately, though, the label system was guided by the following principles:

(1) Low memory footprint. A dynamic four-character table would grow pretty fast. I wanted the table to be unobtrusive, preferably under 64 bytes.
(2) Expendable. I didn't want it to be necessary for the symbol table to be retained in memory after assembly. It should be easy to clear out and start over. If you don't use the symbolic features, the symbol table memory will never be accessed.
(3) Visually distinct from code
(4) Low or zero necessity for error messages
(5) If the label set is small, label redefinition should be easy and meaningful

The current--and probably final--system is as follows:

* There are ten labels for symbols, 0-9, prefixed with - (minus). The minus sigil is used by xa for labels, so it's recognizable (to me) as a label.
* The labels can be used as forward or backward references
* Up to eight forward references can be unresolved at a time
* Each label can be used as a forward reference any number of times (up to eight)
* When a symbol's address is resolved, it releases one of the eight forward reference records
* Re-defining a label is possible. I would tend to re-use -0 for local loops, as I use -loop in xa
* The forward reference resolution checks the addressing mode of its instruction so it can resolve symbols for relative branches, absolute and indirect code, and immediate instructions, while throwing errors for implied mode and unrecognized instructions.
* For immediate or zeropage (including ,X and ,Y) mode instructions, you can specify H or L after the label (again, for both forward and backward references)

I added another feature, which allows you to chop up your memory into BASIC staging areas as you see fit. I plan on having my main program under development at $1000, but I'll have BASIC tests or utilities in other places in Block 5, where I'll have 8K. I'm providing a way to switch BASIC on the fly.

Anyway, here's a demo of forward reference resolution with immediate mode, high and low. Obviously, if the setup routine were longer, you could see the practicality.

Of course, you can always define symbols directly like this, although I don't see me doing it this way very much. Note that you can relocate this code by changing *nnnn at the beginning. The * in line 5 initializes the symbol table. This is what I meant when I said it must be "expendable."

This weekend I'll be spanning this across a pair of 2716s for insertion into an 8K RAM cartridge

[chysn]

Three updates this evening:

(1) I did wind up using label aliases for symbols. So now, instead of being stuck with just 0-9, you can also use A-Z as labels. Just a bit more flexibility, without really giving anything up. There's also a special label @, which, rather than being dynamically-allocated like other symbols, is always tied to a constant index. This means that @ is always available, even if you've used up the symbol table entries.

(2) There's an additional label definition syntax that allows you to put code right after a label definition, without it needing to be on a separate line. This is really just syntactic sugar that makes label definition more like a cross-assembler. See the screenshot below. The original separate-line syntax is still valid also.

(3) I added a way to view the symbol table. It'll show all of the labels in use, with their addresses (or indicate unresolved forward definitions). It also shows the current value of * (meaning, the address you'll write to with @*)

[Noizer]

neverending coding

[chysn]

neverending coding

It's my VIC-20 magnum opus. And it's going to affect everything else I make for the VIC-20, probably forever, so it needs to be well-honed. And if I don't do what I want to do now, while I know the code really well, it won't be any easier later. And, I'm not exactly going out and doing things these days.

Pretty much all I did last night was round out the BASIC test suite with the Somewhat Symbolic features, so I can make sure I don't introduce bugs in the assembler as I go along.

[chysn]

All right, I'm done! "Done" here means that I hit 4096 bytes.

The last feature was one I've been mulling for a while. I'm on the electronic record insisting that assemblers should accept both implicit and explicit forms of accumulator addressing, so I needed to do this in order to avoid being a big hypocrite. I updated the 6502 table to differentiate between implied mode and accumulator mode, and I allow either MNE A or MNE for the four instructions with accumulator mode.

The disassembler shows A for accumulator mode, because that's my preferred syntax.