CPCWiki forum

Edit: Wait, I think I'm OUTing data to the GA in the wrong format, which might explain the weirdness. If I delete this, it's because I discovered that I had failed in a very silly way. :S

Edit again: No, I sorted the OUTput code and the colour numbers (derp)...

INKS_TBL:
db &40,&5C,&4C,&45,&4D,&5D,&55,&57,&5B,&42,&52,&5A,&4A,&4E,&40,&4B,&54
  ; approximately a rainbow, of some kind (ish)

[...]

; mode 0
ld bc,&7F00+&80+0 ; Gate Array + mode + 0
out (c),c
; inks
ld hl,INKS_TBL ; table
ld a,16  ; Start with the border
INKS_SET:
out (c),a
ld d,(hl)
inc hl
out (c),d ; Select pen
dec a  ; next
jp p,INKS_SET ; Repeat while pen >= 0
jr $  ; hang
...but it's still doing the same thing as before. The original message is below. I'd really appreciate if anyone can point me in the right direction; I'm stumped. (unless I find some other thing I did wrong in a comedically silly way :/ )

Yet another edit: I've removed the LD HL (to the start of the table) as it is unnecessary because this second table follows directly from the first, and now it's the OUT (C),r instruction to the Gate Array that the debugger is, for some reason, changing to &ED &7x &...., ignoring the &ED, and doing arbitrary nonsense with the subsequent bytes. This heavily implies that the problem is not with the instructions themselves, but with the memory in/around location &021B; for example, the second-last screenshot below shows WinAPE misintepreting an instruction at &021E subsequently. This just baffles me further, which in itself was something I had thought impossible by this point... Even if I had ever heard of the firmware using RAM in this region, this cannot be a factor as I disable interrupts immediately upon entry.

As well as making no sense at all to me, this is getting very annoying. I was almost making progress before this came along and halted it!  Does anyone have any ideas? This is probably not a very good bug (either with the program, the code, or my brain) report, so please let me know if I can provide any more information that will help.

[original post:]

I typed this already in a form that was perhaps better-explained, but the forum software decided to load the next page, act as though I hadn't typed anything, and send me to a different page when I tried to navigate back using the browser. So, whatever. Thanks, I guess! Note to self: paste everything into Notepad, no exceptions.

I'm coding something - which I will be overjoyed to share if it ever works - but due to my questionable skills decided I would test perhaps the most basic possible thing first, the bit that sets up the screen. Yet apparently I can't even get that right! Although I can't see anything that could be my fault.

As the pictures show, WinAPE is replacing legitimate opcodes with DBs and then executing incorrect instructions as a result afterwards. The code excerpted below, instead of setting the INKs and hanging on the infinite JR as it should, ends up jumping to &07something and then doing a NOP-slide until something makes it RETurn to BASIC.
di  ; Ignore the firmware + stop it from reverting my mode and inks
; screen size
ld b,&BC ; select register
ld hl,CRTC_TBL ; table for 32x32
ld a,(hl) ; counter of pairs
inc hl
CRTC_SET:
[LD C, OUT, INC B, etc., DEC A, JP NZ, blah-blah-blah]
MODE:
; mode 0
ld bc,&7F00+&80+0 ; Gate Array + mode + 0
out (c),c
; inks
ld hl,INKS_TBL ; table
ld a,16  ; Start with the border
INKS_SET:
out (c),a
ld c,(hl)
inc hl
out (c),c ; Select pen
dec a  ; next
jp p,INKS_SET ; Repeat while pen >= 0
jr $  ; hang

What the Debugger thinks is going on:









Sliding back to BASIC, somehow, with INKs conspicuously unchanged:


I haven't got a clue what is going on here. Neither have I dismissed the possibility that I'm missing something really stupid that I've done, but for once, I doubt it. Does anyone have any ideas?