HELP needed - issues with H.STKE hook.

Página 3/3
1 | 2 |

Por NYYRIKKI

Enlighted (5889)

imagem de NYYRIKKI

20-08-2021, 22:32

Yes, this was my conclusion...

Por Manuel

Ascended (18246)

imagem de Manuel

20-08-2021, 22:47

Well, we could change them all to mirrored and later refine the entries. As it's a lot of work, it will require the help of all of you...

Por NYYRIKKI

Enlighted (5889)

imagem de NYYRIKKI

20-08-2021, 23:12

I think it is very bad idea to start putting false, not verified data to the database... People may think then that this data is accurate... If you just change the algorithm, I bet you fill very fast start to get input, what games are likely mirrored... You might lose quite a few users momentarily though in the process.

If you want to change the process, but don't want to alienate users then maybe better to implement "Unknown" mapper type that results in to old guess algorithm while really undefined use the new algorithm... Personally I'm not quite that sure it is all worth of the hassle, but yes... I can see the ideology why this can be seen as step to right direction.

Just to put all (even worse) options to the table, this mirrored/normal issue can be solved also with some "emulation magic"... You can ie. put break point to cart init address and if the cartridge is mirrored, you emulate RET on the break and remove the break point... This likely solves both problems, but is definitely "NO, NO!!!" from emulation perfection point of view.

Por gdx

Enlighted (4818)

imagem de gdx

21-08-2021, 03:35

Crash is not certain, even rare, when the INIT routine is run twice.
A crash often occurs when the header content is not respected. In general, it's when TEXT is not 0000h in the header of the page 4000h-7FFFh or when unused.

I indicated it in the wiki.
https://www.msx.org/wiki/Develop_a_program_in_cartridge_ROM

Grauw wrote:

It means there are two 16K ROM mapper types one mirrored and one not, and the correct one should be specified on a game by game basis in the software DB. The argument that goes from the presumption that the emulator must guess, the software DB is precisely there to prevent the emulator from relying on guessing ROM type, which is notoriously unreliable.

What zeilemaker is saying is that when the mapper type is unknown (guessed), it should default to non-mirrored for 16K ROMs because the mirroring causes issues during new developments, while the usefulness of having mirroring is minimal.

You do not understand what I explained. I said removing the default mirrors is not the right solution (nor the bad one). This fixes a problem on one side but poses another. Either one or the other, they occur quite rarely. The least rare is the one I'm talking about just above but it can be easily corrected by a better analysis of the header.

In addition, I'm not talking about mappers, only 16kB Roms, but I think mirrors should be present for all mappers detected by default (for the Roms not in the database).

Por zeilemaker54

Champion (315)

imagem de zeilemaker54

21-08-2021, 08:59

gdx wrote:

Crash is not certain, even rare, when the INIT routine is run twice.

That is completely depended on what the INIT routine is doing. You are implying it is no big deal, but it is. It is not working like an real MSX. If my INIT routine for example reserve some basic memory, it does this twice when emulated in OpenMSX.

But I inderstand the problem of a incomplete software DB on the mappertype. That means the 16 KB ROMs needs to be tested with mappertype unmirrored.
@NYYRIKKI, are those 2835 ROMs all 16 KB ROMs ?

Por gdx

Enlighted (4818)

imagem de gdx

21-08-2021, 10:15

zeilemaker54 wrote:

That is completely depended on what the INIT routine is doing.

Yes, that's why crash is not certain. I have rarely seen that it causes a problem. Some Disk-ROMs and maybe one game only.

zeilemaker54 wrote:

You are implying it is no big deal, but it is. It is not working like an real MSX. If my INIT routine for example reserve some basic memory, it does this twice when emulated in OpenMSX.

It does the same on a real MSX if we run the game from a cartridge with mirrors. I have programmed a ROM loader (ROM2MMM) that reprodure the mirror and I can guarantee you that it is very rare that it causes a problem. I even think it's the best way by default although it does not change much globally. (I did tests for months, but only games having said that)

Por zeilemaker54

Champion (315)

imagem de zeilemaker54

21-08-2021, 11:01

gdx wrote:

It does the same on a real MSX if we run the game from a cartridge with mirrors.

Yes sure. But a normal 16 KB ROM is not mirrored at all. It has its CS connected to either CS1 or CS2 depended on the needs. This is the default (and most simple) design for a 16 KB ROM, also documented in both MSX tecnical databooks. You only use ROM mirroring if you have a special requirement.

Por gdx

Enlighted (4818)

imagem de gdx

21-08-2021, 11:49

zeilemaker54 wrote:

This is the default (and most simple) design for a 16 KB ROM

Is this important for OpenMSX? What is important is that ROMs are run by default as often as possible. If there are more ROMs that don't work with mirrors, it would be nice to do so. I think this is the only valid argument.

To make OpenMSX closer to a real MSX, there is more important to do. Change Catapult for example. This launcher is so different from the use an MSX. Same for external VDPs, etc.

Por NYYRIKKI

Enlighted (5889)

imagem de NYYRIKKI

21-08-2021, 13:52

zeilemaker54 wrote:

@NYYRIKKI, are those 2835 ROMs all 16 KB ROMs ?

That I can't tell... The database does not contain size information, only hashes.

Por max_iwamoto

Hero (548)

imagem de max_iwamoto

22-08-2021, 21:50

I am glad that this small topic caused such a discussion. Now I will try to get it back on track...

NYYRIKKI wrote:
max_iwamoto wrote:

One more thing... When I originally read about mirrored ROM, I checked and my ROM size was 64KB. So, possibly, the emulator would see it as a mirrored ROM... I changed ROM size to 128KB and it didn't make any difference.

No, that won't work... The problem is that MSX reads the "AB"-header from #4000 and then starts the init routine mentioned on #4002. When that is finished it reads the "AB"-header from #8000 and then starts the init routine again as it is also mentioned in #8002 due to mirroring... So in your case one way to prevent this is to change the page visible in #8000-#BFFF to something else, so that the "AB"-header is not found... As it was already mentioned, using the H-register is not documented way, so in that sense this would be maybe more acceptable approach.

I made a small changes (LD A,01h + LD (7000h),A) and now it works fine, here it is:


ROM_START:

	DI
	CALL	RSLREG
	AND	%00001100
	RRCA
	RRCA
	LD	B,A
	LD	HL,EXPTBL
	ADD	A,L
	LD	L,A
	LD	C,(HL)
	INC	L
	INC	L
	INC	L
	INC	L
	LD	A,(HL)
	AND	%00001100
	OR	B
	OR	C

	LD	H,A
	LD	L,F7h		; RST 30h
	LD	(H.STKE),HL
	LD	HL,START_2
	LD	(H.STKE+2),HL
	LD	A,C9h
	LD	(H.STKE+4),A

	LD	A,01h
	LD	(7000h),A

	RET

START_2:

ducasp wrote:
max_iwamoto wrote:

One more thing... When I originally read about mirrored ROM, I checked and my ROM size was 64KB. So, possibly, the emulator would see it as a mirrored ROM... I changed ROM size to 128KB and it didn't make any difference.

I also tried to force mapper type to ASCII 16 or use "guess ROM type" option and still no changes.

That is weird, a 64KB ASCII 16 mapper rom will not have 8000 mirroring 4000, does 8000 in your rom have the header, making the machine to think it is a different software to be executed?

Strangely enough There is no "AB" at 8000h, but ROM page 0 is located at 8000h. As you can see above, if I set ROM page 1 at 8000h, everything is working OK. I am still not sure is it only on emulators or real MSX as well. I will try to check that.

Página 3/3
1 | 2 |