Question #1: .MTX and/or .RUN to .WAV conversion

[kokkiklhs]

Well, as I said before, I'm a noob with the MTX, though I've managed to load on my recently acquired 512 and play a couple of games that I've found readily converted to .WAV at both nice sites that provide them...
BUT, some of the games I've found are either in .MTX format for use with MEMU, or in .RUN or even .COM (for use with CP/M, I assume)...

I tried to convert Jet Set Willy from .MTX to .WAV using the AppMake utility, but even though it started fine, it stubbornly refused to load with success. All I get is a garbled screen at the end. Am I doing something wrong, or it's just this specific game that can't be converted? Some other .MTX games that I tried to convert to .WAV with the same tool, loaded well...

And how about some good titles that I've found in .RUN format? Can these be converted to .WAV somehow? I understand that AppMake won't do this job, but is there some other utility/trick that I'm missing?

Well, you see, I am a "traditional" guy and I don't like messing with emulators, unless it's absolutely necessary... If I have the machine, I prefer playing/working with the real thing. I also prefer the good old "tape" (I mean sound) loading for such old machines, even if a have (or can have) a floppy disk drive or equivalent modern gadget...

[Martin A]

The RUN file format was something that came in with the extensions to basic that were added to use the disc systems. They're basically a binary image with a 4 byte header tacked on the front wtth the load address and file length. Since all the basic is stripped away they're smaller and load that bit faster.

I seem to remember that there was a tape to disc program that could create them. Mainly beacuse a lot of the early games, from Continental Software especially, used a very similar basic header that could be removed leaving just the binary.

Theoretically they could be converted to basic by crafting a suitable launcher in basic/assembler and dropping the RUN file in at the appropriate spot.

It can be done with any of the "disc" systems, however, if you have a disc system you don't NEED to do any conversion.

[Dave]

*WARNING* - advertising to follow

Of course, you could always add a CFX - it's a hardware add on, so you'd still be using the "real" MTX, but with a modern "disk" system giving access to all those .MTX, .RUN, .BAS files

And then of course, there's MAGROM

[kokkiklhs]

Thank you both, fellows!
Of course I have read so far about CFX and MAGROM and a disk replacement addon for the real thing is cool... I may get myself one of them at some point! But first my goal is to find out how can all these be converted to .WAVs...
I believe that anyone who has a stock machine without any extras SHOULD be able to run as much progs as possible, using only a sound source. And I'm not talking only about an MTX, but also for any other retro-machine which was meant to mainly load from tape back in the time...
I suppose, about the .RUN proggies that since they are (almost) pure binaries, all one has to do is find a way to load them in the correct address (here is where the emulator would be helpful), then save them somehow to "tape" as sound and make the appropriate BASIC loader to attach in the beginning of the code to follow. But this needs a lot more reading from my side, as I haven't realized yet how to properly use MEMU!

I've done it with other machines, though, like the Spectrum or the Amstrad, so it will be more or less a similar procedure...

[Martin A]

Loading and saving a block of code or data using the tape system involves a call to the routine at 0AAE in the system roms.

VERIFY is the system variable at FD67, set to 0 for load, 1 for verify
TYPE is the system variable at FD68. Set to 0 for save, set to 1 for load/verify.

For both load and save the HL register pair holds the start address and the DE pair the length.

The following snip from a real MTX game of the mid 80's shows how tape loading works from. The assembler it came from uses & to indicate hex numbers.

The author was obviously worried about someone running FDXB.COM on the FDX disc system looking at the code.

Step 1 sets a load address of 0000 and the size to 5 bytes. TYPE is set to 1 indicating a load. VERIFY was already zero from the LOAD command that started the program and so is not set here. The CALL is then made to 0AAE to load the code.(For normal BASIC that's in the rom and does nothing. On FDXB.COM where there is RAM at address 0000 that does nasty things to the reset/RST 0 code!)

The next step is the genuine code load for the game. TYPE and VERIFY don't need chnaging so only the address and size are updated Just over 25K is loaded in a single block to the base of the MTX500 ram at 8000.

Code: Select all

80A2 LD   HL,&0000
80A5 LD   DE,&0005
80A8 LD   A,&01
80AA LD   (TYPE),A
80AD CALL &0AAE
80B0 LD   HL,&8000
80B3 LD   DE,&6410
80B6 JP   &0AAE

Note: in this example the 2nd "call" to load/saveload uses a JP rather than a call, that's possibly down to more programmer paranoia. The start address for the program had already been set up on the stack and this code is intended to overwrite the loader with the incomming block of code from the tape.

[kokkiklhs]

Thanks for this detailed info, it might for sure be of interest to specialized Z80 coders and MTX geeks, but to me it doesn't mean much... Of course it can be useful to anyone who understands exactly what's written..

So, if I understand correctly, you can't just save a memory/code block on the MTX, like it happens e.g. on the Spectrum, using the form SAVE""CODE STARTADDRESS, SIZE and there's a more complicated procedure that needs to be followed, right?
Any out-of-the-box help, with, let's say, an example for an actual game, please?

[Martin A]

MTX basic had just LOAD and SAVE for entire programs, thats it. There's no support for saving blocks of data, arrays or the screen like there is on the Spectrum.

Reading and writing data blocks were added for the disc systemes using the USER system extension command. Reading and writing the screen wasn't part of the original disc support, though I did add it for CFX.

However, with the assembler being a build in part of basic, for games writers, that provided the means to loading data blocks by calling the ROM routine direct.

The "Basic" loader progarm, would use the build in assembler to put together a short snippet like the one shown and then load and run a code block. How simple or complicated the code was depended on how concerned the writer was about copying.

At it's simplest it would be something like

Code: Select all

4007 LD A,1
4008 LD (#FD68),A
400B LD HL,#8100    ; typical start address, #80FF was common too
400E LD DE, #2000   ; block lenght
4011 CALL #0AAE
4014 JP #8100

Copy protection was present from the start. Even the very first releases from Continental Software included in the box with the MTX had code to stop the code being listed. Though admittedly those early programs used the built in assembler, they didn't usually load extra blocks. Which is why they were the ideal candidates for conversion to RUN files in the forst place.

[kokkiklhs]

Oh, this nasty copy protection... Of course it was necessary back then and useful for the authors and the software houses, but nowadays it's one of the nightmares of the average retro-hobbyist...
Anyway, isn't there an option to get a complete memory dump (like a snapshot that we know from other computers) through the emulator?
This could be processed afterwards and then be re-loaded on a real machine... But I suppose that in our case this must be out of question, right?

[Martin A]

Andy's put VRAM snapshot and CPU snapshot diagnostic options in Memu. I don't think there's an all in one dump everything option or a reload VRAM from snapshot, though I'm willing to be corrected.

For those games with copies in MTX file format, then yes they can be "processed" on modern kit to "clean" them and then copy back to CF or SD cards using CPM callback filesystem (from Andy's site). That's where the snipped I posted before came from.

Back in the day the MTX's lack of a proper memory clear on reset made copying the smaller games pretty easy. Load the game, press reset, and have a look at the code in Panel. Done!

Anything in loaded in to memory from #4008 to #BFFF is there to be seen. IF you had the SDX then all you needed to do is add the 4 byte header and save to disc as a block. Instant RUN file.

[kokkiklhs]

Andy's put VRAM snapshot and CPU snapshot diagnostic options in Memu. I don't think there's an all in one dump everything option or a reload VRAM from snapshot, though I'm willing to be corrected.

For those games with copies in MTX file format, then yes they can be "processed" on modern kit to "clean" them and then copy back to CF or SD cards using CPM callback filesystem (from Andy's site). That's where the snipped I posted before came from.

Back in the day the MTX's lack of a proper memory clear on reset made copying the smaller games pretty easy. Load the game, press reset, and have a look at the code in Panel. Done!

Anything in loaded in to memory from #4008 to #BFFF is there to be seen. IF you had the SDX then all you needed to do is add the 4 byte header and save to disc as a block. Instant RUN file.

So we're in desperate need of some experienced Z80 coder who also knows well the memory map of the MTX, to create some windoze or DOS driven utility to add the missing parts, in order to be able to have .MTX or any-tape-loading-appropriate format of such things...