I looked to see what the problem is with the firmware of the Philips NMS-2220. Philips had the bad idea of using a ROM that autoboots with the H.STKE (0FEDAh) hook. Because of this, all cartridges that use this hook to be able to use disks cannot work. There may be a way to bypass firmware from a cartridge by inserting an address well placed into the stack but the best is to remove the ROM (Application ROM). Designer can by used in a cartridge.
There is another method usable on several cartridges. I proposed it to Konamiman for Nextor but which unfortunately did not adopt. It is to display a message "Press ESC to show the options menu..." for 2 seconds max under the title and we could press a single key only during this time. This would also work for the Music Module if there was free area in the ROM. The only drawback is that it lengthens the initialization time.
I did like the suggestion to move certain boot keys to a menu, since I think Nextor currently has too many boot keys to remember, especially the slot ones. A menu could reduce the amount of keys exposed, as well as serve as an easy way to look up (and expand) the available functions.
But I don’t like a lengthened boot sequence. Slow boot sequences are part of what makes me not want to use some of the non-MFR multi-cartridges. It should work without introducing a pause, I can always reset the computer if I missed the moment.
@gdx: you could create a fork of Nextor and implement your menu in the fork. Ask us to test it and request some feedback, if in general people like it they can choose between your version or the one from Konamiman. You can also create a pull request to Konamiman’s repository and he can decide to accept it. I’d be interested in such a functionality. Maybe a different key than ESC is a better idea (because ESC is so commonly used), SELECT could work I think…
The startup sequence does not become long if it is lengthened by one second only. In addition, we could make sure to stop this waiting time by pressing the space or Trigger key during this time. (This would not interfere with other cartridges which would also use Space if the slot scan resumes when you stop pressing Space.)
you could create a fork of Nextor and implement your menu in the fork.
I would not do it because it would have to be reproduced for each version. It's too much work.
you could create a fork of Nextor and implement your menu in the fork.
I would not do it because it would have to be reproduced for each version. It's too much work.
I don’t think that you have to redo it for every release. In got you can get the changes from upstream (basically Konamiman’s version) easily and those would merge without issue into your fork (unless some changes are made by Konamiman in the initial code to scan for pressed keys).
And of course it could just be used as a proof of concept which if response is good could lead to implementation in standard Nextor.
I would recommend not to add a timeout, but just don't wait. The wait is only useful if you don't know what to press. Once you do, it's only an annoying delay in the boot sequence. Having to press a key to skip it doesn't make it less annoying.
Waiting time allows you to know when to press the key and which one. So apart from the small lengthening of a second (which could be reduced by pressing Space for example) this method makes it more comfortable to use.
Otherwise, there is another method that is possible to call this menu, it is to create a Basic instruction (eg. CALL SETTING) and a DOS command, but this requires a restart for some functions and even a way to save some data. Which is not always possible.
Maybe using the two methods with shared functions would be best for Nextor. That is to say put the functions to change the boot behavior together and the others in the menu called by the Basic instruction.
I created a patch for the Philips NMS-2220 firmware (MSX designer). It will be downloadable here when it will be accepted. I used the second method for it (CALL DESIGNER).
Code source of this patch is:
PROCNM equ 0FD89h
org 4000h
RomHeader:
dw 4241h,0,4010h,0,0,0,0,0
InstTreatment:
push hl
ld hl,Inst
ChkInst:
ld de,PROCNM
ChkInstLoop:
ld a,(de)
cp (hl)
jr nz,InstDiffers ; Jump if caracter is not same
inc de
inc hl
or a
jr nz, ChkInstLoop ; Jump if instruction name is uncompleted
pop hl
jp 4042h
InstDiffers:
pop hl
scf ; Instruction not found
ret
Inst:
db "DESIGNER",0 
Personally I think I don't mind a longer booting sequence, but only when it comes with another message like: "We should all thank gdx for suggesting this delay." And probably add 5 more seconds to the delay so that everyone can read this message.
I'm sure people will thank* you.
EDIT: The really long MSX booting sequence has been so annoying while developing and testing games. I really don't understand why they can't just remove (or emulating that on very high speed) the booting sequences. MSX emulators is weird that way, emulators on most other 8 bit machines that I use (and I use a lot) have basically skipped the booting sequences.
In openMSX just pass a script with set throttle off, and then after 10 "set throttle on".
Unfortunately this isn't possible on a real MSX.
The really long MSX booting sequence has been so annoying while developing and testing games.
It's more convenient and faster to develop an MSX game on PC/Mac. and we don't have to test often on a real MSX. Only certain parts whose timings are important (eg. I/O accesses) and routines for certain devices should be tested on real MSX. MSX2s have the longest boot sequence. It lasts 8 seconds + the DOS (about 3 sec using flash card interface).
Philips had the bad idea of using a ROM that autoboots with the H.STKE (0FEDAh) hook. Because of this, all cartridges that use this hook to be able to use disks cannot work.
I'm wrong because ESC key is tested just before, but it's more convenient without auto-boot.