Having difficulty running the cpc-sdcc-rom on WinCPC on Linux

[duncan_bayne]

Hi All,

I've compiled the demo CPC ROM from Octoate/cpc-sdcc-rom · GitHub on Linux with the following commands:

sdasz80 -o ./obj/Release/crt0.rel ./lib/crt0.s
sdcc ./src/main.c --opt-code-size --code-loc 0xC100 --data-loc 0x1000 -o ./bin/Release/SDCC\ ROM.ihx --lib-path ./obj/Release --no-std-crt0 -mz80
wine ./util/hex2bin.exe -e rom ".\bin\Release\SDCC ROM.ihx"

This works, with the following output:

hex2bin v1.0.10, Copyright (C) 2012 Jacques Pelletier & contributors

Lowest address  = 0000C100
Highest address = 0000CEF1
Pad Byte        = FF
8-bit Checksum = 54

... and produces a file called SDCC ROM.rom.

However, when I load that into WinCPC and reset the emulator, it basically sits there resetting ... the normal Amstrad welcome text is displayed, then it immediately resets, displays the welcome text, resets, and continues that until I power off and virtually remove the ROM.

I'd greatly appreciate any tips.  I suspect I'm doing something daft here ...

Yours,
Duncan Bayne

[ralferoo]

Can you attach the built ROM file, that way we can take a look at it to see what the problem might be. Certainly crt0.s looks correct and for ROM initialisation, all it does is print a message and return.

It's possible that you're not linking in the generated crt0.rel (I'm not sure what --no-std-crt0) does, nor do I know why you have code-loc at 0xc100. I know it's not gcc, but I'd have expected you to either have a linker script or link the crt0 in first and specify a start address of 0xc000.

That said, it's entirely possible everything's fine and you've just put the ROM in the wrong spot. That continual reboot behaviour is what happens if there's no foreground ROM in slot 0, so you could maybe try to rom in slot 1. But attach the rom image and we can look at what it's doing.

[duncan_bayne]

Right, so the problem has something to do with my Makefile ... I installed Code::Blocks on Linux, tweaked the project to build, and the resultant ROM runs just fine in my emulator.

So I'm obviously missing a step here.  I built the Makefile by cribbing from the Code::Blocks project in the demo GitHub repo.  Perhaps there's an implicit linking step in there that I'm missing or something.

Anyhow I'll let folks know when I've got it building properly without Code::Blocks, and submit a pull request to the project.

[duncan_bayne]

I've submitted a pull request for Linux support ( Linux support by duncan-bayne · Pull Request #1 · Octoate/cpc-sdcc-rom · ) ... now I'm off to figure out why building through a Makefile produces a garbage ROM.  I'm not a fan of IDEs; I'd much rather use Emacs.

[ralferoo]

Ummm, not sure if you know, but that's not what a pull-request is for... It's to say that you have a specific set of patches that you want integrated back into the original author's git tree. If you just want help, you'd be better off e-mailing him.

[TFM]

That ROM has 0 KB, so a problem in compiling?

[duncan_bayne]

Ummm, not sure if you know, but that's not what a pull-request is for... It's to say that you have a specific set of patches that you want integrated back into the original author's git tree. If you just want help, you'd be better off e-mailing him.

Thanks for the tip, but I get the difference :-)  It was just slack use of language on my part.  The aforementioned pull request contains a commit with a new Linux-friendly Code::Blocks project, and a shell script to set up dependencies on a Debian-like distro.  I should have said "created a pull request that provides Linux support."

That ROM has 0 KB, so a problem in compiling?

Definitely.  I was actually missing a step that was implied by the Code::Blocks project but never explicitly stated.  This is why I don't like IDEs    I figured it out by writing a wrapper for SDCC that simply logged every call with all parameters.  The correct Makefile looks like this.