XRoar 0.28 available

[sixxie]

Having hammered out the last few obvious bugs (thanks, everyone), it's time to actually do a release. Same place as usual:

http://www.6809.org.uk/dragon/xroar.shtml

There's still lots to do, so this release is mostly just pulling all the little odds and sods into shape. There's no real difference between this and the last snapshot release from the other day, so no need to rush and download if you already tried that.

[zephyr]

There seems to be a problem with the cassette loading. Sprint won't compile under XROAR 0.28.

[zephyr]

The "-ram SIZE" command line option doesn't seem to be working. I have always emulated a 64K upgraded Dragon 32 with the following command line, but it doesn't work since the release of v0.28.

Code: Select all

xroar -vo sdl -machine dragon32 -extbas d32.rom -nodos -ram 64 -kbd-translate

[sixxie]

Cheers, I've updated the source, will build some binaries later and push.

Edit: they're up.

[zephyr]

Thanks!

[zephyr]

The test below fails under XROAR 0.28.1 CoCo emulation with "-ram 4" and "-ram 16" settings. It works perfectly under XROAR 0.24.

Code: Select all

10          ORG      $0C00
20          ORCC     #$50
30          LDU      #$7FFF
40 RAMTOP   LDA      ,U
50          COM      ,U
60          CMPA     ,U+
70          PSHU     A
80          BEQ      BASIC
90          LDX      #TEXT-1
100          BSR      SHOW
110 BASIC    RTS
120 SHOW     LDA      $FFFF
130          CMPA     #$B4
140          LBEQ     $90E5
150          LBRA     $B99C
160 TEXT     FCC      "32K RAM"
170          FCB      0

These are the exact command line settings that I used for the test.

Code: Select all

xroar -vo sdl -machine cocous -bas bas10.rom -noextbas -nodos -ram 4 -kbd-translate

Code: Select all

xroar -vo sdl -machine cocous -bas bas11.rom -noextbas -nodos -ram 16 -kbd-translate

[sixxie]

That looks right actually - I'm going to say 0.24 had the bug here (well, unimplemented feature at that point).

U doesn't point to valid RAM, so whatever was on the data bus last is used (we've talked about this effect recently with the Manic Miner protection). For indexed addresses, that's usually the next instruction - so LDA ,U gets $63 (opcode for COM indexed), COM ,U inverts $A1 and stores it nowhere, then CMPA ,U+ compares A with $36 - so it thinks it changed, but in reality it just got two different results for an invalid address.

It's possible I've got how RAM is organised in 4K and 16K CoCos wrong though - I don't have one of either to test it. If you have one, what does PRINT PEEK(4096) - 4K - or PRINT PEEK(16384) - 16K - yield? Should be 126 (in the PEEK command, the next instruction following the load is a JMP) if I've got it right.

And for 4K machines, $0000-$0fff should be shadowed from $2000-$2fff, $4000-$4fff and $6000-$6fff, so POKE 9216,0, POKE 17408,0 and POKE 25600,0 should all have the same effect - that of POKE 1024,0, ie inverse @ in top left corner.

Edit: it's possible the buffer between RAM readout and the data bus changes the access characteristics - I've only seen this "data bus persistence" discussed in relation to ROM & IO areas, not RAM... would need to see how real hardware reacts to that buffer being enabled without any RAM being selected. If you do have a real 4K CoCo, adjusting your program to simply read from a "dead" area then store the value somewhere useful could be revealing!

[zephyr]

That looks right actually - I'm going to say 0.24 had the bug here (well, unimplemented feature at that point).

U doesn't point to valid RAM, so whatever was on the data bus last is used (we've talked about this effect recently with the Manic Miner protection). For indexed addresses, that's usually the next instruction - so LDA ,U gets $63 (opcode for COM indexed), COM ,U inverts $A1 and stores it nowhere, then CMPA ,U+ compares A with $36 - so it thinks it changed, but in reality it just got two different results for an invalid address.

It's possible I've got how RAM is organised in 4K and 16K CoCos wrong though - I don't have one of either to test it. If you have one, what does PRINT PEEK(4096) - 4K - or PRINT PEEK(16384) - 16K - yield? Should be 126 (in the PEEK command, the next instruction following the load is a JMP) if I've got it right.

And for 4K machines, $0000-$0fff should be shadowed from $2000-$2fff, $4000-$4fff and $6000-$6fff, so POKE 9216,0, POKE 17408,0 and POKE 25600,0 should all have the same effect - that of POKE 1024,0, ie inverse @ in top left corner.

Thanks for taking the time to explain.

Edit: it's possible the buffer between RAM readout and the data bus changes the access characteristics - I've only seen this "data bus persistence" discussed in relation to ROM & IO areas, not RAM... would need to see how real hardware reacts to that buffer being enabled without any RAM being selected. If you do have a real 4K CoCo, adjusting your program to simply read from a "dead" area then store the value somewhere useful could be revealing

The smallest RAM configuration of my CoCo's (before upgrading to 64K) was 16K.

Regards,
Steve

[zephyr]

Attempting to enable the Dragon 64's keyboard auto-repeat in 32K Mode under XROAR 0.28.1 with the following code causes the emulated machine to lock-up. Same thing happens with the latest snapshot.

Code: Select all

10 POKE&HFF03,PEEK(&HFF03)AND&HFE
20 POKE&H10D,&HBF:POKE&H10E,&H20
30 POKE&HFF03,PEEK(&HFF03)OR1

[zephyr]

At $BF20 ($FE18 in 64K mode) we have the following code.

Code: Select all

LDB    $FF05
BPL    AUTORPT

Checking the B register at this point returned the following results:

B reg under XROAR 0.28.1
32K mode = $B4
64K mode = $00

B reg under XROAR 0.24
32K mode = $7E
64K mode = $7E

B reg on Real Dragon 64
32K mode = $10
64K mode = $10



Peeking $FF05 from BASIC returned the following results:

PRINT PEEK(&HFF05) under XROAR 0.28.1
32K mode = $7E
64K mode = $7E

PRINT PEEK(&HFF05) under XROAR 0.24
32K mode = $7E
64K mode = $7E

PRINT PEEK(&HFF05) on Real Dragon 64
32K mode = $10
64K mode = $10