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

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 for comments,  barbs, etc.