archive.worldofdragon.org

I have tried my old code changing $c000 by $8000 and the result is the same.
If the machine has only 32K, the area from $8000 on *is* ROM, and so it should not
be overwritten ... I think that this will not happen on the real D32

cheers
pere

I see that you don't switch to MAP1 ... The code I was trying does this: sta $ffdf ; switch to MAP1 ldd $c000 ; get two bytes from rom area ldx #$9669 ; create a pattern 1001 0110 0110 1001 stx $c000 ; store into two dos-rom bytes cmpx $c000 ; have been modified? bne No64K ; NO, this machine cannot ...

Hi Ciaran,
thanks a lot for this explanation. I had not thought about this possibility ...
Will try your code.
Just need to be sure that a program that must switch to map1 is not loaded in a 32k machine.
Will tell you how it works for me.

cheers
pere

Hi Ciaran, I am trying to verify a program that switches to MAP1 and writes a word into $c000 then compares the written value to what exists in $c000 and much to my surprise the memory has been written! Even having told XRoar that I want a 32K machine ... I might be wrong, but right now I don't reme...

Hi Pere, To answer your second question, you can specify the jump destination without quotes to pass it by value: CONDJMP a00100 Your first question is more difficult. I've tried before and failed to pass an instruction as a macro parameter. I think it's possible to supply a string to be used as pa...

Hi Ciaran, using this definition CONDJMP MACRO IF ( (\{1}-(*+2)) > 127) lbeq \{1} ELSE beq \{1} ENDIF ENDM and using it this way CONDJMP "a00100" This is the result I get in the .lst file 1BCD CONDJMP "a00100" IF ( (\{1}-(*+2)) > 127) 1BCD 10270000 lbeq \{1} ELSE beq \{1} ENDIF No way to use the par...

Hello, I would like to create a macro that should use a long branch or a short branch upon the distance to the target label. Say something like this: IF (a00100 - (*+2) > 127) ; a00100 is the label where execution should branch if condition satisfied lbeq a00100 ELSE beq a00100 ENDIF How could I cre...

cheers!
hope you enjoy the nice task of debugging
pere

I have a very vague recollection that when I started that patch, the "missing" registers didn't cause any issues, but later they did. I'd say I need to distinguish between 6809 and 6309 targets, but to do the same patch against modern GDB now would mean starting from scratch anyway, and there might...

Another important point ...
IIRC you need to use a 6309 emulation or you will have problems with the '9' register
It looks like GDB 'needs' to get access to all of the registers of the 6309 CPU, so you cannot
debug a 6809 emulation or at least I am not aware of how could this be done
cheers