Keatah Posted January 3, 2017 Share Posted January 3, 2017 https://en.wikipedia.org/wiki/Virtualization Virtualization is more like isolation and protection, running the same native instructions as the hardware. With many iterations possible. Not unlike hyper-threading, where you have a virtual core and real one. Emulation, in terms as we understand it, is running alien non-native code on something. There is big potential here to get caught up in semantics so I suggest a new thread. Quote Link to comment Share on other sites More sharing options...
decle Posted January 3, 2017 Author Share Posted January 3, 2017 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. Yes, with the restriction to one background colour I think this could be made to work without switching screen mode. This possibility opens the artistic question, should it be done? I think a part of the feel of StudioVision is the monochrome nature of the games. Quote Link to comment Share on other sites More sharing options...
carlsson Posted January 3, 2017 Share Posted January 3, 2017 As a proof of concept, I think StudioVision is great as it is. As a service to a community of Intellivision users who fancy the idea to play clone versions of a never released, almost contemporary system that anyway would have bombed completely compared to the competition - in particular the Intellivision itself - you may still consider this as a future addition. Quote Link to comment Share on other sites More sharing options...
decle Posted January 3, 2017 Author Share Posted January 3, 2017 (edited) 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. I think this breaks down into two parts. If we assume that the host is Turing complete, I believe the only absolute constraint to emulating a target is having enough memory and / or backing store on the host to represent the full state of the target. Even this constraint can be relaxed in some circumstances by using greater memory compression in the host than is present in the target. Typically this ratio of required memory is close to 1:1 because the size of the target machine state is typically dominated by memory and backing store. Other bits a pieces like registers are negligible. You can artificially raise this ratio trading memory efficiency in order to gain performance, which brings us to the second aspect. The second part is the performance of the emulated system relative to the target. Here I think your suggested ratio of 10:1 is typical of a simple interpreting emulator. This can vary quite a bit depending on how well matched the target and host are. This ratio can also be reduced significantly using techniques like Just-In-Time compilation. I think the best example of this is Apple's Rosetta software used in the switch from PowerPC to Intel processors. Although the numbers are disputed there are suggestions that the ratio was about 2:1 in this case. Bringing this back to StudioVision, things are not quite as they seem, because of the PML interpreter / emulator within the Studio II. What we have is that the combined performance of the CP1610 native and COSMAC emulated bits of the StudioVision PML interpreter are roughly the same as the Studio II's all COSMAC PML interpreter running half the time. When stated like this it is not nearly so impressive. The only reason StudioVision is in the same ballpark is because the Studio II is also running an emulator. As I think I said earlier, the most important thing when emulating on the Intellivision is to be really picky about what you target. I have not measured the relative performance of COSMAC CPU emulator within StudioVision to the actual COSMAC CPU, but I would expect it is nearer 20:1 than 10:1. This is primarily because of the poor architectural match between the CPU's. The COSMAC has 16, 16 bit registers in addition to its 8 bit accumulator (so these have to be stored in memory on the Intellivision not in registers), all of which must be manipulated 1 byte at a time because of the 8 bit accumulator (something the CP1610 cannot do natively) and any of which could be selected to be either the program counter or stack pointer (again has to be modelled in software on the Intellivision). The native bits of the StudioVision PML interpreter make up for this complexity by being run more of the time (the 50% the real Studio II spends drawing the screen) and being optimised to the CP1610's 8 16bit register architecture, rather than being a straight translation. For example here is the main PML decode loop of the COSMAC PML interpreter, as reverse engineered by Paul Robson: MainLoop: ; Main interpreter loop ghi r6 ; 006b:96 ; Set 2nd variable High phi r7 ; 006c:b7 ; ghi r4 ; 006d:94 ; RC.High := $00 phi rc ; 006e:bc ; lda r5 ; 006f:45 ; Read instruction, adv R5 plo rc ; 0070:ac ; RC.Low := Instruction plo rf ; 0071:af ; RF.Low := Instruction shr ; 0072:f6 ; Put 4 MSB of instruction into D shr ; 0073:f6 ; shr ; 0074:f6 ; shr ; 0075:f6 ; bz CodeExec ; 0076:32 94 ; If zero, exec as code ori AddrTable & 255 ; 0078:f9 e0 ; D := E1-EF (depends on inst MSN) plo rc ; 007a:ac ; RC points to instr addr table glo rf ; 007b:8f ; D = original instruction ani 00fh ; 007c:fa 0f ; D = C0-CF (inst LSB) ori Variables & 255 ; 007e:f9 c0 ; plo r6 ; 0080:a6 ; R6.Low = C0-CF (Instr Byte1 LSN) ldn r5 ; 0081:05 ; Get instruction 2nd byte shr ; 0082:f6 ; Isolate MS Nibble shr ; 0083:f6 ; shr ; 0084:f6 ; shr ; 0085:f6 ; ori Variables & 255 ; 0086:f9 c0 ; R7.Low = C0-CF (Instr Byte2 MSN) plo r7 ; 0088:a7 ; lda rc ; 0089:4c ; Read Instruction Addr High phi r3 ; 008a:b3 ; Into R3.High glo rc ; 008b:8c ; Add 15 to address table now adi 00fh ; 008c:fc 0f ; F1-FF [16 total with LDA] plo rc ; 008e:ac ; lda rc ; 008f:4c ; Read Instruction Addr Low _Execute: plo r3 ; 0090:a3 ; Exec Addr.Low := R3 sep r3 ; 0091:d3 ; And jump there br MainLoop ; 0092:30 6b ; Loop back on return ; ; Execute instructions as code. ; CodeExec: glo rf ; 0094:8f ; Get Instruction Byte ani 00fh ; 0095:fa 0f ; Get Addr 4 MSB phi r3 ; 0097:b3 ; Put in R3 lda r5 ; 0098:45 ; Get Low Byte of Address br _Execute ; 0099:30 90 ; and Jump there And here is the alternative CP1610 equivalent also present in StudioVision, you can still see traces of the original in the comments, but much of the hard stuff is now done 16 bits at a time using lookup tables, rather than bashing the high (ghi / phi) and low (glo, plo) bytes of various 16 bit registers: ; ------------------------------------------------------------------------------ ; pMain - Heavily optimised main interpreter loop. This gives the largest ; performance improvement. The original RCA1802 main loop is 34 instructions ; long. This would take ~350 CP1610 instructions to implement, taking ~3000 ; cycles per Studio 2 virtual machine instruction. This would lead to a ; maximum throughput of ~320 virtual machines instructions per second, even ; if the instruction implementations were trivial. ; ; This version is 27 CP1610 instructions long. It ; raises the maximum theoretical throughput to ~4000 virtual machine ; instructions / sec. This compares favourably with the ~1650 virtual ; machine instructions / sec that the Studio 2 can reach. However, this speed ; up is required as the implementation of most virtual machine instructions are ; fully interpreted, and therefore, are much slower. @@pMain MVI R1802.r5, R5 ; $6f - lda r5 INCR R5 ; MVO R5, R1802.r5 ; ADDI #S2.mem.baseOffset, R5 ; keep address in R5 for later MVI@ R5, R1 ; MVO R1, R1802.rf ; $71 - plo rf ; MOVR R1, R0 ; cache lsb of instruction ANDI #$f, R0 ; ; SARC R1, 2 ; $72 - shr, shr SARC R1, 2 ; $74 - shr, shr BEQ @@pMainCodeExec ; $76 - bz CodeExec ; ADDI #@@pMainInstrAddr, R1 ; optimised jump address eval MVI@ R1, R4 ; store pre-incremented PC in r3 MVO R4, R1802.r3 ; ADDI #$10, R1 ; load pre-computed first opcode MVI@ R1, R1 ; instruction table entry ; XORI #$8c0, R0 ; $7e - ori $c0 MVO R0, R1802.r6 ; $80 - plo r6 ; MVI@ R5, R0 ; $81 - ldn r5 SARC R0, 2 ; $82 - shr, shr SARC R0, 2 ; $84 - shr, shr XORI #$8c0, R0 ; $86 - ori $c0 MVO R0, R1802.r7 ; $88 - plo r7 ; MVII #$6b, R0 ; correct PC MVO@ R0, R3 ; MVII #R1802.r3, R3 ; $91 - sep R3 ; MVI@ R1, R7 ; execute instruction ; @@pMainCodeExec ; call native code, less optimised case ; phiCore r3 ; $97 - phi r3 ldaCore r5 ; $98 - lda r5 ploCore r3 ; $90 - plo r3 ; MVII #$6b, R1 ; correct PC MVO@ R1, R3 ; MVII #R1802.r3, R3 ; $91 - sep R3 dispatchInstr ; ; @@pMainInstrAddr ; instruction address table ; DECLE $000, $0d3, $0cb, $0c0 ; DECLE $0c5, $24f, $0ba, $23e ; DECLE $09c, $257, $0da, $2e6 ; DECLE $0b0, $2c0, $101, $2a5 ; ; @@pMainInstrOpcode ; instruction opcode table ; DECLE $d000, $d045, $d015, $d006 ; DECLE $d006, $d045, $d045, $d086 ; DECLE $d022, $d096, $d086, $d045 ; DECLE $d086, $d102, $d101, $d045 ; Something that has occurred to me is StudioVision does show that back in the day Mattel could have produced a relatively simple hardware adapter, similar to the ShockVision adapter, that would have allowed the Intellivision to play any of the RCA Studio II game cartridges directly, potentially without infringing on RCA's copyrights. And this could have given Studio II owners with games an upgrade path to the Intellivision. Clearly given that the Studio II was not a commercial success this is unlikely to ever have been considered, but I think the technical possibility is interesting. Edited January 19, 2017 by decle 1 Quote Link to comment Share on other sites More sharing options...
mr_me Posted January 3, 2017 Share Posted January 3, 2017 https://en.wikipedia.org/wiki/Virtualization Virtualization is more like isolation and protection, running the same native instructions as the hardware. With many iterations possible. Not unlike hyper-threading, where you have a virtual core and real one. Emulation, in terms as we understand it, is running alien non-native code on something. There is big potential here to get caught up in semantics so I suggest a new thread. Yes, I think virtualisation was the wrong word to use. I'm guessing Asteroids code was ported to the Atari 8bit. Ported in the strictest sense without conversion or translation since the CPUs are the same. Some parts for controls, sound, and display likely rewritten. The did something similar with pacman on colecovision. The StudioVision does have a software CPU emulator, although only a portion of the game code is being CPU emulated. Quote Link to comment Share on other sites More sharing options...
decle Posted January 7, 2017 Author Share Posted January 7, 2017 Hi everyone,I've added a couple more games to the top of the thread, Baseball and Star Wars. When you look at the progression of Baseball from the Studio II and Fairchild Channel F; through the versions for the 2600 and Intellivision; and on into the Colecovision and NES, I think it illustrates just how quickly developers learned to exploit the various consoles of the late 1970s and early 80s.Star Wars is also quite interesting, as well as being one of the first Star Wars video games, it was developed late in the console's life for the ill-fated Studio III. It only saw distribution for licenced clone consoles released in Europe and Australasia. As Carlsson discussed earlier, these clones could generate colour graphics, and while Star Wars supports colour, it only plays in black and white on the monochrome Studio II.Cheersdecle 2 Quote Link to comment Share on other sites More sharing options...
decle Posted January 14, 2017 Author Share Posted January 14, 2017 Hi everyone,End of week 2 of the StudioVision project and I've added a couple more games to the top of the thread, Speedway / Tag and Biorhythm. Speedway is a two player racing game over 9 laps in the vein of a simplified Gran Trak 10 or Sprint 2. Cars can only move in 4 directions, with steering following the Auto Racing "intuitive" model. Although very simple. the cars do accelerate and recovering your lost speed is the main penalty for crashing. Tag is also a two player game. The objective is to score the most points in two minutes by tagging your opponent within 10 seconds.Biorhythm predicts your biorhythms, go figure. It accepts dates in 4 digit year format and judging by a comparative plot obtained from the Interwebnets the Studio II version does not suffer from Y2K issues and continues to work (slowly) to this day. So it predicts at least the existence of the 21st century correctly .I think I'll release details of the Easter Egg within StudioVision with the next couple of games. If anyone is looking for it and would rather I didn't please let me know.Cheersdecle 2 Quote Link to comment Share on other sites More sharing options...
decle Posted January 21, 2017 Author Share Posted January 21, 2017 Hi all,Week 3 of the StudioVision project, as you have probably guessed by now I've added a couple more games to the top of the thread, Pinball and Bingo this time.Like Intellivision Pinball the Studio II version suffers from the choice to make the table landscape rather than portrait. This makes the RCA engineer's decision to make matters worse by putting the score and ball count at the top of the screen, rather than the side, particularly puzzling. I also find that, like Intellivision Pinball, the ball finds the drain rather too easily. Or alternatively, I'm not very good at pinball.Bingo is interesting because it is unclear if it ever saw a release in the US. One or two cartridges have turned up in the last 40 years, most recently in late 2015, otherwise it has a mythical status, not dissimilar to 8K Lock 'N' Chase. The copy discovered in 2015 was dumped and the ROM found to be the same as the more common European version released for the later colour Studio II clones. The game itself is essentially a random number generator and is rather pointless without the bingo cards and chips which came with the it.That puts us at 12 down, four to go. Cheersdecle 1 Quote Link to comment Share on other sites More sharing options...
decle Posted January 21, 2017 Author Share Posted January 21, 2017 Hi everyone,As promised, here are details of the Easter Egg within StudioVision.Interestingly, mr_me was on the money with the very first question about StudioVision:"Is there any reason you can't double up on the resolution?"Kudos!My answer to this question was technically correct, a standard Intellivision cannot do this because it does not have enough GRAM to store the double resolution bitmapped screen. However, because StudioVision was developed on an emulator, it is not necessarily constrained to the capabilities of a standard Intellivision. I patched my development version of Jzintv to allow it emulate an Intellivision with more GRAM, like the World Book Tutorvision has. StudioVision is written to spot whether the additional GRAM is present, and if so, use it to double the screen resolution. Here are a couple of videos that show Bowling running in small and large screen mode for comparison: All StudioVision ROMs have this capability, and always have done. If you want to try the large screen mode you can patch Jzintv 1.0 beta4 (the latest version for which source code is available) with the following file:patchJzintv-1.04.txtThis patch does two things. Firstly, it fixes a small bug that prevents keyboard hack files working correctly (Joe fixed this some time ago in the dev releases). Secondly, it adds a new flag (-G) to the command line to select the amount of Intellivision GRAM. Valid values are: 0 - 512bytes / 64 GRAM characters, the default value and the size of the standard Intellivision 1 - 1024bytes / 128 GRAM characters 2 - 2048bytes / 256 GRAM characters, enough to make the whole screen addressable as a bitmap In order to activate StudioVision large screen mode it is necessary to use -G2Even with the additional RAM it was quite difficult to get the larger resolution to work well. This is because the time available to access GRAM during VBLANK is very limited. This makes it tough to blit the data needed to update the screen quickly enough to maintain smooth movement. Unlike the StudioVision small screen mode, which is locked to a 30Hz update rate, large screen mode uses a variable refresh rate and only updates changed or dirty lines of the 32 line Studio II screen. This means that the refresh rate can be anything from 9Hz to 60Hz depending upon how much of the screen has changed. For the most part this seems to work well, as the Studio II's limitations mean that not much changes from one frame to the next. The one exception is Freeway on StudioVision - Unplugged. The scrolling road regularly dirties the whole screen, dragging the refresh rate down and making the gameplay rather choppy. That said, it does work.Anyway, I hope this is of interest, certainly it is the most innovative feature of StudioVision and pushes the boundaries of Intellivision homebrew state-of-the-art a bit. It was also probably the most challenging aspect to design, implement and tune, which explains why I was keen for it to be found. Cheersdecle 5 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 23, 2017 Share Posted January 23, 2017 Great work. I wonder if Joe Z. would be interested in adding the GRAM size option to the mainline of jzIntv. It seems useful for emulator-only ROM releases. 1 Quote Link to comment Share on other sites More sharing options...
mr_me Posted January 24, 2017 Share Posted January 24, 2017 Hi everyone, As promised, here are details of the Easter Egg within StudioVision. Interestingly, mr_me was on the money with the very first question about StudioVision: "Is there any reason you can't double up on the resolution?" Kudos! My answer to this question was technically correct, a standard Intellivision cannot do this because it does not have enough GRAM to store the double resolution bitmapped screen. However, because StudioVision was developed on an emulator, it is not necessarily constrained to the capabilities of a standard Intellivision. I patched my development version of Jzintv to allow it emulate an Intellivision with more GRAM, like the World Book Tutorvision has. StudioVision is written to spot whether the additional GRAM is present, and if so, use it to double the screen resolution. Here are a couple of videos that show Bowling running in small and large screen mode for comparison: unpluggedSmall.gif unpluggedLarge.gif All StudioVision ROMs have this capability, and always have done. If you want to try the large screen mode you can patch Jzintv 1.0 beta4 (the latest version for which source code is available) with the following file: patchJzintv-1.04.txt This patch does two things. Firstly, it fixes a small bug that prevents keyboard hack files working correctly (Joe fixed this some time ago in the dev releases). Secondly, it adds a new flag (-G) to the command line to select the amount of Intellivision GRAM. Valid values are: 0 - 512bytes / 64 GRAM characters, the default value and the size of the standard Intellivision 1 - 1024bytes / 128 GRAM characters 2 - 2048bytes / 256 GRAM characters, enough to make the whole screen addressable as a bitmap In order to activate StudioVision large screen mode it is necessary to use -G2 Even with the additional RAM it was quite difficult to get the larger resolution to work well. This is because the time available to access GRAM during VBLANK is very limited. This makes it tough to blit the data needed to update the screen quickly enough to maintain smooth movement. Unlike the StudioVision small screen mode, which is locked to a 30Hz update rate, large screen mode uses a variable refresh rate and only updates changed or dirty lines of the 32 line Studio II screen. This means that the refresh rate can be anything from 9Hz to 60Hz depending upon how much of the screen has changed. For the most part this seems to work well, as the Studio II's limitations mean that not much changes from one frame to the next. The one exception is Freeway on StudioVision - Unplugged. The scrolling road regularly dirties the whole screen, dragging the refresh rate down and making the gameplay rather choppy. That said, it does work. Anyway, I hope this is of interest, certainly it is the most innovative feature of StudioVision and pushes the boundaries of Intellivision homebrew state-of-the-art a bit. It was also probably the most challenging aspect to design, implement and tune, which explains why I was keen for it to be found. Cheers decle So what happens in your modified emulator when you have expanded GRAM and run an original Intellivision game? Does it work? 1 Quote Link to comment Share on other sites More sharing options...
decle Posted January 24, 2017 Author Share Posted January 24, 2017 So what happens in your modified emulator when you have expanded GRAM and run an original Intellivision game? Does it work? Cool question. I expect many existing games will continue to work as before, despite the additional GRAM. I've only tried a couple, but they seem to be OK. The Intellivision sets aside 2K for GRAM in the memory map, so the additional RAM does not trample over other things. While the standard machine only has 512 bytes these are repeated 4 times to fill the 2K space. So reading or writing to address $3800, $3a00, $3c00 or $3e00 all access the same memory location. Setting things up for 2K of GRAM means this is no longer true. There are two ways in which this change can cause problems. Firstly, if a game were to update GRAM through the one of the copies instead of using the addresses from $3800 to $39ff adding more GRAM would lead to strangeness. However, I'm not sure there is a good reason for a developer to do this, of course that does not mean it is not done. Secondly, repeating the 512 bytes or RAM effectively frees 2 bits of each card definition in the Backtab. This happens because if a program tries to access GRAM image 64 from memory location $3a00 it will actually get image 0 from $3800, because location $3a00 accesses the same memory location as $3800. So GRAM image 0 = 64 = 128 = 192, the 2 high order bits of the GRAM image number make no difference to the image shown, and so can be used by the programmer for other things. There are good reasons to make use of these bits, but I don't know which if any games do. Perhaps other people do? Quote Link to comment Share on other sites More sharing options...
mr_me Posted January 24, 2017 Share Posted January 24, 2017 Yes, thats it. I couldnt remember exactly but Joe once said that for the Tutorvision to be truely backward compatible it would have to have a way to turn the extra gram on/off. There must be some games that use those two bits. Or maybe the Tutorvision is not 100% backward compatible. Thanks for explaining it. 1 Quote Link to comment Share on other sites More sharing options...
decle Posted January 24, 2017 Author Share Posted January 24, 2017 Yes, thats it. I couldnt remember exactly but Joe once said that for the Tutorvision to be truely backward compatible it would have to have a way to turn the extra gram on/off. There must be some games that use those two bits. Or maybe the Tutorvision is not 100% backward compatible. Thanks for explaining it. Ahh, yes. This is the thread: http://atariage.com/forums/topic/189302-is-the-tutorvision-rarer-than-the-keyboard-component/page-3 As Joe suggests, quickly playing Space Patrol does show the problems. The rocks flicker and the enemy space ships are invisible when extra GRAM is enabled. It looks as though he found problems with other games too. Quote Link to comment Share on other sites More sharing options...
Kiwi Posted January 25, 2017 Share Posted January 25, 2017 I was going to suggest color square mode for full screen resolution of RCA studio 2 games. I then realized that mode would give you 40 by 24 pixels, RCA renders at 64x32 resolution. I'm really impressed by the emulation and how you got it working for the Intellivision. 1 Quote Link to comment Share on other sites More sharing options...
decle Posted January 28, 2017 Author Share Posted January 28, 2017 Hi all,Week 4 of the StudioVision project and I've added couple of "edutainment" titles, Math Fun and Concentration Match, to the top of thread.Math Fun is rather like, well Math Fun. Only without the gorillas, river or bongos. OK so it might be more math than fun. On the plus side it doesn't have the annoying music. For the curious, the Studio II uses forward entry and to make things just a little bit more difficult entries only become visible if the complete, correct answer is entered.Concentration Match is a foreign clone release of the card game Pairs. It is not terribly hard as there are only 9 pairs of cards in play.Cheersdecle 2 Quote Link to comment Share on other sites More sharing options...
killersquirel Posted January 28, 2017 Share Posted January 28, 2017 I just stumbled onto this thread and wanted to say how awesome this is. I won't be able to try it out until a couple of days from now, but I'm eagerly waiting to give this a go. Thanks for making this! 1 Quote Link to comment Share on other sites More sharing options...
+eebuckeye Posted January 28, 2017 Share Posted January 28, 2017 These are awesome! Thanks for doing it! 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted January 31, 2017 Share Posted January 31, 2017 Secondly, repeating the 512 bytes or RAM effectively frees 2 more bits of each card definition in the Backtab. Fixed that for ya . You can also use bits 14 and 15 in BACKTAB cards for other purposes too. Quote Link to comment Share on other sites More sharing options...
decle Posted February 4, 2017 Author Share Posted February 4, 2017 Hi everyone, Penultimate week of the StudioVision project and we have reached the end of the US and Foreign releases. I've added the last couple of games, School House 1 and Grand Pack, to the top of thread.School House 1 is a series of pop quizzes on subjects like Geography, Politics and Maths (again!). You cannot play with a better than 1 in 10 chance of randomly guessing the correct answer without access to the quiz booklets. These can be found here.Grand Pack is a foreign release for the Studio III clones. It seems to take the place of the games built into the Studio II console. Like the built in BIOS ROM it contains Doodle, Patterns and Bowling. However, Freeway and Addition are replaced with Blackjack. Grand Pack brings us full circle for the last game, to a pack in game compilation like Unplugged. Cheersdecle 2 Quote Link to comment Share on other sites More sharing options...
Rick Reynolds Posted February 9, 2017 Share Posted February 9, 2017 Hey Decle,I came across this website and saw this guy has a basic Space Invaders homebrew for the Studio II. Any chance of getting that rom put into your very fine emulator-on-inty? Or are things not really that simple... He has a couple other homebrews also, but I really love the idea of being able to play a space invaders clone. http://www.robsons.org.uk/archive/www.classicgaming.com/studio2/index.htm 1 Quote Link to comment Share on other sites More sharing options...
decle Posted February 9, 2017 Author Share Posted February 9, 2017 Hey Decle, I came across this website and saw this guy has a basic Space Invaders homebrew for the Studio II. Any chance of getting that rom put into your very fine emulator-on-inty? Or are things not really that simple... He has a couple other homebrews also, but I really love the idea of being able to play a space invaders clone. http://www.robsons.org.uk/archive/www.classicgaming.com/studio2/index.htm Hi Rick, Paul's conversions are without doubt the best Studio II games available, so I understand why you would be interested in seeing them. Unfortunately, while I have tested them, I'm not intending to release them. One of the reasons the games are so good is because they are written in RCA1802 assembler, rather than the Pseudo Machine Language (PML) code. This means that they are far more efficient than the RCA games. Unfortunately the inefficiency of the PML games is needed to run in real time, so while StudioVision will run Paul's games, they run slowly. I don't want to discredit Paul's work by releasing something that would not do it justice. Had StudioVision done a good job I would have approached Paul for permission, but as it does not I did not get that far. Invaders is probably the nearest of Paul's games to running well. Initially it plays well However, there is a small pause whenever the invaders move, as StudioVision cannot keep up with Paul's clever programming. Unfortunately as the game progresses and the invaders speed up this dominates and the game becomes unplayable, you simply cannot move or shoot quickly enough. I want to be absolutely clear at this point, this is a shortcoming of StudioVision and not Paul's code. I think it would be possible to fix this by recoding Paul's invader move code in CP1610 machine code, but I think this would be cheating and so I have not tried. Sorry to disappoint decle 2 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted February 9, 2017 Share Posted February 9, 2017 What about a recompilation before execution? or more commonly named JIT (Just In Time) 1 Quote Link to comment Share on other sites More sharing options...
decle Posted February 9, 2017 Author Share Posted February 9, 2017 What about a recompilation before execution? or more commonly named JIT (Just In Time) Not cheating, but currently beyond my computer hacking (or nunchuck) skills. 1 Quote Link to comment Share on other sites More sharing options...
carlsson Posted February 9, 2017 Share Posted February 9, 2017 (edited) Lee Romanow's homebrews (Climber etc) however seem to be made in PML so those would run on the StudioVision, I believe. With the exception of the diagnostics program by Flip, it seems Paul Robson is one of the very few to ever have made application software for the Studio 2 in pure 1802 machine code. Almost everyone else went through PML. So for any aspiring developer, you have two choices: machine code for maximum speed on real console, or interpreted language to be emulator friendly. Edited February 9, 2017 by carlsson Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.