Rockwell famously used 6502-based cores in modems for many years, but that doesn't mean other 6502s couldn't be used. If only there were a way to connect a Commodore 64's audio output directly to an RJ-11 plug ... Convergent WorkSlate stuff I've got to catalogue. Officially the WorkSlate's only means of telecommunications is its 300 baud internal modem. While we have a 9600bps way of wiring up a Workslate to a modern computer, it's always nice to have a simpler alternative, and I figured this would be a great challenge to see if John's old program could let my Commodore SX-64 talk to my WorkSlate. Spoiler alert: it works! I don't know precisely what happened to John; regrettably I know little of his personal history. For a period of time he was a very prolific poster on comp.sys.cbm, but his last post there was July 19, 2000, in which he replied to someone's question about the relationship between sound frequencies and SID register values. (We'll actually talk about this in a bit.) His last post I can find in any Commodore newsgroup of the era is dated the next day, July 20, though he posted through CompuServe and it's possible may have made later posts there. Among his many contributions, including this one, are the Spyne self-extracting file archive utility, a .d64 downloader patch for Common Sense, an in-place PETSCII to ASCII text file converter, a user port-based audio A/D converter and player, and a custom track-by-track floppy disk formatting tool. He issued them all freely for anyone to use for any purpose. While he and I briefly corresponded over snail mail, I can't find the letter he sent me and I don't remember his exact location, and I never heard from him again. Sadly, although I hope I'm wrong, from his handwriting I knew he wasn't a young man and I'm all but certain he has since passed away. Rootsweb lists a John J. Iannetta who died in April 2001 at the age of 82. (If you know for sure, post in the comments, or E-mail me privately at ckaiser at floodgap dawt com.) The "35-cent modem" was first posted on October 27, 1998. John estimated the 35 cent cost based on the then-purchase price of an RCA jack ("listed in my Jameco catalog at 35 cents each"), though this didn't include the phone cable, or about 68 cents in 2025 dollars. Looking in their online catalogue now, you could even go cheaper, since Jameco (not affiliated, not sponsored, just using for comparison) now sells a through-hole right-angle RCA jack for $0.29 — in 1998 dollars, that would have been a mere 15 cents. If you don't have a landline phone cable anymore, the lowest Jameco price for a compatible connector I could find was a 6P6C modular cable for $1.49. Such a cable is technically a RJ-25, but it or an RJ-14 (6P4C) will do just fine. This project is a very easy build job, so let's do it. how T1 lines work. On old exchanges like this one (used in rural New South Wales, Australia), phone lines were carried by literal tip-and-ring connectors plugged into the switchboard to connect calls, which is where the name comes from. Telco guys call a combination of tip and ring a "pair." Each phone line uses one pair. Although it likely makes little difference for this application, there is a polarity to the connection which should be observed, i.e., tip is positive and ring is negative. The cable I used is a real USOC RJ-11C with a 6P2C connector and thus has only two wires for a single pair. The tip wire for this first pair on typical North American RJ-11 installations can be green, or white with a blue stripe (in other countries it may be any number of other colours); the ring wire can be red, blue, or blue with a white stripe. Thus, after stripping back the wires — sometimes easier said than done on a sticky old cable — connect ring to the phono jack's ground/sheath and tip to the phono jack's centre. Make it pretty and you're done. An important warning before we continue: from the telephone company side the line pair carries voltage used to power the phone and ringer, so never plug this cable into a wall jack — doing so could potentially send up to 48 volts to the computer, with likely undesirable and even fiery results. A cable like this should only ever be directly connected to another modem. The software part has to do with how data from the Commodore 64 is modulated to send to the other system's modem. For that, we turn to John's program, as he posted it (in separate versions for NTSC and PAL Commodores for reasons I'll explain as we analyse the disassembly). It was presented as a type-in program in BASIC, short enough to type in by hand, with an embedded machine language section loaded from DATA statements. Here's a couple videos showing what it looked like in practice. The modulated audio is played through the speaker, so don't have it up too high. so the KIM-1 could speak through a DECtalk, that the transmission of a byte or character of data is divided into more or less distinct phases. The default state is mark (one). At the beginning of transmission comes a start bit (always space, or zero), followed by the data (seven or eight bits). After the data comes an optional parity bit, then back to the stop bit for at least one and sometimes two or more bit times. The most common transmission type is 8N1, which is eight data bits, no parity bit, and one stop bit (i.e., characters must be separated by no less than one stop bit, though it can be more). Praat, we see a sine wave of varying wavelength. In the spectrogram at the bottom we can pick out two distinct frequencies being used to encode a character, as shown on the dark black band. This is the hallmark of audio frequency-shift keying (AFSK), or often just called FSK. For this spectrogram I've typed the letter "U" which in binary is 01010101. That's the "wiggle" in the middle. John's program sends 8-N-1, so since we know the byte is framed by stop bits, which are marks/ones, we can deduce the initial frequency is used to transmit a one. Serial communications send the bits in little endian order, i.e., from least significant to most significant, meaning the wiggle is actually the start bit (space/zero), followed by 10, 10, 10, 10, then a stop bit (mark/one) and finally the normal mark state between bytes, which in this plot is indistinguishable from the stop bit. Dr. Strangelove. It remained in operation well into the 1980s; even as just a giant coincidence there are many suspicious similarities between the concept and WarGames' WOPR. The 101 ran at 110 baud over regular telephone lines and became available for commercial sale in 1959. On the wire it uses separate sets of frequencies for each side of the conversation: 1070Hz and 1270Hz (space, mark) for the modem originating the call, and 2025Hz and 2225Hz (space, mark) for the modem answering the call. In 1962 AT&T introduced the Bell 103, which used the same frequencies but ran over twice as fast at 300 baud. It quickly became very popular and almost completely replaced the 101 in commercial use. Even after the 1976 Bell 202 introduced 1200 baud operation (with different frequencies and duplex modes), it remained compatible with the 103 in 300 baud mode, and virtually every third-party 300 baud modem was compatible as well (many were also compatible with ITU-T V.21, which uses the same basic communication scheme but different frequency sets). The Originate-Answer switch on 300 baud modems like the Commodore 1600 VICMODEM and Commodore 1660 "Modem/300" selects which two frequencies the modem will send bits with, using the other two frequencies for receiving. Since any 300bps modem can speak Bell 103, that's why John chose it, and since we're "responding" to the other side that "initiated" the "call" this code uses answerer frequencies. The software came in both NTSC and PAL versions because obviously something like this is highly timing-dependent, and PAL Commodore 64s run slightly slower (0.985250MHz) than NTSC systems (1.022730MHz). The variance is because each video standard uses a different master crystal from which all other clocks are obtained by dividing down, including the colourburst frequency needed for correct display, and also the clock speed of the CPU. This speed additionally affects the 6581 SID sound chip, since each of its three oscillators are incremented by the given audio value (0-65535) every clock cycle, so we need different values for the mark and space frequencies on PAL and NTSC systems. John's last known post in comp.sys.cbm, using slightly different processor speeds, explains the math (shown as written): Using this relationship, we can then solve for "word" to get the proper value for the SID frequency register based on the detected video standard. SID's three voices are thus able to generate tones up to ~3848Hz on PAL machines and ~3995Hz on NTSC machines, well in excess of the necessary range. Because SID generates audio asynchronously, we can just tell it to use infinite sustain (to infinitely prolong the note until we gate it off), play the mark frequency, and then leave the note playing while we go do something else, keeping the line open. Since the specification requires a sinusoidal wave, the code uses the SID's triangle waveform which is the closest approximation. The result is, in fact, the very tone you hear at the beginning of the videos. However, there's one other reason we need separate NTSC and PAL versions, and that's because of how John set up the baudrate. Here's how the BASIC loader starts (from the NTSC version): After reading the hex-encoded DATA statements into memory, at line 110 John's code starts initializing both the SID and the two CIA chips, though he primarily uses CIA #2. To determine bit times, rather than having the CPU manually count off a specific number of clock cycles, this code has the CIA do it. A critical point is that while the CIA chips can be set to issue IRQs or not, their interrupt control registers will still indicate when they would have fired one, even if that individual interrupt condition is technically disabled. John turns off all interrupts on both CIAs so they won't fire and upset system timing, including the usual Timer A IRQ on CIA #1 used for keyscan, then sets Timer A on CIA #2 to repeatedly count down $0d50 (3408) clock cycles. If we divide 1022730 by 3408, we get ... 300.09, almost exactly our baud rate. (It's okay to be a bit faster as long as you're never slower.) A smaller value is used for PAL systems. With the CIAs (and audio) set up, we then go into the mini-terminal, which is loaded into memory and started from the usual location for such routines at 49152 ($c000). We disassemble that next. John chose to call direct into the Kernal for these routines to short-circuit code he didn't need. With thousands of cycles available to send each single bit, the full-fat routines would have been fine, but why bother with work you don't need to do? After initializing the screen editor, the code waits for the next Timer A interval to fire and scans the keyboard manually (since the IRQ isn't running anymore), then fetches the next key, if there is one. Assuming it's not F1 (send a file) or F7 (quit the terminal), the code then goes on to send a character using this subroutine at $c027: Each access on the interrupt control register clears any conditions that were set. This apparent "double-wait" on entering the routine isn't an error: it ensures not only that everything's in a known state, but that also at least one stop bit's interval has elapsed between the prior character and this one. Once that has occurred, we clock out the start bit, then eight data bits least significant first, and finally leave back at the stop bit frequency. Each time, except for the very end, we wait for another trigger on CIA #2's ICR before we proceed. When F1 or F7 is pressed, the mini-terminal sets location $2 to non-zero or zero respectively (above, after the call at $c00f) and returns to BASIC. BASIC then turns back on the Timer A IRQ on CIA #1, and if $2 is non-zero, it proceeds to ask for a device number and filename. This is a fun routine on its own, but you've seen enough of the code to understand the basics of how it works, so let's get out the WorkSlate now and try it with a real device. For the Commodore side, we're going to use one of my portable SX-64 systems. A warning about the SX-64 specifically: never plug in a video cable — more specifically, never connect the audio output — with the computer's power on. Doing so runs you a decent chance of frying the SID, something I actually did many years ago and is a well-known problem. This goes likewise for connecting our mutant phone cable to the SX-64, since we necessarily have to use the computer's video port for the audio signal. The WorkSlate has a built-in terminal desk accessory which can be activated from the Phone menu and selecting Terminal. However, simply selecting the Terminal is not enough. The trick with the WorkSlate is to have the speakerphone line open (Phone, SpkPhone) first, and then try to answer with the Terminal. This is supported by the device; it assumes in this case that you've manually dialed a number somehow (say, from an attached phone handset) and the computer on the other end has answered. We already have the answer stop bit tone playing, so the WorkSlate's modem immediately hears it and tries to go on-line. ATX1D sets up a "blind dial" so that the 64's answer signal is also immediately recognized. The interesting part is comparing how the speakerphone operated between the three Workslates I now have. On the most recent one I acquired and on my "tester" unit that I soldered jumper probes to (both with serial numbers starting with CCA8415), I could hear the "call" and what the SX-64 was sending when the Workslate was in speakerphone mode, as expected. However, on my regular unit (a later machine with a CCA8417 serial number), I could hear both ends of the conversation through the SX-64's speaker, including the Workslate's dial tones and originate frequencies — and nothing on the Workslate's speaker. I'm not sure if this is due to different internal wiring, changes in the tape gate array or both. Again, this is a good reminder that the SID in the SX-64 is unusually vulnerable to stray voltages: if there were proper isolation I shouldn't have been able to hear incoming audio through the speaker output. In fairness, Commodore probably didn't think people would be wiring phone lines to SID audio either. But let's embroider the situation a little more. Some modems may listen for a dial tone first before they attempt to do anything, especially if you need to actually dial a phony (narf narf narf) telephone number, since they reasonably expect there's a real POTS "plain old telephone service" line on the other side. computer did. Programs like Common Sense could be provided a phone number and dial it by playing tones like music. (Interestingly, the VIC-20 does not seem to be capable of precise enough frequency control to generate DTMF; Commodore even warns against it in the Modem/300 manual.) Dialtones and other call-progress tones are often multi-frequency tones similar to DTMF, but they're specified separately by each region's telephone system. In the North American Bell System's Precise Tone Plan, dialtone is a combination of 350Hz and 440Hz at -13dBm, also played using a sine wave. If we use the formulas above and solve for the SID register values using those frequencies, these statements in BASIC will make a sufficient approximation of a dialtone on SID voices 1 and 2 (NTSC): smaller system, so let's make it a little friendlier. I removed the BASIC portion and wrote up a new menu system in pure assembly, incorporating and converting John's original code, and merging the PAL and NTSC versions together. It LOADs and RUNs like a BASIC program but is fully machine language. Ward Christensen, uses a fixed 128 data bytes per block and a simple checksum with known deficiencies, so John opted for the more complex version with a cyclic redundancy check to ensure errors could be promptly detected. Most terminal programs support this mode. We previously encountered a variant of Xmodem-CRC when we were figuring out how The Newsroom's Wire Service operated. From that article, the CRC-16-CCITT used in Xmodem-CRC is transmitted using this algorithm, rendered in K&R C: = 0) { crc = crc ^ (int)*ptr++ << 8; for (i = 0; i < 8; ++i) if (crc & 0x8000) crc = crc << 1 ^ 0x1021; else crc = crc << 1; } return (crc & 0xFFFF); } lda #$01 sta $96 ; number of current packet ; start sending the current Xmodem packet lc08a lda #$00 sta $02 lda #$01 jsr lc027 ; send Xmodem SOH $01 lda $96 jsr lc027 ; send packet number eor #$ff jsr lc027 ; send inverse of packet number ldy #$03 jsr $ffa5 ; Kernal acptr, read next byte from file sta $8b ; store in high byte of CRC jsr lc027 ; transmit it inc $02 ldx $90 ; EOF? beq lc0b3 lc0ad lda #$1a ; yes, handle final packet, store a ^Z sta $8c bne lc115 lc0b3 jsr $ffa5 ; read again sta $8c ; store in low byte of CRC jsr lc027 ; transmit again ldx $90 bne lc115 ; check EOF again lc0bf inc $02 big-endian, unlike the usual 6502 little-endian convention, and exploits the fact that most transmitted blocks will have at least two data bytes. The routine starts each block by clearing the count, then with the modulation routine at $c027 above it sends the standard Xmodem start-of-header (^A) character, the packet number and inverse of packet number, then (checking for EOF each time) reads two characters into the high byte and low byte of the running CRC-16 and transmits them. If the status word at $90 shows an EOF, this condition remains until the file is closed. For each byte after that to complete the block, another one is read and stored into $8d, then shifted into $8b and $8c: When a high bit is rolled out of the rolling CRC-16, this is detected as carry being set (no need for a bitmask) and the rolling CRC-16 bytes are exclusive-ORed with the required polynomial value ($1021, 4129). This is a very efficient translation of the algorithm. The code then continues to run to complete the block of 128 bytes. After the last byte is read from the file and shifted in, we need to incorporate three zero bytes into the CRC-16 to represent the header we sent. We then send that value and "wait" to pretend it worked, then go back for the next block. The weird delay routine allowed John to fit the entire loop into the maximum 7-bit displacement of a relative branch instruction. In fact, when I added code to flash the border on each block, I had to insert an absolute jump instead since those three extra bytes upset the apple cart. At the very end of the file, any block in progress is padded with EOT (^Z), and then Xmodem EOF (^D) is sent to terminate the transmission: Note that the branch at $c11b will always be taken since we just loaded a non-zero immediate into the accumulator. Again, another nice way of increasing code density and reducing type-in size. Should the file have ended in the first two bytes used to prime the CRC-16, John's code just stuffs ^Zs into it manually. John's original post containing the type-in versions (you can cut and paste these into VICE, if you like), plus the assembly source for this unified version and a pre-built binary, on Github. As John never asserted copyright to his programs and explicitly intended them to be freely distributable so that others could use and learn from them, I've placed this version into the public domain (to the extent available in your jurisdiction). You can assemble it using xa65. John was a good guy with a clever programming style and it was nice to see his code running again (and working, though that was a given). Plus, this is a great use for a Commodore to support your other systems, and a roadmap for doing something similar on other machines with sufficiently capable sound hardware. In future articles I think we'll explore a few other things he wrote, including that audio digitizer. I think he would have enjoyed it.

Ask any Atari Stacy owner how to open an Atari Stacy and the answer is always "never, if you can avoid it." So I'll just lead with this spoiler image after the refurb to prove this particular escapade didn't completely end in tragedy: see the much lighter and streamlined STBook in the flesh, let alone own one. If you really want a portable all-in-one Atari ST system, the Stacy is likely the best you're gonna do. And we're going to make it worse, because this is the lowest-binned Stacy with the base 1MB of memory. I want to put the full 4MB the hardware supports in it to expand its operating system choices. It turns out that's much harder to do than I ever expected, making repairing its bad left mouse button while we're in there almost incidental — let's just say the process eventually involved cutting sheet metal. I'm not entirely happy with the end result but it's got 4MB, it's back together and it boots. Grit your teeth while we do a post-mortem on this really rough Refurb Weekend. it lacks a blitter, but does have an expansion slot electrically compatible with the Mega), it sports a backlit monochrome LCD, keyboard, trackball in lieu of the standard ST mouse, and a full assortment of ST ports including built-in MIDI. A floppy drive came standard; a second floppy or a 20 or 40MB internal SCSI hard disk was optional. This was Jack Tramiel-era Atari and the promises of a portable ST system were nearly as old as the ST itself. For a couple years those promises largely came to naught until Atari management noticed how popular the on-board MIDI was with musicians and music studios, who started to make requests for a transportable system that could be used on the road. These requests became voluminous enough for Tramiel's son and Atari president Sam Tramiel to greenlight work on a portable ST. In late 1988 Atari demonstrated a foam mockup of a concept design by Ira Velinsky to a small group of insiders and journalists, where it was well-received. By keeping its internals and chipset roughly the same as shipping ST machines, the concept design was able to quickly grow into a functional prototype for Atari World and COMDEX in March 1989. Atari announced the baseline 1MB Stacy with floppy disk would start at $1495 (about $3800 in 2024 dollars), once again beating its other 68000-based competitors to the punch as Apple hadn't themselves made a portable Macintosh yet, and Commodore never delivered a portable Amiga. Sam Tramiel was buoyed by the response, saying people went "crazy" for the Stacy prototype, and vowed that up to 35,000 a month could be made to sate demand. any configuration. FCC Part 15 certification for the hard disk-equipped 2MB Stacy2 and 4MB Stacy4 was delayed until December 1989 and at first only as Class A, officially limiting it to commercial use, while the lowest-end 1MB floppy-only Stacy didn't obtain clearance until the following year. We'll see at least one internal consequence of this shortly (I did mention sheet metal). The delays also stalled out the system's introduction in Europe and despite Tramiel's avowed industrial capacity relatively few Stacys were ultimately sold. Based on extant serial numbers, the total number is likely no more than a few thousand before Atari cancelled it in 1991, though that's greater than the successor ST Book which probably existed in just a thousand or so units tops. The Stacy's failure to meet its technical goals (particularly with respect to size and power use) was what likely led to the ST Book's development. Unfortunately, although a significant improvement on the Stacy, the ST's decline in the market made sustaining the ST Book infeasible for Atari, and it was cancelled along with the entirety of Atari's personal computer line in 1993. third party upgrade provided an installable internal battery option which could last up to two hours. ACSI ("Atari Computer Systems Interface") predates SCSI-1's standardization in 1986 but is still quite similar, using a smaller 19-pin port, a related but incompatible protocol, and a fixed bus relationship where the computer is always in control. It is nevertheless enough like SCSI that many SCSI devices can be interfaced to it — we'll come back to this too. The rear ports should be covered by a door, but it's missing from this system. is present that the expansion slot never got used by its prior owner(s), and I don't have anything to connect to it either. carefully through their hole in the bottom case so you can lift up the top case completely. peripherals for the Convergent WorkSlate (the WorkSlate itself uses a Hitachi 6303). This serves as the keyboard, mouse/trackball and joystick controller with its own 4K internal ROM and 128 bytes of internal RAM. Counting the RAM, though, we don't have 4MB on this side. Where's the rest of it? other side, covered by tape. Why is it taped? So it doesn't short against anything! Remember, this is exactly how Atari shipped it! The keyboard connector is here as well. This board is quite critical. Without it, the system has no RAM, no ROM and, almost trivially by comparison, no keyboard, trackball, mouse or joysticks. If it's not connected firmly, you'll get a blank screen. requiring desoldering of the 68HC000. This would have been a rather complex upgrade to install. not. What's depicted here is in fact a consolidation of multiple false starts and a whole lot of screaming. The first part was to put the metal shield back on and bend the tabs back to hold it in position. While doing so, be careful with the display wires to get them back into their little canal because they can literally short and spark. I don't know how this is possible but they do! You can also get the display cabling messed up enough that the Stacy will continuously beep at you when you turn it on. The only good way I found to avoid this was to pull as much play in the display wiring into the top case as possible so that the wires don't bunch up in the bottom case. also affect its connection with the logic board. The middle one seems to be the most involved. All of this suggests Atari never meant a 1MB Stacy to be upgraded with this particular card. Hall SC-VGA-2 scan converter to turn the ST's 71.2Hz high resolution display into the 60Hz my VGA box can capture. This stack doesn't get a pixel-perfect grab but the budget isn't there for the super duper OSSC right now, so you'll just have to deal. HDDRIVER that was already on the SD card. extensible control panel, much like Macs use CDEVs, uses CPXes (Control Panel Extensions). Show System. This was what I was using to display the memory configuration before. And, now adjusted, we still have 4MB of memory to my great relief with the computer back in one uneasy piece. I'm not 100% happy with the end result but the trackball button works better and our memory has quadrupled, at least when Stacy is in a good mood. Like I say, I can only conclude that the 1MB Stacy was never meant to be upgraded in this fashion. One of the third-party RAM cards might have worked, but I have no idea where I can find one. Regardless, based on the amount of apoplexy and late-night screaming that Stacy caused over the past couple months' weekends, my wife has told me in no uncertain terms that if I'm ever going to crack this laptop open again, I need to have a good long talk with her about it first. I've decided I'm okay with that.

A merry Christmas and happy holidays from the Southern Hemisphere, where it's my year to be with my wife's family in regional New South Wales, Australia. A friend of the family had an "old Commodore" in their house and asked if I wanted it. Stupid question, yeah? The Australian Commodore and Amiga Review published from 1983 to 1996. The issues here date from 4/89, 5/89, 6/89, 10/89, 11/89, 12/89, 2/90, 3/90, 4/90, 5/90, 6/90, 8/90, 9/90, and the 1990 Annual with an extensive list of Australian BBSes, software packages and user groups. By this time the Commodore 8-bits were past their prime compared to their 16-bit Amiga brethren, but there was still some decent coverage of the 64 and 128 in this set. Unlike most American Commodore magazines, there was little type-in content, at least in these particular issues; the ones here concentrate more on reviews and product announcements with sidecar tips and tricks. The other bit of literature in the box was a 1987-88 Dick Smith Electronics catalogue. If you're on one of the other continents, DSE was approximately Australia's equivalent of Radio Shack and at its peak sold a similar range of rebadged products and electronics. It is likewise no more (shut down in 2016), though its name lives on as a zombie Kogan brand; today its closest domestic equivalent would probably be Jaycar. Type-right and Whiz Kid. rebadged them also). The PC-1360 and PC-1401 were more advanced than Tandy's Sharp rebadges, but they did include the lowend PC-1246 (Tandy PC-8, which avoided being the worst Tandy Pocket Computer ever because of the execrable PC-7) and even lower-end PC-1100, a flip-face unit that had a narrower but 2-row display and basic organizer functions, and sold for more likely because of it. DSE also sold the excellent Sharp CE-126P, a lovely device that combines a thermal printer and cassette interface yet does not rely on the sure-to-fail NiCad batteries other such peripherals did to their detriment. Tandy never sold this unit, rebadged or otherwise. Unlike Tandy, though, DSE simply chose to rebadge other PC systems instead of creating its own like the Tandy 1000 series. At least initially their PCs came from a Taiwanese company called Multitech, which started in 1979 selling their Z80-based "MicroProfessor" MPF-I SBC and later two Apple II clones, the MPF-II and MPF-III. These clones were especially notable for their onboard Chinese language support, drawing characters in high-resolution graphics and as such completely omitting the Apple II's text mode. Subsequently Multitech started producing PC clones in 1984 with the MPF-PC-XT, and over several years served as a PC OEM for many diverse companies such as Texas Instruments. The clones shown here (the 8088-based PC500 and PC700, and the AT-class 80286 PC900) may have been some of the last to bear the Multitech name because after failing to land a large contract with a German firm, company head Stan Shih decided he'd had enough and retooled the company to start selling their own PCs under their own brand in 1987. He chose a new name for the company, too: Acer. But just like the Tandy Color Computers, Dick Smith was still selling their range of 8-bit home computers as well in those days. The last of this line was the Z80-based VZ300, yet another VTech rebadge, and had a whole assortment of peripherals including memory expansion, floppy disk drive (three times the cost of the computer), and interfaces for the joysticks, cassette, printer and disk drive — which was sold separately from the disk drive! I have a VZ300 and some upgrades I need to finish building which will be in a future article. READY. prompt because the computer can't boot from its internal disk drive. The drive activity light never turns on and the drive motor never turns off. inside a Commodore 128DCR for a prior refurb weekend and the disassembly here is the same. With a little bit of care we can avoid tearing the intact warranty sticker here too. To be continued after a trip to Jaycar and some mail orders. A very happy holiday and a merry Christmas to those of you who celebrate it.

I still have my literal first home computer (the Tomy Tutor), and it so happens I also have my literal first game console: the Tandyvision One, Tandy Radio Shack's label variant of the Mattel Intellivision Master Component. The Mattel Intellivision proper originally hails from 1978 and is notable for remaining supported and sold in three different decades (until 1990). Its development is explained well in many places, including by the Blue Sky Rangers themselves, so I'll talk here mostly about the variants. Most of them looked like (and were) ordinary Master Components with different trim; for example, early units were manufactured by GTE Sylvania and GTE had a label variant of their own using silver inlays instead of Mattel standard gold, sold until around 1980. Probably the most "extreme" was the 1981 Sears Super Video Arcade, which had a rather different beige top case and detachable controllers, but was nevertheless manufactured by Mattel under contract using the same basic hardware and slightly different EXEC ROMs. The Super Video Arcade was especially notable because the prior Sears Video Arcade was an Atari 2600 VCS clone. Other variants from around this time include the 1982 Bandai Intellivision, also otherwise identical to a standard Master Component except for Japanese television channel tuning, and the Digiplay Intellivision (also sold as Digimed), which was manufactured by a Sharp subsidiary in Brazil due to that country's then-protectionist policy against imported electronics. Tandy's particular spin was also later in the Inty's lifecycle. In 1981 Mattel Electronics moved manufacturing to its own facilities in Hong Kong; by 1982 they were working on the "Big Mac" project that became the 1983 Intellivision II, a smaller and cheaper cost-reduced version. Tandy, always willing to label engineer first and innovate second (sometimes third, or tenth), made a deal with Mattel as OEM to rebadge some of the remaining O.G. Master Components and sell them in Radio Shack stores. the unreleased 1989 Tutorvision. INTV shifted to NES and Sega development as Inty sales dropped, but their licensing arrangements required them to discontinue the Intellivision in 1990 and the company went bankrupt in 1991. Near as I can determine, only Digiplay sold a non-Mattel version of the Intellivision II (in Brazil), and only Mattel ever offered the Entertainment Computer System. prior to the robbery) it suddenly decided to start working again. In fact, it works perfectly now, just as it used to. I'm not sure why. Anyway, let's get started. There are six Phillips-head screws in the bottom case in the large recessed openings. Remove those and turn it over. off switch (i.e., the button switch is normally closed and pressing it opens the circuit). This particular button was very handy because it has little holes that fit the wire, so it was just a matter of threading them through, making sure the two sides were separated, and crimping it down. No soldering needed. This is the basic notion. The US FCC was very strict about shielding and radio emissions in 1978, so on the original Master Component everything apart from the power circuit lives in a shielded submodule called the logic board assembly. (This was not the case for the Intellivision II, which further helped it to be cheaper.) This submodule is in fact soldered shut for even less RF leakage, with just a few holes for the channel selector, RF out, screw mounts and reset button. Since this mod unavoidably involves some permanent modification to the logic board, even of a minor sort, I decided to do it on a separate known good logic board assembly I had on the shelf from another machine (another Tandyvision, as it happens). That way if I screwed it up, at least I wasn't doing it to the original assembly from my real machine. Plus, I still don't know why the STIC chip in my original console decided to pull a Lazarus, while this replacement one was unlikely to require service anytime soon. carefully unplug the controllers (note their orientation — there are a lot of fine wires!) and then lift out the entire submodule from the bottom case. Fortunately, the age of the solder even on this obviously newer unit is such that a good tug with a metal spatula will break most of the joins cold (I only had to heat up a couple). The "top" we are opening here is actually the bottom, so turn it over and remove the metal shield when the joins are open. Intellivision reimplementation using an NES-on-a-chip. This grab was done with the Sylvie, but the Sylvie has an RF modulator that's nearly as good as this one. The Inogeni VGA box grabbed it while connected to an LCDT600 to display the RF signal and I'm not sure if that's why the top of the screen has that red shift, though the colours are otherwise nice and there is relatively little ghosting. not to do was replace the discs on the controllers (the pads underneath them are still in good nick). Yes, the top layer of the disc is worn down in places, but it's worn because we played it. And now that Dad's no longer with us, touching that pad still feels a little like touching him. So I decided to keep it that way, just like he left it. You know, in case he ever drops by for a game of Biplanes or something. I'll even let him win.

A periodic fascination on this blog is figuring out better ways to get better screenshots of our classic systems, which often hail from the Wild Wild West/East in terms of video standards (read all entries in this series). Naturally the best way is a bitwise direct grab of the framebuffer, but that's only possible if there's sufficient operating system support. This support is obviously absent for things like boot messages (especially important when investigating NetWare on the Power Mac 6100), so we need to figure out a way to capture that information. My capture box of choice is currently an Inogeni VGA2USB3, which is small, self-contained, USB-powered, highly compatible and makes high quality grabs of anything you can wire into composite or a VGA HD-15 connector up to 1080p, but is limited to 60Hz refresh rates. Various solutions like the OSSC exist, but these are more oriented to arcades and consoles rather than (our primary interest) workstations. While you might be able to trick the hardware into emitting a compatible signal, that's not good enough or even possible with several of my machines. Previously my problem child was astro, my SAIC Galaxy 1100, a modified PA-RISC HP 9000/712 crammed into a MIL-SPEC portable case with a fabulous built-in flat panel. These machines ran HP-UX 10.10 in their original heyday, but this particular system runs NeXTSTEP 3.3 for PA-RISC during the brief period of time NeXT supported the architecture and was a big hit at the Vintage Computer Festival West a few years ago. Its flat panel runs at an odd 62Hz and the external VGA port only generates a 60Hz signal for 640x480 (all other resolutions use different refresh rates), which is hopeless for running NeXTSTEP. However, now I have a new candidate I'd like to get some grabs off: a particularly problematic member of the Atari ST family which has been the subject of a long-running and highly frustrating extended Refurb Weekend. You'll get to meet this bad girl soon enough. The standard ST high resolution mode is 640x400 — at 71.2Hz. I can get a picture from it with my trusty NEC flat panel, but not with the Inogeni. The usual solution to this is a scan converter, but those can be expensive and inconvenient. Here's one I picked up used on eBay for $2. Yes, really. It cost more to ship it. an HDMI version with additional resolutions ... for around US$500. However, this or the slightly newer SC-VGA-2A and SC-VGA-2B are all relatively common devices and found substantially cheaper used. Let's try it out and show some sample output, including those delicious NeXTSTEP system messages and some ST grabs. The reason I got the SC-VGA-2 so cheap, and I actually ordered two, was it was sold untested (no power supply). It looked like a robust device in a metal enclosure, so I figured it probably did work, but an extra $2 for a spare to hedge my bets seemed good insurance. Both of them do in fact work. Data General/One and the ULI successor to the AtariLab). Technically this is an 8052-type microcontroller with 1K of on-chip RAM and 32K of on-chip flash for program memory, though it must also have some means of storing settings internally since there are no other obvious sources of NVRAM. This particular part is rated up to 40MHz, but the crystal next to it is 11.052MHz, which still sounds pretty quick until you recall MCS-51 chips take about 12 cycles per instruction (compare to a 6502 that ranges from two to six). It seems to drive the unknown video ASIC using its on-board serial port which was not an unusual mechanism for the time; see, for example, the Focus FS401LF. The other, smaller chip near the input port is an MStar MST9883, which is an overgrown A/D converter sampling analogue pixel data and emitting a serial stream of digital RGB and clock for the video ASIC. It can sample up to 140MHz and doesn't appear to use the 14.31818MHz crystal next to it, which seems to be used by the ASIC. I don't think Hall designed this board; it seems to be Taiwanese based on the board markings, chip manufacturers and some Engrish in the Hall manual which was clearly from an image grab of something else. Other vendors may produce an equivalent version of this device, so if you know of one, post it in the comments. path console graphics (graphics1 is the "alternate" on-board flat panel) and reset. monitor 2). Despite being listed as supported, this caused a black screen, so I (blindly) reset the Galaxy and switched back to mode 5, and then tried mode 3. C. I don't know what this means and Hall doesn't mention it as a separate SKU. The input is "XGA-70" and the output is "XGA-60." to 1280x1024 60Hz. I should note that I don't know if the Galaxy video modes are standard, so I can't say if this is the Hall box's fault or not. -v for a verbose boot. OmniWeb 2.7 running Crypto Ancienne for TLS 1.3. But let's compare that with a similar Grab shot: 13-pin rear video port. Remember, this was Tramiel's Atari, so we got things like 13-pin video with wacky connectors and ACSI instead of SCSI. The converter is passive, so there is no scan conversion. LCDT600 I use for PAL composite capture, it requires an intermediary step with its own power supply and introduces a further amount of lag into the system. It also doesn't seem to display all the modes it advertises, though I have not yet determined who's really at fault for that. But it's a true scan converter that isn't very large, really does work, and seems reliable and well-built. I certainly got my $2 worth, by golly.