Intellivision development, back in the day

[intvnut]

I'm thinking the utility would make something that's useable on a cartridge, the same way the intellivoice cartridges have speech on them. Maybe it just used the GI allophones.

 

Do you happen to have a link to the specific scan, or at least the name of the file? I think I've seen this particular memo, but I've spent so much time looking through the PapaIntellivision memos recently that I'd prefer a direct pointer.

 

It wouldn't be that difficult to rewrite the CTS0256 text-to-speech algorithm for CP1600. It's just the US Naval algorithm, IIRC, which isn't terribly difficult. Mockingboard also used this algorithm as I recall.

 

 

I think the voice actor who did the stuff inside the intellivoice also did some of the speech on the space spartans cartridge.

 

That's quite possible. That said, the Intellivoice BSR page doesn't say who did those voices, so we still don't know.

 

 

CREDITS: All Intellivoice games had scripts by the Creative Media Department (Joey Silvian, Brad Geagley, Glenn Stello) to develop distinct personalities for the voices. Voices were recorded at Fred Jones Recording Services in Hollywood, directed by Joey Silvian. International voices were recorded at studios in France and Italy and smuggled back into the U.S. on tapes marked "blank" to avoid paying duty (really). Voice files were digitized, edited and optimized by the Voice Department (Ron Carlson, Patrick Jost, Deidre Cimarusti, Sandy Disner, Lynn [Liliedahl] Fordham, Irene Pfannkuch). All Intellivoice programs included voice routines written by Ron Surratt and Steve Roney.

 

...

 

 

INTELLIVOICE CARTRIDGE [#3416]

Design/Program/Graphics: Bill Fisher & Steve Roney, Mike Minkoff, Brian Dougherty

Sound: Bill Fisher, Bill Goodrich

Voice of the Computer: Keri Tombazian

see also Intellivoice credits

 

...

It's possible that "Mr. Mattel Voice" is one of the people listed in the first set of credits; however, they're not called out explicitly as a voice actor.

[mr_me]

It's the second last listed file here.

http://decle.org.uk/intellivision/bsr/mattel/bulletins/

[decle]

Hi everyone,

 

Just one update today, but it's a really interesting one.  On page 26, Section 5.5 has been expanded to include an overview and pictures of the PlayCable based development system put together by Joe Jacobs and Dennis Clark.  Here you go:

 

intellivisionDevelopmentBackInTheDay-20190727.pdf

 

And a bit of a teaser:

 

 

 

Enjoy!

 

decle

 

Edited July 27, 2019 by decle

[mr_me]

That's great, and original photos too!  So they must have used their own personal PDP11 system to develop Bumpnjump.  But it's a 16k cartridge, did they still use their playcable hack.  Did Mattel provide them any software tools, equipment?

[+nanochess]

Cool as always! ? Well done! ??

 

[+Lathe26]

On 11/14/2016 at 1:54 PM, decle said:

Hi all,

For some time, I have had an interest in the methods and tools used by Intellivision developers in the 70s and 80s. As a consequence, the following picture shared by scalpel as part of an interview with Patrick Aubry working on an Intellivision game piqued my interest:



This prompted me to see what else the interwebnets could tell us about how things were done back in the day. The results of this research are summarised in the following document (PDF):

 

intellivisionDevelopmentBackInTheDay-20190727.pdf 1.99 MB · 4 downloads

 

I hope it might be of some interest. If you have any additions or corrections please let me know, either on this thread, or via PM.


Thanks

decle

It's probably been answered but I couldn't find it in this thread: do we know what game is he programming in the background?

[+Lathe26]

Regarding the PlayCable section, nice work!

 

Some (small) comments are:

• Might be good to add a photo of the entire top-side of the PlayCable daughter board (more of what is shown in Figure 17).
• Do we know what the serial parameters are (8N1 9600 baud, etc)?  Maybe that's too technical for this document.
• Can we say anything about the protocol?  Again, maybe this is too technical for this document.

[intvnut]

46 minutes ago, Lathe26 said:

It's probably been answered but I couldn't find it in this thread: do we know what game is he programming in the background? 

IIRC, we speculate it's Anteater.

5 minutes ago, Lathe26 said:

 

• Do we know what the serial parameters are (8N1 9600 baud, etc)?  Maybe that's too technical for this document.
• Can we say anything about the protocol?  Again, maybe this is too technical for this document.

I'm pretty certain we have answers to these questions.  It's up to decle whether to include it in this document or a separate one (or both).

[mr_me]

1 hour ago, Lathe26 said:

It's probably been answered but I couldn't find it in this thread: do we know what game is he programming in the background?

Fireman

http://www.gamotek.fr/nice-ideas-storyboards-3/

[decle]

Hey all,

 

After a long hiatus I have an update of the development tools doc.  Hopefully it has some new and interesting bits and pieces.

 

 

Get it while it's hot:

intellivisionDevelopmentBackInTheDay-20200612.pdf

 

This time the big ticket items are:

• Lots of Datawidget goodness... (p8-p16)
  • First contemporary image of (half) a Datawidget courtesy of JoeZ and Twitter
  • First modern images of both the exterior and interior of a Datawidget
  • More details of the Datawidget, Dopey and Crosspatch implementation
• Contemporary picture of the Mattel Graphics Development System and overview (p19)
• Initial overview of MERT, GERT and MODIT, the tools used to create Keyboard Component tapes (p6-p8)
• Summary of a previously unknown Magus debugger written by Bijan Jalali in 1982 (p21)
• More details on the Magus including its origins, the existence of an 8K version and common complaints from 1982 (p23-p25)
• Addition of a comparison of the Mattel development / debugging systems including notes written by Keith Robinson for an updated YFTE (p30-32)
• Images and brief comparison of two additional T-Card designs (p33-p35)

 

On 7/28/2019 at 10:51 PM, Lathe26 said:

• Might be good to add a photo of the entire top-side of the PlayCable daughter board (more of what is shown in Figure 17).

Ask and ye shall receive (after a long wait )

 

On 7/28/2019 at 10:51 PM, Lathe26 said:

• Do we know what the serial parameters are (8N1 9600 baud, etc)?  Maybe that's too technical for this document.
• Can we say anything about the protocol?  Again, maybe this is too technical for this document.

 

I think that some of this is covered in the latest PlayCable Technical Summary.  It looks as though the communications were run using 8E1 (8 bits, even parity, one stop bit).  From the pictures we have it's hard to tell whether the 13.98KHz baud rate of the PlayCable, which was derived from the Intellivision's 3.58MHz clock, was changed by Joe and Dennis (I carefully glossed over this point in the write up ).  Although 13.98KHz might be close enough to the standard 14.4KHz baud rate to work (<3% error), it doesn't seem to be a common speed and I don't think many cards of this era supported it.  Unfortunately, we don't know anything about the software protocol used for communication.  I live in hope that Joe Jacobs might provide us with a dump of the EPROM one day.  It would provide a great reverse engineering project and answer alot of questions.

 

Anyway, I think that's about it for this one.  As always all feedback and corrections are welcome.

 

 

Cheers

 

decle

 

 

Edited June 12, 2020 by decle

[intvnut]

22 hours ago, decle said:

After a long hiatus I have an update of the development tools doc.  Hopefully it has some new and interesting bits and pieces.

Having a read through it now.  Lots of good stuff in here.

 

One thing I didn't see highlighted in the text (or if it was, I missed it):  Keith's handwritten description of the downloaders/debuggers currently in use has the only contemporaneous confirmation of the code name Black Whale we've seen, as far as I know, and it was crammed in there as an edit:

 

 

I chuckled at jzIntv showing up in the debugger comparison.   FWIW, jzIntv doesn't have "run at address" as a separate command, but you can do "g7 addr" followed by "r" to get the same effect.  Think of it as RISC vs. CISC.   

 

From your doc, it sounds like PX1600 Crosspatch allowed source-level debugging.  That's probably worth a row in the debugger comparison table.

 

Something that's probably worth adding to the "Y adaptor" section:  There was an external power supply that goes with that to boost power to the unit when using the Y adaptor.  I don't know that all Y adaptors had one, but the one I had the opportunity to document did:

 

 

 

 

In case you're wondering about the Prio Mail box... I was using that as a "camera stand" for my phone in some of the shots.

 

Quote

Later, having moved offices to Los Gatos, Imagic migrated development from the PDP-11/23 to a DEC VAX-11/750 running BSD 4.1. It might also be inferred from Gary’s comments that Imagic had a bespoke hardware solution for testing.

 

There's a relevant blurb about Imagic's development environment on Intellivision Rocks! that I discovered the other day, while researching Keith's photo of the "momentum" lucite block.  (This hobby takes us strange directions sometimes, eh?)

 

Quote

Pat Ransil, Brian P. Dougherty and Gary Kato were all friends at the University of California at Berkeley. A few years after graduation, Pat was working at Intel when he received a call from Brian, who was then working at Mattel Electronics and putting together a new company to produce Intellivision games. He wanted Pat and Gary (then at Versatec) to be part of it. They agreed, becoming founders of Imagic.

The first task was building the needed Intellivision development tools. Pat programmed a graphics editor and software that controlled the development hardware.

Although Brian and fellow founder Dave Durran had worked at Mattel and knew the Intellivision operating system intimately, Imagic had to have independent technicians reverse engineer it. Only by carefully documenting the fact that its programmers could develop Intellivision games without using what Brian and Dave learned at Mattel would Imagic be able to fight legal accusations of stealing trade secrets.

After completing the development software, Pat tackled the game Atlantis.

 

The "graphics editor" and "software that controlled the development hardware" caught my eye.  Sounds like they did have some custom equipment of their own.  (Not surprising, really.)

 

And a side note:  The EXEC routine names decle uses in his document are names I picked for the EXEC routines when I wrote dis1600.  These are not the same as the names that appear in Your Friend The EXEC.  I am happy to provide the official EXEC names to replace my made-up names in a future revision.

 

[First Spear]

On 11/15/2016 at 2:02 AM, decle said:

 

Starting to follow the BLISS thread provided by Joe I found this message from way back when:

 

https://beta.groups.yahoo.com/neo/groups/intvprog/conversations/messages/984

 

[snip]

 

I tried to get at the intvprog stuff via archive.org and that page was not archived. Does anyone have anything saved from it?

https://web.archive.org/web/*/https://beta.groups.yahoo.com/neo/groups/intvprog/conversations/messages/984

 

[decle]

Hey all,

 

2022 brings a new version of the Intellivision development overview, you can download it here:

 

intellivisionDevelopmentBackInTheDay-20220101.pdf

 

This update focuses on two topics:

• The Magus, or should that be MEGAS.

• The tools put together by Joe Jacobs and Dennis Clark.

 

The details of the changes are...

• Magus / MEGAS information (p23-p27)
  • First images of a MEGAS board
  • Lots of technical details
  • Full circuit diagram of a 16K MEGAS
• More information on Joe Jacobs and Dennis Clarke's development tools (p42-p49)
  • PlayCable development kit and Vector board
  • Details of their software tools such as Foreground, Pick-A-Doodle and DISLX
  • Information regarding a cartridge reader created by Joe Jacobs

If you're interested in the work done by Joe and Dennis at Technology Associates, you might also want to have a look at both the write up of their story and the PlayCable Technical Summary.

 

Cheers

 

decle
 

[Walter Ives]

On 11/17/2016 at 6:29 AM, mr_me said:

How many PDP-11s would APh have had? One?

Yup. One per programmer. That includes the Mattel programmers seconded to APh. Except Mike and Rick shared a system when they were working together on Bowling.

 

WJI

[Walter Ives]

On 11/20/2016 at 11:18 AM, intvnut said:

There's no indication what baud rate was supported, though; no BRG setup was apparent in this code sequence.

Baud rates were either fixed or DIP switch settable, depending on the peripheral.

 

WJI

[Walter Ives]

On 11/20/2016 at 11:18 AM, intvnut said:

The KBD EXEC device I/O structure is fairly sophisticated, using a series of FIFOs managed by software, and a set of soft-plugged interrupt handler stubs (self modifying code, really) for the current set of active devices.

Had to be, given that the Keyboard Component monitors were hard-coded into ROMs and had to be able to accommodate unforeseen new peripherals.

 

WJI

[Walter Ives]

On 11/21/2016 at 11:19 AM, intvnut said:

The low level drivers interface to generic serial and parallel ports, not unlike LPT1:, COM1:, COM2:, and COM3: in a PC. The parallel port is indeed intended to be hooked to a printer. BASIC will print data to it when you use the PRT1 command, for example.

Well, the PC was a johnny-come-lately that didn't debut until August 1981, so more like LPTnn and TTYnn under TOPS-10 or LPn and TTn under RT-11.

 

WJI

[Walter Ives]

On 11/21/2016 at 11:19 AM, intvnut said:

The parallel port is indeed intended to be hooked to a printer. BASIC will print data to it when you use the PRT1 command, for example.

APh designed Keyboard Component interface cards to drive both 80-column dot-matrix printers and serial port Daisywheels.

 

WJI

[Walter Ives]

On 11/23/2016 at 11:21 AM, mr_me said:

I was just listening to Dave Rolfe's interview with the Intellivisionairies. He mentioned that with Mattel's first crack at programming Intellivision, someone tried to hand code the assembly; and how ridiculous that was.

According to D. Johnson, the only hand-assembled code was that written in December of 1977 for the closed-door showing of a running man in a closed room at Winter CES the next month. One person set up the system and wrote a simple 5-command version of Dopey that could examine, deposit, go and punch paper tapes, two others including Rolfe used that to enter their hand-assembled running-man code. By the time Mattel was ready to take the next step, APh had adapted its tool chain to accommodate the CP1600.

 

WJI

[Walter Ives]

On 11/26/2016 at 7:38 AM, mr_me said:

We know that in 1977, prior to APh involvement, Mattel was developing for the Intellivision in preparation for January CES. Don't know who that programmer was but I'm guessing they used a GI development system and assembler, likely on a GI cp1600 based computer.

APh's involvement began in December, 1975. You have undoubtedly read elsewhere that APh brought the GI chipset to Chang's attention. It was APh personnel who prepared the Winter CES demo in the secret windowless room at Mattel headquarters in 1977. GI had supplied a TTL emulator built into a chassis similar in size to the one shown in this EE Times article and mounted in a mini-rack.

The APh engineer sent to survey the situation found a setup that had been unpacked but was otherwise "doornail dead." He plugged it in and spent a couple of days preparing a minimal development environment by hooking up a Teletype model ASR-33 to it, writing and hand-assembling a minimal version of APh's debugger and writing and hand-assembling a minimal interrupt driven program to establish that the system could display background and objects and that the hand-controllers could be read. After that was in place, APh dispatched two programmers to the same room to write and hand-assemble the rudimentary demonstration program shown at CES.

 

WJI

[Walter Ives]

On 11/26/2016 at 7:38 AM, mr_me said:

We also know that Mattel was still programming Intellivision Football at that time.

APh had the only emulator. The Mattel programmer assigned to Football worked at APh two to three days a week. He was torpedoed by the fact that his management was clueless about the amount of work required to write a game and kept giving him other things to do in parallel.

 

WJI

[Walter Ives]

On 11/26/2016 at 8:09 AM, decle said:

The APh assembler is distinct and does not use the same syntax as the GI one. This can be seen by contrasting the MVI@ instruction formats in YFTE and the GI assember manual. The APh assembler uses MOV @source, destination, whereas the GI one uses MVI@ source, destination, much like the version of as1600 we use today. I believe that the reason for this is that not only was the APh solution a cross-assembler generating CP1600 machine code on a PDP-11, but unlike the GI solution it was also multi-target. By tweaking the parser and back-end of the assembler it could be used to generate code for different target processors.

Nope. The APh assemblers for some microprocessors supported both APh's and the manufacturers' syntaxes. If you listen to one of Rolfe's rants about the PULL mnemonic you'll understand that "real programmers" viewed many of the manufacturers' syntaxes as brain-damaged. (For those unfamiliar with the work of Jan Łukasiewicz, you don't "pull" something off a stack, you "pop" it off. Using the term "pull" in this context is like squeaking chalk on a chalkboard. It marks the microprocessor as having been designed by an unsophisticated rube from [insert name of your favorite backward village here] and robs it of credibility.)

 

The assembly language syntaxes of most microprocessors of the day were specified by engineers that hadn't personally done much programming. For the MOV instruction in your example, the CPU designer might have considered loads fundamentally different from stores and register moves fundamentally different than indirect ones. For him the I@ or O@ was conceptually part of the op code. Programmers, on the other hand, especially programmers of more capable machines, don't give a rat's a** about the details of the implementation but feel that the addressing mode is naturally associated with the argument rather than the operation. The CP16000, successor to the CP-1600, supported more addressing modes and the APh syntax was more readily extensible to support that than the GI syntax (e.g.: MOVB   @R2, @R3+ as opposed to … what? MOVIOB@@+   R2, R3?).

 

WJI

[Walter Ives]

On 11/26/2016 at 8:09 AM, decle said:

Again, GI had a software simulation of the CP1600, which presumably could have been extended to model a full Intellivision.

Maybe if you waited a decade for processor speeds to improve sufficiently to make that practical. Then again the GI simulator was written in FORTRAN, so maybe two decades.

 

WJI

[Walter Ives]

On 11/27/2016 at 9:05 AM, mr_me said:

Could that ram emulator, it mentions being built by APh, refer to a cartridge emulator? That document mentions APh testing on the ram emulator prior to programming the proms.

Nope. It refers to an AY-3-9600 System RAM emulator with a 40 conductor ribbon cable that could be plugged directly into the corresponding socket of a production Master Component.

 

WJI

[Walter Ives]

On 11/27/2016 at 9:05 AM, mr_me said:

So prior to Oct 1978 there was only one STIC? APh had four or five programmers working on games that summer; they must have shared one test system. I guess Mattel may have stopped attempting any Intellivision game development in 1978 since they gave the only stic emulator to APh.

Yup. But each programmer had his own PDP-11 for editing and assembly, which is what took the most time. The PDP-11's were networked so the programs could be sent directly to the emulator for debugging.

 

WJI