Project Logs

Collapse

• 2024 Update

  glgorman • 05/10/2024 at 16:39 • 0 comments

  I have started a new project entitled Narcissus 12.0 which you can, of course, find right here on Hackaday.io,  Although I'm not currently doing anything new with the Altair as of right now, I do eventually want to be able to play "Global Thermonuclear War" in the classic WOPR-Wargames style on it - which will, of course, require some kind of chatbot that is ideally capable of running on 8080, i.e.,, maybe something that works like Eliza, on the one hand, but which also provides a front end to a CP/M like operating system, yet which offers more functionality - let's say - like Busy Box.

  Now most of this might turn out to be quite easy to do if I would just simply get the Altair running in terminal mode, that is by burning some EPROMS with the stuff that I have so far, like the MIDI codes, and the PS/2 interface.  This is because I also have an 80x25, late 7'0s vintage video board that, while it needs some repairs, might be able to be made to work again.  Then maybe I could run the WHOPPER code, when I get it written, perhaps on a Raspberry Pi, or Propeller module, as previously discussed.  It is always best to try to push the 8080A original hardware to its absolute limits, of course.

  So, yes. hopefully, I will be doing something with the Altair again, soon - but in the meantime, and on the software side of things, further development will be proceeding along the lines of my newest project, as stated at the beginning of this post.  Thanks for checking in!

• Additional notes on interfacing the 6850 UART

  glgorman • 04/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

  glgorman • 04/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.

  glgorman • 04/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

  glgorman • 04/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

  glgorman • 04/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?

  glgorman • 04/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

  glgorman • 04/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

  glgorman • 04/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.

  glgorman • 04/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 »

View all 11 project logs