Intellivision development, back in the day

[intvnut]

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.

 

I don't think anyone had suggested direct machine coding / hand assembly, at least on the GI side. GI's tools, though, sounded somewhat primitive compared to the full macro assembler setup that APh had. GI's own docs definitely describe having assemblers (both online and cross-assembler), including even their oldest docs from 1974 and 1975.

 

http://bitsavers.trailing-edge.com/pdf/gi/CP1600/CP-1600_Cross_Assembler_Simulator_Users_Manual_Nov74.pdf

http://bitsavers.trailing-edge.com/pdf/gi/CP1600/CP-1600_Microprocessor_Users_Manual_May75.pdf

http://bitsavers.trailing-edge.com/pdf/gi/CP1600/GIC1600_Microcomputer_Users_Manuals_Sep75.pdf

 

 

 

The 6502 may have been in a more primitive state in 1975; however, by 1978 it should have had decent tooling also. I can imagine it wanting/needing advanced cross-tools, though, judging by the state of the assembly code in the recently uncovered 6502 Microsoft BASIC source from 1978. (FWIW, the Microsoft source was created using a hand-built cross assembler using a macro assembler on a PDP-10, and a macro kit written by Paul Allen.)

Edited November 26, 2016 by intvnut

[mr_me]

Okay, so GI did make a cross-assembler/compiler for the PDP-11. I assume it uses the same syntax as their native cp1600 assembler (correct me if I'm wrong). So maybe APh was using GI's cross-assembler or did they adapt/tweak one they already have? I think there is some original APh Intellivision assembler source code out there; is it GI assembler compatible?

 

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. At that time APh already had experience developing for different microprocessors and had PDP-11 cross-assemblers and extra development tools etc. When the Intellivision project came to APh in Dec 1977, they had a very tight deadline to produce a demo for January. How much adapting of their existing tools could they have done for that? After CES in Jan 1978, APh had a few months to get things ready for the summer student programmers coming in May 1978. We also know that Mattel was still programming Intellivision Football at that time. Mattel finally gave up in August 1978 when they had APh debug/rewrite NFL Football for them. We next hear of Mattel getting back to Intellivision programming around 1980 when they sent Mike Minkoff and Rick Levine to APh where they did PBA Bowling (released July 1981). John Sohl, hired by Mattel, also was sent to APh but I don't think any other Mattel programmer did after that. Sometime in 1980/81 Mattel acquired their own development systems based on what APh had. I suppose they could have used GI systems but they didn't.

 

You can hear a bit about those early days in the Intellivisionairies Sea Battle and MicroSurgeon episodes as well as the Baseball one.

[+DZ-Jay]

You can hear a bit about those early days in the Intellivisionairies Sea Battle and MicroSurgeon episodes as well as the Baseball one.

 

It would be great if they excerpted those interviews out and posted them individually. That way we could have them as reference resources for posterity. As it stands, I don't know many who would slog through 4 or 5 hours of extraneous commentary and silly antics just to get to that.

 

-dZ.

[mr_me]

It would be great if they excerpted those interviews out and posted them individually. That way we could have them as reference resources for posterity. As it stands, I don't know many who would slog through 4 or 5 hours of extraneous commentary and silly antics just to get to that.

 

-dZ.

The intellivisionairies website has the exact times for the interviews so its easy to go straight to it. The in-depth highly detailed game commentary is good too.

[decle]

Okay, so GI did make a cross-assembler/compiler for the PDP-11. I assume it uses the same syntax as their native cp1600 assembler (correct me if I'm wrong). So maybe APh was using GI's cross-assembler or did they adapt/tweak one they already have? I think there is some original APh Intellivision assembler source code out there; is it GI assembler compatible?

 

 

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. David Rolfe talks a little about his work on other processors in the baseball interview. APh also seem to have extended this tool chain into software and hardware simulation and test harnesses. Again, GI had a software simulation of the CP1600, which presumably could have been extended to model a full Intellivision. However, APh seem to have focused on a system which would allow them to apply their techniques easily to hardware from different chip vendors. I can see how as a small business this would have made them flexible, opening up more opportunities for work, and reducing the learning curve when taking on projects with different target architectures. For the Intellivision work they went for a hardware harness, the Magus board which extended the toolset into the testing regime. This seems to have given them an integrated end to end development process, well as integrated as anything like that can be on PDP-11s probably with less than 64K of memory.

Edited November 26, 2016 by decle

[decle]

 

 

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.

 

Ahh OK. I guess I had not really seen the EXEC as a BIOS or lightweight MOS. which of course it is. I think rather I had pigeon-holed it purely as a game framework with some utility functions. Here of course we are talking about the KC 6502 EXEC rather than the CP1600 MC one, and I had not considered that it might provide general services in a way similar to for example the Acorn MOS within the BBC micro machines.

Edited November 26, 2016 by decle

[intvnut]

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.

 

This is precisely what I was getting at. APh had a retargetable macro-assembler. It wasn't a compiler in the sense of, say, IntyBASIC or GCC. I believe it was David Rolfe that first mentioned BLISS to me as the likely language the toolchain was written in. The macro facility in the toolset was pretty advanced, as I recall, which would allow you to build higher-level constructs easily, though. If you look through YFTE, you can see they had rather complex macros for setting up timed tasks, interaction dispatches, sound effects, etc.

 

 

David Rolfe talks a little about his work on other processors in the baseball interview. APh also seem to have extended this tool chain into software and hardware simulation and test harnesses. Again, GI had a software simulation of the CP1600, which presumably could have been extended to model a full Intellivision.

 

Well, in particular, the STIC used in those early demos was a hardware emulation. That is, a big box of discrete chips performing the same function that would be integrated onto a single chip, and delivered by GI. You can see those units described in the Papa Intellivision docs. I don't think computers were quite fast enough or capable enough back then to emulate the graphics in software on a bigger computer, at least not in real time. If there were, they were way too expensive and probably wouldn't travel well to CES. And let's face it, real time graphics are kinda the whole point of video games.

 

If you're going to wow folks at CES with a Television Video Game, you need to show off the graphics. No one cares about the CPU, everyone cares about the graphics. We don't have a picture of George Plimpton standing behind a 6507 and a CP1610, after all.

[+DZ-Jay]

The intellivisionairies website has the exact times for the interviews so its easy to go straight to it. The in-depth highly detailed game commentary is good too.

 

It would be great if they excerpted those interviews out and posted them individually. That way we could have them as reference resources for posterity. As it stands, I don't know many who would go through the trouble of seeking and searching and jumping through hoops just to get to that, even if the exact times are posted.

[intvnut]

Well, in particular, the STIC used in those early demos was a hardware emulation.

 

Some references to the STIC and other hardware emulators on Papa Intellivision:

• Page 3 of this PDF: "GI to supply STIC II 2nd emulator by 10/6" (that would be 10/6/1978)
• Pages 13, 15 of this PDF: Several mentions of emulators, including a RAM emulator (probably the System RAM, needed specifically for the STIC)
• Page 17 of this PDF: "Two(2) Video System Emulators - One set up and working in the suite - One stored in the suite"

I believe I've seen other references to emulator boxes on Papa Intellivision, but that's what I could find right now.

[intvnut]

 

Ahh OK. I guess I had not really seen the EXEC as a BIOS or lightweight MOS. which of course it is. I think rather I had pigeon-holed it purely as a game framework with some utility functions. Here of course we are talking about the KC 6502 EXEC rather than the CP1600 MC one, and I had not considered that it might provide general services in a way similar to for example the Acorn MOS within the BBC micro machines.

 

Actually, I'm talking about the combination of the KC 6502-side and KC CP1610-side EXEC. The two halves actually work rather closely together. (By KC EXEC, I mean the ROM at $7xxx that's provided in the KC, but for the CP-1610 to execute.)

 

For example, in "Typewriter" mode (and I believe the default input mode), all keystrokes entered on the keyboard get queued in a KC => MC FIFO. The MC then reads these keystrokes, plays a tone on the PSG, and then re-queues the keystroke in a MC => KC FIFO for eventual consumption by KC software. As a result, all keystrokes result in little chirps coming out of the PSG, which in my mind cement the KC's status as a "toy." They're cute, but they get old quick.

 

I wish I could find my most up-to-date commented disassembly. I had worked through the code and realized what it did before I even knew the KC had that behavior. It was kinda weird to see the behavior in the ROM before seeing it on the real system, and a little thrilling to see the predicted behavior pan out on the real machine.

Edited November 27, 2016 by intvnut

[First Spear]

you guys are smoking my head

[mr_me]

Some references to the STIC and other hardware emulators on Papa Intellivision:

 

• Page 3 of this PDF: "GI to supply STIC II 2nd emulator by 10/6" (that would be 10/6/1978)
• Pages 13, 15 of this PDF: Several mentions of emulators, including a RAM emulator (probably the System RAM, needed specifically for the STIC)
• Page 17 of this PDF: "Two(2) Video System Emulators - One set up and working in the suite - One stored in the suite"

I believe I've seen other references to emulator boxes on Papa Intellivision, but that's what I could find right now.

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.

 

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.

 

Regarding the keyboard component, those keypress chirps can be turned off in software, but it is on by default. If you've ever seen an older person try to learn a computer keyboard for the very first time you can see how audio reinforcement can be helpfull. They tend to hold the key down until they are satisfied it registered. Its also good that keys repeating by holding down required a second button. Early IBM keyboards made a clicking sound. Pretty sure the Commodore PET I first used was silent.

[intvnut]

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.

 

I believe they did have a RAM based board for some game development. (I've alternately heard it called Magus or Widget.) But in that particular PDF, if you read further down the page, it seems pretty clear to me they're talking about emulating the System RAM, which was a custom STIC-specific component:

[intvnut]

Speaking of the Widget:

 

This PapaIntellivision PDF mentions the widget...

 

 

 

As does this one, indicating it has some monitor software at $E000 - $FFFF as well.

 

[intvnut]

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.

 

That seems likely. Given that the original set of games were all APh-written titles, and the BSRs didn't really get staffed and trained until later (if I remember the history correctly), it all fits.

 

 

Regarding the keyboard component, those keypress chirps can be turned off in software, but it is on by default. If you've ever seen an older person try to learn a computer keyboard for the very first time you can see how audio reinforcement can be helpfull. They tend to hold the key down until they are satisfied it registered. Its also good that keys repeating by holding down required a second button. Early IBM keyboards made a clicking sound. Pretty sure the Commodore PET I first used was silent.

 

I guess I never figured out how to turn the chirps off (or if I did, I forgot). :-) I'm sure individual programs turned them off, much like individual games turned off the "keyclicks" sounds the EXEC makes for keypad and DISC.

 

I always assumed there was some other factor behind the manual repeat, such as a patent on the technology or lazy circuit/software design, as opposed to some deep human-factors insight. Typeamatic had been around in various forms for a long time. IBM was definitely unique with their buckling spring keyboards, though. The Commodore PETs, like most other non-membrane keyboards, were silent (save for sounds echoing in their hulking metal bodies).

Edited November 27, 2016 by intvnut

[mr_me]

 

That seems likely. Given that the original set of games were all APh-written titles, and the BSRs didn't really get staffed and trained until later (if I remember the history correctly), it all fits.

 

 

 

I guess I never figured out how to turn the chirps off (or if I did, I forgot). :-) I'm sure individual programs turned them off, much like individual games turned off the "keyclicks" sounds the EXEC makes for keypad and DISC.

 

I always assumed there was some other factor behind the manual repeat, such as a patent on the technology or lazy circuit/software design, as opposed to some deep human-factors insight. Typeamatic had been around in various forms for a long time. IBM was definitely unique with their buckling spring keyboards, though. The Commodore PETs, like most other non-membrane keyboards, were silent (save for sounds echoing in their hulking metal bodies).

Yes, the Application Software department at Mattel (Gabriel Baum and the Blue Sky Rangers of whom we hear all the stories) didn't start until around 1980/81. But Mattel's Engineering "Design and Development" department (eg. Richard Chang, Dave Chandler, Dave James, Rick Timmins to name a few) did initially attempt to program NFL Football according to the interviews. It sounds like that might have been done prior to 1978 and that source code was given to APh to "fix", now I understand it was likely not even compatible with the assembler APh was using. Unfortunately, we haven't heard from that group except through the papaintellivision.com documents. The Mattel "Design and Development" group did produce one released Intellivision game, Melody Blaster.

 

I remember back in the 1980s how I always looked forward to seeing new software and systems. Everybody's interface was different back then, now everything looks exactly the same. I bet that separate repeat button came from some other system. Some computers had clicky keyboards, but was there any other computer that beeped every time you pressed a keyboard key?

Edited November 27, 2016 by mr_me

[intvnut]

I remember back in the 1980s how I always looked forward to seeing new software and systems. Everybody's interface was different back then, now everything looks exactly the same. I bet that separate repeat button came from some other system. Some computers had clicky keyboards, but was there any other computer that beeped every time you pressed a keyboard key?

 

Hmm, good question. The original Apple ][ had a REPT key. The seriously old-school DECwriter II had a REPEAT key. (Believe it or not, I've used both at various points in my life.) I think I've run into a few other machines that had manual repeat. Interestingly, the DEC VT100 did not have a repeat key.

 

I don't think I've encountered any computer that purposefully made electronic chirping tones as part of being a normal typewriter, though. I have seen per-key sounds used as a feedback effect, say, in a game, but that would have come far after the KC.

 

Interestingly, even the ECS omitted the key beeps, so maybe it was a feature that tested poorly?

[carlsson]

For what it is worth, I know from first hand experience that the Oric-1 chirps on every keypress even at the BASIC prompt. I believe I've got at least some more computer in my collection that does, but I can't remember which.

[+DZ-Jay]

 

Hmm, good question. The original Apple ][ had a REPT key. The seriously old-school DECwriter II had a REPEAT key. (Believe it or not, I've used both at various points in my life.) I think I've run into a few other machines that had manual repeat. Interestingly, the DEC VT100 did not have a repeat key.

 

I don't think I've encountered any computer that purposefully made electronic chirping tones as part of being a normal typewriter, though. I have seen per-key sounds used as a feedback effect, say, in a game, but that would have come far after the KC.

 

Interestingly, even the ECS omitted the key beeps, so maybe it was a feature that tested poorly?

 

Well, considering that Every. Single. Computer. Interface showcased in a movie has keyboard clickity sounds accompanied by a subtle chirping tone, I can see how that particular interaction feedback could have been seen as a necessity to implement in order to make it "computery" and recognizable enough for the masses.

 

Perhaps in practice, like you said, it didn't really test well since it does become annoying after a while and it is completely unnecessary if you have tactile feedback.

 

I know that in old Mattel games, I rely on the input-chirp to tell me when a key press was registered rather than looking directly at the screen. It's almost intuitive. However, it would drive me crazy if I had to deal with that while typing in a BASIC program!

 

-dZ.

[decle]

For example, in "Typewriter" mode (and I believe the default input mode), all keystrokes entered on the keyboard get queued in a KC => MC FIFO. The MC then reads these keystrokes, plays a tone on the PSG, and then re-queues the keystroke in a MC => KC FIFO for eventual consumption by KC software. As a result, all keystrokes result in little chirps coming out of the PSG, which in my mind cement the KC's status as a "toy." They're cute, but they get old quick.

 

Fascinating, architecturally this sounds similar to the Tube mechanism used by Acorn to manage the interface between the BBC Micro and its co-processors. That used a ULA, located in the second processor peripheral, to implement the FIFOs, I guess here the FIFOs exist in the RAM shared by the MC and KC and are implemented in software? I think I read somewhere that the RAM was dual ported, a potentially expensive decision. The other difference between the Mattel and Acorn approaches is that the roles of the two processors are inverted. Within the Acorn scheme the second, parasite processor takes on the brunt of the processing work, with the original host processor being relegated to the I/O processor. This gives greater scope for expanding the overall grunt of the system (Intel 80186 and NS32016 processors were available at the time at great cost, and subsequently homebrew PDP-8, ARM, 6809 and other processors have been implemented on FPGAs and Pis) at the cost of constraining I/O to that originally provided. This made sense as the BBC micro had a mass of standard ports and peripherals available. I guess Mattel's approach makes more sense in their closed architecture and the graphics sensitive world of video games, although they didn't really maximise the opportunity to push the graphics and sound capabilities of the whole system forward.

[intvnut]

 

Fascinating, architecturally this sounds similar to the Tube mechanism used by Acorn to manage the interface between the BBC Micro and its co-processors. That used a ULA, located in the second processor peripheral, to implement the FIFOs, I guess here the FIFOs exist in the RAM shared by the MC and KC and are implemented in software? I think I read somewhere that the RAM was dual ported, a potentially expensive decision.

 

Yes, these are all software FIFOs. The FIFOs in theory could be sourced or sunk on either side of the dual-port RAM. The dual-port RAM was a bit, erm, interesting. It's a 16K x 10-bit RAM. It shows up at $8000 - $BFFF on the MC side. On the KC side, it shows up in two ranges: $0000 - $3FFF for the lower 8 bits, and the upper 2 bits show up in the lower two bits of $4100 - $7FFF, if memory serves. ($4000 - $40FF is I/O memory on the KC side.)

 

I don't know if there were any wait-states on the 6502 side for the dual-port memory. I'd hope not, as it holds the zero page. There's no ability to insert wait states on the CP-1610 side (the BDRDY signal isn't pinned out), so it would always need to win the bus when it accessed memory. But, with its multiplexed bus, there was plenty of time to get a heads up that an access was coming, and so you could probably squeeze the accesses into spare ɸ1 cycles on the 6502 side. (The 6502 only accesses memory during ɸ2, if memory serves. The Apple ][ used this trick to multiplex video and CPU fetches without cycle-stealing.)

 

 

 

Within the Acorn scheme the second, parasite processor takes on the brunt of the processing work, with the original host processor being relegated to the I/O processor. This gives greater scope for expanding the overall grunt of the system (Intel 80186 and NS32016 processors were available at the time at great cost, and subsequently homebrew PDP-8, ARM, 6809 and other processors have been implemented on FPGAs and Pis) at the cost of constraining I/O to that originally provided. This made sense as the BBC micro had a mass of standard ports and peripherals available. I guess Mattel's approach makes more sense in their closed architecture and the graphics sensitive world of video games, although they didn't really maximise the opportunity to push the graphics and sound capabilities of the whole system forward.

 

I guess it depends on which processor you consider the "parasite" and which processor you consider the "host." The 6502 was responsible for managing the tape drive, scanning the keyboard, managing printer and serial ports, managing the 9927 CRTC, and so on. When the tape's running, the 6502 does quite a lot of work. It's getting thousands of interrupts of second essentially managing the tape drive bit-by-bit with a fairly elaborate state machine.

 

Microsoft BASIC runs on the 6502 side, most likely because there was a 6502 BASIC available. Most other cartridge software looks like it was aimed at the MC. In principle, the MC could load 6502 code into RAM from the cart. In fact, I did discover that the MC looks for a special cartridge signature ($000, $001) in the first two words at $5000, and treats those cartridges differently. It still executes the cartridge directly from the MC side though. (It turns out the Intellicart runs afoul of this signature, which is how we first discovered it. Since then I've found where in the code it makes this test.)

 

I haven't looked at Physical Conditioning or the French programs to see what the division of labor was between the two CPUs. I imagine it varied by title. All the tapes written in BASIC clearly ran primarily on the 6502. Otherwise, it's not clear to me which CPU was considered "superior" to the other in terms of the system architecture view. At startup, at least, it looks like the MC may have been considered the "master", as all the menu software actually runs on the MC, with the KC relegated to peripheral processor handling display, keyboard input, and tape management, while the "business logic" lives on the MC.

 

Here's an excerpt of the MC-side disassembly showing some of the menu logic.

.

;;==============================================================================
;;  Menu Entry for CARTRIDGE
;;------------------------------------------------------------------------------
L720D:  BIDECLE L721F           ; $720D  001F 0072
        BYTE    "CARTRIDGE",0   ; $720F
        DECLE   $353, " "       ; "Start "
        DECLE   $346, " "       ; "Cartridge "
        DECLE   $357, 0         ; "Program", 0

L721F:  MVII    #$0050, R1      ; $721F  \
        SWAP    R1              ; $7221   |   Look for viable ROM at location
        MVI@    R1,     R0      ; $7222   |__ $5000 (eg. 6 MSBs are zero)
        SWAP    R0              ; $7223   |   If none is found, reset and
        ANDI    #$00FC, R0      ; $7224   |   complain to the user.
        BNEQ    L724C           ; $7226  /

        PSHR    R1              ; $7228  \
        JSR     R5,     L763F   ; $7229   |-- Reset 6502 side and have it
        BIDECLE $C003           ;        /    vector to $C003.  (Slave mode?)

        JSR     R5,     L737C   ; $722E  \___ ?
        DECLE   $000            ; $7231  /    Also clear location $8480

        PULR    R5              ; $7232  \    ($5000 from above)
        SDBD                    ; $7233   |
        MVI@    R5,     R0      ; $7234   |-- Detect special KBD cart?
        DECR    R0              ; $7235   |   ($xx00, $xx01 at $5000-$5001)
        BEQ     L73D8           ; $7236  /    

        MVII    #$02F0, R1      ; $7238  \
        ADDI    #$0012, R5      ; $723A   |-- Set UDB pointer @ $2F0 (for
        MVO@    R5,     R1      ; $723C  /    EXEC cart header-reading utils)

        JSR     R5,     L75AC   ; $723D  \___ Write $D0 to $340 on 6502 side.
        DECLE   $000, $0D0               /

        JSRD    R5,     L7114   ; $7242  \___ write "$1126" to $847[9A]
        BIDECLE $1126,  $8479   ;        /    (address of EXEC's default ISR)
        J       G103D           ; $7249  Do EXEC's normal cart bootup seq.

L724C:  JSR     R4,     L701D   ; $724C  Reset and tell user we didn't 
                                ;        find a cartridge.

;------ "\r\n ? I don't see a cartridge", 0
        DECLE   $304, "I "      ; "\r\n ? I "
        DECLE   $30C, " "       ; "don't "
        DECLE   $30E, " "       ; "see "
        DECLE   "a ", $306, 0   ; "a cartridge", 0
;;==============================================================================

;;==============================================================================
;;  Menu Entry for TAPE
;;------------------------------------------------------------------------------
L725A:  DECLE   L7267
        DECLE   "TAPE", 0

;------ "Start Cassette Program"
        DECLE   $353, " ",      ; "Start "
        DECLE   $347, " ",      ; "Cassette " 
        DECLE   $357, 0         ; "Program", 0

L7267:  JSR     R5,     L7666   ; $7267  \
        DECLE   $001            ; $726A   |-- Sense cassette tape?
        BNEQ    L7280           ; $726B  /
        JSR     R5,     L769C   ; $726D  
        JSR     R4,     L701D   ; $7270  Reset and tell user we didn't find
                                ;        a cassette tape.
;------ "\r\n ? I can't see the cassette tape", 0
        DECLE   $304, "I "      ; "\r\n ? I "
        DECLE   $30F, " "       ; "can't "
        DECLE   $30E, " "       ; "see "
        DECLE   $316, " "       ; "the "
        DECLE   $307, " "       ; "cassette "
        DECLE   $308, 0         ; "tape", 0
;;==============================================================================

.

There was a rather well-developed MC => KC remote procedure call mechanism as well. Again, this suggests the MC was "master", at least when the in-built software was running. There's around a dozen RPCs supported via this interface. Here's the MC-side RPC dispatcher:

.

;;=============================================================================
;;  Invoke a command on the 6502 side and return the result.
;;
;;  INPUTS for L7571
;;    R5 -- Pointer three decles of parameters.  Function returns after
;;          parameters.
;;             RPC Command Number         1 DECLE
;;             Ptr to paramter block      2 DECLES (in BIDECLE format)
;;
;;  INPUTS for L757C
;;    R4 -- Pointer to parameter block.
;;    R5 -- Pointer to RPC Command Number.  Function returns after this decle.
;;
;;  INPUTS for L757F
;;    R0 -- RPC Command number ($01 .. $0C) 
;;    R4 -- Pointer to 3-byte parameter block 
;;    R5 -- Return address.
;;
;;    For all inputs, the RPC command number is a value between $01 and $0C
;;    (inclusive) that requests some action from the 6502-side of things.
;;    The 3-byte parameter block acts as arguments to this RPC call.  These
;;    bytes form "Arg1", "Arg2", and "Arg3", respectively, and their meaning
;;    varies according to the RPC command number.
;;
;;  OUTPUTS:
;;    R0,R1,R2,R3,R4 -- Unchanged
;;    R5 -- Points to return address
;;    C  -- Set if error, Clear if ok.
;;-----------------------------------------------------------------------------
L7571:  PSHR    R0              ; $7571  Save R0
        PSHR    R4              ; $7572  Save R4
        MVI@    R5,     R0      ; $7573  Get RPC cmd number from
        SDBD                    ; $7574  \___ Get the pointer to the parameter
        MVI@    R5,     R4      ; $7575  /    block.
        PSHR    R5              ; $7576  Save our return address
        JSR     R5,     L757F   ; $7577  Do RPC command
        B       L7556           ; $757A  Restore R5, R4, R0 and return.

L757C:  PSHR    R0              ; $757C  Save R0
        MVI@    R5,     R0      ; $757D  Get arg from after JSR
        INCR    R7              ; $757E  skip next instruction

L757F:  PSHR    R0              ; $757F  Save R0
        PSHR    R5              ; $7580  Save return address
        JSR     R5,     L755A   ; $7581  Go blast 3-byte record to 6502

L7584:  DECR    R5              ; $7584  \
        MVI@    R5,     R0      ; $7585   |__ Spin until $8301 goes zero
        TSTR    R0              ; $7586   |   again (meaning 6502 done).
        BNEQ    L7584           ; $7587  /
        SUBI    #$0002, R5      ; $7589  Point to $8300 -- return code
        XOR@    R5,     R0      ; $758B  Was it zero?
        CLRC                    ; $758C  \___ Yes:  Return w/ carry clear
        BEQ     L7590           ; $758D  /
        SETC                    ; $758F  No:  Return w/ carry set.
L7590:  PULR    R5              ; $7590  \___ restore saved R5, R0
        PULR    R0              ; $7591  /
        MOVR    R5,     R7      ; $7592  Return.
;;=============================================================================

.

Here's a not-entirely-decoded summary of the dozen RPCs I've worked out, and their addresses on the 6502 side:

.

    $C36B  CP-1600 -> 6502 RPC cmd #1:  PEEK($340 + 12*Arg1)
    $C371  CP-1600 -> 6502 RPC cmd #2:  POKE $340 + 12*Arg1, Arg2
    $C376  CP-1600 -> 6502 RPC cmd #3:  PEEK(PEEK($340 + 12*Arg1 + 6))
    $C381  CP-1600 -> 6502 RPC cmd #4:  POKE PEEK($340 + 12*Arg1 + 6)), Arg2
    $C340  CP-1600 -> 6502 RPC cmd #5:
    $C399  CP-1600 -> 6502 RPC cmd #6:  Various and sundry tape commands.
    $C3E8  CP-1600 -> 6502 RPC cmd #7:  PEEK address in Arg1/Arg2
    $C3EE  CP-1600 -> 6502 RPC cmd #8:  POKE Arg3 to address in Arg1/Arg2
    $C3F3  CP-1600 -> 6502 RPC cmd #9:  Jump to address in Arg1/Arg2
    $C3F6  CP-1600 -> 6502 RPC cmd #A:  Reset 6502 side and vector to routine
    $C40F  CP-1600 -> 6502 RPC cmd #B:  MemCopy
    $C422  CP-1600 -> 6502 RPC cmd #C:  Kbd Pause Mode / Flush output FIFO

.

Note that all the business about $340 + 12*Arg1 I believe is related to these software FIFOs.

 

So, if you consider the MC the "host" and the KC the "parasite", then yes, the "parasite" processor is the main I/O processor and the roles are somewhat reversed. After all, no Intellivision system could function without an MC. But, flipping around, when BASIC is running, the KC is more the "host" and the MC is the "parasite", and you could theoretically envision more-capable MCs slotting into the same KC in the future.

 

It's probably best to just think of the two as peers when they're connected, with a flexible division of labor depending on what it's doing.

Edited November 29, 2016 by intvnut

[+DZ-Jay]

So, if you consider the MC the "host" and the KC the "parasite", then yes, the "parasite" processor is the main I/O processor and the roles are somewhat reversed. After all, no Intellivision system could function without an MC. But, flipping around, when BASIC is running, the KC is more the "host" and the MC is the "parasite", and you could theoretically envision more-capable MCs slotting into the same KC in the future.

 

It's probably best to just think of the two as peers when they're connected, with a flexible division of labor depending on what it's doing.

 

According to all the (non-technical) information I see from the BSRs on the Keyboard Component, the Master Component was always intended to be the center of the system. Even the KC was intended to provide additional I/O support, but still relegate more important functions to the MC.

 

From the IntellivisionLives.com site:

Slipping the Master Component into the Keyboard Component would unlock the full power of the 16-bit microprocessor in the Intellivision.

 

The Keyboard Component contained 64K of dual port dynamic RAM and its own 6502 processor to handle I/O functions.

 

It is my understanding, like Joe mentioned, that MS BASIC ran on the KC because there was already a version for the 6502, which seems to be purely incidental.

 

I always viewed Mattel's "Intellivision Vision" having a set of interchangeable components with the Master Component unit as the center. All documents and advertisements seem to point to this, including stuff from Papa Intellivision's site. (Also, the fact that it was called the "Master Component" is a clue.) That the industry and the culture was more inclined towards video games was an accident of history that shifted Mattel's focus.

 

I see it similar to what Disney's vision of EPCOT was as compared to what it became: His original vision was a central urban "hub" connecting many aspects of an engineered city, of which an amusement park was just one part. They started with the amusement park to build momentum and raise funds (since they already had built domain knowledge on that particular area), but then got stuck in that direction because that's what the mainstream audience wanted. (Also, Mr. Disney died and his vision was left to die since nobody seems to have cared for it.)

 

-dZ.

[mr_me]

So is it possible to have a multi threaded application that makes use of both processors (and not just for i/o)? It would be unusual since you would have incompatible code. For a non graphical application, which processor would be faster?

[intvnut]

So is it possible to have a multi threaded application that makes use of both processors (and not just for i/o)? It would be unusual since you would have incompatible code. For a non graphical application, which processor would be faster?

 

The communication FIFOs between the KC and MC sides exist for this purpose. Both processors are running code, and you could run a program that straddles both. I haven't decoded the Pic-See software which is supposed to synchronize the MC to tape blocks yet, but that is a form of multi-threaded app right there, with the KC running the tape management thread and the MC running the graphics.

 

In terms of speed, it would depend on how much 16-bit vs. 8-bit arithmetic you're doing. With the 6502 likely at 895kHz, it can still run more instructions per second than the CP-1610, but they're all 8 bit instructions, and they do less per instruction. But, you only do as much as you need to, and so on average, you benefit from the shorter cycle count far more than you hurt from needing more instructions. Carl and I had exactly this debate once. The 6502 does seem to have a performance edge over the CP-1610 at the same clock rate for general purpose code because its instruction cycles are just so lean, and if you're clever, you can get what you need to do done with the lean resources provided. Also, the 6502 does have a richer set of addressing modes, so one of the biggest time-sinks on the CP-1610, random-indexing, is very cheap on the 6502.

 

The CP-1610 pulls ahead at heftier computations such as SQRT, divide, etc. where you really benefit from the 16-bit registers, and you're not randomly indexing memory.

 

The CP-1610 has a cleaner instruction set architecture, IMHO. If you built a version with a non-multiplexed bus and true 16-bit ALU (rather than double-pumped 8-bit ALU), it could be much faster than the 6502 at the same clock. (The CP-1610-2 intended for the ill-fated Intellivision III would have provided that.) But in the form we see in the Intellivision, I believe it's actually slower than the 6502 in most cases.

[intvnut]

In terms of speed, it would depend on how much 16-bit vs. 8-bit arithmetic you're doing. With the 6502 likely at 895kHz, it can still run more instructions per second than the CP-1610, but they're all 8 bit instructions, and they do less per instruction.

 

I looked up the claimed MIPS rate for the 6502 at Wikipedia. It claims about 0.43 MIPS at 1MHz. That's about 2.3 cycles/instruction average. That must be measured running everything in the zero page! So, at 895kHz, that would be about 0.38 MIPS top speed, and probably closer to 0.3 MIPS if you're not all in the zero page.

 

The CP1610 has instruction cycle times ranging from 6 cycles to 14 cycles, with a typical compute sequence probably averaging around 7-ish to 8-ish cycles per instruction. Let's go with a 7.5 cycle average assuming a similarly "best case" instruction mix. So for that, we're at a more leisurely 0.12 MIPS.

 

So, on a raw "instructions per second" measurement, the 6502 is about 3x as fast as the CP1610. That's a pretty big lead straight out of the gate. Even if you require 2x the instructions on the 6502 to do the same work, you still have a ~50% advantage.