Programming 16K games ROM in AM27C128

Rookie (21)

10-12-2020, 16:24

I'm programmig some 16KB games ROM file in EPROM AM27C128. I tried a lot of games and seems to working but some games did't work.
I downloaded a lot of ROM files versions of Pine Applin or Pitfall and programmed but didn't work.
There is a protection or I need a different programming procedure?
I didn't understand why some games 16K work and some don't.

Aangemeld of registreer om reacties te plaatsen

Van roadfighter

Champion (461)

10-12-2020, 16:34

You should take a look at this post, it has some explanation of the ROM and addressing it.
MSX epromcart for testing

Van NYYRIKKI

Enlighted (6067)

10-12-2020, 18:07

Probably they are using different addresses... If your EPROM /OE is connected to /CS1, try connecting it to /CS12 instead. I think this should make most of the games work.

Van Jipe

Paragon (1614)

10-12-2020, 18:30

for a 16KB games only /CS1 or /CS2 are correct

/CS1 for a game start on 4000h
/CS2 for a game start on 8000h

/CS12 is for 32kB games only

use a HEX editor
for 4000h Header is 41 42 xx 40
for 8000h Header is 41 42 xx 80

basic2rom or first ASCII rom have spécial header 41 42 00 00 00 00 00 00 xx 80 and require /CS2

Van mjnman

Rookie (21)

11-12-2020, 11:04

Thanks guys, with setting jumper in CS12 the games start correctly.

Van NYYRIKKI

Enlighted (6067)

11-12-2020, 14:35

Good... Over thinking like Jipe did causes more problems than good. As long as you are playing with only one ROM chip you don't need to worry about that stuff.

Van Jipe

Paragon (1614)

11-12-2020, 15:03

@Nyyrikki: can you specify which problems ?

Van NYYRIKKI

Enlighted (6067)

11-12-2020, 21:50

Jipe wrote:

@Nyyrikki: can you specify which problems ?

Well... For example your instructions are not covering nearly all situations, I would have rather said something like:

Look 4th byte:
41 42 xx Xx
If this--^ number is between 4-7 then use /CS1 else /CS2

But there are some corner cases where we still might be wrong... If the cartridge software is ie. RAM-test cartridge that needs to access all 64kB of RAM then it really may need /CS12 to be used instead... But the problems may appear to other direction as well when /CS12 is used... If the game has ie. "Exit to BASIC" menu entry then you might need to select that two times in order to actually get to BASIC. Also if the cartridge is not a game but ie. device driver running on TPA memory then you might also run in to problems. These kind of problems are easy to avoid by adding something like "RL H & RET C" to beginning of cartridge init routine, but that is not the point. I think I'm already nit picking in <0.1% case range, so I think there is no point to go more deep down this rabbit hole.

Van NYYRIKKI

Enlighted (6067)

12-12-2020, 00:06

Hmm... Seems that I don't feel too happy about my previous answer, so I'm going down this rabbit hole anyway... Let me try again in more technical terms:

It is quite common misunderstanding that it matters which address (#4000/#8000) the ROM-header is found, but that is not the case. It is the CONTENT of the header that defines what happens next. If there is ie. init-address defined, interslot call will be made to that address.

So, what happens if the ROM is visible not only on page 1 (or page 2) but on both page 1 & 2? (Effect that is also known as ROM mirroring)

The "problem" in this case is that the same header is visible two times, so same code may also be executed two times. In order for this to become a real problem all of these 3 things need to happen:

A) The init routine must exit.
This is quite rare for games, but typical for ie. device drivers. The header is found second time only if program exits without manipulating stack pointer.

B) The cartridge does not consider situation that it has already initialized once.
Most easy way to prevent this is ie. add "RL H & RET C" to beginning of init routine. This will make init routine to exit if it is called from #8000 header (RET NC to cancel #4000 header init). Naturally there are endless amount of other ways to handle this as well.

C) The init routine actually does something that should not be done more than once.
This is typically related to reserving TPA memory by lowering HIMEM pointer. Less harmful effects may include showing same initialization texts on screen two times or something like that.

Reason why cartridge may intentionally use ROM mirroring is that this gives it some agility. It can ie. normally run from #4000-#7FFF and have RAM on #8000-#FFFF, but when it ie. needs to use BASIC-routines, it may map it self to #8000-#BFFF instead and have BASIC ROM in #0000-#7FFF

Van gdx

Enlighted (6209)

12-12-2020, 08:35

Nyyrikki, all is explaned in the wiki except for "RL H & RET C". Maybe you can add it?

https://www.msx.org/wiki/The_Memory
https://www.msx.org/wiki/Develop_a_program_in_cartridge_ROM

Mirrors are caused by components economy. (When unnecessary bits are not handled.)
Maybe we should also clarify that in the wiki.

Van NYYRIKKI

Enlighted (6067)

12-12-2020, 13:29

gdx wrote:

Nyyrikki, all is explaned in the wiki except for "RL H & RET C". Maybe you can add it?

https://www.msx.org/wiki/The_Memory
https://www.msx.org/wiki/Develop_a_program_in_cartridge_ROM

Mirrors are caused by components economy. (When unnecessary bits are not handled.)
Maybe we should also clarify that in the wiki.

Actually, I don't really see this subject covered... All I see about mirroring is in "Create a ROM without mapper" chapter and even there it is covered only in one picture that tries to explain situation when /OE is connected to /RD instead of using /CE1, /CE2 or /CE12 standard signals... (When these are used there is newer anything on pages 0 or 3) The possible effects caused by implementing mirroring / disabling mirroring are also not explained. The white part of left 32kB setup is kind of expecting /CE12 is used that would cause mirrors to disappear, but yet grey area explains mirrors like if /RD is used. It also adds confusion as it misses to explain the point that lower 16kB in ROM chip is upper part of the ROM in memory (chip #4000-#7FFF = MSX #4000-#7FFF, chip #0000-#3FFF = MSX #8000-#BFFF). So practically all left and right pictures are from identical situations, just drawn differently, but it is something that is kind of hard to see.

So, indeed this would need some improvement as I think cartridge developer should understand the different hardware configuration options he can take, but at the moment I'm not planning to work on that.