L-Star: Software-Defined 6502 Computer

Replicate an Apple-1. Or an OSI Challenger. Or something else.
Design your own 6502 computer by programming it.

Similar projects worth following
Building your own computer and knowing all the details of how it works, is (arguably) a lost art.

This project lets you build a 6502 computer that helps you not just understand, but also control important details of how it works.

L-Star connects a Western Design Center W65C02 to a Parallax Propeller. The Propeller monitors the address bus and data bus, and emulates memory and I/O devices.

The simplest version of L-Star can be built on a breadboard (see the "instructions" section).

L-Star Plus is a kit version of the project with some extra features: it adds a RAM chip, power supply circuitry, and an expansion port.

I no longer work on this project and I don't make the kit available for sale anymore, however there are links to OSHPark and Mouser if you want to buy the PCB and the parts. Go to for more information if you own the kit.

The L-Star project is an open-source single-board computer design that uses a Propeller microcontroller to control a 65C02 processor. You can use it to emulate early 6502-based computers such as the Apple-1 or the OSI Challenger, or you can invent your own 6502 computer.

All the parts that are needed to put an L-Star together are available in through-hole packages, so you can build it on a breadboard, or on a Propeller proto board. Or you can order a kit on Tindie (click on the Tindie link on the project page), which has some extra features such as a 128KB static RAM chip and an expansion port.

Read more »

  • 1 × Parallax Propeller FLiP Mouser part #619-32123
  • 1 × Breadboard Should be at least 50 columns wide
  • 1 × Computer with USB cable that has micro-C connector
  • 1 × Western Design Center WDC65C02S Mouser part #955-W65C02S6TPG-14
  • 1 × SPST Tactile Switch For resetting the 65C02

View all 6 components

  • Minimal L-Star on a Breadboard, and KITS ARE BACK!

    Jac Goudsmit04/18/2020 at 08:42 0 comments

    I intended to get this done last weekend for the 44th birthday of the Apple 1 computer (April 11 1976) but unfortunately it wasn't meant to be. After I had put the circuit together, it didn't work at first. The 65C02 that I was using, had given the ghost, possibly because of me being careless with static electricity. I checked all the wiring first (which took a long time) and when everything checked out, I wrote a short program to slow the 6502 clock down to a crawl of 1 Hz or so, and write the INA input register to the screen on every clock cycle. That finally showed that the address bus and data bus were the same on every cycle, so the 65C02 wasn't running.

    After I replaced the 65C02 with another, everything worked just like it should, but by then it was Tuesday. Then I got some "distractions" from work and family life, and I could finally get back to it on Friday.

    I replaced the instructions section of the project here on Hackaday with instructions on how to breadboard your own L-Star for (probably) less than $50. Have fun!

    Oh, and by the way, I got parts for a batch of L-Star Plus kits. It will be back in stock some time this weekend. YAY!

  • L-Star As a SuperCon2018 Badge Add-On

    Jac Goudsmit11/05/2018 at 19:27 4 comments

    Apple-1 emulator for SuperCon2018 Badge

    I turned my SuperConference 2018 Badge Add-on board into a 6502 computer, so if you're tired of playing Zork on a Z80, you can play Super Star Trek on an Apple 1 emulator.

    I didn't win the badge hacking competition, though I think I might have had a good chance to at least be admired on stage if I would have had 5 more minutes with a soldering iron; the add-on was basically working but it was disconnected from the badge because of a wiring mistake that I didn't notice until after all the soldering stations had disappeared.

    Read more »

  • PET-2001 Emulator Project Started

    Jac Goudsmit06/11/2018 at 20:02 2 comments

    If you've followed me long enough, you know that my original purpose for the #Propeddle: Software-Defined 6502 Computer project was to build a replica of the Commodore PET-2001 and CBM series computers. The PET-2001 was the first computer I ever used, when I was about 11 years old in 1978. And now I've finally made a start on writing a software-defined computer project to emulate the PET/CBM on L-Star. As you can see in the picture, I have a long way to go.
    Read more »

  • Back in Stock!

    Jac Goudsmit05/26/2017 at 06:38 3 comments

    Got parts, got PCB's, getting Prop Plugs in a day or two.

    That means L-Star is back in stock!

    Order here: (or click on the Tindie link on the project page).

  • Some Ideas for the Future...

    Jac Goudsmit01/12/2017 at 23:05 4 comments

    I received the second batch of production boards and parts, so the kit is back in stock on Tindie. Meanwhile, I figured I should write down what the plans are, especially for the website. See "after the break" for some ideas I'm working on.

    First of all, I've been working some tutorials for owners (or those who want to follow along at home) to learn how to "write their own computer" using the C language:
    • The first tutorial/demo proposes a basic framework that defines types and macros to get started, and generates a clock signal "as fast as possible" and lets you observe how the 65C02 reset sequence works
    • The second tutorial/demo shows how to run a separate cog that presents part of the Propeller's hub memory to the 65C02
    • The third tutorial/demo shows how the PIA of the Apple 1 can be emulated in C, and loads the ROM from Vince Briel's Replica 1 to make the L-Star into an Apple 1 emulator.

    The code for the above is already on Github here, but I'm still working on the text that will be posted on the website soon.

    Future Tutorials

    I'm thinking the next tutorials should be:

    • How to convert time-critical code into inline assembler, and how to use a Propeller timer as clock generator.
    • How to use the SRAM chip.
    • How to implement emulation of memory-mapped (text) video, and how to emulate a matrix keyboard, culminating into an emulator of the Ohio Scientific Challenger C1P (also known as the Superboard II or UK-101).
    • How to implement a virtual storage device using the EEPROM.
    • How to make up your own system, maybe running Forth.

    Future Hardware

    I have several ideas I want to work on in the hardware area:

    • Commodore PET emulator: this is what I originally intended the project to do, but it would need a way to generate interrupts at 60Hz or 50Hz and I'm trying to think of a way to do that without adding extra hardware.
    • Acorn Atom (a.k.a. Hob-bit computer) emulator; this should also be possible without extra hardware.
    • An expansion board with 24 (or more) tactile switches and six or eight 7-segment displays to emulate a Kim-1 or Elektor Junior
    • A "Pro" version for advanced experiments: this would probably be a version of the board that doesn't have the I/O and jumpers on board; it would have a right-angle connector for expansion, which would plug into a new passive motherboard (or simply an IDC connector on a ribbon cable) to connect to multiple expansion boards. Or, going slightly further, something resembling RC2014 but perhaps using card edge connectors.
    • A "Pro 16" version that uses a 65C816 instead of a 65C02 and has (say) 4MB of static RAM and runs faster while the CPU is not accessing the Propeller. This could perhaps be used to emulate the Mensch Computer or simply to run Fuzix. You know, just for giggles.
    • A modification to use a PIC microcontroller instead of a Prop Plug to connect it to a host system. This would eliminate the FTDI controller, the one and only chip in the design that's not available in a DIP package, and would make it easier to put the system into an enclosure.

    Are You Still Reading?

    I have disappointingly little time to get all this stuff done, and I hope owners and enthusiasts will step up to help some day. Whether you have a kit or not, if you've read through the documentation and you can think of something you want (me) to do with the L-Star, or if you would like to propose any ideas for expansion boards or software projects, let me know!

  • Now For Sale on Tindie!

    Jac Goudsmit11/08/2016 at 05:34 0 comments

    I received the PCB's for the first production run!

    That means you can now actually buy the project as a kit on Tindie. Click the link on the project page to order.

    I'll be setting up the web site at this week (hopefully), so that new owners will have a place to go to find build instructions, documentation, and maybe even a forum to share what they've done with the system, ask questions, or make suggestions. If it's going to be a lot of work, it means I'm doing it right!


  • Hardware Revision 5: Could This Be the One?

    Jac Goudsmit10/11/2016 at 04:15 0 comments

    After the disaster with Rev. 4 (see the last log), I learned a couple of things and made some changes resulting in Rev. 5:

    Read more »

  • So Much Fail: Building the Rev. 4 Boards.

    Jac Goudsmit09/13/2016 at 07:09 1 comment

    Last Friday, the Rev. 4 boards arrived from OSHPark, and a Purple PCB Day is always a good day. Also, BBC America was doing their Star Trek 50th Anniversary Marathon of all the Original Series episodes and I was the only one home, so this was going to be a fun night of watching the young version of Khan, Zefram Cochrane and the Tribbles, and soldering my project together. Or not?

    Two of these are not like the others...

    Read more »

  • Hardware Revision 4: Now with All the Pins You Need!

    Jac Goudsmit08/28/2016 at 22:08 0 comments

    This weekend I was able to do some work on the hardware of the project again, and I decided to bump the version number, so it is with pride and joy that I announce Revision 4 of the L-Star hardware.

    Read more »

  • Hardware Revision 3

    Jac Goudsmit06/15/2016 at 03:27 2 comments

    As I mentioned in the "Hardware Revision 2" posting, there were some small but significant problems with that version of the schematic and PCB:

    • The ~RAMEN pin ended up in the wrong place on the jumper block, which would make it difficult to use video, a keyboard and the on-board SRAM chip at the same time.
    • With the added on/off switch, the board got a little crowded around the RESET6502 button which made it harder to press the button. Also I didn't like that the buttons didn't line up nicely in the layout anymore.
    • The board still had the old problem that the solder islands for most parts/footprints were a bit on the small side.

    Here's a picture of the Revision 3 layout:

    First of all, I switched the location of A16 and ~RAMEN (and the accompanying 3.3V and GND pins) so that ~RAMEN can be jumpered to P27 which is connected to KBCLK in the "default" configuration. I considered moving things around so that ~RAMEN would be the default for P27 and KBCLK would be an alternative, but I decided it would cause too much confusion so I didn't do that.

    I moved the power LED to a location between the pushbutton switches, so now there should be enough space for a finger to push the button again. I also lined the pushbuttons up, close to the places where they were in revision 1. The LED is in a sort-of-odd place, so far away from the power connector and the power switch, but it's where there was enough space for the traces. I would have liked it on the right side of the board (and the power switch too) because I imagine that side will be pointing towards the user, but that's simply impossible unless I make the board a lot bigger.

    I edited all the footprints on the board and made sure that they all use solder islands with a size that's big enough to solder if you have a non-professional solder iron, or if (like me) you have some old solder tin that doesn't flow as well as it used to do.

    I discovered another oversight that I wanted to fix: the jumpers didn't have the ~RESET6502 signal on them. So I changed the jumper block from 7-by-5 to 8-by-5 and added the signal near the top, where it was easy to line up with the ~RES6502 pin on the expansion port connector. As it turns out, this had a fortunate side-effect: I found out that five 10-pin pin headers are cheaper than two 20-pin headers of the same series (the ones with the green plastic that I got by mistake but look really good and nicely define the color scheme of the project, along with the purple PCB and the red jumpers). This will make it easier to break/cut the jumpers to size for the final kit.

    I also made the footprint of the voltage regulators a little smaller, which allowed me to reduce the board size again, and to line up the power switch with the RESET6502 pushbutton.

    I haven't ordered parts or PCB's yet, because I'm considering another change: I'm thinking of putting the voltage regulators upright, and wiring them up differently so they'll be in parallel instead of in series. This will allow expansion boards to use more power on the 5V rail (the 3.3V regulator is currently fed by the 5V rail) and might reduce heat production because the current only has to go through one regulator instead of two. On the other hand, it might cause other problems like interference and the need for bigger electrolytic capacitors.

    Another change I'm considering is to use a 50-pin expansion header instead of a 40-pin one. You may have noticed that there is just enough space to do that, and that's not a coincidence. A 50-pin header would make it possible to run the video and keyboard connectors to the expansion board, as well as some signals (~BE, A16, ~RAMEN) that I had to leave out because of the 40-pin limit. This would make it possible to design an expansion board that e.g. generates color video and uses the PS/2 keyboard, without the need to add connectors for them to the expansion board. And it would be possible to let an expansion board take over some functions take over some functions that currently only...

    Read more »

View all 14 project logs

  • 1
    A Minimal L-Star on a Breadboard

    These instructions describe how to wire up a minimal version of L-Star on a breadboard, and make it work as an Apple 1 replica. If you would like to know how the Apple 1 works, and you don't have much time or money, this is probably the project for you. And because it's on a breadboard, you can re-use the parts for something else once you get tired of it.

    The Propeller microcontroller that I used for the L-Star project, needs quite a bit of peripheral hardware to make it useful. Parallax, the company that makes the Propeller, recognized this and they make the Propeller FLiP module available (their item number is 32123). The FLiP is more expensive than the Propeller of course, but it not only has the Propeller on board and gives you access to all I/O pins, but it also has an EEPROM, an FTDI chip for USB communication with a computer, a few LEDs for debugging, and a power supply that can use either the USB connection or an external power source as input, and generates 3.3V as well as 5V as output. The photo below shows two FLiP modules: one from the top and one from the bottom.

    The Propeller FLiP and a WDC65C02S (the version of the 65C02 that's still in production) are almost all you need to make a working Apple 1 replica. All that's missing is a breadboard with at least 50 columns, 2 resistors of 10K, and some wire.

  • 2
    Getting Started: Mount the FLiP module and the WDC65C02S

    Mount the FLiP all the way to the right of the breadboard, with pin 1 (indicated by the triangle) pointing to the bottom left. The USB connector of the FLiP is at the edge of the breadboard that way so you can easily connect it. Leave 2 rows of the breadboard free above the top of the FLiP and 3 rows at the bottom.

    Leave 5 columns free between the WDC65C02S and the FLiP, for wires that will go there and to leave space for your finger to push the Reset button on the edge of the FLiP. Leave 2 rows of breadboard free above the WDC65C02S and 3 rows at the bottom. Pin 1 of the WDC6502S should be at the bottom left, so the notch on the chip should be on the left.

    I cut up a large sticky note so it matched the size of the WDC65C02S, and I stuck it to the chip. Then I wrote the names of the pins on it with the help of the Data Sheet. This really helped me make sure that I didn't make mistakes so I highly recommend it.

    The pushbutton that will be used as reset button for the WDC65C02S is on the left of the chip with 2 unused columns in between.

    You can decide to make your own variations on the circuit of course, but I put the WDC65C02S and the FLiP and the reset button in these exact locations for a good reason: It left exactly enough space on the left to add some optional components that I'll get back to later.

  • 3
    GND and Power

    GND: FLiP pin 29 to 6502 pin 21

    To avoid any mishaps with static electricity, it's probably a good idea to start by connecting GND of the FLiP to VSS of the WDC65C02S (can I just call it "the 6502" from now on? Thanks!).

    3.3V: FLiP pin 32 to 6502 pin 8

    The original 6502 that came out in 1975 worked on 5V, but the Propeller uses 3.3V as power supply, and doesn't like it when its I/O pins get fed with 5V. So in the L-Star project, we feed the same 3.3V to the WDC65C02S which (unlike its MOS predecessor in the old days) is perfectly fine running at that voltage.

View all 11 instructions

Enjoy this project?



Gary Stoneburner wrote 01/14/2019 at 19:28 point

OSI emulation: in APR 2017 post indicated would be adding use of serial port to PC.  Still planning to do so? :-)

  Are you sure? yes | no

Jim wrote 04/28/2017 at 21:13 point

Is there any way to store programs in the C1P mode? The tinkering I've done before always had the serial port for a terminal and to allow save / load pretty much like the original. (I owned a C1P--good times... I traded it in for a C4P-MF which I still have but haven't powered on in about 30 years.)

  Are you sure? yes | no

Jac Goudsmit wrote 04/29/2017 at 01:15 point

Hi Jim! I've been on vacation so my memory is a little vague on the details about the C1P emulation. I think the current version of the firmware lets you use the serial port of the prop plug to enter keystrokes but I'm not sure. The ACIA (which would be used to store programs on cassette with the original hardware) is not emulated at this time, I'm still working on that.

  Are you sure? yes | no

Jim wrote 04/29/2017 at 18:27 point

I've looked through the Propeller code, but have to admit it is mostly greek to me. I honestly can't remember ever coming across anything that directly addressed the ACIA other than the I/O routines in the ROM. The one exception was when someone would try to change to baud rate, but that was usually from the command line and only if you had a serial printer. (Which not many of us did.)

On the C4P, I had a serial printer and also a KC audio take interface I could go back and forth between so I could salvage all my C1P cassettes.

I've been tinkering with OSI BASIC in 64tass and running in SYMON, but would like to move it to actual hardware. The thing I know I don't want to recreate is the member mapped video hardware which is one of the cool things about your project.

  Are you sure? yes | no

Jac Goudsmit wrote 04/29/2017 at 19:43 point

(I can't reply to your reply to my reply so I'm replying here)

There is no code in Github yet to emulate the ACIA, it's on my system at home and in a very early stage. Basically, it will be a new module similar to the A1PIA.spin module in the Apple 1 emulators. A Propeller cog will detect reads and writes to the ACIA addresses in 6502 space, and will communicate with another module that talks to the PC via the serial port.

I had a look at the current state of the OSI emulator and I see now that I remembered it wrong: at this time (April 2017) the OSI emulation doesn't use the serial port to the PC at all. I apologize if I got your hopes up, but it's purely a software issue: it can definitely be done, and it will be.

I'm sorry the SPIN code is difficult to read. Spin is an obscure language that's specific to the Propeller. I intend to use C and C++ for future projects but when I started on this, the GCC compiler for the Propeller wasn't stable enough to do that yet. There's no way to avoid Assembly because it's the only way to make some things cycle-accurate, but rewriting the SPIN parts in C should make things easier to understand for everyone.

If you're interested, you might learn something from the tutorials at The first 3 demos implement an Apple 1 emulator in C. Because there's no Assembly involved, it can't make the 65C02 run at 1MHz (the C compiler optimizer isn't smart enough to make it run fast enough), but in principle it works the same as the other Apple 1 projects.

I intend to add more demos and write web pages about them, but I've had very little time for the project lately because I've been busy at work and then went on vacation. I intend to write more tutorials e.g. about memory-mapped text video such as the OSI.

By the way, I intend to rewrite the OSI video driver because there were some misunderstandings on how the original OSI video hardware worked: in my emulated video driver (which I originally created for Vince Briel's Superboard III project), the characters outside the "used area" are invisible but I think on the original hardware there were 32 columns and 16 rows of text but the characters outside the "used area" were simply left blank. I also want to make it possible to emulate a later OSI video board that could be switched to 64 columns by poking a value at a certain place.

  Are you sure? yes | no

Jim wrote 04/29/2017 at 21:03 point

6502 assembler, I can do. C or C++, not so much. :-)

The original was 32 characters by 32 lines of "video RAM", but only 24x24 was actually displayed. In a lot of assembly code, it was easier to do things in batches of 32 anyway. Everything outside the 24x24 area was left blank by the ROM routines and BASIC.

I think the last design (when they went to the plastic case) allowed you to have 32x16 and there were different modifications available that supported 32x16 (and some other strange values).

The C4P video could support 64 characters per line (with 32 lines--although if I remember right no all lines showed on the screen) and you could "poke" that down to 32. (A lot of the 8x8 pixel characters in the character ROM look better when they are closer to being "chunky" like the 24x24 or the 32x32.

If you get to 64/32 characters by 32 lines AND 24 characters by 24 lines, you would be able to emulate either the C1P or C4P. (There was a separate memory map for color on the C4P. I guess actually it was the C2-4P that was just black and white video. I don't remember seeing much use the 32 character text mode on the C1P--by the time that came out the C1P wasn't as "bleeding edge" as it had been years earlier.)

I definitely understand about being busy and trying to fit things into non-existent "spare time". If I can help on the 6502 / C1P side of things let me know. (I'm happy to buy a kit--I just know that the Propeller side of things is not something I'm likely to unravel.) I haven't looked at the ROMs you're using, but there was also the garbage collection issue in the original 8k BASIC. (There are actually two different bugs--one that hangs the system and one that corrupts strings.) I spend some time running the "definitive" patches for that to ground if you are interested.

I worked for an OSI dealer through part of college and then struck out on my own in the blossoming field of "computer consulting" (which was largely writing software) for a few years until I graduated. Worked on a lot of the Challenger 3 series (which were serial based, included the 6502, 6800, and Z80 processors, could support hard drives, could "time-share" with multiple terminals, and even had some of the first "networking" capabilities in microprocessor based system to allow you to use the hard drive on one C3 system with other systems). For the most part, the C1Ps and C4Ps were reliable machines. Power supply capacitors would go now and then (more in the C4P). Sometimes you had to "reseat" the chips in their sockets.

The C4P (and I think the late model C1Ps) did have some provisions for sound. It was a D/A converter in the C4P. I believe the last builds of the C1P had some type of simple tone generator.

  Are you sure? yes | no

Jac Goudsmit wrote 04/29/2017 at 22:07 point

(Once again replying to a reply)

I expect that part of my audience isn't really interested in how the Propeller firmware works or how to create new software-defined computers, they just want to download one project into the Propeller EEPROM and play with the 6502 computer as if it's their old familiar computer. It looks like you are part of that group, and that's perfectly fine. Eventually I want to make it easy for people like you to download various computer emulations without the need to use the Propeller tool or SimpleIDE or anything else. I have some ideas on how to do that, but for now, documentation needs to have the highest priority.

Color video is not possible with L-Star unless you add extra hardware. The Propeller is capable of generating color video, but it would require more than one pin (I'm already using a "cheat" to use a single digital pin for composite monochrome video output). But 64 or 32 columns is easy to do, and will eventually be done. If I get a lot of feedback from people like you who would like to see it, it will move up on the priority list :-)

The bugs in Microsoft BASIC are widely known and have been fixed. I don't know if the ROM image in the L-Star repository on Github has the fixes, but if not, it's easy to build the project with a different ROM file (just change the file name in the OSI.spin module). Similarly, replacing the OSI monitor by SYMON is trivial too.

I've also done a project called #KimStar where I mapped the Apple 1 PIA chip emulator and the WOZ mon into the memory of a MicroKim computer to find out what was wrong with its hardware. I suppose it would be possible to do something similar with the OSI emulator so that you could call SYS <number> to start the WOZ mon and use the serial port of the Propeller to download programs to the OSI RAM memory. 

There are many possibilities of solving the problem of getting software and data into the memory of an emulated computer, but of course it will be necessary to understand the Propeller, the 6502 and the L-Star circuit to do that. I really want to make it possible for everyone to do that but it will take a lot of documentation and therefore a lot of time. Thanks for bearing with me!

  Are you sure? yes | no

Jim wrote 04/30/2017 at 18:39 point

I've been reading your various posts and a bit about the Propeller.

Actually, I like your idea of a "bus-based" solution although I may be viewing it differently than you describe.

It seems like you run out of I/O pins long before you run out of horsepower.

And if you look at a lot of what builders tend to find challenging it is around the glue logic and the video. Well, those and storage--but if we wanted easy storage we'd tinker with CP/M instead of the 6502... :-)

A "motherboard" similar to what you have with four to six "expansion slots" would let you take address, data, and clock to those slots. Then you could build a "standalone" daughter card for (using an example) video. Now you just have to 1) emulate video RAM and 2) handle the video output. You could have one Propeller dedicated to those tasks. (Which might mean being able to use VGA even if you emulate lower resolutions so everyone doesn't have to track down another monitor or implement color.)

Part of the config for the Propeller on that card could include things like the font, the memory address (so it could do it's own address decoding, removing the need for any glue logic), the output format, etc..

There could be other cards for the keyboard, ACIA/UART, maybe audio, and who knows what else.

With some I/O freed up for the Propeller on the "motherboard", you could do two chip enable lines--one for RAM and one for ROM. Then if you had 64 kbyte chips, you could map RAM and ROM however you wanted. (Or carve out chunks that would do nothing with the expectation that the Propeller on a daughter card would handle that address range.)

And I do like the concept of mapping part of the "ROM" into the Propeller so you can experiment with new code by loading it there instead of actually burning it into ROM. (Or maybe you just have 64K of ram, load some of it with ROM content, and let the propeller handle the R/W line so those portions are never written to by the 6502.)

One thing doing address decoding down to the byte would do is open up some space. Using the C1P as an example, the ACIA was only decoded down to A10 (I think) so it has 128 bytes tied up. But it really only uses two bytes. (You know address decoding but I'll throw it in for completeness--that means that to the CPU that look like those two bytes are repeated 64 times.)

With byte level address decoding I could now populate that area with (making up a somewhat sane number) two, three, or four "virtual" ACIAs. Or I could set aside 64 bytes as RAM for the monitor to use so I don't eat up so much Page Zero space. Bottom line is that I could remain fundamentally "compatible" while adding new features and functions "in the cracks" of the old memory map.

And, in theory, I could load the Propellers with different code and change from a C1P to a PET to an Apple ][. All with an architecture that makes "glue logic" obsolete--and that is the pain point for a lot of people looking at building their own computer from scratch even if it isn't rocket science.

  Are you sure? yes | no

Jac Goudsmit wrote 11/06/2016 at 18:11 point

I'm at the Hackaday Super Conference this weekend! If you want to see L-Star, ask me! I'm wearing a badge with "Jac" on it.

I would have given a presentation or a workshop but the project wasn't done yet (I'm expecting the first production PCB's tomorrow). Maybe next year!

  Are you sure? yes | no

Brett wrote 03/17/2016 at 17:41 point

Thanks. That's right. It was exciting to get a real 6502 chip to do something. Plus it's a pretty cost effective Apple 1. I will try out the resistor fix for the TV.

  Are you sure? yes | no

Brett wrote 03/17/2016 at 16:41 point

Great project. I got it working with just the terminal connection. My LCD television did not like the 1-pin tv signal too well.

The diagram in the github readme file is missing information on what to connect to the 6502's VDD and VSS pins. It's pretty obvious I suppose though.

I found that it helps to print out a diagram of the 6502 in the orientation that you will wire it, as well as marking down the orientation of the propeller pins on the propeller project board (in the orientation you'll look at them while wiring).

I used two 3300 ohm resistors. One of the resistors I used for 6502 pins 2,4,6,36, and 38. The other 3300ohm resistor, I used for the tact button on pin 40. I'm not sure if two separate ones were necessary, but it got it working.

Perhaps this pinout I used for my project will be helpful to a newbie trying this.

6502 Pin 1 (VPB) - No Connection
6502 Pin 2 (RDY) - +3300 ohm, resistor signal
6502 Pin 3 (PHI1O) - No Connection
6502 Pin 4 (IRQB) - +3300 ohm, resistor signal
6502 Pin 5 (MLB) - No Connection
6502 Pin 6 (NMIB) - +3300 ohm, resistor signal
6502 Pin 7 (SYNC) - No Connection
6502 Pin 8 (VDD) - +3.3 volts
6502 Pin 9 (A0) - Propeller Pin 8
6502 Pin 10 (A1) - Propeller Pin 9
6502 Pin 11 (A2) - Propeller Pin 10
6502 Pin 12 (A3) - Propeller Pin 11
6502 Pin 13 (A4) - Propeller Pin 12
6502 Pin 14 (A5) - Propeller Pin 13
6502 Pin 15 (A6) - Propeller Pin 14
6502 Pin 16 (A7) - Propeller Pin 15
6502 Pin 17 (A8) - Propeller Pin 16
6502 Pin 18 (A9) - Propeller Pin 17
6502 Pin 19 (A10) - Propeller Pin 18
6502 Pin 20 (A11) - Propeller Pin 19
6502 Pin 21 (VSS) - Ground
6502 Pin 22 (A12) - Propeller Pin 20
6502 Pin 23 (A13) - Propeller Pin 21
6502 Pin 24 (A14) - Propeller Pin 22
6502 Pin 25 (A15) - Propeller Pin 23
6502 Pin 26 (D7) - Propeller Pin 7
6502 Pin 27 (D6) - Propeller Pin 6
6502 Pin 28 (D5) - Propeller Pin 5
6502 Pin 29 (D4) - Propeller Pin 4
6502 Pin 30 (D3) - Propeller Pin 3
6502 Pin 31 (D2) - Propeller Pin 2
6502 Pin 32 (D1) - Propeller Pin 1
6502 Pin 33 (D0) - Propeller Pin 0
6502 Pin 34 (RWB) - Propeller Pin 24
6502 Pin 35 (NC) - No Connection
6502 Pin 36 (BE) - +3300 ohm, resistor signal
6502 Pin 37 (PHI2) - Propeller Pin 28
6502 Pin 38 (SOB) - +3300 ohm, resistor signal
6502 Pin 39 (PHI2) - No Connection
6502 Pin 40 (RESB) - +3300 ohm, resistor signal from tact button (add ground to the line if the button is pressed)

  Are you sure? yes | no

Jac Goudsmit wrote 03/17/2016 at 17:37 point

Hi Brett! Sorry, as of today (March 17, 2016), the instructions aren't complete yet, it's been a while since I had time for this. I'm happy to learn that it's not too hard to figure things out anyway.

I'm not surprised your LCD doesn't like the 1-pin video output. It might help to put a 470pF capacitor parallel with the video output, but it depends somewhat on how picky your TV is. An old CRT TV should work just fine.

The reason you need the separate 3300 Ohm resistor on the reset (RESB) line is that if you would tie the reset line together to all the other control inputs (RDY, IRQB, NMIB, BE, SOB), you would pull those lines to ground at the same time as the reset line when you push the reset button. If you would set up a system that requires one of the other lines to be pulled down, you'll have to separate that line onto its own 3300 Ohm resistor too.

The list of connections is correct, however you used physical pin numbers on the WDC 65C02 and logical pin numbers on the Propeller. For those reading along: On a DIP Propeller, logical pins 0..7 are on physical pins 1..8; logical pins 8..15 are on physical pins 13..20; logical pins 16..23 are on physical pins 21..28 and logical pins 24..31 are on physical pins 33..40. SMT packages for the Propeller use different pinouts.

Let me know if you have further questions!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates