Inkspector 2.0.5 available

[XoRRoX]

I'm having another issue that I'm having trouble understanding.

When I use Go To Address in the debugger, type an address, select RAM Page #0 and press OK, it stays in RAM02 in the listing, instead of the expected RAM00.



Perhaps it's selecting the currently active page? Would it be possible to have a setting where one can select a RAM page it goes to by default, or an Auto setting where it'll select the active page?

[XoRRoX]

When entering a new value in the Poke function, the Poke button doesn't become active. When pressing Enter, the value also isn't changed in memory.




For now, I used the Write memory function instead.

[PeterJ]

@XoRRoX,

I have mentioned @Inky so he gets a notification regarding your questions.

Just use the '@' symbol and start typing the username, then pick the name from the Drop-down list that appears. The user then gets an email or notification alert.

[g0blinish]

32bit please

[Inky]

When entering a new value in the Poke function, the Poke button doesn't become active. When pressing Enter, the value also isn't changed in memory.




For now, I used the Write memory function instead.

The Poke button is disabled while an RZX recording is being made. I should probably make this a bit more obvious

[marenja]

bugreport

Tools > Assemble Clipboard Contents fills skipped space with zero values.

;part 1
org $5820
db 0,56,48,8,16,24,32
ld a,1
ld a,2
ld c,3
ld hl,addr

;part 2
org $5920
db 0,56,48,8,16,24,32
addr:
ld a,1
ld a,2
ld c,3
ld hl,addr

In this example right picture shows a large black area of bytes that I was not going to change. Left picture is expected result - two separate areas of changed bytes.

Everything is almost good if you do operation 2 times - 1st with part 1 and 2nd with part 2. But this trick is not good if you have labels across parts or if you have a lot of different parts.

[Inky]

bugreport

Tools > Assemble Clipboard Contents fills skipped space with zero values.


In this example right picture shows a large black area of bytes that I was not going to change. Left picture is expected result - two separate areas of changed bytes.

Everything is almost good if you do operation 2 times - 1st with part 1 and 2nd with part 2. But this trick is not good if you have labels across parts or if you have a lot of different parts.

@marenja
The assembler is actually working as intended. It’s copying all the memory between the lowest assembled address ($5820) and highest ($592F). At the moment it doesn’t track individual addresses that have been assembled to (so that it can copy only those). However, the assembler’s .pok file generation code added in 2.0.5 does track the addresses (otherwise you could end up with ridiculously large .pok files containing harmful zeros if you had lots of ORGs), so I will make the assembler use the .pok address tracking code for everything in 2.0.6, which will make the assembler work as you expect in this case.

[XoRRoX]

InkSPector already works great with the left analogue stick of my Xbox S joypad. For isometric games I'd prefer the d-pad instead. Would it be possible to link the controls of the analogue stick to the d-pad's? Then they could be used interchangeably.

[sn3j]

Thank you for this great work @Inky. Is it ok to add a bug report here or is there a more formal way?

I have an issue with Kempston mouse support. My Basic program reads out the x/y port values with IN and places the pointer accordingly on the screen. This works well with display scale at 100%, the pointer follows the PC mouse movement to the spot. But at scales 200% and 300% the pointer runs away from the mouse (at 2x/3x speed). It seems the mouse coords are not adjusted to the display scale.

Another thing is that the keys 0-9 from the numeric keypad are not mapped to the regular keys 0-9 (might be I missed to set an option here).

And a minor issue is that by default the cursor keys are mapped to nothing which seems a bit restrictive. 2.0.4 had "Native cursor keys" as default.

[Inky]

Thank you for this great work @Inky. Is it ok to add a bug report here or is there a more formal way?

I have an issue with Kempston mouse support. My Basic program reads out the x/y port values with IN and places the pointer accordingly on the screen. This works well with display scale at 100%, the pointer follows the PC mouse movement to the spot. But at scales 200% and 300% the pointer runs away from the mouse (at 2x/3x speed). It seems the mouse coords are not adjusted to the display scale.

Another thing is that the keys 0-9 from the numeric keypad are not mapped to the regular keys 0-9 (might be I missed to set an option here).

And a minor issue is that by default the cursor keys are mapped to nothing which seems a bit restrictive. 2.0.4 had "Native cursor keys" as default.

Hi @sn3j! Sorry for this tardy reply

Reporting bugs here's fine. Just to let you know all three of these things have already been addressed for 2.0.6 which I'm hoping will be out sometime in May, free time permitting.

Cheers,
Inky.