archive.worldofdragon.org

Does XRoar assume that an attached cartridge is read only? If so, is there any chance we can have that changed to allow writing to the cartridge images? A real Dragon (and seemingly POKEs from BASIC) will happily attempt a write instruction to 0xC000 if you tell it to.

Maybe this could be a command line switch, so that people don't accidently destroy their downloaded ROM images? Or if it didn't resave the ROM file (so acted as volatile RAM) then that would be ok too.

Maybe it's not something anyone other than me would use so I understand if you're not into the idea.

Cheers.

XROAR would need to emulate a device like Sarah Burgin's RAM upgrade cartridge. It could be selected using the "-cart-type" command line option.

e.g.

-cart-type RAM 8K, 16K, 32K, etc

Cool project there, thanks for linking. Never seen that before.

I recently ended up putting some ram in the cartridge slot and just thinking of some cool ways to use it. If Xroar supported it then I could write the necessary code on my er... lunch breaks...

Hello Ciaran,
I'm late, as usual ...
I have tried a bit you new 6309 emulation for Dragon.
These are my very first results:
1) The emulation reflects perfectly the real problem in native mode if you dare to use PLAY commands, for instance:
This efectively demonstrates that in emulation mode PLAY gives no problems but in native mode it does, due to the two extra registers added to the stack.

2) Surprisingly, if you just use this piece of code, after having started an emulation with disk enabled and loading the program from disk: When program ends you can work in Basic as usual but ... you will get no answer if you type DIR, it just hangs up! (I'm using XRoar v0.29v1)
If before typing DIR you first change the basic program so that it takes you back to emulation mode, the disk comes back to life without problems!!

By the way, lately I'm having problems everytime I start an XRoar session, despite I relay on default parameters or if I force it with "-disk-write-back " it just doesn't save any changes / saves I do to disk, so when I start XROAR again and load the disk image, I discover that I have lost all of my last savings!
I must press everytime I start XROAR the keys CTRL + SHIFT + 5 to ensure drive 1 will be backed up!

I am planning to test the patches to solve the play problems (by Steve / Zephyr) both in normal mode and in 64k mode
Hope to come back soon with more tests done.

Best regards
Pere

I may have found a bug when emulating a Dragon 32. I am getting inconsistent results when LLIST(ing) to a file, though usually the "Dragon 32" hangs and will not respond to anything but a "reset" (hard or soft). This behaviour does not occur when emulating a Dragon 64.

At the very least this bug applies to xroar-snap-20130129-w32 and xroar-snap-20130107-w32.

Strange, the Dragon 64 ROM sensibly waits for any key to be released before printing (the lines are shared), but the Dragon 32 ROM doesn't seem to. Will have to investigate further.

Just tried xroar-0.29.2-w32.zip, and single-bit sound is still not working.

I've got around to testing the 0.29.2 package in Wine, and sound in Fahrfall (alpha-3) is working for me. Which only proves it works in Wine, of course! Sound is otherwise ok for you?

sixxie wrote:I've got around to testing the 0.29.2 package in Wine, and sound in Fahrfall (alpha-3) is working for me. Which only proves it works in Wine, of course! Sound is otherwise ok for you?

Yes, the six-bit sound works fine. I used the Tandy Diagnostics v2.1 cartridge from the Uploads section to test single-bit sound under Xroar 0.29.2 CoCo and Dragon emulation.

I made my own diagnostic cartridge from the ROM image and tested it on my own CoCo 1/2 and Dragon 32/64 machines, so I know for sure that the single-bit test works perfectly with real CoCo and Dragon hardware. The single-bit sound test also works OK under Xroar 0.24 CoCo and Dragon emulation.

Ah! For some reason I thought Fahrfall used single-bit sound... Ok, more problems!