Knightmare Gold

If I remember correctly, the only modes R#23 doesn't work on are the text modes.It does work, it just doesn't do what you'd expect!

@ BiFi.
Second the information in portugues in the Knightmare Gold site, the 7MHz was neccessary for changing the sprite Y coordinates accordingly to the R#23 value and to maintain the screensplit stable.

Only for that?!?! wtf!

Don't be so negative/critical people. Try to applaud the effort instead...

Hey, Guys... calm down. You start to blame things withtout propper knowledge of what are you talking about.
First of all, there is about 8KB of extended routines (data compressed, originaly it was almost 16KB), plus data that is placed on VRAM (about 34KB, uncompressed).
The amount of changes needed for add smooth scroll in Knightmare is simple enormous. The game is *very* optimized and uses every drop of your 3.57MHz to be just like it is on MSX1. To made it an MSX2 it was needed, in first place, cope with the bigger amount of data to be transfered to VRAM. Attibute + Color table on MSX1 / Sprites mode 1 are just 128 bytes (4*32). On MSX2 it is a bit larger: 640 bytes (4*32 plus 16*32). It's "just" 5 five times the size which made a "simple change" to become a nightmare. There was *no* processor time to do it at 3.57Mhz.
The solution was make deeper changes on the graphics code. Since the game was developed to avoid 4 sprites in the same line, I tried to disable the "scrambler" routine, which placed each sprite in a different priority every interrupt (more on that later). This proved to be a wise solution, since the sprites did not flick or disappear anymore (8 sprites per line are much better than 4 sprites per line)... and this change provided me several Z80 machine cicles to work.
But even this way, when many sprites were on the screen, there was slow down... but since now an character sprites was always at the same place on the VRAM (its color data only changed when the character was destroyed), I could add a color cache for the sprites. This proved to be nice, and the game stopped to slowdown when many enemies ware on the screen. But I had spent almost every bit of free cicles per interrupt doing it (yes, everything is optimized).
When I started to think about smooth scroll, the first thing to do was create the screen split. This consumed even more cycles on interrupt, because now I had to test line interrupts, update screen position counters and etc, etc, etc. I tried to optimized as much as possible (the code is even changes itself to speed up things), but those things ate my last Z80 cycle available at 3.57MHz.
Well, then I started to work in the smooth scroll itself. The idea was change things so I could scroll the entire screen (256 lines) and only draw the new lines, like games developed for smooth scroll should work... which would give me some mode Z80 cycles to work with. Well, after some weeks of hardwork, finding everyplace where VRAM addresses were referenced and changing everything (because at that time I had 4 tables for colors, patterns and names) the result was simply... jerky. Many problems appeared because when you scroll the screen, the VDP keep the "disable sprites" at lines D0 and D8, which brought me a terrible headache: I had to TEST the sprite position of each sprite moved, and make little changes in the position to avoid those positions (which made, sometimes, all sprites disappear from the screen... very annoying). Games developed for vertical smooth scroll use special preparation to "delete" sprite lines when need to plot on those positions, so the sprite is plotted one position below and the move is not perceived by the player (Aleste does that). But on Knightmare this is not done, nor I had space for more sprites to use, space to place them in the RAM, VRAM bus to use... so I had to create another solution.
The new solution was add a 8 pixel mask in the top of screen, and only scroll up to 8 pixels, and keep fast updates of sprites so they do not "jump" in the screen when the "back scroll" is made. But now I had to use framebuffer approach and redraw the entire screen (like Space Manbow does, as far as I know). After some more months working, it was almost done. The framebuffer (including the crazy verifications so the "modifiable blocks", like the "?" ones, could be plotted in the correct position... in the actual screen or framebuffer), the screen split was ok... but I was not able to make the "enemy" sprites not to jump. This was very difficult to correct, because the game update the sprites positions in several different places in the game... and the enemies are updated using a table in the RAM, which is sent to VRAM at once (the usual procedure on good games). But the problem was Knightmare doesn't sync this update with the screen update (the update of attribute table on VRAM should happen on VBlank)... I tried to move it to VBlank, but no luck: I had no spare cycles to do it, the game simple became choppy. That time I decided the game would not have smooth scroll and gave up for 2 or 3 months, working on several other things (including the Graphical Menu, some of the manual/box graphics, etc).
Well, even if I had decided to not include smooth scroll on final release, I felt I should try once more. At least to show something and say: "Look people, I tried." But the fact is: I reprogrammed everything, using a new trick, based on some of the game variables, and the enemies started to be scroll as expected...
After I could make the sprites/background scroll in sync, I started to work on other "problems", moving the clocks to the scoreboard (there is no way to keep themn on the screen when using smooth scroll in a tiled mode), correct some glitches in odd situations, adjust the background to push Popolon smoothly with the background, etc, etc, etc.
When I finished (and lots of mods are simply not commented here, I could write a book about Knightmare Gold, but I have no time and believe most people are simply not interested), I noticed one sad thing: the game of course works in 3.57Mhz when using smooth scroll... but there are several problems: 1) It is shoppy. 2) The screen split become unstable, because there are not enough cycles to the game run between interrupts... (mainly when many enemies are on the screen). And worst of all 3) The game simply freezes sometimes.
I'm not happy and I'm trying to optimize several routines for speed (now I know how much space I can use for these optimizations) and trying to make it work on 5MHz (MSX2+ Panasonic computers) too, but I belive it'll be a miracle if I can make it work on 3.57MHz machines.
And... even at 7Mhz, when playing with CD music there are minor glitches with smooth scroll. This is caused because CD routines must verify when a music was finished to start it again and to accomplish this, the game has to exchange atapi packets with CDROM... and sometimes the IDE/CDROM is just too slow... and at these times the screen blinks. Since the problem happens a lot less than a few times per game and the "blank" time is just *one* interrupt (1/60s), it's not annoying... this is why I decided to make smooth scroll + CD default on 7MHz computers (but the user can disable it, if he wants to).
I'll try to use a trick to avoid this problem: with musics longer than the stage time, the verification can be disabled most of time, being enabled only on final bosses, where the CPU is less loaded. I don't know if it will work, but I'll try for sure.
Everything in this text was written to explain to you... that no, it's not only a change on a VDP register. And to colorize sprites it is not just a matter of screen capture and color them in Photoshop. There are *lots* of problems. Also, there is a big difference between "design a game to use smooth scroll" (like Space Manbow) and "adapt a game which *was not* designed to use smooth scroll" so smooth scroll can be used. All in all, most of smooth scroll of Space Manbow is horizontal, where problems like D0/D8 line positions do not happen. And the vertical smooth scroll on Space Manbow is, when it happens, somewhat choppy in 3.57Mhz (IMHO). Also, the design of Space Manbow Screen allows it to use only one line of split screen (of course, it was designed to use smooth scroll, even when using set adjust). Because of the way the screen was designed on Knightmare, I had to create two split lines. The alternative was modify even more the screen layout, which I did not wanted to.
I hope you understand it was never was my intention to make it need 7MHz computers (or 5MHz computers, if I find some more things to speed up) and I'm always doing my best in lowering the system requirements of my softwares.

My kindest regards,
Daniel Caetano
Amusement Factory

Daniel, keep up the great work!

And please try to support Novaxis SCSI CD-ROM