Jump to content
IGNORED

Intellivision Keyboard Component pics


y-bot

Recommended Posts

With that track order, the two data tracks will overwrite eachother when flipped. Oh well, it's not like we had a shortage of basic storage space. And I'm pretty sure basic can't make use of analog voice.

 

I have 4 blank tapes. Part of me wants to see RW data and audio and recorded on some of them. Then again, I am worried that any audio will just be little Timmy recording himself farting. :ponder:

Link to comment
Share on other sites

With that track order, the two data tracks will overwrite eachother when flipped. Oh well, it's not like we had a shortage of basic storage space. And I'm pretty sure basic can't make use of analog voice.

 

Yeah, that's what I thought originally -- then I saw Joe's list of tracks and assumed that was the correct order. I guess we don't know?

 

-dZ.

Link to comment
Share on other sites

  • 4 months later...

Hey all,

 

It's been a while, so here is a bit of an update. Back in September when we did the development kit video Ron and I also made some further progress with his K/C tape drive. We got it to the point that we could intermittently load and save BASIC programs, but it is far from reliable. Here is a quick video showing a save, followed by a failed attempt to load the program back:

 

 

Small programs would load maybe one time in five, so it did not seem worth posting the video at the time.

 

Since then we have been a bit distracted doing cool things with Ron The Cat's PlayCable, however, we anticipate getting back to the K/C in the coming weeks. We are hoping that the problem is just a motor speed thing and a bit of lubrication and adjustment will fix it. We have bought an tape with a 3KHz signal on it to help with setting up the mechanism. However, as this is a regular tape, not one with IR clear leaders, the K/C will not play it. So we also wrote a little bit of software to directly control the tape drive from the K/C keyboard:

 

post-46336-0-88911100-1547804072.png

 

This completely bypasses the EXEC and all the clever Mattel stuff and just bit bangs the memory addresses that contain the tape status and control registers, as described on page 27 of this Papa Intellivision document:

 

post-46336-0-74258000-1547804478.jpg

 

The result is that (sometimes) Mimi speaks :D

 

 

(I'm not sure if the response you can hear to "Oui, j'ai faim", is Ron getting in a sneeky bit of French practice or a recording of the original owner from 1980, I'll let Ron clarify that ;)). Unfortunately, other times the lesson does degenerate into "The Chipmonks Teach French" because the pinch roller is not pressing against the capstan hard enough and the tape is pulled through too quickly:

 

 

"Houston, nous avons un problème...", but lets cling to the positive. Sometimes Mimi does actually speak!

 

 

Cheers

 

decle

 

  • Like 5
Link to comment
Share on other sites

Interesting stuff! To me, the Keyboard Component represented the "futuristic world of jetpacks and flying cars" back in the very early 1980s, and it is fascinating to see it slowly come to life and realize its potential.

 

By the way, how do you intend to use the 3KHz tape to diagnose the tape transport? Is it a matter of running the mechanism and then analysing the wobble on the output?

 

Keep up the good work! Let us know of any progress.

 

-dZ.

Link to comment
Share on other sites

If I recall correctly, the tape drive brake pads had to be replaced. Is that correct.

 

Tape seek works, so the read head must be working. Strange plod reading doesn't work reliably. Maybe it's because the pinch roller isn't controlling the speed correctly.

 

Why did you have to pre-rewind the tape before psav; because it looks like automatic rewind does work. Great to see these progress updates.

Edited by mr_me
  • Like 1
Link to comment
Share on other sites

Mimi is now on playback sounding her normal sexy self when I use the play command Decle provided for me to play the tape deck manually .

I took the cover off the tape deck to make sure the pinch roller is connecting and it plays back fine I think. Sometimes it doesn't connect.

We still need to test it with diagnostic equipment but sounds like what we got off my other tape cassette when recording the voices and data to a wav file earlier last year.

 

Tried to load the Conversational French tape (Tape 2 which is all i have) and it correctly rewinds to the beginning , then goes a little bit forward to find the load instructions, plays for just a bit to get them but then I just get "loading" on the screen forever with no errors or anything. We are using a modified USA MC with the KC but modified to go to HDMI - cannot imagine this is having anything to do with it.

 

Would be nice if we could just cheat and inject the code it expects bypassing the tape drive and see if a screen loads.

 

The brake pads were replaced , seem to work fine but maybe not stopping the tape at the exact place it needs to be by a very small amount ?

 

 

 

Sounds like we have nearly a working tape drive but as yet no cigar ……..just imagined my avatar with a cigar out of the mouth ….

Edited by Ron The Cat
  • Like 1
Link to comment
Share on other sites

Not sure what's suppose to happen with only tape two. The main index is on tape one and you can select the lessons on tape two from that index which I assume prompts you for tape two. Maybe both tapes have the same index program. Try typing R for resume rather than T. What happens when you put in a basic tape and type T?

Edited by mr_me
  • Like 1
Link to comment
Share on other sites

Ah ... classic RTFM .... seems French is reliant on having tape 1 (we only have tape 2) loaded first as you choose your name from that and its stored. Also the master index..duh

 

Will have to wait 5 years now to see if can get a complete conversation French on ebay. Having the tape with a voice on it has been helpful just to see if the deck is reading stuff correctly and in the ballpark for speed and understanding how data and audio is organised.

 

Think for now we will have to concentrate on getting the basic tapes saving and loading consistently for the purposes of getting the tape drive back into action.

 

Can't really grumble , Decle has done an stellar job in 2018 recreating the development kit for Ron's KC and getting my Playcable to come alive again.

Edited by Ron The Cat
Link to comment
Share on other sites

So wait ... is it because it didn't load the master index that it just stalls when loading, waiting for something that will never happen? I can see how that could happen, but I would imagine that if there is a specific dependency on the order of the tapes, that measures would have been put in place for this. Like when an old C=64 game asks for "disk 3 of 4" and you insert disk 1 instead: it should detect this, no?

 

-dZ.

  • Like 1
Link to comment
Share on other sites

So wait ... is it because it didn't load the master index that it just stalls when loading, waiting for something that will never happen? I can see how that could happen, but I would imagine that if there is a specific dependency on the order of the tapes, that measures would have been put in place for this. Like when an old C=64 game asks for "disk 3 of 4" and you insert disk 1 instead: it should detect this, no?

 

-dZ.

 

The index showing lessons III, IV and V are on cassette 2. You need to have cassette 1 to have loaded the full index for both tapes 1 & 2 but also have entered the name you are doing the lesson for or chose a previously entered one.

There seems to be no erroring checking for this if cassette 2 is inserted and you hit "tape", it tries to load code that just is not there for the menu. You need to load tape 1 for the menu and then if prompts you to insert the other tape when you have lessons on the index that are on tape 2. The tapes are not self contained as we thought and we only have cassette 2 :(

 

In some ways this is good news , it explains why our French was stuck on loading forever when we hit tape. Chances are it might well load French or Jack succesfully now.

 

We have Jack but it is in shrink wrap

Edited by Ron The Cat
Link to comment
Share on other sites

 

The index showing lessons III, IV and V are on cassette 2. You need to have cassette 1 to have loaded the full index for both tapes 1 & 2 but also have entered the name you are doing the lesson for or chose a previously entered one.

There seems to be no erroring checking for this if cassette 2 is inserted and you hit "tape", it tries to load code that just is not there for the menu. You need to load tape 1 for the menu and then if prompts you to insert the other tape when you have lessons on the index that are on tape 2. The tapes are not self contained as we thought and we only have cassette 2 :(

 

In some ways this is good news , it explains why our French was stuck on loading forever when we hit tape. Chances are it might well load French or Jack succesfully now.

 

We have Jack but it is in shrink wrap

 

Wow, this seems like such a strange oversight to not include error checking for the order of the tapes -- especially when you consider the complexity of the entire computer-controlled system, where it seems they thought of most other cases. :o

 

Oh well, good to know. Good luck!

 

-dZ.

Link to comment
Share on other sites

From decle's post, the drive is not reading reliably. I'm not sure we know what's suppose to happen with tape 2 only. Maybe the same thing as putting a basic tape and executing T, i.e. it has no loadable "tape" program. Or maybe it has one but it's failing to read it. There should be a way to make your own tapes from the copies Frank made, one day.

 

Edit:

Can you not hear the speech by playing the tape in a standard audio tape player?

Edited by mr_me
Link to comment
Share on other sites

  • 2 weeks later...

Hi everyone,

 

Another small update on the K/C tape drive (apologies for the sound at the start):

 

 

As you can see following a bit of lubrication we have BASIC programs loading and saving correctly and pre-recorded audio also works as expected (if a little noisily). Although we recorded Mimi talking last year using a regular tape machine, it is still nice to hear her talking through the K/C. Small steps. :thumbsup:

 

The next thing is to investigate Conversational French tape B to try to understand whether what we see is expected. I find it a little surprising that there is no error message or suggestion to load tape A. Not very Mattel. :ponder:

 

Things not mentioned in the video that probably should have been...

 

@Lathe26 - unfortunately BASIC does not permit recording of audio, so I don't think you will hear Timmy farting, at least not on a tape that can still be used by K/C BASIC. However, it is worth playing tapes like Conversational French to catch 35 year old language practice.

 

@mr_me - We had to rewind the tape in the previous video because it seemed to be the only way to get BASIC programs to load. As you can see it didn't really work and with a bit of lubrication it is no longer necessary :)

 

@DZ-Jay - We checked the speed of the motor using a 3KHz tone recorded on a regular tape. We can use the tape diagnostic program seen in the video to play any regular tape. The K/C just can't detect the start or end of the tape. We found the tape speed to be very close (the 3KHz tone was measured to be 2.992KHz on R17 of the tape analogue board) using a digital oscilloscope. Ron's Pico scope will provide min / max / average and standard deviation frequency measurements. Perhaps not as good as a proper wow and flutter meter, but good enough. We did not bother trying to tinker, given the mean error was less than 0.3%.

 

The ping-pong heard after the BASIC program loads comes from Ron's laptop, not the K/C. The squeal you can hear whilst fast forwarding to Mimi talking is a constant tone on the audio track, not program data. We can't directly hear the program on data track (although it may well be contributing to the noise heard on the audio).

 

We removed the plastic tape door to give easier access to the mechanism and a better view.

 

And for the two people who are interested, BASIC performance is confirmed at 98 seconds for David Ahl's test program using # to evaluate powers.

 

 

 

Cheers

 

decle

Edited by decle
  • Like 4
Link to comment
Share on other sites

Great work! One step at a time.

 

 

The next thing is to investigate Conversational French tape B to try to understand whether what we see is expected. I find it a little surprising that there is no error message or suggestion to load tape A. Not very Mattel.

 

This is the same thing that I thought. Such a complicated electro-mechanical device, with so many features and fail-safe guards, but it won't alert you of something dead-stupid like putting the wrong tape in first. It doesn't sound like David Chandler's work.

 

Anyway, great job. I have one question. On your "debug program" screen, the first line on the left column ("4000 - Data"), the "F" in "F3" seems to flicker when the camera is facing it. Is this perhaps a video recording artefact or something related to the device's video processing? It seems very localized to the single background card where the "F" is, even as the camera moves around.

 

It reminds me of similar video corruption I would get on old Commodore 64s when the VIC-II was going bad.

 

-dZ.

Link to comment
Share on other sites

  • 1 year later...

BIG news, we have gotten a commercial tape working on Ron's K/C!  We can now have hours of fun with Crosswords 3.

 

 

It's still flakey, and won't play any of the cool tapes like Jack LaLanne, so I'm still getting fatter in lockdown 2.0.  But this is significant progress!

 

For the record, my wife continued to battle the recalcitrant spacebar and did finish puzzle 2:

 

image.thumb.png.3516eccc210e73b1382869ccd0d0b93a.png

 

Edited by decle
  • Like 15
Link to comment
Share on other sites

Most of them worked back in the early 1980s.  Many of the returns were likely due to user error.  The recall was due to Mattel cancelling the product in order to absolve themselves of having to support the computer with more software.  It was cancelled because they couldn't get manufacturing costs down and the product could never be competitive.  Since then then the rubber belts and brakes in the tape drives have deteriorated, so working units are rare. The original cassette tapes, now close to forty years old, are also deteriorating.

  • Like 2
Link to comment
Share on other sites

  • 2 years later...

I induced someone who worked with Chandler back in the day to review this forum with me. I've made some comments you may find helpful. Please allow for the fact that these comments relate to matters that occurred forty years ago and were made without reference to notes. There may be some inconsistencies due to memories returning as they were being refreshed. Also be hyper-aware that I may have garbled some of the information in translation.

I'm starting here because this is the first thread we looked at.

On 12/6/2017 at 2:57 PM, decle said:

The two white strips are small grounding fences designed to reduce electrical interference between the 3 sections of the board

Nice guess! But they're really laminated power bus bars with integrated bypass capacitance.

image.png.ca177d5b9d7634698589bc22a80865e4.png
On 12/6/2017 at 2:57 PM, decle said:

Secondly, the 4K of CP-1610 ROMs are split into 3 chips, a single 2Kx10 RO-3-9502 (big 40pin DIP) and two 2kx8 9316Bs (two wider 28pin DIPs). I'm not sure of the reason for this split...

The 9502 was the most convenient way to get the latched CP-1600 address lines. It wasn't a vendor issue: all ROM devices were supplied by GI.

On 12/6/2017 at 2:57 PM, decle said:

page 0 acts a bit like an extended register set...

The 6502 materials make this claim, but it's pure Chuck Peddle marketing hype. The 6502's zero page memory is no more an extended register set than is the entire 64K memory space of the PDP-11: both are directly accessible in two memory cycles beyond the op code fetch. It is more practical to think of 6502 accesses to zpage as "normal" and accesses to the rest of memory, which require a third memory cycle, as "extended." Actual 6502 programs never came close to needing 256 variables, so zpage addressing was the norm--extended addressing was only needed to access device registers, arrays and character strings.

On 12/6/2017 at 2:57 PM, decle said:

Page 1 is typically used for the processor stack.

It is a mistake to think of the entirety of a 6502's page 1 memory as being reserved for the processor stack. Typical 6502 programs use less than 40 bytes of stack. A very large program, with ten levels of subroutines (a huge number), each pushing six bytes of data (much more than typical), would only require 80 bytes of stack. Adding two levels of interrupt would require another 12, bringing the total to 96 bytes. The remaining page 1 memory (164 bytes in this example) would be fair game for other uses.

The fact that the stack must be located in page 1 is a limitation, not a feature. Chuck Peddle saved a bunch of transistors on the 6502 (3510 transistors vs. 4100 on the 6800 he had worked on previously while at Motorola) by doing such things as only implementing an 8-bit stack pointer and using an implied 0x01 for the high byte of the address. As a result, your typical 40-byte long stack must be located somewhere in page 1, which is a limitation.

It is not unusual for 6502 designs to have a total of 256 or fewer bytes of RAM, doubly addressed to appear in both page 0 and page 1. (By 'double addressing' I mean that accessing, say, location 0x0012 is the same as accessing location 0x0112. You can double address a device by simply not connecting all of the address pins. In this example you would leave A8 unconnected.) For example, the Atari 2600 has only 128 bytes of RAM, doubly addressed so that it appears at both 0x080-0x00FF and 0x0180-0x1FF. (It actually appears in more places than that, but that's beyond the scope of this discussion). This means that the same block of physical RAM could be used for either zpage or stack.

The point of all the above verbiage is that in the early 1980's memory was far too valuable to dedicate a full 512 bytes to the 6502 just because it had special zpage and page 1 addressing modes. It is hard today to appreciate how dear memory was. You may find this perspective useful as your archaeological digging proceeds.

On 12/6/2017 at 2:57 PM, decle said:

The weird thing is that both these pages are implmented using the 16K shared memory.

Nothing weird about it. Since all of a 'huge' 16K memory was shared, why would one add chips and complexity to create a small piece of special memory at a much higher cost per bit? Two additional 2114 devices would have yielded only 256 x 8 of additional RAM; four would have been required to create dedicated pages for each of zpage and stack. Adding such dedicated pages would also have increased the fragmentation of the address space. Furthermore, if more memory chips were to be added it would far better to use them to increase the DRAM width to 16 (APh strongly recommended doing that, but Mattel wouldn't go for the increased cost of the 6 extra chips).

On 12/6/2017 at 2:57 PM, decle said:

The CP-1610 probably should not tinker with either as it could potentially cause problems for the 6502.

You've surely heard tales of the lengths programmers went through to save ROM decles; that miserliness applied to RAM too. It would been unconscionably wasteful to impede the 1600 from using zpage or page 1 RAM not used by the 6502. Programmers had memory maps that showed exactly which locations were claimed by either CPU for every application. Furthermore, the two processors used zpage locations to communicate with each other, and programmers had a list of all interesting variables and a description of their use.

On 12/6/2017 at 2:57 PM, decle said:

Therefore, it is not possible for the two CPUs to access the memory independently, instead the CP-1610 and 6502 have to arbitrate access to the RAM. Unless there is some clever clock phase fun, this might mean the introduction of wait states, blocking access by one or other CPU while its twin is reading or writing. Clearly, if this is the case, it would slow things down, and while this is probably OK for data that is genuinely shared, it might not be the best idea for page 0 and 1.

The CPUs do access the memory independently. The 6502's clock is phase-locked to the CP1600. Both CPUs in this system have memory cycles of 1.1 us or longer, but the access time for all devices used by the Keyboard Component is 500ns or better. The CP1600 accesses memory during the 6502's PHI1, the 6502 accesses it during PHI2. Access is thus transparently interleaved—no wait state or access blocking is required.

 

 

On 12/6/2017 at 2:57 PM, decle said:

The other thing is that I don't believe that MM5290J is really a dual ported RAM...

The MM5290J device is National Semiconductor's implementation of the industry standard 4116 16x1 DRAM. It is the memory system as a whole that is dual-ported.

 

 

On 12/6/2017 at 2:57 PM, decle said:

According to the data sheet, while it does have two data lines, it looks as though they are exclusively in and out...

The two pins are usually tied together on single-board designs, and they are here. The separate pins for Din and Dout are convenient for interfacing to bus transceivers when designing RAM cards for multi-board systems (like DEC UNIBUS memory boards implemented using 8641 quad unified bus transceivers).

 

 

On 12/6/2017 at 2:57 PM, decle said:

All very interesting.

Your name seems to ring a <BEL>.

 

 

On 2/24/2018 at 3:19 AM, JohnPCAE said:

I'd love to get a look at what they did to genlock the overlay video. I'm still working on my overlay video project (including color text, not just pushing it to white pixels), but it would be interesting to see their solution for getting a stable image. While achieving white text is relatively easy, creating color text requires exquisite timing precision since hue is based on signal phase.

Stabilizing the two images was not a problem: the two sides operate off the same crystal-derived system clock (MCLK), recovered using a phase-locked loop, synchronized with (probably) some combination of MSYNC and SR1. The video signal from the Keyboard Component only adds luminance to the video generated by the color chip, it produces no color component, but that's not because of any difficulty with stabilization.

Every Master Component pixel is the width of one cycle of the color carrier—if you change colors it takes about a full cycle for the new color to stabilize. That is why the objects of all of home video games of the era have trailing shadows. One of the considerations of game designers was picking colors for which the trailing shadows are less objectionable.

The high resolution pixels used for the Keyboard Component's characters are only half the width of a color carrier cycle, so attempting to display high resolution characters of a different tint than the background would have resulted in an unreadable blur—the color carrier simply cannot change phase that fast. In the frequency domain, alternating half-color burst pixels yield a signal with a 7.16 MHz fundamental, and the vestigial sideband broadcast television video signal is very strictly limited to a 4.2 MHz bandwidth. You can do better with composite or component video, but no color television sets were sold with composite, component or S-video inputs until the '80s. The Sony Profeel modular video system, introduced in 1980, was among the first. A large part of the wow factor of the Intellivision III demos at the 1983 winter CES was due to the fact that Profeel TVs accepted other than RF input.

Furthermore, the Keyboard Component only has 1Kx8 of video RAM, enough to hold the character number for each of the character positions but not to hold any associated color or other attribute data.

 

 

On 2/24/2018 at 3:41 AM, intvnut said:

I don't think they actually genlock in the PLL sense. Rather, I think the TMS9927 is being driven by the same clock as the STIC and so has a well defined phase relationship to the STIC. I have a feeling the CBLNK and SR1 signals combine with HSYN/VSYN outputs from the TMS9927 and some logic to gate the pixel clock to the TMS9927 until it's locked in place with the STIC.

Something like that. But thanks to the FCC and Glen Dash, an honest-to-goodness PLL was required to recover MCLK reliably. The Keyboard Component uses an LN56x-family device for the PLL, probably an LN565.

 

 

On 2/24/2018 at 3:58 PM, intvnut said:

Also, I suspect the KC EXEC may be different between the Computer II and Computer III.

Good guess. But since the two boards had to be functionally compatible, it couldn't be very different. Specifically, there was no point in adding a new feature to the CPU1 or CPU2 monitor ROMs since software had to run on both units and so couldn't take advantage of the new feature. This was not a great limitation, since if a particular cassette needed a new monitor capability it could patch it in itself.

Recollections are fuzzy here, but there was a preliminary test release of about 50 units to employees of a large nearby company, and the Computer II board was probably made for that release.

 

 

On 2/24/2018 at 3:58 PM, intvnut said:

There are two PROMs on the KC motherboard that are of appropriate size to serve as "self-load PROMs" for the CRTC. The self-load location is marked as "Don't touch!" in the KC memory map image I linked above. Neither PROM has patterns that quite make sense as TMS9927 CRTC parameters, though, unless there's, erm, interesting wiring between the PROM and the CRTC.

The self-load feature is not used by the Keyboard Component: there's no point, there's a whole 6502 to do the loading! While the system designers understood the self-load feature they saw no reason to describe it in the documentation they prepared for the programmers so they simply included the comment, "Don't Touch!"

It's more likely that the PROMs were used as a low-chip count way to implement random logic. They would have been converted to much cheaper masked ROMs for volume production.

 

 

On 2/24/2018 at 5:04 PM, JohnPCAE said:

I'm starting to think this is why the KC only output white text: when you push a pixel to white, it doesn't matter if your output timing isn't ***exactly*** synchronized with the color burst coming from the MC. The same holds true for any gray-scale signal you send, that would lighten the colors the MC is outputting. They wouldn't need to be precise to MCLK * 4 (14.31818MHz), which is what I'm having to do to get reproducible colors.

No. The Keyboard Component timing derives its master clock from MCLK, and so its video signal IS **exactly** synchronized to that of the Master Component. The Keyboard doesn't attempt to produce colored pixels for the reasons given above: (1) its pixel size is much smaller than one cycle of color carrier and (2) the high-resolution system only has enough RAM for a monochrome display and that was all that was needed to fully meet the functional requirements.

Furthermore, while luminance is added to the Master Component video signal, the signal is not pushed all the way to white. Step function changes in luminance require bandwidth, and if that bandwidth is not available there are uncancelled harmonics that manifest themselves as artifacts. One gets a more readable font if one just moderately increases the luminance.

 

 

On 2/24/2018 at 5:04 PM, JohnPCAE said:

While I can use a crystal to get that frequency easily, I still have to somehow slave it to MCLK.

An LN565 should do the job nicely. Just copy the Keyboard Component circuit.

 

 

On 2/24/2018 at 5:04 PM, JohnPCAE said:

For a crystal with a tolerance of ±30ppm, it equates to a potential drift of up to ±0.5 a clock cycle per frame.

The NTSC burst frequency is specified as "3.579545 mc ± 0.0003 per cent [±3ppm] with a maximum rate of change not to exceed 1/10 cycle per sec per sec." Crystal oscillator circuits generally include a variable capacitor to precisely trim the frequency. While that precision is easily achievable, in practice the lock range of a real TV set is much larger and you don't have to be anywhere near that precise.

 

 

On 6/3/2018 at 3:53 AM, intvnut said:

This implies that the KC EXEC expects the STIC to be blanked. How weird...

Why is this weird? The KC EXEC doesn't care whether the STIC is blanked or not. If the CP1600 isn't doing anything (as in command input or BASIC I) blanking works just fine; if there's an application on the CP1600 side that needs something more than a blank green screen it will have to initialize the required background itself anyway.

 

 

On 7/22/2018 at 5:37 AM, DZ-Jay said:

The reason it was unreliable was because of trying to keep costs down.

Nope. Most of the production problems were due to inexperience with manufacturing. There was nothing inherently unreliable in the Keyboard Component's electronic circuit design—I challenge you to find a part of the circuit where cost-cutting reduced reliability. Reliability issues were mostly a consequence of skipping the "preproduction prototype" cycles and rushing a preliminary design straight from a wire-wrap prototype into production at an assembly house that wasn't up to the task. There was also a problem with production engineers making design changes without consulting the original designers; these had to be reverted. As a specific example, the Computer II circuit boards were ordered in quantity straight from layout without taking the trouble to test them first and rev them as necessary.

Although Chandler always expressed high confidence in the reliability of the cassette mechanism, many others were quite skeptical that it could hold up to the rather tough treatment it received. A sample APh subjected to a long period of 24-hour a day testing held up well, though APh warned that its test wasn't statistically valid and offered to conduct a rigorous one. The problems experienced with the drive these days seem to all be due to rubber parts that degraded over time.

One manufacturing issue that really was a huge problem was in tape duplication. Tapes that were recorded at 1x speed worked reliably. The high-speed duplicators set up for production were spec'd to have a high frequency response they didn't legitimately meet. Mattel had procured the tape stock, and the duplicator tried to point the finger at that. There was significant tape-to-tape inconsistency, and there was no economical way to test each individual tape before shipping. Resolution efforts were focused on improving the process to work at full speed rather than simply slowing the recording speed down. The under-informed tended to attribute problems that were really tape duplication issues to the drive.

 

 

On 7/22/2018 at 5:37 AM, DZ-Jay said:

It was intended to be a "full-fledge professional computer"

Nope. It was originally intended to be a "home computer," meant for things that Jeff Rochlis felt people wanted to do at home, as opposed to a product that did traditional computer-like things. Hence the emphasis on Exercise, Weight Loss, Speed Reading and Astrology cassettes as opposed to word processors, spreadsheets and modems. Even BASIC wasn't in the original mix of contemplated software--when the press asked Rochlis and Huber about that they replied that their consumer research had shown that most consumers had little interest in writing their own software. Chandler pushed to have a word processor included in the original mix but Rochlis wasn't interested. APh snuck a line editor with EMACS-influenced editing commands into the Keyboard Component monitor as a programming object that other programs could access when they needed the ability to edit text. Object-oriented programming in 1979!

 

 

On 7/21/2018 at 8:24 PM, First Spear said:

It is now easy to see why these never really made it, they were more of an engineering-driven project than a marketing-driven project; I can imagine that if a business unit leader said "let's make this" instead of Papa Intellivision, it would have had 1/2 the features, been more reliable, and sold.

Nope. Entirely marketing driven. The business unit leader's names were Jeff Rochlis and Ed Krakauer. The Keyboard Component is definitely not a product that an engineering team would have designed on their own.

 

 

On 7/21/2018 at 8:24 PM, First Spear said:

IR sensor and microswitch to detect a special tape with super-clear header area?! Just another example of places for the unit to be unreliable.

Not at all. First, the two components had unrelated functions: the microswitch detected that a cassette was in place; the IR sensor detected that the cassette was rewound. Both components are exceedingly reliable (your microwave oven uses a microswitch to detect that the door is closed). Clear leader is nothing special either; that's what you get if you scrape the magnetic coating off a normal piece of tape. Tapes with clear leader were readily available, and the ability to detect it is was a standard feature of better quality cassette decks, used to implement the "auto-stop" function.

 

 

On 7/21/2018 at 8:24 PM, First Spear said:

Wow, the KC was just too complex to survive as a real product.

Nope. Complexity was not an issue in the cancelation decision.

 

 

On 7/22/2018 at 5:37 AM, DZ-Jay said:

You are right that the reason the project continued for so long was due to Papa Intellivision's influence and clout within the company...

Nope. The Keyboard Component was Jeff Rochlis' baby and was an essential element in getting Spear and Wagner to approve the Intellivision project at all. Chandler was hired to help implement that vision, which was already set in stone before Mattel even began advertising for his position. Although Chandler fully bought into the concept (which contributed to the reason he was picked), in this regard he was a minion, not a driving force. He was, in fact, somewhat distressed that there was no word processing program in the mix.

 

 

On 7/22/2018 at 5:37 AM, DZ-Jay said:

Remember, those features were driven by marketing, not engineering.

Yup. But Rochlis and Chandler were naïve about the cost when initially specifying those features. As they learned more and more about the actual cost, Rochlis, Wagner and Spear kept opting to proceed. Denham, on the other hand, who took over as president when Rochlis left, was shell-shocked.

 

 

On 7/22/2018 at 5:37 AM, DZ-Jay said:

The tape-lead detection mechanism wasn't some cobbled-together hack they came up with; it was standard in many devices of the time...

Yup. The tape mechanism selected, which included that feature, was a pre-existing off-the-shelf OEM product, not something specially designed for Mattel.

 

 

On 7/22/2018 at 5:37 AM, DZ-Jay said:

By the time something like it could have been done practically, data storage was moving towards disk-based rather than tape-based...

Nope. By 1978 floppy disk systems abounded; APh used them for development and had designed floppy drives into products for other customers. Even Heathkit was selling assemble-it-yourself kits to hobbyists. Mattel could easily have implemented a floppy-based system, but such a system wouldn't have had the audio capability, which was essential for the product Rochlis envisioned. If you look at the Keyboard Component's cassette subsystem (the deck and its associated control and analog boards) it's every bit as complicated as a contemporary floppy drive. Check it out for yourself: disassemble both the Keyboard Component cassette mechanism and a floppy drive mechanism and compare them side-by-side. Then do the same for the read/write electronics boards. Chandler was quite aware of this. Higher management wasn't.

 

 

On 7/22/2018 at 5:37 AM, DZ-Jay said:

I do not believe anything less than the actual Keyboard Component would have made any impact to in the market...

Anything less than the actual Keyboard Component would not have had the required features and would never have been considered. Together, the built-in typewriter mode, French, and BASIC use just about every Keyboard Component hardware feature.

 

 

On 7/22/2018 at 5:37 AM, DZ-Jay said:

Oh, and a "business unit leader" did say "let's make this" instead: It was the ECS, which in my personal estimation, is an embarrassment to be called a "computer" -- and this is coming from someone who owned one when he was a young impressionable child, as his very first computer...

Ouch! But you're not alone in your assessment: Chang, Chandler and most of the technical hardware folks at Mattel agreed. Yup, Chang too. In assuming responsibility for the design of the ECS Chang was being a good soldier, responding to the desirements of his boss despite his better judgment. Denham and Prodromou, who were neither computer people nor video game players, were boxed in by their predecessors' decisions and saw no other short term options.

But that's only a part of the larger story. The first Voice Synthesizers, Space Spartans and B-17 Bomber landed on the shelves of Gottschalk's department store in Fresno shortly after Labor Day in 1982 and the marketing minions assigned to monitor their movements immediately sent back word that they were making themselves comfortable there, refusing to budge. The possibility that the ECS would do the same suddenly became very real to even the highest management. In consequence they felt a desperate need to find something else to sell until the just-approved Intellivision III and its computer module were ready. And so those panicking "business unit leaders" exercised their phenomenal cosmic power and said, "Let there be the Aquarius." And they saw the Aquarius, and that it was good, and felt satisfied that they had done their jobs as executives, and their panic subsided.

 

 

On 8/10/2018 at 7:54 AM, decle said:

This means that in a rough and ready sense each long half cycle at 1.5KHz is binary 0, each short full cycle at 3KHz is binary 1 ...

Nope. It's just wrong to think of the Differential Manchester signal in those terms. You're thinking in FSK terms, and this ain't that. FSK thinking is simply not applicable to decoding Differential Manchester signals.

 The shapes you see aren't half cycles of sine waves, they are a squared up signal whose rise and fall transitions have been frequency limited. Think of the signal in terms of time slots. The sync pattern establishes the initial alignment of the slots and the signal is self-aligning thereafter. A transition in the middle of a time slot represents a one, no transition in the middle of a time slot represents a zero. The result is an AC signal with no DC component that is easily transmissible and storable. As you can see from your figure, the transitions in the middle of the time slots are easy to detect despite significant signal distortion.

The raw signal coming out of or fed into the Manchester encoder/decoder logic is a squared-up version of what you show in your figure. But it takes infinite bandwidth to transmit a fully squared up signal. If you send a fully squared up signal through a channel with finite bandwidth the edges of the signal will get rounded and the transitions slew-rate limited and you will get a signal like the one you show here. So the interesting question here is, how short can you make the time slots and still get a signal that is recoverable after having been sent through the limited-bandwidth channel of a cassette tape?

Ferric oxide cassettes playing at 1 7/8 inches per second have a nominal bandwidth of 10-12 kHz, although some claim higher. But you have to remember that the signal at the high end of the reported range is 6dB or more down from response at the center. Furthermore, the real question is, "what is the effective bandwidth of the whole channel, including the high-speed tape duplication stage?" (That’s where the quality monitoring tapes in the Papa Intellivision collection fit in.) For a consumer product you have to engineer a system for which ten thousand sets of Conversational French tapes will average no product returns.

You report a "short full cycle at 3KHZ", which translates to 333 us/bit (confirmed by your data capture at https://www.youtube.com/watch?v=88IEY3oPlpg&t=785s). Eyeballing the signal, you can see that the slew rate is just fast enough to produce a full range signal excursion for the 1 bits—if the 1 bits were much shorter you wouldn't get a full peak-to-peak excursion. So the data is recorded at about the fastest data rate the system can reliably accommodate.

Interestingly, 1/(333 us/bit * 1-7/8 inches/second)=1600 bpi, which is the same bit density as the familiar industrial reeled computer tapes of the time (the ones you see in the big computer rooms shown in the movies of the '80s). Not too shabby.

 

 

On 8/10/2018 at 7:54 AM, decle said:

it is not clear that the digtial bias is required when reading from the tape

It's clear that it isn't. The tape read head induces a current in a coil wrapped around a core and so can only detect change in magnetic flux. You remember ´E = −∂B/∂t, discovered by your own Michael Faraday just a few miles down the road from you. Stated more simply, the tape head is a transformer and it's rather difficult to pass a DC component through a transformer. Furthermore, the differential Manchester code was chosen because it has no DC component, no matter what the data content. Any DC bias in the read signal is an artifact that carries no information. There is probably a high value resistor somewhere in the read circuit to bleed off any DC bias introduced by signal imperfections.

Tape response functions have linearity issues for signal values near zero, where the magnetic domains on the tape reverse direction. When recording one can in principle apply a DC bias to the recording field to move the entire signal outside that range, which appears to be what you're thinking. But that's old technology, even older than the Intellivision.

Although today we think of the twentieth century as a single point of time in ancient history, in fact many years passed between the invention of magnetic audio recording and the advent of the Philips cassette. Sometime during that interval it was discovered that very good recording linearity could be achieved by convoluting the audio signal with a very high frequency signal (75+ kHz) that jiggles the magnetic domains on the tape during the recording process, sort of like evening out the surface of sugar in a bowl by jostling it. This somewhat misnamed process is called AC bias, and tape recording circuitry has a bias oscillator that provides the signal used to induce the jiggle. The AC bias signal is also used to erase the tape. You needn't concern yourself with AC bias unless you're trying to emulate driving the actual record head coil. Since the read heads can't recover the AC bias signal except as extremely low-level hiss, there's really not much point of carrying your emulation down to that level unless you also plan to model the magnetization of the individual domains on the tape. There are a few tens of billions of those per inch.

Oh, and the reason recorders of the day had bias switches is because the ideal bias current for chromium dioxide tapes is higher than the ideal bias current for iron oxide tapes. Don't let the existence of such bias switches mislead you into thinking that there's a DC bias in the audio signal.

 

 

On 8/10/2018 at 7:54 AM, decle said:

This transposition of the data on the tape was another noise protection mechanism. If there was a drop out or other problem of less than 10msec in length it would only corrupt one bit of each of the 32 decles and the data could be recovered. If the bits associated with a single decle were stored consecutively on the tape such a dropout would nuke the data in a single decle beyond the repair of error correction.

Bingo! (Well, not electrical noise protection, just drop out protection.)

 

On 8/11/2018 at 6:43 AM, decle said:

Couple of notes on the implementation. I've used pure sine waves rather than the "interesting" waveform seen on Ron's tapes. This might cause a problem, but could be changed pretty easily.

Pure sine waves are great for an FSK channel, but not so much here. Instead, you want the centers of the rising and falling transitions to be regularly spaced:

/¯¯¯\___/¯\_/¯¯¯\_/¯\
| . | . | . | . | . |
| 0 | 0 | 1 | 0 | 1 |

These are not sine waves or even portions of a sine wave. If you eyeball your recorded signal the one bits are just fine but the zero bits droop a bit after the leading transition. By using sine-shaped segments of different frequencies (differing by a factor of two!) you are introducing jitter into the transition points, the location of which is the only thing that really matters. The little daemons that operate the decoding circuitry will be able to handle it (in the absence of long dropouts), but they'll be rolling their eyes in your general direction.

On 8/11/2018 at 6:43 AM, decle said:

And I've put in what I think is a similar DC bias...

A Differential Manchester encoded data stream has no relevant DC component.

 

On 8/12/2018 at 2:27 PM, Lathe26 said:

It would be a poor Mattel design decision to allow users to write over the records since a user's Keyboard Component whose tape drive was slightly out of alignment might screw up the PLL timing that is pre-encoded on the tape (phase shifts, frequency shifts, frequency wow and flutter due to belt wear, etc). It would be better to leave these records as read-only and only allow writing on a different track entirely. That doesn't mean that is what they actually did, but that would be my suspicion.

The Keyboard Component tape system is a block-structured random-access device along the lines of LINC tape or DECtape. The pre-recorded data track does quadruple duty: it holds pre-recorded data, it contains data identifying its absolute position on the tape, its inter-record gaps serve as markers for seeking to the correct record at fast-forward and rewind speeds and it serves as a time-code track for synchronizing program material with the audio tracks. The 6502 monitor implements a software phase-lock loop to maintain time-code continuity when audio spans inter-record boundaries (rather like a color TV's phase lock loop maintains color phase continuity between the gated color burst signals at the beginning of each horizontal scan line).

 

 

On 8/12/2018 at 2:27 PM, Lathe26 said:

how much KC software would have contained 260K decles on a machine that only had 16K decles of RAM in the initial software releases...

Um…most of it. APh was continually impressing on Mattel how much storage was going to be required to implement the cassettes they envisioned. French, the very first program out of the gate, needed two whole cassettes for a mere five lessons and, as Decle reports, has "lessons recorded on both the Read Only and Read/Write tracks." Football needed team data and playbooks for 16 teams and could record the game, Income Tax Preparation required a separate memory page for each tax form, Reading Comprehension required a huge library (text takes a lot of space, even when stored as radix-100; a single page of a paperback book can contain over 2400 characters), Stock needed years of historical data, Spelling and Math had separate themed animation for every week of the school year, Bear Run loaded new mapping data for each level, Astrology had a large ephemeris plus a huge library of horoscope text, Crosswords tapes were competing with paperback puzzle books that held 100 puzzles per book, Wheel of Fortune had a huge library of phrases, Programmed Learning could be filled to the limit with subject matter, Weight Loss had a long list of foods and separate data bases for multiple users, etc.

 

 

On 8/13/2018 at 9:44 AM, intvnut said:

On PapaIntellivision, look for the PDF that has this in it:

 

post-14113-0-86274900-1534178069_thumb.png

The Chuck Rudd who received that document was a Mattel employee in Chandler's group who, among other duties, served as liaison with APh. This document was printed on one of APh's printers. The stamped date is only 13 months after the Chandler's Keyboard Component kickoff meeting with Maine and Harrower in Hicksville.

 

On 8/13/2018 at 9:44 AM, intvnut said:

Frank dug up some BLISS16 code (we think it's BLISS16) that generates the ECC code.

APh had been using BLISS for systems code since 1975, well before the advent of the C programming language. It had BLISS compilers targeting both the 36-bit PDP-10/PDP-20 family and the 16-bit PDP-11 family. K&R didn't publish their seminal book introducing the C language until 1978.

 

On 8/13/2018 at 12:48 PM, mr_me said:

The KC Basic book says each record stores up to 2kB. So with 100 records that's 200kB ... Sounds like a lot.

It's comparable to a single-sided single-density 8" floppy's worth, so it was competitive with contemporary floppy disk-based systems. But it took noticeable time to seek to the right place, so longer tapes impacted perceived performance. That's why BASIC data tapes weren't full C60s.

 

On 8/17/2018 at 2:31 AM, DZ-Jay said:

I would imagine had this gone into actual production and become a staple of Mattel Electronics catalogue, we would have seen the eventual release of pre-formatted, double-sided tape cassettes. You're right, it would make sense since a BASIC tape wouldn't have any use for the Read-Only tracks, so flipping the tape and making them available could have been an option.

The pre-recorded data track was needed to position the tape to the appropriate record—alignment would have been problematic without it. One couldn't have users erasing and re-writing it piecemeal.

It was appreciated at the time that there were two fundamental choices for track order: either they could alternate data-audio-data-audio, in which case the capacity of a digital-only cassette could be doubled by flipping it, or they could be symmetric audio-data-data-audio, in which case it couldn't. Test data showed that the center of the tape was less susceptible to dropouts than the sides. Reliability trumped capacity and the two data tracks were placed in the middle.

 

On 8/17/2018 at 3:33 AM, mr_me said:

I'm surprised there was no attempt at copy protection.

That would indeed have been an inconceivable oversight, especially considering the tapes were expected to sell for around $70. Look harder.

 

On 8/17/2018 at 8:47 AM, Lathe26 said:

As for dubbing a copy, it is theoretically possible. The only issue is that you need to find a blank tape whose leader tape (the part that comes before the magnetized tape) is permeable to infrared light since the KC uses such a sensor to find the start of the tape.

Such tapes weren't all that hard to find. If you couldn't find one, leader tape and splicing kits were available from your local stereo shop or Radio Shack. The Intellivision BASIC data tapes weren't copy protected. The system's designers would have preferred users to be able to use ordinary cassettes for storing BASIC programs, but the pre-recorded data track was needed to make the tape a block structured device. They would not at all mind having users make their own. The copy protection scheme used for regular program cassettes would have frustrated copying by all but well-financed commercial scale pirates.

 

On 8/17/2018 at 9:14 AM, DZ-Jay said:

A lot of variance was added to microcomputer implementations to compensate for the flakiness and bad quality of typical music cassette recordings. The KC, having a dedicated tape machine may not have such tolerances built in.

The Keyboard Component had no problem reading cassettes duplicated on ordinary cassette drives.

 

On 1/18/2019 at 1:56 AM, decle said:

This completely bypasses the EXEC and all the clever Mattel stuff and just bit bangs the memory addresses that contain the tape status and control registers, as described on page 27 of this Papa Intellivision document:

 

post-46336-0-74258000-1547804478.jpg

Which document was also printed on an APh printer.

 

On 2/2/2019 at 10:03 AM, decle said:

The next thing is to investigate Conversational French tape B to try to understand whether what we see is expected. I find it a little surprising that there is no error message or suggestion to load tape A. Not very Mattel.

Not very Mattel indeed! And not very APh, either. I don't know the answer, but we're clearly missing something.

 

On 2/3/2019 at 4:36 AM, DZ-Jay said:

Such a complicated electro-mechanical device, with so many features and fail-safe guards, but it won't alert you of something dead-stupid like putting the wrong tape in first. It doesn't sound like David Chandler's work.

It wasn't. Chandler played no role in software development.

 

On 11/12/2020 at 1:59 AM, mr_me said:

It was cancelled because they couldn't get manufacturing costs down...

This statement isn't even a little bit true. Although the manufacturing cost weighed heavily on management's mind, it was an irrelevant consideration in the actual decision to cancel the unit.

image.png

  • Like 6
Link to comment
Share on other sites

9 hours ago, Walter Ives said:

Such tapes weren't all that hard to find. If you couldn't find one, leader tape and splicing kits were available from your local stereo shop or Radio Shack. The Intellivision BASIC data tapes weren't copy protected. The system's designers would have preferred users to be able to use ordinary cassettes for storing BASIC programs, but the pre-recorded data track was needed to make the tape a block structured device. They would not at all mind having users make their own. The copy protection scheme used for regular program cassettes would have frustrated copying by all but well-financed commercial scale pirates.

This reply mis-characterizes the original comment:

  1. The original comment wasn't past tense; it was present tense.  The original comment was that if you wanted to make copy of a KC tape today, you would need a tape with a clear leader that was UV permeable.
  2. The original comment neither stated nor implied anything about copy protection.  The comment had no relation to copy protection.
  • Like 1
Link to comment
Share on other sites

On 12/3/2022 at 8:00 AM, Walter Ives said:

Nope. Most of the production problems were due to inexperience with manufacturing. There was nothing inherently unreliable in the Keyboard Component's electronic circuit design—I challenge you to find a part of the circuit where cost-cutting reduced reliability. Reliability issues were mostly a consequence of skipping the "preproduction prototype" cycles and rushing a preliminary design straight from a wire-wrap prototype into production at an assembly house that wasn't up to the task. There was also a problem with production engineers making design changes without consulting the original designers; these had to be reverted. As a specific example, the Computer II circuit boards were ordered in quantity straight from layout without taking the trouble to test them first and rev them as necessary.

 

Although Chandler always expressed high confidence in the reliability of the cassette mechanism, many others were quite skeptical that it could hold up to the rather tough treatment it received. A sample APh subjected to a long period of 24-hour a day testing held up well, though APh warned that its test wasn't statistically valid and offered to conduct a rigorous one. The problems experienced with the drive these days seem to all be due to rubber parts that degraded over time.

 

One manufacturing issue that really was a huge problem was in tape duplication. Tapes that were recorded at 1x speed worked reliably. The high-speed duplicators set up for production were spec'd to have a high frequency response they didn't legitimately meet. Mattel had procured the tape stock, and the duplicator tried to point the finger at that. There was significant tape-to-tape inconsistency, and there was no economical way to test each individual tape before shipping. Resolution efforts were focused on improving the process to work at full speed rather than simply slowing the recording speed down. The under-informed tended to attribute problems that were really tape duplication issues to the drive.

 


Although I find the entire post, generally, fascinating and insightful, I believe it mischaracterizes a few of the points it purportedly attempts to rebuke.

 

On my quoted comments specifically, related to the reliability of the product stemming from cost-cutting decisions, I was not trying to suggest that the device was a flaky, useless mess of unreliable components, but that a focus on maintaining the price point within the range of a retail product precluded the employment of actual commercial components out in the market.

 

You cannot tell me that attempting to do what an IBM 3420 or DECTape tape machine did on a consumer graded retail cassette tape deck from the 1970s was a simple, straightforward, and uncomplicated application of the technology, devoid of any risks of unreliable performance from a device which was not designed or for it as it's common use case.

 

That was my point:  That had Mattel included a commercial tape drive in its offerings, along with the attendant commercial software and support -- all extant and in reliable production in the industry at the time -- the KC tape drive reliability issues would not have been as much of a concern.  But then again, Mattel wouldn't be able to sell such set up for under $1,000.00.

 

The overarching point is that, the moment you aim sophisticated, commercial-grade technology applications at a consumer retail market product, your options of available components and solutions to employ are curtailed necessarily by the cost differential between the markets.


Mr. Ive's point seems to be that the root cause was unfamiliarity of the manufacturing process -- which is, of course, very true; but I would assert that this is itself an incidental result of precisely applying such technological solutions to a market in which no readily available components exist, within a business environment that has never dealt with such solutions before.


Still, the additional background and contextual information is very interesting indeed.


Anyway, thank you Mr. Ives for responding at all.  Your posts have been a fount of new insight to this community.  I read every single one, and found them all fascinating. :)

 

It feels awkward to ask at this point, so pardon me for doing so boldly:  what is your connection to the Intellivision product?  You've mentioned some personal or familial relation to someone in its history; would you mind sharing at who's memories, knowledge, and experience we have had the honor of glimpsing from your posts?

 

I am not familiar with your name, but given the breadth and depth of your insight, your authority on the subject seems to be unquestionable.

 

    Thank you,

    dZ.

Edited by DZ-Jay
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...