News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_cpcitor

16KB ROM game compo - technical thread

Started by cpcitor, 12:56, 05 January 13

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

cpcitor

Hi,

Any good tutorial or documentation for ROM development ? Some things can be guessed from the "EXAMPLE ROM CODE" section of the announcement but that might not be enough to be unworried. Google finds tons of ROMs but no tutorial/doc easily. Nothing found on the forum, but I might have searched wrong. From the wiki Source Codes - CPCWiki and direct links, not much about this.

I've been doing some small demo stuff in, err, about 1993, all coded on a CPC 464 with external floppy drive (scrolltext, raster effects, some precomputed 3D animations, a simplistic video codec).

My current dev platform is Ubuntu Linux. I've been playing a little with sdcc and z88dk past year, enough to run a simple "hello world" from a generated disk image. But I've never been in ROM-based dev (I know basics about read-from-ROM write-to-RAM behavior of the CPC in some circumstances but some documentation to refresh memories would be nice).

Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

SyX

Quote from: FindYWay on 12:56, 05 January 13
Hi,

Any good tutorial or documentation for ROM development ? Some things can be guessed from the "EXAMPLE ROM CODE" section of the announcement but that might not be enough to be unworried. Google finds tons of ROMs but no tutorial/doc easily. Nothing found on the forum, but I might have searched wrong. From the wiki Source Codes - CPCWiki and direct links, not much about this.

I've been doing some small demo stuff in, err, about 1993, all coded on a CPC 464 with external floppy drive (scrolltext, raster effects, some precomputed 3D animations, a simplistic video codec).

My current dev platform is Ubuntu Linux. I've been playing a little with sdcc and z88dk past year, enough to run a simple "hello world" from a generated disk image. But I've never been in ROM-based dev (I know basics about read-from-ROM write-to-RAM behavior of the CPC in some circumstances but some documentation to refresh memories would be nice).
Of course FindYWay, i'm going to add this info during the weekend in a special CPCWiki page.

You can find all the info needed in the section 10 of the Firmware Guide, a side of that you have articles in magazines, for example in the ACU magazine you have this and this, that Hermol linked yesterday in CPCRulez forum.

I have upgraded the source code example in the first post to a more verbose "hello_world.rom", and i have attached to this post.

With respect to making a rom in c, the important thing is that your code must be compiled to run from $c000  (except the bytes used by the header) and your data section must be located in ram. I have found a few links for making msx cartridge games in c, this using sdcc looks very promising for porting to cpc, in theory only need to make a few changes in the crt0.S. Take a look and tell us if you find any problem :)

db6128

#2
Quote from: FindYWay on 12:56, 05 January 13I know basics about read-from-ROM write-to-RAM behavior of the CPC in some circumstances but some documentation to refresh memories would be nice
Do you mean DRAM refresh? If so, you never need to do anything* to refresh it, and this is the same whether your code resides in RAM or ROM. See my recent question about this and the great informative replies from arnoldemu and from ralferoo.

* aside from not setting certain registers in the CRTC to weird values for extended periods of time
Quote from: Devilmarkus on 13:04, 27 February 12
Quote from: ukmarkh on 11:38, 27 February 12[The owner of one of the few existing cartridges of Chase HQ 2] mentioned to me that unless someone could find a way to guarantee the code wouldn't be duplicated to anyone else, he wouldn't be interested.
Did he also say things like "My treasureeeeee" and is he a little grey guy?

cpcitor

#3
Quote from: SyX on 14:07, 05 January 13
I have upgraded the source code example in the first post to a more verbose "hello_world.rom", and i have attached to this post.

Great ! That shows very interesting things.

Quote from: SyX on 14:07, 05 January 13
With respect to making a rom in c, the important thing is that your code must be compiled to run from $c000  (except the bytes used by the header) and your data section must be located in ram. I have found a few links for making msx cartridge games in c, this using sdcc looks very promising for porting to cpc, in theory only need to make a few changes in the crt0.S. Take a look and tell us if you find any problem :)

I just took a look. Thanks ! Those links and your explanation make a very nice starting point, especially thinking that a good compromise is probably to make a C-based shell with selected assembly-optimized area for critical sections (as size contraint permits).
Some commercial games did that (Mortville Manor used Pascal).

Ahlalah, How can I take care of wife, kids, work, all the rest (including Linux-based white-hat hacking) and also a CPC-targeted project ? By the way, my (z88dk) C-based hello world is on cpcitor/cpc-dev-tool-chain · GitHub and I'll probably share there. Git or github-based forking is encouraged as it makes much easier to share/reconcile stuff with other devs.

Quote from: db6128 on 16:28, 05 January 13
Do you mean DRAM refresh?

Thanks db6128 for the links. I was referring to the fact that when code is in upper ROM ($c000), you can read data from the ROM and write data to the RAM at the same address range. This comes handy if you never have to read back from the displayed memory : your ROM code does not obstruct or use up any RAM range, so you have more RAM to play with.
If you need to read displayed memory, you must write some code that reconfigure bank switching to be able to read from RAM (and that code must run from another area, or you'd be sawing the branch you were sitting on). I believe the firmware has some routines to do it transparently for you, but at a cost in performance. Anyway, I guess everything is explained in the Soft968: CPC 464/664/6128 Firmware - CPCWiki .
Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

SyX

Quote from: FindYWay on 17:58, 05 January 13I just took a look. Thanks ! Those links and your explanation make a very nice starting point, especially thinking that a good compromise is probably to make a C-based shell with selected assembly-optimized area for critical sections (as size contraint permits).
Some commercial games did that (Mortville Manor used Pascal).
By the way, my (z88dk) C-based hello world is on cpcitor/findyway · GitHub and I'll probably share there. Git or github-based forking is encouraged as it makes much easier to share/reconcile stuff with other devs.
Vous êtes les bienvenus  :)

And thanks for sharing, i'm sure that more people will find interesting being able to use c.

Quote from: FindYWay on 17:58, 05 January 13Ahlalah, How can I take care of wife, kids, work, all the rest (including Linux-based white-hat hacking) and also a CPC-targeted project ?
Jajaja, we are all in the same situation, stealing time where there is none. Don't forget have fun!!!  ;)

db6128

Quote from: FindYWay on 17:58, 05 January 13Thanks db6128 for the links. I was referring to the fact that when code is in upper ROM ($c000), you can read data from the ROM and write data to the RAM at the same address range. [...] If you need to read displayed memory, you must write some code that reconfigure bank switching to be able to read from RAM
Oops, silly me! Obviously you just meant to refresh your memory, not the CPC's. :D
Quote from: Devilmarkus on 13:04, 27 February 12
Quote from: ukmarkh on 11:38, 27 February 12[The owner of one of the few existing cartridges of Chase HQ 2] mentioned to me that unless someone could find a way to guarantee the code wouldn't be duplicated to anyone else, he wouldn't be interested.
Did he also say things like "My treasureeeeee" and is he a little grey guy?

Octoate

Hi,
I just had some time this afternoon and assembled a small and simple Code::Blocks project which shows how to create a ROM for the CPC with the SDCC compiler. You can find the code on GitHub (either clone it or download it as a ZIP file). It currently relies on Windows, because it uses a Windows "hex2bin" executeable, but it is rather simple to change this setting to make it working on other systems, too.
If you have any improvements for it, don't hesitate to send me your patch and I will include it :-).
--

cpcitor

Quote from: Octoate on 20:40, 05 January 13
Hi,
I just had some time this afternoon and assembled a small and simple Code::Blocks project which shows how to create a ROM for the CPC with the SDCC compiler. You can find the code on GitHub (either clone it or download it as a ZIP file). It currently relies on Windows, because it uses a Windows "hex2bin" executeable, but it is rather simple to change this setting to make it working on other systems, too.
If you have any improvements for it, don't hesitate to send me your patch and I will include it :-).

Great !

What does this hex2bin exactly do ? Is it the same as http://sourceforge.net/projects/hex2bin/ ?

Had a CPC since 1985, currently software dev professional, including embedded systems.

I made in 2013 the first CPC cross-dev environment that auto-installs C compiler and tools: cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC, later forked into CPCTelera.

Octoate

Quote from: FindYWay on 21:03, 05 January 13
What does this hex2bin exactly do ? Is it the same as Hex2bin | Free Development software downloads at SourceForge.net ?
It converts the compiled from Intel Hex format to a binary file. Yes, this SF project is exactly what I used for the example.
--

Optimus

Quote from: Octoate on 21:09, 05 January 13
It converts the compiled from Intel Hex format to a binary file. Yes, this SF project is exactly what I used for the example.


Great! That will be handy for a start as I like to work on Codeblocks/SDCC too these days.

arnoldemu

I have been thinking about the rom game development.

If the code runs from rom, no self modifying code can be used, it may sound obvious, but there are some music drivers and existing library code (e.g. for sdcc) that does that.

In addition, when the rom is initialised, calling "kl curr selection" is useful to identify the slot it is installed in, so that you can turn your rom on/off and use the ram that is "underneath" it. Thinking about it, you may not need to do this, because the rom should remain selected, and you should just be able to turn it on/off to access the ram behind.

In terms of screen ram, move it to &4000-&7fff or &0000-&3fff (using IM 2 of the z80), then you can read/write it as you need from code within the rom itself.

some ideas that may help...
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Gryzor

A slightly off-topic note, if you feel like it, you can start as many threads as you want on the issue - no reason to stay in this one here. If a few are created I may add a sub-forum for the competition :) 

db6128

#12
Quote from: arnoldemu on 14:46, 07 January 13If the code runs from rom, no self modifying code can be used, it may sound obvious, but there are some music drivers and existing library code (e.g. for sdcc) that does that.

Something that occurred to me is that the same fact might also limit anyone who wanted to use self-modifying code in a spriting routine, e.g. to restore the horizontal byte offset and/or horizontal loop counter. This assumes a one-size-fits-all, RAM-efficient but (relatively) speed-poor routine in which all the main pairs of registers are already occupied in reading from the sprite, masking from a separate look-up table, and writing to the screen.

Personally, I've managed to avoid SMC (in an unrelated programming exercise) by monopolising all four of the 8-bit IX/Y registers, but that leads to the routine touching all of my non-alternate registers, which definitely feels a little bit excessive! ;) And, underscoring the classic trade-off of space vs. speed, looping using an Ixx register is 1 NOP slower per byte than looping with a normal register, which does count, especially for a non-shifted sprite. So, the one-routine-fits-all and looping routine is only efficient for space. In a speed-intensive context, I would use sprites of constant horizontal dimension and unroll the loop to avoid any horizontal looping and counter-resetting at all (even if it was done via a normal 8-bit register).

And, at least in non-ROM contexts, there are probably good arguments for instead reserving the Ixx registers to store very commonly used variables (e.g. coordinates, HP, etc.), as reading from these registers is quite a bit faster than loading from RAM.</thinkingaloud>
Quote from: Devilmarkus on 13:04, 27 February 12
Quote from: ukmarkh on 11:38, 27 February 12[The owner of one of the few existing cartridges of Chase HQ 2] mentioned to me that unless someone could find a way to guarantee the code wouldn't be duplicated to anyone else, he wouldn't be interested.
Did he also say things like "My treasureeeeee" and is he a little grey guy?

TFM

So why don't you use code that gets expanded (from a compressed 16 KB ROM) into RAM. There it can self modify.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

db6128

It depends. Is code allowed in RAM, or only data/assets?
Quote from: Devilmarkus on 13:04, 27 February 12
Quote from: ukmarkh on 11:38, 27 February 12[The owner of one of the few existing cartridges of Chase HQ 2] mentioned to me that unless someone could find a way to guarantee the code wouldn't be duplicated to anyone else, he wouldn't be interested.
Did he also say things like "My treasureeeeee" and is he a little grey guy?

Sykobee (Briggsy)

Quote from: db6128 on 23:48, 07 January 13
It depends. Is code allowed in RAM, or only data/assets?


Everything has to start off in the ROM. It could be that your first port of call when you |MYGAME is call exomizer to decompress the rest of the ROM into RAM, and then go from there! Maybe not quite in the spirit of things (it's basically a really fast speedloader!).


IMO that does mean that you aren't able to make use of all that lovely free RAM you would otherwise have for double buffering or runtime game data (for the more tactical games).


However a compromise is if you have some favourite self-modifying-code based routines, then decompress them to RAM, and leave the rest of your code in the ROM.

db6128

Quote from: Briggsy on 00:19, 08 January 13Everything has to start off in the ROM. It could be that your first port of call when you |MYGAME is call exomizer to decompress the rest of the ROM into RAM
OK, so it's only the initial conditions that matter.

QuoteIMO that does mean that you aren't able to make use of all that lovely free RAM you would otherwise have for double buffering or runtime game data (for the more tactical games).
Very true, and personally, I think I'd prefer to see people taking this opportunity to exploit a full 64 kB of non-banked memory to do cool things, rather than just decompressing into RAM and doing the same kind of things as if it were loaded from any other medium.
Quote from: Devilmarkus on 13:04, 27 February 12
Quote from: ukmarkh on 11:38, 27 February 12[The owner of one of the few existing cartridges of Chase HQ 2] mentioned to me that unless someone could find a way to guarantee the code wouldn't be duplicated to anyone else, he wouldn't be interested.
Did he also say things like "My treasureeeeee" and is he a little grey guy?

SyX

Quote from: db6128 on 23:48, 07 January 13It depends. Is code allowed in RAM, or only data/assets?
Of course, you can make what you like :)

Quote from: Briggsy on 00:19, 08 January 13However a compromise is if you have some favourite self-modifying-code based routines, then decompress them to RAM, and leave the rest of your code in the ROM.
I'm using exactly that approach.

TFM

Oh. just... btw... in case we use compression... can the game be a 128 KB only game. Or must it run with 64 KB only too?
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

SyX

Quote from: TFM/FS on 18:08, 08 January 13
Oh. just... btw... in case we use compression... can the game be a 128 KB only game. Or must it run with 64 KB only too?
I'm sorry, my friend, but the game must run in all the CPCs with 64KBs of RAM and a romboard, we want that all the machines can enjoy the productions. The next year is 30th anniversary of the 464 :) :) :)

... although i know how attractive the 6128 is, and not only for the extra ram, i think the $C3 paging mode would be used a lot ;)

TFM

Ok, 64 KB is probably a good idea.  :)  So projects don't get too big and stay more realistic.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Gryzor

if someone wanted to make a 128KB title, why not having it as hors concours? Yeah, Ideally not, but...

Oh shit, you're right, it's going to be 30 years. How are we going to celebrate? :)


TotO

Quote from: Gryzor on 13:05, 09 January 13
if someone wanted to make a 128KB title, why not having it as hors concours? Yeah, Ideally not, but...
Sega Master System use 8KB RAM and Megadrive 64KB ...
When you get a ROM support, you don't need much RAM.

No "hors concours", as 64K is far enough with a 16K ROM. (else, no challenge)
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

SyX

Quote from: Gryzor on 13:05, 09 January 13Oh shit, you're right, it's going to be 30 years. How are we going to celebrate? :)
I'm sure that we get nice ideas during the year and we should open a thread for it in a few months ;)

Gryzor

Quote from: SyXQuote from: Gryzor on Today at 14:05:07Oh shit, you're right, it's going to be 30 years. How are we going to celebrate? I'm sure that we get nice ideas during the year and we should open a thread for it in a few months
Why wait? :)


Powered by SMFPacks Menu Editor Mod