aaarugh!!!!!!!!!!!!!!!!!!!!!!!!!

[AMSDOS]

This is stupid, I cannot get this dam thing to work properly, I've tried a different tact on this by relocating the screen to &4000 which has almost worked, but now the sprite routine isn't behaving like it should. Works good when the screen is at &C000<->&FFFF, but at &4000 I can display the entire thing at the top of the screen X = whatever & Y = 199, but go below that and it starts to chop the bottom of the sprite off! Have a Look at it when Y = 100 and Y = 10 for instance and you see what I mean!! I've got a feeling it's got to do with the address the Firmware is returning from the SCR DOT Position (&BC1D), and tried to correct this by Subtracting the value in H by &80, but alas no good!    I don't know how to use those SUB, SBC or whatevers!    I discovered earlier that the same result would happen if I had the screen at &C000 and had read "LD BC,&4050" in the sprite routine below and of course it works when it's set BC is set to &C050, though I tried it the other way "LD BC,&4050" after I relocated the screen to &4000<->&7FFF only to get the same result!    Please Help!! 

Code Select Expand

ORG &2000

LD A,&40
CALL &BC08
RET
.BEGIN
LD L,(IX+00)
LD H,(IX+01)
LD E,(IX+02)
LD D,(IX+03)
;; LD HL,YVAL
;; LD DE,XVAL
CALL &BC1D
PUSH HL
LD DE,SPRITE
EX DE,HL
LD C,(HL)
INC HL
LD B,(HL)
INC HL
EX DE,HL
POP HL
.NOTZERO 
PUSH BC
PUSH HL
.LOOP 
LD A,(DE)
XOR (HL)
LD (HL),A
INC HL
INC DE
DJNZ LOOP
POP HL
LD BC,&0800
ADD HL,BC
JR NC,EXIT
LD BC,&C050
ADD HL,BC
.EXIT 
POP BC
DEC C
JR NZ,NOTZERO
RET
.XVAL
DEFW 100
.YVAL
DEFW 100
.SPRITE DEFB &08
DEFB &02
DEFB &00
DEFB &00
DEFB &30
DEFB &C0
DEFB &73
DEFB &EC
DEFB &73
DEFB &EC
DEFB &73
DEFB &EC
DEFB &73
DEFB &EC
DEFB &30
DEFB &C0
DEFB &00
DEFB &00


[ervin]

I haven't had a chance to try yet, but I *think* it may be because of this bit:

LD BC,&0800
ADD HL,BC
JR NC,EXIT
LD BC,&C050
ADD HL,BC
.EXIT 

It looks as though the line
JR NC,EXIT
will only work as intended when the screen lives at &C000.

Because if the screen is at &4000, you won't get a carry until many more &0800's have been added.
Instead you probably need to check if HL has increased past &7FFF.

Something like that anyway.

[AMSDOS]

Think you might have something there with the "JR NC,EXIT", I calculated the it from the top - 4000 and 8 or 9 calculations takes it to &8000. So it needs to be something which needs checks if &7FFF has been reached or passed and if so to re-adjust, to &4000. So what the routine at the moment is doing is checking if the address has reached 0 or passed it and if so to load BC with &C050. Bit confused why it's &C050 in that example which is the 4th or 5th line down?

Unfortunately my understanding of JR and flags isn't great, so if an example can be provided which implements that strategy, that would be wonderful.

[arnoldemu]

something like this should work at any screen address (not tested):

Code Select Expand


ld a,h
add a,&8
ld h,a
;; at this point it will go to zero if wrapped
and &38
jr nz,exit
ld bc,&0050-&3800
add hl,bc


Sorry I've not helped with this recently. I've not had chance to look at the cpm2.2 memory map etc close enough to know how to make it all work.

[AMSDOS]

arnoldemu wrote:

something like this should work at any screen address (not tested):

Code Select Expand


ld a,h
add a,&8
ld h,a
;; at this point it will go to zero if wrapped
and &38
jr nz,exit
ld bc,&0050-&3800
add hl,bc


Sorry I've not helped with this recently. I've not had chance to look at the cpm2.2 memory map etc close enough to know how to make it all work.

Close enough for me, that routine left a small gap in the sprite, so I just altered "LD BC,&0050-&3800" to "LD BC,&0050-&4000" without really knowing what that line was doing and it works fine now. Have only tested this in AMSDOS, so fingers crossed it works in CP/M - from what I could make out it was going to work in CP/M 2.2 without Disabling or Enabling Upper ROMs though.

Oh well that's fine!! The number of Pascal Compilers I can use are limited, something which I can selectively replace TP with is either too expensive (Embeded Pascal) or in early infancy with Z80-Pascal at Sourceforge, may have the potential to become another developing program for the CPC, unfortunately it appears it will take a while to develop it. Did try one of the other AMSDOS based Pascals, though couldn't really get the hang of it, probably because TP sets a high benchmark which is what made it a popular developing tool in it's day.