Dragon Booty

Got a software project you're working on? Share the details with us here.
Please only post 1 topic per project and keep the replies and threads pertaining to the project within the same post.
Forum rules
Software Project Forum Group:
Please 1 one topic per project.
Keep all comments and replies and threads within the same topic, and try to avoid creating new ones.

Dragon Booty

Postby sixxie » Tue Oct 17, 2017 9:43 am


As more than one person has requested it, here's a boot block that:

  • Detects Dragon, Coco1/2 or Coco3
  • Uses tokenised BASIC to load and exec appropriate binary

Example tokenised strings for running BASIC programs instead included in the source.

Includes a hybrid disk image with space allocated both to DragonDOS and RSDOS, and a Makefile that builds the bootblock and copies it into the appropriate place for each system.

Remember RSDOS binaries are not the same format as DragonDOS binaries, so you'll need to generate separate versions. asm6809 can generate either!
Posts: 9
Joined: Tue Oct 17, 2017 9:19 am

Re: Dragon Booty

Postby ogsteviestrow » Tue Oct 17, 2017 1:44 pm

Awesome stuff! Many thanks for all you do.
Steve Strowbridge aka The Original Gamer Stevie Strow
Host of CoCoTALK! the nation's leading live talk show featuring the Tandy Color Computer


User avatar
Site Admin
Posts: 55
Joined: Mon Sep 18, 2017 11:31 pm
Location: Port Saint Lucie, FL

Re: Dragon Booty

Postby MarkO » Tue Oct 17, 2017 6:36 pm

Sixxie, You Rock!!!!

Is there any way to "patch" the CoCo Binaries or Dragon Binaries to run on the "other system"??

Please Post any other "tricks" you might have..

Posts: 10
Joined: Mon Sep 18, 2017 11:37 pm

Re: Dragon Booty

Postby sixxie » Wed Oct 18, 2017 4:56 pm

MarkO wrote:Is there any way to "patch" the CoCo Binaries or Dragon Binaries to run on the "other system"??

Wall of text warning... Awooga.

Oh definitely. It's really unlikely that what's written for one (of CoCo1/2 or Dragon) couldn't be made to run on the other. For simple ports, there are really only two considerations: ROM call entry points and the keyboard matrix layout, both of which differ (and for Dragon -> CoCo ports, you might have to exclude Color BASIC-only machines).

One thing in our favour is that the indirect ROM entry table at $A000+ is the same on both platforms, so if that is used to read keyboard or joysticks, you're stylin' (as I'm led to believe they say). Many CoCo cartridge games were written "properly" and only use these indirect calls, and as such work unmodified on the Dragon. If only I could claim the reverse were true...

The closest I've ever come to failing is with Dunjunz, where the different keyboard layout might have scuppered it for the CoCo - four players with their controls somehow not conflicting, and different rows of keys "locked out" by the joystick firebuttons. In the end, if you're on a CoCo, the keyboard controls are slightly odd, but usable.

Here are a few Dragon -> CoCo ports: http://www.6809.org.uk/tmp/da/coco_ports/

Techniques for finding where to patch vary if you don't have the source. Some of those I did in the early 90s and involved writing small BASIC programs to search for BD [8-f]x xx and similar (calls into ROM). More recently it's possible to run in an emulator and visually identify such calls (grep for entering ROM area in trace mode of XRoar). Reads/writes to $ff00 / $ff02 will need studying to see if some sort of translation is required there.

I still find this site really useful: http://dragon32.info/info/ - cross reference with the Unravelled series to find the CoCo equivalents of ROM calls, and you're most of the way. It even contains both keyboard matrix layouts interleaved.

If you want to make previously artefacted colours look ok on a PAL machine using PMODE 3 (accepting that a simple conversion is all you can achieve there), that's another can of worms... Contrariwise, a Dragon game in white on black would look a bit odd on an NTSC machine (RF / composite), so you might want to switch its video mode to green on black.

I've previously made use of XRoar's "-snap-motoroff" option which dumps a machine snapshot to a named file whenever the cassette motor transitions to "off" - i.e., when a game has finished loading, but probably before it's executed any of the game's code. Then extract the game binary from that dump (in current snapshot format machine RAM is offset into snapshot file by 37 bytes IIRC, so it's pretty easy to find the bit you want).

For actually doing the patching? Well, just break out your favourite hex editor :) I quite like "hexer" when it doesn't crash for its vi-like controls.

Edit: and already there's a post in the "wrong" section...
Posts: 9
Joined: Tue Oct 17, 2017 9:19 am

Return to Software Projects

Who is online

Users browsing this forum: No registered users and 1 guest