Print Page - My brain is awful at emulating real brains [prev. “WinAPE is replacing opcodes”]

WinAPE is fine; it was me who was beind weird! Original post below for posterity/embarrassment.

Spoiler: Show

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)...

Code: [Select]

 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.

Code: [Select]

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:

(http://i.imgur.com/Km9mo.png) (http://i.imgur.com/Km9mo.png)

(http://i.imgur.com/8H0GH.png) (http://i.imgur.com/8H0GH.png)

(http://i.imgur.com/MQlKU.png) (http://i.imgur.com/MQlKU.png)

(http://i.imgur.com/tCfzP.png) (http://i.imgur.com/tCfzP.png)

Sliding back to BASIC, somehow, with INKs conspicuously unchanged:
(http://i.imgur.com/zRpr0.png) (http://i.imgur.com/zRpr0.png)

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?

Try setting the mode with:

ld bc,&7F00+&8C+0
out (c),c

Bits 2 & 3 must be set to disable upper and lower rom. You'd be banking in the lower ROM over your program with the value you have been using.
Check out Grim's page (http://www.grimware.org/doku.php/documentations/devices/gatearray) on the gate array for more detail.

The firmware has an interrupt that resets the inks to the ones *IT* wants.
You talked to the hardware, it then interrupted a bit later, and talked to it too ;)

EDIT: Correction. I see that you added a di.

hmmm

Quote from: arnoldemu on 11:23, 05 December 12

The firmware has an interrupt that resets the inks to the ones *IT* wants.
You talked to the hardware, it then interrupted a bit later, and talked to it too ;)

EDIT: Correction. I see that you added a di.

hmmm

Axelay is correct. Your code is in lower rom location 7f80 will probably turn on the lower rom. move it to another location e.g. &4000 or change the OUT.

Oh, brilliant - thanks a lot for spotting that, Axelay, good catch! :) And thanks to Arnoldemu for the suggestions, too. I clearly rushed too much when reading about the GA – so although it is quite a confusing device, this was more a case of my brain not having all the right bits set. Thanks again, both of you! And my apologies to WinAPE, haha.

Anyway, when I’m finished with this, I doubt there’ll much addressing space left for any of this “ROM” and “firmware” malarkey ;)

CPCWiki forum

General Category => Emulators => Topic started by: db6128 on 23:54, 04 December 12