I just found a Solid Snake demo ROM - it has only the intro screens, and fits a 128K cartridge. In fact, it takes only 112K, because the last 16K of it is empty (FFs).
The rom type is "Konami5 8kB".

Is there a disk version of it ?
If not, how difficult it will be to create a disk version for a 128K RAM MSX2 ?
It should be simple enough, as far as I understand.

Correct me if I'm wrong:
1) I have to fill 112K of RAM with 7 chuncks, 16K each, using OUT &HFE,<page_num>
2) there should be some subroutine that can switch between pages
(placed somewhere in the last 16K RAM page, where exactly ?)
3) I have to patch every place in original code where page switching happens
with CALL subroutine.
4) Start the game, using the address at 4002.

The only thing I don't understand is the following: the ROM chunk is 8K,
while the mapper's chunk is 16K. What is the trick here ?
Should I study the rom's code to find the pairs of 8K it maps simultaneously and fill the RAM accordingly ?

Which disk version can I take as an example ?
Can someone guide me ?

Quote:

The only thing I don't understand is the following: the ROM chunk is 8K, while the mapper's chunk is 16K. What is the trick here ? Should I study the rom's code to find the pairs of 8K it maps simultaneously and fill the RAM accordingly ?

That's the general idea indeed.

Quote:

Which disk version can I take as an example ? Can someone guide me ?

Any disk version will do, as long as the files are saved as 8KB chunks and in most cases Basic loaders are pretty easy to see how things are done. It's against MRC policy to link to such games in here, so you'd have to find some yourself. You might be able to find some on FUnet though.

Happy hunting!

Well, I finally created this disk version, and it runs on my Yamaha with 128K RAM/128K VRAM (you can download it from my homepage).

I was lucky: this ROM uses most of it's 8K pages in pairs: 01,23,45,78 (in fact, 28 and 78, but 78 works in both cases),AB,CD, which fills 6 of 7 free 16K RAM pages.
For other 2 pairs - 06 and 09 - I used the last free page of RAM, first half of which always contains rom page 0, and the second one I replace with 6 or 9 when the switching happens. 8K ROM pages 6 and 9 I store in compressed form in empty places of other pages
(page 3 had 3900 free bytes, page B - 6568 free bytes, page 8 - 3632 free bytes).

I know, usually ROM cracks use VRAM to store and retrieve pages, but using compression and empty places in various pages I managed to not use VRAM at all.

The last thing I have to do is to add an SCC support.

I already found on the net some recommendations about SCC detection - I have to check not only slots A and B, but also the slotexpander, etc. I also heard about "bad cracks", which work with SCC incorrectly, don't find an SCC, etc.

That's why I want to ask your help in founding the ready and good working routines for
a) finding the slot and subslot when SCC is placed
b) routine for switching on the SCC slot
c) routine for switching back

Another question: if the program only uses SCC and don't use PSG at all, can I somehow make it produce at least partial sound via PSG (kind of partial emulation of SCC via PSG) ?

10x in advance for answering.

; keep interrupts disabled

SCCSlot: db 0 ; SCC Slot
temp: db 0

ld de,SearchSCC
ld hl,SCCSlot
call Search
;---

Search: ld [.srch_s],de ; insert search routine address
ld [.srch_p],de
ld [.read_s],hl ; insert address to store slotnr in
ld [.read_p],hl
ld [hl],0 ; reset slotnr

ld b,4
.pri_l: push bc
ld a,4
sub b
ld c,a
ld hl,EXPTBL
add a,l
ld l,a
ld a,[hl]
add a,a
jr nc,.notExp

ld b,4 ; slot is expanded
.exp_l: push bc
ld a,24h
sub b
rlca
rlca
or c
ld [temp],a

.srch_s: equ $+1
call 0

.read_s: equ $+1
ld a,[0]

or a
pop bc
jr nz,.end
djnz .exp_l
.nextpri:
pop bc
djnz .pri_l
ret

.notExp: ; slot is not expanded
ld a,c
ld [temp],a

.srch_p: equ $+1
call 0

.read_p: equ $+1
ld a,[0]

or a
jp z,.nextpri
.end: pop bc
ret

SearchSCC:
ld hl,[F343h] ; read RAM Slot for page 2
cp l
scf
ret z

ld a,[l66e3]
ld b,a
and 3
rrca
rrca
ld e,a
rrca
rrca
ld [EnableSCC.PriSlot2],a
or e
ld [EnableSCC.PriSlot],a
ld [DisableSCC.PriSlot],a
ld e,a
in a,[A8h]
ld [.restoreA8],a
and 00001111b
or e
out [A8h],a
ld a,b
and 00001100b
rlca
rlca
ld [EnableSCC.SecSlot],a
ld e,a
ld a,[FFFFh]
cpl
ld [.restoreFFFF],a
and 11001111b
or e
ld [ffffh],a
ld hl,9000h
ld de,9800h
ld c,[hl]
ld [hl],3fh
ex de,hl
ld a,[hl]
cpl
ld [hl],a
cp [hl]
cpl
ld [hl],a
ex de,hl
scf
jr nz,.end

ld [hl],0
ex de,hl
ld a,[hl]
cpl
ld [hl],a
cp [hl]
cpl
ld [hl],a
ex de,hl
scf
jr z,.end
ld a,b
ld [SCCSlot],a
or a

.end: ld [hl],c
.restoreFFFF: equ $+1
ld a,0
ld [ffffh],a
.restoreA8: equ $+1
ld a,0
out [a8h],a
ret


; EnableSCC
;
; Enables SCC in page 2

EnableSCC::
in a,[A8h]
ld [DisableSCC.restoreA8],a
and 00001111b

.PriSlot: equ $+1
or 0
out [A8h],a
ld a,[FFFFh]
cpl
ld [DisableSCC.restoreFFFF],a
and 11001111b

.SecSlot: equ $+1
or 0
ld [FFFFh],a

ld a,[DisableSCC.restoreA8] ; restore primary slot for page 0,1,3
and 11001111b
.PriSlot2: equ $+1
or 0
out [A8h],a
ret

; DisableSCC
;
; Disables SCC, returns page 2 to previous

DisableSCC::
ld a,[.restoreA8] ; prepare for secondary slot write
and 00001111b
.PriSlot: equ $+1
or 0
out [A8h],a

.restoreFFFF: equ $+1
ld a,0
ld [FFFFh],a

.restoreA8: equ $+1
ld a,0
out [A8h],a
ret

> ld a,[l66e3]

No such label... what should it be ?

oops, sorry.. that's the TEMP label

What I'm currently doing is trying to make SCC work from slot A,
and the code is as follows:

; switch on the slot 1 in page 2 where SCC is placed
ld a,1
ld h,$80
call $0024

Here I return control to the game.
It does:

; use SCC
ld a,$3F
ld ($9000),a
then works with SCC in 9800 area
ld a,$0E
ld ($9000),a

here I get control again and do the following:

; switch back to RAM in page 2
ld a,($F342)
ld h,$80
call $0024

Something strange happens:
on emulators it works fine: I hear SCC sound when an SCC cart is inserted, or PSG only if not (and it's OK).

But on real MSX without SCC program runs very sloooow, and is desynchronized with music. Can it be that calling 0024 too much leads to delays ?
Will direct usage of A8/FFFF help ?

Probably an interrupt problem, 0024h (ENASLT) disables the interrupts.

About the SCC detection rutine; before you check wave RAM, you should write 0 to #98C0 to prevent read/write errors.

Just my 2 cents

That's not true. Only if a previous program wrote to 98C0h that MIGHT be needed. But even Konami does not use this undocumented register, so it should be left alone.

Check this out: www.manuel.msxnet.org/msx/softw/soft/sccdetec.lzh

Quote:

That's not true. Only if a previous program wrote to 98C0h that MIGHT be needed. But even Konami does not use this undocumented register, so it should be left alone.

As I said you SHOULD (not MUST) do it. So it is true. You can have problems if you don't do it.
About undocumented: can you tell me where is the official document about SCC?
Konami doesn't search for SCC. Does this mean that you should not search it?
Furthermore, if you want to avoid problems with other hardware, SCC should not be searched. Just ask the user where is it.

Manuel, thank you very much for an SCC detection code.

For now, I consider the work finished.

I checked everything on various emulators, but I still can't confirm that everything is OK, because I just have no SCC cartridge. So, please someone help me to test the demo.
I'll check it on my SCC-less computer in a day or two.

The updated disk version of Solid Snake 2 Demo can be downloaded from my homepage, as usual (mail me to borus@<NOSPAM>bigfoot.com if you need)

10x in advance.

Quote:

Manuel, thank you very much for an SCC detection code.

Uhm.. what about GuyveR's detection code? ^_^

>Uhm.. what about GuyveR's detection code? ^_^
I had some problems with it, maybe because I use cross-assembler with somehow different syntax (sbasm), and at some point I got the link to Manuel's page - the code I downloaded from there compiled and worked immediately, at first run.

So, nothing personal or bad with GuyveR's code - I just didn't want to spend more nights debugging problems I probably created myself, and got the one that worked for me.

At this point I want to say thanks to everyone who tried to help me.
It is my first experience in creating disk version of MegaROM.
I have to say, it was real fun.
I also have to admit that the work was simplified by a number of tools, which typical MSX freak didn't have at the time where most of cracks were done.

The most valuable tool is NO$MSX - an emulator with a built-in debugger.

A big portion of the code was written and debugged inside NO$MSX.
The feature I loved very much is possibility to run at >=1000% speed during debugging - this helps to approach the breakpoint very fast.

Another thing that helped me was the ability to patch the ROM and try it in emulator - this is very helpful in some cases.

Memory switching log generated by RuMSX was very helpful to investigate the switching process statistically and to plan the layout of blocks in memory.

I'm sure, that creating and debugging MSX software on emulators speedups the process alot. But I also have to say, that no emulator is perfect, and the final check have to be done on a real hardware.