• Apple II BMP Display Success!‚Äč

    sup4rl33thax0r09/10/2018 at 06:40 1 comment

    So, an admission.  It’s been a bit since my last update.  Turns out that I don't work on this project full-time :)

    Anyone that works on hobby projects knows that time is usually the constraining factor when it comes to getting stuff done.  Work, fixing things, cleaning the shop, and so on generally gets in the way of meaningful progress on SUPAR AWESOME PROJECTS.  That's a big part of why I gave myself a decade to get this project done.  Oh, I didn't mention that?  Yeah, this is a decade-long project.  I think I'm on track.

    Believe it or not though, I have made some great progress since the previous update.  Among other things, I have the full Simplified Perturbations Models running on the INMOS transputer hardware.  Last we checked in, I had some stuff running including decoding the TLEs (Two Line Elements) but I had yet to show off actual orbital predictions.  But after some epic hacking sessions, that stuff is for real working.  I'm going to write those accomplishments up but for now what I want to talk about is this map stuff.  

    Two posts ago, I detailed some plans to get a satellite map running on Apple II hardware.  The first part of this was succeeding in the display of DHGR (Double Hires GRaphics) bitmaps.  As in BMP, the stuff that you can output directly from a modern version of Adobe Photoshop here in Twenty Eighteen.  That would provide the background map atop which I could display the satellite position.  This was harder than I thought it'd be.

    The first barrier to getting DHGR running on the Apple II was the lack of awesome documentation.  I mean, it was out there but for a guy like me used to including some standard libraries and pushing stuff to a display it wasn't exactly intuitive.  I will right now say that it took me a LOT of revisions to get it right.  I looked at a lot of on-screen garbage trying to puzzle out what was going on.

    So close.  

    So, if you'll excuse a little diversion I want to talk about Apple II graphics.

    First, the fact that we can display a 560x192 monochrome bitmap on the Apple II is kind of amazing.

    Woz, that is to say, Steve Wozniak, was a brilliant hardware designer.  He was working at Hewlett Packard when he started coming up with the schematics for what would become the Apple I, and he was all about efficiency in design.  Woz was absolutely great at making the very most of the fewest ICs possible.  It's fair to say that it would be hard to strip much out of the Apple II and get meaningful NTSC video out of a design.  The entire video system is based around the NTSC (and later, PAL) waveforms.  Woz basically looked at the required video signal and said, "How can I design a system with minimal cost and display meaningful graphics from a video buffer".  To be sure, his business partner Steve Jobs was probably totally on-board with this cost-optimization in the pursuit of producing an affordable computer with maximum sustainability for Apple.

    That said, the side effect of reducing hardware complexity was to increase the software complexity.  There was no sprite hardware, and the video modes played epic tricks with the timing of the video signal to produce colors.  As a result of this spartan hardware design, the higher resolution video modes became fairly complex when it came to memory maps.  In modern frame buffers, there is a nice linear correspondence between the byte stored in memory and its position on the screen.  On the Apple II, one finds themself hopping all over the memory map to load an image that will be properly displayed on the screen.  Line 2 starts at a position farther than it should from Line 1, as does each subsequent line, except...

    Read more »

  • How to Speak Transputer

    sup4rl33thax0r08/07/2016 at 02:27 4 comments

    Hello Hackaday.com readers! Not sure who submitted my project (if anyone) but I am excited to see it there nonetheless!

    When I last checked in, I was working on a solution for the graphical display of satellite position. I'd decided on the Bulgarian Pravetz Apple II clone as a suitable platform, and had been working away on some 6502 assembly code to draw the map and satellite position. I also said, "something-something hook Bulgarian Apple II clone up to transputers" and proceeded to ramble on about other stuff.

    At some point I did mention that a design for the link adapter interface would be forthcoming. Let it not be said that I don't deliver. I give you, the Keplermatik Interface Adapter:

    Yep. It's a circuit.

    First of all, the more astute observers among you will notice that there's a bit more going on with this board than a simple link interface. There are a few buffer chips, some LED arrays... Oh wait, it's...


    As I was drawing up this circuit, I started thinking about how handy it'd be to break out the bus signals for debugging purposes. That led to thinking about how old machines showed all that on the front panel, and at that point it pretty much came a foregone conclusion that Keplermatik was getting some sweet address and data bus activity indicators, a.k.a. Blinkenlights. For early development, there are some onboard LEDs that will provide a sweet disco scene under the hood, but more importantly there are some double-row headers toward the rear of the card that will connect via ribbon cable to a DB25 and DB9 on the back side of the machine. Later, the Keplermatik console will have some nice big blinkenlights that connect to those ports.

    So enough about lights, what about the super-awesome INMOS transputer link?

    As mentioned in an earlier post, this board is designed around an IMSC011 link adapter, pictured above. This is the chip that does the important work of allowing the Apple II to talk to those wily transputers.

    When in its Bus Interface mode, it's silly how easy the IMSC011 is to interface to the Apple II. The 6502 uses Memory Mapped I/O, and the Apple II has some special address decoding going on that allows a peripheral slot to know when it's being talked to.

    As seen in the above connector pinout diagram, Pin 41 of the bus is called "Device Select", and the decoding circuitry takes it low when any memory in the range $C0x0 to $C0xF is accessed (where x is the slot number + 8). This can conveniently be connected to the IMSC011's Chip Select (CS) line, which enables the link adapter when taken low. This signal, combined with the RW (read/write) line and two address lines, is basically all that's needed outside of the data bus to send and receive data through the link adapter.

    About those two address lines. The IMSC011 has a set of registers that can be read and written to determine link status. These registers are selected through various combinations of the RS0 and RS1 Register Select lines, and connecting these to the lowest bits of the Apple II address bus essentially maps those registers into the Apple II's address space. How, you ask?

    Remember how that device select line goes low when memory in a certain range is accessed? That's because the address decoding circuitry ignores the 4 lowest bits of the address, leaving them available for the device to do stuff with. So, if we connect the 2 lowest bits of the address bus (represented by the A0 and A1 address lines) to the IMSC011, then when the Apple II bus selects those lines in the process of accessing its memory the registers will appear on the data bus.

    Another side effect is that since we're ignoring A3 and A4 (and the Apple II isn't decoding them to select our device), then the registers actually repeat throughout that portion of the memory space! For example, the register at $C0x0 will also appear at $C0x4, $C0x8, and $C0xC.

    One thing about hardware of this vintage, there are no fancy SPI peripheral drivers or anything like that required to interface...

    Read more »

  • Graphics, retrostyle.

    sup4rl33thax0r07/25/2016 at 00:27 0 comments

    As I’ve been developing this satellite tracking console, the goal has been to create a really unique piece of hardware that does useful work. The fact that it’s built up from a very eclectic collection of parts is pretty important to the aesthetic, so when I started thinking about doing a map-based display of satellite location, I had to do some hard thinking on what to use.

    When it comes to Cold War-era display hardware, I first considered going purely electromechanical. This type of map can be seen in the James Bond movie, “The Spy Who Loved Me”. In the climactic scene, there’s a huge semi-transparent globe with lights underneath that designate the locations of the hijacked submarines and the nukes they launch. Major retrocool aesthetic to be had there, no doubt.

    The evil Stromberg didn't deserve a map this legit.

    Stromberg did not deserve such a legit map.

    Looking at how I could accomplish this, I considered using a piece of plexiglass that I would mask off and etch latitude and longitude squares into. This panel would cover a simple X-Y robot that could position a glowing LED anywhere underneath that panel, which could fade on and off in a convincing fashion to show the location of the selected satellite.

    While the effect would undoubtedly be fun to watch, the electromechanical technique had a major shortcoming. There was no way to easily show the curved line showing the future track of the satellite. This feature is one of the coolest things about satellite tracking maps, and I didn't really want to give it up. I considered trying to build the ability to form bezier curves out of a light pipe into the X-Y bot, but that was starting to get pretty complicated. I also thought about using a galvanometer and laser to trace the curve onto the panel at high speed, but I wasn’t sure about dumping that 80s aesthetic right on top of my 60s-style map.

    Since it was starting to become obvious that the display would most likely be purely electronic in nature, I started thinking about CRT-based displays. One of the first things that came to mind was to hack a vector board from an old Atari arcade game (like say, Asteroids) into the system and use that with some DACs hooked into the transputer hardware. There’s a lot that I totally loved about that idea, especially considering how much I adore those old Atari vector games, but there was another factor that played into my eventual decision: my long-standing desire to create something useful with 6502 assembly.

    The MOS Technologies 6502 is one of the most ubiquitous microprocessors of the 20th Century, and can be found everywhere from embedded systems to the original Nintendo Entertainment System. In fact, 6502-based hardware was responsible for some of the coolest consumer electronics of the Cold War era. Here’s a short, not all-inclusive list of 6502 love (including variants such as the 6507 and 6510):

    • The aforementioned Nintendo Entertainment System.
    • Commodore 64, best selling computer of all time.
    • Commodore VIC-20, predecessor to the 64.
    • Commodore PET, predecessor to the VIC-20.
    • Commodore 1541 Floppy Drive. Commodore really loved the 6502!
    • Atari 2600.
    • Atari 800.
    • Tamagotchi. 6502 in your pocket!
    • BBC Micro. Even the Brits loved the 6502.
    • Bender Bending Rodriguez, bending robot. Shown to have a 6502 in his noggin in the Futurama episode, “Fry and the Slurm Factory” :)
    • and last, but certainly not least, the Apple I and II. That’s right, the chip responsible for computing whether your beloved Mario fell into the abyss is the same one responsible for informing you of your death from dysentery.

    When it came to choosing a 6502-based platform to assimilate as part of this beast of a project, it was kind of hard to find one that fit the ‘theme’ of exotic, industrial-grade hardware. That list above? Full of gaming systems and kiddie stuff. None of them too rare, either.

    The whole 6502 idea might have actually stopped there, were it not for the fact that Ivan much preferred industrial espionage to actual engineering. There was...

    Read more »

  • TRAMs, Green Wires, and Fake B008s

    sup4rl33thax0r05/25/2015 at 20:01 2 comments

    Time for another project update.

    At the time of my previous report, my next steps were to get the orbital models running on real transputer hardware. Not the simplest task, considering the technological archeology required, but a fun one. So without further adieu, I present the transputer modules (TRAMs) in question:


    The one on the left rocks 2MB of DRAM and the one on the right 4MB. Kinda nice to have a real memory controller in these things. You can even run a real OS on one (or more). That's a story for another day, though.

    The next question becomes, how to load code onto these odd beasts? Today, in the world of Arduino and countless clones, everything is USB- and flash-based. You plug your board into USB and a fancy bootloader programs your code into flash memory, you reboot the micro and it runs your code. Not so, here. The TRAMs don't have flash (or any other non-volatile storage) and USB certainly didn't exist back then. Instead, the TRAMS usually wound up in an expansion board that plugged into the host computer. INMOS (creator of the transputer) designed and sold boards for IBM PC-compatibles, Sun SparcStations, and so on. One of their most popular boards, the B008, boasted space for 9 TRAMS and a name just begging to be giggled at by immature young men:

    Hur, hur. He said, "B008".

    Not my board. Wish it was, but alas they're rare as hen's teeth these days. I found one guy with a board on some random website, and emailed him to see if he'd sell, but he wasn't interested. Instead, I found one of these on eBay:

    What we have here is a sort of weirdo knockoff of the B008 (dare I call it a 'fake B008'?), made by a company called Transtech. They made industrial control hardware (for which transputers are pretty well suited) and advertise their TMB08 to be 100% compatible with the INMOS B008. Fair enough, so Buy It Now, right?

    Not so fast. In addition to a much less amusing moniker, I noticed a little bit of oddity in the above picture (which is from the auction). First, there's a little goofy module plugged into the leftmost TRAM slot. We also have a funny looking red porcupine looking thing on the right, that upon closer inspection has a bunch of wire-wrapped connections. And on the back, which I unfortunately didn't get a pic of, the TRAM0 slot was sporting a couple mysterious green wires soldered between its headers. Last but not least, this B008-shaped thing has a card edge connector the likes of which haven't been seen for a loooong time. That there, ladies and gentlemen, slots into the grandaddy of all IBM PC buses: ISA. This architecture debuted in the O.G. IBM PC (model 5150), in 1981. Good thing that I have one of those, so I decided to ignore all of the oddness and give it a shot. TRAMs installed in board, I plopped it into the 5150 and attempted to establish communications. Unsurprisingly, that was a failure.

    That thing on the left: Fake B008 plus two TRAMS, sitting snugly against the CGA board of the 5150. You can see one of the bastard green wires sticking up shortly after I forcibly disconnected it from the top header of the TRAM0 slot.

    So I spent approximately a whole evening attempting to ignore the oddity of the weirdo module, porcupine thing, and mysterious green wires. Instead, I went through the pain of trying countless combinations of IO addresses, IRQs, and DMA channels in an attempt to get a response from the board. In retrospect this was silly, though I have to say that IRQ conflicts and such were pretty common back in the day and it wasn't uncommon to spend some frustrating evenings doing battle in the same way.

    Finally admitting to myself that I was going to have to dig into whatever logic was behind the strangeness, I set to researching both the B008 and the TMB08. I found schematics and other documentation, and it became apparent that the TMB08 was, as advertised, compatible with the B008 but that mine had been in some way altered.

    The porcupine thing turned out to be slotted in where an INMOS C004 32-way...

    Read more »

  • Adventures in Retro Display Technology

    sup4rl33thax0r04/21/2015 at 06:45 0 comments

    So the console actually has two sides, one built out of vintage 60s/70s/80s American computing and interface technology and another out of Soviet. The American side is going to handle calculating the satellite's relative position to the station, and the Soviet side is going to handle tuning the radio for doppler shift and antenna positioning. As alluded to in an earlier post, the American side is going to use INMOS transputers, while the Soviet side is going to use a hand-built computer based upon the KM1810VM88, a Soviet clone of our well-known Intel 8088.

    I recently settled on numeral displays for American side of the retro satellite tracker console: the Sperry/Beckman SP-353. It's a gas-discharge display that was developed in 1971 as an improvement upon nixie tubes and sports numerals 0.55" tall. Kind of a pain to drive, but definitely suits the overall aesthetic. I did consider using nixies, but I'm kind of sick of seeing them everywhere!

    On the Soviet side, I'm going to use IV-22 VFDs. They're actually somewhat similar to the SP-353s in driver requirements.

    Combining these with assorted American and Soviet indicator lamps and buttons on each side should make for a pretty neat looking result. Finally found some proper Tellite switches for the American side of the console, more on that to come. Still researching what's appropriate for the Soviet side.

    Also still trying to decide whether to interface the displays and switches directly to the vintage calculating hardware for each side or use modern hardware as drivers to simplify the interface requirements. I think it may be reasonable to directly interface the transputers with some C012 link chips, but it's really tempting to use an XMOS on the Soviet side to handle all the displays and switches. Decisions, decisions.

  • Transputers?

    sup4rl33thax0r04/21/2015 at 06:13 0 comments

    At some point in planning this project, I stubbornly declared to nobody in particular that the hardware in question had to be era-appropriate and suitably exotic. Preferably something used in spaceflight. Something not commonly found in home or business computing. Something Cold War-era. Definitely not a modern microcontroller.

    Enter the Transputer.

    Used in spaceflight? Check.

    Era appropriate? Check.

    Exotic? Double-check.

    Transputers were an early technology from the "golden era" of massively parallel computing (say, the early 80s). They introduced some groundbreaking concepts that are still used today, even though not many people have heard of them. I'm not going to dwell on the fine details here, but look 'em up. Also check out their modern descendant, the XMOS microcontroller.

    So transputers (the OG ones, not the XMOS descendant) are what's being used on the American side of this beast. The Soviet side will be sporting something a little different, more on that in a future post.

    As one of the first steps in this project, I've been re-implementing the Simplified Perturbations Models on INMOS transputers (props to those who have come before me on more standard platforms, and from whose work I'm drawing heavily). The models were published in 1988, the transputers came out in 1985, and the frustratingly-ancient INMOS C compiler I'm using was published in August 1990. As the screenshot attests, making some real progress despite the challenge of dealing with ancient high-tech gear. The code that's complete thus far compiles and is up and running on an emulator, with real transputer hardware hopefully not far behind!