Getting young people into 6502

[Tor]

BigDumbDinosaur wrote:

Again, just my two cents worth, but I think everyone who is pushing the FPGA/Propeller/Raspberry PI, etc. approach is completely missing the point of creating a beginner's kit.

It isn't really fair to lump the Propeller in with a FPGA or Raspberry PI - certainly not the latter. Or Arduino. If you're going to skip the logic gates for something else then the Propeller would be as close to bare metal as you could get. It has much of the eighties' approach in it (and the designer wanted it that way). You work with pins and serial and counters and logic, in assembly as much as anything else, and you're intimately close to what you're doing (e.g. feeding clock and other signals to the 6502). I'm not saying that it's a better approach than using the traditional logic gates and VIAs etc., just that it shouldn't be compared to using a Pi, for example.

-Tor

[BigEd]

I had a thought. Someone with a strong electronics bias might see the bare board of a Raspberry Pi or Arduino, and think "Great, an electronics board! What's on there, what is socketed, where are the bypass caps... wait a minute, this is all nailed down! There's nothing to do!" and that would be a mistake. If price wasn't a primary concern, these devices would have smooth plastic cases, exposing only the connectors. They are both devices which exist to be programmed, and to have things hooked up as peripherals. They are not electronics kits!

[enso]

I think there are several distinct categories of going back to basics here.
-Building computers from discrete logic chips, and understanding how they work
-Programming bare-metal machines without GUIs and giant software infrastructures
-Doing anything outside the Microsoft/Apple proprietary domain
-Retrocomputing and restoring old machines
-Using small stand-alone machines (R-Pi, arduino, etc) for projects
-Learning to build minimal custom systems FPGAs
-FPGA retrocomputing
-6502 coding on emulators

That's just skimming the top of my list. Many of these are not really compatible, and we can spend a lot of time calling each other names for not understanding the obvious. However, all of these are good things. There is no reason to discourage a young person excited about modding some NES game from messing with an emulator.

I think we should not argue about the 'authenticity' of any of these (and many other) pursuits and welcome and support anyone interested in this stuff. The thing that joins us is the love of (or curiosity about) the original 6502 chips and systems, and the desire to have them in our lives in some form, even if they are modernized in some way.

This forum is one of the most supportive places I've seen on the Internet. Let us keep it that way.

As for a minimal real 65C02 system, I think Garth has it pretty much down. Perhaps we can agree on that. I'd be happy to work with anyone interested on an open PC board design, a DIY kit, or assemble a few boards for a good cause. Then we would all have a reference hardware platform, be able to help newcomers by developing a code base, etc.

[barrym95838]

enso wrote:

... However, all of these are good things. There is no reason to discourage
a young person excited about modding some NES game from messing with an
emulator.

I think we should not argue about the 'authenticity' of any of these (and many
other) pursuits and welcome and support anyone interested in this stuff. The
thing that joins us is the love of (or curiosity about) the original 6502 chips and
systems, and the desire to have them in our lives in some form, even if they are
modernized in some way.

This forum is one of the most supportive places I've seen on the Internet. Let
us keep it that way ...

Dang it! I can't seem to figure out how to give a "Thumbs-Up" to your post,
so I'll just do it this way ...

Mike

[BigEd]

Yeah, strongly agree.

[mkl0815]

good conclusion. full ack!!

Mario.

[whartung]

enso wrote:

As for a minimal real 65C02 system, I think Garth has it pretty much down. Perhaps we can agree on that. I'd be happy to work with anyone interested on an open PC board design, a DIY kit, or assemble a few boards for a good cause. Then we would all have a reference hardware platform, be able to help newcomers by developing a code base, etc.

This sounds good to me, all I ask is that whatever the design is, it use modern, available, off the shelf parts. And by "available" I mean a vendor, not eBay.

Unless you're selling kits, presenting an up to date parts list that you can get at Jameco, or whatever, would lower barriers to adoption.

Also, I've seen in the past, folks talk about the basic board and next thing you know, they're off in the weeds, all in different directions, until all of the discussion is NOT about the basic board.

The thing I liked about the Propeller solution was that the chip turned in to a super Multi I/O chip (along with the decoding logic). How it was done internally, within the Propeller, is irrelevant. Few people care what goes on inside of the VIA chip, or any other parallel/serial chip. What they care about is the functionality it provided.

So, in the end, your board had 4 chips that conveniently matched the block diagram: CPU, ROM, RAM, I/O.

Also, it appeared, that in the end, you had a simple device that was readily programmed with a minimal toolset. A usb-serial port (which you'd need anyway to talk to the machine) and "COPY PROGRAM.BIN CON:" on boot to load it.

The user friendly features that simplify development and use take chip count. Requiring an EPROM burner, eraser, ZIF socket, etc. just to get the code over to blink the light, it just not tenable in todays day and age. Adding the display and hex pad ala KIM-1 adds a lot more complexity to the board, so, as much as I like the KIM, I don't think it's appropriate for THIS project.

Having a device that is programmed and accessible over a serial port, with an I/O header that you can wire up to a breadboard to blink lights, click relays, and spin motors, that's a win. It's a little more complex because of the separate CPU/RAM/ROM compared to a modern SoC. But the usability is there. And that's what needs to be a prime criteria.

[enso]

Here is a brief analysis of a 3 different options.

1) WDC 65C02, RAM, ROM, discrete logic IO decoder.
2) WDC 65C02, maybe RAM, 'magic chip'
3) FPGA

1) WDC 65C02, RAM, ROM, discrete logic IO decoder.
Pros:
- Old-school DIY - build and learn.
- All off-the-shelf easy-to-source parts.
- Kit possible
Cons:
- Programming ROMs requires special equipment and long turnaround.
- Hard to modify hardware (real-world chips required to add features)

2) WDC 65C02, RAM, 'magic chip'
Magic chip may a Propeller, AVR or PIC with on-board flash, fast enough to emulate ROM and IO.

Pros:
- Still close to 'real' hardware
- Kits possible
- Relatively easy and fast to program the 'ROMs'
- lots of free IO, SPI, analog etc.
Cons:
- More complexity (to modify system)
- An extra processor to program and learn
- Reliance on third-party chips and development tools
- Hard to modify hardware (real-world chips required to add features)

3) FPGA
Pros:
- Obsolescence-free
- Any non-analog IO possible
- Updates can fix hardware issues
- Faster than any 'real' hardware
- Any reasonable system, from a basic design to a full retromachine possible
- Advanced hobbyists can share hardware designs easily
- ROM development/testing is painless as ROM is really RAM (committing to bitstream is a little more involved)
Cons:
- No kit
- Complexity (to modify system)
- Programmable hardware is a different skillset with a steep learning curve
- Lack of opensource tools, reliance on FPGA-maker

Here we probably find ourselves leaning towards one of the above. Let's look at it from the point of view of a newbie user.

1 and 2 may come as a kit, providing a learning and 'bonding' opportunity. There is something to be said for building your own system from parts.
3 will have to be purchased assembled.

Once the user has a working system, they will do some messing around with it. All of the above will provide a similar experience. Working with an assembler, a BASIC interpreter, C or Forth will take some time to assimilate. If the user is still with us at that point, they will probably try to incorporate their system into some project.

What next?
1 Requires hardware work to do anything, no matter how simple, including making a new ROM to boot directly into custom code.
2 Requires learning how to program the 'magic' chip in order to expand IO, remap the system or change the 'ROM'. Expansion is limited to what's available on the chip.
3 Requires learning Verilog or VHDL and setting up a complicated development system to make changes.

However,
1 is pretty much a fixed system that is pretty time-consuming to modify. Any modifications are pretty much permanent. There is no 'downloading' of hardware.
2 is relatively flexible - multiple configurations can be kept around, easily reloaded. Downloadable projects make it easy to change the system.
3 is totally flexible - just like 2 but more so as libraries of entirely different hardware may be loaded.

In terms of cost, it's pretty close. 2 dispenses with ROM, RAM and IO in exchange for a SOC of probably the same cost. 3 dispenses with everything. Over the lifetime of the user, 2 and especially 3 are more flexible and adaptable to future environments.

So here we are. Three different directions. Probably the same initial user experience - a board that connects to a PC with a serial port. A very different lifecycle, however.

[8BIT]

Not that it matters to me, don't forget the small class of microcontrollers that can emulate a 65C02 AND provide onboard RAM, ROM, and IO.

http://sbc.rictor.org/avr65c02.html

Once the boot loader is installed, the user can re-configure the entire platform via a standard RS-232 link. This includes a new ROM image and/or updates to the emulator itself.

My SBC2OS, EhBASIC, and FigForth are already supported. It would not be too hard to adapt my DiskOS for the 65C02 which would allow access to CF card or IDE storage. One could add support for SD flash cards as well. Ethernet access is already supported.

While the internal IO decoding is fixed, 95% of the AVR's IO system is accessible to the user. This includes EEPROM, timers, serial protocols, A/D, and discrete IO as well. The IRQ system works too. AND, the startup cost is minimal.

I don't think this should be overlooked as a viable option, or bridge, from Software Simulators to silicon.

Daryl

[jac_goudsmit]

enso wrote:

Here is a brief analysis of a 3 different options.

Quote:

2) WDC 65C02, RAM, 'magic chip'
Magic chip may a Propeller, AVR or PIC with on-board flash, fast enough to emulate ROM and IO.

Pros:
- Still close to 'real' hardware
- Kits possible
- Relatively easy and fast to program the 'ROMs'
- lots of free IO, SPI, analog etc.
Cons:
- More complexity (to modify system)
- An extra processor to program and learn
- Reliance on third-party chips and development tools
- Hard to modify hardware (real-world chips required to add features)

I agree with you, enso, but I think in my project the Cons are not as bad as a quick passer-by might expect.

The idea behind my Propeddle design (the one where the "magic" chip is a Propeller) is that it will be useful even to those who aren't familiar with the Propeller, and don't want to learn anything about the Propeller. Although the maximum flexibility may only be accomplished by those who are familiar with both the Propeller and the 6502, I expect to make Propeller firmware available that will make it possible to minimize the Cons in your list.

The complexity of the system is also the source of the flexibility of the system. And in the case of the Propeller, a lot of existing code (video drivers, SPI, I2C, SD card drivers) can be used to build the virtual system as seen by the 6502. The same is probably true for the the other options (in other words: video, SPI, I2C, SD cards etc. can also be done with task-specific hardware or FPGA's) but the Propeller with its 8 cores is able to combine much of this functionality in one chip that costs about $15 (including the required crystal, EEPROM, and serial-to-USB hardware). And if you want 7-segment displays, you can always just emulate them in the video driver

Compare this to e.g. a parallel EEPROM (such as the 28C256) that could be used on the 6502 bus. This is an interesting option but even if some hardware is added to the project to make it possible for the 6502 to re-flash its own EEPROM somehow, it would still be necessary to bootstrap the system with an EEPROM that has something in it, to get the 6502 running. So the users would have to depend on someone else to flash the first image into the EEPROM, or they would require some hardware to put that initial program into the EEPROM themselves. And all of that adds up, in cost and time. With Propeddle, all the user needs is an Internet-connected computer and a USB cable(*).

I have to admit, I don't know much about FPGA's and CPLD's and I didn't want to include one in the project because of this, and because of the fact that I didn't want to learn Verilog or VHDL. But because of this, users won't have to learn Verilog or VHDL either. And they don't need extra hardware to program the FPGA. Besides, I may be wrong, but I think there's no such thing as a through-hole FPGA. Soldering the DIP version of the Propeller is within the grasp of a lot more people than soldering an FPGA.

You're right that, if the system would include a fixed-size [E]EPROM, it would be necessary to change the hardware whenever the user gets the idea of changing the RAM or ROM size. The great thing about Propeddle is that it defaults to a memory map that contains only RAM, which can be pre-loaded with code by the Propeller (with help from the 6502). From there, it's trivial to change some of that RAM into ROM by only allowing the read-pin to be activated by the 6502. Yes, it's necessary to change the Propeller firmware to make these kinds of changes, but theoretically it's possible to implement a lot of architecture decisions for the 6502 side of the system in the form of tables, and those tables can be generated by a PC application or even by the Propeller itself. No programming required.

Even before it's possible to put a 6502 system together with some sort of interactive interface, I intend to provide a library that will hide most of the Propeller-specific complexities, so it should be enough to know C (or C++) to reconfigure your Propeddle-based 6502 system. So even though the Propeller may not be as easy to understand as the 6502, it's won't be necessary to know it thoroughly, either. I'd say that's a good compromise between (a) requiring so much hardware that the project becomes cost-prohibitive, and (b) requiring so much programming knowledge that the Propeller part (or in general: the "magic chip" part) becomes too much of a distraction. But that's just my very biased opinion of course

===Jac

(*) the interface hasn't been finalized yet; I may decide to require an FTDI cable or an SD card to transfer software to the Propeller.

[GARTHWILSON]

I changed the topic title to "Getting young people into 6502", to differentiate from getting them into computers in general, or simply electronics, as our common interest here is 6502 which is the focus this forum is absolutely committed to. The "young people" part of the title was referring especially to teens, as the pre-teen brain is usually not developed enough yet to have the needed reasoning ability, and the 20's bring more independence, both financial and knowing how to reasearch things.

The idea that that the forum would come up with a kit or product is something good that I wasn't expecting. I really was only thinking that some discussion would make us all more aware of possible opportunities to help young people. If we endorse a particular kit or product, we might as well take advantage of something already available if practical, and just add something minor if it needs it. There are already Daryl's SBCs, and Apatco's

6502.org wrote:

Image no longer available: http://ncs.apatco.com/shop/published/publicdata/SHOP/attachments/SC/products_pictures/eb50.JPG

(ignore the spam in the reviews section), and maybe one of WDC's on 65xx.com which I can't find ATM. The idea of having a keypad and display (like the KIM-1 someone mentioned) does add the attraction that although support from a PC is possible, it is not mandatory. A ROM programmer is not required to get going, although if they want to buy one, the ROM is socketted and they can do their own. And to answer this from jac_goudsmit above:

Quote:

Compare this to e.g. a parallel EEPROM (such as the 28C256) that could be used on the 6502 bus. This is an interesting option but even if some hardware is added to the project to make it possible for the 6502 to re-flash its own EEPROM somehow, it would still be necessary to bootstrap the system with an EEPROM that has something in it, to get the 6502 running. So the users would have to depend on someone else to flash the first image into the EEPROM, or they would require some hardware to put that initial program into the EEPROM themselves. And all of that adds up, in cost and time. With Propeddle, all the user needs is an Internet-connected computer and a USB cable(*).

Daryl's EEPROM-based SBC and SBC OS let the ROM be modified by the very computer it's running. It can transfer code to the RAM to run while the EEPROM itself is being written to and is unavailable for the milliseconds needed for the write. No extra hardware is needed. Different ROMs could be provided up front too.

Quote:

You're right that, if the system would include a fixed-size [E]EPROM, it would be necessary to change the hardware whenever the user gets the idea of changing the RAM or ROM size.

Jumper setting would take care of it.

Quote:

And in the case of the Propeller, a lot of existing code (video drivers, SPI, I2C, SD card drivers) can be used to build the virtual system as seen by the 6502.

Not to downgrade the Propeller, but note that some of this is also already available for 6502, like the code on my site for doing SPI and I²C on the 6522. I did find SD card daunting though, as I wrote recently.

To comment on enso's 3 ways: I lean heavily toward #1. It does not involve a second processor type or Verilog. The two cons are not cons at all, because we can supply a pre-programmed ROM or choice of several ROMs that let it work right out of the box. Again, with EEPROM, it can also program its own ROM without separate equipment or even a PC. Although adding features requires hardware, such hardware would plug in via standard pin headers. A ribbon cable could go from the pin headers to even standard breadboards, either solderless or soldered. Since the breadboards won't be handling the processor's own busses but only 6522 I/O, the far less than ideal construction of a solderless breadboard won't hamper the computer's operation. With an ACIA and a couple of VIAs, nearly anything can be connected, which is largely what my circuit potpourri page is all about. It is very flexible, being just a scaled-down version of my workbench computer which has three VIAs, and lots of things interfaced through them. (It also has three ACIAs but I have really only used one in recent years.)

If a solution really had to have a minimum of parts (which I don't see as a necessity), another option would be the 65134 microcontroller. Unfortunately the '134 (and '265) is mask-programmed; and although you can have external ROM and RAM, doing this requires forfeiting a lot of I/O pins.

[mkl0815]

As you may noticed before, I'm also a "fan" of #1. It has the clearest focus on the 6502 with no other CPU involved.
One good starting point could be the following design: http://searle.hostei.com/grant/6502/Simple6502.html
It has a really low chipcount and uses a mc6850 as ACIA, that is much cheaper and better available then a 6551.

All chips a available as DIP, so breadboarding is a good start and for those who want to play further a PCB could be provided at tindie.com, like Unaclocker has done for the eeprommer.

A VIA can also easy be added if needed.

I've looked at the NCS-2056T kit. That's really cool, but too expensive with $180. But the good thing they have is a good documentation. This could be provided as wiki and (if someone would invest the time) also as PDF. If we wnat to start such a project here.

Mario.

[BitWise]

If I was designing a simple 65(C)02 board I'd opt for more RAM and a smaller boot ROM (say 4K) with a simple monitor.

A 32K RAM/32K ROM split is simple from an address decoding perspective but means you need to reprogram (E)EPROMs to make full use of memory or develop your own. Given that you are probably using a more powerful PC as a terminal to the 6502 and you can easily download ROM images. Alternatively include an option for an I2C/SPI memory on the board to copy from on reset.

I'd also use a 128K or 512K SRAM (like the Alliance AS6C1008/4008) and either waste the unused portion (if using simple decoding logic) or bank switch it (if using a PLD for decoding).

[bogax]

I wonder if it would be practical to get a 6502 board
to talk to a PC via SPI through an SD card slot.

Could make for simple hardware on the 6502 side.

[Arlet]

bogax wrote:

I wonder if it would be practical to get a 6502 board
to talk to a PC via SPI through an SD card slot.

PCs don't use SPI to talk to the SD card. They use the MMC/SD interface instead, and they expect a fast responding slave device.

But you could add a SD card slot on an 6502 board, and add a preprogrammed EEPROM to access it, and copy files to RAM and execute them.