06/11/2018 at 20:02 •
---------- more ----------
The early PET/CBM machines had up to 32KB RAM on board, a character-based memory-mapped video display, 8KB ROM for Microsoft BASIC, 2K ROM for the screen-based editor, and 4KB for the operating system which Commodore called the "Kernal". There were 3 simple I/O chips in the early models: one for the keyboard and the cassette interface, one for the IEEE-488 (GPIB) interface, and one for the second cassette port and the user port. Later models added a CRT controller chip to simplify the video hardware.
RAM and ROM
In the projects that I've already written for L-Star, I've extensively used the Memory module which give the 6502 access to a memory area in the hub of the Propeller. To emulate a ROM, all I need to do in Spin is to put a "file" command in the source code to load a ROM image file and then run a Memory module to map it into 6502 address space. I can do this with RAM too, but the Propeller only has 32KB of hub memory available, part of which is used up by the program. Though it would be possible, in theory, to use hub RAM as 6502 RAM for the PET/CBM project, it's much easier to just use an external SRAM chip such as the one that's on the L-Star Plus board. One cog is in control of enabling the SRAM based on the address bus of the 6502, and because I already had that module, it was a matter of copying it and adding lines to initialize the module and start it up.
In the original machines, video was the most complicated part of the hardware, because the RAM needs to be accessible by the 6502 while it's generating a constant signal. Just like in many other early 6502 computers, the entire system was built around the video hardware. Commodore figured out that with 40 characters per row, and a video line time of about 64 microseconds, it would be possible to run the CPU at about 1MHz and design some circuitry that alternates the access to the video hardware between the CPU and the video generator hardware twice per clock cycle. On the later 80-column motherboards, they used an even smarter approach where the video hardware sees the memory as 2048 words of 16 bits and decodes the characters at twice the speed.
With L-Star, the video part is easy because it basically has already been done. The Propeller is really good at generating video; it has I/O registers and assembly instructions to help with this. It can do 6-bit VGA or PAL or NTSC composite video, but all those modes need 3 or 4 or 8 pins. L-Star doesn't have that many pins available (most pins are connected to the 65C02) so I use the 1-pin TV driver which is fine for a monochrome text video output similar the PET/CBM. That software module wasn't written by me but by a couple of smart guys in the Parallax forums. I only had to convert the PETSCII font from a ROM dump at ftp.zimmers.net to the correct format for the 1-pin TV driver.
There are actually two fonts in a PET/CBM: one that has upper and lower case characters, and one that has upper case and graphics. And there are actually differences between the fonts in the PET and the fonts in the later CBM machines. But my short term goal was to get text on the screen, and fortunately that's just a few lines of code to start the video cog. And then another line of code to start another Memory module to give the 6502 access to the hub memory that represents the characters on the screen.
The PET/CBM talked to peripherals via a parallel interface using a standard called IEEE-488. That standard is more generally known as the Hewlett-Packard General Purpose Interface Bus (HP-GPIB or simply GPIB) and is still in use in instrumentation devices today. It made it possible for the Commodore engineers to design a computer and not worry about what kind of peripherals might one day be available for it. Commodore floppy drives (and printers and hard disks) are computers too (some floppy drives even have two CPU's), and they talk to the IEEE-488 bus via a standard protocol.
I probably won't implement emulation for the IEEE-488 bus. As far as I understand, real PET/CBMs work fine without the PIA chip that is used for the IEEE-488 interface, and there are probably better ways to load and save software and data into and out of memory. And if you want to connect L-Star to a real floppy drive, you'll have to build hardware anyway, so the need to add a PIA (and an address decoder) is probably not a big deal.
Keyboard and Cassette
PET/CBM's have two cassette interfaces, but most people only used one of them (professional users probably used a floppy drive and no tape at all). As mentioned before, there are probably better ways to get software and data in and out, so I don't think I'll write code to emulate the cassette, at least not for now. It would be nice to use the serial port (P30 and P31) on the Propeller, but I may run into trouble with that; I'll get back to this in a few minutes.
The keyboard that was used on the PET/CBM was a matrix keyboard on two ports of a PIA chip (a different one from the IEEE-488 interface). I wrote a driver for a matrix keyboard in the OSI Superboard emulator, and I'll probably modify that for the PET project. I may have to do a bit of a start-over because I'll have to use the 1-pin keyboard driver and the OSI keyboard uses 2 pins.
If you're somewhat familiar with other L-Star projects, you'll know that it has 3 uncommitted pins on the Propeller, which aren't connected to anything except the expansion header and the jumper bed. And if you counted along with the story above, you will have concluded that one pin is needed for video, one to control the SRAM chip and one to get input from a PS/2 keyboard. That means all pins are in use.
This is a problem, because there is one feature that I haven't mentioned yet: in the PET/CBM, the IRQ line is activated sixty or fifty times per second, depending on the mains frequency (I think the signal actually comes from the video circuitry but that doesn't matter). This is used to time operations in programs, let the cursor blink, etc. And there's no pin free on the Propeller to generate the signal that's supposed to go to the IRQ line of the 6502.
I'm not sure yet how to solve this. I could use P30 (which is normally used for serial transmit) to connect to !IRQ. That makes it difficult or impossible to use the serial port while the emulation is running, unless I write some software to implement a 1-pin serial port.
Another possibility is to not implement a keyboard emulator for the PS/2 keyboard, so it frees up a pin that can be used for !IRQ. But that makes it necessary to connect a computer to the serial port to generate keyboard input. Also not a very good solution; I'd like to the design to be stand-alone.
I could also try to do something in software: fifty or sixty times per second, I could let the Propeller feed a BRK instruction to the 6502 which is executed pretty much the same as an IRQ interrupt. But a normal IRQ doesn't set the B flag in the flags register whereas the BRK instruction does. So the Propeller will also have to interfere when the 6502 pushes the flags onto the stack, or when it accesses the location on the stack where they are stored. That could become very complicated. Which is somewhat ironic because in the real computer, the circuit that generates the interrupt is so very simple.
So About These First Life-Signs?
In the picture above, you see what appeared on the screen when I emulated just the RAM (with the SRAM module), the video, and the ROM. No peripheral chips are emulated yet. What I would expect on the screen is a message "COMMODORE BASIC" and "31743 BYTES FREE". But it looks like the execution drops into the machine language monitor as if it executed a BRK instruction. I suspect that the behavior is caused by a wrong combination of ROM image files. I started on the PET project about 2 years ago and hit a snag; I don't remember what it was but it wouldn't put anything on the screen at all. The project got shelved but now I picked it up and made some tweaks and write a module to trace the 6502 to follow what it's doing. I know I experimented with various combinations of ROMs when I worked on it before, so maybe what's in there is not correct, and somewhere somehow the code in one ROM jumps or calls code in another ROM that's not in the location where it's supposed to be.
What worries me more is that the display is garbled: That means that the 6502 is writing data to emulated screen memory but there are some bits that are mangled. I have a feeling the RAM chip is holding the databus a little bit too long at the end of a clock cycle, so I may have to tweak the Propeller code a little. The 6502 has to execute a lot of code and read and write a lot of locations in ROM and RAM to get to the point where it displays the Machine Language Monitor prompt, so I'm optimistic that it's fixable.
05/26/2017 at 06:38 •
Got parts, got PCB's, getting Prop Plugs in a day or two.
That means L-Star is back in stock!
Order here: https://www.tindie.com/products/jac_goudsmit/l-star-plus-software-defined-6502-computer/ (or click on the Tindie link on the project page).
01/12/2017 at 23:05 •
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.
- 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.
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.
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!
11/08/2016 at 05:34 •
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 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!===Jac
10/11/2016 at 04:15 •
After the disaster with Rev. 4 (see the last log), I learned a couple of things and made some changes resulting in Rev. 5:
The mounting hole in the lower left corner of the PCB has been a pain since the start of the project, and if you look at the project logs, you can see it has moved around a lot. For Rev. 5 it's finally where it belongs: in the corner. I swapped the locations of the on/off switch and the power socket, so I could move the SRAM chip up a little, to make space for the hole. I can't believe I didn't think about it earlier and I don't think I'll have to move it again. That means it will be the location of the mounting hole on future expansion boards too.
That sounds pretty final, and it is. I think Rev. 5 is the design that will go into production. I adjusted some parameters (such as the pad-to-soldermask clearance, the flood plane clearance and minimum width, and the via drill and pad size), to prevent problems from Rev. 4 from reoccurring. I also nudged the keyboard connector over a little bit, to make it easier to prevent short circuits with the resistors when soldering.
Nevertheless, after the problems of Rev 4, I didn't feel confident enough to order a full production run of Rev. 5 at OSHPark. I placed a regular 3-board order and if they turn out okay, I'll order more.
I also ordered enough parts to have a small number of kits available on Tindie as soon as possible. But it looks like I may have to order a bigger batch of parts soon: There are already enough people on the waiting list to sell most kits of the first batch...
I updated the links to the OSHPark and Mouser order pages in case you want to order your own, but of course that will be more expensive than ordering from my Tindie page once it's ready. Thanks for your patience!
UPDATE: I got the Rev. 5 boards back from OSHPark and built one; see the updated picture at the top of the article. As you can see, the green headers are back!
09/13/2016 at 07:09 •
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?
The first thing I did was to sort through the big box of parts that I had gotten from Mouser earlier in the week, with enough passive parts for 10 kits and then some. I decided not to get all the chips because I still have most of the chips from the first production run of #Propeddle: Software-Defined 6502 Computer and I could easily reuse those chips even though they're a few years old. They've been on conductive foam all that time so they should be fine. I figured it might be a better idea to invest a little bit into some extra passive parts so that I could get them at a lower price. For example, resistors get a lot cheaper per part, if you buy 200 of them instead of, say, 10 or 60.
I've soldered so many different versions of my own project that I can almost do it in my sleep now. Well... That's an exaggeration of course, but the actual assembly of the first board which I will call Board 400, went pretty fast. I found a couple of minor problems that I'll fix for the production version (for example, now that the board is so much smaller as when I started, some parts are really too close together so I'm going to have to move some things around to make it easy to solder for beginners). But nothing was obviously wrong. I went through the entire assembly in one go and took pictures along the way that I might use for the building instructions, but I didn't really test anything along the way. You can probably guess where this story is going, right?
The board looks beautiful, and though things get crowded in a few places (which I will fix for the production version, as I said), it was easy to solder. But when I plugged it in... nothing happened.
As it turned out, there was a short between 3.3V and GND (the flood planes on the top and bottom side). This was the first time that that ever happened with any board from @oshpark. I've always gotten excellent quality PCB's from them and this was no exception. There was no short on the unpopulated boards. So what went wrong?
I started desoldering some of the parts from the first board (particularly, the ones that I noticed were close to other parts) to see if I had been too sloppy with my soldering. But the short didn't go away. Bummer! I went to bed and figured I'd look at it again on Saturday morning.
I had a closer look on Saturday but I didn't get any wiser from it. My 20 year old solder tin that I brought with me from Europe when I emigrated, sprayed rosin core everywhere of course, so I cleaned it up a bit to see if I could see any tin where there shouldn't be any. I didn't.
So I sort of gave up on "board 400" and decided to solder together "board 401". I started with the resistors, and the MLCC capacitors. Then just for giggles I put my multimeter on the board. This one was shorted out too! What the actual beep?
I desoldered the capacitors from board 401 because it was easy to do, and measured again. Still shorted. I used solder wick and a solder sucker to clean the pads. Still shorted.
I gave up on board 401 and started putting together board 402. I didn't really want to put all those boards together; as much fun as it is to solder them together, I really don't need that many L-Stars laying around my house! And if I was going to put all my own kits together for myself, I wasn't going to get paid for the parts. The passive components alone are probably close to $25 per board, and that's after I switched to the cheap header-by-the-mile parts instead of the cool green headers that I had before (which I will probably switch back to).
I started board 402 with the LED and the power supply, so I could quickly plug it in after soldering each part. But I didn't run into any problems at all, this one was just perfect and super easy.
Back to Board 401
Meanwhile, I had posted my non-progress on Google+ and got an email from Laen at OSHPark. He said he noticed the clearance around the solder mask was a little on the high side.
A close-up photo of board 401 reveals what the problem really was. When you look at the board with normal, say 49 year old eyes, you might think those shiny things at the edges of the solder islands are just like the the light reflecting off the edge of the solder resist near the edge of the board, but they are exposed copper from the GND flood plane. I must have played with the settings at one point and set the pad-to-solder-resist to 0.2mm (almost 0.008 inches) instead of 2 mils (0.002 inches). I bet I shorted out almost all those resistors I soldered in. To paraphrase captain Kirk: Face, the palmed front here.
I decided maybe board 401 would be salvageable, now I knew what the problem was. I cleaned up all the islands (which took hours!) and finally cleared the short circuit. Then I did the same as with board 402: I mounted the LED and power supply first, and then added each component with a quick light-up test in between. I caused (and fixed) a few more shorts but when I was done, I decided this would do as a demo model or something. I would have to put a sticker on the back side to remind me never to do any soldering on it, lest it would short out again. And that's when Murphy struck again.
Murphy's last laugh
I soon found out that, though I had avoided shorting out the flood planes (or anything else), there were a few points on the board that weren't connected even though they should be. For example, I could communicate with the Propeller but I couldn't store the program into the EEPROM. Strange. I tried another EEPROM that worked fine on board 402... Bupkis.
So I pulled out the beeping multimeter again and found out one of the I2C wires wasn't connected. I put on a botch wire to fix it, thinking nothing of it. No big deal, "Chips happen" as they say. But then I needed another one, and another, and another. The entire data bus except for one bit was disconnected between the Propeller and the 65C02. Can you see why, in the next picture?
No, it's not because of my (I admit, utterly shoddy) soldering; it's because most of those vias don't have a hole in them, so they're not vias at all, they're just islands. The tiny drill that the board house used to drill vias, must have broken in the middle of my board, and nobody noticed it.
So yeah. About $60 in parts lost, as well as two OSHPark PCB's and pretty much a whole weekend. Lessons learned:
- Figure out exactly what the best settings are for clearance (pad-to-pad and pad-to-solder-resist)
- Don't use the most extreme settings that your PCB provider offers, unless you have to (I bet 0.015 inch drills break a lot).
- Solder accurately even if you've done the same thing 20 times already
And uh... suggestions on better solder tin are welcome, solder tin donations even more :-)
08/28/2016 at 22:08 •
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.
One change that I made since Rev. 3 (which I never built) is that the PCB is now even smaller. It's now within a hair of fitting within the "magical" 80x100mm "Half Eurocard" size. The short side is 0.01mm too wide to fit into the crazy limit imposed by the free and cheap versions of Eagle. I don't think I'll fix that unless someone asks; I think this design is going to be the production version.
The most important improvement compared to revision 3 is that the expansion port is now a 50-pin header instead of a 40-pin header. As I mentioned in the previous project log, the location of the expansion port was always designed with the possibility that there could be a 50 pin header some day, and that day is now. For most projects, the original 40 pins may be enough, but the extra pins should remove any fears of future regrets: Simply every single important control signal is on the connector. The added pins are:
- RDY: The RDY pin can be used to hold execution (insert wait states) on the 6502: when it is pulled LOW, the 6502 stops executing, but the address bus and data bus are still going through their usual motions. In the original 6502 it only stopped read cycles and not write cycles, and it was intended to deal with slow hardware, usually ROMs. On the WDC 65C02 in this project, the RDY pin also stops when the processor is doing a write cycle. So on old hardware, the pin was rarely used and because of the change in the WDC processor, any use that can't be emulated by letting the Propeller stop the clock is probably not worth fixing, so I left it off the expansion port until now. In the unlikely case that it might be useful for a project where an expansion board controls the pin, it's available now.
- BE: The Bus Enable pin is a unique feature of the WDC 65C02. It puts the address bus, data bus and R/~W pin in a disconnected state to make it possible for other devices to use the bus. I admit, it was tempting to use it to let the Propeller access the SRAM chip directly, but because I was out of pins on the Propeller, and because it's easy to work around that problem with software (i.e. simply let the Propeller feed dummy instructions to the 6502 that take care of filling the RAM) I decided not to use it. I still expect that it will be difficult to use, because the Propeller has to know when to stop paying attention to the bus, too. But anyway, it's on the expansion port now.
- A16 and ~RAMEN: In most cases, it would be enough to let the Propeller have control over the SRAM chip (if it's even necessary to have an SRAM chip in the first place). But now the expansion port has the RAM control signals, it's possible to put some sort of hardware address decoding on there and keep Propeller pins free for other purposes
- KBCLK, KBDATA and TVOUT: It makes sense to have these on an expansion board: for one thing, it will make it possible to do things like generate color video from the expansion board. And by putting all signals in the jumper block on the expansion port, it's possible to replicate the jumper block on the expansion board, or even to remove the right side of the board (Prop plug, jumper block PS/2 and video connectors) completely, and/or put them on a separate board that's connected to L-Star via a ribbon cable.
- ~RES: This is the reset input for the Propeller, and though there already is a header to connect this signal to a switch in an enclosure, it's also a good idea to have it on the expansion port. For example: if you would want to separate the "right side" of the board from the rest of the board, the reset line is needed because it's also on the Prop Plug.
- Two GND pins: When there are so many pins connected to a second board in the system, it's always a good idea to have a good ground reference.
There are actual people owning actual hardware that uses the 40 pin connector, so the 50-pin connector is backwards compatible with the 40-pin connector. The two GND pins were added on one side and the 8 other pins were added on the other side. I don't expect to make any further changes to the pinout, because all the signals that I think could possibly interesting to any expansion devices, are on the connector. The only ones that are not on there are the Propeller clock and the brown-out protection. But I already decided that it's not worth making any changes to those: the project is intended for those who want to learn about the 6502, and while those two would useful, they would also be a distraction from the intentions of the project and add expense.
I ordered a batch of PCB's from OSHPark, and I plan to build it to make sure it works, I'm thinking of leaving the chips off the Mouser order, and stocking up on the passive components so I can do a production run soon, and finally put the project up on Tindie.
06/15/2016 at 03:27 •
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 Propeller on the L-Star board can do, such as controlling the SRAM chip. Furthermore, it lets me add some more pins to supply power to the expansion board, which is also a little bit of a concern.
05/29/2016 at 06:36 •
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 thinking it should be possible to do away with that, with some smart programming.
The SRAM control cog is in a module called SRAMctrl.spin in the new Apple1SRAM project. The code in that project activates the SRAM for the entire low 32K memory area which is also present in Vince Briel's Replica 1. It doesn't use the memory cog to emulate any RAM, only ROM. The 32K of available RAM is nice, because now there's no need to patch the Krusader program in the emulated ROM (it's kinda hard coded to expect that the system has 32K). It's trivial to make the amount of SRAM even larger, but instead of mapping more SRAM into memory, I wonder if maybe I could emulate the CFFA1, or the Apple 1 cassette interface using the Propeller. That would make L-Star into a Replica 1 Replica! :-)
05/16/2016 at 23:39 •
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!