archive.worldofdragon.org

Yes, that's a good point. If the random number generator used by the game is interrupt based then it may well give different results running on T3; otherwise I'd guess there's a decent chance of it behaving the same way.

I was thinking similar thoughts! :lol: The original Dragon Convert for MS-DOS is unfortunately limited to a single segment for its file buffer (64 kb; or more accurately $FFF0 bytes since one paragraph is required by the C runtime). It does use huge pointers, so might actually work across multiple s...

You're welcome! Yes the load address is encapsulated within the header block. A standard format file will have only 1 header block. For example, you could create a simple autorun file like this - suppose you have a short machine language routine installed at $200-$27F (which could itself be a custom...

This is actually really easy to do. The most common method, as referenced in the DU response you mention, simply involves overwriting the launch vectors (or "ram hooks") between $15E-$1A8 in the system variable area of memory. These hooks are a table of 3 byte addresses to which the Dragon's built-i...

There isn't, sorry!

I haven't looked at your file, sorry, however Dragon Convert (DC.EXE) usually is more picky than a real Dragon; it uses a pretty simple technique to trace the waveforms in order to determine their wavelengths. It requires 8-bit samples (preferably mono) and can be susceptible to noise; the cleaner t...

You can do conversions between TXT/BAS and CAS using DC.EXE too!

Here is one pragmatic suggestion for creating CAS files with the correct byte leaders: 1. Start up xroar 2. Press CTRL+L and select a CAS file with or without the correct byte leaders 3. CLOADM 4. To find start address: PRINT PEEK(487)*256+PEEK(488) 5. To find end address: PRINT PEEK(126)*256+PEEK(...

That's neat, well done. I created something a little similar on the Dragon once, which scanned the text screen and then converted it to a BASIC program that uses the appropriate set of PRINT or PRINT@ statements (choosing literal strings, CHR$ and STRING$ as necessary) rather than the POKE approach....

sixxie wrote:T3 dynamically adapts its cpu rate, right?

Yes, it does; unless Alt-S is used to turn it 'OFF'.

Tab-D displays the current delay factor (whilst Tab with < or > shows the negative and positive rates of change).