Jump to content
IGNORED

StudioVision - An RCA Studio II emulator for the Intellivision


decle

Recommended Posts

January 2017 marks the 40th anniversary of RCA launching the Studio II.

 

post-46336-0-17425600-1483261937_thumb.jpg

To celebrate this occasion I'm pleased to release a collection of ROMs that allow you to enjoy the thrill of monochrome gaming, straight from 1977, on your Intellivision. Each ROM contains a copy of the StudioVision emulator and one RCA Studio II game cartridge.

 

(click to animate all screen shots)

post-46336-0-48374000-1483261994_thumb.gif Unplugged - Play the 5 games built into the Studio II console

svUnplugged.rom

 

post-46336-0-21596200-1483262040_thumb.gif Space War - One or two player space shooter

svSpaceWar.rom

 

post-46336-0-88331700-1483262092_thumb.gif Tennis / Squash - Pong style tennis and solo clones

svTennis.rom

 

post-46336-0-36278400-1483262138_thumb.gif Gunfighter / Moonship Battle - Wild West action, with added space combat

svGunfighter.rom

 

post-46336-0-42292600-1483262187_thumb.gif Blackjack - They didn't hire the shifty eyed dealer until 1978

svBlackjack.rom

 

post-46336-0-21897500-1483262246_thumb.gif Fun With Numbers - A Mastermind clone and a number sorting puzzle

svFunWithNumbers.rom

 

post-46336-0-27118900-1483775531_thumb.gif Baseball - Simple 2 player version, not bad for 1K

svBaseball.rom

 

post-46336-0-04362500-1483775626_thumb.gif Star Wars - One of the earliest video game versions

svStarWars.rom

 

post-46336-0-38683300-1484381172_thumb.gif Speedway / Tag - Two player racing and lose the flag games

svSpeedway.rom

 

post-46336-0-48988400-1484381597_thumb.gif Biorhythm - Predictions of the future from the 1970s

svBiorhythm.rom

 

post-46336-0-22506200-1484982629_thumb.gif Pinball - Tommy in black and white

svPinball.rom

 

post-46336-0-58217500-1484982731_thumb.gif Bingo - Was it released or wasn't it?

svBingo.rom

 

post-46336-0-40429400-1485586712_thumb.gif Math Fun - More maths, fun

svMathFun.rom

 

post-46336-0-40122900-1485586827_thumb.gif Concentration Match - The card game Pairs

svConcentrationMatch.rom

 

post-46336-0-24237300-1486195425_thumb.gif School House 1 - School quiztastic

(requires these quiz booklets)

svSchoolHouse1.rom

 

post-46336-0-27325700-1486195560_thumb.gif Grand Pack - End as we started

svGrandPack.rom

 

post-46336-0-35900200-1486798963_thumb.gif Demonstration Cartridge - Fresh off the press

svDemonstration.rom

 

post-46336-0-52538400-1486799035_thumb.gif Programming Cartridge - Unleash your creativity

(requires this manual and to map hex keys to your PC keyboard use this hack file: keyprg.txt)

svProgrammingCart.rom

 

Unfortunately, Studio II games can be a little cryptic, especially when it comes to controls. They often boot up to a black screen and require the use of both controllers to get things started. To help, some brief instructions for each game are displayed in a marquee at the bottom of the screen. Alternatively, scans of the original instructions can be found here. StudioVision uses the Intellivision number pads to represent the Studio II controllers. The left number pad is Studio II controller 'A', the right is controller 'B'. I recommend the use of the following Jzintv keyboard hack file. This gives an authentic cramped feeling by mapping your PC keyboard onto the Studio II like this:

 

post-46336-0-51390500-1483262333_thumb.png keyhack.txt

Additionally, for the Intellivision programmers out there, there is a fairly large and hopefully interesting Easter Egg in StudioVision. If it is run on an Intellivision with 2K of GRAM rather than the standard 512bytes StudioVision will double the screen resolution. Here is a comparison of Bowling in small and large screen mode:

 

post-46336-0-57029600-1484983296_thumb.gif post-46336-0-16470100-1484983295_thumb.gif
 
There is no easy way to give a real Intellivision 2K of GRAM, however, it is possible to enhance Intellivision emulators to mimic it. 2K GRAM mode can be enabled in Jzintv with the flag -G2
 

If you are interested in how StudioVision works you can take a look at the source code:

 

studioVisionSource.zip

This is released under a non-commerical Creative Commons licence. I don't own Warren Trachtman's musical arrangement or the Studio II BIOS ROM image. To build StudiVision with the Jzintv SDK1600 use the following command:

as1600 -o svUnplugged.rom studioVision.asm

You will notice that the resulting ROM image is not identical to that posted above. This is because of fixes and improvements to the emulator that later games have required.

StudioVision has been written and tested using the excellent Jzintv emulator. Whilst StudioVision ROMs should work on real hardware and other emulators, your mileage may vary.

If you have any problems or feedback please let me know.


Enjoy!

decle

Edited by decle
Further ROM updates to improve CC3 compatibility
  • Like 20
Link to comment
Share on other sites

(copied from main Intellivision forum)

Wow! The Intellivision is emulating a different computer! I like the intro screen. Is there any reason you can't double up on the resolution. The scrolling instructions are great; would be nice if we could control it with the disc.


Thanks for the feedback. Your questions are really good.

The Studio II has a 64x32 bitmapped display. It takes 32 Intellivision GRAM cards to model it. So whilst the Intellivision's screen is large enough to double the resolution, unfortunately a standard Intellivision does not have enough GRAM to map the 128 cards required.

Disc control is something I considered. These kind of projects are always a bit of a compromise between authenticity and ease of use. In this case the decision was made for me because I don't have a means of testing on a real Intellivision. Given that the Studio II only has keypads, I was not sure how well a disc would work with the games. Of course, if you are using an emulator it is always possible to map the keys to any controls you fancy.


Cheers

decle

Edited by decle
  • Like 1
Link to comment
Share on other sites

Yes I wouldn't change the game controls. What I meant was using the disc to scroll the instructions.

 

Sorry, I misunderstood. I did not think of that. It is a good idea, and would certainly be doable, either with the disc or action buttons.

  • Like 1
Link to comment
Share on other sites

Cool! I just have played the cars game in the first ROM.

 

I've hide the duplicated topics, it's a good thing to be a moderator here ;)

 

Thanks for deleting the extra posts.

 

Freeway is not bad, I found it quite challenging to do a clear run without crashing at the higher speed. From an implementation perspective it seems to be a unique game. The scrolling is achieved by changing the start address of the screen in memory. So rather than the road and traffic scrolling and your car remaining still as you might expect; in reality the road and traffic are not moving vertically, the screen start address is being decremented by 8 bytes to move everything down a line and the position of your car is being adjusted to keep it at the same point on the screen. It seems to be the only game that uses this feature of the hardware. The ability to do this complicates the StudioVision screen rendering quite a bit as you have to keep checking for wrap around when plotting each line to the screen.

 

I also quite enjoy a game of bowling and tennis against my 10 year old son, and the sorting puzzle in Fun With Numbers is interesting, until you work out the method. Whilst none of the games are as sophisticated as those on the Intellivision I don't think they are bad for 0.5K of code.

  • Like 1
Link to comment
Share on other sites

Emulated or simulated? I know with your other projects that there's some hardware compatibility that you can take advantage of, but I didn't think a fullblown CPU emulation would be feasible on the CP1610.

 

 

This is an excellent question and, given how slow the CP1610 is, you are right to be sceptical. To be honest, I’m pleased that you are dubious. It shows that the results are good enough for you to think I must be cheating ;)

 

The short answer is that each game’s cartridge software is there, running, and from its perspective StudioVision is just a simple interpreting emulator.

 

Before I go further I should say up front that I am standing on the shoulders of giants. StudioVision would not have been possible without the detailed investigation of the Studio II by Paul Robson and the work done by Carl Mueller Jr emulating the Intellivision in the restrictive environment of the GameBoy Color.

 

The more complete explanation is that when selecting which target system to emulate on the Intellivision you have to be very picky. The RCA Studio II uses the RCA COSMAC processor clocked at 1.78MHz and can execute about 120,000 instructions / second, roughly the same as the CP1610 in the Intellivision. Like the Atari 2600 a lot of the RCA CPU time (about 50%) is spent drawing the screen, something you get more or less for free with the Intellivision. So in reality Studio II games only get 50-60,000 instructions per second and the Intellivision is about twice as fast. However, this is not enough to emulate in real time. The weird architecture of the COSMAC processor means it takes a minimum of 8 CP1610 instructions to execute a single COSMAC one, so we are back to an emulator being at least 4 times slower than a real Studio II.

 

However, there is another helpful Studio II design feature, its architecture looks like this:

 

post-46336-0-45633700-1483353833_thumb.png

 

Like the Intellivision there is an EXEC or BIOS providing services to the games, it is written in RCA COSMAC machine code (COSMAC code is highlighted in blue in the diagram). However, unlike the Intellivision, a big part of this BIOS is a Pseudo Machine Language (PML) interpreter (the Pseudo Machine Language has been documented by Paul Robson). The majority of most games are written in this Pseudo Machine Language (PML code is highlighted in green) rather than COSMAC machine code.

 

When a game is running most of the time is spent interpreting the PML instructions. The interpreter within the Studio II takes about 30 COSMAC instructions to decode a single PML instruction (i.e. load a PML instruction from memory, update the program counter and work out which function to call to execute it). This is great because it means that the Studio II can process no more than 2,000 of these PML instructions per second. So, if rather than naively using the COSMAC interpreter in the BIOS we write our own one, in CP1610 machine code, and use that instead there is a massive potential speed up. This leads to StudioVision looking like this:

 

post-46336-0-92232900-1483353844_thumb.png

 

The CP1610 PML interpreter (CP1610 code is highlighted in red) can decode a PML instruction in 27 CP1610 instructions. This gives us at most about 4,000 PML instructions per second. If we were to use the COSMAC interpreter these decoding operations would take at least 250 CP1610 instructions per PML instruction (30 COSMAC instructions * 8 CP1610 instructions per COSMAC instruction).

 

StudioVision does have a full COSMAC CPU emulator written in CP1610 machine code. This is required because the CP1610 PML interpreter only decodes instructions, it then calls the existing COSMAC functions in the Studio II BIOS to actually execute them. The COSMAC CPU emulator also handles any bits of game code not written in PML.

 

Unfortunately this is still not quite fast enough. Using the existing COSMAC implementations in the BIOS to execute all the PML instructions is just too slow. Looking at where the time is being spent by the games we see that it is dominated by executing 4 types of long and slow PML instructions. These instructions move and draw software sprites; and read the Studio II keypads. By writing our own CP1610 implementation of these 4 instructions within the CP1610 PML interpreter we get another big speed up, more than enough to get the games to run in real time. The other 38 PML instruction types remain unchanged and the interpreter continues to use the COSMAC functions in the BIOS to execute them.

 

So the BIOS and game code is inside StudioVision and the majority of it is used in the execution of the games. I have changed exactly one byte of this code. If you fire up Jzintv in debug mode and look at $9000 - $9800 you will find the Studio II BIOS and game code, it is all 8 bit. However, at address $906b you will see a single 16 bit value, $100. This marks the start of the COSMAC implementation of the PML interpreter (as you can see at address $006b in this reverse engineering of the Studio II BIOS). $100 is a not a real COSMAC opcode, it is a fake that causes the COSMAC CPU emulator to request the CP1610 PML interpreter to decode and execute a single PML instruction. This is the one and only hook into all the speedups.

 

The net effect of all these simple tricks and nonsense is that we have an emulator that can run all Studio II code, but achieves a significant speed up for PML code. So much so that PML games run more or less at full speed. StudioVision will also run the modern homebrew Studio II games, including Paul Robson’s excellent Space Invaders, Pac-Man and other arcade ports (undoubtedly the best games for the console). However, because these are written far more efficiently in COSMAC machine code, rather than PML, they can't make use of the speedups and run very slowly within StudioVision.

 

I have taken rather more care when writing StudioVision than my previous work, such that it should be possible to release the code without causing myself too much embarrassment. My intention is to do this in due course. However, I don’t want to do this until people have had a bit of a chance to find the Easter Egg. Access to the source would make this trivial.

 

 

Cheers

 

decle

  • Like 9
Link to comment
Share on other sites

Wow, that's amazing. So basically we have a very inefficient platform (or perhaps more kindly, they appear to have traded CPU cycles for ease of programming), and you're also able to optimize a bunch of drawing routines. I'd call this "mostly emulation" :) Bloody impressive.

 

I could be wrong, but this is the first I've ever seen of a system emulating a contemporary. The 2 pieces of hardware were released only 2 years apart! My next obvious question - how about a 2600 emulator next? :D Obviously we can't recreate the palette, but your comment about how much CPU is spent drawing makes me wonder...

  • Like 3
Link to comment
Share on other sites

I love the title screen transformation sequence, very creative! :)

Cheers, it was one of those evolving things. Using a monochrome Mattel screen was an obvious start. When I worked on the logo, the question of which colours to use came up, and from there I got into theming the games with network colours (initially RCA, later switched to Mattel), which then led to faking the title screens of vaguely appropriate Mattel screens and finally it came full circle to the glitchy switch between the two titles. It's funny how these things develop.

 

What are you using to track the music?

Ahh, the music, right well first thing you need to know is I’m not a musician, and the music solution is something I will revisit in future projects. The tracker decision stemmed from a much larger problem for me, where to source some easy to integrate music. To try to make things easy I decided pretty early on to make the music 2 voice, leaving the 3rd for the Studio II’s beeper, no mixing here. However, I also wanted each game to have a unique tune, so I needed plenty of music. There are a couple of retro games from my youth that use ragtime, it seems to translate well to limited voices to me. I found Warren Trachtman's website which has a load of ragtime piano midis, helpfully recorded with left and right hands on different tracks. I converted these to text using MidiCsv and used a script to strip out one note from each hand. The script creates a a simple file of DECLE statements with next to no compression (you can find the tune data at $F000 onward, typically it is 3-4K of data for 2-3 minutes of 2 track music). The tracker is a really noddy 60Hz ISR routine that I knocked up in an evening, no funky effects etc.

 

I did consider using the Intellivision Music Tracker, which looks to be an excellent piece of work, and now I have a bit more experience I would probably use it. However, at the time it was more than I needed and I was a bit intimidated by it. As I said, the tracker was a very small bit of the music problem for me.

 

To me the most interesting bit of the music is that some of the midis seem to have been recorded from live performances, certainly there are some changes in tempo and note velocity which I would would not naturally expect from an offline arrangement (and which complicate the stripping process significantly). I tried to keep these aspects in the translation process, as I think it removes some of the artificial feeling that can come through in chip tunes. That is certainly something I would look to do again.

 

I would also be interested in how other people source the music itself, especially if they have zero musical talent like me.

 

I suppose that the emulated environment is itself the little square with the game in it, right?

Yes, you are correct. If you play bowling (game 3 on Unplugged) the lane border marks the edge of the 64x32 bitmapped screen.

 

 

Cheers

 

decle

Link to comment
Share on other sites

Wow, that's amazing. So basically we have a very inefficient platform (or perhaps more kindly, they appear to have traded CPU cycles for ease of programming), and you're also able to optimize a bunch of drawing routines. I'd call this "mostly emulation" :) Bloody impressive.

I think there are two reasons for the inclusion of PML. The first as you say is ease of programming (although it does not look much easier than assembly to me) and the second is minimising game ROM size.

 

I could be wrong, but this is the first I've ever seen of a system emulating a contemporary. The 2 pieces of hardware were released only 2 years apart! My next obvious question - how about a 2600 emulator next? :D Obviously we can't recreate the palette, but your comment about how much CPU is spent drawing makes me wonder...

Unfortunately I think there is a long history of using of contemporary and even older (if more powerful) machines for emulation purposes. For example Gates and Allen used an 8008 emulator (launched 1972) running on a PDP-10 (launched 1966) to create BASIC for the Altair. This is similar to what we have here, the Intellivision and COSMAC inside the Studio II are two machines of similar power, both emulating a simpler slower PML one.

 

Now the 2600, I have to say at the outset I'm not an Atari expert, but I believe we fall foul of the way the video is subsystem works. On the Studio II the screen is bitmapped, so there is a chunk of 256 bytes of RAM and each bit maps to a pixel on screen. To draw the screen the CPU is forced to transfer the contents of this RAM to the video chip by a DMA routine. It has to do this while the screen is being drawn and it cannot run game code at this time. The transfer code is separate from the game code and resides in the BIOS. Game program code can draw to the screen at any time it is running by changing the contents of the 256 byte RAM, the changes will be picked up at the next screen refresh. From an Intellivision emulation perspective the important thing is the existence of the 256 byte frame buffer. It means that during VBLANK we can read this RAM and transfer the contents into GRAM for the Intellivision to display them. In the emulation we don't bother ever running the DMA transfer code, as it is entirely redundant, saving us 50% of the CPU time.

 

Now, to the Atari and shaky ground for me. My understanding is that the game code controls the drawing mechanism much more directly in the 2600. So as the TV beam scans the screen the game more or less directly controls the brightness and hue by bashing registers on the TIA video chip. There is no backing store of RAM or the associated decoupling of the game changing the screen and this change being drawn. To do this the 6507 CPU (which is significantly faster than the CP1610) has to be more or less dedicated to this task throughout the drawing process. In order to emulate this in a RAM backed video processor like the Intellivision it would be necessary to run the 6507 emulation throughout the drawing process to generate the necessary TIA register bashing (notice that this immediately gives up the performance benefit to the emulator of the CPU doing the drawing as the CPU emulation has to run all the time). Then the TIA emulation would need to translate the register state changes into a RAM frame buffer for later display. Finally, like the Studio II the emulation code would transfer the frame buffer into GRAM during VBLANK. I think this lot would be doable if the CPU emulation can run fast enough and there is enough spare overhead. Unfortunately I don't think the CP1610 is up to the task in this instance, but I'm willing to be proven wrong. There is also another potential problem. Each Intellivision backtab card can only have 2 colours (for the monochrome Studio II this is not a problem). Because Atari games are not written with this constraint in mind, their colourful screens would probably look a bit like a typical Spectrum game with colour attribute clash artifacts where the colours can only change at card boundaries.

 

cc.jpg

Edited by decle
  • Like 1
Link to comment
Share on other sites

Cheers, it was one of those evolving things. Using a monochrome Mattel screen was an obvious start. When I worked on the logo, the question of which colours to use came up, and from there I got into theming the games with network colours (initially RCA, later switched to Mattel), which then led to faking the title screens of vaguely appropriate Mattel screens and finally it came full circle to the glitchy switch between the two titles. It's funny how these things develop.

 

Ahh, the music, right well first thing you need to know is I’m not a musician, and the music solution is something I will revisit in future projects. The tracker decision stemmed from a much larger problem for me, where to source some easy to integrate music. To try to make things easy I decided pretty early on to make the music 2 voice, leaving the 3rd for the Studio II’s beeper, no mixing here. However, I also wanted each game to have a unique tune, so I needed plenty of music. There are a couple of retro games from my youth that use ragtime, it seems to translate well to limited voices to me. I found Warren Trachtman's website which has a load of ragtime piano midis, helpfully recorded with left and right hands on different tracks. I converted these to text using MidiCsv and used a script to strip out one note from each hand. The script creates a a simple file of DECLE statements with next to no compression (you can find the tune data at $F000 onward, typically it is 3-4K of data for 2-3 minutes of 2 track music). The tracker is a really noddy 60Hz ISR routine that I knocked up in an evening, no funky effects etc.

 

I did consider using the Intellivision Music Tracker, which looks to be an excellent piece of work, and now I have a bit more experience I would probably use it. However, at the time it was more than I needed and I was a bit intimidated by it. As I said, the tracker was a very small bit of the music problem for me.

 

To me the most interesting bit of the music is that some of the midis seem to have been recorded from live performances, certainly there are some changes in tempo and note velocity which I would would not naturally expect from an offline arrangement (and which complicate the stripping process significantly). I tried to keep these aspects in the translation process, as I think it removes some of the artificial feeling that can come through in chip tunes. That is certainly something I would look to do again.

 

I would also be interested in how other people source the music itself, especially if they have zero musical talent like me.

 

Yes, you are correct. If you play bowling (game 3 on Unplugged) the lane border marks the edge of the 64x32 bitmapped screen.

 

 

Cheers

 

decle

 

Thanks for the detailed description, very interesting.

 

As for what others use for music, most Assembly Language programmers use Arnauld Chevallier's Intellivision Music Tracker. Those using IntyBASIC employ the built-in tracker in that language framework. I think that's it.

 

There's also Carl Mueller Jr.'s sound effects and music engine, which seems to be very versatile. However, as far as I know he never released it into the wild as a utility library so it's only used in his own games.

 

If you need help using the Intellivision Music Tracker, just ask. I wrote an article once describing the data format, which is similar to the old Amiga Fast Tracker modules (MOD). In reality, any MIDI-to-MOD converter could be adapted to generate the necessary data from a music file.

 

-dZ.

  • Like 1
Link to comment
Share on other sites

Wow, that's amazing. So basically we have a very inefficient platform (or perhaps more kindly, they appear to have traded CPU cycles for ease of programming), and you're also able to optimize a bunch of drawing routines. I'd call this "mostly emulation" :) Bloody impressive.

 

I could be wrong, but this is the first I've ever seen of a system emulating a contemporary. The 2 pieces of hardware were released only 2 years apart! My next obvious question - how about a 2600 emulator next? :D Obviously we can't recreate the palette, but your comment about how much CPU is spent drawing makes me wonder...

 

How about the Atari 8-bit computer emulating the original Asteroids machine, uses the arcade roms too. Have you seen that?

 

As far as emulating the VCS on an Intellivision, I'm hesitant to say no because I'm continually amazed at the progress being made and demonstrated through projects like this.

 

I've never seen the Intellivision push pixels around as fast as a VCS, nowhere near half-fast even. It feels like there is a lot going on inside Inty that would get in the way of the bare metal feel of the VCS.

Edited by Keatah
Link to comment
Share on other sites

 

How about the Atari 8-bit computer emulating the original Asteroids machine, uses the arcade roms too. Have you seen that?

 

As far as emulating the VCS on an Intellivision, I'm hesitant to say no because I'm continually amazed at the progress being made and demonstrated through projects like this.

 

I've never seen the Intellivision push pixels around as fast as a VCS, nowhere near half-fast even. It feels like there is a lot going on inside Inty that would get in the way of the bare metal feel of the VCS.

I just played it on Altirra. Thanks, very nice. Now arcade Ateroids and the Atari 8-bit computers use the exact same CPU. So technically that might be called computer virtualisation rather than computer emulation.

 

Most Intellivision games use an old 20hz framework. Checkout Intellivision Dreadnaught Factor or Worm Whomper at 60Hz they feel quick like the 2600.

Link to comment
Share on other sites

@decle: Does the above emulator also handle programs in colour, those running on clones like the M1200 and MPT-03? IIRC those assign colours in boundaries of 8 pixels, which would suit one GRAM card each.

 

Great question! No, there is no colour handling. I had assumed that the colour would be fully bitmapped, given the existence of the doodle program. Therefore, I did not even consider looking at it. But looking here for example:

 

 

there is clearly colour attribute clashing. So if, as it seems, colour is card centric (8x8 pixels or bigger) it might well be doable.

Edited by decle
Link to comment
Share on other sites

@decle: Does the above emulator also handle programs in colour, those running on clones like the M1200 and MPT-03? IIRC those assign colours in boundaries of 8 pixels, which would suit one GRAM card each.

 

Man I am stupid sometimes. I spent ages chasing down a bug in Star Wars just after Christmas because the game was writing over and corrupting data just above the RCA Studio II memory in the StudioVision memory map. I thought it was a bit weird that the game would be assume it could write to such a high address, given the Studio II has no RAM there. I bet it was writing the colour data.

 

Thinking about it, adding colour, well adding background colour, might be a big job. StudioVision uses colour stack mode. To do arbitrary background colours per card would require a switch to foreground / background mode, with its associated limitations on colour choices, lower case text etc. Hmm need to think about that.

Edited by decle
Link to comment
Share on other sites

 

Thanks for the detailed description, very interesting.

 

As for what others use for music, most Assembly Language programmers use Arnauld Chevallier's Intellivision Music Tracker. Those using IntyBASIC employ the built-in tracker in that language framework. I think that's it.

 

There's also Carl Mueller Jr.'s sound effects and music engine, which seems to be very versatile. However, as far as I know he never released it into the wild as a utility library so it's only used in his own games.

 

If you need help using the Intellivision Music Tracker, just ask. I wrote an article once describing the data format, which is similar to the old Amiga Fast Tracker modules (MOD). In reality, any MIDI-to-MOD converter could be adapted to generate the necessary data from a music file.

 

-dZ.

 

Ahh, so I re-invented the normal approach, only more convoluted and not as good. Yup, that is pretty standard for me.

 

I'll have to look into MIDI-to-MOD and the Intellivision Music Tracker further for the next project. Thanks for the link to the article.

Link to comment
Share on other sites

As far as I know, the colour clones have one fixed background colour at a time, and then eight foreground colours on that. I never quite understood Color Stack limitations, so I don't know if that is feasible.

Color Stack mode allows you to use the first 8 colors as background (the Stack); and for the foreground you can use all colors on GRAM cards, but only the first 8 on GROM cards.

 

dZ.

Link to comment
Share on other sites

Ok, then I imagine it would work out. Actually the only two background colours I have encountered on my M1200 are dark blue (a little hard to obtain on the Intellivision, but regular blue would have to do) and dark green (which is one of the first 8 colours, it appears). Black for the B&W Studio II as already implemented. The foreground colours on the M1200 are black, red, medium blue, pink, slightly less dark green, yellow green, light blue and white, which I'm sure could be reasonably well mapped for this purpose.

  • Like 1
Link to comment
Share on other sites

 

Unfortunately I think there is a long history of using of contemporary and even older (if more powerful) machines for emulation purposes. For example Gates and Allen used an 8008 emulator (launched 1972) running on a PDP-10 (launched 1966) to create BASIC for the Altair. This is similar to what we have here, the Intellivision and COSMAC inside the Studio II are two machines of similar power, both emulating a simpler slower PML one.

 

Yeah, I guess when I say "contemporary" I also think "vaguely hardware equivalent" - at least in terms of overall power. Obviously there's always been some level of emulation on high-end equipment going on (that's how they generally wrote software in the first place, before dev kits became commonplace). I'm sure someone could easily write an Intellivision emulator on a 1979-era mainframe - but I'm thinking an INTV emulator on a Colecovision, or similar.

 

Most emulation requires at least a 10:1 jump in performance before you can even consider it, and Moore's Law aside, you didn't often see similarly-priced hardware existing at the same time with such a performance gap.

 

And as mentioned, running code on the exact same chip isn't emulation. Well, it can be, but I suspect that's not what 8-bit Asteroids is doing. I gotta assume they're executing the code natively. Still impressive, but it's more like virtualization.

  • Like 1
Link to comment
Share on other sites

Ok, then I imagine it would work out. Actually the only two background colours I have encountered on my M1200 are dark blue (a little hard to obtain on the Intellivision, but regular blue would have to do) and dark green (which is one of the first 8 colours, it appears). Black for the B&W Studio II as already implemented. The foreground colours on the M1200 are black, red, medium blue, pink, slightly less dark green, yellow green, light blue and white, which I'm sure could be reasonably well mapped for this purpose.

The problem will be cycling the stack to get the proper background colours.

Link to comment
Share on other sites

 

Yeah, I guess when I say "contemporary" I also think "vaguely hardware equivalent" - at least in terms of overall power. Obviously there's always been some level of emulation on high-end equipment going on (that's how they generally wrote software in the first place, before dev kits became commonplace). I'm sure someone could easily write an Intellivision emulator on a 1979-era mainframe - but I'm thinking an INTV emulator on a Colecovision, or similar.

 

Most emulation requires at least a 10:1 jump in performance before you can even consider it, and Moore's Law aside, you didn't often see similarly-priced hardware existing at the same time with such a performance gap.

 

And as mentioned, running code on the exact same chip isn't emulation. Well, it can be, but I suspect that's not what 8-bit Asteroids is doing. I gotta assume they're executing the code natively. Still impressive, but it's more like virtualization.

What is the actual difference you are making between "virtualization" and "emulation"? If you have object code written for a target CPU which has been implemented in software on a different system, that's a virtual machine. But isn't that also what jzIntv and MAME do?

 

My understanding was that, traditionally, a virtual machine was specifically because the target machine does not exist physically, so there is no actual physical architecture to execute the code except a software program. Think of JAVA, Infocom's Z-Machine, a BASIC interpreter, SCUMM, etc.

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