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.

Axelay

Quote from: Bryce on 08:34, 26 May 14
But isn't the Command to start the game saved in RAM? If a game uses the command |SUPERKIDINSPACE, then that's already 15 bytes used up, plus a jump address etc brings this to 19 or 20 bytes per game. So 8 games could be using up quite a bit more RAM.[nb]Or I'm talking complete B0llox, I'm not a coder[/nb]

Bryce.


Oh, that's what I thought, and I'm a coder!  Apparently.  I dont have much time for the OS though.  :D  Anyway, the 7 random game ROMs I have installed in WINAPE saved 28 bytes when I disabled them, so it appears the name is indeed left in ROM.


Quote from: mr_lou on 06:31, 26 May 14
I am but a poor musician. I wouldn't have any clue on how to see how much ram a rom is using.



If you really want to check you can use this from BASIC:


? HIMEM



To get the highest memory location free.  Add or subtract a ROM and reset the CPC or emulator, and do it again.  HIMEM will change by the number of bytes that game ROM used.


Bryce

Interesting, so my footnote was correct :D If that's the case, then are the games just RAM hungry or do the need to start below a certain address? The amount of free RAM is obviously the problem, because it's the only thing that changes as you add games.

Bryce.

redbox

The RSX is kept in the ROM and the OS firmware routine KL FIND COMMAND searches through them each time.

When writing ROMs you set the amount of memory you want to reserve yourself, but for things like game ROMs it should really only be a couple of bytes...?

Axelay

Well I wouldn't be surprised if some earlier games dependent on the OS were made with an assumption of only AMSDOS present with no other ROMs, so they might well overwrite RAM above a lowered HIMEM and cause an issue.

Bryce

Quote from: Axelay on 09:46, 26 May 14
Well I wouldn't be surprised if some earlier games dependent on the OS were made with an assumption of only AMSDOS present with no other ROMs, so they might well overwrite RAM above a lowered HIMEM and cause an issue.

Oh, that really would mess things up.

Bryce.

mr_lou

Um...  I can't keep up.

What are you generally saying? That Softbrenner's utility uses more than 4 bytes pr. game? Or are there other theories as to why I can only install about 7 games before I begin running into trouble?

ralferoo

Quote from: Bryce on 08:34, 26 May 14
But isn't the Command to start the game saved in RAM?
No.

A ROM registering any number of RSX commands uses 4 bytes. The ROM's RSXs are stored in a linked list with 2 bytes to point to the next entry and 2 bytes to encode the ROM number and "configuration". The RSX table always lives at #C004 in a ROM, so there is no other data required.

A ROM can additionally reserve EXTRA RAM for its own use, which is then passed to it in IY when any RSX is used, but this is optional. When the ROM is initialised, the firmware calls the ROM with HL set to the highest free address and DE set to the lowest free address. A ROM can choose to allocate memory from either low memory or high memory by increasing DE or decreasing HL by the amount of memory required. These updated values are then the input to the next ROM and after the last, they are stored for BASIC's use as LOMEM and HIMEM.

Bryce

Good to know. I intend writing my very first ROM program in the near future. I see the learning curve will be steep :(

Bryce.

ralferoo

It's not too bad. Here's a very simple ROM I made as part of my FPGA project...

It shows a couple of these tricks... It uses a few bytes from high memory to install a function to RAM, copied from staticfunc_start. In this case, it's just a helper routine that reads a byte from (HL) of ROM B, but obviously that needs to exist in either the LOWER ROM (it doesn't) or RAM...

Anyway, |ROMS shows all the ROMS installed on the system along with the table addresses, which you'll see decreases by 4 for a lot of ROMs.

There's also a |MEM command that delves into the HIMEM and LOMEM variables to show you how much memory is left.

Ignore the other commands - they're for an SREC-over-serial bootloader that I use for getting code onto my FPGA board quickly... :)


Bryce

Thanks, I've also found a few other samples from around the interweb that I'm currently gazing dumbly at. Unfortunately my Z80 ASM knowledge is also very low which doesn't help.

Edit: What did you compile that on? The other samples I have are for Maxam (which I also intend using) and they look slightly different.

Bryce.

tastefulmrship

On the subject of SOFTBRENNER; it's a great application for those who either can't build their own ROMs, or do not have patience to build their own ROMs... but it has its limitations;

1. It is a generic ROM build application, so it uses a LOT of ROM space for memory manipulation, etc... so, large games (like WONDERBOY) are impossible to convert using this application (see image below) yet are simple enough with the multiple ROM image builder!

2. It can only build up to 32kb files (well, lower than 32kb... see above) onto 2 ROMs... so, games like CYBERNOID 2, HEAD OVER HEELS, BOMB JACK 1&2, CPCWIKI ZYNAPS that fit on 3 ROMs are impossible to convert using this application.

3. It displays a "header" onscreen (so you know the ROM is loaded) as standard... and, as Mr Lou pointed out a while back, if you have a large number of ROMs installed, every time you boot, you get a whole screen-full of useless information! Which is why the multiple ROM code was build without anythign displayed on screen... it just RETs to BASIC. The disadvantage, of course, is not knowing which ROMs are actually installed! ^_^


It's horses for courses, but I prefer to build my own ROMs that work perfectly fine in WinAPE (but ALL fail in JavaCPC) using code written by people here in the CPCWiki community who have a far better understanding of how ROMs work and what's required to get them to work than I ever would! If others insist on undermining my/their work, then that's their problem!

I realise people will probably never download my ROMs; I'm only doing it because I enjoy the challenge of getting games down to as small a size as possible with as much detail as possible (loading screens, etc). My current mission is the FreeScape games... almost all of which cannot be crunched to 2 ROMs if displaying the loading screen and background screen! This is why the 3 ROM code was developed... and SOFTBRENNER simply cannot cope with that! EVER!

ralferoo

Quote from: Bryce on 12:02, 26 May 14
Edit: What did you compile that on? The other samples I have are for Maxam (which I also intend using) and they look slightly different.
That code works fine with both pasmo and WinCPC, so it should also work fine in Maxam (although I've never used it, so I could be wrong). If it's just label syntax (.label versus label: then I suspect most assemblers will take either form).

You might have a problem with lines like this:

staticfunc_len equ $-staticfunc_start

in which case you should replace with something like:

staticfunc_xxx:
staticfunc_len equ staticfunc_xxx-staticfunc_start


It should be fine on an equ line, but I've noticed different assemblers tend to consider $ to be variously the current address or the next address, so I try to never use it except in an equ expression... And some assemblers prefer = to equ...

arnoldemu

Quote from: mr_lou on 11:16, 26 May 14
Um...  I can't keep up.

What are you generally saying? That Softbrenner's utility uses more than 4 bytes pr. game? Or are there other theories as to why I can only install about 7 games before I begin running into trouble?
What do you mean by trouble? I want to understand the problems you are seeing.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

mr_lou

Quote from: arnoldemu on 13:39, 26 May 14What do you mean by trouble? I want to understand the problems you are seeing.

Well.... after flashing a certain number of ROM files, some of them will suddenly not work anymore.
I forget how many it is now, but I remember being somewhat disappointed that it was a low number. I think maybe 7 ROMs.
Definitely no where near the 32 slots that are available on the MegaFlash.

For example. After flashing these about 7-8 ROMs, the HxC ROM would start showing all text as random graphics, so I couldn't read what was going on. And other games would simply just not work. To get the HxC ROM working again, I had to first delete some ROMs and then re-flash the HxC ROM. It wasn't enough re-flashing the ROM without deleting ROMs and it wasn't enough just deleting ROMs. I had to first delete some ROMs and then re-flash.

This happens both on my CPCplus and CPC6128. I should probably mention though, that both CPC's has some chip replacing some other chip that makes all 32 slots on the MegaFlash available. Bryce knows more technical info on this, as he did the replacing for me. I don't remember myself.

Bryce

Ok, that really is wierd. So other ROMs are getting corrupted? Either something is overwriting the reserved RAM or something is confusing the ROManager software. Was it a particular game that caused the corruption? Have you tried filling the MegaFlash with utilities instead of games?

Bryce.


mr_lou

Quote from: Bryce on 15:42, 26 May 14
Ok, that really is wierd. So other ROMs are getting corrupted? Either something is overwriting the reserved RAM or something is confusing the ROManager software. Was it a particular game that caused the corruption? Have you tried filling the MegaFlash with utilities instead of games?

No, I just tried other games.
I too suspected it might be a certain ROM file that did something nasty, so I tried flashing different games. But I always ran into the same problem.

At the time, I put the blame on the explanation that it was the name of the ROMs that overwrote something. But now that we know that can't be the case, I wonder what it is then.

redbox

Quote from: Bryce on 11:33, 26 May 14
Good to know. I intend writing my very first ROM program in the near future. I see the learning curve will be steep :(

This is an easy to follow example.

It reserves 32 bytes of memory during the initialise routine.

It then uses this memory to store the string you supply via the |DOUBLE,"my string" command. The location of this reserved memory is passed by the IY register when the RSX is called.

Gryzor


TFM

No, the RSX chain uses the pointer to the ROM. Nothing must be stored extra in RAM. Don't know where you got this from.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

TFM

Quote from: mr_lou on 11:16, 26 May 14
Um...  I can't keep up.

What are you generally saying? That Softbrenner's utility uses more than 4 bytes pr. game? Or are there other theories as to why I can only install about 7 games before I begin running into trouble?


No. Using the Softbrenner is the GOOD way to make ROMs. And they all run. Other ways lead to problems.


BTW: Softbrenner can be used for nearly all games. Of course the limitation is a bit less than 32 KB. But since we have Exomizer, this means in reality much more. My largest game I converted to ROM has 108 KB uncompressed and fits finally just so in two 16 KB ROMs.

TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

ralferoo

Quote from: TFM on 21:47, 26 May 14
No. Using the Softbrenner is the GOOD way to make ROMs. And they all run. Other ways lead to problems.
Using the Softbrenner is the GOOD ONE way to make ROMs. Other ways MAY lead to problems if you do it wrong:laugh:

mr_lou

Quote from: TFM on 21:47, 26 May 14No. Using the Softbrenner is the GOOD way to make ROMs. And they all run. Other ways lead to problems.

Other ways may result in the game using more than 4 bytes of RAM?

ralferoo

The main problem I know about are not setting the carry flag before returning - the 464 didn't check this, the 664/6128 consider it an error. It was documented as far as I know, but the 464 ignored the carry.

To be honest, I can't really see how else you can go wrong when making a ROM...  You update the memory size in DE and HL if required as part of the initialisation call, and the system registers the RSX list for you. Beyond that, your ROM is inactive until an RSX command is called and then for a game loader you can pretty much do what you want to memory after that...

TFM

Quote from: ralferoo on 15:20, 27 May 14
The main problem I know about are not setting the carry flag before returning - the 464 didn't check this, the 664/6128 consider it an error. It was documented as far as I know, but the 464 ignored the carry.


On a 6128 I tested numerous ROMs for this carry flag. And IMHO the OS doesn't bother. No, it's clearly not that flag. The problems come up when ROM software is fiddling around in the OS, or use up too much RAM, or doing the latter one especially before the DISC ROM gets initialized.


You can easily check by your self!

TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

redbox

I didn't set the Carry flag in the Subtera Puzlo ROM...

Shhh, don't tell anyone  8)

Powered by SMFPacks Menu Editor Mod