Black Whale Keyboard Component development kit demo

[decle]

Afternoon all,

A bit of a longer video today from RonTheCat's KC lab. Hopefully it has some interesting stuff you've not seen before, unless you are a BSR

We have converted Ron's Keyboard Component setup from a Blue Whale into a replica of a Mattel Black Whale development kit. We have a video of the result, hopefully it gives a flavour of what using some of Mattel's tools might have been like in 1983:

The video is done in one long take, so there are some errors and flubs along the way . I've added chapter points to the YouTube description, so you might want to view it there if you are after a particular section.

The big news is that this demonstration confirms the excellent re-engineering of Daniel Bass's development kit boards done by JoeZ and FrankP. Great work guys!

There are some things we probably should have mentioned, but forgot:

• Ron's KC is a standard production model (a Computer III). In converting it to a Black Whale it was not modified in any way.
• The MC used is a standard NTSC Intellivision model 1. In addition to the modifications mentioned as you can see we removed its RF shield for easy access.
• We don't know how Mattel modified the MC to link the PCIT and INTR pins to get breakpoints to work. The circuit used is a minimal solution constructed from first principles.
• The Dev Kit software is not completely compatible with Ron's KC. We had to change two bytes in the 6502 code to get it to correctly initialise the serial board. How this incompatibility was circumvented at Mattel is not known.
• We don't know what, if any, PDP-11 comms software was used by Mattel. We do know that there is no flow control between the PDP-11 and the Black Whale. So either can flood the other by sending data faster than they can process. With VTCOM in FAST mode this will sometimes happen at the end of sending a line of program data. We could use VTCOM SLOW mode, however, this is very conservative and takes an order of magnitude longer. So we use FAST mode and slow down the emulation while we download a program to prevent data corruption. Presumably this would not be necessary if we used a real PDP-11 and the comms software used by Mattel.
• Other than typing X to start the Dev Kit software you don't use the KC directly. All the commands are typed on the terminal (in this case a wireless keyboard connected to the laptop).
• We're not sure why our first attempt to set the value at $5C2A failed. Looking back, judging by the $F3 returned by the dev kit, it seems we might have changed the data in some other address. Thankfully it did not screw up the demo!

As always, many thanks to RonTheCat for an excellent lunch and for the chance to play with his many, wonderful Intellivision toys.


Cheers

decle


Links to things mentioned in the video:

• Development Kit Reverse Engineering Report by JoeZ
• SimH Minicomputer Emulators
• IMDI - the Intellivision Music Digital Interface
• Intellivision break out board and MC/KC extension cable
• Intellivision development tools description
  

[Ron The Cat]

Great work Decle , glad to be part of this great adventure to get to see how things would have worked back in the day to develop stuff

 

Seeing it work the first time felt I could hear jurassic park music in the background , like seeing a

dinosaur for the first time

Edited September 30, 2018 by Ron The Cat

[+DZ-Jay]

Great job, guys! I'm still watching the video, but I am very excited over this -- it's something I've been dreaming to find out more about for ages. So thanks for doing it.

 

One thing, though... I was a bit surprised to see my avatar printed on a sheet of paper. What's that for? Just keep in mind that it is intellectual property too, not a generic freely available image.

[intvnut]

I think I have an explanation for what happened with the misdirected memory update at $5C2A. It's one of (many) bugs in the debug monitor.

 

To be clear, I'm referring to this moment in the video:

 

 

In that screen cap, you can see that 5C2A/ caused the monitor to print out F3 (notice, only 2 digits), and subsequently the update didn't take place as expected. When repeated, typing 5C2A/ caused the monitor to print out 0055 (notice, 4 digits!), and the update proceeded as expected.

 

The monitor has two commands, / and ;, that are meant to update CP1610 and 6502 memory, respectively. The two commands share a common implementation, and use the byte at 6502's location $14 to distinguish which command is running: 0 means /, and non-zero means ;. In the monitor, locations $08, $11, and $14 also are used to indicate whether the 1st, 2nd, and 3rd arguments are present, and if present, how many digits they hold.

 

It turns out there's a couple of bugs here that stack on top of each other to yield the behavior seen in the video.

 

To understand this, you need to see the code. This is the top of the command processing loop for the 6502-side monitor:

.

E0BD  20 A4 EA  JSR $EAA4   ; Send CR+LF out serial port (blocking)
E0C0  A9 3E     LDA #$3E    ; \__ Send '>' out serial port (blocking)
E0C2  20 AB EA  JSR $EAAB   ; /

E0C5  A9 00     LDA #$00    ; \
E0C7  85 0F     STA $0F     ;  |
E0C9  85 10     STA $10     ;  |
E0CB  85 11     STA $11     ;  |- Zero $0F through $14
E0CD  85 12     STA $12     ;  |
E0CF  85 13     STA $13     ;  |
E0D1  85 14     STA $14     ; /

                ;; Arguments are stored in this order:
                ;;
                ;;      $13:$12, $10:$0F, $07:$06
                ;;
                ;; $14, $11, and $08 store the number of digits in each argument,
                ;; to indicate whether the argument was provided, and if so, how
                ;; long it was.  (Length matters for some commands.)
                ;;
                ;; Arguments are separated by commas or less-than signs.

                ;; Shift all the arguments over by one:
E0D3  A5 0F     LDA $0F
E0D5  85 12     STA $12
E0D7  A5 10     LDA $10
E0D9  85 13     STA $13
E0DB  A5 11     LDA $11
E0DD  85 14     STA $14

E0DF  A5 06     LDA $06
E0E1  85 0F     STA $0F
E0E3  A5 07     LDA $07
E0E5  85 10     STA $10
E0E7  A5 08     LDA $08
E0E9  85 11     STA $11

.

 

This is supposed to print out a prompt, and then zero out all three arguments. That's not actually what it does. It prints out the prompt, zeros out arguments 2 and 3, and then does a copy: Copy 2 => 3, and then copy 1 => 2.

 

I think the code at $E0C5 was meant to zero out arguments 1 and 2, not 2 and 3. If it had, then all three arguments would have been zeroed.

 

As a result, the first argument of one command ends up getting carried in as the second argument of the next command.

 

In the video, decle runs the 'V' command to verify the ROM. The 'V' command then branches to the code seen above. This ends up copying the argument for 'V' to the second-argument position.

 

Next, decle runs the 'M' command to print out memory. The 'M' command has a second bug:

.

E32E  20 34 E3  JSR $E334   ; Body of command below.
E331  4C D3 E0  JMP $E0D3   ; Get next command     <=== Actually.... a bug!

.

The entry point for 'M' does a JSR to the body of the command, and then does a JMP to $E0D3 when it's done. Look at the code above: This just copies argument 2 => 3, and then 1 => 2 before processing an incoming command. That means, the non-zero argument from 'V' that had been copied to the second-argument position has now been moved to the third argument position.

 

As I mentioned above, the / and ; commands use location $14 to distinguish which command was actually invoked. Otherwise, they share a common implementation. You can see this in the dispatch for / and ;:

.

E13B  C9 2F     CMP #$2F    ; '/'
E13D  F0 38     BEQ $E177
E13F  C9 3B     CMP #$3B    ; ';'
E141  F0 32     BEQ $E175

...

                ;; The ';' and '/' commands are closely related:
E175  E6 14     INC $14     ; ';' branches here, falls thru to JMP
E177  4C B0 E3  JMP $E3B0   ; Dispatch for both ';' and '/'.

.

Location $14 also holds the length of the third argument. So, due to the bug in how arguments get moved between argument slots and the fact that 'M' returns to the wrong part of the parsing loop, we now have a non-empty third argument when we arrive in /. That causes / to think the user actually entered ;, and it instead tries to inspect and modify 6502 memory.

 

Look again at that screen shot:

The monitor printed out 2 digits on the first attempt. That's what ; would do: Display the byte (2 digits) from 6502 memory, and then let you modify it. On the second attempt, the monitor printed out 4 digits. That's what / should do: Display the word (4 digits) from the CP-1610 side, and let you modify that.

 

I think we can see why this debug monitor was on version 5: It was buggy and is still buggy.

[intvnut]

This video is pretty darn cool, BTW. I really enjoyed watching it, and seeing all of this come to life. I realize I jumped right into debugging above, but first and foremost, I think it's really f'ing cool you're bringing this all back to life.

 

Thank you for your dedication to bringing up this repro hardware!

Edited October 1, 2018 by intvnut

[+DZ-Jay]

This video is pretty darn cool, BTW. I really enjoyed watching it, and seeing all of this come to life. I realize I jumped right into debugging above, but first and foremost, I think it's really f'ing cool you're bringing this all back to life.

 

Thank you for your dedication to bringing up this repro hardware!

 

I agree, it is very cool indeed! You see pictures and movies of people back in those days debugging programs with reams of printed code and a pencil, or sitting at a telex typing computer instructions. To me, watching this video feels like a window into "the future" of the past. Interactive debugging on-board an Intellivision feels like ahead of its time back in the early 1980s.

 

Thanks for doing this!

 

-dZ.

[mr_me]

Very nicely done. It's amazing to see the KC development system in action.

 

On the intellivisionlives KC page Keith did mention the KC ram addressing was modified for cartridge addresses. It looks like the first 4K of KC ram is not available, leaving 12K. Daniel Bass' last project, Tower of Mystery/Doom, uses at least 24k with 8k in the KC memory space. He would have had to use a ram cartridge either way. If they did modify the KC ram addresses could they have developed 12K games without a ram cartridge? Perhaps they did at first but as they moved to 16K cartridges they didn't bother.

 

I thought most, if not all, KC development systems were served by VAX computers at Mattel. While a PDP-11 could serve maybe six terminals, a VAX could serve dozens. No matter as VMS or unix would have something similar to vtcom to send files into intellivision memory.

[First Spear]

AAAAAAAAAaaaaaaaaaaaamazing.

 

Just wow. Thank you for putting your energy into unlocking some of the "how did they do that" mystery!

[tschak909]

I do need to point out:

 

Yes, it is most likely that the printer port on the terminal was used to connect directly to the Black Whale. This is in reality an "auxiliary" serial port, which can be flipped to, and back again.

 

Typically this is done with the following escape sequences:

 

ESC [ 5 i to flip on

ESC [ 4 i to flip off

 

These can be specified on modern systems with termcap capabilities "po" and "pf" respectively.

 

-Thom

[intvnut]

On the intellivisionlives KC page Keith did mention the KC ram addressing was modified for cartridge addresses. It looks like the first 4K of KC ram is not available, leaving 12K. Daniel Bass' last project, Tower of Mystery/Doom, uses at least 24k with 8k in the KC memory space. He would have had to use a ram cartridge either way. If they did modify the KC ram addresses could they have developed 12K games without a ram cartridge? Perhaps they did at first but as they moved to 16K cartridges they didn't bother.

 

I'm personally skeptical that they had modified the Keyboard Component to move the shared RAM down to $5xxx. If they did, though, they probably only moved $A000 - $BFFF down to $5000 - $6FFF, given how the monitor works.

 

 

I thought most, if not all, KC development systems were served by VAX computers at Mattel. While a PDP-11 could serve maybe six terminals, a VAX could serve dozens. No matter as VMS or unix would have something similar to vtcom to send files into intellivision memory.

 

I do know Keith had mentioned Andromedas, which were clones. I forget where, but I heard some suggestion Mattel had less capable systems than APh had access to.

 

In the Patrick Aubry photo, we can see a VT-100 clone (C.ITOH CIT-101), and when I looked up its docs, it definitely had a "dual port" mode with pass-through support as suggested in the video.

[daniel3302]

Very nicely done. It's amazing to see the KC development system in action.

 

On the intellivisionlives KC page Keith did mention the KC ram addressing was modified for cartridge addresses. It looks like the first 4K of KC ram is not available, leaving 12K. Daniel Bass' last project, Tower of Mystery/Doom, uses at least 24k with 8k in the KC memory space. He would have had to use a ram cartridge either way. If they did modify the KC ram addresses could they have developed 12K games without a ram cartridge? Perhaps they did at first but as they moved to 16K cartridges they didn't bother.

 

I thought most, if not all, KC development systems were served by VAX computers at Mattel. While a PDP-11 could serve maybe six terminals, a VAX could serve dozens. No matter as VMS or unix would have something similar to vtcom to send files into intellivision memory.

It was 35 years ago, so my memories are a bit fuzzy, but I do not remember ever using the KC for game development. As I recall, we had a double row of cubicles (4x2) with a PDP-11 at the end of the row serving the 8 programmers (or maybe it was 3x2 and only 6 programmers). I only remember using the video terminal and the MC with the "magus board".

 

Two side memories just jostled by that description of our work environment -

1) I remember Ray Kaestner worked on the other side of the cubical wall from me, i.e. we were on the same row of cubes. Presumably, this is why the Loco-Motion machine showed up at the end of our row one day (as Ray was originally to be assigned that game - I was working on a LUCKI game at the time). Well, it was the proximity of that distraction that led to my instant addiction which led to my inspiration that led to my demonstration that led to me being assigned to Loco-Motion!

 

2) The other game distraction of mine was Hack ( https://en.wikipedia.org/wiki/Hack_(video_game) ) which was played on the PDP-11 via the video terminal and keyboard (not KC). I remember that Mark Kennedy also played and once made the comment that the keyboard was pressure-sensitive and the harder you pounded on the appropriate key, the stronger your hit against whatever monster you were fighting would be. Of course he was pulling my leg, but at the time, he said it so earnestly and so dead pan, that I just wanted to believe him!

Anyway, you should be able to see that my implementation of Tower of Mystery was strongly influenced by my addiction to Hack!

Edited October 1, 2018 by daniel3302

[BSRSteve]

We had Andromedas when I started in late 1981, which was well before they had done anything with Keyboard Components. By mid-late 1982 we got a VAX, running Unix. I think that is when they started using the Keyboard Components (which I still think we called Blue Whales, not Black Whales), and shortly after that, they mixed in the Magus boards. At that time, I was working on Utopia for Aquarius, so I was not affected. I don't really remember what system I had when I returned to Intellivision for a while after that, and I spent the last several months working on the Power of He-Man for Colecovision.

 

But I agree that using the KC for development was with the VAX.

 

I may have some paperwork regarding that history in the voluminous files that Keith left behind, but I haven't gotten around to digging through the history yet.

[+Lathe26]

Love the photo of the handsome devil at the beginning of the video!

[Ron The Cat]

Love the photo of the handsome devil at the beginning of the video!

 

 

Seems to always to bring some luck watching over us.

 

Few other teasers scattered around in the video ....

[+Lathe26]

BTW, I _finally_ got to watch the whole video. Great work!

 

I really found it fascinating that the CP1610 wasn't just a jumper wire but needed a live chip to extend the signal.

[intvnut]

BTW, I _finally_ got to watch the whole video. Great work!

 

I really found it fascinating that the CP1610 wasn't just a jumper wire but needed a live chip to extend the signal.

 

Yeah, that was a detail that decle and I sweated for a bit. I did update that portion of my reverse engineering document. It turns out that PCIT* is held from TS2 through TS4, and fades during the following TS1. INTR* however is synchronized and sampled during that same TS1, and it appears the signal needs to be stable through TS1. (That is, it seems to sample on the falling edge of TS1/rising edge of TS2). So, you need to stretch PCIT* at least one T-state.

 

 

 

(Screen shots from the CP-1600 Microprocessors User's Manual dated May 1975.)

Edited October 17, 2018 by intvnut

[intvnut]

BTW, I _finally_ got to watch the whole video. Great work!

 

I really found it fascinating that the CP1610 wasn't just a jumper wire but needed a live chip to extend the signal.

 

BTW, this is the exact quote I added to the reverse engineering doc:

 

 

Hardware note: The pulse from /PCIT is not quite long enough to trigger an interrupt on /INTR. It appears the pulse needs to be stretched by at least 40ns to reliably trigger an interrupt, based on experiments with an actual Intellivision.

 

40ns isn't that long. This really is just addressing a hold-time violation, I believe. To put it in perspective, at 1MHz, a full clock cycle is 1000ns. It's a case of "so close, yet so far."

 

decle and I also spent some time poring over the GIC1600 computer schematics to come to our conclusion. The GIC1600 actually stretches the PCIT* pulse a full 500ns. The GIC1600 used a CP1600 (not CP1610) and ran about twice as fast. Stretching 500ns means stretching for a full clock cycle. Experiments in a real system showed we needed a minimum stretch of around 40ns, though. Those experiments were on PAL. I don't know if they've been repeated on NTSC. (At one point I said it had been tested on NTSC in my reverse-eng doc, but now I think I added that in error.)

 

Massive kudos to decle for performing the actual experiments on real hardware—and heck, making a full reproduction of the dev system! The final PCIT* stretching circuit as I understand it, and as mentioned in the video, adds around 2 µsecs (2000ns) to be truly reliable with tons of margin. I personally think it's overkill, but you know what they say: You can never have too much overkill.

 

I'll let decle chime in with the details as he sees fit.

 

Also, here's a link to the CP-1600 Microprocessor User's Manual I mentioned earlier.

 

I need to publish an update to the reverse engineering doc. There's been a couple minor corrections. We also discovered that the debugger doesn't work with the stock KC 6502 EXEC ROM (at least not in the Computer III variant), and uncovered at least one more bug in the debugger which lead to the minor mishap seen in the video (as I described upthread).

[+Lathe26]

Regarding the KC Debugger cartridge...

 

https://www.youtube.com/watch?t=15&v=sLlu_RpElBs

[+Lathe26]

 

 

 

[+Lathe26]

While I do own an EPROM dumper/programmer, I am not likely going to dump these ROMs. Compared to the other cartridge known to exist, my chips have the same markings (version 5 F displayed when executed, CRCs of 32DF and ECA1). They very likely have identical code. However, if someone thinks that there is a chance that there is different code in these ROMs, I can be persuaded to dump them.

 

 

[+cmart604]

Wait. What?!?!? That's awesome! Congrats.

[intvnut]

Do you have the serial board or just the monitor ROM cartridge?

 

I don't think it's possible to interact with the monitor ROM w/out the serial adaptor, otherwise I'd suggest checking the checksums from within the monitor to see if they match there. Otherwise, I put the odds at 99.44% they're the same, modulo any bits that might have faded to '1' over the years.

[+Lathe26]

Do you have the serial board or just the monitor ROM cartridge?

 

I don't think it's possible to interact with the monitor ROM w/out the serial adaptor, otherwise I'd suggest checking the checksums from within the monitor to see if they match there. Otherwise, I put the odds at 99.44% they're the same, modulo any bits that might have faded to '1' over the years.

 

I only have the ROM cartridge, no serial adapter. I agree that there doesn't appear to be a way to interact without it. Pressing Ctrl+C twice didn't even work (standard KC mechanism to get back to a prompt). ... I'll have to see if I can get one...

 

I agree with your 99.44% assessment. The remaining 0.56% is blueberry filling.

[Walter Ives]

On 9/30/2018 at 5:13 AM, decle said:

We have converted Ron's Keyboard Component setup from a Blue Whale into a replica of a Mattel Black Whale development kit.

The Keyboard Component was nicknamed after the largest mammal because of its massive size—the name had nothing to do with color. Never heard speak of a black whale—sounds like a later embellishment added by a bearded bard weaving stories glorifying the days of yore.

[+DZ-Jay]

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

The Keyboard Component was nicknamed after the largest mammal because of its massive size—the name had nothing to do with color. Never heard speak of a black whale—sounds like a later embellishment added by a bearded bard weaving stories glorifying the days of yore.

I think somewhere in these here parts you'll find someone making a similar point.  I think we all took it to be just that, but the name stuck as a useful distinction between different iterations of the development environment.

 

    dZ.

Edited December 5, 2022 by DZ-Jay