WARNING : Don't play kids. Don't play it at work either.
This is a repo for all of the versions of Copyright Infringement : The regressive right, a game where Rikuto has trapped you in one of his games and paired you with another mate. It is a very short game that was initially made for the Colecovision to demonstrate that it is possible to achieve FMVs on the Colecovision through the use of MegaROM bank switcher.
Later, another unrelated game for the TI-99/4a (Dragon's Lair) took it a step further and did full motion video with PCM sound at 13khz and on a gigantic 512MB rom !
This is so far the only port to use sprites for the HUD as the other ones so far don't use it.
Why the MSX ? Originally i wanted to do a straight port of the Colecovision as the two share the same VDP (at least for MSX1). However i thought it would be a shame to restrict myself to MSX1 and i also encountered an issue with ASCII16 that is said to have a 512kb limit on real hardware. I did not want to risk real hardware compatibility while i wait for my MSX2 to arrive so this version is MSX2 only.
I also did consider an MSX2+ version but pushing YJK frames at decent speeds on it will be very challenging and i want to avoid requiring a boosted Z80 like on Panasonic's models or even a TurboR so this version will have to wait for one.
This one does not use sprites unlike the Colecovision : only a part of the screen is being refreshed. The other reason is that, while i could make sprites work on MSX1, they work differently on MSX2.
However if i work on an MSX1 port, i will have to use sprites again due to the color attribute potentially clashing with the nature of the game.
Download ZX Spectrum 48k version
This port was more challenging than i thought it would be. Originally i wanted this to be a cartridge game but z88dk does not support bank switching and i'm not aware of anyone attempting that except through some custom assembly. I estimated that i could only fit 3-5 compressed frames at best. Needless to say, i gave up on that idea and instead went the casette route.
However, going the casette way means that you are being limited by the amount of memory that's on the computer. Even on a ZX Spectrum 128, it's still 64kb unless you do bank switching. For now, i decided to target the 48k model and use ZX1 compression as it is the fastest algo on the ZX spectrum.
I also attempted to combine it further with RCS but results show the two combinaison are too slow for FMVs so went back to simply using ZX1 for animated frames and RCS+ZX1 for static screens. I should point out that this still only saves about half of the space.
I also considered the use of Biforst2 (8x1 multicolor) or even Gigascreen but these would require more bandwidth and a lot more memory as well. If i ever make use of these, it will have to be for a Spectrum 128k version.
This is a really strange beast, especially it's CPU and the way controls work (through UART). The V.Smile actually supports hicolor ! But i stuck with 8bpp due to bugs with the text layer when combined with hicolor. I might upgrade this to hicolor after further hardware tests...
This port does not have any PCM sound for now as i've been told attempts so far failed on real hardware. I may look into this eventually myself.
It's also not using sprites but the hardware was decently powerful enough for sprites not to be needed in my case. I may want to use them eventually but this game does not need them.
Game is entirely 8bpp although i do have a 16-bits variant that's also provided for testing and if you guys are curious.
Lack of sound is a shame so i may revisit this eventually.
I then had the idea of basically treating the 512x256 character-based display and defining each character as a pixel. Doing so would achieve a resolution of 64x30. It is then a matter of simply uploading the bitmapped graphics to 0xF080, which contains the buffer for the text characters onscreen.
The amusing part is that the default font did not have a completely white block to achieve this. However, it's possible to upload your own character set in the 127-255 range so that's what i did.
Other games went further with this and made their own proper character set and worked around this but this would have been very annoying to deal with and probably not fast enough for my purpose.
Sadly z88dk doesn't support sound for this target so it has been disabled for this build. The 64x30 mode also looks very chunky, and i thought the 128x60 would also be challenging to be honest hehe... The results aren't pretty but it is smooth however.
You may also wonder how i managed to fit 5 frames of animation and still make it work on an 8KB machine ? Well thanks to the ZX7 compressor this is doable now. Frames that would normally be 1920 bytes large are compressed down to 280 bytes or so. The decompressor is also 240 bytes or so and plenty fast as well so it's worth it.
I might actually make a proper game for this someday but not a lot of people are interested in business machines like this one. Perhaps i'll do a flappy bird like i did on the Laser 200.
This version performs pretty good and i think technically wise, it should hold up.
It's a shame the Sinclair QL only has a primitive beeper that you can only send commands to via an intel microcontroller which rules out 1-bit PCM even.
The Sinclair QL is definitively a mixed bag : it has a much better CPU than the Zx Spectrum but the graphical upgrades are not really massive. The only notable difference on the QL is the complete lack of color clashing and a higher resolution mode with 4 colors. This game uses the low resolution with 8 colors but with dithering, both modes look interesting i would say. Dithering is not used in-game as it would increase the RAM consumption even further... However it is used for the static screens.
I also borrowed OS/screen 2 memory for storing data as we're really running out of space... Forget about using malloc on this thing ! Just push your data to a fixed location and follow the memory map. Yes, that forces you to track your own memory usage but that can be a good thing honestly.
There was also initially a bug with the game overwriting some of the systems functions for text drawing etc... resulting in the game outputting no text ! I had to move up the memory location slightly higher to avoid this issue. There are ways around this but they all involve disabling the OS or moving it to another location, both of which have their own disadvantages and complications. Therefore, i decided to do that instead.
This port was extremely challenging for multiple reasons :
- I had to figure out how to even get a working binary on this as there was not toolkit to speak of
- Once i did that, i had to figure out the hardware, which required me to hop through multiple documents and blog posts, including in Russian.
- The PDP-11 GCC backend is extremely buggy and would produce broken executables at -O1 and higher.
- This forced me to rely a lot more on PDP-11 assembly and functions.
- Once i did know about all of this, trying to fit the game into 15.5Kb of RAM was extremely challenging.
The results are mixed but i still managed to fit the animations as well as beeps and all. I may consider having an expanded version for later BK revisions but i would rather port this to more capable Soviet computers like the Vector-06C or the Corvette.
This port was very simple to do. Unfortunately RAM is an issue and the 48k amount is misleading due to how the memory map is laid out. In reality, this is more like a 32k machine and you have to load the games from casette so it's still pretty limiting. It's only slightly better than the BK-0010 version because of the extra memory but that's it.
At least there's a wide range of 4 color palettes to choose from !
This was very challenging to even make it work and the lack of documentation further hurt it. It's a shame as according to dom (z88dk maintainer), you can actually emulate a 320x288 pixel mode by using the PCG banks together.
This game as it is only uses 160x72 for the story text and 80x25 ingame, resulting in a very chunky look. Additionally, no sound due to lack of documentation on how to even output sound...
Cool name for a computer though, maybe i'll revisit it for my next game.
I would argue it's quite better than the Spectrum due to the slightly superior graphics and 3 channel sound. The first Oric sold 200,000 units in France and UK for these reasons along with the price matching the Spectrum. However they never really evolved beyond that and soon faster computers came out...
As for the port itself, besides dealing with the RAM, it was mostly straight forward tho unlike on the Z80, it turns out LZSA is too slow for decompressing frames on it ! I will have to think of something for the C128 and C64 ports...
The Oric, thankfully, has a decent amount of memory and not a retarded memory mapping either so it was easy to get something to work. Not a bad version i would say.
I implemented highscore saving (this is based upon the Oric version) but it seems not to work reliably so unsure... It's still there in any case.
This game is also illsuited for the NES as the PPU isn't designed for bitmapped graphics unlike most old computers are. Updating the nametable takes too many cycles so the only proper way of getting close to that was to swap out the CHR banks, which is what i did.
The NES also has hardware DPCM support but the way it's laid out means that if you need more than 16kb, you'll have to switch banks. This port does make extensive use of voices, even further than the MSX2 version as they are used ingame also. Overall, it wasn't too difficult but this console isn't as easy as it may seem at first !
There's also some PCM samples in there although it's heavily downsampled, 4-bits and you can barely make out what he says. I still wanted to include it however.
The other big issue is the huge amount of VRAM it needs to update and the lackluster CPU for it. I mean, updating 48kb multiple times per second on a puny Z80 is no small task ! I cheated a little bit by downgrading it to 4 colors in game to get it in a playable state. It works but you can still see the graphics chip struggling to keep up.
I'm sure with delta compression, compressed code etc... i could get it further than this but even if i could figure that out, z88dk's support for non-CP/M platforms is also lackluster as well !
I think i did a decent-ish job but it could have been better even considering the hardware.
Like NEC PC-88, it was a business machine for the most part and got plenty of adult games because of it. On paper, the PC-98 should have enough grunts to have the game run well on this. However, this only applies to the later models with 386s, as earlier models may struggle with this game.
Interestingly, the 8 colors 640x200 video mode is exactly the same as the PC-88. In fact it's how i initially managed to make my PC-88 work on the PC-98! The 16 colors add only adds an intensity plane on top of the RGB ones.
However, because of the greatly increased resolution (640x400) and color count, you now have to push a whopping 128kb of VRAM stuff onscreen.
Unlike the PC-88, the address space is large enough to contain it so this isn't the problem... The problem is that earlier models have CPUs that are just not fast enough to compensate for the increased VRAM count.
There are ways around this, such as instead using the 640x200 16 colors mode. However this mode actually won't work on later PC-9821 models as NEC completely dropped it (along with B&W modes).
According to my limited testing, it only becomes smooth at around 20mhz on a 386. This version, like the PC-88, acts like a PC-Booter but uses an internal copy of FreeDOS along with DOS 2.0's open sourced COMMAND.COM to reduce memory usage further.
The game may use more conventional memory than usual, especially with the P86 mode so be careful.
It is still very interesting to program for however, as there's still the EGC Blitter chip from earlier models and the text layer is still separate from the graphics layer, freeing resources that would otherwise be wasted on drawing text manually. This version uses DJGPP and also adds PC-9801-24K support compared to the PC-98 version. There's no reason i couldn't have done it to the PC-98 version other than the fact that i only managed to figure it out later...
Unfortunately it doesn't support the 8514/XGA cards but it would have been too slow ingame anyway... This supports 14 different video modes so besides Plantronics support (which dosbox-x still doesn't emulate), there should be something for everybody. Note that the higher resolution cards are only available on the 386 version. Technically it could have worked in real mode but that would have required XMS so i will pass on that...
If you wish to run the game on an IBM AT 4.77Mhz computer, you will need to turn off sound or use a soundblaster and stick with CGA graphics.
This port wasn't too challenging to do, except for a bug that happened in STsprite that prevented me from doing anything until it was fixed. That said, i decided to not to use STSpritelibs because i realised i didn't need it. (it was fast enough without the Blitter chip) This version supports STE DMA sound and it will sounds much better than the PCM trick with the YM2413 chip... Still at least on the bare standard ST, you do get something.
Maybe i'll make a separate Atari Falcon version at some point...
The game runs smoothly otherwise but it could have been much better. I may revisit this too with eventually 256 colors mode.