Thanks for your work on this! I recently did my first playthrough of MoG with an eye to eventually speedrunning it, and your notes saved me some time finding a few things in RAM when I was working on planning a speedrun route. Did you happen to spot anything about how drops work, for curiosity? During gameplay, it seems like there are only certain enemy types that are able to drop keys, but I don't see anything in the enemy data table that obviously confirms that theory, at a glance.
Thanks! I had not looked at it so far, but I just did a quick check. I didn't find the exact mechanism, but here are some notes that may help you get started. The first line is closest to the item drop, I work back to see where things came from: Write to backing store at 6f7c@1 From switch at 6f2f@1 (a=ix+b, ix=e800) Copy to e80[9ab] from *f01c at 6675@4 f01c is written on kill at 65fe@4 67af: HL = 67b6+5*L -> this is to pointer stored at f01c Source for L is *f019 f019 is written to A (which is 5b) at 65e3@4, called from 655c@4 A is set at b661@1 code at b648@1 checks for special enemies (multi-drop, like bird dragon) I was analyzing a coin dropped from the bat at the top left of the screen where demeter is.
So your question stuck in my head, and now we have thoroughly investigated what is happening. On github I wrote a complete description of when items drop and how many in the file item-drops.txt. TLDR: it depends on the enemy type in a fairly complex way. The table I wrote in that file should help you figure out which enemies you want to kill. A get-rich-quick scheme seems to be to kill gorillas. And early game the bouncy balls. Unless you want keys, in that case kill bats or worms. But for serious speed run preparation, you need to read item-drops.txt.
Thank you! It's very interesting and amazing how a skilled programmer who knows how Z80 assembler works internally discover the secrets of a classic like Maze of Galious. I played it at that time on my MSX and I always wondered how they managed to compress such amount of data (graphics, music, program logic, etc.) in only 128 KB in a time when every byte saved doing complex tricks was the goal of every game developer.
Really, really nice video! So many interesting tidbits. Like, I hadn’t thought that the game used metatiles, but now I can’t unsee it :). Or sprites in graphics to overcome the attribute clash limitations, that is quite an advanced technique for its time I think. And super cool that you actually got into the missing room and it contained more than just bricks!
Thank you so much for making this video! This is very cool! And lots of details are super interesting. For example, the boulders where Pamperse is! being enemies and not boulders. Very cool! It is also very interesting to learn the encoding mechanism they used for storing the maps! I always suspected it used some sort of 4x4 patterns, but wasn't sure how were they encoded, this clarifies it all! As for which game to look at next, I think you should pick your own favorite haha, but I would be interested in something from the Nemesis Saga, for example Salamander: how are maps encoded, enemies, etc. Again, thanks for creating this!
On MSX, the sequel was only released in Japanese. I've considered learning that to be able to play it, but so far I haven't done that. Perhaps I should extract all the strings and throw them on the forums on msx.org for someone else to translate them. I can then put the translations back into the game. 🙂
@@drwijnen1729 well I was not referíng to the oficial sequel , SHALOM (which btw has been already translated) but to the homebrew unoficial sequel that will be launched Xmas 2022
I am currently doing a code analysis on Dragonslayer 6 and writing my findings in a blog. It is written so that beginners can follow it and explains every tool used. If you are interested, let me know.
Absolutelly IMPRESSIVE! What a meticulous job that only someone who loves this system and this game can do. Is the generated map available for view/download? Thanks for this precious work!
Thanks! The code to generate the map is at the link that I put in the description. I don't like to put generated files in a repository, so you need to run the code for it. For that, you need to have Python 3 installed. All results are saved to files in /tmp/. If that is a problem (which it is if you're running Windows), change the path in the code. The "interesting" (depending on what interests you) executables in there are: - makemaps.py: create all the maps. - read_patterns.py: create the characters image. - read_sprites.py: create sprite images. - gods.py: create text of gods (images including that text are generated in read_patterns.py) - findtext.py: unfinished program to generate the intro and end demo scrolling text.
What an amazing video! I learned a lot about many things I was wondering since my childhood when I played this masterpiece. Question: Is it also possible to create a graph of the states and possible state transitions from the state machine you mention? Or is that way too complex?
I did make a list of states. The possible transitions shouldn't be too hard to get, but I'm not sure how interesting that would be: it's pretty obvious if you see the list of states: 00: Konami logo 01: MoG logo 02: demo (substate 1 = game; 2 = story) 03: "game start" blinking 04: initial world load 05: normal steady state 06: "[hero] out" screen wipe 07: "game over" screen wipe 08: entering world 09: pause 0a: goto new room 0b: item screen 0c: use magnifier 0d: returning to castle 0e: god in world 0f: boss appearing 10: god in castle 11: end demo 12: entering password 13: boss fight 14: boss victory after key pickup
@@drwijnen1729 ah yes i see. I thought there would be much more and detailed states which would give an indication on how the game engine would work. These states only control general program flow.
Great video, thanks! For a next game, I was thinking about an MSX2 game. The graphics would take a lot more bytes in the ROM and still they crammed a game like Metal Gear into only 128kB! It also has a lot of rooms and similar data as MoG. Might be interesting to compare them?
Oh, that's an interesting idea. I already did Metal Gear once, actually. (Just the map, not all the other things like we did here.) Surprisingly, if I'm not misremembering (it's been a while since I did that), it uses the same method of "characters" (which are just 8x8 images, of course) and tiles built from those characters. I suppose even without using hardware characters, it's still a very good way to make sure it can be stored in limited memory.
@@drwijnen1729 I'm sure it did, but it will still be more data than for screen 2 graphics. How the heck did they manage to get that all into only 128kB?? By comparison, it's only 18% of a regular MSX floppy disk!
@@ManuelBilderbeek The difference isn't that big though. A line of 8 pixels in screen 5 takes 4 bytes instead of 2. So if this game was encoded for that, it would not be 20kB+10kB, but 40kB+10kB. Yes, that's significant and possibly a reason to have fewer character sets, for example. But it's not a miracle that it would fit in the cartridge. But yes, compared to the near unlimited storage space on a floppy disk, it's small of course. ;-)
Thanks! Penguin Adventure is interesting. It's definitely possible to read the map from the rom, but I'm not sure how it should be presented to the user. I might do it later; I have now started with Nemesis, but there were other things I needed to do first, so it's taking long (generating a map doesn't take this long). After that I was thinking of doing an MSX2-game first. Probably Metal Gear 2. So there is already a queue. ;-)
Hello. I am doing a code analysis on Dragonslayer 6 and writing a blog about the process of learning how the code works. It is written so it can be followed by beginners and explains all steps i have taken. If you are interested, let me know.
Thanks for your work on this! I recently did my first playthrough of MoG with an eye to eventually speedrunning it, and your notes saved me some time finding a few things in RAM when I was working on planning a speedrun route.
Did you happen to spot anything about how drops work, for curiosity? During gameplay, it seems like there are only certain enemy types that are able to drop keys, but I don't see anything in the enemy data table that obviously confirms that theory, at a glance.
Thanks! I had not looked at it so far, but I just did a quick check. I didn't find the exact mechanism, but here are some notes that may help you get started. The first line is closest to the item drop, I work back to see where things came from:
Write to backing store at 6f7c@1
From switch at 6f2f@1 (a=ix+b, ix=e800)
Copy to e80[9ab] from *f01c at 6675@4
f01c is written on kill at 65fe@4
67af: HL = 67b6+5*L -> this is to pointer stored at f01c
Source for L is *f019
f019 is written to A (which is 5b) at 65e3@4, called from 655c@4
A is set at b661@1
code at b648@1 checks for special enemies (multi-drop, like bird dragon)
I was analyzing a coin dropped from the bat at the top left of the screen where demeter is.
So your question stuck in my head, and now we have thoroughly investigated what is happening. On github I wrote a complete description of when items drop and how many in the file item-drops.txt. TLDR: it depends on the enemy type in a fairly complex way. The table I wrote in that file should help you figure out which enemies you want to kill.
A get-rich-quick scheme seems to be to kill gorillas. And early game the bouncy balls. Unless you want keys, in that case kill bats or worms.
But for serious speed run preparation, you need to read item-drops.txt.
I know this game and know how MSX games are made. And your video is just GREAT!
Keep it up!
Thank you! It's very interesting and amazing how a skilled programmer who knows how Z80 assembler works internally discover the secrets of a classic like Maze of Galious. I played it at that time on my MSX and I always wondered how they managed to compress such amount of data (graphics, music, program logic, etc.) in only 128 KB in a time when every byte saved doing complex tricks was the goal of every game developer.
Really, really nice video! So many interesting tidbits.
Like, I hadn’t thought that the game used metatiles, but now I can’t unsee it :). Or sprites in graphics to overcome the attribute clash limitations, that is quite an advanced technique for its time I think. And super cool that you actually got into the missing room and it contained more than just bricks!
Thank you so much for making this video! This is very cool! And lots of details are super interesting. For example, the boulders where Pamperse is! being enemies and not boulders. Very cool! It is also very interesting to learn the encoding mechanism they used for storing the maps! I always suspected it used some sort of 4x4 patterns, but wasn't sure how were they encoded, this clarifies it all! As for which game to look at next, I think you should pick your own favorite haha, but I would be interested in something from the Nemesis Saga, for example Salamander: how are maps encoded, enemies, etc. Again, thanks for creating this!
Thanks! I was also thinking of one of the Nemesis games, so they're certainly a good candidate. :-)
Excellent analysis. Very interesting and illustrative. Congratulations!!
Thanks!
Yes, I always like when the ground work is well done, details are correct and there are interesting bits of information to be found. Thank you!
Fantastic work! I really enjoyed this video
I loved this game - you made my day! 👍 For another game: Maybe Spyhunter C64, Super Hue II or Jumpman?
Its a state-of-the-art programming piece! Hope the sequel Pampas&Selene follow same technical skills
On MSX, the sequel was only released in Japanese. I've considered learning that to be able to play it, but so far I haven't done that.
Perhaps I should extract all the strings and throw them on the forums on msx.org for someone else to translate them. I can then put the translations back into the game. 🙂
@@drwijnen1729 well I was not referíng to the oficial sequel , SHALOM (which btw has been already translated) but to the homebrew unoficial sequel that will be launched Xmas 2022
Subscribed, thank you for THIS!
I really want to see you doing the code analysis, specially if you show the tools used to read the data and how you make sense of what is what.
I am currently doing a code analysis on Dragonslayer 6 and writing my findings in a blog. It is written so that beginners can follow it and explains every tool used. If you are interested, let me know.
Absolutelly IMPRESSIVE! What a meticulous job that only someone who loves this system and this game can do. Is the generated map available for view/download? Thanks for this precious work!
Thanks! The code to generate the map is at the link that I put in the description. I don't like to put generated files in a repository, so you need to run the code for it. For that, you need to have Python 3 installed. All results are saved to files in /tmp/. If that is a problem (which it is if you're running Windows), change the path in the code.
The "interesting" (depending on what interests you) executables in there are:
- makemaps.py: create all the maps.
- read_patterns.py: create the characters image.
- read_sprites.py: create sprite images.
- gods.py: create text of gods (images including that text are generated in read_patterns.py)
- findtext.py: unfinished program to generate the intro and end demo scrolling text.
@@drwijnen1729 many thanks for the info. I will try it.
You're brilliant!
What an amazing video! I learned a lot about many things I was wondering since my childhood when I played this masterpiece.
Question: Is it also possible to create a graph of the states and possible state transitions from the state machine you mention? Or is that way too complex?
I did make a list of states. The possible transitions shouldn't be too hard to get, but I'm not sure how interesting that would be: it's pretty obvious if you see the list of states:
00: Konami logo
01: MoG logo
02: demo (substate 1 = game; 2 = story)
03: "game start" blinking
04: initial world load
05: normal steady state
06: "[hero] out" screen wipe
07: "game over" screen wipe
08: entering world
09: pause
0a: goto new room
0b: item screen
0c: use magnifier
0d: returning to castle
0e: god in world
0f: boss appearing
10: god in castle
11: end demo
12: entering password
13: boss fight
14: boss victory after key pickup
@@drwijnen1729 ah yes i see. I thought there would be much more and detailed states which would give an indication on how the game engine would work. These states only control general program flow.
Great video, thanks! For a next game, I was thinking about an MSX2 game. The graphics would take a lot more bytes in the ROM and still they crammed a game like Metal Gear into only 128kB! It also has a lot of rooms and similar data as MoG. Might be interesting to compare them?
Oh, that's an interesting idea. I already did Metal Gear once, actually. (Just the map, not all the other things like we did here.) Surprisingly, if I'm not misremembering (it's been a while since I did that), it uses the same method of "characters" (which are just 8x8 images, of course) and tiles built from those characters. I suppose even without using hardware characters, it's still a very good way to make sure it can be stored in limited memory.
@@drwijnen1729 I'm sure it did, but it will still be more data than for screen 2 graphics. How the heck did they manage to get that all into only 128kB?? By comparison, it's only 18% of a regular MSX floppy disk!
@@ManuelBilderbeek The difference isn't that big though. A line of 8 pixels in screen 5 takes 4 bytes instead of 2. So if this game was encoded for that, it would not be 20kB+10kB, but 40kB+10kB. Yes, that's significant and possibly a reason to have fewer character sets, for example. But it's not a miracle that it would fit in the cartridge. But yes, compared to the near unlimited storage space on a floppy disk, it's small of course. ;-)
best game msx
Great job! I case you are planning to do a similar job I would suggest you Penguin Adventure.
Thanks! Penguin Adventure is interesting. It's definitely possible to read the map from the rom, but I'm not sure how it should be presented to the user. I might do it later; I have now started with Nemesis, but there were other things I needed to do first, so it's taking long (generating a map doesn't take this long). After that I was thinking of doing an MSX2-game first. Probably Metal Gear 2. So there is already a queue. ;-)
Hello. I am doing a code analysis on Dragonslayer 6 and writing a blog about the process of learning how the code works. It is written so it can be followed by beginners and explains all steps i have taken. If you are interested, let me know.
😍😍👏🏻
Gaaf