POC Computer Version One

[BigDumbDinosaur]

Well, I've been able to maintain momentum on this. I recoded the ROM to operate the '816 in native mode, using the 16 bit stack and all that. Native mode produces no visible changes at this point but does run faster during the memory testing phase, thanks to 16 bit loads and stores.

[BigDumbDinosaur]

I had to set this project aside for a while due to other demands on my time, but recently resumed and got busy writing a little code. Here are a few screen shots:

POST screen, with memory test in progress. This is a full checkerboard test that touches every location in RAM.

Memory test completed, and system ready to detect SCSI hardware and start an operating system. But...

There isn't any SCSI hardware (yet), so the BIOS ROM falls into a machine language monitor.

The monitor is able to disassemble code.

All the new and improved '816 instructions are understood. Note the gratuitous "branch long" instruction at $00E2B1.

The monitor is also able to dump memory.

Number conversion is included. Typing an appropriate radix followed by a number in that format will print the number in binary, octal, decimal and hex.

Next piece of code to write is the assembler. BTW, I went back to emulation mode, as I already had a lot of the M/L monitor basics written and test in 65C02 code. Once all of this is working as it should I'll come up with a native mode version.

[ElEctric_EyE]

Nice to see your progress once again BDD! Just a few questions, forgive me if they've been answered before...

How much RAM is available? What is the checkboard test? How long does it take to complete the test?

[BigDumbDinosaur]

ElEctric_EyE wrote:

How much RAM is available?

Currently it's 52K of RAM, 4K I/O and 8K ROM. So the "128K Static RAM" in the POST screen is a little bit of malarkey. There is a 128K static RAM in it but I'm not decoding A16 in this design.

Quote:

What is the checkboard test?

That was supposed to be "checkerboard test." I fixed the post.

"Checkerboard" mean writing alternating patterns of $A5 and $5A (%10100101 and %01011010, respectively) into every memory address from $0000 to $CFFF and then checking to see if the same value can be read back. First page zero is tested in this fashion, and then when that test has completed, absolute RAM is similarly tested, with the RAM count being maintained on page zero. There's a delay after the pattern is written to each memory cell before it is checked, which allows time for data to bleed off if a cell is defective (unusual with SRAM). In the event a cell is found to be defective a terse diagnostic is printed and then the system is halted.

Quote:

How long does it take to complete the test?

I don't know the exact number of machine cycles, but in wall-clock time it's done in a fraction of a second with an 8 MHz clock. Even with the time expended on updating the RAM count on the screen, it's less than a second from start to finish.

[BigDumbDinosaur]

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.

[BigDumbDinosaur]

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:

Code: Select all

;	encoded mnemonics MSB...
;
mnetabhb .byte $1c,$84,$24,$84,$ad,$84,$15,$84,$8a,$84,$15,$8a,$ad,$84,$15,$84
         .byte $1c,$84,$84,$84,$ac,$84,$15,$84,$23,$84,$53,$a9,$ac,$84,$15,$84
         .byte $5d,$13,$5d,$13,$1a,$13,$9c,$13,$8b,$13,$9c,$8b,$1a,$13,$9c,$13
;
;
;	encoded mnemonics LSB...
;
mnetablb .byte $d8,$c4,$22,$c4,$06,$c4,$1a,$c4,$62,$c4,$1a,$4a,$06,$c4,$1a,$c4
         .byte $5a,$c4,$c4,$c4,$c6,$c4,$1a,$c4,$48,$c4,$c8,$28,$c6,$c4,$1a,$c4
         .byte $26,$ca,$1a,$ca,$aa,$ca,$1a,$ca,$62,$ca,$1a,$4a,$aa,$ca,$1a,$ca

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:

Code: Select all

xxxxxxxx
||||||||
|||+++++---> addressing mode
|++--------> operand size (0-3)
+----------> 1: accept 8 or 16 bit operand

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.

[ElEctric_EyE]

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!

[BigEd]

BigDumbDinosaur wrote:

the data tables in all consume 816 bytes.

Nicely done!

[BigDumbDinosaur]

ElEctric_EyE wrote:

Would you be willing to share your assembler/disassembler for the 65C02?

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.

[BigDumbDinosaur]

BigEd wrote:

BigDumbDinosaur wrote:

the data tables in all consume 816 bytes.

Nicely done!

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

[GARTHWILSON]

Quote:

I never found a good use for those instructions, so I simply ignored them.

They would be great if your I/O is in ZP. Mine is not, so I like to put serial clock lines on bit 0 of a port so I can, for example, use INC DEC to do a positive pulse on the line (starting with it low), and use bits 6 and 7 for 1-bit inputs so I can test them with BIT without first loading A. Bit 6 goes to the C flag which makes it extra quick for shifting data in when bit-banging a synchronous-serial line. The latter is even better than BBS/BBR in that regard.

[BigDumbDinosaur]

GARTHWILSON wrote:

Quote:

I never found a good use for those instructions, so I simply ignored them.

They would be great if your I/O is in ZP. Mine is not, so I like to put serial clock lines on bit 0 of a port so I can, for example, use INC DEC to do a positive pulse on the line (starting with it low), and use bits 6 and 7 for 1-bit inputs so I can test them with BIT without first loading A. Bit 6 goes to the C flag which makes it extra quick for shifting data in when bit-banging a synchronous-serial line. The latter is even better than BBS/BBR in that regard.

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!

[ElEctric_EyE]

BigDumbDinosaur wrote:

...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...

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!

[BigDumbDinosaur]

ElEctric_EyE wrote:

BigDumbDinosaur wrote:

...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...

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!

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.

[fachat]

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é