Jump to content
IGNORED

IntelliXpander module


opcode

  

86 members have voted

  1. 1. What design would work best for the IntelliXpander?

    • Make it to match the original Intellivision design
      58
    • Make it to match the Intellivision II design
      28

  • Please sign in to vote in this poll.

Recommended Posts

Well...the attribute bus is 14 bits wide on the Inty I and II. Do we know what the specs are for the attribute format in the III? For instance, they could have widened the bus to a full 16 bits with little difficulty. So while its 2 bytes per attribute, as far as the STIC is concerned it's only one word per attribute. Similarly, they could have widened the pattern bus from 8 to 16 bits. It's already shared with the System RAM bus so the lines would already be there. It's even possible that they could have done all that and still remain within 40 pins, I would think, with some clever rearranging.

 

As far as the color output: it isn't a rhetorical question: how is the video getting to the Inty? Unmodified Inty I's only support external video MUX input on pin 8, whereas Inty II's also support external video replacement on pin 2.

Edited by JohnPCAE
Link to comment
Share on other sites

All good questions. So let's see. 14 or 16 bits doesn't matter, as it is represents a single 16 bits access.

However I think you made a very good point about doubling be bus. We know from specs they planned to move GROM/ GRAM to cartridge, and the prototype seems to have a very wide cartridge port.

However by moving GROM to cartridge they may have doubled the width of the bus to 16 bits. By keeping the same clock speed, that gives us:

40 bytes from pattern, since it doubled from 8 to 16 bits

40 bytes from BACKTAB, since it was already 16 bits

16 bytes for sprites, since it is also part of GROM and has doubled

Total gain is 28 extra bytes compared to Intv 1.

 

Now it isn't clear how they planned to use the 2 bytes per tile attribute. I assume that in 160 mode, it is the same as Intv 1. For the new 320 mode, probably they planned to use 2 bytes per 16 pixels wide tiles, just to keep access the same, not 1 byte as reported here previously.

 

So 96 bytes / scan line is the actual memory bandwidth. Interestingly, if using 256 pixels resolution, we get the exact same bandwidth by using 16 pixels wide tiles and 2 bits per pixel (4 colors per tile), 1 byte attribute. Very usable.

 

As for vídeo, yes, the hardware guy informed me about the MUX thing and is working on it.

Link to comment
Share on other sites

The Mattel Intellivision III "Target Specification" does explain some improvements to the proposed STIC memory access compared to the original Intellivision.

 

The original Intellivision STIC had a separate 14-bit data bus using one 14-bit word of attribute data per tile. But the pattern data was only in 8-bit rom/ram. The Intellivision III STIC would share the 16-bit data bus with the CPU and now accesses full 16-bit words of graphic attribute and pattern data in 16-bit rom/ram. That is the improvement to the proposed STIC, double the pattern data compared to original Intellivision. The number of horizontal tiles would remain the same at 20, so tiles in 320 pixel mode become 16 pixels wide, 2-colours. So data throughput should be the same in Intellivision III 160 pixel mode or 360 pixel mode. Looks like it would still be one 16-bit word of attribute data per tile (14-bit for original Intellivision).

 

The document mentions that the new system requires 2x the bus bandwidth of STIC1 and 2x instruction throughput for the CPU compared to original Intellivision. With the new memory architecture, it says "the CPU bus utilisation cycles are interleaved with the synchronous operation of the video chip". It goes into memory access cycles and pixels drawn etc.

 

edit:

In Intellivision III 160 pixel mode it would be 20 tiles, each 8-pixels wide, and four colous. One 16-bit word pattern would use 2-bits per pixel for four colours. Original Intellivision would have 160 pixels with 20 tiles, each 8-pixels and two colours. One 8-bit pattern, 1-bit per pixel for two colours.

Edited by mr_me
Link to comment
Share on other sites

I wouldn't say that the planned new STIC had 2x the bus bandwidth, as 2x would be 152 bytes per scan line instead of 96. So it is kind of disappointing, less than the ColecoVision's 104 (nominally 140 considering sprite attributes are in VRAM) and same year NES's 120 bytes per scanline. So it is more like Intv 1.5 specs for a machine costing twice the regular Intv 1 at the time. Moore's law didn't apply here, 3 years since Intv 1, less than twice the performance for the same launch price. Explains why they scraped it.

Link to comment
Share on other sites

For sure, the Intellivision III would not have been considered Mattel's next generation game system. That would have been the Intellivision IV. The Intellivision III, was a quickfix response to coleco vision, pushed by Mattel marketing. Designing the III started after work on the IV started. The Intellivision II was only $69 by Christmas 1983 and the III was cancelled by management. I don't think the IV was actually cancelled but most people were layed off at about the same time.

  • Like 1
Link to comment
Share on other sites

I was wondering what the issue would have been with Mattel going full 40x24 tiles with 8x8 4-colour tiles for the Intellivision III. Would it have been too many changes with the STIC chip. Mattel was dependent on General Instrument making the changes and perhaps there was a time or budget constraint. Or was there some other technical issue. Atari and the C64 also had 320 pixel modes but using them in games didn't seem practical; most of their games use 160 mode.

Edited by mr_me
Link to comment
Share on other sites

Part of the problem with 320 mode, I think, is that it complicates color output. The chroma signal operates at 1/4 the frequency of the luma signal. Therefore, when you use 160-pixel mode, each pixel can have its own unique color. However, in 320-pixel mode, each pair of pixels share a single color waveform. That's why you see some odd tinting on letter stems in that mode: the colors of adjacent pixels are blending somewhat. It means that the hardware has to perform that blending on each pair of pixels to make everything look okay, and that's not taking gamma correction into account.

Link to comment
Share on other sites

Despite the 320 pixel 2-colour per tile limit. The Intellivision III might have been capable of very colourful high resolution 320x192 graphics. I'm thinking if the Atari 2600 can produce 128 colours on the screen, Mattel would have addressed their 16 colour limit. The Intellivision IV specs mentions multiple interrupts per scanline. If the Intellivision III permits reprogramming the colour palette per scanline it could have a high resolution screen with hundreds of different colours.

 

"The display logic, actually supports each row of cards independently and in full operational mode several control parameters must be passed to the row display logic. These parameters include the descriptor list start address, the desired x and y offset, the display operating mode and any color pallette changes." (Target Specification Intellivision III - Background Detail)

 

The above seems to indicate that pixel scrolling different rows of tiles independently is possible, and that if you can't reprogram the colour palette per scanline it could be done per tile row.

Link to comment
Share on other sites

I am already using row scroll. 16 colors on screen isn't bad at all, especially when you can select from 4096 or so.

Having 4 colors per 16 pixels isn't bad either, as that is on par with NES stuff. Problem is 2 colors per 16 pixels, that is inferior to even ColecoVision. In 160 resolution mode things get a litle better.

 

The only reason STIC 2 had those funny modes is because they had to keep it backward compatible. So the clock rate still had to be 7.14MHz, and they couldn't make significant changes to the pipeline other than double the GROM bus.

 

IntelliXpander doesn't replace STIC, so we are free from those restrictions. For example, by increasing the clock speed by 50% (same clock as ColecoVision's TMS9928), we get 144 memory cycles per scan line (still less than the ColecoVision's 170 memory cycles). That is an awesome number. That give us 2 bits per pixel and 2 bytes of attribute per tile. I like that better, and think it is more consistent with a 3 years gap between systems.

  • Like 3
Link to comment
Share on other sites

We can add Moon Patrol and Zaxxon to the intellixpander list if desirable.

Goonie is now playable. Working on the shooter.

Hmmmm...well Joe Z's Space Patrol and Oscar's Space Raid pretty much have those two games well covered so I think there's probably a whole bunch of other games that might make more sense. :)

Link to comment
Share on other sites

Man, the Intv crowd is hard to pleasure..... :(

It is probably that they are interested in other games that don't have existing decent original or homebrew versions.

 

I personally can play Moon Patrol and Zaxxon on our Intellivisions via their awesome homebrew equivalents, what I would want are games they can't play like Mr. Do! or Goonies or Graduis

Link to comment
Share on other sites

Gorf would make sense as it's 4 games in one AND uses voice modulation...

 

But honestly, it up to you. We could sit here and pound the crap out of you with suggestions for eternity and get nothing done. You already made a great choice in Goonies... keep it going.

 

JR

Link to comment
Share on other sites

Gorf would make sense as it's 4 games in one AND uses voice modulation...

But honestly, it up to you. We could sit here and pound the crap out of you with suggestions for eternity and get nothing done. You already made a great choice in Goonies... keep it going.

JR

Oh, you want voice. How about Bosconian with all voices?

  • Like 1
Link to comment
Share on other sites

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

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

×   Your previous content has been restored.   Clear editor

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

Loading...
  • Recently Browsing   0 members

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