CPCWiki forum

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 (http://www.cpcwiki.eu/index.php/Programming) 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).

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 (http://www.cpcwiki.eu/index.php/Programming) 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 (http://www.cpcwiki.eu/index.php/Soft968:_CPC_464/664/6128_Firmware), a side of that you have articles in magazines, for example in the ACU magazine you have this (http://cpcrulez.fr/coding_src-list-investigating_CPC_roms_ACU.htm) and this (http://cpcrulez.fr/coding-eprom_programming__ACU.htm), 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 (http://andrear.altervista.org/contents/msx/inertia/howto/) 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 :)

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 (http://www.cpcwiki.eu/forum/programming/the-firmware-is-interrupting-my-code-popping-my-return-address-and-losing-it!/msg55360/#msg55360) and the great informative replies from arnoldemu (http://www.cpcwiki.eu/forum/programming/the-firmware-is-interrupting-my-code-popping-my-return-address-and-losing-it!/msg55373/#msg55373) and from ralferoo (http://www.cpcwiki.eu/forum/programming/the-firmware-is-interrupting-my-code-popping-my-return-address-and-losing-it!/msg55462/#msg55462).

* aside from not setting certain registers in the CRTC to weird values for extended periods of time

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 (http://andrear.altervista.org/contents/msx/inertia/howto/) 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 (https://github.com/cpcitor/cpc-dev-tool-chain) 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 (http://www.cpcwiki.eu/index.php/Soft968:_CPC_464/664/6128_Firmware) .

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 (https://github.com/cpcitor/findyway) 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!!!  ;)

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

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 (https://github.com/Octoate/cpc-sdcc-rom) (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 :-).

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 (https://github.com/Octoate/cpc-sdcc-rom) (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/ (http://sourceforge.net/projects/hex2bin/) ?

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 (http://sourceforge.net/projects/hex2bin/) ?

It converts the compiled from Intel Hex format to a binary file. Yes, this SF project is exactly what I used for the example.

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.

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

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 :) 

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>

So why don't you use code that gets expanded (from a compressed 16 KB ROM) into RAM. There it can self modify.

It depends. Is code allowed in RAM, or only data/assets?

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.

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: 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.

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?

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 ;)

Ok, 64 KB is probably a good idea.  :)  So projects don't get too big and stay more realistic.

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? :)

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)

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 ;)

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? :)

Well, a 128 KB title would be probably one which is using 64 KB as V-RAM already. Which makes sense when doing a multiways scrolling.
On the other hand 64 KB are enought, even when using double buffering, you still have 24 KB (firmware stays ok) or 32 KB (firmware gets deleted) for the game.

And to compress an (up to) 32 KB game into a 16 KB ROM makes indeed sense in my eyes.

I guess this game compo is a source of motivation for me :) :) :)

Quote from: TFM/FS
 
I guess this game compo is a source of motivation for me

Go for it man!!!

I try [nb]Damn it TFM!!! There is no such thing like trying, either you do it or you don't[/nb] it!

Just do it !  :D

Remembers me about one of these advertisments... What was it again...?

Ah!!!

Riot! Just do it!

Hi,
thanks to duncan_bayne, I have updated the SDCC / Code::Blocks example to support Linux, too. Now the Linux version also doesn't need "wine" to run the "hex2bin" utility, because I have added a native binary. I also changed the Linux Code::Blocks project to use the "Makefile" instead - hey, we Linux users don't need a GUI, a command line and "vi" is enough :-).
You can get the latest version from GitHub (https://github.com/Octoate/cpc-sdcc-rom).

Quote from: Octoate on 23:35, 01 February 13
Hi,
thanks to duncan_bayne, I have updated the SDCC / Code::Blocks example to support Linux, too. Now the Linux version also doesn't need "wine" to run the "hex2bin" utility, because I have added a native binary. I also changed the Linux Code::Blocks project to use the "Makefile" instead - hey, we Linux users don't need a GUI, a command line and "vi"  :o is enough :-).
You can get the latest version from GitHub (https://github.com/Octoate/cpc-sdcc-rom).

Emacs  :P !!!!

Quote from: gerald on 09:34, 02 February 13
Emacs  :P !!!!

Hell yeah!

duncan-bayne/emacs-setup · GitHub (https://github.com/duncan-bayne/emacs-setup)

;D

and python  ;D

Perhaps a rule for future contests is that the program must be fully developed and created on a cpc/plus?

Quote from: steve on 14:04, 03 February 13
Perhaps a rule for future contests is that the program must be fully developed and created on a cpc/plus?

No, because you can't check that.

True; unless the dev also had a live vid stream :D But why anyway?

No need to reduce the participants by adding restrictions.

For convenience, most peoples use their PC with emulators.
The goal is to run to the target machine.

While we're at it let's make devs sit on uncomfortable, non-ergonomic desks and use books to prop the monitor a bit higher :D

Quote from: steve on 14:04, 03 February 13Perhaps a rule for future contests is that the program must be fully developed and created on a cpc/plus?

Why?

Quote from: db6128 on 20:56, 03 February 13
Why?

Just more of a challenge.
I am sure that on an 8 core PC with 64 GB ram and a modern high level compiler, the programs just write themselves :laugh: .

[Sarcastic]
Yeah, that's exactly how it works. Just open a CLI and type: "Make cool CPC game ,assembly,  Target=C:\Coolgame.exe"

I use powerful computers to do the same in hardware. Try the CLI command "Create cool CPC expansion, TTL, RAMExp, s, c", great command. It's a amazing how creative 8 cores can be.
[/Sarcastic]

Bryce.

The whole point of compilers on powerful hardware is to make software easier to write.
I remember in the late 70's there was a program called "the last one", as in the last piece of commercial software a user would ever need to buy.
Of course reality did not match the hype, but that was 30 years ago.

It's not the same for hardware because you are all hardware bods not programmers.  :laugh:

The best software in the world will probably be able to make the job easier and automate certain tasks, but that isn't what makes a good game. Good games require creativity, and no software in the world can offer you that.

Bryce.

Sorry for the 8-core PC, but the CPC can't handle a 1MB "hello world!" nerd program...
Disqualified !!!  :-\

I don't think anyone organising anything like this would take the suggestion seriously, but count me as someone fully against it. Consider it in light of the fact that even many of the titles made during the CPC's original lifetime probably weren't programmed on it much or at all. I have no idea why someone would have a problem with tools that make development easier, prolong an architecture's lifespan, and expand both the boundaries of what it can do and the scene overall. Asking for development to be confined to the native system in real time is asking for stagnation at best.

Well, it has already been said that there is no way of verifying how the program was developed, so that is the end of it, and I never expected people to react they way they have, maybe they thought I was suggesting that they should sacrifice their children to the programming gods. :o

Quote from: db6128 on 02:42, 04 February 13Consider it in light of the fact that even many of the titles made during the CPC's original lifetime probably weren't programmed on it much or at all.

Absolutly.

Quote from: steve on 20:58, 03 February 13
Just more of a challenge.
I am sure that on an 8 core PC with 64 GB ram and a modern high level compiler, the programs just write themselves :laugh: .

That's already challenging enough to design and to write a decent program for the CPC, believe us  ;D

Quote from: db6128 on 02:42, 04 February 13
Consider it in light of the fact that even many of the titles made during the CPC's original lifetime probably weren't programmed on it much or at all.

There was PDS (http://www.cpcwiki.eu/index.php/PDS_development_system).

Quote from: steve on 14:04, 03 February 13
Perhaps a rule for future contests is that the program must be fully developed and created on a cpc/plus?

Pretty unfair for those of us who sadly don't have a CPC in the house, (and wouldn't be allowed one if they tried)!
Also one reason we're still getting games on the CPC is that the PC based development tools make things easier for people to do such things as a hobby.

Quote from: Axelay on 10:13, 04 February 13

There was PDS (http://www.cpcwiki.eu/index.php/PDS_development_system).

Thank you, I was trying to find it w/o success... PDF, PSD, PSS...  :-\

Quote from: steve on 20:58, 03 February 13
Just more of a challenge.

It wouldnt be more of a challenge in a way I would regard as interesting though.  Z80 assembly is Z80 assembly, on whatever you develop it on.  The difference is, my real hardware is a pretty straight forward 128K CPC with 3" disk and Maxam, and from memory, source code of 150k would compile to about a 16k executable in something like 5 minutes.  On my PC, that takes less than a second.  Now if I spot problems, with PC based tools I can immediately pause execution, check various memory locations, restart with break points and get to the bottom of something all in a matter of a few minutes.  On my CPC, I'd have to check those memory locations by assembling a new version with some memory locations written to the screen.  With that 5 minute assembly process each time until I find the problem.  The process is basically the same, but could take an hour or more to achieve the same result that took a couple of minutes on PC.  So I dont see PC tools as making it 'easier', they just make for a far more efficient use of time.

The most important thing for me is that when developing with an emulator, my source code is always safe. When I was writing anything back in the day, even with a ROM-based editor/assembler, I still had to keep saving and loading my source code for fear of corrupting it between runs (made worse by only having an unexpanded 464, so no RAM banking and tape only). It's not even that you can just look to see if the source is still there - what if you just corrupted a few bytes in the middle of the source?

Not only couldn't I use the whole memory, I also had to think carefully about where my source was in memory, which severely limited what I could do.

Even having my source on disc would be safer, but there's still no guarantee if you're doing a loader for instance that you couldn't accidentally format a track.

With a modern emulator, you can just compile and run in a couple of buttons and you know the source is completely safe. Even if you test regularly on real hardware (I do), the boost in iteration time makes it far preferable to using a real CPC for source editing and assembling/compiling.

I don't know if a pc hd is more save than a 3" disc. My first batch of 10 3" discs from 1987 (Panasonic) still runs 100% well, without any error. Now show me that PC HD from 1987  :laugh:

Quote from: Octoate on 23:35, 01 February 13
"hex2bin" utility, because I have added a native binary.

Thanks for the effort. Have you made a fully static binary ?
Else it will fail on many cases, as only the Linux kernel (by contrast with upper layers) makes efforts at binary compatibility (and is very good at that : binaries from kernel before 1.0 are reported to work unmodified on latest kernel). Yet a binary supports only one architecture.

On cpcitor/findyway · GitHub (https://github.com/cpcitor/findyway) (which has a different approach) I elected to automatically download and compile the cross-compiler and iDSK, so as to not add any platform dependency or require the user lenghty procedure before enjoying development.