Now that I seem to have gotten most (if not all) hardware matters settled with POC V1.0, I've been working on an updated design called POC V2.0. This update retains much of the original's circuitry but adds an expansion port, which I plan to use to test a SCSI host adapter design I'm concocting. Also, I changed the MAX238 transceiver from a PDIP to a small outline package and replaced the 5-/14 inch floppy disk drive power connector with the smaller Berg type used on 3-1/2 inch floppy drives.

Here's a picture of POC V2.0's board layout. Overall dimensions are 6 inches by 3-3/16 inches. As with POC V1.x, this is a four-layer board.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I finally got around to finishing the assembler part of the machine language monitor. My original plan was to adapt an older assembler I had written for the 65C02. However, due to the substantially greater number of addressing modes available with the '816, as well as the possibility of 16 bit immediate mode operands, the 'C02 code proved to be inadequate. It turned out that scratch-writing a new assembler was less time-consuming than trying to rework the older code.

The core of the assembly process is a set of data tables to translate mnemonics and addressing mode symbology to actual machine instructions and vice versa. Two of the tables are compressed mnemonics in opcode order (i.e., the first entry in each table corresponds to BRK). This is the old "compress three ASCII characters into 15 bits" trick, so that BRK becomes 1C D8 (big endian order), with the 1C value being byte zero in one table and the D8 value being byte zero in the second table. Here's a subset of the two tables:


A third table, also arranged in opcode order, contains addressing mode and instruction size data, with a one-to-one correspondence to the mnemonic tables. I used the following format for that table:


Additional tables point to the symbology that is recognized by the assembler, for example "(),X" or "(,S),Y". The index into these tables is derived from the addressing mode bits of the above.

If an immediate mode instruction's addressing mode data has bit 7 set, the assembler will assemble a 16 bit operand if entered. For example, LDA #$34 would assemble as A9 34, as would be expected. LDA #$1234 will assemble as A9 34 12. However, LDA #$0034 will assemble as A9 34, even though entered in 16 bit format. If a 16 bit operand is desired even though the MSB is zero, it can be forced by coding LDA ^#$34 or LDA ^#$0034, either of which will assemble as A9 34 00. Immediate mode instructions such as REP and SEP do not have bit 7 set in their addressing mode data, so an instruction such as SEP #$1234 will cause an error.

It's entirely possible that a more efficient method exists to do the translation, but this does work and the data tables in all consume 816 bytes. The disassembler uses the same set of tables to do its work. The assembler code itself consumes 355 bytes, not counting support subroutines, all of which are used in more than one place in the monitor.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Would you be willing to share your assembler/disassembler for the 65C02? When I get my keyboard and display working on the PWA, I would like to program directly on the PWA, instead of burning a 512K EEPROM every change I make!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Nicely done!

Yes, but it will involve more than a little work to do so.

The assembler/disassembler is actually part of a machine language monitor that I developed under contract years ago for the BIOS ROM of an SBC that was used as an intelligent terminal server. Because of this, there are a number of software dependencies that would have to be resolved. In particular, the code that disassembles and displays an instruction or dumps memory makes use of terminal control sequences for such things as clearing to the end of a line, turning on or off reverse video, etc. Changing those to suit your application, as well as providing subs to perform primitive terminal I/O (specifically getting or putting a character), would be required. All of the I/O stuff exists in the BIOS ROM, of course, but naturally is hardware-dependent.

Also, the assembler/disassembler as written doesn't recognize the BBRx/BBSx/RMBx/SMBx instructions that the 'C02 understands (but are absent on the '816). I never found a good use for those instructions, so I simply ignored them.

There are other issues that would have to be addressed to make the monitor work outside of the environment for which it was written. They can be resolved but will, of course, require time to work out.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks. If a Big Dumb Dinosaur with claws instead of fingers can do it, anyone can, even Bill Gates!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The code's ancestry goes back to the NMOS 6502, so I didn't have the bit-branch instructions anyhow. When I got the commission to do the terminal server I hastily added the new 'C02 instructions that I knew would be useful, like STZ and PHY. Since all of the I/O code was interrupt-driven and didn't use ZP for anything except indices and pointers, I didn't even consider the bit-branchers. Of course, they aren't in the '816 at all, so it's oh well!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Ah, I see. That's ok then. I have an old atari book that has a disassembler in machine code. I'll do more research when the time comes. At least I'll know who to come to when I need advice. Man I wish I could adapt Micromon from the old C-64 days!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I'm pretty sure the source code for Jim Butterfield's Supermon 64 is floating around somewhere. Only thing is a comment would die from sheer loneliness in the source. Sir James wasn't one to expend too many keypresses in that area.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I have in fact adopted my old C64 machine language monitor (including assembler/disassembler, for NMOS6502 only though) to the PET, as well as to my selfbuilt operating system (the latter shows how to emulate the CBM's OS functions). xa65 source code is available. I'll dig it up if needed or you'll have a look at http://www.6502.org/users/andre/osa and dig it up yourself

André

My SBC-2 and SBC-3 both have a disassembler - 65C02 opcodes on the SBC-2 and 65816 on the SBC-3.

In addition, the SBC-2 has a mini-assembler, very similar to the Apple ][ mini-assembler, that supports the 65C02 opcodes. Mini means it will assemble opcodes and hexidecimal values - no labels or variables are supported. Branch instructions are entered using the target address, so it will compute the proper offset.

If desired, an assembly source could be sent via the RS-232 port and the assembler will assemble it on the fly into RAM. It does not use handshaking so a plain text transfer is done with inter-character and inter-line delays in the terminal emulator.

Source code would look something like this:



Crude, but effective for simple routines or quick test code.

Sources are on my website - look in the Downloads tab under sbc2os.zip and sbc3.zip

It would not be too hard to port to another platform.

If you want to see the assembler/disassembler code working, download my 65C02 Simulator. It has the sbc2os running on it.

Daryl

Same with the assembler in my POC's BIOS ROM. It will compute both 8 and 16 bit branch offsets, plus accept 16 bit immediate mode operands where allowed (all immediate mode instructions except REP and SEP).

Technically speaking, an assembler is not required to understand labels or variables. So, calling your assembler a mini-assembler is being mean and disrespectful to it. It does the job of translating LDA #65 into A9 41 and poking that byte sequence into RAM at an address of your choosing, which means it is a real assembler. Anything it can do over and above that is frosting on the cake.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

That may be true, but since Apple called it a mini-assembler, and mine is spun from it, that is what I call it too. It seems to be ok with that label.

One feature I did add to mine is the ability to accept numeric parameters in any of four bases, so:


all mean the same to the assembler.

In the absence of the radix symbol the assembler assumes hex, so LDA #a is the same as LDA #$0A.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!