News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Converting a game to ROM - and LOTS of ROM files inside!

Started by FRAGKI-2012, 00:30, 28 March 13

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

SyX

Quote from: CraigsBar on 22:49, 09 June 14
They all run, Utopia quite happily reports the RSX's for the first roms in slots 0 - 15
And in the Firmware 3.14, you can make CALL &B8E0 to get a list of roms installed in the 32 slots or CALL &B8E0,rom_number for getting the RSXs of the rom number you have choosen.

And the people using the firmware 3.14 expansion rom (the one with the RAM disk), you can use the more friendly rsx |HELP or |HELP,rom_number for it.

Tai

Quote from: mr_lou on 20:24, 09 June 14
I'm actually quite interested in hearing how many games people have managed to install without running into problems.
This is the list of installed ROMs in my ROMBoard.


No issues detected so far.




mr_lou

Quote from: Tai on 17:18, 10 June 14
This is the list of installed ROMs in my ROMBoard.
No issues detected so far.

That is also impressive. I definitely can't have that many ROMs installed without problems.  :(
Neither in my CPC6128 or in my CPC+

CraigsBar

I have just swapped my 6128 plus over with my Schneider CPC 6128 (both have centronics connectors) and the same 32 Roms all work fine there too. I wonder what combination you were having issues with mr_Lou?
IRC:  #Retro4All on Freenode

mr_lou

Quote from: CraigsBar on 18:25, 10 June 14
I have just swapped my 6128 plus over with my Schneider CPC 6128 (both have centronics connectors) and the same 32 Roms all work fine there too. I wonder what combination you were having issues with mr_Lou?

When I find time I'll try installing some ROMs again, and list the process here. I definitely cannot fill all the slots of my two MegaFlash units without running into problems. If I install a certain number of ROMs, they start to not work anymore. I don't remember what the limit was before experiencing trouble, but it was less than 16.

At the time I asked Bryce about it, and he believed it was because each installed ROM took up some RAM to store the RSX command (I think it was). But now people are saying that each installed ROM only takes up 4 bytes. So I'm puzzled.

But as I said, I'll try again when I find the time, and then document in a new thread here at CPCwiki forum when what goes wrong.

mr_lou

Ok, I made a test just now. Here's how it went:

Deleted all ROMS except BASIC in slot 0 and ROM Manager in slot 4 and CPM in slot 7.

Installed Dead on Time in slot 1 and 2 - works
Installed Defend or Die in slot 3 - both games work
Installed Don't Panic in slot 5 - all works
Installed Fruity Frank in slot 6 - all good
Installed Donkey Kong in slot 8 - all work
Installed Spindizzy in slot 9 and 10 - all work
Installed Ghouls in slot 11 - everything still works
Installed Kane in slot 12 and 13 - everything still works, now beginning to be surprised.
Installed Space Harrier in slot 14 and 15 - everything still works!
Installed Ghosts'n'Goblins in slot 16 and 17 - didn't test this game because I forgot the command, but other games worked still
Installed Chuckie Egg in slot 18 - all still works! Very surprised
Installed Atlantis in slot 19 - still works!
Installed Blagger in slot 20 - BANG!!!

After installing Blagger in slot 20, I can't run Space Harrier. It's just a black screen. And Dead on Time crashes on the title screen as the attached photo shows.
The other games seems to still work though.

So...  memory issue? Dead on Time and Space Harrier requiring more memory than the other games?

ralferoo

Did you apply the patches to the ROM that I suggested a couple of pages back?

mr_lou

Quote from: ralferoo on 20:43, 10 June 14
Did you apply the patches to the ROM that I suggested a couple of pages back?

Er.....  no.
I missed that post. I'll see if I can find it to read what that's about.

EDIT: Oh, well I have no clue on how to apply such patches.
But I can confirm that I'm not using standard firmware in any of the two CPC's that has MegaFlash installed. I had Bryce install a newer firmware in order to have all 32 slots available without needing the booster rom.

redbox

Quote from: mr_lou on 20:53, 10 June 14
I had Bryce install a newer firmware in order to have all 32 slots available without needing the booster rom.

If that's the OS I patched then you'll need to do the extra patches ralferoo described.

Or you can use Firmware 3.14 which is on the X-Mem page.

mr_lou

Quote from: redbox on 21:22, 10 June 14
If that's the OS I patched then you'll need to do the extra patches ralferoo described.

Or you can use Firmware 3.14 which is on the X-Mem page.

I can't remember what firmware it was/is.
And I wouldn't know how to apply the patch.

For now, I'm settling for what works. ralferoo suggested that I install the first ROM of the games in slots 1-15, and the other ROM of the games in slots 16-31. This helps a little at least.

redbox

I remember patching the normal 6128 OS ROM by request so I expect it's that one.

Quote from: mr_lou on 21:28, 10 June 14
Install the first ROM of the games in slots 1-15, and the other ROM of the games in slots 16-31.

That's what all of these ROM games need - one universal ROM (launched by something like |GAMEMENU) which lists available games in other slots.

Then *all* of the game ROMs can be background ROMs which don't take up any system resources and are ignored by normal OS scans.

SyX

Then is moment to "bell the cat", and try to agree in an standard for rom games.

I'm going to explain my idea and we can review it.

1.- Our system is going to have a game launcher rom, that will show a list with the games in our romboard and let us to launch the game we want to play.

The first version can simply print the names and ask for the rom number to run and maybe add support for the two more common compressors (appack and exomizer) and the typical code to copy/decrunch games to ram, for a nice save in space in the game roms (a nice benefit of adding those common things here is that when we have the FAT32 system, we could use directly those roms as the files for loading those games from HD/CF/... ).

2.- Now we need to put a header in this games rom, for our launcher can find them.  For the first game rom, the format would be:
    ORG  $C000
rom_type
    DEFB 'G'        ; It's a Game rom and firmware doesn't initialize
                    ; because is not a Foreground or Background rom
game_id     
    DEFW 12345      ; CPC-Power game ID

rom_number
    DEFB 0          ; 0: First rom, 1: Second, ...

game_name
    DEFB 'Game name',0

launch_game
    ; Routine that copy the game to ram and launch it
   

With respect to the game_name, we could limit the lenght to 16 chars maximum and padded the rest with 0s. 

And for the rest of roms of a game, everything is the same and only change the rom_number and those roms doesn't need the launch_game routine, neither the game_name.

Ideas, opinions, ...


CraigsBar

Sounds like a really slick solution to many problems. I hope this happens as it will simplify the current 'can I remember the RSX' issue.

Sent from my HTC One_M8 using Tapatalk

IRC:  #Retro4All on Freenode

CraigsBar

Oh, and if possible on a plus include burnin' rubber in the Rom game menu
IRC:  #Retro4All on Freenode

redbox

I've got one half developed already so will get on and finish it.

Then I'll release the header information and can easily convert the existing ROM games to work with it.

mr_lou

Does this mean that all 32 slots can be filled without problems whatsoever, no matter what ROM files we're installing and what firmware we're using?

arnoldemu

Quote from: SyX on 00:06, 11 June 14
Then is moment to "bell the cat", and try to agree in an standard for rom games.
great idea.

I have one more suggestion to really improve the use of standard roms:

Can we modify the firmware again? this time you can use up to 32 ROMs *with commands*. This means they can be in any slot.
This gives us more flexibility for using normal roms too.

Before it would store data like this:

rom 1, rom 2, rom 3 etc.

how about:

rom 1,rom 7,rom 20 etc, rom 50.

if it found more than 32 it would stop (so it would not break ;) ).

now we can organise our roms as we need without firmware breaking as long as we don't have more than 32 with commands.

Now are free to mix our normal roms and game roms in any slots we want.

Special game boot rom discovers the special game roms in any slot, firmware finds the standard roms in any slot.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

ralferoo

Quote from: SyX on 00:06, 11 June 14
    ORG  $C000
rom_type
    DEFB 'G'        ; It's a Game rom and firmware doesn't initialize
                    ; because is not a Foreground or Background rom
game_id     
    DEFW 12345      ; CPC-Power game ID

...

Let's NOT use 'G' here, the firmware already defines type 2 here for an extension rom. It'd be far better to just have some magic number after the correct byte here.

gerald

Quote from: ralferoo on 12:40, 11 June 14
Let's NOT use 'G' here, the firmware already defines type 2 here for an extension rom. It'd be far better to just have some magic number after the correct byte here.
The firmware defines 3/4 type of ROMs  ;)
0 : foreground (like basic) -> will be foreground program after init of background ROM
1 : background (like amsdos or any classic additional ROM)  -> will be initialised for RSX
2 : extension (when SW does not fit in a single slot) -> ignored by init system
128 : this is the specific to the on board basic (bit 7 set as on board flag)

Ideally, the Game ROM should be type 2 (extension), while the game manager uses type 1.
On the Game ROM, we could re-use the 3 version bytes as marker for the manager.

arnoldemu

The version bytes can be any value, pity Utopia and other tools may expect numbers.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

TotO

I agree with gerald. Using type 1 as entry point then type 2 for the next pages.
That is a good way to be system friendly.

Quote from: arnoldemu on 13:28, 11 June 14
The version bytes can be any value, pity Utopia and other tools may expect numbers.
Because it's a byte... But, better to expect a version number for... a version number, no?




"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

SyX

For me is perfect :)

My idea of using a new rom type was only for saving one byte in the first game rom, but sure we should respect the firmware better and mark them as extension. And maybe we should respect too the version bytes for put logical values there, because we can have a 64/128 KBs versions of a game or if somebody discover a bug in a game and make an improved version, then people could have problems in knowing with roms are from the version fixed and which are from the old bugged, ...

@redbox is important your feedback, because you are working in a game launcher already. Are you missing anything?

And @arnoldemu, i like your idea of searching for the first 32 foreground and background roms, it's more logical for the typical 2014 CPC user.

TotO

In this case, better to respect the way to find the name into the ROM too.
And doing something like that:

02 00 00 00 05 4D 59 47 41 4D 45 4E 41 4D C5 00   .....MYGAMENAM..
So, managers will display all properly.


"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

redbox

Quote from: SyX on 14:35, 11 June 14
@redbox is important your feedback, because you are working in a game launcher already. Are you missing anything?

Well I've been working on it today and made some progress.

This is the header I was using for the extension (game etc) ROMs:


;; redbox ROM

    org    &c000

    write     "CHUCKEGG.ROM"

    defb    2            ; extension ROM

DtROMIdentifier:
    defb    "rbr"

DtROMPart:
    defb    1            ; ROM part...

DtROMTotal:
    defb    1            ; ...of total

DtROMName:                              ; description (always 12 chars)
    defb    "Chuckie Egg ",0       

DtCompressor:                           ; type of compression
    defb    1            ; 0 = none, 1 = exomizer, etc.
DtDestination:
    defw    &8000
DtLength:
    defw    &233e
DtExecute:
    defw    &9a97

DtROMData:

    incbin  "CHUCK.EXO"             ; ROM data

.EndOfROMCode

    nolist

repeat 65536-EndOfROMCode
    defb    &ff                     ; pad out unused space within ROM
rend

    list


The launcher ROM is then run by using |RBR.  This copies a routine to &BE00 which walks all ROMs from 31 to 0 and searches for the "rbr" string.

If a ROM is found, it prints the ROM number, part number, total number and description to the screen like this:



Then, if you type |RBR,number it will execute that ROM.

Still haven't done the code for multipart ROMs (more than 1 ROM) and am wondering if &BE00 is a safe place to hold my routine (which is less than &200 bytes)...?

SyX

Quote from: redbox on 15:56, 11 June 14Still haven't done the code for multipart ROMs (more than 1 ROM) and am wondering if &BE00 is a safe place to hold my routine (which is less than &200 bytes)...?
Well, in the moment you received a valid game rom number to launch, you are free to use the RAM as you like, because games are going to do that too.

A very different case would be if you were loading & run those roms from floppy, RAM Disk or one of the future FAT32 for CF and similars, because those devices uses RAM between $BE40 - $BE7F (FAT32 is going to use even a few more extra bytes here, before the stack).

Powered by SMFPacks Menu Editor Mod