Custom Homebrew Commodore 128

[commodorejohn]

Yeah. Doing a relocatable stack on the 65C02 isn't hard (heck, it's in my design, and I'm still a newbie at this,) but it's still limited to 256 bytes, which just isn't enough for a serious OS. I suppose you could theoretically extend it by keeping external track of the stack pointer by, I dunno, counting pulls from the top of the stack and pushes to the bottom and relocating the stack accordingly, but at that point it's so complicated that you might as well just move to a CPU that'll save you the trouble.

Anyway, anything that works like Unix and has the Unix nature is Unix, no matter what anybody says.

[BigDumbDinosaur]

The 65C816's relocatable stack is tailor-made for use with C or any other stack-oriented language.  With the '816, the stack can be anywhere in RAM from $000000 to $00FFFF.  Practically speaking in a banked RAM environment, each bank could have its own private ZP and stack, with the stack at the top of each bank and growing downward as needed.  Since the stack pointer is 16 bits, growth obviously can exceed 256 bytes, greatly enhancing the use of the stack for passing parameters.  Alternatively, you could use the '816 with linear addressing (16 MB max) and just let the stack occupy all space in the lower end of the $000000-$00FFFF range.  Of the two, I see the banking method as a more tidy way to do it.

Also, it is possible to locate zero page somewhere other than at the physical zero page, again anywhere in the range of $000000 to $00FFFF.  This means subroutines that need to use ZP locations can be given ZP storage that is not shared with the calling routine.  In fact, with a little planning, you could attached some storage to the end of the sub solely for ZP use.  Presumably, you'd know in advance how many ZP locations would be needed and allocate some storage for that many bytes.  Obviously you could eat up a lot of RAM doing so, but the possibility is there.  Not coincidentally, WDC sells a C compiler/assembler package that is optimized for use with the '816's relocatable ZP and stack.

The only practical way to use the 'C02 with a UNIX-like kernel is to have banked RAM in which each process has a private ZP and stack, both fixed, of course.  On a context switch, you'd save the registers and stack pointer in a designated location in that bank, switch to a different bank, load the SP and registers from storage and off you go.  That would avoid smashing the stack or running out of ZP space when many processes are running, but would still limit you to 256 bytes of ZP and stack space per process.  Of course, you can nest quite a few subroutines on a 256 byte stack (42 to be exact if every sub pushes all registers), but it would be limited for parameter passing.  It's not ideal but could be made to work.

[commodorejohn]

Yeah, the 65C02 is sub-optimal for high-level languages. The 816's still got its quirks (I really don't see why the Direct Page register couldn't have used its 16 bits as the high 16 bits of the address and allowed relocation to any page in memory,) but it's quite a bit friendlier to that sort of thing.

[BigDumbDinosaur]

Yeah, the 65C02 is sub-optimal for high-level languages. The 816's still got its quirks (I really don't see why the Direct Page register couldn't have used its 16 bits as the high 16 bits of the address and allowed relocation to any page in memory,) but it's quite a bit friendlier to that sort of thing.

The ZP "quirk" isn't a quirk at all but an intentional design decision that works around the fact that the '816 doesn't have an actual 24 bit address bus.  Maintaining some bus compatibility with the 65C02 was essential to getting anyone to purchase the '816.  The genesis of the '816 was in 1982, a time when the 6502 and derivatives were flying high (and would gain more altitude, thanks to the Commodore 64).  It all started when Apple approached Bill Mensch about developing an upscale 6502 for the Apple IIGS.  Apple had a lot of experience with the 6502 architecture, but wasn't at all interested in buying more 6502's from MOS Technology, since it was part of Commodore (plus it was rumored that Steve Jobs detested Jack Tramiel).

Apple's requirements demanded that reasonable compatibility be maintained with the '02 (hence the emulation mode following reset), and the answer to that was a processor whose registers could be 16 bits wide, but still work with an 8 bit data bus and fit into a DIP40 package.  The idea of having 16 bit wide registers but using an 8 bit data bus already existed in the Intel 8088, but given the packaging costs of that MPU, Intel evidently reasoned that adding the D8-D15 data lines wouldn't affect saleability of the processor (adding them helped).  That's what became the 8086.

Although I'm speculating a bit here, I suspect Mensch stayed away from a true 24 bit address bus due to packaging requirements and possible cost run-up.  In any case, he would have had to stick with the 8 bit data bus to satisfy Apple's requirements.  The IIGS was competing with the Amiga, Atari ST and the Mac, and cost had to be a major factor.  Hence the design.

The problem with not having a real A16-A23, of course, is that a ZP address will be automatically bound into the "bank zero" segment of the MPU's address range (I'm not sure how well versed you are on the '816 architecture, so please ask for clarification if needed).  The bank address, which is merely a sort of software kludge that establishes A16-A23 when PHI2 is low, cannot wrap under program control.  That is why you cannot set a 16 bit page address for ZP.  There is no 16 bit page address at all.  There's the 16 bit absolute address asserted on A0-A15 and a bit pattern corresponding to the bank number ($00-$FF) asserted on D0-D7 during PHI2 low.  Glue logic on the data bus has to latch the bank number while PHI2 is low and form A16-A23 from it.  As soon as PHI2 goes high, D0-D7 is data, preventing an instruction like LDA(ADDR),Y from being able to use a cross-bank address for ADDR.

As you noted, however, the '816 is a substantial step up from the 'C02, and with 16 bit loads, stores and register operations, you get more compute-bound power at any given clock speed.  It isn't going to fool anyone into thinking it's an Athlon64, but it'll get plenty done.

[commodorejohn]

Oh, it's a multiplexed address bus? That explains the awkwardness with the PC not being able to cross bank boundaries, too...

[RobertB]

The genesis of the '816 was in 1982, a time when the 6502 and derivatives were flying high (and would gain more altitude, thanks to the Commodore 64).  It all started when Apple approached Bill Mensch about developing an upscale 6502 for the Apple IIGS.  Apple had a lot of experience with the 6502 architecture, but wasn't at all interested in buying more 6502's from MOS Technology, since it was part of Commodore (plus it was rumored that Steve Jobs detested Jack Tramiel).

Apple's requirements demanded that reasonable compatibility be maintained with the '02...

(snip)

Although I'm speculating a bit here, I suspect Mensch stayed away from a true 24 bit address bus due to packaging requirements and possible cost run-up.  In any case, he would have had to stick with the 8 bit data bus to satisfy Apple's requirements.  The IIGS was competing with the Amiga, Atari ST and the Mac, and cost had to be a major factor.  Hence the design.

Thank you for that bit of history.  I look at my Apple IIGS with a bit more understanding now.

                AmiWest Show on October 16-18,
                Robert Bernardo
                Fresno Commodore User Group
                http://videocam.net.au/fcug

[airship]

Was DIP40 an Apple requirement? I ask because the IIGS uses a square package 65816.

[commodorejohn]

Eh? Both my IIGS and the broken one I salvaged my 65816 out of use DIP-40 CPUs. Is yours PLCC? I wonder if that's a difference between board revisions...

[BigDumbDinosaur]

Oh, it's a multiplexed address bus? That explains the awkwardness with the PC not being able to cross bank boundaries, too...

Right.  If the address is $12AB34, A0-A7 will be $34 and A8-A15 will be $AB, same as with the 65(C)02.  The $12 part of the addressâ€"actually the bank addressâ€"will be present on D0-D7 while Ø2 is low.  When Ø2 goes high, $12 will vanish from D0-D7 and be replaced by data.  This method was developed so the intended target of the '816 (the IIGS) could run Apple IIe and IIc software, provided the programmer didn't employ illegal NMOS opcodes.  At reset, the '816 bank address is set to $00 and "native" 6502 code will run without alteration.

Due to the A16-A23 multiplexing scheme it is necessary to latch the bank address while Ø2 is low, which gives rise to potential timing gotchas as the clock speed is ramped up.  WDC illustrates a suggested bank address latch circuit on page 45 of the data sheet using a '373 or '573 latch (the better choice is the 74ABT573 due to its sub-10ns prop time and greater bus drive capability).  However, analysis of the timing indicates that it would be marginally reliable at the MPU's rated clock speed of 14 MHz and most likely non-functional above that speed (the '816 is capable of 20 MHz).

For that reason (among others), I'm not using the bank function in my '816 SBC and instead will map 48K chunks of RAM into address space via a CPLD.  PLD's propagate in the single digit nanosecond range, and there are no cummulative gate delays, even in complex combinatorial logic situations.  BTW, it would be possible to use a PLD or a GAL to latch the bank address if it was desired to establish a linear memory model.  However, it still would not be possible for cross-bank code to sequentially execute.

Was DIP40 an Apple requirement? I ask because the IIGS uses a square package 65816.

That I don't know but I doubt it.  At the time the Apple IIx (the IIGS's ancestor) was conceived (c. 1982) the DIP40 was most prevalent in MPUs.  The first IIGS motherboard I ever saw (some time in 1987) had a 65C816 in a DIP40 package.  However, by then, PLCC was already in use and I imagine Apple probably asked WDC to produce a PLCC version of the '816.

Generally speaking, board layout tends to be easier with a PLCC package, as the radial arrangement of the pins simplifies bringing out related connections, such as the address bus lines.  I used the PLCC form factor in my SBC V1.0 design whose PCB I illustrated earlier (it's the PLCC package near the left end of the board).

[commodorejohn]

Hmm. If it's a multiplexed address bus, I might actually consider using my 816 in System/65 without A16-A23; I'll have to give it some thought.

[airship]

Eh? Both my IIGS and the broken one I salvaged my 65816 out of use DIP-40 CPUs. Is yours PLCC? I wonder if that's a difference between board revisions...

I don't own one, but I checked one out at the local recycler's and it had the square chip. I was disappointed because I wanted to strip it for parts to play with.

[BigDumbDinosaur]

Hmm. If it's a multiplexed address bus, I might actually consider using my 816 in System/65 without A16-A23; I'll have to give it some thought.

That's my plan as well.  The inability of the '816 to execute code that crosses banks makes the banking scheme marginally valuable in my opinion.  However, the MPU's other capabilities transcend the awkward memory model.

In my design, the memory map will look like the following:

   $xx0000-$xxBFFF   segmented RAM, where xx is a segnment number from $00-$FF
   $00C000-$00CFFF   low ROM or common RAM
   $00D000-$00DEFF   I/O or common RAM
   $00DF00-$00DFFF   hardware & memory management unit (HMU, always present)
   $00E000-$00FFFF   high ROM or common RAM

At reset, the MPU will see the following:

   $000000-$00BFFF   RAM
   $00C000-$00CFFF   RAM
   $00D000-$00DEFF   I/O
   $00DF00-$00DFFF   HMU
   $00E000-$00FFFF   ROM

High ROM will contain a BIOS, which will consist of a basic interrupt handler, console port driver and basic SCSI driver.  At boot time, the behavior will be similar to a PC, with an attempt being made to load a boot block from SCSI ID 0/ LUN 0.  Low ROM will contain a machine code monitor that will be started if the BIOS is unable to load a boot block from disk or if the boot block doesn't contain valid boot code.  The monitor will include a function to import code via a second serial port on the board.

The HMU will consist of four addresses: one to select the current RAM segment, another to determine what will appear in the range of $00C000-$00FFFF, a third that will enable/disable protection for common RAM and a port that will be tied to a priority interrupt encoder.  Common RAM protection can be set as none, no write access allowed or no read/write access allowed.  If protection is enabled and code in any RAM segment other than segment $00 attempts to improperly access common RAM, an ABORT interrupt will occur (accomplished by toggling the MPU's /ABORT input).  This feature will prevent a process from straying outside of its segment.

Writing to any ROM location will bleed into RAM, allowing an ISL to write code into any common RAM area except the I/O block.  Once the ISL has occurred, ROM can be mapped out and the OS can be run entirely in RAM, thus avoiding having to wait-state the system for ROM BIOS accesses.  I envision the OS having two components: the main kernel running in the $000000-$00BFFF range and a part running in common RAM from $00E000-$00FFFF.  The latter would contain the user-accessible kernel jump table, interrupt handlers, cross-segment transfer code (like the INDEFSTA code in the C-128, but much tighter and with 16 bit transfers) and, of course, the '816 hardware vectors.  The common RAM from $00C000-$00DEFF could be used for inter-process communication (e.g, semaphores or shared memory), since that would be entirely compute-bound and wouldn't need the services of the I/O hardware.

In theory, I should be able to utilize 16 MB of RAM.  The largest SRAM piece that I've been able to find that is in a package that can be hand-soldered is 512Kb x 8, so 32 of those would be required for the full complement of RAM (homemade DIMMs, anyone?).  The RAM segmenting scheme is actually quite simple.  The 32 /CE (chip enable) lines would be controlled by 32 registered outputs on the CPLD in response to the segment number written into the HMU.  Each SRAM has 19 address lines (A0-A18).  Therefore, any given 64K segment can be selected in a given SRAM by asserting that chip's /CE line, and bringing combinations of A16-A18 high or low as required.  The address lines of all SRAMs can be connected together, as an SRAM will tri-state if /CE is high, thus minimizing the number of lines that must be controlled to map different RAM segments in and out of MPU space.

Of course, this is only a paper computer right now. 

[RobertB]

Both my IIGS and the broken one I salvaged my 65816 out of use DIP-40 CPUs.

When I get back home, I will check my GS.

               AmiWest Show on October 16-18,
               Robert Bernardo
               Fresno Commodore User Group
               http://videocam.net.au/fcug

[commodorejohn]

Well, for a paper computer it's not too bad

[RobertB]

     If you want a paper computer, go to

http://www.erikschubach.com/vintage/sx-64-paper-model.php

Much lighter than 25 pounds... ! 

             AmiWest Show on October 16-18,
             Robert Bernardo
             Fresno Commodore User Group
             http://videocam.net.au/fcug

[BigDumbDinosaur]

     If you want a paper computer, go to

http://www.erikschubach.com/vintage/sx-64-paper-model.php

Much lighter than 25 pounds... ! 

             AmiWest Show on October 16-18,
             Robert Bernardo
             Fresno Commodore User Group
             http://videocam.net.au/fcug

Yes, but can you network them? 

[RobertB]

The first IIGS motherboard I ever saw (some time in 1987) had a 65C816 in a DIP40 package.

O.K., I just opened up the clamshell of my 1987 copyright IIGS and inside is a socket at U18 for a 65C816 DIP40.

However, by then, PLCC was already in use and I imagine Apple probably asked WDC to produce a PLCC version of the '816.

Note that above I don't say there is a 65C816 in the socket, because it has been taken out and an adapter plug has been installed there which goes to a Transwarp board, and that board has a W65C816PL.

             AmiWest Show on October 16-18,
             Robert Bernardo
             Fresno Commodore User Group
             http://videocam.net.au/fcug

[RobertB]

Yes, but can you network them? 

I imagine that if you make a couple out of stiffer cardstock, make them slightly larger, cut a 2-inch hole into them, and draw a string tight between the pair, you'd be able talk into them and transmit voice from one to the other.  Peer-to-peer networking! 

             AmiWest Show on October 16-18,
             Robert Bernardo
             Fresno Commodore User Group
             http://videocam.net.au/fcug

P.S. I almost forgot to mention another paper computer... one which I passed out to friends at a Vintage Computer Festival years ago.  Go to

                     http://www.homecomputermuseum.de/comp/14.45_de.htm

for your very own PET 2001 (pdf). 

[BigDumbDinosaur]

Well, for a paper computer it's not too bad

Speaking of paper computers, here are the schematics for my first design:

Memory Map
MPU Interface & Chip Select Logic
RAM, ROM & I/O
External Interface

Also, I rearranged the PCB to make it a bit denser and to shorten the length of the buses:

Printed Circuit Board

[BigDumbDinosaur]

I figure I've stared at this design enough to either eliminate all errors or not see those that are still present.  Being a brave soul, I'm forging ahead and have ordered some PCBs on which to assemble this contraption.  If you see a large mushroom cloud rising over the midwest USA, that's only me applying power to my "computer."

[commodorejohn]

Ah, fun. Let us know how it turns out!

[airship]

Good luck, BDD! I'm anxious to see how your design works out.

I've got a breadboard around here somewhere with a 6502 and two 6522s scavenged from a dead 1541 drive. There are also two battery-backed RAM chips. With a few glue chips, I figure I ought to be able to come up with something that works eventually.

[BigDumbDinosaur]

The challenge in building this contraption will be in soldering the SRAM to the PCB.  The SRAM is in an SOJ32 package whose pins are on 50 mill centers.  i, being a big, old, broken-down and dumb dinosaur, don't have quite the hand-eye coordination I did back in the days of Pong and Pac-Man (the latter who has taken up residence in me).    Other than the SRAM, the rest of it shouldn't be too tough.

[commodorejohn]

Not sure exactly where to get them, but I know there are SOJ-to-DIP converter sockets available...that might ease the pain considerably.

[BigDumbDinosaur]

Not sure exactly where to get them, but I know there are SOJ-to-DIP converter sockets available...that might ease the pain considerably.

I've looked at those.  Using them partially defeats the value of the SOJ package, which is its smaller footprint and lower stray capacitance.  Also,you still have to solder the SOJ package to the adapterâ€"this is not a "plug in the SOJ IC" solution.  I'll just have to suck it up and work under the magnifier.