XRoar 0.28 available
XRoar 0.28 available
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.
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.
Re: XRoar 0.28 available
There seems to be a problem with the cassette loading. Sprint won't compile under XROAR 0.28.
Re: XRoar 0.28 available
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
Re: XRoar 0.28 available
Cheers, I've updated the source, will build some binaries later and push.
Edit: they're up.
Edit: they're up.
Re: XRoar 0.28 available
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.
These are the exact command line settings that I used for the test.
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
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
- Attachments
-
XROARTST.CAS
- XROAR TEST CODE
- (1.07 KiB) Downloaded 270 times
Re: XRoar 0.28 available
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!
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!
Re: XRoar 0.28 available
Thanks for taking the time to explain.sixxie wrote: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.
The smallest RAM configuration of my CoCo's (before upgrading to 64K) was 16K.sixxie wrote: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
Regards,
Steve
Re: XRoar 0.28 available
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
- Attachments
-
- RPT64-ON.zip
- (222 Bytes) Downloaded 271 times
Re: XRoar 0.28 available
At $BF20 ($FE18 in 64K mode) we have the following code.
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
Code: Select all
LDB $FF05
BPL AUTORPT
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