Running PUT9000 under NEXTOR

That can be checked with dos version , well that can perhaps also be done with Nestor , but that does mean old software doesn’t work with never versions.

For now I added patching for Nextor 2.1 alpha2 in the way it was done for the other DOS versions.
Here is the result put9000_13092018.zip
It might work.... or not...

You can find the code on Bitbucket (put9000)
I have created a project to cross compile on Ubuntu and added make targets to launch into openMSX with both MSX-DOS2.31 and NEXTOR.

I tried to use the CHPUT hook and to allocate TPA. But struggled too much with relocating the small piece of code to go from the CHPUT hook into an allocated page. I need to look at this again later.

To reload MSX-DOS is not what I stuggled with. Writing some code that needs to be relocated is.
Nevertheless if you have something that is usable, I would be happy to use that.

While attempting to change the loader I did too many things at the same time:

• Use H.CHPUT instead of the MSX-DOS patch
• Add calls to ENASLT, since now it is clear I cannot assume RAM from the primary mapper is already there
• Allocate space from TPA
• Make the code that was fixed to 0x3f00 relocatable

This became quite a mess yesterday evening.
So, I will re-attempt with smaller steps.

The source code of jANSI is available on MSX Info pages and would be interesting take a look on it, perhaps it can contains some idea that can be used.

Hi erik,

Testing PUT9000 with my telnet client, it seems it is not updating the cursor position ram variables:

0xF3DC - Current Line
0xF3DD - Current Row

This is important for Telnet terminals, for two reasons:

1 - Lots of BBSs use Cursor Down and Cursor Right 255 positions (which should be acceptable, you just move until the end), then print bs and any character and finally \x1b[6n to ask current cursor position. At this point my software gets current line and current row, that was not updated, and as result BBSs will think screen is less than 80x25...

2 - Syncrhonet BBSs also use this on a few modules, like the ones print messages / avatars, get the current cursor position and then position what they want to print based on that (maybe this is because those modules are external, go figure) and if a proper cursor position is not given, it will either see it is where it should not and not print (print a message error instead) or print it on the wrong position...

Also I'm getting artifacts using a V9990 on my OCM, pardon the bad quality of the image, but I do not have a 15Khz monitor handy and my capture card sucks:

P.s.: I've checked this on a 15KHz vga monitor a few days ago and the artifacts were there. I've tested both Chibi Akumas v9990 version as well as Life On Earth and also both show no artifacts on the same system, so I'm kind of thinking it is not an issue because I'm using a v9990 on an OCM system. :)

Anyway, thanks for the driver, just telling what I've found out. :)