• The First Single-PCB Prototype, and Trace Cog Fix

    I’ve built probably about a dozen prototypes of the various versions of Propeddle over the last three years, but this is the first time that Propeddle has come alive by itself, on its own circuit board, without any assisting hardware (other than the power supply and the Propeller Plug). And I found and fixed the bug that I was talking about in the previous post, in the trace cog.

    It's a little bit of a botch with the added LEDs, rewired LDO's and other changes, but this is a Rev.11 Propeddle on a Rev.10 board.
    It’s a little bit of a botch with the added LEDs, rewired LDO’s and other changes, but this is a Rev.11 Propeddle on a Rev.10 board.

    Continue reading  Post ID 286

  • Wire Wrap Update

    A while ago, I announced here that I was considering making a wire-wrap version of Propeddle. The article is gone now: I kinda gave up on it because I was busy with lots of other things. But in the last few weeks, I started thinking about the idea again while I was working on the Kicad schematics, and decided to go ahead and make a wire-wrap version of Propeddle, based on the Parallax Propeller USB Proto Board, and the Human Interface Board.

    Don't you just love the wire pr0n? :-)
    Don’t you just love the wire pr0n? 🙂

    Continue reading  Post ID 286

  • The New Propeddle Kit Almost Ready!

    This is OSHPark's rendition of the Propeddle Rev. 10 PCB.
    This is OSHPark’s rendition of the Propeddle Rev. 10 PCB.

    As I mentioned before, I’ve been working on a version of the Propeddle kit that has everything included: Not just the 65*02, memory and glue logic, but also the Propeller (and it surrounding hardware), and the connectors. Once I learned how KiCad works, this wasn’t very difficult, though I think KiCad could use some improvements when it comes to moving parts and traces at the same time. The result is a PCB that’s slightly smaller than a 160x100mm EuroCard, so it should fit in many standard enclosures. Continue reading  Post ID 286

  • Find the Differences ;-)

    Propeddle PCB design in Eagle vs. KicadWhen I started working on Propeddle, I hadn’t worked with any electronic/PCB design software for a long time. To be precise, I think the last time I used Orcad was probably during my failed attempt to get an EE degree in 1986/1987. I learned how to use Eagle because it was used by many engineers, had a decent library and there were plenty of good tutorials around. Meanwhile, I’ve also learned Designspark PCB, and Kicad, and as I mentioned before, I decided that Kicad would be the program that I would use for Propeddle, now that I can no longer use Eagle.

    Continue reading  Post ID 286

  • Kicad Pro Tip for Importing Designs from Eagle

    After you use a script like Eagle2Kicad.ulp to export an Eagle design to Kicad, use the Kicad Library Editor to remove any symbols from the library that you created as power supply symbols. If you don’t, Kicad will be seriously confused.

    I had a few symbols for VCC and GND in my Eagle design for Propeddle because I didn’t like the symbols that Eagle uses. This got me in trouble with Kicad, without it letting me know about it.

    Continue reading  Post ID 286

  • Achievement Unlocked: Schematics Converted to Kicad and Posted on Github

    Propeddle kicad schematic
    Propeddle schematic, just after converting it to Kicad.

    I’ve been working on my Propeddle project for about three years now (on and off — mostly off), and one of the things that’s been on the to-do list for a while is to move the schematic from the free “Light” hobby version of Eagle to Kicad or some other electronic design program that will let me make the PCB bigger, and won’t take me to court for selling my design as a kit, and won’t cost me so much that I have to double the price for the kit to make up for the expense.

    I’ve tried the conversion before and it failed every time, and I couldn’t figure out why. I even tried other software besides Kicad (such as DesignSpark, which I really liked by the way) to see how much trouble it would be to just start over.
    Continue reading  Post ID 286

  • It works!*

    So the question “Is it possible to bit-bang a 6502 processor with a Propeller to make it work at 1MHz?” has been answered, and – as expected – the answer is YES!

    Propeddle running its first program using the PASM code
    A screenshot of the Parallax terminal program showing the Propeddle running a simple test program that increments a byte in SRAM in an infinite loop

    Continue reading  Post ID 286

  • The Brielcomputers.com OSI Replica Project

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

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

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

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

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

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

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

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

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

  • Of Baby Steps and Binutils

    Hello everyone!

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

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

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

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

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

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

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

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

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


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