CoCoSDC and DragonMMC memory problems.

[robcfg]

Hello, fine people!

I was talking to Salva Cantero, who recently made the nice DragonTet Tetris clone, and found out that when we save the game to a disk image and run it on a CoCoSDC or DragonMMC, it misbehaves or plain crash on load.

On Xroar or by loading it as a tape file in a real machine, it works perfectly.

I've had this error with some programs of mine, and I think it's related to the memory map or how these cards map memory or we inadvertently load it over the cards own program.

DragonTet loads at $2800 and it's size is 13176 bytes.

Anyone knows what is the problem?

[pser1]

Hello Robert,
just by curiosity I have downloaded it and then run the game on XRoar.
It doesn't even start if you are emulating a HD6309, but works nicely on any MC6809

So we might suspect that machines with the 6309 could find some opcode that they detect as errors
cheers!

[robcfg]

Thanks Pere, I'll give that a try!

I've been sent videos of machines where the 2nd player misbehaves, but in my Dragon 64 with 6309 and the resistor pack it simply fails to load and the machine crashes.

[zephyr]

That copy of the game saved on your attached "DTET.VDK" file is corrupt. Try my (re)copy of the game saved to Disk (.VDK) and cassette (.CAS). It should work perfecly under Xroar (6809E CPU) Dragon or CoCo emulation.

It should also run ok with 6309E CPU emulation, as long as you are using one of Steve Woolham's Enhanced v3.1 or v3.2 Dragon ROMs.

The start, end, and exec addresses that I used for (re)saving the game to cassette (.CAS) were:

Start $2800
End $5B6E
EXEC $2800

The start, end, and exec addresses that I used for (re)saving the game to disk (.VDK) were:

Start $2800
End $5B6F
EXEC $2800

[robcfg]

I see what has been the problem.

Cmoc generates the binary file WITH the disk header already in, but my tool assumes the files have no header, thus the 'corruption'...

I'm going to do a couple of tests to confirm.

Thank you Zephyr!

[robcfg]

And by checking the CMOC compiler flags, there's one named --raw which generates the binary file for the selected platform with no header...

Now, there's still one issue and it's that when using a CoCoSDC or a DragonMMC, the second player pieces always drift to the right as if the L key was always pressed.

This does not happen with a regular disk drive/gotek or loading the game from tape.

[zephyr]

I don't have access to CoCoSDC or a DragonMMC, so I can't do any of the testing myself. But I will try to help you with this.

I have written a little machine code routine to try and protect the game code from any external interference. I have located my routine at $2797-$27FF, just before the start of the actual game code. The routine resets the hardware to default, disables the FIRQ, relocates the system stack to a safe place, and uses a dedicated IRQ service routine while the game is running. Everything is restored to normal when the game exits.

The compiler uses its own keyboard routine during gameplay. The only time it calls the ROM system keyboard routine is at the start of the game for the menu selection.

I have attached a both disk (.vdk} and cassette (.cas, .wav) files for you to test with CoCoSDC and DragonMMC. Please let me know if this solves the problem.

Regards,
Steve

[robcfg]

I've tried the disk file with both card and the problem persists.

Salvador is looking at the sensibility of his joystick routine.

Could you elaborate on that routine, I had some of my early Dragon assembly tests failing and would like to know if the cards were interfering with it.

Thanks for your kind help!

[zephyr]

Here is the source code. its in Encoder 09 format. I never use anything else.

Regards,
Steve

[robcfg]

Thanks a lot!