sjasmplus for Amstrad development

[JD]

Hi guys,

I'll start off my telling you my situation. I've written a game in assembly for the Commodore 64. The game part (logic and content) is virtually complete as of the last few weeks. Additionally, a few months ago I started translating the game code from 6502 to Z80, and writing compatible sprite routines to get the game running on the ZX Spectrum. It's a little behind the C64 version in features and bugfixes, but apart from that it's close to being finished as well.

So that just leaves the big one I'd like to complete the set and get this game on the Amstrad CPC464 as well. Most of the game code should be identical to the Spectrum version, just needing new drawing/sound/input routines etc. So in theory at least, it should be the quickest of the 3 to do. I'm having some trouble getting started though. I used sjasmplus for the Spectrum port, and I don't believe it has support for Amstrad output by default (although I've heard people have come up with their own custom solutions?). I've downloaded and tested pasmo, and successfully built the 'hello world' to a CDT. I've tried running the sjasmplus style Spectrum source of my game through pasmo just to see what happened, and it had rather a lot of problems. After I removed some sjasmplus specific lines and converted the local labels to pasmo's format, it started picking up invalid operands on some instructions (like ex hl,de / ex de,hl, or sometimes just add 8 instead of add a,8). I'm a long way from being an expert at Z80 coding so I don't know if and where I've used pseudo-ops that sjasmplus supports and pasmo doesn't. Or if that's even the problem :S I don't mind if I have to have 2 different sources for the 2 versions but it'd be good if they could both use the sjasmplus syntax so that the large portions of common code could be kept synchronized more easily.

Just wondering if anyone's had experience using sjasmplus for CPC development, or tips in general about the Spectrum -> Amstrad conversion.

A few extra notes. I'm mostly working on a Mac although I have a PC available. And the game is actually an improved version of a unexpanded Commodore VIC-20 game I made some years ago, which should tell you it's not cutting edge

Thanks for reading!

[TFM]

KUDOS!
Well, I don't know about Pasmo, but commands like "ex de,hl" or "add a,8" should be usable for all Z80 assemblers. At least MAXAM (runs on the CPC itself) works with that.

The biggest work for a specccy port is to bring things on the screen. While the speccy has a text mode (I think?), the CPC uses the upper 16 KB (&C000 to &FFFF) as video-ram.
Informations can be found at:
Unofficial Amstrad WWW Resource

Good luck for your project :-D

[arnoldemu]

Some notes:

Safe memory range is &0040-&a700.
basic loads to &170.

Lowest place you can *LOAD* a binary file to is &389 e.g.:

openout"d"
memory <address>-1
closeout
load "code",<address>
call <exec>

Screen is normally at &c000-&ffff.
stack is normally at &c000 and goes down.

lower rom (containing OS) can be paged into memory between &0000-&3fff.
upper rom (containing BASIC or others) can be paged into memory between &c000-&ffff.

From basic, a game is run with:

RUN"<filename>

keep it in the safe memory ranges and it'll run from cassette and disc.

screen is normally 40 crtc chars wide, 25 crtc chars tall. firmware functions work with this.

coding for cpc is similar to coding for spectrum.

the code to calculate the next screen line is different.
look at: http://www.cpctech.org.uk/docs/os.asm and find "SCR NEXT LINE".

there are other bits of code in the wiki that show the same idea, and how to read the keyboard.

I hope that helps you.

ex hl,de is not a valid instruction it's ex de,hl

some assemblers accept add a,8 others just add 8.

[Gryzor]

Wow, a cross-platform title from the same developer? This should be reeeeally interesting!

[fano]

Just wondering if anyone's had experience using sjasmplus for CPC development, or tips in general about the Spectrum -> Amstrad conversion.

Hi , i am not using sjasmplus but sjasm for my bigger devs on CPC.As i ignore totaly firmware, i do not see a lot of difference in CPC or Speccy except for hardware (GFX/SND/INPUT/MASS STORAGE), regular Z80 code ran exactly the same for me.If you need more details about the hardware programming , just ask , we'll explain here 
I rode somewhere sjasmplus is bugged, but without precision.Did you encounter problems with it ?

[JD]

@TFM/FS Thanks! That link will come in handy when I get on to the hardware specific stuff. The Spectrum also has only a bitmap, no tiled mode like the C64 and VIC-20. The VIC by contrast doesn't have a bitmap mode, only a few user definable characters with which you can simulate one. The code to get sprite movement at 1x1 precision took up quite a large part of the games 4k size   The screen matrix of the VIC and C64 game is actually simulated on the Spectrum, both for background collisions and for managing buffered sprites without the need for a full screen double-buffer (its complicated!).

@arnoldemu Thats some useful info. I assume the purpose of staying within the safe memory area is so that data can be loaded in from tape or disk without having to be unpacked, or have a special loader to load data into the trickier areas? Because the game data needs to fit into about 40k on the Spectrum, it should be feasible to fit it into the safe area. One thing about the 40x25 I'm contemplating is, I believe it's possible to cut this down to 32x24, like the Spectrum? The game's play area is only 256 pixels wide to allow all versions to use the same stage layouts, so saving some screen buffer memory sounds useful. Admittedly I don't know if it actually frees up any memory or just reduces the scanned area? Any info about that would be great.

@Gryzor It's been an ambition of mine to create a game on all three of the big 8-bit home computers, and I'm particularly looking forward to the Amstrad since I've never programmed one before

@fano I don't expect I'll be using any of the ROM either, just directly accessing the memory/ports etc. Help and advice would be much appreciated, I'm sure I'll have something to ask once I get further forward in it! To be honest, I don't remember if I found any issues with sjasmplus that I would describe as bugs - the copy I built from source gets a bit confused about line numbers in the error output, which I believe is down to the type of line endings in the source. Other than that I've found it to be quite good. I'd like to keep using it, if only I knew what to do with my output to get it into the memory of an emulated CPC? I don't know much (well, anything) about the Amstrad's emulation file formats, or tools that exist for managing .dsks or .cdts.

[fano]

One thing about the 40x25 I'm contemplating is, I believe it's possible to cut this down to 32x24, like the Spectrum? The game's play area is only 256 pixels wide to allow all versions to use the same stage layouts, so saving some screen buffer memory sounds useful. Admittedly I don't know if it actually frees up any memory or just reduces the scanned area? Any info about that would be great.

CPC display zone is fully configurable with CRTC regsiters 1 and 6 for dimensions (in characters) , registers 2 and 7 are used to set position on screen (more info here : CRTC - CPCWiki).You can easily compute char position on screen address with this simple formula (x unit is byte , y is line)
addr=base_adress(#C000 is default)+x+(y\8*(CRTC register 1 value*2))+((y MOD 8 )*2048)
In other terms each character first line is accessible in a linear way (char width = 2 bytes), next lines are every 2048 bytes.
If posted some time ago something that may be usefull to understand screen addressing on CPC : Hardware scrolling: problem with sprites/tiles

Problem with saving memory in this configuration is it fragmented as screen memory is composed of 8*2K blocks, on blocks for each line of a char .So ,  if you use a 32*24 chars config , you'l get for a (32*24*2) so 1536 for each block , you'll save (2048-1536) per block so 8*512=4K.The problem is you will get this free space at the end of every block so :
512 bytes at #C000+1536
512 bytes at #C800+1536
512 bytes at #D000+1536
...
and so on.If you can deal with that , it can be usefull (i used this in rtype (that is somewhat of speccy port in 32*24 chars) to add some compiled graphics)

About keeping sjasm+ , you can output a binary file and using Winape to build a file that include your binary and run it.For example, if your binary has been compiled at #1000 :

org #1000
run #1000
nolist
incbin "mybinairy.bin"

just run that in winape assembler , this is the way i am testing my programs compiled with sjasm.If you need breakpoints, with winape you can use a 2 bytes sequence (from norecess) directly in your binary that halt the emulator : db #ED,#FF

[Prodatron]

addr=base_adress(#C000 is default)+x+(y\8*(CRTC register 1 value*2))+((screen MOD 8 )*2048)

Small correction:

addr=base_adress(#C000 is default)+x+(y\8*(CRTC register 1 value*2))+((y MOD 8 )*2048)

[fano]

ops, thx

[arnoldemu]

@arnoldemu Thats some useful info. I assume the purpose of staying within the safe memory area is so that data can be loaded in from tape or disk without having to be unpacked, or have a special loader to load data into the trickier areas? Because the game data needs to fit into about 40k on the Spectrum, it should be feasible to fit it into the safe area. One thing about the 40x25 I'm contemplating is, I believe it's possible to cut this down to 32x24, like the Spectrum? The game's play area is only 256 pixels wide to allow all versions to use the same stage layouts, so saving some screen buffer memory sounds useful. Admittedly I don't know if it actually frees up any memory or just reduces the scanned area? Any info about that would be great.

Yes, the safe area is for the purpose of loading and being compatible with the firmware while loading.

After that you can freely unpack data as you need, and as long as you disable interrupts or "turn off the firmware" by re-directing the interrupt and not using any functions, you can overwrite the firmware area and use it for yourself, after that you need to everything yourself.

Methods I have used before are to load as much as I can into the safe area, load some into the screen area, turn off firmware, relocate screen part down lower so the screen stays at &c000, and then you're free to re-use it.

Yes the screen can be resized the same as the spectrum. Provided you do not use hardware scrolling, this gives you extra space, although because of the layout of the screen, it's not continuous, it's in 8 seperate blocks, but it's enough to store data and code.