Custom Homebrew Commodore 128

[BigDumbDinosaur]

I've made progress to where I have a fully-functioning M/L monitor that works with the W65C816S running in 16 bit native mode.

Seen below is the POST screen, which ends up in the monitor due to no disks being attached to the system.  Succeeding posts will have more screens, as I can't link all of them in one message due to the 1024K limit.

[BigDumbDinosaur]

Assembling a 16 bit load and add, and a 24 bit store.  This will be the M/L equivalent of 1234 + 4321, using BCD arithmetic.

[BigDumbDinosaur]

Assembling another instruction, using the monitor's built-in radix conversion feature to enter a bitwise operand to the SEP (set status register bits) instruction.  The radix conversion is similar to that in the C-128 monitor, with the exception that @ is used to denote an octal value instead of &.

[BigDumbDinosaur]

The program has been run and stored its result.

When operating in native mode, the W65C816S has selectable register widths, as well as some registers not found on the eight bit 65xx MPUs.  Hence the register dump following the execution of BRK is more elaborate to account for the differences:

PB - program bank, which is the equivalent of the A16-A23 address lines when an opcode is being fetched from RAM.  PB is automatically forced to $00 when an interrupt occurs.

PC - 16 bit program counter.  When combined with PB, an effective 24 bit execution address is expressed.

NVmxDIZC - status register displayed as flag bits instead of hex (this could have been done in the C-128's monitor, as there is plenty of room in the ROM to store the extra code).  mx represents two bits that control register widthsâ€"a set bit means 8 bits.  m sets .A and read-write-modify memory accesses (e.g., ROR $AF41 or BIT $AF41) to 8 or 16 bits.  x sets the .X and .Y registers to 8 or 16 bits.  Note that there is no B (BRK) bit, as the MPU has separate vectors for IRQ and BRK when running in native mode, eliminating the need for the B bit.  Two new instructions, SEP and REP, can be used to set or clear, respectively, status register bits.  For example, SEP #%00110000 sets both m and x, causing all registers to operate in 8 bit mode.  SEP #%00000001 does the same thing as SEC.  In a program where interrupts are to be disabled, decimal mode set, carry set, 16 bit accumulator enabled and 8 bit index registers enabled, it can be accomplished in one instruction with  SEP #%00011101.

.A - 16 bit accumulator, which is really two 8 bit registers that can be used singly or in tandem.  A very useful instruction, XBA, can swap the two registers, so $1234 can become $3412.  Instructions that implicitly work on both registers use the letter C to indicate this.  For example, TSC transfers the 16 bit stack pointer into the 16 bit accumulator, even if the m bit is set (8 bit accumulator and memory).

.X, .Y - index registers.  If either register is holding a 16 bit value and the x status register bit is subsequently set (select 8 bit width), the MSB in both registers is forced to zero.  If set to 16 bits, an instruction such as LDX #$00 is really LDX #$0000, and INX increments a 16 bit value.  Hence, the code:

    LDX #$FF
    INX
    INX

results in .X = $0101, very useful for handling data arrays!

SP - stack pointer.  As the 16 bit stack pointer can be set anywhere in the range $0000-$FFFF, the stack is fully relocatable, and, in fact, subroutines can be given their own local stacks.  In my SBC, the top of RAM is at $CFFF, so that is where I start the stack.  As with the 8 bit stack pointer in the 65xx, the '816's stack pointer will wrap if decremented past zero.  The '816 has instructions that can transfer the stack to and from the accumulator, as well as to and from .X.  If the stack pointer is to be copied into .X, x status register bit has to be cleared to avoid losing the MSB.

DP - direct page starting location.  In W65C816S parlance, "direct page" is a euphemism for zero page.  DP can be located anywhere in the memory range $000000-$00FFFF, which gives rise to the possibility of subroutines being given their own local zero pages.  In my design, I am running the direct page on physical zero page, so DP will always display $0000.

DB - data bank, which is the equivalent of the A16-A23 address lines when a load, store or read-modify-write operation is being performed.  DB can autoincrement when access reaches the top of a 16 bit RAM segment, thus permitting linear memory addressing over the processor's full 16 MB range.

[Hydrophilic]

That's pretty cool you have a working OS for your single board computer.  If you can call an ML Monitor an OS 

I also think it's cool how the layout and syntax is compatible with C128 Monitor.  I'm sure you have your design goals, but it would be sweat if your evenetual OS were compatible with Commodore's KERNAL.  I mean, if you could implement console I/O with calls to $FFCF and $FFD2 and maybe PLOT (I forget its address), that would go a long way to making a large library of software (PET / VIC / C64 / C128) easily adaptable (if not truly compatible).

I've never built a computer from scratch like you, so kudos!  I wrote my own simple OS for the C128 way back in the day, but without a EPROM burner, it was just a cumbersome replacement OS (like CP/M or GEOS).  I have built a couple of PC-compatibles, but that was board level 'plug & pray'... nothing like your work!  I have built some simple arithmitic circuits but not a CPU (or even ALU) and definately not a single board computer.  If I ever get the time to get into FPGAs, I'd like to build a 6502-compatible CPU from one or more.  I'm thinking one for the ALU and one for the instruction decode/execution.  More like a single board CPU.

Well that's me and some of my dreams.  But you've got some reality... congradulations!  Keep us posted 

[BigDumbDinosaur]

That's pretty cool you have a working OS for your single board computer.  If you can call an ML Monitor an OS 

Actually, there's quite a bit crammed into that EPROM.  In addition to the M/L monitor, there's console I/O that can do simple graphics, an IRQ handler that runs a 32 bit uptime counter, along with a 10 millisecond interval timer, EIA-232 primitives to drive the 2692 DUART, and a reset handler that does a full checkerboard RAM test at boot time (reporting it to the screen on the fly).  The ROM also has code that can read and write the real-time clock registers, as well as the 256 bytes of NVRAM within the RTC.

I also think it's cool how the layout and syntax is compatible with C128 Monitor.

Actually, the monitor is based on much older code that I developed for the C-64 around 1984.  I did borrow some ideas from the C-128 monitor.  A lot of it, however, was scratch-written to work with the W65C816S architecture.

I'm sure you have your design goals, but it would be sweat if your evenetual OS were compatible with Commodore's KERNAL.  I mean, if you could implement console I/O with calls to $FFCF and $FFD2 and maybe PLOT (I forget its address), that would go a long way to making a large library of software (PET / VIC / C64 / C128) easily adaptable (if not truly compatible).

That probably won't happen in ROM, as there isn't enough room to fit it all in.  Also, the display you are looking at is on a WYSE 60 terminal.  All of the console I/O was written specifically to run that terminal (and its derivatives).  Th Commodore screen I/O model is quite different and actually less capable.

As for Commodore software compatibility, that isn't likely, as the MPU operates in its 16 bit native mode and the BIOS itself has little in common with the Commodore kernel.

I've never built a computer from scratch like you, so kudos!

Awww, it's not that hard.  I did it entirely with off-the-shelf hardware.  No custom PLDs or any of that stuff.  The Dallas RTC is probably the most exotic piece of silicon in the whole design.

[commodorejohn]

Quite cool SCSI, though? Really? Whew.

[airship]

*sigh* Another thing that's on my 'bucket list' that I probably won't live long enough to do. (Not that I'm in any imminent danger, mind you.) Of course, I remember when you were worried that you'd drop dead any any moment, too, BDD, so maybe there's still time. If not, I can at least enjoy your experience vicariously! Great work!

[BigDumbDinosaur]

Quite cool SCSI, though? Really? Whew.

SCSI and I are old friends, dating back to when the ink was barely dry on the first ANSI standard published in 1986.  I actually have some of the SCSI programming stuff memorized and can tell you which opcodes do what ($08 does read using a 21 bit LBA). 

I found an NOS source for AMD 53C94 SCSI ASICs, a device which perform all of the SCSI bus sequences in hardware with relatively simple commands.  Interfacing the 53C94 to the W65C816S bus will be a bit of a challenge.

[BigDumbDinosaur]

*sigh* Another thing that's on my 'bucket list' that I probably won't live long enough to do. (Not that I'm in any imminent danger, mind you.) Of course, I remember when you were worried that you'd drop dead any any moment, too, BDD, so maybe there's still time.

Me?  Drop dead?  Man, having a 10 ton dinosaur keel over would cause seismic tremors and flatten out a lot of vegetation, as well as one or two cars.    However, thanks to ridiculously-priced drugs and a hematologist who was trying to not lose a paying patient, dropping dead seems to be less a threat these days.  The problem isn't fixed by any means, but Pac-Man is under control.

If not, I can at least enjoy your experience vicariously! Great work!

Thanks.  I was amazed when I fired it up the first time and it actually came to life.  I'll post a few more pictures when I get them.

[BigDumbDinosaur]

BTW, here's a picture of my test setup for my little computer (you can barely see it on the bench).  That terminal is a WYSE 60, which was definitely the Commodore 64 of the terminal world.  I'm sure I've installed several thousand of these over the years.

[airship]

Unfortunately, I was *ahem* asked by my wife to dumpster my Wyse when we moved into our newly built house many years ago. I got it dirt cheap when my employer went out of business.

[BigDumbDinosaur]

Unfortunately, I was *ahem* asked by my wife to dumpster my Wyse when we moved into our newly built house many years ago. I got it dirt cheap when my employer went out of business.

And you're still married to her???   

There are still plenty of WY-60s around, as well as derivatives such as the WY-150, WY-160, GPT (last model produced by WYSE), WY-325 and WY-375 (the last two are color).  A company called Vecmar sells remanufactured units.  As I still have a number of clients running on terminals attached to UNIX and Linux systems, I do some business with Vecmar when a terminal goes kaput.  WYSE, of course, has discontinued the production of new terminals, but they'll be around for a long time.  Most modern thin clients include terminal emulation, and of course, WY-60 is most common.

[commodorejohn]

Yeah. My local recycling center actually has stacks of Wyse terminals; I got a perfectly functional WY-150 for nothing; the only thing I had to shell out for was the keyboard.