OS-9 Level 2 for (updated) Dragons

[robcfg]

Isn't $86C70 too big of a number?

That's over 512KB...

[sixxie]

Well there's all the other snapshot metadata too.

Sorry, I tried replying but it looks like my submission got lost.

The snapshot format is probably a bit to random to predictably know what maps to what I'm afraid.

And saving as .ram doesn't include iMMUnity - I'll try and fix that, at which point a .ram file would contain the 64K on-board, followed by the iMMUnity RAM.

[sixxie]

Ok new snapshot here

https://www.6809.org.uk/tmp/xroar/

snap-1.13.22 will include iMMUnity RAM when you save a snapshot with a .ram extension (which is just the RAM - not a snapshot you can re-load - but useful for analysis).

As mentioned, the on-board RAM should come first, so the iMMUnity RAM will start from 65536+

(and this includes the iMMUnity registers in GDB with -gdb-pseudo-regs)

[pser1]

Isn't $86C70 too big of a number?
That's over 512KB...

You are right, Robert
But testing with the iMMUnity module adds some 2Mb to the Dragon 64 ...
cheers!
pere

[pser1]

@sixxie
I will download and test the new snapshot of XRoar.
On GDB the flags are shown in hexa and then in decimal.
The only thing I would like to ask for a change ...
Keeping into account that each bit can only be 0 or 1, I would prefer to see them only in decimal format
and then the byte value of $cc would be very useful too. (We had it before!)
In case you could do anything of this, I would appreciate if the flags could appear from MSB to lSB (as in a binary number)
right now they appear in reverse order.
thanks a lot!
pere

[pser1]

Hello,
I have saved a snapshot OS9L2.ram and then I have compared the contents to the old one OS9L2.SNA
The first time data was using from $86C70 to $88270 (I just saved $1600 bytes for testing the screen)
This second time it is using from $86A00 to $88000 (same length)
Looking at the mappings on $FFA4 (slot 5 of MMU for task #0) I can see value $03 there
If the first 65536 bytes are the physical RAM, then the iMMUnity data begins at $10000
This means that the message data begins at offset $76A00 and this corresponds to page 3B that unfortunately
would be linked to slot 3 instead of slot 4.
And this page is never used in the MMU registers ...
pere

[sixxie]

On GDB the flags are shown in hexa and then in decimal.
The only thing I would like to ask for a change ...
Keeping into account that each bit can only be 0 or 1, I would prefer to see them only in decimal format

I can't see anything in GDB that seems to let you override that. Very odd choice. Might be able to patch it, but would need to make it only omit structs...

and then the byte value of $cc would be very useful too. (We had it before!)

There are two options for this. The current one declares cc as a "struct", and it lets you refer to individual values (e.g. "print $cc.Z", "set $cc.I=1"). The other one, which I'd used previously, declares it as a "flags" register, and will show those fields, but not let you refer to them by name. I can revert back to flags if it's more useful...

It would be nice if the target description let you suggest output formats to GDB - that would probably solve both these problems - but alas...

In case you could do anything of this, I would appreciate if the flags could appear from MSB to lSB (as in a binary number)
right now they appear in reverse order.

That I can certainly do; had wondered about it myself. It's only in this order because it follows the example of other GDB target definitions.

..ciaran

[pser1]

@sixxie
concerning the flags, if I had to choose between struct or integer I'd prefer the struct because that way I can see immediately
which flags are set.
In case you could change the format, I would suggest to just print the flags that are set (as previous versions)
cheers!
pere

[sixxie]

@sixxie
concerning the flags, if I had to choose between struct or integer I'd prefer the struct because that way I can see immediately
which flags are set.
In case you could change the format, I would suggest to just print the flags that are set (as previous versions)
cheers!
pere

Oh you can still _see_ them as flags - you just can't refer to elements of it in the GDB shell (or presumably if this sort of thing got punted to some python helper). Here's the difference...

AS FLAGS:

Code: Select all

(gdb) info registers cc
cc             0xa0                [ E=1 F=0 H=1 I=0 N=0 Z=0 V=0 C=0 ]
(gdb) print $cc.I
❌️ Attempt to extract a component of a value that is not a structure.
(gdb) set $cc.I=1
❌️ Attempt to extract a component of a value that is not a structure.

AS STRUCT:

Code: Select all

(gdb) info registers cc
cc             {E = 0x1, F = 0x0, H = 0x1, I = 0x0, N = 0x0, Z = 0x0, V = 0x0, C = 0x0} {E = 1, F = 0, H = 1, I = 0, N = 0, Z = 0, V = 0, C = 0}
(gdb) print $cc.I
$1 = 0
(gdb) set $cc.I=1
(gdb) print $cc.I
$2 = 1

Unfortunately it seems to be a choice between one or the other...

There are a couple of other options if I don't specify an integer type for each field:

Code: Select all

# as flags
cc             0xa0                [ E H ]

# as struct
cc             {E = 0x1, F = 0x0, H = 0x1, I = 0x0, N = 0x0, Z = 0x0, V = 0x0, C = 0x0} {E = true, F = false, H = true, I = false, N = false, Z = false, V = false, C = false}

[pser1]

Oh you can still _see_ them as flags - you just can't refer to elements of it in the GDB shell (or presumably if this sort of thing got punted to some python helper). Here's the difference...
There are a couple of other options if I don't specify an integer type for each field:

Code: Select all

# as flags
cc             0xa0                [ E H ]

Hello,
the one I have left from your last comment is the one I would prefer. The byte value is shown and only the flags that are set do appear
Could this be done adding a parameter? most probably it requires code change I am afraid
cheers!
pere