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!
01/19/2015 at 06:02 •
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.
As I may have mentioned before, I worked with Vince Briel at Brielcomputers.com on a replica of the Superboard II last year, so I had some code laying around from that project: a modified 1-pin TV driver that can handle the 256-character OSI font, and an OSI keyboard emulator.
The Propeller has 32 digital I/O pins, of which 25 are used by the address bus, data bus and R/~W line. Two pins are more or less reserved by the serial connection to the PC and two are used by the I2C EEPROM that stores the Propeller program (the 6502 clock is generated on the I2C clock line). That leaves only 3 pins for other I/O. Two are used for the PS/2 keyboard, and one is used for video.
One Pin TV Driver
You may wonder how the Propeller can generate an analog video signal on a single digital pin. The secret is that it uses one of the built-in timers to generate a high-frequency block wave. The impedance and capacitance of the connected monitor reduces the high-frequency signal into a DC-level, which is interpreted as black. The Propeller sets the pin LOW for blanking and synchronization, and it sets it HIGH for white.
The 1-pin TV driver was written by a few members of the Propeller forums as a means for debugging programs, but originally, it was written in such a way that it wouldn't have worked for the Superboard II emulator. For one thing: it stored the font in the cog, which made it incapable of displaying the 256-character OSI font: the font data would have taken up the entire cog, not leaving any memory space for the code. So I modified the code to read the font from the hub. This reduces the maximum resolution a bit (hub access is much slower than cog access), but we should never need more than 64 characters per line, which is well within the limits of the modified driver.
The original Superboard II video hardware was a very simple circuit. It generated 32x32 characters (totaling 1KB of video memory) of monochrome video at 60Hz (50Hz in Europe). But the characters around the edge would be in the non-visible areas of most screens, so the software only used 25 lines of 25 characters in the middle of the screen. I modified the 1-pin TV driver so that the first character that's displayed doesn't necessarily have to be the first character in the video buffer. And at the end of each row of characters, the driver adds a number to an address, to make a few characters invisible. That way, the line addresses are still (say) 32 addresses apart, but only (say) 25 characters per line are visible.
For now, the 1-pin TV driver is hardcoded to emulate the Superboard II display with the 1KB memory (32x32 characters). The parameters can easily be changed to change the video to 48x32 or even 64x32. Some of the original video adapters for other OSI computers were capable of switching between two modes (e.g. 32x32 and 64x32) by writing to a specific address in memory; this is currently not possible because the video parameters are calculated at compile time; however I'm planning on changing this in the future.
OSI Keyboard Driver
All computer keyboards are implemented as a matrix of switches: Each key is connected to one row and one column of electric lines. The computer activates a row, and then checks which column(s) is/are active to see which key switch connects that row to a column. In modern computers and in your PS/2 keyboard, the computer that takes care of scanning the keys has been replaced by a microcontroller. Simply said, the microcontroller in a PS/2 keyboard translates the scanned keys to a serial signal, which is sent to the host computer (the host computer can also send signals to the keyboard to turn the LEDs on or off).
But in old computers such as the OSI Superboard II, the computer was directly connected to the keyboard matrix, Obviously this has disadvantages: the computer won't see a key press if it doesn't scan the matrix every once in a while. We may not be able to change that, but we do have to translate the data from the PS/2 keyboard into scan data.
On the Superboard II, the 6502 stores a value to location $DF00 to activate the rows of the keyboard matrix, then it reads back from the same location to find out which column(s) on that row have their switches pushed down. It's possible (to an extent) to detect multiple simultaneous key presses, and the keyboard matrix on the Superboard II was especially designed to make sure that simultaneous pressing of the shift, shift-lock and repeat keys together with other keys would never be a problem.
The OSI keyboard driver has to do the reverse of what the controller in the PS/2 keyboard already does: it has to convert the incoming serial data from the keyboard back to a keyboard matrix that the software will understand. The work to do that is divided between two cogs: the first cog executes pretty much the same code as the original PS/2 driver included with the Propeller software, the second cog monitors the 6502 address bus and data bus to check if any keyboard scanning is going on.
Instead of generating an ASCII code or a scan code, the first keyboard cog keeps track of a table of which keys are currently pressed. The PS/2 protocol allows multiple keys to be pressed at the same time (not all keyboards support this equally well but that's a different problem) so the cog can simulate simultaneous pressing of keys. The table matches the keyboard matrix of the original OSI, and stores a bit value of 1 for each key that's currently pressed. When the second cog detects that the 6502 is scanning the keyboard by writing a value to $DF00, it basically changes the index of the byte in the table that Propeller will present to the 6502 when it does a read from $DF00.
The value that the 65C02 stores at address $DF00 can't be used directly. There are 256 possible values of the byte that the 65C02 may store at the location, but there are only 8 rows. On the real hardware, it would be possible in theory to activate multiple columns at once, but if we would emulate this, it would take a lot of extra code, and/or a lot of extra memory. Instead, the driver implements a compromise: as long as the 65C02 only scans one row at a time, it will get accurate results, but if it tries to scan multiple rows at the same time, it gets the columns for the row with the highest number. To accomplish this, the Propeller code uses a table that it generates at runtime, containing the base-2 log values for values 1 to 255.ACIA
The cassette port of the Superboard II was connected via a Motorola 6850 ACIA (serial port controller). At this time, that chip isn't emulated yet. I will fix that soon: the serial port to the PC can then be used with a terminal program to save or load programs.