Back in the day... I was a Plus/4 and C64 user back in the day (and still am too), but since I'm in the US, there was nothing more than a handful of titles released in the US for the Plus/4. I used to use my Plus/4 for a programming machine since it was so much easier in BASIC.
But once I started hitting sites like this, I noticed that a lot of groups converted software from the C64 over to the Plus/4. Since obviously they didn't reprogram them from the ground up - how was this done? Was it a matter of finding programs that weren't heavy in sprite usage, disassembling them on the C64 and redirecting it to the proper locations on the Plus/4? The amount of work doing this must have been incredible back in the day since the tools that exist now didn't then. What all was involved?
Re: Back in the day... Hi, back in the day I was a teen, and was really amazed by Pigmy's work on converted games. I made with him some chat (via snail mail) and got some technical insight, although I am not able to replicate them in real life, here it is: (If you check te SVS Ultimate map, you will find some direct references to C64 registers, memory maps, etc)
-The char and GFX modes are pretty similar on the two machines, especially hires. (in multi modes there are extra limitations on +4,need special attention or manual settings). In such modes only the addresses, color codes, charsets and the register modification settings needed to be converted/changed in the programs torun on +4. The main routines, the UI, the AI, all can work and run the same way, if they fit too the proper address TED does not use. If I remember well, the zero page requried special attention, maybe Plus/4 has less space, while ob C64 they use it very actively due to extra speed.
These are how the text adventures and the simplier gfx adventures converted by Pigmy. (Hobbit, Hulk, Eric the viking, etc). I liked them all. If there was no sprite cursor, music or animation, it was easily converted by him. Certainly, you need a certain level of experience and knowledge to do that, but he mentioned a specific game (maybe Spiderman?) he converted only in 4 hours + small finetunings) It is a kind of impressive, right? I think he was 15 or 16 at that time. What a genius.
-When you have one sprite cursor, and a fully GFX GUI (Tass Times, etc) then he realized a software sprite in a resident driver, continuously storing the original background, then put with XOR the sprite bitmap (should use background and Color3 in multi, these do not cause color bleeding) then when move it, then XOR it again (=remove it) and store the next position background GFX, then XOR it again, etc. Reading out the position is done by the original SW, he just need to use the original addresses for positioining. On +4 there is no mouse, just joystick control. It is very raster time eating process, and together with SID emulation (even if it is only FRQ convertion) it brings the Plussy to it'slimits.
Certainly it did not work on character modes, as the XORing only works with bitmap. You can replicate this multicolor software sprite in BASIC3.5 with GSHAPE and SSHAPE commands. Expacially color3 is useful, if you do not want to do a screen with fully inverted way (I mean background color is then not used as bacground,but as a drawing color and the bacground is in fact filled with color1 and color2 thingies).
In BASIC is is damn slow, but I was able to move around a "soft spitre" pointer on a Multicolor bitmap without any color bleeding or loss of background information. Maybe with Compilers it would be much faster, but Austrospeed does not compile the GFX commands (as far as I know) and +4Comp still fails in all the way it can.
You may check Magicians Curse, it is a very nice and fast software sprite emulation. Only the first was made properly, the later amateur changes did not understand the reverse logic behind how SW sprite works on Plussy.
-3D HIRES and Multi games (Head Over Heels, Driller, Elite, etc) required the least effort, though the software sprite in the later certainly caused challenges (also the fixed 3rd color on plussy makes some interesting results). But in black and white mode it was rather easy to implement (?).
-Spectrum games maybe the most straightforward, unfortunetely they are made in a different assembly dialect
-Fast animations, simulation of multiple C64 sprites (?) exceeds my knowledge. Sprite simulation in hires modes without color bleeding: I think it is impossible.
Sorry if I did any mistake in the above descriptions, there are guys who know MUCH better these things, not to mention that some of them even PRACTICE it too They will correct me, and PLEASE do it.
Also, I have to mention, that the general knowledge on these tricks/magics became well known and widely used by the more expert programmers here (Csabo, Luca, Skoro, KICHY, gerliczer, MAD, TLC, etc). I mean almost anyone else than me :-)
Re: Back in the day... Just my two cent, since I plan to convert my current plus/4 experiment to the c64, too. The C64 and the plus/4 do have almost the same graphic modes.
There is one difference: If you have multicolor bitmap mode, then the plus/4 supports 2 free colors per 4x8 block and 2 solid ones for the entire image. On the C64 you have in this mode 3 free colors per 4x8 block and 1 solid color (backgroundcolor) for the entire image.
If you port from the C64 to the plus/4 it's also pretty easy to convert the colors, since the plus/4 has some (of the 121) colors which are somehow close to the 16 ones of the C64.
However what's really bad about the C64 is, that you can't have real doublebuffering, because the colormatrix is always at the same location (the screenmatrix can be changed, though). On plus/4 you can change screenmatrix and colormatrix to reside in every location you want (of the 64kb).
I don't know anything about sprite handling back in the days, however it is pretty hard to code a fast routine which uses low memory (both at once). You can do very fast sprites if you stick to just one color for the sprite. And you can even do very fast sprites if you consume a lot of memory, however memory is a resource you should handle wisely, so perhaps do some (a little) slower sprites.
If it comes to sprite colors, the plus4 is sadly a little of. You could do sprites with their own colors, but you must somehow handle color clashing then or choose the location of the sprites in the level wisely (e.g. no background graphics). The easiest approach is to reserve some colors for the sprites (for instance 2 in bitmap mode, which would be the same for the entire image), you could use these 2 colors also for the background, but you will have to somehow make sure the sprite is not vanishing because of indistinguable colors (between the sprite and the background). So my assumption would be, that plus/4 games always would have less colourful sprites than their c64 pendandts, or you just have no background graphics behind them.
I didn't mention, that the c64 can use the same code like the plus/4, because it's the same "processor family". However the plus/4 should be a little faster. But as Krill pointed out, in reality it seems a little slower because of more graphics updates per frame. You can make the plus/4 really faster, by disabling graphics output after some screen line, though.
I think porting games without sprites to the plus/4 is not that big of a deal. If it gets to sprites, then it somehow gets complicated. Soundtechnically I just have no clue, but there are sid converters as far as I know and it seems, that most of the people own a SIDCard, too. If you use a SIDCard than the porting is done by just changing some adresses in the code, as far as I know!
Hope this helps a little, and perhaps some other people also do have some (perhaps opposing) points..
Re: Back in the day... Hah, all this talking about conversions take me back to the time when Dizzy 3 (Fantasy World Dizzy) got 4 versions to be really fixed
About comparing the bitmap graphics, I can't avoid this famous repost.
Re: Back in the day... Well, I know it is a lot of other things involved, (drawing routines, etc), but why the Plus/4 Elite runs only marginally faster than the C64, while the C128 (seems to e in VICII mode) looks pretty fast comapred the two? The PI calculation showed, that the Plus/4 should have the very same raw processing power as the C128. Maybe the C128 Elite version has a more optimized drawing routine? Or what I left out ?
Re: Back in the day... @Luca: The guy in the main comment of the YouTube page seems to be quite a moron. What better bitmap layout is he talking about?
Re: Back in the day... MMS did you take into account, that the plus/4 is a lot faster with the screen disabled? For me it's a bit scary that the C64 really is that much slower (for me it really looks a lot slower), some people told me that with the badlines the plus4 should be almost at the same margin like the C64..
Re: Back in the day... @Mad: The C64 being that much slower is actually not really surprising if one does some little math. One frame consists of 312*63-25*43=18581 available cycles for the C64 (worst case in all badlines and no sprites), while 112*109+25*6+65+25*2*22=23058 available cycles for the +4 (worst case in all badlines and no slow clock). Although the frame rate is a bit higher in the C64, AFAIR.
Re: Back in the day... That means, that the plus/4 is around 1.2409450514 times faster than the C64 under normal conditions. That really was not clear to me at all. ( Perhaps I just get a hard time converting the stuff from plus/4 to C64 let's see. )
Re: Back in the day... I've just added a comment to the youtube's video. C64/PAL has higher (!) frequency of CPU than C+4 (0.96 vs 0.89 MHz) and C64 uses one badline while C+4 uses 2. C+4 advantage is hardware double frequency on borders, C128 may use double frequency at the vertical borders by software. C+4 is only 25% faster than C64 in the standard screen mode but maybe up to 130% faster without screen. It is interesting to compare Commodore versions with BBC Micro which may use true 2 MHz with CPU. IMHO Elite for Spektrum or Amstrad has poor quality.
Back in the day...
