I've done some more work on SaveROM. The list of changes:

• full MSX-DOS2 support, which allows saving to FAT16 drives, and use sub-directories
• fixed a bug causing dumping megarom 00-FF range to get in an infinite loop
• megaROM question has become a type select
• added memory overview of pages containing something
• added display for megarom block number as a progress indicator

Thanks go to Patriek Lesparre for improvement ideas.

Introduction

Usually flash cartridges allow reading data only from Z80 pages 1 and 2 (address range $4000-$BFFF). With the LPE-FlashG it's also possible to run software that was written to run from Z80 page 0 (address range $0000-$3FFF). Because of this feature it's also possible to run 48 kB unmapped ROM software, like "Universe: Unknown" and "The Cure". In case of the LPE-FlashG a little bit of mapping is required. Why and how is described in this article...

The LPE-FlashG mapper

The mapper is ASCII8 and ASCII16 compatible, selectable with a jumper. General information about MegaROM mappers is described on:

http://bifi.msxnet.org/msxnet/tech/megaroms.html

The following table shows the Z80 paging and LPE-FlashG specifics on how the first 4 blocks are initialised:

Z80 Page	0		1		2
Mapper	$0000-$1FFF	$2000-$3FFF	$4000-$5FFF	$6000-$7FFF	$8000-$9FFF	$A000-$BFFF
ASCII8	---- (0)	---- (0)	$6000 (0)	$6800 (1)	$7000 (2)	$7800 (3)
ASCII16	---- (0)		$6000 (0)		$7000 (2)

The values between parenthesis are the initial block values. The hexadecimal values (indicated by the $-prefix) preceding them are the common switch addresses, if applicable.

Adapting the 48 kB unmapped ROM

To get 48 kB unmapped ROM software running from the LPE-FlashG we need to have the following configuration:

Z80 Page	0		1		2
Mapper	$0000-$1FFF	$2000-$3FFF	$4000-$5FFF	$6000-$7FFF	$8000-$9FFF	$A000-$BFFF
ASCII16	---- (0)		$6000 (1)		$7000 (2)

As shown in the table, this 48 kB unmapped feature is only possible in ASCII16 mode. The value for page 1 should be 1 in stead of the initialised 0. To correct this, a little piece of additional code is required. The following source code (tniASM ready) shows how it's to be done:

		org	0
		phase	$4000
		dw	"AB",lpeInit,0,0
rst8:		ds	3
lpeInit:	ld	a,1
		ld	($6000),a
		dephase

; over here, the rest of your code and data for page 0 is
; located

		org	$4000
		dw	"AB",init,0,0,0,0,0,0
init:

; over here, the rest of your code and data for pages 1 and
; 2 is located

Here's how it works. When the ROM is started under normal conditions, the system will look for the cartridge header on address $4000. The address on init is found and it'll jump to that address, causing it to start normally.

When the ROM is started from the LPE-FlashG block 0 is located in both pages 0 and 1. Block 2 is already correctly mapped in page 2. In this case the cartridge header is found and the address on lpeInit is found and executed. This special piece of code is fitted exactly before the init in block 1, where the real page 1 init code is located. The code at lpeInit switches page 1 to block 1, to restore the full 48 kB ROM. After that the address of init is reached AND the correct block is selected in page 1. This means the blocks are set up correctly with the first 48 kB ROM in unmapped style and the game will start as if it was started under normal conditions.

The 3 bytes at rst8 can be used for an optional RST $8 entry.

Final words

I hope this article will be useful when creating new 48 kB unmapped ROMs for MSX to run them from LPE-FlashG without the requirement to make changes later on.

Of course it's also possible to patch existing 48 kB unmapped ROMs, like "Universe: Unknown" and "The Cure" mentioned in the introduction, to run from LPE-FlashG. For these two titles, IPS patches are already available here and may be useful in creating your own patches for other 48 kB unmapped ROMs.

I've just updated the Montana John and the Templar's Treasure Password Addition patch to the just released v1.1 of the game. An additional feature to the patch is that the position of the pointer doesn't change anymore.

Again, the IPS patch is available in the MSX IPS Patch Archive.

After almost a year of delay due to MRC, ROMLOAD v1.99u was released. Among the changes are of course the bugfixes I've released a cumulative IPS patch for v1.99t for. Here's the list:

• Fixed support to run 16 kB mapped games in the SD-Snatcher Sound Cartridge
• Added support to run the MSX-DOS 2 Kernel in a Sound Cartridge
• Added reformatted usage output to make everything fit a WIDTH 80 screen
• .ROM is now the default extension
• Fixed subslot number display when detected in an expanded slot
• Fixed bug causing non-existing Sound-Cartridges to be detected
• Added support to use ESE-SCC up to 512 kB of RAM in stead of a Sound Cartridge
• Updated /P to enable patching up to 64 blocks within the limits of the ROM image

At my request (almost a year ago) and some persuation MRC has finally removed ROMLOAD and IPS4MSX from their download database. The reason I wanted them offline were the following:

1. The fine print of their policies became quite clear in a forum post posted on 30 June 2007:
   "...there's a reason they were drawn up the way they were: we get to do whatever the h00t we feel like. Basically the policies were written with a few things in mind.
   
   1) If you behave like a wanker we get to ban your ass.
   2) If we ban your ass because you're a wanker you don't get to delete your forum posts.
   3) If you dislike us because we're a bunch of wankers you don't get to delete your forum posts.
   4) If we ban your ass because you're a wanker you don't get to remove anything you submitted from the freeware downloads db.
   5) If you dislike us because we're a bunch of wankers you don't get to remove anything you submitted from the freeware downloads db.
   
   Well, basically, once you submit something to MRC it stays on MRC, even if you very much dislike us."
2. I never agreed on automatic updates for the new releases in the download database, and yet every time I released a new version of either of the programs it got updated there.

There was a referer block on the download files for a while, and MRC thought that was the actual reason and they interpreted it as such. If it was the actual reason I would've requested them removed before 30 June 2007.

During the e-mail correspondence, references were made to totally unrelated topics and me not replying on those particular parts seemed to be the main reason for the particularly persistent stalemate.