I noticed that the assembler doesn't like using IX and IY as half registers. Is it unsupported, or using a different syntax than the one I expected - LD IXH,A ?

Technically, they aren't official Zilog instructions, but most assemblers go for them. It's sometimes really handy to load IX and IY in halves, or you desperately need that extra register :-)

From a manual on assembler:


More Control Over Index Registers
You know, you can access the high and low bytes of IX and IY. It's a little more complicated because the instructions aren't officially supported by ZiLog, and it is a little on the unelegant side. Nevertheless they can be useful in some circumstances, like when all your registers are locked up and you need an 8-bit counter bad.
The high byte of IX is called either IXH or HX (remember these are unofficial registers so there are no standard names). The low byte is called either IXL or LX. The high and low bytes of IY are named similarly.

To use a part of an index register in an instruction:

Pick an instruction that allows both H and L to be used as an operand, excepting shifts, rotates, BIT, SET, and RES.
Use H if you want the high byte, or L if you want the low byte.
Immediately precede this instruction with .DB $DD to use the IX half-registers, or .DB $FD to use the IY half-registers.
Example: LD E, IXH
.DB $DD
LD E, H

Example: SUB IYL
.DB $FD
SUB L

Be aware that once you specify a prefix, you are locked into using that index register's half-registers. It is impossible to combine the half-registers of HL, IX, or IY in one instruction:
.DB $DD ;LD IXH, IXL
LD H, L

Tip of the day:

Clearly, a US keyboard doesn't have this £ thing. I have no idea if it's on a spanish or austrian one. I doubt it. So, just in case you need it, with a default US character set, the ` (back quote) seems to do the same job in compiled code.

Chances are I'm the only person that's relevant to. But hey I'm sharing anyway. Hush.

I have polished a bit my sprite routine, writting it in just one file and erasing repeated code (it worked OK up to this point) and adding a new subroutine to set the background colour of the playing area. Wheter I use or not this routine (and even if I take it out of the sprite routine file and copy it in any part of the main program code) its causing the graphics behave strangely.

When I'm drawing the "show room" (the only one atm, where I'm trying the graphics and the movements) I call (via Gosub) the routines drawing the different parts, i.e.:
GOSUB ESQUINA -- DRAWS THE CORNERS
GOSUB HABITACINESCONPUERTA -- DRAWS THE "WALLS" AND THE DOORS

When I draw the decoration parts (i.e. a carpet, or different floor designs) I see one of the coordinates of the sprites is changed:

If I draw the carpet (GOSUB ALFOMBRA), then the transparent window has its Y coordinate changed, whatever the correct value is.

If I draw the star (GOSUB ESTRELLA), the main sprite's X coordinate is changed.

And so on. I'll copy the .bas files for the game and the library so you can check it changing between the decorations (MADERA, FLECHAIZDA,FLECHADERECHA,ESTRELLA,SUELOEQUIS,LABERINTO). Perhaps it makes any sense to you. I don't include the .rle file because its the same I sent you last time.



The main program:

This version enhances zxbasm (ZX BASIC assembler), so the compilation process is much much faster:
Download here: <!-- m --><a class="postlink" href="http://www.boriel.com/files/zxb/zxbasic-1.2.5r1513e.msi">http://www.boriel.com/files/zxb/zxbasic-1.2.5r1513e.msi</a><!-- m -->

The assembler doesn't seem to like LD A,R which is standard Mnemonics for instruction ED5F.

I think we need some word in the definition for subs and functions that makes -O2/3 NOT optimize something out of the loop because it doesn't seem to be called - but needs to be kept in, perhaps because it contains asm code that we need to keep.

REQUIRED SUB Name()
REQUIRED FUNCTION a(b as uInteger) as uinteger

or some such?

This then culminates in interesting stuff like

REQUIRED SUB initialize () AS INTERRUPT
<code>
END SUB

This version fix -O3 bug related to bit-rotation routines (mostly used in graphics and scroll routines).
Download here: <!-- m --><a class="postlink" href="http://www.boriel.com/files/zxb/zxbasic-1.2.5r1513c.msi">http://www.boriel.com/files/zxb/zxbasic-1.2.5r1513c.msi</a><!-- m -->

If you previously experienced any problem with -O3, you should try now with this new release.

Also, for people wanting to send me some test code: you may also send me the code in a private message attachment (e.g. you have a game you don't want others to see before it's finished, or even a commercial game, etc...)

I don't know how to call this, but heretic might be close. Let me explain what happens:

I'm making my crap game and I'm following strictly the programmers manual of good practics, you know, first I do the loading screen, then I do some graphics, sprite first and then the backgrounds and at last I try to do some code to move the whole thing with QAOPM (it could be I'm reading the manual upside down, yes).

Now I'm at the stage where I have the sprites done and I'm making the rooms' background. At this stage I just draw it all on the screen and when I'm happy with an item I add a ' before the line to make it a coment and move on to the next item. When I have everything, I will sort it all out.

Well, I had the first room layout. I did a carpet to decorate it. It was ok so I greyed it out (with the ' ) and started to desing a "David Star". When I print it, the first two graphics of the sprite data (which happen to be the mask for the sprite looking down) are corrupted. Somehow it seems that the background data (made with plots and draws) is overwritting the beginning of the sprite data. The strange thing is that if I print the carpet first and over it I print the star, nothing happens. And if I print the star making it double lined, everything is OK too.

So I'll send you a package with the code and attachements so you can check it if you want. No need to hurry up, I can workaround it and go on with the game.

Apenao

Attached Files

  gentle.zip (Size: 7.72 KB / Downloads: 949)

It would be nice to be able to map the program produced in memory, work out where it is - and optionally, where gaps are (very useful for IM2 stuff) so that the gaps could be used. Even if only as buffer memory for other functions.