Author Topic: 16KB ROM game compo - technical thread  (Read 8593 times)

0 Members and 1 Guest are viewing this topic.

Offline cpcitor

  • The user previously known as FindYWay
  • CPC6128
  • ****
  • Posts: 235
  • Country: fr
  • My heart still runs on traditional CPC.
    • My code for the CPC.
  • Liked: 111
16KB ROM game compo - technical thread
« on: 13: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).

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

I made 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.

Offline SyX

  • 6128 Plus
  • ******
  • Posts: 1.084
  • Country: br
  • Liked: 1004
Re: 16KB ROM game compo - technical thread
« Reply #1 on: 15:07, 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 :)

Offline db6128

  • 464 Plus
  • *****
  • Posts: 316
  • Country: gb
  • We don’t speak 8080 in this house.
  • Liked: 71
Re: 16KB ROM game compo - technical thread
« Reply #2 on: 17:28, 05 January 13 »
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
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
« Last Edit: 17:34, 05 January 13 by db6128 »
[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?

Offline cpcitor

  • The user previously known as FindYWay
  • CPC6128
  • ****
  • Posts: 235
  • Country: fr
  • My heart still runs on traditional CPC.
    • My code for the CPC.
  • Liked: 111
Re: 16KB ROM game compo - technical thread
« Reply #3 on: 18:58, 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.

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.

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 .
« Last Edit: 09:00, 09 January 13 by FindYWay »
Had a CPC since 1985, currently software dev professional, including embedded systems.

I made 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.

Offline SyX

  • 6128 Plus
  • ******
  • Posts: 1.084
  • Country: br
  • Liked: 1004
Re: 16KB ROM game compo - technical thread
« Reply #4 on: 20:24, 05 January 13 »
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).
 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.

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 ?
Jajaja, we are all in the same situation, stealing time where there is none. Don't forget have fun!!!  ;)

Offline db6128

  • 464 Plus
  • *****
  • Posts: 316
  • Country: gb
  • We don’t speak 8080 in this house.
  • Liked: 71
Re: 16KB ROM game compo - technical thread
« Reply #5 on: 21:24, 05 January 13 »
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. […] 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
[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?

Offline Octoate

  • CPC6128
  • ****
  • Posts: 289
  • Country: de
    • Octoate.de
  • Liked: 59
Re: 16KB ROM game compo - technical thread
« Reply #6 on: 21: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 :-).
--

Offline cpcitor

  • The user previously known as FindYWay
  • CPC6128
  • ****
  • Posts: 235
  • Country: fr
  • My heart still runs on traditional CPC.
    • My code for the CPC.
  • Liked: 111
Re: 16KB ROM game compo - technical thread
« Reply #7 on: 22:03, 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 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.

Offline Octoate

  • CPC6128
  • ****
  • Posts: 289
  • Country: de
    • Octoate.de
  • Liked: 59
Re: 16KB ROM game compo - technical thread
« Reply #8 on: 22:09, 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.
--

Offline Optimus

  • 464 Plus
  • *****
  • Posts: 346
  • Country: gr
  • Liked: 161
Re: 16KB ROM game compo - technical thread
« Reply #9 on: 17:45, 06 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.

Offline arnoldemu

  • Supporter
  • 6128 Plus
  • *
  • Posts: 5.273
  • Country: gb
    • Unofficial Amstrad WWW Resource
  • Liked: 2154
Re: 16KB ROM game compo - technical thread
« Reply #10 on: 15:46, 07 January 13 »
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

Offline Gryzor

  • Administrator
  • 6128 Plus
  • *****
  • Posts: 14.372
  • Country: gr
  • CPC-Wiki maintainer
    • CPCWiki
  • Liked: 2586
Re: 16KB ROM game compo - technical thread
« Reply #11 on: 21:12, 07 January 13 »
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 :) 

Offline db6128

  • 464 Plus
  • *****
  • Posts: 316
  • Country: gb
  • We don’t speak 8080 in this house.
  • Liked: 71
Re: 16KB ROM game compo - technical thread
« Reply #12 on: 21:26, 07 January 13 »
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.

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>
« Last Edit: 21:41, 07 January 13 by db6128 »
[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?

Offline TFM

  • Visit the mysteries of the CPC at www.futureos.de
  • Supporter
  • 6128 Plus
  • *
  • Posts: 9.899
  • Country: aq
  • Space Chicken for FutureOS is free!
    • index.php?action=treasury
    • FutureOS - The revolution on CPC!
  • Liked: 1972
Re: 16KB ROM game compo - technical thread
« Reply #13 on: 22:19, 07 January 13 »
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

Offline db6128

  • 464 Plus
  • *****
  • Posts: 316
  • Country: gb
  • We don’t speak 8080 in this house.
  • Liked: 71
Re: 16KB ROM game compo - technical thread
« Reply #14 on: 00:48, 08 January 13 »
It depends. Is code allowed in RAM, or only data/assets?
[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?

Offline Sykobee (Briggsy)

  • 6128 Plus
  • ******
  • Posts: 653
  • Country: gb
  • Liked: 214
Re: 16KB ROM game compo - technical thread
« Reply #15 on: 01:19, 08 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.

Offline db6128

  • 464 Plus
  • *****
  • Posts: 316
  • Country: gb
  • We don’t speak 8080 in this house.
  • Liked: 71
Re: 16KB ROM game compo - technical thread
« Reply #16 on: 01:27, 08 January 13 »
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
OK, so it’s only the initial conditions that matter.

Quote
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).
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.
[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?

Offline SyX

  • 6128 Plus
  • ******
  • Posts: 1.084
  • Country: br
  • Liked: 1004
Re: 16KB ROM game compo - technical thread
« Reply #17 on: 15:50, 08 January 13 »
It depends. Is code allowed in RAM, or only data/assets?
Of course, you can make what you like :)

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.
I'm using exactly that approach.

Offline TFM

  • Visit the mysteries of the CPC at www.futureos.de
  • Supporter
  • 6128 Plus
  • *
  • Posts: 9.899
  • Country: aq
  • Space Chicken for FutureOS is free!
    • index.php?action=treasury
    • FutureOS - The revolution on CPC!
  • Liked: 1972
Re: 16KB ROM game compo - technical thread
« Reply #18 on: 19: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?
 
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Offline SyX

  • 6128 Plus
  • ******
  • Posts: 1.084
  • Country: br
  • Liked: 1004
Re: 16KB ROM game compo - technical thread
« Reply #19 on: 23:19, 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 ;)

Offline TFM

  • Visit the mysteries of the CPC at www.futureos.de
  • Supporter
  • 6128 Plus
  • *
  • Posts: 9.899
  • Country: aq
  • Space Chicken for FutureOS is free!
    • index.php?action=treasury
    • FutureOS - The revolution on CPC!
  • Liked: 1972
Re: 16KB ROM game compo - technical thread
« Reply #20 on: 00:04, 09 January 13 »
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

Offline Gryzor

  • Administrator
  • 6128 Plus
  • *****
  • Posts: 14.372
  • Country: gr
  • CPC-Wiki maintainer
    • CPCWiki
  • Liked: 2586
Re: 16KB ROM game compo - technical thread
« Reply #21 on: 14:05, 09 January 13 »
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? :)


Offline TotO

  • 6128 Plus
  • ******
  • Posts: 2.962
  • Country: fr
    • ?area=showdonations;u=4
    • Cent Pour Cent [dot net]
  • Liked: 2074
Re: 16KB ROM game compo - technical thread
« Reply #22 on: 14:57, 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)
Unregistered from CPCwiki forum.

Offline SyX

  • 6128 Plus
  • ******
  • Posts: 1.084
  • Country: br
  • Liked: 1004
Re: 16KB ROM game compo - technical thread
« Reply #23 on: 15:17, 09 January 13 »
Oh 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 ;)

Offline Gryzor

  • Administrator
  • 6128 Plus
  • *****
  • Posts: 14.372
  • Country: gr
  • CPC-Wiki maintainer
    • CPCWiki
  • Liked: 2586
Re: 16KB ROM game compo - technical thread
« Reply #24 on: 16:31, 09 January 13 »
Quote from: SyX
Quote 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? :)