Why not the W65C134S

[whartung]

So, what's wrong with the W65C134S.

The packaging is the primary problem, so ideally someone can make a module that mounts the CPU and exposes Interesting Things to, perhaps, a pair of headers, making the package accessible.

But once there, you get a seemingly pretty nice one chip solution, right away, ready to do things. It already has a little RAM, and some I/O, including serial, and the built in monitor.

So, right away, someone could be coding simple machine language programs and get lights blinking and such.

But the nice part, is that all of the other stuff folks want to explore: adding RAM, adding devices, adding decoding logic, all the rest of Garths basic system (I think) CAN be done. It may be a one chip micro controller, but it seems to me it's a fully accessible, fully expandable core that folks can do incrementally complicated things with.

All they lose, is access to the last page of RAM $F000, because it's got the monitor. Hardly a great loss for a starting system. And finally, perhaps some addresses tied to the internal I/O ports. Again, hardly crippling.

But what is key, is that all of the stuff they learning, the signaling, the coding, the architecture, can be applied directly to a "raw" 6502 project.

You can easily see a basic kit that has the essentials to the controller working. Then the next step is a tutorial to add, perhaps, a 32K RAM chip. Then the next can be adding a EEPROM. Then you can add a VIA, or some other chip for I/O stuff. Sure, it's redundant I/O, but if someone wants to explore how its done, it's there ready for them to do it. Let them discretely decode the addresses for these chips. Later, another experiment can have them using a CPLD for that phase instead. Add a sound chip, whatever.

For all I know, you could make the board with 40 pins on the bottom that happens to fit in a 40 PIN socket, and this thing becomes the CPU for a normal 6502 project. When they're all done, they yank this card out and add in a real 6502 chip, and move along.

But the nice thing, is that it's a solid foundation, giving quick results, that can be readily expanded as far as someone wants to go. And it's not taking them down some other path. "Learn this code set, or this cpu, or this family" and then come back to the 6502. Rather it's 6502 from the get go.

Is there anything else I'm missing here? Maybe not all of the 6502 signals come out?

But, sure seems like a pretty nice little start.

[GARTHWILSON]

I like it, and I'd like to see it given more attention. I'll even say that PLCCs are thru-hole-friendly, since thru-hole PLCC sockets come in both soldertail and wire-wrap (high prices on the WW version notwithstanding). My one complaint about the '134 and '265 is that to add any external memory, you are required to forfeit a lot of I/O pins; and you pretty much have to add external memory since you can't program the internal ROM at the workbench and it only has 192 bytes of RAM.

[8BIT]

I know Tony (NightmareTony) has used that and had a lot of issues with the initialization andexternal memory. He was recognized by WDC if I recall for his work on it. There should be some old posts here somewhere... I just don't have time to search for them.

[whartung]

GARTHWILSON wrote:

I like it, and I'd like to see it given more attention. I'll even say that PLCCs are thru-hole-friendly, since thru-hole PLCC sockets come in both soldertail and wire-wrap (high prices on the WW version notwithstanding). My one complaint about the '134 and '265 is that to add any external memory, you are required to forfeit a lot of I/O pins; and you pretty much have to add external memory since you can't program the internal ROM at the workbench and it only has 192 bytes of RAM.

Yea. I count 15 available, which is not quite 2 8-Bit ports, but that includes the 2 sets of PE and NE interrupt port sets and 3 random undefined ports.

It's not a lot, certainly not what you have on yours , but it's not zero.

And, again, the impetus for more RAM is not necessarily a bad thing, I think. Standalone, sans ROM, the chip is not super useful, but it IS functional and capable. Chip w/board, power, serial connector, couple LEDs and push buttons on a bread board -- quick success.

And adding RAM can be the first project.

[8BIT]

8BIT wrote:

I know Tony (NightmareTony) has used that and had a lot of issues with the initialization andexternal memory. He was recognized by WDC if I recall for his work on it. There should be some old posts here somewhere... I just don't have time to search for them.

Here's the discussion from Tony. Seems a CPLD or FPGA might be needed to work out the external memory mapping.

viewtopic.php?f=1&t=833&hilit=65c134


Daryl

[rwiker]

whartung wrote:

So, what's wrong with the W65C134S.

The packaging is the primary problem, so ideally someone can make a module that mounts the CPU and exposes Interesting Things to, perhaps, a pair of headers, making the package accessible.

As Garth Wilson has already stated, there are PLCC sockets available in both solder-tag and wirewrap versions.

whartung wrote:

But once there, you get a seemingly pretty nice one chip solution, right away, ready to do things. It already has a little RAM, and some I/O, including serial, and the built in monitor.

So, right away, someone could be coding simple machine language programs and get lights blinking and such.

But the nice part, is that all of the other stuff folks want to explore: adding RAM, adding devices, adding decoding logic, all the rest of Garths basic system (I think) CAN be done. It may be a one chip micro controller, but it seems to me it's a fully accessible, fully expandable core that folks can do incrementally complicated things with.

All they lose, is access to the last page of RAM $F000, because it's got the monitor. Hardly a great loss for a starting system. And finally, perhaps some addresses tied to the internal I/O ports. Again, hardly crippling.

If I read the datasheet correctly, you don't even need to lose that - CS7B covers the last 4KB as well if the internal ROM has been disabled.

As far as I can see, all of this also applies to the 65C265, too - the main drawback is that the 84-pin PLCC socket is a bit more expensive than the 68-pin socket required for the 65C134.

[BigDumbDinosaur]

Too much integration for this old dinosaur. Having a separate MPU with RAM, glue logic, etc., is much more flexible. Plus, as Garth noted, the '134 has to be mask-programmed, a "feature" that has no doubt reduce its desirability to the folks that manufacture products that use a microcontroller.

[whartung]

BigDumbDinosaur wrote:

Too much integration for this old dinosaur. Having a separate MPU with RAM, glue logic, etc., is much more flexible. Plus, as Garth noted, the '134 has to be mask-programmed, a "feature" that has no doubt reduce its desirability to the folks that manufacture products that use a microcontroller.

How, precisely, does the '134 prevent you from going that route BDD? What signals are missing? As Garth also noted, the masked ROM can be switched away and replaced with an external ROM.

Seems to me, properly configured (and it apparently can be wired this way, say, with jumpers), there is a perfectly, and completely functioning 6502 available to anyone who wants to break it free.

[rwiker]

whartung wrote:

BigDumbDinosaur wrote:

Too much integration for this old dinosaur. Having a separate MPU with RAM, glue logic, etc., is much more flexible. Plus, as Garth noted, the '134 has to be mask-programmed, a "feature" that has no doubt reduce its desirability to the folks that manufacture products that use a microcontroller.

How, precisely, does the '134 prevent you from going that route BDD? What signals are missing? As Garth also noted, the masked ROM can be switched away and replaced with an external ROM.

Seems to me, properly configured (and it apparently can be wired this way, say, with jumpers), there is a perfectly, and completely functioning 6502 available to anyone who wants to break it free.

Seems to me the '134 is actually more flexible than the '02 - it has a lot of built-in I/O and a ROM monitor - both of which can be configured away at will.

[BigDumbDinosaur]

whartung wrote:

How, precisely, does the '134 prevent you from going that route BDD? What signals are missing? As Garth also noted, the masked ROM can be switched away and replaced with an external ROM.

Seems to me, properly configured (and it apparently can be wired this way, say, with jumpers), there is a perfectly, and completely functioning 6502 available to anyone who wants to break it free.

Lessee...we have to attach an external ROM to have something other than whatever WDC ships in the unit. Pardon me for being dense, but I fail to see any value in such an arrangement.

rwiker wrote:

Seems to me the '134 is actually more flexible than the '02 - it has a lot of built-in I/O and a ROM monitor - both of which can be configured away at will.

After configuring away the I/O and ROM what do you have left? An embedded microprocessor with no way to talk to the outside world. So then you're back to adding ROM and I/O using (gosh!) more chips. I can do the same thing with a 'C02 (or '816) a GAL, a ROM, a piece of SRAM and something to handle I/O. It'll be much more flexible and I can use any I/O I want with having to work around the limitations of a canned MPU sitting behind logic that I can't control. Incidentally, I challenge you to attach a SCSI controller like what I have with my POC unit to a '134 or '265.

I think you guys are not only missing the point but are going in the opposite direction of what a true 6502 SBC is all about. If you are intent on using a microcontroller there are much better choices.

[BigEd]

You miss the point, I think. If we can use their rom as a boatloader then we have side stepped the problem of a newbie needing a programmed rom.

Each of these threads is considering a different approach of dropping or tackling a particular challenge. It doesn't really help to suppose that each thread needs to address the same set of questions as to how it falls short of a do-everything machine. That's not what we're trying to do here.

Cheers
Ed

[whartung]

BigEd wrote:

You miss the point, I think. If we can use their rom as a boatloader then we have side stepped the problem of a newbie needing a programmed rom.

Exactly. It's self bootstrapping. Not only is it self bootstrapping, it's in production, and in stock at the typical internet retailers.

BigDumbDinosaur wrote:

Lessee...we have to attach an external ROM to have something other than whatever WDC ships in the unit. Pardon me for being dense, but I fail to see any value in such an arrangement.

You have to do that with a normal 6502. The difference is that you don't have to do that on day 1 just to get a light to blink.

Quote:

After configuring away the I/O and ROM what do you have left? An embedded microprocessor with no way to talk to the outside world. So then you're back to adding ROM and I/O using (gosh!) more chips. I can do the same thing with a 'C02 (or '816) a GAL, a ROM, a piece of SRAM and something to handle I/O. It'll be much more flexible and I can use any I/O I want with having to work around the limitations of a canned MPU sitting behind logic that I can't control. Incidentally, I challenge you to attach a SCSI controller like what I have with my POC unit to a '134 or '265.

As far as I can tell, all of the signals of the CPU are available externally. I asked what signals from the original chip were not available. So, while the CPU is embedded, it can be incrementally exposed until you've exposed it all to the outside, ready for whatever awaits it there (such as a SCSI connector).

I don't know how many I/O pins your SCSI connector needs, but even after exposing the internal CPU there's still 15 pins of I/O available, plus a UART on the 6502 version.

Quote:

I think you guys are not only missing the point but are going in the opposite direction of what a true 6502 SBC is all about. If you are intent on using a microcontroller there are much better choices.

Well, let's see.

With a single chip, you get an honest to goodness 6502, a serial interface, some RAM, a free Monitor that lets you download code, and I/O ports. So, with a single chip, power, and a serial cable, you can have 6502 code blinking an LED. That's pretty cool, and assembly can be done in an afternoon.

Then, add a 32K RAM chip, and a little bit of decode logic, and you get the same chip, but more RAM. So, now you've got a machine that can not only blink a light, or whatever, but you can download a BASIC, or Forth, or whatever, and work with it using your serial terminal and keyboard. From start to boot prompt, downloading and running BASIC or Forth is probably less than 10 seconds.

That's a cool little project right there, taking a working machine, and wiring up and adding the decode and RAM chip. At the end, you have an even more functional machine, but it's still a slave to the host for software.

Next, the user buys a PROM programmer, and you tweak the existing decode logic to add an EPROM of some kind. Now you can burn the BASIC in to the PROM, and it's a self contained SBC with a serial port, and some I/O. It even boots the BASIC, skipping the monitor completely. Blinky lights driven by BASIC. Another incremental step in circuit design and tooling for the user.

Next, you present how with minor work, some remapping of the decode logic, and setting of a configuration bit on the chip, you have now replaced the monitor ROM with your own. So now you have full access to the memory space, save for those parts that are using the (still configured) internal ports.

Next, you can perhaps redo the circuit design for the EEPROM to make it self programmable. Boot from the embedded monitor, download the programmer loader and the code to burn, and now you no longer need an external programmer. You could do this as the previous step, but it's arguably even more complex, so maybe it's not appropriate. But another incremental increase in functionality.

From there, you can add another UART, or another VIA, or whatever. You can also REPLACE the internal ones with the external ones.

And by the time the user gets to this point, the idea of swapping in a normal CPU rather than the micro controller is straightforward. They're already using all of the control signals, they have all the theory, they have a WORKING implementation of the support circuits and chips, etc. You might even be able to design a board that has room for both the 134 socket and the 6502 socket, and when they get to the end, they can swap them out.

What you get, is you get quick success, and quick turnaround, and continual improvement as you explain the new complexities introduced by each step.

Step 1, soldering the chip, oscillator, connectors, and perhaps some jumpers on to a board, gives them real success and results right away. It's low risk, and little to go wrong from bag of parts to a monitor prompt on their PC, and from there to some blinking LEDs. And none of what they're learning, about techniques, tools, architecture, and software is lost. It's ALL 6502, and remains so throughout the entire project.

And they get to take it as far as they want and find interest, yet rewards them all the way. With barely a need for a multimeter. That's the really awesome part of this, is that you basically never have to throw anything away. It becomes an instructional task of taking the capabilities of the micro controller and exposing them one by one, while it's still a running machine the entire time.

What doesn't this teach them that you want them to learn?

[8BIT]

whartung wrote:

Next, the user buys a PROM programmer, and you tweak the existing decode logic to add an EPROM of some kind. Now you can burn the BASIC in to the PROM, and it's a self contained SBC with a serial port, and some I/O. It even boots the BASIC, skipping the monitor completely. Blinky lights driven by BASIC. Another incremental step in circuit design and tooling for the user.

You could probably bit bang the 65134 IO to program an EEPROM directly - no need to buy a programmer. Then, you can hang it on the bus and run it.

[whartung]

8BIT wrote:

You could probably bit bang the 65134 IO to program an EEPROM directly - no need to buy a programmer. Then, you can hang it on the bus and run it.

Yea, I don't know what's necessary to get the chip in the right mode for programming, and to get the data to it, or how any of that works.

[Michael]

whartung wrote:

With a single chip, you get an honest to goodness 6502, a serial interface, some RAM, a free Monitor that lets you download code, and I/O ports. So, with a single chip, power, and a serial cable, you can have 6502 code blinking an LED. That's pretty cool, and assembly can be done in an afternoon.

I tried to bring up a '134 in single chip mode awhile ago without success. You need a 32768 Hz crystal and a clock source which I provided from a PIC microcontroller plugged into the socket on the left. The PIC also provides the reset signal.

The plan was to get it working in single chip mode and then use a pair of CLC (configurable logic cell) modules in the PIC for the phase 2 qualified /rd /wr lines for a 32-KB RAM in the right most socket. Then the PIC would use the '134 monitor to load RAM with monitor, basic, whatever, via serial at "power up".

I hope to get back to this soon.

Cheerful regards, Mike...