Define msx2 segmentation rules (to fix hangs at boot and direct reads)

[balyuf]

Hi Alan,

This is my first time contributing something on github! I am an MSX retro-computing enthousiast and I have a fix for the MSX2 target ...

Your commit 83342ae244312ff662543fce74907aeb90de6e66 (msx2: sort out the memory maps and buffers) introduced direct read access to userspace and to support that feature it changed buffer locations, but also set the code segment for common code to CODE1 (iso COMMONMEM). By itself this change crashed the MegaFlashROM SD card detection (as its code was spilling over into the bank that needs switching), but even when e.g. putting its code back in COMMONMEM then the inode code crashes for the same reason while performing direct reads.

So, after playing around a bit, I discovered that MSX1 has a rules.mk entry in its platform directory, defining the segmentation rules. MSX2 did not have such a rules.mk. After introducing it, based on the MSX1 one, but adapting its VIDEO and FONT segmentation to what is done in MSX2 (I hope), now everything is back to normal - well up to speed is probably a better expression, because the direct read shows off on the MSX TurboR in comparison with the last working commit b047efe617e419a07661a0aacf86571d27f019c9 (msx2: note work needed to fix the horrible I/O speed)!

Is this the way to go, and are the rules correct for MSX2? I played around a bit with my build and had no crashes. VI however seems to misbehave (often the screen shows stripes and when saving sometimes much more is saved than what was in the buffer), but I think that is a separate bug, in userland, not in the kernel? (In general I noticed kernel keyboard handling is a bit off, having frequent doubles and missers on openmsx, something I want to look at; the doubles issue should be fixed by introducing delay after the first keystroke). Anyway, that's all off topic for this pull request. What do you say?

Kind regards, Filip.

[EtchedPixels]

What sdcc are you using for this as I can't duplicate the crash at all.

The vi one I can see - that looks like a bug in the vdp2 code rather than the editor. Looks like it trashed the font for some reason. I know the timing is probably not quite right on the vdp2 so it might just be driving it too fast.

Keyboard seems ok to me but any improvements are welcome.

[balyuf]

Hi Alan,

I am using sdcc from your own repo. Should I take the stock one? I compiled it on WSL2 with recent and up-to-date Ubuntu, with stock boost libs. Should I go for the ones from the website?

I was wondering why nobody else seemed to complain about this indeed. For me the SD detect code was spilling over the 0x4000 boundary for instance. I looked for pattern 11 01 01 (from the SD listing) and it was at 0x8138 in the fuzix.ascii8.rom (so 0x4138 in address space). Segmentation is clearly working in my setup, but why would there be this difference?

Regards, Filip.

[EtchedPixels]

I fixed the vdp code. The other one is me being really dumb

There's a rules.mk in my build tree that I forgot to git add 8)

Try the changes I just pushed

[balyuf]

YES!!!

This works and vdp stripes fixed indeed, thanks!

What I still see is if you have a screen with on the second line from above some remnant of output (say an ls output) when vi opens it does not clear that line, but going there clears it ...

That is repeatable, what I have had that after saving and catting my file of 3 lines I had a bunch of kernel space garbage in the file too, I don't know how to repeat (but I am known to impulsively do things which breaks software, haha).

The keystroke speed is a funny thing. Today the keystrokes are slower and only very occasionally I get doubles or missing one. But what I do see is this: ctrl-c keeps reproducing itself until I stop pressing control. Same with ctrl-k, which I hoped would kill the line but gave a nice glyph). I sometimes wonder if the speed thing is not just plain MS Windows madness ... I do have a tendency to type irregularly and so type subsequent letters too fast, almost coinciding. I noticed that various PCs (drivers) through the years cope differently with that. Anyway I will follow up and see if there is something to be done in order stabilize this.

Being new here, what should we do with the pull request? You can of course close if you want ...

[EtchedPixels]

I think this one is fixed - if you figure out the tty one let me know.

vi not clearing some bits until you go there is a bug in the vi clone I think - it does the same under Linux and I've not yet worked out why

[balyuf]

Ok, I saw that MSX1 has the same VDP stripe issue ... would you import the fix over there too?

And the keystroke speed feels completely different from MSX2, so I think I will look into harmonizing MSX1 and MSX2 ...

[EtchedPixels]

I will take a look - the MSX1 and 2 code are actually unrelated

[balyuf]

The stripes are now gone on MSX1, but this reveals now a more fundamental problem with clear_across - it does not clear till EOL, as evidenced by opening vi (without file) on a full screen: the ~'s are printed, but no spaces beyond. I verified that the right clear_across statements are issued, and I also tried to increase VDP_DELAY, even up to 5 NOP's to no avail. When I issue kprintf's for every clear_across in vt.c, the closing bracket of my print string appears on screen (kprintf issues right before the clear_across itself). So it may still be a timing issue? Do you have any idea what might be going on?

[balyuf]

Ok, problem with clear_across fixed in pull request #999 ...