Close

Does this project spark your interest?

Become a member to follow this project and don't miss any updates

Software-Defined 6502 Computer

"Propeddle" is a single-board computer kit with a 6502 controlled by a Propeller.

1.5k 2 31 17

This project was created on 05/31/2014 and last updated 2 months ago.

Description
Have you ever wondered what it would be like to build a computer from scratch, and make it work the way you want? Before personal computers such as the Commodore PET-2001 or the Apple 2 became available in the late 1970s, the only way for an individual to own a computer was to build one yourself. And every self-built computer could be unique, customized to the wishes and interests of the person who built it.

The ability to build a computer from scratch, and having a deep understanding of how it works, is (arguably) a lost art nowadays. The Propeddle tries to change this. It is an open-source electronic kit, available soon (ETA end of June 2014) from tindie.com. It only uses through-hole components (no SMD) so it should be easy to solder together even for those who have limited soldering experience. You can also purchase it pre-assembled for a small extra charge.

For more information, see the official website: http://www.propeddle.com
Details

The 6502 and the Propeller are connected via a few glue-logic chips. The Propeller has 32 digital I/O pins and they are all in use; many of them are used in more ways than one. The Propeller controls the 6502, and enables the SRAM memory chip.

The Propeller generates the clock pulses for the 6502, at a maximum rate of 1MHz. During the first half of each clock pulse, the 6502 doesn't use the data bus, so the Propeller can use this time to enable two 74HC244 octal buffers to connect to the address bus. It can use the address to make decisions about what to do during the second half of the clock pulse, for example if the 6502 is in the process of writing a byte into the screen buffer, the Propeller can catch this write and put the byte in its own memory to show a character on the screen.

Signals such as interrupts and Reset can be generated by the Propeller by using a 74HC574 octal D flipflop. During the first half of the clock pulse, the Propeller puts the signals on the pins that are connected to the '574 and clocks the flipflops so that the updated signals will be sent to the 6502 continuously even though the Propeller only updates them once per clock pulse.

The RAM chips is connected to the data bus and address bus of the 6502 and its Chip Select line is permanently active; however the two pins that control whether the RAM reads or writes a byte from or to the data bus are under direct control of the Propeller. When the 6502 accesses a memory area that's mapped into the Propeller (such as a video buffer), the Propeller just needs to make sure that the RAM chip doesn't get activated at the same time.

The 6502 has to boot from a memory area that's initialized with data before the 6502 starts. This can be done in two ways: The first way is to simply map the ROM area into the Propeller. The second way is for the Propeller to write the ROM image to the SRAM chip before starting the 6502. However, the Propeller doesn't have direct control over the address bus and the 6502 can't start until there's something in memory. 

This problem is solved by a clever algorithm that generates a Reset or NMI on the 6502. The 6502 retrieves a pointer to a location to start executing a Reset or NMI handler, and the Propeller intercepts the retrieval of that pointer to send the 6502 to a location where the code needs to be stored. During the first half of each clock pulse (when the 6502 isn't using the data bus but an address is already available), the Propeller puts the byte to store onto the data bus, and enables the Write line on the RAM chip to store the data. Then during the second half of the clock pulse, it disables the RAM chip and generates dummy instructions for the 6502. So the 6502 thinks that it's busy doing nothing to handle the Reset or NMI, but the Propeller is storing data into memory behind the back of the 6502.

At the time of this writing, the download algorithm hasn't been totally debugged yet, but I've been successful in setting up an emulator for the Apple 1 and mapping Ken Wessen's Krusader ROM into 6502 memory which makes it possible to write programs in Assembly language or Basic. See http://youtu.be/8BCoQepmyYU for a demo. This is just the first emulator of an existing system. More emulators for other systems will follow, and of course it's possible to design a new system that's not based on any pre-existing hardware at all. Furthermore it's possible to use an expansion bus to connect hardware that might be too difficult to emulate with the Propeller.

Project logs
  • Download Routine Working

    4 months ago • 0 comments

    The code that Propeddle uses to download data into the SRAM chip "behind the 6502's back" as described in the project description, was written over two years ago but never tested. I'm pleased to report that with a few minor bug fixes and improvements, it works now. The latest version of the software that's in Github downloads the test program or Krusader ROM image into the SRAM, and then resets the 65C02 without mapping the ROM areas to the Propeller hub memory (as it did before).

    Mapping Hub memory into 6502 memory space using the Hub Cog module was an easy way to get the system up and running, but the ability to download data to the SRAM chip instead is extremely important: With working download code (which is part of the Control Cog), it's no longer necessary to run a Hub Cog, and it's no longer necessary to keep the ROM image in memory while the system is running.

    One feature I want to add is the possibility or downloading the SRAM from EEPROM (particularly the part of the EEPROM that isn't used by the Propeller). I kinda prepared for that possibility, but it's not implemented yet.

    Another feature I'm planning to implement is reading data from SRAM and storing it into hub RAM or into the EEPROM. This will be trivial to do, and will be essential to emulate external storage devices such as floppy disks.

    Storing ROM data into the SRAM chip is enough to make it work, but really there should be a way to keep the 6502 from accidentally overwriting any memory that should be read-only. That's where the RAM Cog module comes in: it starts a cog that monitors the address bus of the 6502 and may block read or write access (or both) to the SRAM chip by making the RAMOE and/or RAMWR lines high.

    But I think the next thing that I'll do is finish (or rewrite) the Theory of Operation page on the website, so it explains how this magic download software thingy works.

    ===Jac

View project log

Discussions

Adam Fabio wrote 4 months ago null point

Old and new meet in this great board! Awesome work Jac - Thank you for entering The Hackaday Prize! I'd love to see some demos of the Propeddle connected - Think you could load up the hackaday retro edition? http://retro.hackaday.com/

Are you sure? [yes] / [no]

Jac Goudsmit wrote 4 months ago null point

Hi Adam, and thanks for your kind words!

All the ways that I can think of to show the Retro website on Propeddle in the current configuration, I would call cheating: I could download the file into the project and compile it into the Propeller EEPROM, or I could configure the virtual Apple 1 hardware as terminal and just print everything from the keyboard to the screen, and copy the web page to the serial port on my PC.

The proper way to do it, in my opinion, is to set up a configuration that can run LUnix (that's not a typo -- look it up) or GeckOS. Those are operating systems written for the 6502 which work a lot like Unix. They have a TCP/IP stack, a Telnet client and other goodies that should be capable of downloading the Retro website and others straight from the Internet without much help from a PC (other than a SLIP or PPP proxy server to convert Ethernet to serial).

One of the things I will do in the near future is to create emulators for the early Commodore computers such as the PET-2001 and the CBM-8032, because those were the first computers I ever used. GeckOS already works on those machines; LUnix doesn't, but may be easy to port. I may create a machine that's optimized to run LUnix, who knows.

In short: the Retro website is definitely something that can be done in the future, just not right now, unless I cheat.

Are you sure? [yes] / [no]

Similar projects