If you disassemble mc, you must keep in mind that the disassembler must start at a valid mc-code entry point. So you must take the contents of init. address, i.e. 406Ah, as start address. If you start at 4010, you'll propably get data interpreted as mc-code. Looking on the disassember listing from your post form yesterday 12:05, you see that there's no 406Ah in the address field of that listing. The call instruction on 4062 takes three bytes from 4062 up to 4064. The next instruction begins at 4065h. But these is most likely not really an instruction, it only appears as instuction because it happens that the code or date at this locations is interpreted as call by your disassembler. The disassembler assumes that the bytes on it's start address are code bytes. If the disassembler e.g. encounters a JP xxxx instruction, it will continue to disassemble the contents of the addresses after that instruction, but this contents need not be executable code, but data. So you must be careful on what you are doing. Neither the disassembler nor the processor know about what the bytes they're processing are really like or intended by the programmer, the contents of a byte doesn't contain information whether it'll be code or data. This information is only supplied by the PC (program counter) for the processor and by the start adress for the disassembler. In contrast to the processor, the disassembler does not take the jump as I mentioned above, so that you can easily get data misinterpreted as code. There are tools where you can go to a mc-code step by step and e.g. decide if you take a jump or not and create a commented disassembly file. If I remember correctly, the tool was called NU (don't know what this stands for) and there was a enhanced version of it called NULU. But maybe I confuse it with DASMZ! I never really used this programs. I started to write a programm called CST (code structure tracer) in Turbo Pascal where the disassembly process was controlled by the different kinds of branching instructions (i.e. JP, JR, CALL, RET, RST).

Quote:

Quote: This is not the correct way!! You assume that the ROM takes control and never returns. But is only the case with games and programs that do not interact with other system expansions. Once again, I know all this. But we were talking of a ROM with only an executable machine code program, with only the first 4 bytes set up and the rest set to 0. Please read all the messages before

So what? This is not a reason to violate the standards. By stoling bytes to the ROM header you gain less than 16 bytes, and you risk to have compatibility problems, it is really woth to do it?

No compatibility issues at all if you are using the original cartridge in a real MSX. The problem comes when loading ROMs into RAM and/or using emulators.

It seems that you are disassembling Penguin Adventure. The real ROM size is 128KB and Z80 can point only 64KB. This means, that you can not see all of the ROM at a same time. To get rid of this problem 8k mapper is used. (explained earlyer)

The two most significant bits in address line are not connected, so it seems that the ROM is 4 times in there when this is just illusion caused by the fact that address lines overflow every 16384 bytes.

Thanks a lot. I understand it better now. I disassembled the rom-file and indeed got 4 times this 4000H-BFFFH block. Can I assume that the first block from 4000H till BFFFH is the '0' block and the next 4000H-BFFFH block is the '1' block, etc ?

So if somewhere in the block 0 code the writing to address 6000H occurs, I need to look for the next instruction in a different block ?

regards,

pp

What I just want is the complete machine code of this game in a listing, and I preferably don't want to bother about block swapping or other 'housekeeping tasks' of the MSX. Now, with the used disassembler, I got 4 4000H-BFFFH blocks, which I need to lay after each other, or have to paste in somewhere. Not that I'm lazy, but it's 128 K !

By the way, how the hell do you guys know by just a few bits that this is Penguin Adventure ????????

You are really dedicated people. I hope to be one too, ever.

regards,

pp

The NULU.COM I have looks more like a library manager than a disassembler.

Ah, sorry... I gave you a bit miss information. This game is not "mirrored" 4 times, but only 2. (#4000-#7FFF and #8000-#BFFF)

To access all of the 128K you the game is splitted to 16 (#0-#F) 8KB blocks, that can be selected by writing to #6000 or #8000 or #A000

To dump all of the ROM, do following: Select slot, where the game is connected to area #8000-#BFFF and write values 0-15 to address #8000. After each write save the area between #8000 and #9FFF.

Here is (non tested) example MSX-BASIC program:

10 'SAVEPENG.BAS
20 if peek(&hf677)=128 then poke &hf677,&hc0:poke &hc000,0:run"SAVEPENG.BAS"
30 OUT &A8,(INP(&hA8) and &b11001111 or &b10000) ' Slot 1
40 for i=0 to 15
50 poke &h8000,i
60 bsave"penguin."+hex$(i),&h8000,&h9FFF
70 next

... now you have whole game in 16 files although (with 7 bytes extra header each).

Next problem you have is to find out, what address the blocks should be addressed and are they containing music, graphics, ML or some packed data. There is no any easy way to do this. You just need to read the code... and yes, the correct start address for reading is #406A in block 0 located in area #4000-#5FFF

Quote:

By the way, how the hell do you guys know by just a few bits that this is Penguin Adventure ????????

If I say "A long time ago in a galaxy far, far away" you propably know, what movie I am talking about. Shouldn't we all know our favourite games by hart?

Konami added some sort of identification in about all games. Using that it's possible to see which game it is just by looking at the ROM contents.

BiFi, you are right It's all in here:

Quote:

T4010h 43...... C... LD B,E T4011h 44...... D... LD B,H T4012h 07...... .... RLCA T4013h 43...... C... LD B,E

4010: DB "CD" ; Konami ROM identifier
4012: DB #7,#43 ; RC-number in little endian BCD

--> GOOGLE -> RC743 -> I feel lucky -> MRC

Why "CD", that seems odd to me... Why not "RC"? Combined with the little endian 0743 that makes up for the whole product code...

We can only guess... maybe because when you look at the ROM on HEX editor and 80 column screen, you'll see pattern:

AB
CD

... or maybe they knew that next MSX version SUB-ROM will start with "CD" and they wanted to give us a hint, who is really behind next MSX.

It's all a big conspiracy! (or maybe I've just had too much coffee)

Thanks for the program NYYRIKKI. I don't care figuring the next problem out. Penguin Adventure is my favourite. I'm devoted to find what I need in this program, even if I have to debug it totally. Do you like this game as well ? It still has a secret ! I need to find it before its 20'th anniversary next year.

How can I run the basic program while the cartridge is in ? I don't want to open the cartridge case or put it in a warm MSX ! I just found the software ROM on the internet and am using that one to disassemble.

regards,

pp

I have been investigating these Konami identifications on request. There are a few other methods as well...

Quote:

How can I run the basic program while the cartridge is in ? I don't want to open the cartridge case or put it in a warm MSX ! I just found the software ROM on the internet and am using that one to disassemble.

There are not many other possibilitys. Some slotexpanders have dip switches to enable/disable a slot. You can boot the MSX with slot disabled and then just change the dip. You can also build a switch to your MSX. Last possibility is to get / build a EPROM / flash / SRAM cartridge, where you put a program that skips the boot of second cartridge.