*** M E M O R U M ***

The classic game of searching for mines.

Press 'A' to reveal the square, press 'S' button to flag as a mine.

Love the faux Win95 styling!

I can't get it to run on real hardware.

The file is too big and overwrites the disc system before it's finished loading.

The first Memotech virus ?

I couldn't get his first game to run either. I have not tried on a real MTX yet (which is why I had not commented before now), but the MTX file does not seem to have a proper header

It's got a valid RUN header 0x8000 0x7c00

However anything longer than 0x5700 starts over writing the CPM BDOS that's loaded in from 0xD700 to provide disc services.

I've sort of got it running, by reading in to lower memory, then using Panel to move it up to 0x8000.

There's screen corruption issues from pushing the VDP interfact too hard though. Pitty, as it looks good with those "wondows" colours and such.

Thanks for the feedback.

I didn't realise CPM was in the higher memory. I've changed it to limit the memory to 21K.

I only actually use 16K, I just padded it make my life easier.

I've also added some wait states around the VDP decompressor.

(It did run fine in MEMU)

It depends how you run MEMU.

If you use the -cpm switch then CP/M functionality is emulated and extra high memory is available.

If you load the CP/M boot ROM using -rom4 boot-type07.rom, and have a disk image, then the memory map in MEMU is the same as real hardware.

No trashing the CPM code area this time instead USER RUN is being pedantic about the file size, and erroring "no data" as the file is too short.

The header format for the RUN file is data block start, and data block size. So the file size needs to be (at least) 4 bytes longer than the data block size.

To make it work with a 20992 byte data block size, the file needs to be 20996 bytes. Or the block size in the header needs reducing to 20988 (0x51FC) to work with a 20992 byte file size.

With 4 random bytes added to the end of the file, I've sucessfully got it to load and run. Unfortunately it's still corrupting the display. You're not the only on caught out by code that works in emulation, but not on real hardware. Interesting things happen if you don't set the read & white bits correctly for address updates as I found out :http://primrosebank.net/computers/mtx/p ... om_dev.htm

Having re-read Andy's notes in the Hextrain sources, I suspect that the problem is the sequence

You could try inserting the 2 NOPS between the address setup and the data write . Although only a 3us address set up to data read delay is mentioned in manual, apparently there needs to be a delay between an address set up and a data write too.