Commodore 128 Alive!

All

   If I missed a FAQ about this subject, please kindly show me the light.  In hopes that this is a legitimate new topic, could somebody shed some light on this idea:

I'd like to custom build a commodore 128 based off of the schematics.  I'd want to remove the C64 and CPM modes so its just a Commodore 128.  Would this even be doable?  I'm not sure how intertwined the other modes are in the hardware.

Has anybody thought about doing this or done this already? If so could you share your experiences.

I figure all I would have to do would be to take the schematics to a custom printed circuit board company, go procure the parts through jameco or similar places, solder them all on and power it up.

On down the road it would be nice to have an SD card reader emulate the harddrives to make it all the more portable.

What do you guys think about this idea?

Um, you really couldn't remove the C64 mode, since it forms the essential basis for 128 mode. You could remove the C64 ROM, maybe, but that's about it. As far as CP/M mode, you could remove the Z80 and its ROM, but again, the C64 hardware forms the basis of what's provided in that mode, too. The big question is, why would you want to? It's not like you're going to gain any kind of performance in so doing, and C64 mode is at least 50% of what anybody uses a 128 for, anyway.

Quote from: commodorejohn on October 01, 2009, 11:32 AM
Um, you really couldn't remove the C64 mode, since it forms the essential basis for 128 mode. You could remove the C64 ROM, maybe, but that's about it. As far as CP/M mode, you could remove the Z80 and its ROM, but again, the C64 hardware forms the basis of what's provided in that mode, too. The big question is, why would you want to? It's not like you're going to gain any kind of performance in so doing, and C64 mode is at least 50% of what anybody uses a 128 for, anyway.

Actually you can't remove the Z80 - the Z80 has control of the machine at startup.

Ah, true. I suppose you might be able to tinker with the machine so that that wasn't the case, but even then you still come around to the question of why you would want to do all this.

New parts are not available to build a C128. The MMU was a custom part from Commodore. So was the CPU (it has two special registers). The 6526 VIA chips are no longer made. The VIC-II, VDC, and SID chips were also custom CBM chips. To get most of the parts for this project, you'd have to scrap one or more real C128s. You could go the route of creating an FPGA version, but programming those is a very specialized skill.

For an example of the kinds of things that are involved in that approach, you might want to check out the Chameleon  (http://www.syntiac.com/chameleon.html)project that Individual Computers is doing. It's a cart for the C64 that essentially replaces its entire innards with gate logic. Features include 1.8x acceleration, VGA out, REU emulation, and more.

Everyone always has reasons it can't be done. I say go for it! ;-)  I'm not aware of anyone who has recreated a commodore machine from schematics. Of course as others will tell you it's not as easy as you make it out to be. You can't take schematics somewhere and have a board done. You'll have to lay it out yourself. And yes, you'll likely have to use an entire working C128 just to get the parts you'll need, but if your goal is to learn then that's fine. If you don't need 40 column mode then skip the VIC-II. You don't NEED the Z80. There's no reason you couldn't design it out if you knew how. And of course, you'd have to make some changes to the firmware/kernal/basic. While you're at it, go ahead and replace the ROMS and RAM with newer versions to reduce the chip count.

Steve

PS: There are plans on the web to replace a 6510 processor with a 6502 and an IO chip, so you don't really need the same one in the C128. The Z80 was only made the controller to solve some compatibility problems with the magic voice cartridge... without "c64" mode you don't need it.

All

Thanks for the replies!.  To answer everybody's question as to why I'd want to do it - basically just to see if I could and for personal satisfaction.  I didn't know these chips were custom chip and aren't made anymore.  That pretty much puts a kink into my plans.  As for going the FPGA route, does anybody know where I could find some inside information about how the chips work so that I could use it should I go that route.

Thanks everybody for the responses!

I can dig the "because I can" mentality, myself. But have you considered that, rather than reinvent a perfectly good wheel, you might as well just make something up out of whole cloth? That's what I'm working on (http://john.seikdel.net/65main.htm) at the moment, and to me, at least, it's more satisfying than recreating a modified version of an existing computer. Cheaper and easier, too, considering that you don't have to obtain any specialty parts from anywhere and can just use what's available from wholesale electronics retailers.

wow commodorejohn that is amazing!!  I'll definitely bookmark your site and keep tabs on it.  I hadn't thought of putting into that kind of perspective.  It definitely makes things easier without having to find custom chips.

Heh, I wouldn't start calling it "amazing" until it's actually working ;)

QuoteI can dig the "because I can" mentality, myself.

That's a good attitude to have.

Now, since most if not all 6502 assemblers generate two zero bytes when they encounter a BRK instruction, we'll need to define a macro to generate the necessary pair of bytes for a BIOS call.

They do?  That's news to me and I've been writing 65xx assembly language programs for some 30 years.  Here's the assembler listing from Kowalski's simulator of a short demo program I wrote:

0001   2000  78          sei
0002   2001  00          brk
0003   2002  58          cli                    ;this instruction would be skipped
0004   2003  A9 2D       lda #45
0005   2005  18          clc
0006   2006  69 01       adc #1
0007   2008  00          brk                    ;actual end of program

Note that the CLI following BRK was correctly assembled and the program counter was not double-incremented.  I get the same results with my UNIX 65Cxx cross-assembler.

The process of fetching the second call number involves some stack manipulation and makes things a little slower than a jump table, but I think the advantages outweigh this.

It would make it a lot slower due to all the stack manipulation, not to mention difficult to debug if you make a coding error.  Plus every BIOS routine would have to end with an RTI.  BRK disables IRQs, so you'd have to account for that as well.  Also, since IRQ and BRK jump through the same vector on the 6502, you'd have to get the stack copy of the status register to see what's what.  Compare all those stack acrobatics to the two pushes that a JSR does and you'll quickly find out what "slow computer" means.  :)  Take it with a grain of salt, but I think you will end up with a cumbersome system.

Also, if you want to use BRK for debugging how would you go about doing so if it is used to call the BIOS?

2   Z80 ACTC
3   Z80 DART

I'd stay away from Z80 hardware.  The Z80 bus cycle is very different than that of the 6502.  A good choice for a dual ACIA is an NXP SCC2692, available in DIP40 and PLCC44 packages (the latter is actually easier to work with).  Hook the 2692 to a MAX238 and you've got two EIA-232 channels in a compact package.

Some form of battery-backed real-time clock, possibly with some battery-backed RAM as well.

Take a look at the Maxim DS1511.

4MHz clock generation: what do I need?

    * Also, can I run the components at closer to 5MHz without things frying?

If you get your 65C02 (not 6502) from Western Design you'll get a part that is certified to run at up to 14 MHz.  All your glue logic needs to be 74ABT, 74AC or 74HC, in that order of preference.  Stay away from 'LS stuff.  Your limiting factor on system speed will be your I/O hardware.  SRAM as fast as 15 NS is readily available, so that won't be an issue.  A reasonable design could probably be clocked at 8 MHz if you don't impose too many gates into the glue logic.

As for clock generation, use a can oscillator running at twice the desired clock speed and run it through a flip-flop.  Connect the oscillator output to the clock input of the flop, connect /Q to D and get your clock pulse from Q.  The flop will produce a very sharp rise and fall time, which is de rigeur with the 65C02.  Plus the flop will produce a two phase, non-overlapping clock, which will be useful for qualifying writes to SRAM (get the opposite phase from /Q).

Lastly, I'd consider using the W65C816S instead of the 65C02.  Your memory management will be a lot less cumbersome, plus you can do 16 bit loads and stores if you wish.

Have fun and socket all the expensive stuff so you can salvage it when the first iteration doesn't work as expected (it almost never does).

I attached a little teaser for you.

Quote from: BigDumbDinosaur on October 09, 2009, 10:49 AMIt would make it a lot slower due to all the stack manipulation, not to mention difficult to debug if you make a coding error.  Plus every BIOS routine would have to end with an RTI.

I'm not quite sure how it would make it more difficult to debug; I already have the BIOS-call dispatch part of the interrupt code written, and it works like a charm when I run it in the simulator.

QuoteBRK disables IRQs, so you'd have to account for that as well.  Also, since IRQ and BRK jump through the same vector on the 6502, you'd have to get the stack copy of the status register to see what's what.  Compare all those stack acrobatics to the two pushes that a JSR does and you'll quickly find out what "slow computer" means.  :)  Take it with a grain of salt, but I think you will end up with a cumbersome system.

Well, yes, it is slower, but the point to this project is simplicity over speed (since it's my first attempt at this sort of thing.) Doing the BIOS calls with BRK instructions isn't going to be fast, but I think it'll make things easier to keep track of when trying to write software for it. I'll get to the fast and efficient stuff in later projects ;)

QuoteAlso, if you want to use BRK for debugging how would you go about doing so if it is used to call the BIOS?

Got a BIOS call to invoke the monitor, as well as an option to set unimplemented calls to break to the monitor as well.

About the whole using-BRK-for-BIOS-calls thing, keep in mind that the design at present is anything but set in stone. Although I think I'll be sticking to my scheme for the moment, I do appreciate the advice, and there might be something in the future that tips me back to the jump-table method.

QuoteI'd stay away from Z80 hardware.  The Z80 bus cycle is very different than that of the 6502.  A good choice for a dual ACIA is an NXP SCC2692, available in DIP40 and PLCC44 packages (the latter is actually easier to work with).  Hook the 2692 to a MAX238 and you've got two EIA-232 channels in a compact package.

I'll take that into consideration, but I'm kind of trying to use the parts I have available where possible, since my financial resources are rather, er, limited at the moment.

QuoteLastly, I'd consider using the W65C816S instead of the 65C02.  Your memory management will be a lot less cumbersome, plus you can do 16 bit loads and stores if you wish.

I'd do this, but I'm saving my '816 for a later project. Besides, I have something of a fondness for the smaller processors.

QuoteHave fun and socket all the expensive stuff so you can salvage it when the first iteration doesn't work as expected (it almost never does).

Isn't that the truth ;)

P.S. In regards to the clock circuit, what do you think of thee one in Chris Ward's (http://www.chrisward.uklinux.net/6502/circuit.shtml) 6502 computer? Apparently it provides a clock signal the same frequency as the crystal used, which is convenient. I need to figure out if I need to change anything for it to run at 4.9MHz, though...

Quote

QuoteI'd stay away from Z80 hardware.  The Z80 bus cycle is very different than that of the 6502.  A good choice for a dual ACIA is an NXP SCC2692, available in DIP40 and PLCC44 packages (the latter is actually easier to work with).  Hook the 2692 to a MAX238 and you've got two EIA-232 channels in a compact package.

I'll take that into consideration, but I'm kind of trying to use the parts I have available where possible, since my financial resources are rather, er, limited at the moment.

Compared to some of the other stuff you'll need to bring your project to fruition, the six bucks or so that the 2692 costs will be minor.  You may discover yourself rethinking your approach when you start to interface that Z80 stuff.  BTW, what do you plan to do about a board on which to build your unit?  It's either going to be wirewrap or a PCB.  Point-to-point on a perf board will have problems much over 2 MHz.

QuoteP.S. In regards to the clock circuit, what do you think of thee one in Chris Ward's (http://www.chrisward.uklinux.net/6502/circuit.shtml) 6502 computer? Apparently it provides a clock signal the same frequency as the crystal used, which is convenient. I need to figure out if I need to change anything for it to run at 4.9MHz, though...

It uses too many gates and will not produce a clean output at higher frequencies.  ***DO NOT USE IT***  Use something like what I showed above and you will be able run up to as high as 20 MHz (assuming the rest of the system can handle it).

The reason for running the oscillator through the flop (in case you didn't read my previous remarks in toto) is to sharpen the rise and fall times of the clock signal, which is critical with the 65Cxx family.  Here's an excerpt from the 65C02 data sheet that you need to understand:

Phase 2 In (PHI2) is the system clock input to the microprocessor internal clock.  During the low power Standby Mode, PHI2 can be held in either high or low state to preserve the contents of internal registers since the microprocessor is a fully static design.  The Phase 2 Out (PHI2O) signal is generated from PHI2.  Phase 1 Out (PHI1O) is the inverted PHI2 signal.  An external oscillator is recommended for driving PHI2 and used for the main system clock.  All production test timing is based on PHI2.  PHI2O and PHI1O were used in older systems for system timing and internal oscillators when an external crystal was used.

As an aside, a crystal suitable for use as an MPU clock generator costs nearly as much as a can oscillator.

The second reason for running the oscillator through the flop (again, in case you glossed over that earlier) is to generate an out-of-phase clock for qualifying writes.  Hardware should only be written when PHI2 is high, as that is when A0-A15 are guaranteed to be stable and valid.  A reverse-phase clock makes it easier to qualify writes on some types of hardware.

BTW, if you make the mistake of writing when PHI2 is low, A0-A15 may not be valid and therefore there's no telling where the data will end up.  A0-A15 doesn't become valid until late during PHI2 being low.  The hardware needs setup time to react to the address on the bus.  Ignore that fact and I can guarantee you a DOA system.

BTW, take a gander at www.6502.org (http://www.6502.org) for more info on 65xx stuff.

Quote from: BigDumbDinosaur on October 09, 2009, 12:36 PMBTW, what do you plan to do about a board on which to build your unit?  It's either going to be wirewrap or a PCB.  Point-to-point on a perf board will have problems much over 2 MHz.

Good question. I'm not really sure at this point; a PCB would be nicer, but it would mean even more work and learning time (and a fair chunk of money;) on the other hand, knowing how to design PCBs would definitely come in handy on later projects. I guess I'll figure out when I get to the point where I'm close to ready to start assembly.

QuoteIt uses too many gates and will not produce a clean output at higher frequencies.  ***DO NOT USE IT***  Use something like what I showed above and you will be able run up to as high as 20 MHz (assuming the rest of the system can handle it).

Good to know, thanks. I figured it wasn't as simple as just cranking up the speed (because it usually isn't,) but it's nice to have some confirmation..

As you may have gathered, my knowledge until now has been pretty much limited to the architectural side of computing, and I've been learning about the electronics side primarily by reading about other people's projects. Is there a good tutorial or reference you can recommend for this kind of thing?

Quote

QuoteBTW, what do you plan to do about a board on which to build your unit?  It's either going to be wirewrap or a PCB.  Point-to-point on a perf board will have problems much over 2 MHz.

Good question. I'm not really sure at this point; a PCB would be nicer, but it would mean even more work and learning time (and a fair chunk of money;) on the other hand, knowing how to design PCBs would definitely come in handy on later projects. I guess I'll figure out when I get to the point where I'm close to ready to start assembly.

I use ExpressPCB (www.expresspcb.com (http://www.expresspcb.com)).  They have reasonably good PCB layout software, which also includes a decent schematic drafting application.  You can link your schematics to your PCB layout, which assists in making connections and minimizing mistakes.  Once you've got your PCB layout done you can order it from them through the web and in a few days you will receive your boards.  i can vouch for the quality of their PCBs as I've been using their service for many years to prototype and make short production runs.

At one time I used to point-to-point or wirewrap everything due to the difficulty of getting small quantities of PCBs made at a reasonable cost.  That's changed and now I seldom use hand techniques for anything other than simple "proof-of-concept" circuits.  Below is a pic of a PCB layout that I did in ExpressPCB for a automatic block signal control system for a large scale model railroad club.

Quote

QuoteIt uses too many gates and will not produce a clean output at higher frequencies.  ***DO NOT USE IT***  Use something like what I showed above and you will be able run up to as high as 20 MHz (assuming the rest of the system can handle it).

Good to know, thanks. I figured it wasn't as simple as just cranking up the speed (because it usually isn't,) but it's nice to have some confirmation.

The CMOS version of the 6502 is touchy about the rise and fall time of the clock pulse.  The oscillator and flop circuit I illustrated earlier has a rise/fall time of about 3 NS, well within the 8-10 NS requirements of the WDC 65C02.  The crystal alone cannot usually achieve that at frequencies over 4-6 MHz.  As I said, the flop helps to sharpen the rise/fall time and also generates opposite phase clocks for write qualification.

QuoteAs you may have gathered, my knowledge until now has been pretty much limited to the architectural side of computing, and I've been learning about the electronics side primarily by reading about other people's projects. Is there a good tutorial or reference you can recommend for this kind of thing?

See www.6502.org (http://www.6502.org) for lots of info on building your own 65xx computer from scratch.  There are a number of links to websites where different working designs are described in considerable detail, including schematics.  Due to the ubiquity of the 6502 family, probably more has been written about that one processor than any other except Intel's kludges.

Ah, cool. I'll definitely keep ExpressPCB in consideration, then.

And thanks for the 6502.org link, I'm sure that'll help. Do you know of a good introduction to computer electronics in general?

QuoteDo you know of a good introduction to computer electronics in general?

www.6502.org (http://www.6502.org) has some tutorials on the subject.  Also, you can hit the search engines for information on logic gates, decoding, etc.  Wikipedia has some fairly good stuff on the glue logic needed to make it all work.  It also helps to study the designs concocted by others.  It's kind of hard to point you to any one resource that has everything.  You'll need to do some old fashioned searching.

Okay, then. That's mostly how I've been figuring things out all along, it just would've been handy if there was a good central reference. Thanks again for the information!

One thing you should probably consider is starting out with a simple system with a basic memory map.  All too often, I (and others) have seen someone who has never scratch-built a computer attempt to put together a first effort whose complexity rivals that of a four-processor Opteron server.  Needless to say, the would-be computer designer is quickly overwhelmed with technical issues for which he cannot devise a solution, and thus abandons the project before even getting out of the gate (no pun intended).

For a first effort I highly recommend you use a very simple memory map, such as:

    $0000-$7FFF   RAM
    $D000-$DFFF   I/O
    $E000-$FFFF   ROM

This sort of map is relatively easy to decode and won't require a lot of gates to work.  Remember, the more complex the memory scheme, the more decoding required, which increases gate delays and hence introduces timing problems that may prevent your creation from working.

As far as the MPU goes, the W65C816S is little more in cost than the W65C02S but offers a lot more functionality.  In fact, the PLCC44 version of the '816 is actually cheaper, according to WDC's website.  Since you mentioned you ultimately wanted to build a more elaborate unit based on the '816, why not get acquainted with it right off the bat?  You can start out with running it in emulation mode (the default following reset) and as you work out the kinks in your new machine, switch the '816 to native mode and take advantage of such handy features as a 16 bit stack pointer, 16 bit wide registers, separate vectors for IRQ and BRK, etc.

As far as I/O goes, look at NXP's SCC2692 dual ACIA for serial connectivity (used with a Maxim MAX238 to take care of the the TTL to RS-232 voltage levels) and a Maxim DS1511Y+ for a timekeeper.  Maxim will sample in quantities of one piece, so you might be able to get some of this stuff for free.

Although it's tempting to use a 65C51 UART for serial I/O, it has a number of programming limitations that I personally find annoying.  I'd stay away from it.  The 2692 is more involved to program, but is much more flexible and has dual channels.  You can use one channel for your "console" connection and the other to download code into RAM.

Speaking of RAM, 32K x 8 SRAM is real cheap and can be gotten in a PDIP package, which is easier to work with than an SOJ package with its 50 mil pin spacing.  You can connect A0-A14 of the SRAM directly to the MPU's A0-A14 address lines, and connect the /CE pin on the SRAM to the MPU's A15 line.  With that arrangement, any address below $8000 will result in the MPU sinking A15, which will enable the SRAM and map it into processor space.  If the address is $8000 or higher, A15 will be high, /CE will be high, and the SRAM will tri-state.  Simple.

Decoding I/O and the EPROM is a little more involved but not too much so.  Be sure to use 74ABT or 74AC logic to minimize gate propagation delays.  ABT logic runs down in the 6-10 NS range and AC logic is only slightly slower.  Don't use 74LS, as it is largely obsolete and in some cases, difficult to obtain.  Gate part numbers to consider are 74AC00 (NAND), 74AC04 (NOT), 74AC08 (AND),74AC32 (OR) and 74AC138 (3-8 decoder, used for selecting I/O chips).  All of these are readily available from sources such as Mouser and Digi.  For SRAM, look at Cypress' CY62256LL-70PC, which is a 70 ns, 32 Kb x 8 in a PDIP package.  JAMECO stocks it.

Don't try to build this thing by slobbering wires all over a Radio Shack perf board.  If wiring errors don't get you, excessive distributed capacitance or cross-talk between signal paths will.  This is where wire-wrap or a PCB pays off.

After it's wired up and ready to go, first meter Vcc to ground to locate any shorts -- no point in having it go up in smoke.  Then power it and examine the clock line with your logic probe to see that a clock signal is present.  If so, plug in the chips and start testing!  You might want to consider a NOP generator (http://6502.org/mini-projects/nop-gen/nop-gen.htm) to plug in in place of the EPROM to verify circuit operation.

Quote from: BigDumbDinosaur on October 14, 2009, 02:58 AMOne thing you should probably consider is starting out with a simple system with a basic memory map.

Actually, I think I might do this. I was looking through my assorted scavenged stuff, and it looks like I have some extra components that should be close to enough to build a simple test system around a 6507 I pulled from a broken Atari; I figure I can divide up the 8KB address space into 4KB of RAM, 2KB of ROM, and some very simple I/O without too much complexity.

QuoteSince you mentioned you ultimately wanted to build a more elaborate unit based on the '816, why not get acquainted with it right off the bat?

I'd still like to keep it as an 8-bit system, just for the sake of things, but I'll consider this.

QuoteAs far as I/O goes, look at NXP's SCC2692 dual ACIA for serial connectivity (used with a Maxim MAX238 to take care of the the TTL to RS-232 voltage levels) and a Maxim DS1511Y+ for a timekeeper.  Maxim will sample in quantities of one piece, so you might be able to get some of this stuff for free.

Hmm, that's good to know. I think I'll at least see if I can get ahold of them...

QuoteSpeaking of RAM, 32K x 8 SRAM is real cheap and can be gotten in a PDIP package, which is easier to work with than an SOJ package with its 50 mil pin spacing.  You can connect A0-A14 of the SRAM directly to the MPU's A0-A14 address lines, and connect the /CE pin on the SRAM to the MPU's A15 line.  With that arrangement, any address below $8000 will result in the MPU sinking A15, which will enable the SRAM and map it into processor space.  If the address is $8000 or higher, A15 will be high, /CE will be high, and the SRAM will tri-state.  Simple.

Well, I actually already have 128KB of SRAM in a DIP package, but I am using the A15 trick, with some assorted logic to control what part of the 128KB the 32KB window is looking at. I might hook it up without the mapper logic at first, though, just until I verify that it's working.

QuoteBe sure to use 74ABT or 74AC logic to minimize gate propagation delays.  ABT logic runs down in the 6-10 NS range and AC logic is only slightly slower.

Well, the chips I have on hand are in the 7-14ns range, but I did add the numbers up and it looked like the memory mapper for the SRAM (the slowest part) still came in fairly well under the 200ns cycle time. Fortunately, if it's not fast enough to avoid problems, TTL is cheap; I could probably replace the entire setup with pocket change plus shipping.

QuoteGate part numbers to consider are 74AC00 (NAND), 74AC04 (NOT), 74AC08 (AND),74AC32 (OR) and 74AC138 (3-8 decoder, used for selecting I/O chips).  All of these are readily available from sources such as Mouser and Digi.

Indeed. Digikey's generally reasonable with prices (and, as a bonus, right in my home state.) I'm using a 3:8 decoder for dividing the top half of memory, and a 4:16 for dividing up the I/O area.

QuoteDon't try to build this thing by slobbering wires all over a Radio Shack perf board.  If wiring errors don't get you, excessive distributed capacitance or cross-talk between signal paths will.  This is where wire-wrap or a PCB pays off.

Duly noted. I'm definitely going to look into ExpressPCB when I've got the design closer to completion; wire-wrap's a little scarier of a proposition, but still doable.

QuoteIf so, plug in the chips and start testing!  You might want to consider a NOP generator (http://6502.org/mini-projects/nop-gen/nop-gen.htm) to plug in in place of the EPROM to verify circuit operation.

This is a terrific idea, many thanks for it.

Quote from: commodorejohn on October 14, 2009, 03:28 AM

Quote from: BigDumbDinosaur on October 14, 2009, 02:58 AMOne thing you should probably consider is starting out with a simple system with a basic memory map.

Actually, I think I might do this. I was looking through my assorted scavenged stuff, and it looks like I have some extra components that should be close to enough to build a simple test system around a 6507 I pulled from a broken Atari; I figure I can divide up the 8KB address space into 4KB of RAM, 2KB of ROM, and some very simple I/O without too much complexity.

Why would you want to monkey with something as lame as a 6507?  You'll have to generate a two phase clock, you'll be trying to interface NMOS logic with CMOS logic, the address space sucks, timing will be a pain in the katushka, etc.

Quote

QuoteSince you mentioned you ultimately wanted to build a more elaborate unit based on the '816, why not get acquainted with it right off the bat?

I'd still like to keep it as an 8-bit system, just for the sake of things, but I'll consider this.

The '816 powers up in 8 bit, 65C02 emulation mode, so you aren't forced into writing anything in 16 bits.  The circuit interfaces are almost identical.

Quote

QuoteSpeaking of RAM, 32K x 8 SRAM is real cheap and can be gotten in a PDIP package, which is easier to work with than an SOJ package with its 50 mil pin spacing.  You can connect A0-A14 of the SRAM directly to the MPU's A0-A14 address lines, and connect the /CE pin on the SRAM to the MPU's A15 line.  With that arrangement, any address below $8000 will result in the MPU sinking A15, which will enable the SRAM and map it into processor space.  If the address is $8000 or higher, A15 will be high, /CE will be high, and the SRAM will tri-state.  Simple.

Well, I actually already have 128KB of SRAM in a DIP package, but I am using the A15 trick, with some assorted logic to control what part of the 128KB the 32KB window is looking at. I might hook it up without the mapper logic at first, though, just until I verify that it's working.

See the attached example of RAM, ROM and I/O decoding.  The example places RAM from $0000-$CFFF, so you can use A0-A15 of your SRAM, with your I/O at $D000 and ROM at $E000.  It'll be more flexible than what you are contemplating, and more like what a real system would be.

Keep in mind that you *MUST* qualify all writes to PHI2 (clock high).  The address bus cannot be considered valid otherwise and a write to RAM, in particular, will go astray.  That's where that flip-flop clock circuit I showed earlier comes in handy.

Also attached is a pic of a PCB I designed that has a 65C816, 2692, 128KB SRAM (the small SOJ package in the middle), two RS-232 ports, a Dallas real-time clock and the flip-flop PHI2 clock generator.  The board is 6.75 inches wide and 3.125 inches high.  This unit is stable to 10 MHz (highest speed at which I've run it).  It probably won't run much faster due to the 70ns access time of the EPROM.

Quote from: BigDumbDinosaur on October 14, 2009, 12:34 PMWhy would you want to monkey with something as lame as a 6507?  You'll have to generate a two phase clock, you'll be trying to interface NMOS logic with CMOS logic, the address space sucks, timing will be a pain in the katushka, etc.

Not for the main project, for a simple starter board, just to make sure I know what I'm doing. I'd be using the 6507 because I have it on hand and it's not really suitable for much else besides a very simplistic project. If the clock generation's all that complex, though, I might have to re-think.

QuoteSee the attached example of RAM, ROM and I/O decoding.  The example places RAM from $0000-$CFFF, so you can use A0-A15 of your SRAM, with your I/O at $D000 and ROM at $E000.

Well, my design already has RAM at $8000-CFFF, it's just in a separate pair of 8KB SRAM chips, so I have a common area as well as the bankable RAM.

QuoteKeep in mind that you *MUST* qualify all writes to PHI2 (clock high).  The address bus cannot be considered valid otherwise and a write to RAM, in particular, will go astray.  That's where that flip-flop clock circuit I showed earlier comes in handy.

Gotcha.

Quote

QuoteSee the attached example of RAM, ROM and I/O decoding.  The example places RAM from $0000-$CFFF, so you can use A0-A15 of your SRAM, with your I/O at $D000 and ROM at $E000.

Well, my design already has RAM at $8000-CFFF, it's just in a separate pair of 8KB SRAM chips, so I have a common area as well as the bankable RAM.

I was illustrating how it could be done with a single 128K x 8 SRAM (SRAM can be gotten to 512K x 8 in 50 mil SOJ packages, BTW).

I'm presently working on a more elaborate design that will be able to use up to 16 MB of RAM, mapped as 256 separate banks of 48K each, plus common RAM from $C000-$FFFF, with I/O overlaying at $D000-$DFFF and the EPROM overlaying at $C000-$CFFF (low ROM) and $E000-$FFFF (high ROM).  Low ROM will contain a machine code monitor and high ROM will contain a jump table accessible BIOS. As the decoding of a system of that complexity becomes unwieldy with discrete logic I will use a CPLD to do what would otherwise take a gazillion gates.

What I have in mind for this mess will be a UNIX-like kernel and the utils to go with it.  The machine architecture will lend itself to multitasking and with judicious use of the 65C816's /ABORT line, I can implement true hardware memory protection.  I'm doing this because I've been banging away at UNIX for some 30 years now and always wanted to try to run it on a 65xx processor system that can actually do something useful.  :D  This will be one of my retirement projects.

Ah, nice. If you do get Unix running on the 816, I think I might try for a compatible system when I get around to doing a project with mine...

QuoteAh, nice. If you do get Unix running on the 816, I think I might try for a compatible system when I get around to doing a project with mine...

*** UNIX-like kernel ***  :D

Only software that has been certified by The Open Group can truly be called UNIX.

Having quite a bit of knowledge of UNIX internals, I have a fairly good idea how to implement a similar kernel on 65C816 hardware.  Something like it could probably be tried with the 65C02, but lacking a 16 bit relocatable stack, the 'C02 would be hamstrung in several ways.  Also, hardware memory protection would be more difficult to implement, as a number of memory-access qualifying gates would be needed to do what the '816 /ABORT line does.

Another significant advantage of the '816 in this sort of thing is the 16 bit wide registers and the hardware-implemented block move functions (MVN and MVP).  16 bit mode means about 60 percent fewer clock cycles to copy data from one place to another and if a linear move is feasible, MVN and MVP can do it in one clock cycle per byte.  Moving, say, 32K would require about 3ms on a system running at 14 MHz, assuming no memory wait states.

Right now I'm fooling around with my SBC V1.0 design (PCB illustrated above) to work out some basic coding for the 2692 dual ACIA and the Dallas 1511 RTC.  The latter has a timer that can be set up to generate an IRQ at any desired interval down to 10ms.  10ms corresponds to a 100 Hz jiffy IRQ, so I'm sure you can see where I'm going with this (UNIX jiffy IRQs occur at a 100 MHz rate).

In the near future, I will be posting some of this at the 6502 website (http://www.6502.org) for comments,  barbs, etc.  :D

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.

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.

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.

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

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

Quote from: BigDumbDinosaur on October 15, 2009, 02:51 PM
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 (http://videocam.net.au/fcug)

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

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

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

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

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.

Quote from: commodorejohn on October 16, 2009, 12:50 AM
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.

QuoteHmm. 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.  :D

Quote from: commodorejohn on October 16, 2009, 12:50 AMBoth 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 (http://videocam.net.au/fcug)

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

     If you want a paper computer, go to

http://www.erikschubach.com/vintage/sx-64-paper-model.php (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 (http://videocam.net.au/fcug)

Quote from: RobertB on October 16, 2009, 07:58 AM
     If you want a paper computer, go to

http://www.erikschubach.com/vintage/sx-64-paper-model.php (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 (http://videocam.net.au/fcug)

Yes, but can you network them?  :D

Quote from: BigDumbDinosaur on October 16, 2009, 01:37 AMThe 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.

QuoteHowever, 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 (http://videocam.net.au/fcug)

Quote from: BigDumbDinosaur on October 16, 2009, 12:42 PM
Yes, but can you network them?  :D

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 (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 (http://www.homecomputermuseum.de/comp/14.45_de.htm)

for your very own PET 2001 (pdf).  :)

Quote from: commodorejohn on October 16, 2009, 03:59 AMWell, for a paper computer it's not too bad ;)

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

Memory Map (http://bcstechnology.net/sbc/sbc_p1.gif)
MPU Interface & Chip Select Logic (http://bcstechnology.net/sbc/sbc_p2.gif)
RAM, ROM & I/O (http://bcstechnology.net/sbc/sbc_p3.gif)
External Interface (http://bcstechnology.net/sbc/sbc_p4.gif)

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

Printed Circuit Board (http://bcstechnology.net/sbc/sbc_pcb.jpg)

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

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

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

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.

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

Quote from: commodorejohnNot 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.

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.

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.

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

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.

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  :)

Quote from: Hydrophilic on September 17, 2010, 11:30 AMThat'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.

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

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

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

Quite cool :) SCSI, though? Really? Whew.

*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!

Quote from: commodorejohn on September 17, 2010, 10:25 PM
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.

Quote from: airship on September 18, 2010, 06:28 AM*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 (http://en.wikipedia.org/wiki/Idiopathic_thrombocytopenic_purpura) is under control.

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

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.

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.

Quote from: airship on September 19, 2010, 05:47 AMUnfortunately, 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 (http://wyse.vecmar.com/) 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.

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.