Intellivision development, back in the day

[decle]

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:
 

http://www.gamotek.fr/wp-content/uploads/2016/10/NiceIdeas_1984_programmation_Fireman_Aubry.jpg

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-20230801.pdf

 

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

Edited September 20, 2023 by decle
Tried to embed the image of Patrick, it shows up fine in the preview, but get replaced with a link in the final version. Have i mentioned that the editor here is crap?

[+nanochess]

Now this an extensive research

 

Well done!

[carlsson]

I would look into which cross assemblers were available for S-100 bus and newer CP/M systems. It appears some other cross development was made on TRS-80 computers and alike, which likely were cheaper than getting a PDP-11. Of course Apple II systems may be relevant too.

 

Here is a search result from InfoWorld, though as late as May 1982. It mentions a manufacturer offering CP/M cross assemblers for National Semiconductors 70-series & COP400, Intel 8084 (sic?) & 8051, Zilog Z8, RCA 1802, AMI S2000 and Fairchild F8. While the GI CP1610 is not mentioned, it wouldn't surprise me if a similar product was available from another vendor.

[intvnut]

Some quick details I got from David Rolfe years ago (bubbled through my own potentially faulty memory):

 

The APh toolchain was written in BLISS, which was DEC's systems programming language. If you dig around long enough on Papa Intellivision, you can find the code that computes the Hamming code for encoding Keyboard Component tapes; this code looks like a variant of BLISS as well, confirming this.

 

The APh toolchain used a different syntax for CP1610 instructions, making them look a little more like PDP-11's instruction set. (Given how similar the two were, this makes a certain amount of sense.) For example, GI's documentation shows "MVI@ R4, R0" and "MVO@ R0, R4". In APh's syntax, that becomes "MOV @R4, R0" and "MOV R0, @R4". Arguably, APh's syntax is easier to follow. Also, in APh's syntax, a @@ in an instruction implied SDBD: "MOV @@R4, R0" means the same as "SDBD; MVI@ R4, R0" in GI's syntax.

 

David also mentioned that when he moved to Cheshire and wrote Beamrider for Activision, the toolchain they used there used GI's syntax, not APh's.

 

 

Other details from my dusty memory vaults:

 

Based on what we know of the ill-fated Magus-II board (offered and then rescinded in the late 90s by Intellivision Productions), it was fairly similar to the original Magus board, using a PCI card to provide the custom parallel interface. It would not surprise me to learn that they had used a custom card in their PDP's to talk to the original Magus.

 

 

Regarding using the Keyboard Component as a development tool: Elsewhere, I've seen mention that they had interfaced a standard serial port to the KC for development. The KC provides 16K x 10-bits of RAM mapped into the Intellivision address space. So, you could do a fair bit of development using that RAM, and then save your final compiles for the cartridge memory map until near the end. KC maps the 16K x 10-bit RAM at $8000 - $BFFF in the Intellivision address space.

 

The "two parallel peripheral I/O expansion ports" don't refer to "parallel ports" in the sense of a parallel printer cable. Rather, these were two cartridge ports at the back of the KC that connect to the 6502 processor bus. The Microsoft BASIC cartridge plugs into one of them. The other could be used for arbitrary peripheral expansion. They're parallel only in the sense that they provide a full bus, rather than providing expansion over daisychained serial links, like the VIC-20/C64.

[catsfolly]

This sounds pretty accurate, as far as I can remember.

 

I vaguely remember Mattel had this huge Intellivision Graphics development system. It looked like it was designed by someone with a relative in the "light-up push button" business, because it used light up push buttons for everything.

 

To create a new gram card, the user selected the card, and then pushed the buttons on an 8 by 8 push button grid to set the gram card pattern. Once they had defined a gram card, they put it in backtab by pressing the buttons on a 20 by 12 light-up button grid, with one button representing each backtab position. A monitor above the control panel showed the simulated Intellivision screen.

 

As the number of Game Developers at Mattel increased, it became harder and harder to get time on this graphics system (I think there was only one of them). So finally Eric Wells wrote his "Mr. Color" graphics tool that ran on the Intellivision, and most people used that to develop Intellivision graphics.

 

Catsfolly

[intvnut]

To create a new gram card, the user selected the card, and then pushed the buttons on an 8 by 8 push button grid to set the gram card pattern. Once they had defined a gram card, they put it in backtab by pressing the buttons on a 20 by 12 light-up button grid, with one button representing each backtab position. A monitor above the control panel showed the simulated Intellivision screen.

 

Ah yes, I had heard of the big push-button machine! I believe Karen Nugent spoke very briefly about it at one of the panels at CGE many moons ago ('99 or 2000 time frame). That was back when CGE still attracted a fairly large Intellivision / BSR panel, and I was just beginning to get into real trouble with Intellivision homebrewing.

 

It's sounds fascinating! I wonder if anyone has pictures.

 

I also wonder if any EPROMs are still floating around w/ Mr. Color on it. I'd love to see that in action too.

[freewheel]

Someday I'm gonna turn my development environment on its head, and make it all awkward and oldschool cool like this. I use old - practically ancient by today's standards - tools to do Inty development, and they're still orders of magnitude more powerful than anything even dreamed of back then.

 

Technological progress still blows my mind sometimes.

[intvnut]

Someday I'm gonna turn my development environment on its head, and make it all awkward and oldschool cool like this. I use old - practically ancient by today's standards - tools to do Inty development, and they're still orders of magnitude more powerful than anything even dreamed of back then.

 

Technological progress still blows my mind sometimes.

 

I wish you would have told me before I got rid of my ADDS Viewpoint terminal, AT&T 3B1 / PC 7300 UNIX PC and AT&T 620 terminal.

 

Harness the power of a 10MHz 68010, baby! Of course, mine may not have been old school enough, given I had the decked-out version with the 4MB RAM card and a 40MB MFM drive.

[decle]

Someday I'm gonna turn my development environment on its head, and make it all awkward and oldschool cool like this. I use old - practically ancient by today's standards - tools to do Inty development, and they're still orders of magnitude more powerful than anything even dreamed of back then.

 

Technological progress still blows my mind sometimes.

 

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

 

Which bizarrely was the first question that popped into my head on reading the name BLISS. A couple of mails further on Kyle explains it was all a coincidence.

 

This little interchange was on a thread started by some numpty from the UK who had Googled this little gem from David Rolfe's website:

 

http://home.earthlink.net/~davidrolfe/trivia.htm

 

So a couple of things. Firstly, there is nothing new under the sun, I must have known about the use of BLISS, despite never having heard about it before (I hate getting old). And second, like you freewheel I'd love to have an authentic development system running on a PDP-11. It seems to me an ideal first task for it would be compiling David's example.

 

decle

[catsfolly]

Well, to tell you the truth, working on a PDP-11 with all my files on an 8 inch floppy disk in a single directory wasn't BLISS for me! I don't miss it at all.

 

But, it would be fun if someone could find or recreate all the include files necessary to make exec based games with the modern tool chain. It would be interesting to try and write a "modern" exec based game...

 

 

Catsfolly

[+DZ-Jay]

This topic is fascinating to me, and it is indeed one of the first questions I ask to someone from "back in the day." Thanks, decle, for doing the research and compilation of information, and for everyone who's added more details.

 

-dZ.

[mr_me]

My understanding is that the Andromedas that Keith was referring to were PDP-11 clones. Keith worked at Mattel and Kimo worked at APh and they likely had different systems. I heard something about Mattel not wanting to pay for the good stuff that APh had. How many PDP-11s would APh have had? One?

[decle]

My understanding is that the Andromedas that Keith was referring to were PDP-11 clones. Keith worked at Mattel and Kimo worked at APh and they likely had different systems. I heard something about Mattel not wanting to pay for the good stuff that APh had. How many PDP-11s would APh have had? One?

 

Interesting. Found a couple more references, so it seems plausible that we are talking about Andromeda Systems Inc, who it seems were flogging both DEC cards and DEC derived systems.

 

With regard to the number of machines, I agree. Keith's description is at odds with David's podcast interview where he describes APh as a micro business. I had assumed they were talking about different times, but they could as easily be talking about different locations (or both).

[mr_me]

APh in Pasadena was run out of someone's house in 1977. By the summer of 1978 they must have got an office as they had a half dozen programmers working on Intellivision games.

 

Initially, 1980 or 1981, Mattel programmers went to the APh office to program Intellivision. I think by 1982, Mattel quickly ramped up their staff and had dozens and dozens of programmers and the systems to support them (at their office in Hawthorne).

 

Edit: And in 1982 most Intellivision programmers at APh moved to Cheshire Engineering or Atari.

Edited November 18, 2016 by mr_me

[intvnut]

Going back to the earlier comments regarding parallel ports: The Papa Intellivision site does show what the parallel interface adaptor looked like for the Keyboard Component Printer. See the bottom of this page.

 

Also, I spent a couple hours Friday evening and worked out the device service routines in the KC EXEC. It appears the unit supported 1 parallel output port and up to 3 MC6850-like serial devices. While I don't know that they were MC6850s, I did compare the code's actions against the MC6850 datasheet and MAME emulation, and the driver is consistent with MC6850. Also the MC6850 was under consideration for other peripherals mentioned at Papa Intellivision. There's no indication what baud rate was supported, though; no BRG setup was apparent in this code sequence. The only thing I see is that they set the baud divider for div-by-16, which is pretty standard.

 

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. Here's just the portion showing the MC6850 and parallel I/O driver. The parallel I/O is really simple: Just write bytes to a specific location, and it handles the data strobe, etc. A separate readable location returns interrupt status (~ACK or ~BUSY) in bit 7, and has a writable interrupt enable on bit 5.

;;=============================================================================

; Data from $DCB5 to $DCBC (8 bytes)  JUMP TABLE
DCB5  .byte $BD, $DC    ; DCBD
DCB7  .byte $C8, $DC    ; DCC8
DCB9  .byte $D3, $DC    ; DCD3
DCBB  .byte $DE, $DC    ; DCDE 

DCBD  A9 00     LDA #$00    ; \_ Reset?
DCBF  8D FE B7  STA $B7FE   ; /
DCC2  AD FE B7  LDA $B7FE
DCC5  29 E0     AND #$E0
DCC7  60        RTS 

DCC8  A9 03     LDA #$03    ; \_ Reset 6850
DCCA  8D FC B7  STA $B7FC   ; /
DCCD  A9 F3     LDA #$F3    ; \_ Check IRQ, Parity Err, Overrun, Framing Err, 
DCCF  2D FC B7  AND $B7FC   ; /  Transmit Empty, Receive Full flags
DCD2  60        RTS 

DCD3  A9 03     LDA #$03    ; \_ Reset 6850
DCD5  8D FA B7  STA $B7FA   ; /
DCD8  A9 F3     LDA #$F3    ; \_ Check IRQ, Parity Err, Overrun, Framing Err, 
DCDA  2D FA B7  AND $B7FA   ; /  Transmit Empty, Receive Full flags
DCDD  60        RTS 

DCDE  A9 03     LDA #$03    ; \_ Reset 6850
DCE0  8D F8 B7  STA $B7F8   ; /
DCE3  A9 F3     LDA #$F3    ; \_ Check IRQ, Parity Err, Overrun, Framing Err, 
DCE5  2D F8 B7  AND $B7F8   ; /  Transmit Empty, Receive Full flags
DCE8  60        RTS 

; Device Service Routine (DSR) records
DCE9  .byte $F1, $DC    ; DCF1  DSR #0  Printer
DCEB  .byte $08, $DD    ; DD08  DSR #1  Serial 0 (6850)
DCED  .byte $20, $DD    ; DD20  DSR #2  Serial 1 (6850)
DCEF  .byte $38, $DD    ; DD38  DSR #3  Serial 2 (6850)

; DSR #0:
DCF1  .byte $00                 ; Flags:  None
DCF2  .byte $0A                 ; Offset to handler stub?
DCF3  .byte $00, $00            ; RX FIFO addr:     NULL
DCF5  .byte $60, $BE            ; TX FIFO addr:     $BE60
DCF7  .byte $FE, $B7            ; Periph address:   $B7FE
DCF9  .byte $65, $DD            ; Handler address:  $DD65
DCFB  .byte $00, $00            ; 
DCFD  .byte $08                 ; TX FIFO depth 
DCFE  .byte $00                 ; DSR #0?
DCFF  .byte $AD, $FE, $B7       ; LDA $B7FE     ; \
DD02  .byte $29, $80            ; AND #$80      ;  |- Handler stub
DD04  .byte $D0                 ; BNE ...?      ; /

DD06  4C CD DD  JMP $DDCD       ; Initialize parallel port

; DSR #1:
DD08  .byte $95                 ; Flags:  Int enable; 8-N-1; Div-by-16
DD09  .byte $0B                 ; Offset to handler stub?
DD0A  .byte $A0, $BE            ; RX FIFO address:  $BEA0
DD0C  .byte $E0, $BE            ; TX FIFO address:  $BEE0
DD0E  .byte $FC, $B7            ; Periph address:   $B7FC
DD10  .byte $50, $DD            ; Handler address:  $DD50
DD12  .byte $00, $00            ;
DD14  .byte $08, $08            ; RX, TX FIFO depths
DD16  .byte $01                 ; DSR #1?
DD17  .byte $AD, $FC, $B7       ; LDA $B7FC     ; \
DD1A  .byte $29, $80            ; AND #$80      ;  |- Handler stub
DD1C  .byte $D0                 ; BNE ...?      ; /

DD1D  4C C1 DD  JMP $DDC1       ; Initialize 6850

; DSR #2:
DD20  .byte $95                 ; Flags:  Int enable; 8-N-1; Div-by-16
DD21  .byte $0B                 ; Offset to handler stub?
DD22  .byte $20, $BF            ; RX FIFO address:  $BF20
DD24  .byte $60, $BF            ; TX FIFO address:  $BF60
DD26  .byte $FA, $B7            ; Periph address:   $B7FA
DD28  .byte $50, $DD            ; Handler address:  $DD50
DD2A  .byte $00, $00            ; 
DD2C  .byte $08, $08            ; RX, TX FIFO depths
DD2E  .byte $02                 ; DSR #2?
DD2F  .byte $AD, $FA, $B7       ; LDA $B7FA     ; \
DD32  .byte $29, $80            ; AND #$80      ;  |- Handler stub
DD34  .byte $D0                 ; BNE ...?      ; /

DD35  4C C1 DD  JMP $DDC1       ; Initialize 6850

; DSR #3:
DD38  .byte $95                 ; Flags:  Int enable; 8-N-1; Div-by-16
DD39  .byte $0B                 ; Offset to handler stub?
DD3A  .byte $A0, $BF            ; RX FIFO address:  $BFA0
DD3C  .byte $E0, $BF            ; TX FIFO address:  $BFE0
DD3E  .byte $F8, $B7            ; Periph address:   $B7F8
DD40  .byte $50, $DD            ; Handler address:  $DD50
DD42  .byte $00, $00            ;
DD44  .byte $08, $08            ; RX, TX FIFO depths
DD46  .byte $03                 ; DSR #3?
DD47  .byte $AD, $F8, $B7       ; LDA $B7F8     ; \
DD4A  .byte $29, $80            ; AND #$80      ;  |- Handler stub
DD4C  .byte $D0                 ; BNE ...?      ; /

DD4D  4C C1 DD  JMP $DDC1       ; Initialize 6850

; This jump table appears reachable from the code unpacked above (?)

; Handler dispatchs for DSR #1, #2, #3:
DD50  4C 71 DD  JMP $DD71       ; RX: 6850 receive
DD53  4C 92 DD  JMP $DD92       ; Update settings
DD56  4C 9D DD  JMP $DD9D       ; TX: Send character
DD59  4C A7 DD  JMP $DDA7       ; TX: Enable TX interrupt
DD5C  4C AE DD  JMP $DDAE       ; RX: Disable RX interrupt
DD5F  4C B5 DD  JMP $DDB5       ; RX: Receive character
DD62  4C BA DD  JMP $DDBA       ; RX: Enable RX interrupt

; Handler dispatches for DSR #0:
DD65  4C 8F DD  JMP $DD8F       ; RX: No operation
DD68  4C 92 DD  JMP $DD92       ; Update settings
DD6B  4C 9D DD  JMP $DD9D       ; TX: Send character
DD6E  4C A7 DD  JMP $DDA7       ; TX: Strobe character (?)

; TX/RX 6850
DD71  BD 40 03  LDA $0340,X     ; \_ If inactive, skip (?)
DD74  10 19     BPL $DD8F       ; /
DD76  A0 00     LDY #$00        ; \_ Read status register
DD78  B1 FB     LDA ($FB),Y     ; / 
DD7A  6A        ROR A           ; Receive register full?
DD7B  90 0F     BCC $DD8C       ; No: Check TRDE for intr. reason
DD7D  29 10     AND #$10        ; Overrun?
DD7F  F0 0F     BEQ $DD90       ; Yes: Return w/ error
DD81  A0 01     LDY #$01        ; \_ Receive a byte
DD83  B1 FB     LDA ($FB),Y     ; /
DD85  A9 40     LDA #$40        ; \
DD87  85 90     STA $90         ;  |- C=0: No error, V=1: Interrupt handled
DD89  24 90     BIT $90         ; /
DD8B  60        RTS             ; Return

DD8C  6A        ROR A           ; Transmit register empty?
DD8D  90 F6     BCC $DD85       ; Yes:  That's reason for the interrupt
DD8F  18        CLC             ; C = 0: No error
DD90  B8        CLV             ; V = 0: Not reason for the interrupt
DD91  60        RTS             ;

DD92  BD 40 03  LDA $0340,X     ; \
DD95  29 DF     AND #$DF        ;  |-- Disable TX interrupt
DD97  9D 40 03  STA $0340,X     ; /
DD9A  4C FA 00  JMP $00FA       ; Write updated config byte

DD9D  A5 90     LDA $90         ; Get character to send
DD9F  E6 FB     INC $FB         ; \
DDA1  20 FA 00  JSR $00FA       ;  |- Send it by writing to second address
DDA4  C6 FB     DEC $FB         ; /   
DDA6  60        RTS             ; 

DDA7  BD 40 03  LDA $0340,X     ; \_ Enable TX interrupt
DDAA  09 20     ORA #$20        ; /
DDAC  D0 E9     BNE $DD97       ; (unconditional)

DDAE  BD 40 03  LDA $0340,X     ; \
DDB1  29 7F     AND #$7F        ;  |- Disable RX interrupt 
DDB3  D0 E2     BNE $DD97       ; /   (unconditional)

DDB5  A0 01     LDY #$01        ; \_ Receive character
DDB7  B1 FB     LDA ($FB),Y     ; /
DDB9  60        RTS             ;

DDBA  BD 40 03  LDA $0340,X     ; \_ Enable RX interrupt
DDBD  09 80     ORA #$80        ; /
DDBF  D0 D6     BNE $DD97       ; (unconditional)

; Initialize 6850
DDC1  A0 00     LDY #$00        ;
DDC3  A9 03     LDA #$03        ;  Master reset
DDC5  91 FB     STA ($FB),Y     ;
DDC7  BD 40 03  LDA $0340,X     ;  Init baud rate, etc.
DDCA  91 FB     STA ($FB),Y     ;
DDCC  60        RTS 

; Initialize parallel port
DDCD  A9 00     LDA #$00        ; \_ Reset printer: send 0x00 character
DDCF  8D FF B7  STA $B7FF       ; /
DDD2  AD FE B7  LDA $B7FE       ; \   Read status byte
DDD5  29 10     AND #$10        ;  |- Bit 4 = printer type detect?
DDD7  D0 0A     BNE $DDE3       ; /   If 0, need to send add'l characters.
DDD9  A9 1E     LDA #$1E        ; \_ Send ?? (0x1E = ASCII Record Separator)
DDDB  8D FF B7  STA $B7FF       ; /
DDDE  A9 0D     LDA #$0D        ; \_ Send Newline character
DDE0  8D FF B7  STA $B7FF       ; /
DDE3  60        RTS             ; 

[decle]

 

Going back to the earlier comments regarding parallel ports: The Papa Intellivision site does show what the parallel interface adaptor looked like for the Keyboard Component Printer. See the bottom of this page.

 

Also, I spent a couple hours Friday evening and worked out the device service routines in the KC EXEC. It appears the unit supported 1 parallel output port and up to 3 MC6850-like serial devices. While I don't know that they were MC6850s, I did compare the code's actions against the MC6850 datasheet and MAME emulation, and the driver is consistent with MC6850. Also the MC6850 was under consideration for other peripherals mentioned at Papa Intellivision. There's no indication what baud rate was supported, though; no BRG setup was apparent in this code sequence. The only thing I see is that they set the baud divider for div-by-16, which is pretty standard.

 

Wow, impressive work. So if I'm following this correctly, Mattel wrote the low level driver stubs in for one parallel device and up to 3 serials, but not the specifics of the devices they were connecting to? So they would have had to add further code to actually interact with the printer or modem for example? If this is correct I wonder why they bothered with the stubs themselves, or made them specifically serial / parallel. I wonder if the tape drive one of the serial devices or if that is controlled by some other mechanism.

[intvnut]

 

Wow, impressive work. So if I'm following this correctly, Mattel wrote the low level driver stubs in for one parallel device and up to 3 serials, but not the specifics of the devices they were connecting to? So they would have had to add further code to actually interact with the printer or modem for example? If this is correct I wonder why they bothered with the stubs themselves, or made them specifically serial / parallel. I wonder if the tape drive one of the serial devices or if that is controlled by some other mechanism.

 

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.

 

I don't know what, offhand, will cause BASIC or other software to communicate with the three COM ports. But, it does appear if you interface a 6850 at the appropriate addresses, it should "just work."

 

The cassette drive has its own dedicated driver. Frank and I have spent a considerable amount of time (Frank more than I) reverse engineering the tape drive and the software stack associated with it. It's really quite an impressive bit of work. It's not a simple FSK modem accessed via a serial port, like, say, a Kansas City Standard old-school tape. Rather, it's a block-oriented, hardware controlled / hardware addressed dual-speed machine, with all sorts of interesting capabilities.

 

Frank has a version of MAME that actually supports the tape drive. He's working on bringing that to a recent version of MAME. From one of Frank's comments on Facebook:

 

I still have a 2002 version of MESS which I enhanced to support loading of BASIC programs. I am merging those changes back into the current version of MAME. At that time I only barely got Family Budgeting running...that still works...

[intvnut]

If this is correct I wonder why they bothered with the stubs themselves, or made them specifically serial / parallel.

 

 

BTW, perhaps you're reading too much into my "stub" comments: The Keyboard EXEC sets up a series of records in RAM for handling peripheral interrupts that are actually directly executed when a peripheral interrupt arrives. By default, these records are filled with JMPs to a generic "ignore" handler. When you open a COM port or LPT port, the firmware copies the appropriate 6-byte "stub" into the corresponding slot in RAM, and patches in the missing byte on the BNE that terminates the stub.

 

Stub was perhaps not the best choice of word here.

 

As for software to make use of these peripherals, it would need to ask to open the device and then make use of the FIFO. In the case of the parallel port, BASIC already knows how to use it. I haven't dug into the EXEC calls BASIC makes to make this happen. I imagine anything that uses a serial port makes similar calls.

 

In my mind, this isn't much different than DOS providing basic support for LPT1:, COM1:, COM2:, etc. out of the box, whether or not the ports where physically present, or software is installed that wants to make use of it. It's totally appropriate for the EXEC to provide standardized access to these ports if they're meant to be standard ports across all keyboards, when the port is present. The total amount of code in the Kbd EXEC is actually pretty small, and saves having an add-in ROM on the serial adaptor or parallel adaptor.

Edited November 21, 2016 by intvnut

[mr_me]

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. APh had expertise in the early days of microprocessors and they had the idea of using a larger computer and built compilers to create the assembly; ideas that were developed at CalTech. The compiler tools could be tweaked for different target processors.

 

----------------------------------

It's nice to see that emulating the Keyboard Component is still being worked on. Not sure how others feel but I would like to see it fully emulated. Looks like the Keyboard Component cartridge port is emulated and the Microsoft Basic cartridge is dumped. Looks like the tape drive is at least partially emulated and "Family Budgeting" has been converted to some sort of tape image. I imagine if someone wants to see the Keyboard Component Basic software (eg. Crosswords, Family Budgeting, Geography Challenge) running, would it not work in any Microsoft Basic compatible interpreter. From what I understand the KC Basic only used standard ASCII characters for graphics and very little, if anything unique to the KC. Perhaps it saved data to tape.

 

With the Mame I have, the Keyboard Component emulator can load files to three different cart slots. The first slot is for the Intellivision cartridge slot. I'm guessing the other two are for the two KC i/o ports, and if I had a Basic ROM file it would load up Basic? I don't see anything about tape image but I'm guessing emulating the tape drive might be more complicated.

[carlsson]

In case the Keyboard Component stored its programs according to the Kansas City standard, possibly those could be loaded on other systems as well.

[intvnut]

In case the Keyboard Component stored its programs according to the Kansas City standard, possibly those could be loaded on other systems as well.

 

As I mentioned above, it's very much NOT the Kansas City standard. It's a block addressed, random-access custom format, with heavy error correction coding, support for fast-seek, synchronization across 2 digital and 2 analog tracks... I think it has more in common with minicomputer / mainframe tapes at that point than it does with the "FSK modem on tape" style Kansas City format.

 

You can actually see a description of the block format on Papa Intellivision. Look at the last few pages of this PDF: http://papaintellivision.com/pdfs/CCF10232011_00020.pdf (Note: Frank and I had worked out the format before these docs were released. It's interesting to see the documents after the fact, though.)

 

 

The ECS is closer to the KCS, with some notable differences:

• All its tones are 2x the KCS (2400Hz/4800Hz instead of 1200Hz/2400Hz)
• The ECS includes a parity bit, while KCS does not.

Of course, the actual contents of the tape are specific to the ECS and whatever programs are on there, so I doubt they'd be interchangeable with any other systems either.

[intvnut]

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. APh had expertise in the early days of microprocessors and they had the idea of using a larger computer and built compilers to create the assembly; ideas that were developed at CalTech. The compiler tools could be tweaked for different target processors.

 

I'll have to listen to the interview. It sounds like a great listen.

 

In my previous chats with David, it sounded like all of the coding for the Intellivision was in assembly, but they had built a fairly rich and capable macro assembler to make it seem more like a high-level language. I remember him saying that that tool set was retargetable, and is a big part of the reason Mattel used a different assembly syntax than the one published by General Instrument. The CP-1600 looks an awful lot like a simplified PDP-11, interestingly enough, so if you were at all versed in PDP-11, the CP-1600 is really easy to pick up. Mattel's syntax is, unsurprisingly, closer to PDP-11 than GI's.

 

The only game written in C, IIRC, was Utopia for the Aquarius. One of Steve Roney's videos on Intellivision Lives! (I think) briefly touched on that. I suppose there were other compiled languages (Pascal was popular; FORTRAN was around too, but a poor fit).

 

 

It's nice to see that emulating the Keyboard Component is still being worked on. Not sure how others feel but I would like to see it fully emulated.

 

I too would love to see it emulated. I'm really glad Frank's got the skills and the time to make it happen in MAME. Maybe some day it'll come into jzIntv, but I'll be honest, it's not been a priority for me when I have so many other fish to fry. It's been fun working with Frank, though, trying to understand how this beast is put together.

 

 

Looks like the Keyboard Component cartridge port is emulated and the Microsoft Basic cartridge is dumped. Looks like the tape drive is at least partially emulated and "Family Budgeting" has been converted to some sort of tape image. I imagine if someone wants to see the Keyboard Component Basic software (eg. Crosswords, Family Budgeting, Geography Challenge) running, would it not work in any Microsoft Basic compatible interpreter. From what I understand the KC Basic only used standard ASCII characters for graphics and very little, if anything unique to the KC. Perhaps it saved data to tape.

 

Frank's dumped and decoded several tapes. The error correction built into the tapes has definitely helped reconstructing some of the images.

 

Michael Steil has incorporated Intellivision Microsoft BASIC into his grand unified Microsoft 6502 BASIC. (Google Cache link, as the site's often slow.) From his tree, you can build several related versions of Microsoft BASIC for the 6502, including the Intellivision. From his work, we now know roughly where Mattel's version fits in the Microsoft family tree, and what extensions and changes Mattel added to the BASIC.

 

There are a few extensions to Microsoft BASIC for saving and loading data on cassette, playing and recording audio on cassette, and primitives for sending data to the printer. From Michael Steil's page: "Intellivision BASIC replaced LOAD and SAVE by PLOD, PSAV, VLOD, VSAV and SLOD, PRT, GETC and VER were added, and PEEK, POKE and WAIT were removed." With a little work, I imagine those portions could be adapted for other systems, such as the Apple ][. The VLOD/VSAV might be hard to mimic, though. I'm not sure what SLOD did; I'll have to look.

 

The Keyboard Component used ASCII plus some add'l tiles for simple block-oriented graphics, similar to what the TRS-80 Model 1/Model 3 offered for its low-res block-oriented graphic mode. It didn't offer the PSET-style primitives the TRS-80 did, however. The KC also has some "macro" characters that expand single characters to full strings. One macro prints a low-res Intellivision logo—the same one that appears on the KC bootup screen (below). I don't remember if those can be triggered from BASIC, or if they require a 10-bit value to be sent from the Master Component. Those "macro" characters are used a number of places in the KC EXEC software, though, for menus and so forth.

 

 

I'm not sure how complete Frank's tape emulation is. I don't know, for example, if he's worked out how to synchronize the audio data with the digital framing blocks, which will be needed for programs like Conversational French.

 

I imagine once he gets it resync'd with the latest MAME tree, it'll go out for the world to see. He's posted some of his progress on his Facebook page, if you look him up.

 

With the Mame I have, the Keyboard Component emulator can load files to three different cart slots. The first slot is for the Intellivision cartridge slot. I'm guessing the other two are for the two KC i/o ports, and if I had a Basic ROM file it would load up Basic? I don't see anything about tape image but I'm guessing emulating the tape drive might be more complicated.

 

That's right on the 3 cartridge ports. One is the Master Component cartridge port, and the other two should be the two cartridge/expansion ports on the back of the KC. If you have the BASIC ROM plugged into one of the KC ports (it shouldn't matter which), then it should give you the option to fire up Microsoft BASIC.

 

For the tape support, I'm not sure how Frank's implementing that actually, and how the user will "insert" and "eject" tapes. But, I'm sure he'll post instructions once it's working and pushed out to MAME.

Edited November 24, 2016 by intvnut

[mr_me]

Okay, so KC Basic was one of the more customised Microsoft Basics. And the logo graphics is built from extended ascii characters. Mattel's "Intro. to Basic" guide talks about printing chr$(27) plus two other codes to get at the 64 graphic characters, 36 character strings, and a bunch of other stuff for the screen and cursor. You can turn off the beeps/bloops with "print chr$(27);chr$(31);chr$(72)". They took out the peek/poke commands; that might have let someone hack a full cp1610 program, maybe? I thought I read somehwere (maybe papaintellivision.com) that Mattel planned a second version of KC Basic that would allow programming Intellivision colour graphics.

 

From the guide, the slod command loads a basic program from the prerecorded track of a tape; plod/psave must use the rewritable track of a tape; vlod/vsav is for variable data. If you look at the instructions for Crosswords for example, it will say to type "slod 1" and "run".

[intvnut]

Actually, I'm pretty sure VLOD/VSAV is "voice", meaning the audio track.

EDIT: I stand corrected. VLOD/VSAV is for saving/loading variables to tape.

Edited November 24, 2016 by intvnut

[+DZ-Jay]

 

I'll have to listen to the interview. It sounds like a great listen.

 

In my previous chats with David, it sounded like all of the coding for the Intellivision was in assembly, but they had built a fairly rich and capable macro assembler to make it seem more like a high-level language.

 

I think what he meant was the idea of doing the op-code assembly by hand rather than using a cross-compiler/cross-assembler from a mini-computer. I could see why APh could laugh that off when they had such sophisticated tools at the time.

 

-dZ.