wAx: Wedge Assembler/Disassembler

[chysn]

I'm not yet sure whether this falls under the category "dumb gimmick" or "useful tool." I'm going to work on it a bit more and see how interested I continue to be.

wAx is a wedge assembler for the VIC-20. It jacks into GONE and grabs characters after a dollar sign ($), and assembles instructions in quotes. Machine language can thus be assembled in BASIC runtime, or directly on the command line. A short sample session is below.

I still need to implement some addressing modes (indirect modes are left), and I'll make the GitHub repo public once it's handling all 6502 instructions. Instructions have to be in quotes because some of them (AND, EOR, ROR, ORA) involve BASIC keywords. I can look for tokens, of course, and I might do that later.

It should weigh in at less than 1K when it's done. I may or may not do a wedge disassembler. It might be educational for me. But I'm encoding the instructions in a weird way to save memory, so there would be some refactoring. Really, a disassembler would be more useful to me than an assembler, and I kind of like the idea of not having to SYS into a different environment when diagnosing issues with ML programs.

wAx might be absurd, but it's been a fun Saturday diversion.

[chysn]

Yeah, I'm totally going to do a disassembler.

I was resigned to having to add a fourth byte for each instruction in my data table. I had 12 bits for instruction encoding, plus four bits to store the addresssing mode, and eight bits for the actual opcode. I figured that, to add real mnemonics, I'd need five bits per letter, for a total of 15 bits. Then I'd need 12 more for addresssing mode + opcode, for a total of 27 bits, meaning that I'd have no choice but to add another byte to the table for every instruction table entry (150 of them).

I looked for ways to reduce this. I was hoping that maybe all the letters weren't used, so I checked. Unfortunately, 21 of 26 letters are used in 6502 instructions. So then I checked on a per-position basis and found that each position only uses 14 letters! By "position" I mean that each instruction has 3 positions (LDA's positions are 0=L, 1=D, and 2=A). So, I need to have three different character tables, but I can represent each instruction's letters in only 12 bits. Sweet!

I'm hoping that there are no encoding collisions with this technique. If there are, I can probably solve this by re-ordering one or more of the tables. I'm excited about this discovery because I can do a disassembler without having to add another 150 bytes of data. I can add 42 bytes of data instead. And, it's going to be more elegant, which I like.

But mostly, this encoding is bi-directional, which means: wedge disassembler!

[chysn]

Update: Due to some typos in the instruction list at masswerk, from which I'm scraping my 6502 data, it turns out that my numbers of positions were a bit off. The second position actually has 18 characters in use, which kind of shoots my first plan down.

However, if I look at how many two-letter combinations START instructions, there are 34 of those, which can be represented in 6 bits. Then, the third position uses 15 characters for four bits. So now I can encode each instruction's mnemonic bi-directionally in 10 bits. Downside is that I now need an 83-byte data table, but I can live with that unless I think of a better idea.

Update again: I don't need an 83-byte data able, though. I can chain tuplets (two characters described by a single data point) together in such a way that the end of one tuplet is the beginning of another. For example, the table

ASEORTANOADEBPLSBMTXCMCPHBCLDBNJMTSTYBINBEBVBROJS

can be used to locate the first two characters of any 6502 instruction, and it takes only 49 bytes. Then there are 15 possibilities for the third character, for a total of 64 bytes of encoding table space. 49 might be the smallest-possible such table, but I've got a program working on that question.

[pixel]

This is the simplest version of a disassembler I was able to think up: https://github.com/SvenMichaelKlose/ben ... ssembler.c . It's using an opcode-indexed table https://github.com/SvenMichaelKlose/ben ... code-map.c but in return the print function couldn't get any dumber (or smaller therefore). Perhaps it's an inspiration.

[chysn]

Here's a video demo. Features now include

* Disassembly
* Assembly
* Breakpoint Management
* Memory Hex Dump

wAx is zero-page neutral. It restores all locations that it uses, except for $07, which isn't sacred to anyone.

Thanks to this forum's own Mike for his generous counsel on several critical issues.

https://www.youtube.com/watch?v=3jd9iyUHqZY

Edit: The above is an updated video. It's two minutes shorter than the other one, and shows the hex editor. Also, I'm sort of getting my sea legs with VICE, not making as many hunt-and-peck typing errors.

[R'zo]

This is awesome!
Beautiful work.

Thank you.

[chysn]

This is awesome!
Beautiful work.

Thank you.

Thanks! I'm kind of going through and re-writing it now that it's working This process always makes it temporarily stop working, but makes it more efficient in the end. Once this is done, I'm going to use it to make a game, and work out bugs and stuff. After I've whaled on it for a while, and know it's stable, I'll make it available to anyone who wants it under a Creative Commons license.

[Schlowski]

That's impressive! Powerful and yet simple, I like it very much.

[Noizer]

Here's a video demo. Features now include

* Disassembly
* Assembly
* Breakpoint Management
* Memory Hex Dump

wAx is zero-page neutral. It restores all locations that it uses, except for $07, which isn't sacred to anyone.

Thanks to this forum's own Mike for his generous counsel on several critical issues.

https://www.youtube.com/watch?v=DbP5MwXhByA

Very nice. As one can see in the video, illegal opcodes show question marks.
Would be great if one would get the decoded display.

[chysn]

Very nice. As one can see in the video, illegal opcodes show question marks.
Would be great if one would get the decoded display.

Love it! I'm doing that. I'm assuming by "decoded display" you mean "the hex value of the unknown opcode."

Since the video, I added a couple other features. I added a hex editor, since all the building blocks were in place and it took about 50 bytes. Also, you can keep the code or memory listings going by holding down shift. Or you can engage shift-lock and watch code fly by forever.

[chysn]

Very nice. As one can see in the video, illegal opcodes show question marks.
Would be great if one would get the decoded display.

As I ponder it further, it's possible that you're wondering if this could actually support illegal opcodes for assembly and disassembly. The short answer is "absolutely."

The only barrier is knowing what to add. I did not generate my instruction table by hand; that would have been tedious. I wrote a program to scrape data from the mass:werk 6502 Instruction Set web page and generate the table for me. Mass:werk's list is littered with errors, which you don't notice until you try to generate data from it.

But I could certainly add instructions if I know the name, opcode, and addressing mode. It adds three bytes to the table size for each new instruction. And it's something I really don't know much about. When I was a kid, my friends and I found a couple functioning "illegal" opcodes on our middle school's C64s. We gave them names and tried to find uses for them. But now you've got 65C02 opcodes, too, and I'm kind of lost. I'm pretty old-school here, is what I'm saying.

TLDR; Yeah, it's possible, but I don't have a great background in it. If that was even your question

[chysn]

I'm reading up on this topic. It's crazy. It's like I used to feel when they released a new Magic set. "Woah, AAX is so powerful! It operates on two registers with one instruction! Ban it!"

I think I need some input, though, to know what assembler/disassembler support would look like. I'm thinking that I'd just make different tables available for installation. Like, I'd have a plain 6502 version of wAx, and then extended tables that you LOAD"65C02",8,1 to add additional instructions. The additional file would just drop itself in at the memory location at the stop byte of the 6502 table....

[Noizer]

Very nice. As one can see in the video, illegal opcodes show question marks.
Would be great if one would get the decoded display.

As I ponder it further, it's possible that you're wondering if this could actually support illegal opcodes for assembly and disassembly. The short answer is "absolutely."

The only barrier is knowing what to add. I did not generate my instruction table by hand; that would have been tedious. I wrote a program to scrape data from the mass:werk 6502 Instruction Set web page and generate the table for me. Mass:werk's list is littered with errors, which you don't notice until you try to generate data from it.

But I could certainly add instructions if I know the name, opcode, and addressing mode. It adds three bytes to the table size for each new instruction. And it's something I really don't know much about. When I was a kid, my friends and I found a couple functioning "illegal" opcodes on our middle school's C64s. We gave them names and tried to find uses for them. But now you've got 65C02 opcodes, too, and I'm kind of lost. I'm pretty old-school here, is what I'm saying.

TLDR; Yeah, it's possible, but I don't have a great background in it. If that was even your question

Here we go: https://csdb.dk/release/?id=185341
There is no difference between c64 illegal opcodes and vic 20 one. It's the same processor- after all - I coded some fantastic things with that knowledge.

[chysn]

Here we go: https://csdb.dk/release/?id=185341
There is no difference between c64 illegal opcodes and vic 20 one. It's the same processor- after all - I coded some fantastic things with that knowledge.

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

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

[Noizer]

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