Nextor 2.0.1 and 2.1 Alpha 1 released

Nextor 2.0.1 and 2.1 Alpha 1 released

by konamiman on 04-04-2014, 09:41
Topic: Software
Tags: Nextor
Languages:

Brace yourselves, all Nextor lovers around there: Konamiman has released not one but two new versions of the MSX-DOS based disk operating system for MSX computers.

Nextor 2.0.1 corrects a bug in the kernel booting sequence that rendered it unusable in the openMSX emulator and could potentially cause problems in real computers as well. The kernel ROM files, the MKNEXROM tool and the driver development guide have been updated.

Nextor 2.1 Alpha 1 is the first preview of the next major version of the OS. It features the ability to mount disk image files in drive letters, so that their contents can be accessed seamlessly as if the file was a normal storage device. As usual - alpha software is, well, alpha software; so make a backup of all your data before giving it a try.

Another new item available is the source code of the Sunrise IDE driver for Nextor. This driver is known to be quite buggy, so if you are a developer you can now take a look at it and perhaps suggest some improvements.

Last but not least, there is a new "Donations" section in Konamiman's page. All the software and resources in the site are still -and will continue being- available for free, but if you feel like giving some economic support to the author you can now do so via PayPal and Skrill.

Relevant link: Konamiman's MSX page

UPDATE: Version 2.0.2 has been released, which fixes the bug discovered by saccopharynx.

Comments (56)

By konamiman

Paragon (1117)

konamiman's picture

04-04-2014, 10:13

Remember that there is a Nextor work-in-progress forum topic in case you want to discuss about Nextorities.

By snout

Ascended (15184)

snout's picture

04-04-2014, 12:57

Mounting DSK images on MSX. Euhm... that's quite awesome!

By Creepy

Champion (332)

Creepy's picture

04-04-2014, 13:02

O wow, mounting disk images! Smile

By Latok

msx guru (3821)

Latok's picture

04-04-2014, 13:08

Oh goody goody!!

By Grauw

Ascended (9748)

Grauw's picture

04-04-2014, 14:03

Mounting diskimages: A w e s o m e.

Many props to Konamiman!

By edoz

Prophet (2314)

edoz's picture

04-04-2014, 15:15

Running Naked in a Field of Flowers Running Naked in a Field of Flowers Running Naked in a Field of Flowers Running Naked in a Field of Flowers Running Naked in a Field of Flowers

By Prodatron

Paragon (1789)

Prodatron's picture

04-04-2014, 19:45

Cool stuff!

By saccopharynx

Master (151)

saccopharynx's picture

05-04-2014, 01:48

Your time and effort are much appreciated, thanks. I'll try it on openMSX ASAP.

By Latok

msx guru (3821)

Latok's picture

05-04-2014, 13:06

This morning I updated to nextor 2.1 alpha 1 and its mega!!

By saccopharynx

Master (151)

saccopharynx's picture

05-04-2014, 15:06

Hi,

I haven't yet tried it on openMSX, but I'd like to report an issue I'm having on BlueMSX when using Nextor v2.0.1. Basically, I just follow the steps in the Getting Started Guide and I cannot boot in MSX-DOS 1. The screens hangs all blue and nothing else happens.

I didn't have this issue with Nextor v2.0 Beta 2. At that time, the disk with tools + Nextor didn't include MSX-DOS 1, so what I copied to the third partition was an MSX-DOS 1 of my own. So, I supposed that maybe the issue now is due to the MSX-DOS 1 included in the new NEXTOR-DSK.ZIP. However, I tried to use my own MSX-DOS 1 with the new Nextor v2.0.1 but without success, I cannot either boot in MSX-DOS 1. For confirmation, I repeated all the steps again using Nextor v2.0 Beta 2. In that case, I can boot in MSX-DOS 1, so this should be an issue of the new version.

Are you experiencing the same problem?

Finally, I would like to report some errata in Section 3 and Section 4 of the guide:

Section 3:
* Step a: "...you boot in the COMMAND2 prompt in drive C:". The new version seems to boot in drive B:
* Step m: The COPY commands should be COPY"B:..."

Section 4:
* Step a: "Assign partition 2 to drive B:...". It should be "...drive D:..."

Cheers,
S

By sd_snatcher

Prophet (3443)

sd_snatcher's picture

05-04-2014, 17:50

Thanks for another version of Nextor, konamiman! Big smile

By konamiman

Paragon (1117)

konamiman's picture

05-04-2014, 22:39

Hi @saccopharynx, thank you very much for your bug report. Unfortunately I am not being able to reproduce te bug, I am perfectly able to boot in MSX-DOS 1 mode, and I am also testing with blueMSX. Could you tell me the exact machine configuration you are using?

By saccopharynx

Master (151)

saccopharynx's picture

06-04-2014, 01:07

Hi,

I don't know if it will help much as I'm just using the regular MSX2 modified as you described. Please see the configuration:

[CMOS]
Enable CMOS=1
Battery Backed=1
[FDC]
Count=2
[CPU]
Z80 Frequency=3579545Hz
[Board]
type=MSX-S3527
[Video]
version=V9938
vram size=128kB
[Subslotted Slots]
slot 0=0
slot 1=0
slot 2=1
slot 3=1
[External Slots]
slot A=1 0
slot B=2 0
[Slots]
0 0 0 0 80 "" ""
0 0 0 0 79 "Machines/Shared Roms/MOONSOUND.rom" ""
0 0 0 0 84 "" ""
0 0 0 4 66 "Machines/Shared Roms/MSX2.rom" ""
1 0 0 8 96 "Machines\Shared Roms\Nextor-2.0.1.SunriseIDE.rom" ""
2 2 2 2 43 "" ""
3 0 0 2 78 "Machines\Shared Roms\MSX2PMUS.rom" ""
3 1 0 2 20 "Machines/Shared Roms/MSX2EXT.rom" ""
3 1 2 4 65 "Machines/Shared Roms/PHILIPSDISK.rom" ""
3 2 0 64 22 "" ""
3 3 2 2 42 "Machines/Shared Roms/XBASIC2.rom" ""

I will do it one more time today, but I repeated the process 3 or 4 times yesterday without success.

Thanks,
S

By saccopharynx

Master (151)

saccopharynx's picture

06-04-2014, 09:41

Hi,

Additionally, I have recently tried the following configurations (In BlueMSX) without success either (when booting in MSX-DOS 1):

MSX2+ (nextorv2.00 + Nextor-2.0.1.SunriseIDE.rom)
MSX2 (Nextor-2.1-alpha1 + Nextor-2.1-alpha1.SunriseIDE.ROM)

I have also tried to follow the instructions in Sections 3, 4 and 5 using openMSX, but as soon as the system boots (before even starting with the steps in Section 3), I get the following message error: "Disk driver not found. System halted."

I'm not sure if I'm doing the right procedure on openMSX, but I suppose that it should be:

  • Disk A contains the NEXTOR-DSK
  • the driver (Nextor-2.0.1.SunriseIDE.rom) is in slot 1
  • I'm using the IDE extension properly (set power off, hda hd.dsk, set power on)

When using openMSX, I tried this on a Panasonic FS-A1GT, Panasonic FS-A1WX and National FS-5000. Am I missing something else?

Thanks,
S

By Manuel

Ascended (17753)

Manuel's picture

06-04-2014, 12:03

For openMSX, copy ide.xml to nextor.xml and in it, replace the ide rom sha1sum with the one of the new nextor rom. And put that rom with your other system roms.

By saccopharynx

Master (151)

saccopharynx's picture

06-04-2014, 15:30

Thanks Manuel, at least it is now working the same as BlueMSX, which means that I can create the partitions but cannot still boot in MSX-DOS 1, but that is not an issue of openMSX. By the time, is there any way to deactivate the SHA1 calculation each time that the HD image is written? That is adding a lot of delay.

Konamiman, as you have read, the same issue unfortunately occurs with openMSX too. Since I get the message "HALT detected, which means a hang" when I try to boot in MSX-DOS 1, I would say that this is an issue related to this new version. Can you please confirm that you tried the last version of Nextor? It is extremely rare that I see the same issue with both emulators...And as I said, MSX-DOS 1 can be booted if I use instead Nextor-2.0-beta2.SunriseIDE.rom.

Cheers,
S

By konamiman

Paragon (1117)

konamiman's picture

06-04-2014, 16:46

After extensive testing I have finally been able to reproduce the problem. It seems to be in the sector 0 boot code that is executed when booting in DOS 1 mode: for some reason, MSXDOS.SYS is not being read.

The funny thing is that when booting from a diskette, it works. Try it: remove all hard disks from the blueMSX "File" menu, leave the Nextor tools DSK in the first floppy drive, and press 1 while botting. It will boot in the COMMAND.COM prompt as expected.

Well, here I have some debugging to do...

By Manuel

Ascended (17753)

Manuel's picture

06-04-2014, 17:25

Quote:

is there any way to deactivate the SHA1 calculation each time that the HD image is written? That is adding a lot of delay.

Try the latest openMSX build, improvements have been made on that. See http://openmsx.fixato.net/ for latest builds. They should be very stable.

By edoz

Prophet (2314)

edoz's picture

06-04-2014, 17:59

I loaded the Alpha version to my Megaflash. I replaced the nextor rom and the nextor.sys file.

If I type VER on the prompt I got :

Nextor kernel version 2.1 alpha 1
Nextor.sys version 2.10

Is this ok ?

By edoz

Prophet (2314)

edoz's picture

06-04-2014, 19:05

what I mean .. I used the nextor.sys from the zip file (alpha version) but I see version 2.10.
It seems that mapdrv.com is not working but call mapdrv in basic is.
What is the different ?

By edoz

Prophet (2314)

edoz's picture

06-04-2014, 19:12

And I can only use the G drive as a mapped drive ?

By konamiman

Paragon (1117)

konamiman's picture

06-04-2014, 22:16

That's correct, NEXTOR.SYS in the zip file has version 2.10, it has no "alpha" label. Sorry if that's confusing.

By Grauw

Ascended (9748)

Grauw's picture

07-04-2014, 01:50

By the way konamiman, calculating the free space takes a long while on FAT16, and to improve performance there is a hack to stop this calculation at 32 MB, right?

However, on my One Chip MSX the built-in SD-card interface reports free space very quickly! When I insert the MegaFlashROM SCC+ SD with Nextor and go to the SD-card drive however, I get a long waiting time. Could it be that they have a faster method to detect free space on FAT16? Maybe you can use it.

By saccopharynx

Master (151)

saccopharynx's picture

07-04-2014, 02:12

Quote:

Try the latest openMSX build, improvements have been made on that. See http://openmsx.fixato.net/ for latest builds. They should be very stable.

Many thanks.

By saccopharynx

Master (151)

saccopharynx's picture

07-04-2014, 02:13

Quote:

Well, here I have some debugging to do...

Thank you for confirming the issue.

By konamiman

Paragon (1117)

konamiman's picture

07-04-2014, 09:14

edoz wrote:

what I mean .. I used the nextor.sys from the zip file (alpha version) but I see version 2.10.
It seems that mapdrv.com is not working but call mapdrv in basic is.
What is the different ?

The version scheme for the Nextor kernel is major.minor.revision. However the scheme for NEXTOR.SYS is the same that was used by MSXDOS2.SYS: major.minor revision, noticie the missing dot. Hence NEXTOR.SYS 2.10 is actually 2.1.0.

MAPDRV.COM and CALL MAPDRV are completely equivalent. Do you say that one is working for you but the other is not? How are you using them?

Grauw wrote:

However, on my One Chip MSX the built-in SD-card interface reports free space very quickly! When I insert the MegaFlashROM SCC+ SD with Nextor and go to the SD-card drive however, I get a long waiting time. Could it be that they have a faster method to detect free space on FAT16? Maybe you can use it.

I know that there is such a faster method for FAT32, but not for FAT16. My guess is that the OCM firmware has some kind of hack to use the built-in FPGA to calculate the free space, bypassing the DOS/Nextor code. But I could be wrong; the only way to be sure would be by reverse engineering/debugging.

By Manuel

Ascended (17753)

Manuel's picture

07-04-2014, 10:00

saccopharynx wrote:
Quote:

Try the latest openMSX build, improvements have been made on that. See http://openmsx.fixato.net/ for latest builds. They should be very stable.

Many thanks.

Please let me know whether it's better in the latest development build from that site.

By Grauw

Ascended (9748)

Grauw's picture

07-04-2014, 15:14

konamiman wrote:

My guess is that the OCM firmware has some kind of hack to use the built-in FPGA to calculate the free space, bypassing the DOS/Nextor code.

Hmm, I doubt that…

By msd

Paragon (1455)

msd's picture

07-04-2014, 19:14

I doubt that too. I would measure the disk speed.

By Grauw

Ascended (9748)

Grauw's picture

08-04-2014, 00:22

It’s the same sd-card in the same slot… Only difference that it boots with Nextor in stead of the built-in DOS ROM. Afaik ESE patched the ROM with FAT16 support, and I suspect it also includes something clever to speed up size calculation.

By Retrofan

Paragon (1262)

Retrofan's picture

08-04-2014, 07:56

Grauw wrote:

By the way konamiman, calculating the free space takes a long while on FAT16, and to improve performance there is a hack to stop this calculation at 32 MB, right?

However, on my One Chip MSX the built-in SD-card interface reports free space very quickly! When I insert the MegaFlashROM SCC+ SD with Nextor and go to the SD-card drive however, I get a long waiting time. Could it be that they have a faster method to detect free space on FAT16? Maybe you can use it.

The same goes for Padial SD interface with FAT16: it reports free space very quickly on my MSX turbo R.
Thanks for this update Konamiman. Still hoping you also will support the Padial SD interface with Nextor.

By saccopharynx

Master (151)

saccopharynx's picture

08-04-2014, 15:56

Manuel wrote:
saccopharynx wrote:
Quote:

Try the latest openMSX build, improvements have been made on that. See http://openmsx.fixato.net/ for latest builds. They should be very stable.

Many thanks.

Please let me know whether it's better in the latest development build from that site.

Manuel, sorry for the delay but I've been busy. It is hard to say, if there is an improvement, unfortunately I cannot say that it is notorious. What's indeed the purpose of maintaining a hash value for a HD image? Is it just for data integrity? In that case, is openMSX emulating an expected behaviour that happens on a real MSX each time that data is written? If not, why not to remove that for HD images and keep it for machine ROMs only?

Cheers,
S

By konamiman

Paragon (1117)

konamiman's picture

08-04-2014, 17:46

saccopharynx wrote:

I'd like to report an issue I'm having on BlueMSX when using Nextor v2.0.1. Basically, I just follow the steps in the Getting Started Guide and I cannot boot in MSX-DOS 1. The screens hangs all blue and nothing else happens.

FIXED!! :RNFF:

Thank you for very much for reporting the bug. I don't boot in MSX-DOS 1 mode often so I would hardly have noticed the bug by myself. :)

By wouter_

Champion (453)

wouter_'s picture

08-04-2014, 20:08

saccopharynx wrote:

What's indeed the purpose of maintaining a hash value for a HD image? Is it just for data integrity? In that case, is openMSX emulating an expected behaviour that happens on a real MSX each time that data is written? If not, why not to remove that for HD images and keep it for machine ROMs only?

The reason why openMSX regularly calculates a hash of the HD image is the "reverse" system: Suppose you write something on your HD image and then reverse to some time before that write. So now the MSX is back in an 'old' state, but the HD image already contains 'future' changes(*). To avoid risking disk corruption we make the HD image read-only when you reverse to a moment in time where the content of the HD was different. And to be able to detect these differences we store a hash of the image in each reverse-snapshot.

In older openMSX versions we used sha1 as a hash function. So on each write to a (big) HD image there was indeed a noticeable delay caused by the hash re-calculation. Newer openMSX versions use tth which can be calculated incrementally. So now there should be no delay anymore when writing to (big) HD images.

@saccopharynx: if you're still seeing delays after each HD write with the latest openmsx version, then we'd like to know about it

(*) In the future we might also (optionally) revert the state of the HD image. Depending on the situation you may want either this is or the current behavior.

By Grauw

Ascended (9748)

Grauw's picture

08-04-2014, 21:22

Ha, the tiger hash! :)

By saccopharynx

Master (151)

saccopharynx's picture

09-04-2014, 02:44

wouter_ wrote:

@saccopharynx: if you're still seeing delays after each HD write with the latest openmsx version, then we'd like to know about it

Thanks, it clarifies why it is needed. I do know how noticeable were former delays (in very old versions) so as to compare with current ones. Probably the improvement was indeed significant and I just cannot distinguish the difference because I first noticed this on openMSX v0.9.0. When I updated to v0.9.1, the delays basically remained the same. That is why I say that they are not notorious (specifically comparing v0.9.0 and v0.9.1).

If you want to experience the same delays I see, please just follow the the instructions in Sections 3 and 4 of the Nextor 2.0 Getting Started Guide at http://www.konamiman.com/msx/nextor/docs/Nextor%202.0%20Getting%20Started%20Guide.pdf. My HD image size is 100MB.

Cheers,
S

By saccopharynx

Master (151)

saccopharynx's picture

09-04-2014, 02:47

No worries @Konamiman. I will have a look at that as soon as I can. Thanks a lot.

By Manuel

Ascended (17753)

Manuel's picture

09-04-2014, 09:44

saccopharynx: so, please try with a recent version, 0.9.1 is old and does not contain the improvements that wouter mentioned.

By saccopharynx

Master (151)

saccopharynx's picture

09-04-2014, 10:26

You're right, sorry about that. The download link was just a bit below from the top of the page that I didn't check the date and thought that it was the most up-to-date version.

By Manuel

Ascended (17753)

Manuel's picture

09-04-2014, 10:37

So, is the problem gone with the latest version? (Also, what download link do you mean exactly?)

By saccopharynx

Master (151)

saccopharynx's picture

09-04-2014, 11:16

I meant the download link to v0.9.1 (I didn't see the link to http://openmsx.fixato.net/builds/windows/x86).

I cannot tell you now if I see improvements. I downloaded http://openmsx.fixato.net/builds/windows/x86/openmsx-0.10.0-..., but unfortunately, it seems that the directory structures for extensions and machines have changed, as well as many rom names, so making this new version to work is not straight forward (it is not as simple as copy and paste the hole directory structure). I will try it this weekend.

I have also seen some inconsistencies in the way that roms are linked (e.g. some paths refer to the "roms" directory, others don't).

Thanks,
S

By saccopharynx

Master (151)

saccopharynx's picture

09-04-2014, 11:38

One more thing, when I was trying the latest version of openMSX (the one pointed above), the emulator crashed when using the National FS-5000. The crash is weird because it does not occur every time. Basically, the emulation starts, but after the scrolling MSX logo, the emulation windows "some times" just closes (most of the times if I press F9 while starting the machine).

By Manuel

Ascended (17753)

Manuel's picture

09-04-2014, 16:03

The paths are irrelevant. If you put your ROMs in the systemroms folder, all ROMs are just found (by sha1sum). So if you have your ROMs in your share/systemroms folder (as explained in the manual), it's a matter of uninstalling the old openMSX and installing the new one and everything runs. It's more comfortable to use the MSI installer for this, so http://openmsx.fixato.net/builds/windows/x86/openmsx-0.10.0-...

About the FS-5000 issue: does it only occur with this machine? Does it still happen if you use the default settings? (rename or move out of the way the settings.xml file (make sure to keep it in case this fixes the problem, so we can investigate it))

By saccopharynx

Master (151)

saccopharynx's picture

10-04-2014, 00:58

Manuel wrote:

About the FS-5000 issue: does it only occur with this machine? Does it still happen if you use the default settings? (rename or move out of the way the settings.xml file (make sure to keep it in case this fixes the problem, so we can investigate it))

Not only with that machine. I am trying others now and I see the same issue: Panasonic FS-A1FX, FS-A1GT and Talent TPC-310. My settings.xml has no settings. Anyway, I renamed the file but there is no difference. Unfortunately, I cannot tell you much more because I have not been able to reproduce the crash every time I run the emulator. It looks random even though there is a cause.

FYI: The issue happens no matter I use Catapult or the command line.

Cheers,
S

By Manuel

Ascended (17753)

Manuel's picture

10-04-2014, 09:43

OK, so you're using the 32-bit version on which OS exactly? (I tried the 32-bit version on XP and couldn't reproduce it...)

Is openMSX simply exiting or do you get some kind of crash message?

If you run on the commandline, do you see any message there?

I'd really like to pinpoint and fix this issue, so I need your help Smile

Did you try a version with the MSI installer?

By Grauw

Ascended (9748)

Grauw's picture

10-04-2014, 10:28

Getting increasingly off-topic guys… consider creating a forum thread for this issue.

By saccopharynx

Master (151)

saccopharynx's picture

10-04-2014, 11:20

Totally out of topic. Feel free to move it. I will let you know in details ASAP.

By Manuel

Ascended (17753)

Manuel's picture

10-04-2014, 12:27

Good idea, I'll ask the moderator.

By snout

Ascended (15184)

snout's picture

10-04-2014, 13:08

Unfortunately we can't move the comments to the forum (easily), so please start a brand new forum topic on the openMSX forum and take it from there. Thanks!

By Prodatron

Paragon (1789)

Prodatron's picture

13-04-2014, 20:55

konamiman wrote:
Grauw wrote:

However, on my One Chip MSX the built-in SD-card interface reports free space very quickly! When I insert the MegaFlashROM SCC+ SD with Nextor and go to the SD-card drive however, I get a long waiting time. Could it be that they have a faster method to detect free space on FAT16? Maybe you can use it.

I know that there is such a faster method for FAT32, but not for FAT16. My guess is that the OCM firmware has some kind of hack to use the built-in FPGA to calculate the free space, bypassing the DOS/Nextor code. But I could be wrong; the only way to be sure would be by reverse engineering/debugging.

FAT32 is logging the free space and the next free cluster inside the "fsinfo" sector, which makes free space calculation and disc space allocation much faster.

On my TurboR with a MegaFlash-SD Card and a 4095MB FAT16 partition I measured the following:
- Nextor: DIR command with 1 file and free space calculation: 5,76seconds
- SymbOS: DIR command with 1 file and free space calculation: 2,85seconds
So it seems, that there is some potential for a faster detection, as the SymbOS driver is currently not optimized (LDIR instead of LDI:LDI:..., single instead of multiple sector read commands), and internally it always works with 32bit values. I could have a look at the code (long time ago...), if you are interested.

By rjp

Master (190)

rjp's picture

26-04-2014, 05:49

Maybe the quickest way is to do not report any free space. In my Turbo-R, Nextor reports 32 Mb of free space very quickly. But in my MSXs 1, 2 and 2+ (I've got plenty of them), even using RALLOC, we needed to wait some (little) time to finish the DIR command.

Why not RALLOC patches Nextor, in order to report 0 bytes, and doesn't make any calculations? It would be very interesting.

By Meits

Scribe (6350)

Meits's picture

07-11-2016, 16:19

Now I do wonder what I am doing wrong here after doing exactly what done in the screenshot on top of this newspost:

By Meits

Scribe (6350)

Meits's picture

13-11-2016, 23:41

Anyone got it working and likes to share the knowledge?

By Guillian

Prophet (3413)

Guillian's picture

14-11-2016, 10:34

Try updating NEXTOR.SYS to version 2.10

By Meits

Scribe (6350)

Meits's picture

14-11-2016, 14:13

Just did and it failed.
Does that perhaps have something to do with me already having used mapdrv to map the secondary sd card by doing:
mapdrv b: 1-0 3 1-3
?

Edit:
Got the NEXTOR.SYS from your latest romdisk and it doesn't work. I flashed your romdisk and it does work. Something in my boot sequence is the cause of it not working. Will have to find out.

By Meits

Scribe (6350)

Meits's picture

14-11-2016, 14:29

It turned out my mapdrv.com was outdated Running Naked in a Field of Flowers