Is there any way to use a disk-drive without the buffer eating most of the upper memory? The disc buffer forced some games to boot with the control key to eliminate the second logical driver, but even MSX-DOS2 with more FREE memory would not run some cassette games ...

If someone use a software to convert from BASIC listing to ROM would loading from MSX-DOS works just fine for 27KB games?
A ROM loader could be the easier way to port those games to disk!

26-27K is asking a bit much but 25500 is quite easy to obtain from within BASIC with just one disk drive plugged in.

An article concerning this was published, many many moons ago, in the Brazilian CPU-MSX magazine #20 - in Portuguese unfortunately.
It was called, appropriately enough, "<CONTROL> nunca mais!" (<CONTROL> never again).

Basically this article showed how to obtain up to 25500 bytes from within Basic without the need to restart the machine, thus eliminating the tiresome habit of having to reset and hold down the CONTROL key.

That is, the BASIC code shown could be placed at the beginning of an AUTOEXEC.BAS such that before loading a game that required it the extra memory could be freed up - up to an extra 2070 precious bytes.

The whole thing was done using a few (around 25!) POKE commands followed by a CLEAR 200,HI : CLEAR and worked perfectly.

The byte accounting shown was the following:

28815 : no disk drive
23430 : 2 disk drives (A: and B
24988 : 1 disk drive (A
25500 : 1 disk drive NOT 3.5"

The reasoning behind these numbers was:

1558 bytes (24988-23430) saved by eliminating the buffer and control blocks for the 2nd drive - and, of course reallocating the buffer and blocks for the first drive further "up" memory.

512 bytes more (25500-24988) could be saved in the case of a 5.25" drive - which was by far the most common in Brazil at that time. This is due to the fact that the FAT12 table is smaller on a 5.25" disk - exactly one sector smaller to be exact - thus a further 512 bytes could be saved.

Of course with virtual drives running under an emulator it shouldn't be any sweat to create 360Kb "disks".

As I said the beauty of the the solution was that it could be (and was, by me) implemented at the start of an AUTOEXEC.BAS. After all the necessary code was 100% BASIC!

It completely eliminated the idiotic solution of having to reset the machine in order to run some games.

Of course the REAL ones to blame are the original disk interface designers who COULD have assumed just ONE drive as a default with TWO drives being an option for those who wished it by the simple expedient of holding down the CONTRL key on initialization.

I did actually implement this in my MICROSOL (ports, not memory) disk interface cartridge by changing the initialization code in the ROM to do exactly that: change the code (2 jump instructions); sunbathe the EPROM, then burn it again.

If you're interested I'll look out the BASIC code from the article in question and post it. The original code published in the magazine had a line left out by the publisher so even if you could locate a copy of the article you'd be missing an all-important line of code. Did they do that on purpose, I wonder?

I'll look for the code as soon as I finish figuring out how to iniitalize this damn database for the blueMSX Launcher front end - don't hold your breath, cos it's beyond me at the moment - just way too complicated for my simple mind - methinks that suicide WILL BE a viable option if I still can't figure it out after a few more hours :-(

--
blue lantern
--
up in the mountains about 250km west of Rio de Janeiro

i think it's because of the japanese era of the early personal computers.
x68000, pc98, fm-77av, and others have 2 fdd default on their machines.
and most games use the fdds to run the games at the same time.
i think around 1987 or 1988, they already knew they would have trouble in this uncommon
design. the first to go to cd was the fm-towns. but it's not the best solution either
beacuse not much games used it....

format wars and headaches...