Close
0%
0%

Project Seven

Bringing deep learning to platforms such as the Raspberry Pi, Parallax P2, or maybe an Altair 8800 for general robotics and other things.

Similar projects worth following
Welcome to Project Seven. Why not, call it something else, you might ask? Well, ATT once had some operating system or "whatever " it really was, which they called "Plan Nine". That of course is an awesome title; that seems to allude to the classic "Plan Nine From Outer Space.", whether that was intentional or not. Hence, why not call this project, "Project Seven?", since up until now I have posted six previous projects? That should seem logical enough.

Now, what does "Project Seven" do? Well, anything we know how to ask it to do, of course - to borrow from a famous Ada Lovelace quote. Thus, "Project Seven" will be a platform for experimenting with Artificial Intelligence applications by using microcontrollers, and for doing stuff like using AI to try to get simple robots to solve mazes, recognize simple English commands, and so on, in addition to doing simple stuff like sequencing MIDI, or playing Lunar Lander.

The field of A.I. in electronic music should have great potential for developing new approaches to the ever-present issue of how to address the ever-changing challenges with respect to how to develop new strategies in the realm of education, with a particular focus on so-called "STEAM" programs, for example.

What if we could train an AI to recognize patterns in a musical passage, or collection of musical passages and then apply whatever rules that we can deduce for the purpose of creating new compositions?  Perhaps some very interesting results might be obtained from a system that employs just a few "virtual neurons", whether that might mean that it might need a network where the number of nodes only a few "dozens" or "hundreds" of nodes, instead of numbering in the billions, that is - in order to achieve some interesting results - is something yet to be determined.

Traditional digital audio workstation software (DAW), however, is not oriented toward the manipulation of unusual, and in particular, custom data structures, such as the types of data structures that might be generated internally, if we were to use a Tensor-Flow or GPT-style model in the domain of input analysis.  So this will require custom software on the PC, side of things, or on the Raspberry Pi side of things, if we go that route, i.e., with respect to any issues with content creation that might arise.

Then there are the issues of hardware interfacing with traditional electronic instruments, and/or interfaces, where a much simpler, and therefore easier to implement, set of requirements will need to be addressed.  For this, we might want to implement a simple Z-80, 6502, Arduino, Propeller, or Pi-based interface.

This project will proceed on several "forks" therefore, with a view toward providing a balanced, and integrated approach to the issues discussed so far, while at the same time providing a cohesive framework that works in each of those domains.  The emphasis, therefore, will be in "getting something up and running", that WORKS, on the one hand, and yet which provides, "room to grow" - while documenting the paths and steps taken, as well as some of the pitfalls, encountered along the way.

Economic factors will need to be taken into account.  Obviously, when developing hardware and software materials that might be within reach of the programs that might be offered by many middle schools; as well as the secondary "college prep" educational frameworks; there is the possibility that some school districts might want to invest in perhaps hundreds if not thousands of "systems".   Therefore, if recycled materials that are widely available can be repurposed and for good use, then any approach which makes such a good use, thereof, while at the same time integrating "state of the art concepts" will clearly be seen as being superior to many other initiatives, no matter how lofty their achievements. 

prometheus.pdf

Notes from a previous project on converting the UCSD Pascal Compiler to C++ while Creating a New type of Compiler for AI – Neural Applications by giving them Digital DNA

Adobe Portable Document Format - 225.17 kB - 04/22/2023 at 19:15

Preview
Download

  • 1 × Altair 8800 computer, or any CPU capable of emulating an Altair, or other suitable 8-bit processor, such as the Arduino Every.
  • 1 × Sound Blaster MIDI cable.
  • 1 × Electronic Keyboard, Drum Machine or other MIDI equipment featuring a traditional 5 pin DIN style MIDI connector
  • 1 × Prototyping supplies, such as perf board, IC sockets, DB-9 and DB-15 connectors, or cojmmpatible headers
  • 1 × Software for this project, which will be made available on GitHub.

View all 7 components

  • Additional notes on interfacing the 6850 UART

    glgorman04/23/2023 at 05:39 0 comments

    Here again, is the code just discussed for reading the serial port and then displaying the data on the status LEDs, but now it has been split into an initialization section and a main loop.   Obviously, we should also want to do something with the data as it is input like storing it in a buffer, but this is a very useful piece of code that can be used for testing purposes.

    INIT1:
      LDA  0x1f   ; reset the UART
      OUT  0x0a   ; configure for eight-bits + odd parity + one stop bit
      LDA  0x1c   ; at 1X clock rate
      OUT  0x0a
      RET          ; or HALT?
    
    LOOP: 
      IN   0x0a   ; get port status byte
      AND  0x01   ; mask for Rx status bit
      JZ   LOOP
      IN   0x0b   ; read the data
      OUT  0xff   ; display front panel LEDs
      JMP  LOOP
      NOP
      NOP

    It would also be nice if this code were interrupt driven.  Changing the infinite loop to a return at the end gives us a callable function.  Then we need to call INIT1 to initialize the port, and then we could call GETCH, whenever we want to get a character.  This works for polled I/O, that is if we don’t mind having our application hung while waiting for input, when in fact we want if to be able to do other things, like maintaining time code, streaming MIDI, and so on.  Of course, if we are going to be working in a high-level language such as Pascal, C, or even C++, then we will probably want some functions that we could call, and that have names like PEEK, GETC, READ, etc.

    INIT1:
      LDA  0x1f   ; reset the UART
      OUT  0x0a   ; 
      LDA  0x9c   ; for PS2 kbd configure for 8-bits + odd parity + 1 stop bit
                  ' at 1X clock rate, and generate interrupts on RxByte
                  ; FOR MIDI data - there should be NO PARITY - and the 
                  ; clock rate is 16X - so change this to LDA 0x95
      OUT  0x0a   ; 
      RET
    
    PEEK:
      IN   0x0a   ; get port status byte
      AND  0x01   ; mmask for Rx status bit
      JNZ  GETC
      LDA  0xff   ; return EOF if port not ready
      RET
    
    GETC:
      IN   0x0b   ; read the data
      OUT  0xff   ; display on front panel LEDs
      RET

    Now let’s rewrite what we have so far to read data from the PS2 keyboard using interrupts.  According to the 6850 UART data sheet, setting bit 7 enables the receive port interrupt, and on the MITS 88-2SIO serial board, the IRQ level is set by a jumper wire on the board so as to point to an octal address in the zero page, 0X0, giving us just eight bytes to store the interrupt service routine.  Since we have 24 bytes so far, it should be obvious that the ISRs will have to go somewhere, and that the zero-page locations will contain a simple dispatch function.  The 88-VI-RTC board will also need to be configured to allow interrupts at the appropriate level, and so on.

    At a certain point, we will also need to start counting the number of CPU cycles that are used in servicing the read request.  MIDI messages frequently contain multiple bytes, which are generally sent consecutively, in 8-bit format, with one stop bit, and no parity.  For example, according to Wikipedia, a full MDI time code message looks something like this: 

    F0 7F 7F 01 01 hh mm ss ff F7

    This will most likely be sent by a remote device in burst mode if our device is receiving the time code.  So, although receiving bytes from a keyboard might seem quite leisurely, with MIDI streaming at 31250 bps, we will need to be able to handle up to 3125 bytes per second, which gives us a “budget” of about 320 microseconds per byte received, which will allow for no more than 160 8080A instructions to be executed, given a 2 MHz clock, or else we risk a buffer overflow since the 6850 can only buffer one already received character, in addition to any that are presently being clocked in.

    The manual for the MITS 88-VT-RTC includes some sample code for creating a simple clock that is interrupt driven, and that allows the current time to be read from BASIC.  Using this...

    Read more »

  • PS2 Keyboard Input Now Working On The Altair

    glgorman04/21/2023 at 21:47 0 comments

    Here it is!

    The MITS 88-2SIO dual serial port card has the ability to be configured, via a rabbit warren of jumper wires, for either TTL, RS-232, or Teletype mode.  Likewise, the baud rate is also selected via jumpers, with separate jumpers for the two 6850 UARTs.  So I configured one of the two ports for TTL, but without RTS, CTS, or DCD handshaking; which frees up about six now unused inverters on some 74LS04 ICS, which have the VERY convenient jumper positions made completely easy to use.  After reading the 6850 UART datasheet, it appears that the wants to capture data on the rising edge of the clock, which is the opposite of what I saw on the oscilloscope when probing the output of the PS2 keyboard directly, i.e., the keyboard outputs the clock line held high via a 2.2K internal resistor, which then goes low for eleven pulses when the keyboard is sending data.  So I think maybe I need to invert it for proper operation.?  Well, that turns out to be quite simple, by routing a pin from the Molex connector to an unused gate on one of the 740LS4s, which therefore provides some anti-static buffering, as well as the inverted clock signal,  that I THINK that I need.

    So I put together a simple 8080 machine language program to read from the keyboard and to write to the data LEDs.

    ORG 0000:
    
           LDA  0x1f   ; reset the UART
           OUT  0x0a   ; configure for 8-bits + odd parity + 1 stop bit
           LDA  0x1c   ; at 1X clock rate
           OUT  0x0a
    LOOP:  IN   0x0a   ; get port status byte
           AND  0x01   ; mmask for Rx status bit
           JZ  LOOP
           IN   0x0b   ; read the data
           OUT  0xff   ; display on front panel LEDs
           JMP LOOP
           NOP
           NOP

    O.K. Then.  What now?  Obviously need to come up with some code to do the translation of PC scan codes to ASCII, but there is a bunch of other stuff that comes to mind.  Like working on the interrupt-driven versions of the I/O routines, and testing the ability of the Altair to also send and receive MIDI data, using the interface module that I am also working on, even though that module will eventually be equipped with something like an Arduino Every, as I have discussed previously.

  • Tick Tock. Tick Tock. Hickory Dickery Dock.

    glgorman04/17/2023 at 05:22 0 comments

    Even though this ancient S-100 prototyping board has seen better days, as can be seen by the missing pads on some of the address and data lines, it can still be put to good use.  Here I am grabbing the 2 MHz system clock on pin 49 and sending it to a 74LS74 which is being used as a divide by four.

    And thus we can obtain, by very simple means, a nice, clean, stable 500 kHz derived clock signal which can be passed on to one of the 6850 UARTs(Hopefully), so that when that particular UART is run in 16x mode, it will be able to send and receive signals at the MIDI data rate of 31250 bps.  At which point I should hopefully have no problem getting the Altair to stream MIDI data in, and thereupon use it to make the front panel LEDs blink in interesting ways; like with MIDI data in real-time.

    Of course, this might be fun to build ... eventually.

  • Trying out the latest version of KiCAD

    glgorman04/13/2023 at 07:49 0 comments

    This is so totally preliminary, but why not?

    Well, this is going to take a while; but wow!  O.K., sure.  Why not?  I know I am kind of old school about this sort of thing.  So I thought I specified a 15-pin IDC connector, and it gave me a connector with 2 rows of 15 pins, and now I realize that maybe what I really want is the connector that has two rows of eight pins.  It also placed the Arduino module 180 rotated 180 degrees from how I would want it.  This is going to take a while.

    After about an hour of fiddling around.

    I noticed of course that the KiCAD software numbers the pins on the IDC connectors differently from how they are numbered on the DB-15 connector, which I will explain further at some point.

    In the meantime, once upon a VERY long time ago, I actually made my own "sound card" for my Apple II+, by creating a very simple, but working data bus grabber that I could plug into any available Apple II slot.  Then I ran the ribbon cable to some proto-board where I put together a simple D-A converter which used a 74LS374, IIRC, along with some resistors in a variation of the typical R-R2 configuration, to in turn implement the D-A part.  This was done in such a way as to allow for the selection of either 4-bit stereo, or if the two output channels were tied together with a hand-selected resistor, I could have 8-bit stereo,  Then I created wavetables in BASIC and saved the wave files to a floppy disk so that I could then play back pre-recorded "samples", as it were by using the BLOAD DOS call to load the samples, which were usually 256 bytes in length, and which could be played by an appropriate CALL to the hand-assembled "driver" which would output at 25,600 samples/second.  And it just simply "worked", and probably would still work except for the fact that my II+ has keyboard issues, and although I also have an Apple IIe motherboard, I don't have a keyboard or case for that one at all.

    Yet in any case, here is how the "universal I/O" concept could come together.  Maybe I rip apart my much beloved Apple II bus grabber from days gone by and build my "new and improved" universal I/O module so that I get EXACTLY the features that I want and NEED for the II+, and possibly the IIe, and all of the rest, as previously discussed.

    Learning how to do everything in KiCAD is going to be a bit of work, but the results are going to turn out so much nicer than trying to do this the old-fashioned way.

    So, even though this actually works, I think I will end up with a strong preference for the new and improved method.  Even if it can be quite a bit of fun to just simply sit down with a bag full of old parts, and test fit this, or that, here or there while trying to figure out "how the busses" are going to route when all gets said and done.   Maybe throw in a Propeller chip for that Apple II, to get some VGA mode, but then there is a 3.3-volt vs. 5-volt issue, and whether to use proper MOSFET-based level shifters or just latches and resistors.  Now if I join the "surface-mount" bandwagon, then a lot of that stuff becomes a lot easier to work in, whether it is resistors, FETs, latches, etc., even though that totally messes up the "retro-feel" of things, there are some nice payoffs in terms of making the best use of board real estate, and of course, staying within the power budget - since and Apple II, or a Commodore 64 for that matter, is much more constrained than a full-size Altair, (with it's 18 AMP power transformer), for that matter.

    Yet I found a Z80-style dual bidirectional parallel port chip, which might turn out to be useful.  Let's suppose that I use it on the Apple II side of things while letting an Arduino handle all of the control lines.  Given that it REALLY is possible to just simply connect up a 74LS374 directly to the data bus, slot enable and write lines, and get something that works like a "port", on the one...

    Read more »

  • Ground Control To Major Tom

    glgorman04/12/2023 at 18:02 0 comments

    As discussed earlier, MIDI signals are able to be sent and received from the board, so now I am working on adding a PS2 keyboard interface option.  This particular IBM keyboard seems to work just fine, without having to do any communications on "wake up" before it will talk to an external device.  However, it did suffer from breakage of the original mini-DIN connector, many years ago, and rather than try to repair it at the time, I simply went out and bought another one.  Just like nearly everyone else in our modern throw-away society, where if you had to pay someone to fix something, it all too often will cost more than a new one.  Well, for now, maybe I will go ahead and put a DB9 connector on the keyboard since there is actually a standard for that, and then I am also adding a connection to my MIDI interface dongle, which is starting to look like it could turn into a mini-Altair in its own right.

    For now, the LED board is incomplete, and does "nothing", but at least the interface board is sending +5V to the MIDI cable and getting MIDI data back, with the PS2 interface to be added next.  This will greatly simplify testing - if I decide to go ahead and connect it, using jumper wires, to an Arduino 2560.  Of course, as I noticed just yesterday, the "Arduino Every", might turn out to be the ideal path to take for this particular device.

    Yet, a bunch of stuff comes to mind.  While on the one hand, there are other Altair emulators out there, those, for the most part, tend to emulate the features of the 8800A front panel, leaving out some otherwise very interesting, and well as potentially useful features of the 8800B.  In particular, the 8800B version of the Altair, has some front panel switches that do things like "load and/or display the contents of the accumulator", as well as "reading and/or writing to specified I/O" ports.

    Now I really don't want to go full Monty on this, with a design that might somehow display the contents of ALL the CPU registers, on row after row of blinking lights, just like the old UNIVAC display consoles that Irwin Allen repurposed, well, you know, in "Lost In Space", and "The Time Tunnel", and I think even in the basement of the "Towering Inferno."  Now imagine that one - a computer-controlled building?  Now, who would have thought of that?  Then there was the time that Starbuck and Apollo had to infiltrate a Cylon Base Star so that they could blow up the Base Star's control center.  I think that that one was a two-part episode, from the original series, entitled "The Living Legend".  Lots of blinking lights, and worth checking out.

  • Interfacing the PS/2 Keyboard to the Altair?

    glgorman04/11/2023 at 23:31 0 comments

    Now that I am getting MIDI data with an actual piece of hardware, I am considering adding a PS2-compatible interface to some unused area of board real estate, for use of course with the Altair, when I get the MIDI sequencer software up and running in some sort of "stand-alone" mode.

    Now what we are seeing here is what this particular IBM keyboard just so happens to put out, when I jam the "Num Lock" key, which contrary to what you might have heard, is processed just like any other key.  The difference between CAPS LOCK, and NUM lock, from other keys, therefore, is in how the PC responds when those keys are pressed, and that is by responding with some signals that tell the keyboard to turn certain lights on and off.  Now if we don't implement the bi-directional part of the protocol, and in effect only let the keyboard do the talking, then it appears that the keyboard is giving us eleven clock pulses for every key press, or repeated messages in case of s "stuck" key, as seen here; that is - along with the data which is on the data line.  That's it!  Oh, and of course mapping the IBM key codes back to ASCII, which is easily done in software.

    Now this suggests to me that MAYBE I should try my hand at PS2 keyboard decoding using one of the available UARTs on my Altair 2SIO serial board, which of course right now has a fried baud rate generator chip, that I will have to find a replacement for, or else I will have to fabricate something custom, which I am also contemplating - in any case, since MIDI runs at 31250 bits/second, and that would require a 500 kHz UART clock, which is quite easily done by dividing the 2 Mhz Altair system clock by four with a 74HCT74, or else a 74HCT163.

    Unfortunately, right now I only have one serial board (with two ports), so I will have to think of something else, if I want the Altair to support direct keyboard input, MIDI I/O, and have a PC connected via a USB dongle.

    One of the nice things about the Parallax Propeller P1 chip is that it is available in a through-hole 40-pin version, so it is possible to contemplate designing an all-new board that at least looks like it could have been made in the late '70s, or early '80s.

    So there is a method to some of the madness after all, and that is because of the principle of "design" reuse.  Thus I have "built something" so far that could evolve into a Pi hat or a stand-alone protocol converter, or maybe it could become a Commodore64 compatible cartridge, or maybe I could also have a PS2 converter for my Apple II, or maybe it could be a traditional Arduino form factor shield.

  • What I don't like about Arduino

    glgorman04/11/2023 at 07:16 0 comments

    Here we have a general concept, of something that could be accomplished.  Let's suppose that I have a custom board fabricated for my MIDI interface, which I built earlier today, using a combination of through-hole and surface mount components.  In particular, what would happen if I used a surface mount version of the 328P, along with any level shifters, etc., that I might need for Propeller or Raspberry Pi interfacing?

    So that could be used to make a stand-alone module.  Then what if I leave some space on the board for a through-hole version of a 74HCT374 or something like that, which could then be inserted into a wire-wrap socket that could be soldered to the top board; but then the wire wrap pins could extend into the bottom board, where maybe only the power pins, and or corner pins would need to be soldered, i.e., so as to make potential disassembly - not impossible, just in case.  This technique would allow for the construction of separate modules, where one module might be an extremely compact and otherwise fully self-contained 6502 computer, with CPU, RAM, and ROM; while another module could be an external I/O module, and yet another might be part of a debugging system, with or without blinking lights.

    Then in effect, we could build up four or more layer designs, by creating individual modules that would then communicate through a "back-plane" of sorts; which would allow for the creation of a "final board" design - that can then be custom ordered and built up according to the final "project integration" plan; and with a good expectation that it will just simply work, "right out of the box", the first time.

    Now if you have ever tried to plug an Arduino module into a prototyping board; you know about the header spacing glitch; which also makes it impossible to place "shields" side by side on a regular perf board.  Which makes it completely unsuited for professional work.  Clearly, something better is needed.

    Here we see how the external IO might eventually use a multi-layer board to integrate with a larger system.

    Well, in any case; I have reached the point, now that I have a way of getting MIDI signals in a board-friendly format so that I can consider the possibility of continuing with the real Altair MIDI project.  Or is it going to be an Apple II MIDI project?  Or will it be a Raspberry Pi MIDI dongle?  Maybe it will turn into a MIDI everywhere micro-sequencer!  Oh and let's not forget the time code.  Yeah, time code.  Gotta have time code, in some form or fashion.

    Then again some of the newer Arduino stuff, like the Arduino Every, are looking fairly attractive, and I think that I just might be able to find a place to sneak in a pair of 15-pin headers.  Yeah, so I download the latest datasheet for the Arduino Every, and it says something like "revised" on 4/11/2023. 

    When did they say that that was?  Hmmm.

  • The Unicorn is in the Garden

    glgorman04/11/2023 at 03:35 0 comments

    Started working on a dongle to connect the Sound Blaster MIDI cable to the Altair, or perhaps a Raspberry Pi, or else an Arduino - or perhaps it can be made to work with "all of the above."  Here we are receiving some MIDI data from a Yamaha keyboard which is playing some material in demo mode.  I scavenged a DB-15 female connector to IDC connector via ribbon cable from an old PC, that probably went to the recycler years ago, and that is how the Sound Blaster MIDI cable normally connects to the game port of a PC, that is if it still has a traditional game port.  Added some IDC header pins and other goodies to some perf board, and presto, "instant" MIDI to "whatever" dongle, well, hopefully soon enough.  Now as far as the Sound Blaster-compatible MIDI cables go, that part is pretty simple to wire up.  Apparently, pins 4 and 5 are connected to the ground, then +5 volts should connect to pin 8, and that provides the power to some internal circuitry that is built into the cable assembly.  Finally, MIDI data from a remote device will appear on pin 15, whereas pin 12 can be used to send MIDI data, which will need to be clocked at 31250 bits/second. 

  • OK Then, Let's actually build SOMETHING.

    glgorman04/06/2023 at 20:13 0 comments

    Some stuff that might actually turn out to be useful

    If you have access to a genuine Altair or a full-size replica, that would be awesome - but fortunately, it is not a requirement.  That is because Altair emulators can be run on any Arduino. However, I haven't looked into whether an Arduino can handle the 31250 bps data rate of standard MIDI AND still talk to another device over a USB dongle at the same time.  If it all works out well, hopefully, it will turn out to be possible to turn a bare 328P chip, without the Arduino base into a full-fledged MPU-401 compatible sequencer, that just might be able to run "stand-alone" or while tethered to an attached PC.  Or there is the Z-80 route.  Of course, if you want to try the "real Altair" route, then it will be necessary to obtain a vectored interrupt board, in addition to a board with hopefully at least two working UARTS.

    Now if you can lay your hands on one of those game-port MIDI cables that came with every Soundblaster ever sold, back in the day, then you are also way ahead of the game, as far as that part of the project goes, and that is because those cables usually have the required optoisolators built into the cable, which saves us some work.  An old standard PC joystick might be fun to mess around with also.  So get busy scavenging your junk drawer.

    Then on the software side, it would also be nice to have something that runs on the PC side that just might make, well, whatever hardware we end up using, actually do something interesting, like playing music or running a new and improved version of "Lunar Lander", or whatever.  The fact that the MIDI protocol is sometimes used in robotics, whether in an industrial capacity or in some entertainment-animatronics applications, should not go unnoticed, either.  Thus whether we end up with a musical device that might be tethered to a DAW, or whether it is capable of running standalone as a true sequencer, remains to be seen.  Yet that is also one of the goals of this project.

    Of course, I want to get it up and running on the Altair, and have some kind of application running on THAT machine, just for the sake of the coolness factor.  These machines are certainly capable of doing much more than just playing "kill the bit", or running BASIC as a demo.  So some assembly language work will need to be done, for the custom stuff that is yet to be accomplished.  Yet nonetheless, for convenience, most of the development will be done in C/C++ on a PC, with an eye toward writing compatible code that will also, eventually compile and run on any of a number of microcontrollers.  

    Now as far as instant gratification is concerned, reading data from a USB to RS-232/TTL convertor at one speed, such as 231 kbps, and then repeating them at another speed, such as the 31250 MIDI rate, seems like a simple enough task. Hopefully, it is also one of those things that can be done pretty much as an afternoon project.  That is, once all of the hardware is hooked up, and the toolchain is configured.  Since like I said, that part will mostly be just reading some data, and then writing it, either in a loop or ideally with interrupts.  Yet, once we get to that point, all kinds of new, interesting, and hopefully fun possibilities should emerge.  Like sequencing, or using pitch detection software to control a vocoder, which would be a separate device (they exist).  Yet, we will be doing this stuff using the Arduino or Altair-based MIDI, and that will give us some very fine-grained control of things that we can't otherwise do with traditional (read: commercial) DAW software - especially in a live environment.

    Of course, on the side of economic factors, last time I checked, a 328P microcontroller can be hand for just a few dollars, that is, without going the fully Arduino route - which suggests to me something that might be very important in an educational environment,...

    Read more »

  • There is something WEIRD about this Altair!

    glgorman04/03/2023 at 16:06 0 comments

    At some point, I think I will upload a YouTube video about this.  This is weird!  Either Ed Roberts was a truly mad genius, and he invented something that even he didn't know about, or else, in some other form or fashion there is something else really weird, and perhaps undocumented about just this particular Altair's front panel, which is acting like another one of those not quite yet discovered but begging to be appreciated and therefore also "undocumented feature" lurking in the Altair series all these years, that, as stated nobody seems to have discovered - as of yet, or at least until now.  Or it is really just something balky about the front panel on this particular machine that nonetheless begs to be understood, and of course, hacked, and therefore - exploited!

    Let me explain further.  I bought this particular machine off of eBay something like twenty years ago, or thereabouts, knowing that the seller was selling it, AS-IS, even after disclosing, that it "powers up", but address LED A10 never comes on, neither does data LED D2, and it may have been otherwise impossible to test because although RUN-STOP seemed to work, Examine did nothing and so on.  

    I found that the problem was a defective IDC connector on the Interface board that was refusing to make consistent contact with the ribbon cable.  So I had to replace the IDC connectors and the ribbon cable with a new set of IDC connectors (which were a bear to remove and replace) and a "new" set of ribbon cables made from a set of standard 34-pin floppy connectors.   So far so good.  Everything seems to work so far, except for LED D2, which MIGHT actually be a problem with the front panel, like maybe a bad 7404 or perhaps an actual bad LED.  I don't know yet.  But I just discovered something that seems hauntingly familiar, on the one hand, based on what I think I remember about these machines from back in my college days if you know what I mean - but then again? Well - suffice it to say that I would have never guessed what was about to happen - that is besides the half a dozen other things that have gone wrong in the last couple of weeks, that I will discuss later - like the fried bridge rectifier, the shorted capacitors on the video board, and so on.  Yet that's not the really interesting part.

    O..K, then, this is where things just got really weird.  I started working on an Interrupt driven set of I/O routines since I have not only the REV 0, dual serial board, but also a genuine Vectored Interrupt board, and something that might be fun to try would be writing a simple MIDI sequencer, where I could perhaps burn a MIDI file of something like Beethoven'f fifth symphony to an EPROM and then set the RTC to fire off interrupts every 1000 microseconds, or so so that it can pump out MIDI messages over one of the serial ports, which I could then hook up to any actual MIDI instrument.  That should seem simple enough to implement, right?  Just wait for an interrupt to fire, increment a counter, and then compare the "tick count" against the MIDI time associated with the next event in the "file" that I might have to read from EPROM since I don't have an Altair floppy.

    Well then, so I started toggling in some hand-crafted machine language, just to test things, on the one hand, and for proof of concept on the other - and then things got weird as I said, and which I will explain further, soon enough.

    So I toggle in something like this, and I never expected to see what happened next!

    ; data values in OCTAL
    
    0000:  333 377          IN 377        ;  read sense switches
    0002:  323 377          OUT 377       ;  display on data LEDs
    0004:  303 000 000      JUMP 000 000  ;  loop forever
    0007:  166              HALT
    
    

     Now, when this is toggled in just like what you see here, it works simply enough.  The 8080 goes into an infinite loop reading the "sense" switches, A8-A15, and updating the data LEDs with whatever is toggled in at the time.  Simple...

    Read more »

View all 10 project logs

  • 1
    Getting Started

    This project is under continuous development.  At this time, if you can scavenge the required components, then you can follow along as the project continues to take shape.  Eventually, I am planning on having an actual "universal" board made by an outside board manufacturer.  So it is always a good idea at this point to use sockets and standardized connectors, for the eventual conversion to the final build.

  • 2
    Download the Software

    If you look at some of my previous projects, you will find that I have been doing quite a bit with custom software on the PC side of things, working with Visual Studio.  In the GitHub repositories, therefore you will find C/C++ code for serial port interfacing, printing sheet music, creating oscilloscopes and spectrum analyzers, etc.  There is also a port of the UCSD Pascal compiler that is in the works, which will (hopefully) eventually include some  DSP tools for Audio, etc., that will work with Propeller and other microcontrollers, with or without an attached PC.   

    Thus the software support for the project is "extensive", yet the purpose of the software, therefore, is NOT to provide a finished product, but rather to provide a "framework" that solves many of the "show stopper" problems with microcontroller interfacing that arise when the time comes to create something that "works in the real world" and not just "in the manufacturers' sandbox."

  • 3
    Just Build Something

    You should be able to figure out this part.  This is a modular, multi-platform solution "space" with wide applications.

View all 4 instructions

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates