This project is submitted for

Description

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 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 or on a Propeller USB Proto-board.

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. All the parts are through-hole, so the kit is easy to put together. The kit is for sale on Tindie.

I'm using these pages as a "glance into the kitchen". Some information may get outdated because of this. I'm setting up a new website at l-star.org to provide information to kit buyers.

Details

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.

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 l-star.org 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!

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 l-star.org 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!

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?

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...

The Apple-1 and OSI Superboard / Challenger emulators don't need a lot of RAM and ROM memory. For those projects, the Memory cog module (see the project details) does its task just fine to map a ROM image into the 6502's address space, and let the 6502 (effectively) read and write the Propeller hub memory as if it's real RAM.

But the Propeller only has 32KB of hub memory, and for some (future) projects, that simply might not be enough, and it will be necessary to put some real memory in the system.

I designed the L-Star Plus as a kit that includes an SRAM chip to take care of this problem. The chip is a 128KB Alliance Memory AS6C1008-55PCN. Why 128KB you might ask, if the 6502 only has 64KB of address space? Well, as it turns out, there is no 64KB SRAM chip, at least not one in a DIP package, with 16 address lines and 8 data lines, and 3.3V compatibility. So I had to use a 128KB chip instead. First world problems!

The lowest 16 address lines of the SRAM are connected to the 6502 address bus, and the data lines are connected to the data bus. The highest address bus pin (A16) was grounded in the Rev.1 PCB design, but is available on the jumper block on the L-Star Plus in the Rev.2 design.

That means that the Propeller can be connected to the SRAM chip's Chip-Enable-Not pin (~CE) to put the chip on the data bus when needed. All that's needed is a new software module that I wrote last week, called SRAMctrl. This module builds a literal bitmap of which addresses in the 6502 address bus should be mapped into the SRAM chip. Then, on each 6502 clock cycle, it checks the bit in cog memory that represents the address that the 6502 requests, and, if necessary, activates the SRAM chip's Chip Enable line.

The bitmap actually consists of two tables that seamlessly work together. The R/~W line of the 6502 address bus is used as an extra address line when an index into the table is calculated (it's not a coincidence that the R/~W line is connected to the P24 pin of the Propeller, adjacent to P23 where address bus line A15 is connected). That way, reads and writes can be controlled separately and it's possible to create read-only memory areas in the SRAM chip. For some future large projects, this may make it possible to let the Propeller initialize the RAM with a ROM image file, and then let the 6502 boot from the SRAM. See if you can do that in an ordinary 6502 system (tip: you can't).

It would be nice if each address on the 6502 address bus were represented by one bit in the table, but this would be difficult. The table wouldn't fit in a cog, so I would have to e.g. let two or more cogs work together or retrieve data from the hub. Using two or more cogs just to turn an SRAM chip on or off is not very efficient, and putting the data in the hub is a non-starter because it takes quite a few Assembly instructions to generate the index into the table, shift the bit out from the long-word entry. If I would have to add a hub access instruction to that, there just wouldn't be enough time in a 6502 clock cycle to get everything done.

So the compromise is that (for now), each bit in the table represents 16 bytes in 6502 address space: the first bit represents addresses $0000 to $000F, the second bit represents $0010 to $001F etc. For most uses, this should be more than adequate. A future version of the SRAM control cog could be made to support a one-in-8 resolution instead of the current one-in-16 resolution, by eliminating the separate handling of reads and writes.

Another compromise is that if you want to use the SRAM chip in your Software Defined Computer, you'll have to either give up the monochrome 1-pin video output, or you'll have to switch from the full PS/2 keyboard driver to the 1-pin keyboard driver (by Ray Rodrick a.k.a. Cluso99 on the Parallax forums) which doesn't need the keyboard clock input. For now, that also means that you'll have to ask the user to push the space bar on the PS/2 keyboard to measure the keyboard-specific clock speed. But I'm...

The L-Star project has been getting some attention recently, so I decided to do some work on the hardware.

I added a couple of missing pull-up resistors, so that the circuit keeps working correctly, even if you remove the Prop Plug from it. I also made the footprint for resistors a little bigger so that common carbon film resistors fit nicely. And I added an On/Off switch so you can turn the system off and don't have to go searching for the power cable that fell down behind your desk when you want to power it up again.

Even though there are more components and all the resistors take up more space, it was still possible to reduce the board size significantly. I didn't quite get it down to the "magic" 80x100mm Half Euro-card size, but I got pretty close: the Rev. 2 board is 12% smaller (in surface area) than the Rev. 1 board.

I ordered a set of boards from OSHPark, and created a shared project on the OSHPark website too. I also created a project at Mouser. The result looked somewhat like this.

Update: Hold the Phone!

Unfortunately once I got the PCB's back from OSHpark and put it together, I noticed that I had made a few small but annoying mistakes.

For one thing, I added the A16 address line for the 128KB SRAM chip to the jumper block, but I added it to the wrong jumper. That means with the Rev.2 PCB, it's not possible to connect the ~RAMEN line to P27 with a jumper, and that really really REALLY is the pin I would like to connect it to.

Another problem: The smaller board size made it cheaper to produce, but with the added on-off switch, the components are so close together that I have trouble pushing the reset button for the 65C02. My finger just doesn't fit between the LED, the chip and the 2-pin header to reach the button.

So the bad news is that I'm going to have to design a third version of the PCB, even though the first two versions technically work just fine. I guess the good news is that I didn't make a production run of the Rev.2 board. And I have a chance to fix another thing that's been nagging me for a while: the solder islands were too small. More news soon!

Ohio Scientific (OSI) was a company that produced many 6502-based computers in the late 1970s and early 1980s. One of those computers was the Superboard II, also available in a case as the Challenger C1P. In the UK, many people may remember the CompuKit UK101 which was a clone of the Superboard II, available as a kit from a magazine. The Superboard II doesn't use IRQ or NMI interrupts, generates character-based monochrome video, and the original machine only had 4KB of memory. This makes it a great candidate to be replicated on the L-Star hardware.

All integrated circuits are CMOS based, so you should take the usual precautions about static discharge.

3

Step 3

The first thing you solder onto the board should be the socket for the power. The reason to solder this first is that the solder islands partially overlap with the footprints of other components. If you would put the other components in first and then solder the power socket, you might overheat the other components, or they might get in the way.

Discussions

Become a member

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.)

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.

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.

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 https://github.com/jacgoudsmit/L-Star/tree/master/Software/SimpleIDE. 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.

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.

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!

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.

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.

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.