archive.worldofdragon.org

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.

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

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.

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

Edit: they're up.

Thanks!

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.

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!

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.

Thanks for taking the time to explain.

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

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

Regards,
Steve

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.

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