Propeddle

Software Defined 6502 Computer

Software Defined 6502 Computer

+menu -


  • Welcome to Propeddle!

    Propeddle Rev8 S/N 800
    The Propeddle circuit board

    Propeddle is a Software Defined 6502 Computer, based on the Propeller Platform. The name is a contraction of “Propeller” and “Peddle”, in honor of Chuck Peddle, one of the engineers who designed the 6502.

    It’s not an emulator and it’s not a replica of any existing computer — it’s something in between. It uses a real 65C02 processor as CPU and a real RAM chip as memory. A Parallax Propeller generates the clock and other signals needed by the 65C02, and it also controls the memory chip. This way, the Propeller determines how the 65C02 “sees the world”.

    Besides some glue logic, that’s pretty much it for the hardware. Other hardware such as video, audio, keyboard and storage may be emulated by the Propeller or can be added as an expansion board. The expansion bus also makes it possible to connect Propeddle to a back plane (motherboard) that makes it work without Propeller.

    You can buy Propeddle online as a kit. All schematics, PCB designs and software are open source (MIT License) so you can also build one yourself, should you be inclined to do so. All components are through-hole so you can even build one on a breadboard. A Propeller Platform motherboard is needed to make Propeddle work, as well as some other hardware to connect peripherals such as a TV and/or a keyboard.

    Propeddle was inspired by the Prop6502 project by Dennis Ferron, for which he got an honorable mention in a Parallax contest in 2008. Thanks for sharing, Dennis!

    More information will appear on this website. Much of this information is also available on the SavageCircuits forums.

    Thanks for reading!

    ===Jac


  • The Brielcomputers.com OSI Replica Project

    Posted on by jac_goudsmit Comment

    When I was at the Maker Faire in San Mateo in May 2012, I met Vince Briel of brielcomputers.com. It was the high point of the day and made the Maker Faire even more memorable than it already was. When I introduced myself, he immediately knew who I was. He knew about Propeddle project and he told me what he was working on: a replica for the OSI 600 “Superboard II”.

    I had to admit that I’d never heard of such a thing, but now I know that the Superboard II was the base for the Ohio Scientific Challenger computers. I’ve seen those before but never worked with them. Ohio Scientific was present at the legendary 1977 West Coast Computer Faire where the “big three” (TRS-80, the Apple-II and Commodore PET) were also announced. While the oldcomputers.net page, linked above, dates the OSI in 1978, this report by David Ahl mentions the Challenger being demonstrated at the show where the other computers were merely announced.

    Vince told me at the Maker Faire how he had the 6502 connected to a Propeller to emulate video, and we discussed my PETSCII driver for Propeddle for a while. We talked about using the RDY line to hold the 6502 while the Propeller was working, and how it wasn’t needed for Propeddle. We also talked about connecting the Propeller to 5V system and I told him Propeddle uses the WDC 65C02S which is able to work on 3.3V like the Propeller.

    A few months ago, Vince and I started exchanging emails about the OSI, and I started learning about the system. It’s actually a fairly simple 6502 system with RAM, ROM, video, a keyboard and a 6850 ACIA. It doesn’t use any interrupts, the keyboard is basically a switch matrix with an address decoder. The ROM has an early version of Microsoft Basic.

    The video hardware on the OSI is a bit weird. It uses a 256-character font in monochrome without inverse video, and the memory is organized as 32×32 characters (1KB total). However, the characters are so wide that on a CRT monitor the leftmost and rightmost characters are invisible, so the editor only uses 25 columns and 25 rows.  Vince asked me for help to implement that in his video driver so I did. And things went on from there.

    The 6502 has to access memory inside the Propeller to display video, and I contributed some code to do this. Vince then proceeded to add more code to let the 6502 access the ROM too. I designed a schematic to map a number of areas in the upper 32K of the 6502′s address range into the Propeller as “virtual memory” so that the ROM could be stored in a contiguous area of hub memory. That way it takes fewer instructions to decode memory operations. I also modified the PS/2 keyboard driver for the Propeller that Chip Gracey (of Parallax) wrote, so that it can be used to emulate the polled keyboard of the OSI.

    By this time, Vince decided that this project (which he had been working on for a while) is now finally in a stage where he’s confident that he can finish it. You can see the work in progress on his discussion list here.

    It’s been an absolute honor and pleasure to work with Vince, on a project that’s almost (but not quite) completely unlike Propeddle :-)

    I hope to see him again at the next Bay Area Maker Faire in May 2013. He promised he’ll bring his prototype and I can’t wait to see it and play with it. I taught Vince some things that I know from the Propeddle project, and I learned some important things that I will use for the continuation of Propeddle. It will definitely be possible to make an OSI emulator with Propeddle, but it will not be the same as “the Briel thing”. :-)

    This entry was posted in Other Bookmark the permalink

  • Of Baby Steps and Binutils

    Hello everyone!

    It’s been quiet for a while again in the land of Propeddle, so here’s a short update.

    A while ago, I wrote an in-depth article about Propeller programming in C, and because of this, I was invited by Parallax to write some documentation for the PropGCC official website. I agreed that I would contribute some articles, but first I want to get Propeddle in a more finalized state, so I can sell it as a kit, and hopefully give a presentation at the Propeller Expo next May.

    I’ve been rewriting the software in C and inline assembler for a while, and currently the code for the control cog is code-complete, and I’m ready to start debugging it with my Logic Analyzer.

    Unfortunately, however, I’m hitting a major snag. Although it compiles without warnings or errors, the machine language that gets generated by the assembler is wrong: the Gnu Assembler (GAS) for the Propeller apparently still has some major issues that apparently don’t affect the C compiler, but generates fixups that are miscalculated for all instructions with immediate source arguments except JMP/JMPRET.

    I had a long look at the Gnu Assembler code today and learned a lot about the architecture of binutils (of which GAS is a part). But the longer I look at it, the more I wonder why it works at all.

    The Propeller uses hub memory and cog memory. All data and program code is initially stored in the hub, and gets downloaded to the cogs to get executed. In the hub, every byte is addressable, but the cogs use 32-bit addressing (every address represents a 32-bit word). When an instruction in the code refers to another item, the reference might refer to the location where that item is stored in the hub, or the location in the cog where the item was copied when execution started.

    When using the Spin language, a reference or pointer to an item always refers to the hub. In assembler, all references and pointers refer to cog memory, except hub instructions. So it makes sense for GAS to store cog addresses into those instructions, and that’s what it does in most cases, but it gets it wrong:

    • Whenever an instruction refers to one or two locations in cog memory and isn’t used in immediate mode, everything appears okay
    • When using immediate arguments with JMP/JMPRET, the assembler stores an immedate value that (apparently) corresponds to the location of the referred label within the module, which is not correct in certain situations because it doesn’t take into account that the actual code may not start at location 0
    • When using immediate arguments with other instructions such as MOV or MOVS or MOVD, the value of the source argument is stored as an immediate value but it’s converted to a cog address only if the label was preceded by .cog_ram.

    I’m going to try a workaround for this (basically by putting the assembly code in a separate module) but I’m probably going to be working on fixing this problem in the Binutils too.

    ===Jac

    [Update: The problems in GAS are now fixed, thanks Eric Smith (maintainer of Propeller-GAS)]

     


  • Status Update

    Hello everyone!

    It’s been a while since I had time to work on the project, so I figured you deserve an update.

    Here’s the short version of my to-do list:

    • Work on documentation
    • Parallax GCC for Propeller
    • New schematic / PCB design tool
    • Improve the schematics to reduce dependencies

    Continue reading →


  • I am today’s Featured Engineer at EEWeb.com!

    I’m excited to announced that I am today’s Featured Engineer on the EEWeb.com website.

    http://www.eeweb.com/spotlight/interview-with-jac-goudsmit

    The interview was submitted in February so the last paragraph is slightly out of date: You can now in fact buy the Propeddle kit although I don’t have an official web shop at this time. Send an email to jac-at-goudsm-dot-it for more information.

    ===Jac


  • Temporary build instructions

    Posted on by jac_goudsmit Comment

    To those who bought a kit at the Parallax Expo:

    THANK YOU VERY MUCH!!!

    I’ve been off the Internet all weekend so I had no way to work on the documentation, and there was just not enough time to get it done today once I got back on the grid.

    I truly appreciate your patience and your trust, it inspires me to keep working on the software, the hardware and the documentation. I assure you, I’m working as hard on it as I can, but unfortunately I have other obligations to my work and my family too. Thank you for understanding.

    What follows is an abbreviated version of the build instructions, without pictures for now. I will post a full version with pictures as soon as I can. Use the rightmost board in my Twitter profile background picture for reference if you wish.

    1. Remove the warning sticker.
    2. Start with the (16) resistors near P0..P15, and then do the (6) resistors around the 65C02. The resistors are small, but there’s not enough space to lay them down so bend one wire and solder them in in “stand-up” fashion. Cut off all the wires EXCEPT the resistor wire that’s near pin 37 of the 65C02. Leave that hanging for now. You will have 3 resistors left over; this is intentional!
    3. Solder the (5) blue decoupling capacitors in the designated places near the IC’s. Cut off the wires but don’t cut the resistor wire yet (if you already cut it before reading this, don’t worry).
    4. Solder the (5) diodes in the designated locations near pin 20 of the 65C02 location. The dark band on the diode (cathode) goes towards the tip of the printed arrows. If you get this wrong, the circuit will not work, so make sure you get this right!
    5. Break the male headers into two pieces of 4 pins and two pieces of 16 pins (if it goes wrong and you end up with more pieces, don’t worry, once they’re soldered they’ll be okay). These headers need to be soldered to the BOTTOM side of the circuit board. The easiest way to do this is to plug the long pins of the unsoldered male headers directly into your Propeller Platform motherboard, and then while the pins are still plugged in, put them through the holes in the Propeddle board and solder them from the top. That way the pins are guaranteed to line up perfectly.
    6. Now, solder the female headers (two 4-pin, two 16-pin) on the top side. If you have another board to plug in on top of Propeddle, you can use the same method as above to align the female headers before you solder them. If you don’t have a board that goes on top (yet), you can also decide not to solder the female headers until you get one.
    7. Solder the IC sockets: do them one at a time and make sure you have the notch on the same side as what’s printed on the circuit board. Solder two corners of each socket first and make sure they’re inserted all the way into the board before you solder all the other pins.
    8. As the sticker said, there is a minor problem with this circuit board: pin 36 is not connected to VCC although it should be. This is why we left the the wire from the resistor near pin 37 uncut: it’s that resistor’s connection to VCC. Bend it over diagonally to pin 36 of the 65C02 and solder it to the 65C02 and cut it off. If you already cut the wire off, simply solder another piece of wire between the resistor and the 65C02 pin and cut it off as needed. Whatever you do, make sure the wire doesn’t touch anything else.
    9. Insert the IC’s into the sockets. You’ll have to bend the pins a little (use your workbench to bend all pins at the same time) to make them fit. I know, the markings on the chips are very hard to read and the smaller IC’s have the same number of pins. To make it easier to recognize the 74HC374, I put it on the foam sideways. The two 74HC244′s are on the foam parallel to the bigger chips. Note, all chips are static sensitive so you probably don’t want to walk around with them on your socks. Just pull them from the foam one by one, bend the pins as needed and insert in sockets.
    10. That’s it! You will notice a couple of unsoldered jumpers and the expansion port connector is not included yet either because there’s nothing that can connect to it yet (I’ll be sure to throw in those connectors with the first expansion boards once they are done). The unused jumpers are to convert the board to 3.3V and to use an original NMOS 6502 (which is not supported at this time but may be interesting for some hobbyists who want an alternative to the 65C02). The extra resistors are to add SYNC and CLK2 connectivity but reduce the video output possibilities; they are also not supported (yet).

    I know some of the soldering points on the circuit board are pretty close together and the solder islands aren’t very big. If soldering is not your thing, or if you aren’t confident that you can solder it together yourself without causing short circuits, contact me I’ll solder it together for you for a small charge plus shipping cost.

    If your Propeddle doesn’t work after you put it together, contact me too (tip: use a flatbed scanner to send me a picture of both sides)! I’ll help you make it run, or I we can arrange for you to send it to me to fix it for you (depending on what’s wrong with it). You will have to pay the shipping cost, though.

    Thanks again.

    ===Jac

    PS I will post code here tomorrow. The code is now online on Github.

    This entry was posted in Build Instructions Bookmark the permalink

  • Theory of Operation, Part 1

    Posted on by jac_goudsmit Comment

    (Note, some details of the drawing are out of date, I’ll replace it as soon as I can)

    This article explains how the Propeddle electronics work in detail. Some generic knowledge of digital electronics, the Propeller and the 6502 are assumed, but even if you’re not familiar with the intricate details, you should still be able to follow this.

    Continue reading →

    This entry was posted in Documentation Bookmark the permalink