MiNT 1-18-0 broke my Milan Keyboard

[milthorst]

I had been happily running MiNT 1.15.12 on my Milan 060 until my hard drive died. After restoring from backups to a new (used) drive, I though I'd upgrade to 1-16-1 beta using wongck's excellent guide (Thanks wongck for saving my bacon while the forum was down). That worked OK except for occasional hangs during boot-up. I thought moving up to 1-18-0 might fix this (it does boot on the first try most of the time), but now the keyboard is unreliable. Typing often requires multiple presses of the key before a character appears. The "dropped" characters wind up in the Console window. When I run Shutdown, the messages go to the screen instead of a window. Trying various combinations of Toswin2 and Xconout2 makes no difference. Same with/without keyboard.tbl. I'm using n_aes 2 and Jinnee and I'd like to stay with them. Starting n_as with INIT= or GEM= also makes no difference. Have I found a bug or is there an easy fix I've overlooked?

Milt in Seattle

[ThorstenOtto]

Maybe you found a bug, but nobody is going to fix that in an ancient release. Please try a current snapshot, and if that bug still persists, report it on the mint mailing list, or in github issues

But even then, it might be hard to fix if that is specific to the milan.

[PeterS]

Maybe we need a 1-20 release so people don't use these ancient versions.

[joska]

I'm using a rather old 1.19 (from 2014!) on my Milan060, keyboard is working perfectly fine. So try updating to 1.19 and see if that solves your problem.

https://bintray.com/freemint/freemint/d ... ur-060.zip

Please note that this archive contains binaries for the Falcon/CT60, Hades060 and Milan060. Make sure to only use the Milan-relevant parts.

[mikro]

Make sure to only use the Milan-relevant parts.

FreeMiNT takes care of that. No need to disable anything, except if you want to save memory. The snapshot is configured in such way that only milan-compatible modules are loaded (if not, it's a bug and report it).

[joska]

Ahh, I forgot about that. But I would atleast remove the non-Milan kernel from the auto-folder, even if it just exits gracefully there is no need to slow down boot and clutter the screen.

[mikro]

There is no (non-)milan kernel in auto-folder. :)

[joska]

There are two kernels in the AUTO-folder in that archive. mint060.prg which is 368937 bytes and mintmil.prg which is 367832 bytes. Are you saying that both are for the Milan? In that case, why two?

[Neurotoxic]

There are two kernels in the AUTO-folder in that archive. mint060.prg which is 368937 bytes and mintmil.prg which is 367832 bytes. Are you saying that both are for the Milan? In that case, why two?

Could it be that the "mint060.prg" is for a Milan with a 68060 CPU and "mintmil.prg" for a Milan with a 68040 CPU? So the user has to choose the correct kernel and delete the wrong one from the auto folder?

[joska]

There is a separate archive for the 040-build, with three kernels in AUTO: mint040.prg, mintara.prg and mintmil.prg

[mikro]

Ah, sorry, I thought you are talking about the preconfigured snapshot:

tt_falcon_clones.png

Which indeed works on TT/Falcon/Milan/Hades out of the box.

[milthorst]

I finally got MiNT 1-19 from Joska's zip file to boot all the way through to Jinnee, and verified that the keyboard problem still happens with it. BTW, the mint060.prg kernel refuses to run on my Milan and tells me so! Not sure where to go from here, but its too late to try anything more tonight. Did anything change between 1-16-1 beta and 1-18-0/1-19-cur that could have affected keyboard handling? I also saw this message during boot-up: "Hardware needs SUPER on first descriptor!" What does it mean?

[Neurotoxic]

I think the language and keyboad settings of the Milan are done with the msetup.prg. Just rename the *.tbl file in your mint folder to *.tbx or move it out of the mint folder. You could also delete it but I won't recommand it.

[ThorstenOtto]

BTW, the mint060.prg kernel refuses to run on my Milan and tells me so!

I think that is normal. The 060 kernel is for other 060 based machines. Milan is a bit more special.

Did anything change between 1-16-1 beta and 1-18-0/1-19-cur that could have affected keyboard handling?

Probably a lot. But since the kernel is working for others, there must be something else going wrong.

I also saw this message during boot-up: "Hardware needs SUPER on first descriptor!" What does it mean?

The message is from here. Maybe harmless? @joska should be able to tell. Unless that has changed recently, MiNT still expects the PMMU to be initialized by some other means (dunno whether that is already done by the TOS on Milan, otherwise by tools like SET_MMU).

[joska]

I also saw this message during boot-up: "Hardware needs SUPER on first descriptor!"

Completely normal.

After reading your first post more thoroughly...

Typing often requires multiple presses of the key before a character appears. The "dropped" characters wind up in the Console window.

...I suspect that your problem is not MiNT itself. My guess is that you have some process or TSR running that is eating your keypresses. What else than mintmil.prg and the graphics card driver do you have in the auto-folder? Which accessories? Desktop? GEM programs? A complete list of processes (Control+Alt+L will bring up the Task Manager showing all the processes) may help.

You mention Console window, I assume that's TosWin? Running Miniwin with the old console.tos hack can give you problems under recent (as in "from this century") kernels. What happens if you don't run your terminal emulator/console?

[joska]

When I run Shutdown, the messages go to the screen instead of a window.

Completely normal, as the console window is a GEM application and is one of the very first things that is killed during a shutdown.

[milthorst]

I never saw any shutdown messages other than the final System Halted until moving past 1-16-1.

I had a look at keyboard.c and noticed that Ozk's change to interrupt handling went in between 1-16 and 1-18.

A strange observation yesterday evening: I left the system on while I was away for 45 minutes, and when I came back the keyboard was working properly. After a reboot, problem was back.

ACCs are: bubble.acc, cache040.acc, cdaudio.acc, cops.acc cs4235.acc, outline.acc, ps_contr.ac, st-guide.acc, ximgsnap.acc.
AUTO folder (unsorted): atidrv11.prg, isapnp.prg, cs_bios.prg, nvdi.prg, extendos.prg, mintmil.prg, wdialog.prg, fpu__2m.prg.

I tried disabling keyboard.cpx. Didn't help. Will try to attach some screenshots as soon a I find a place to host them.

[ThorstenOtto]

The first thing would be to disable *everything* that is not absolutely needed to boot the system. Maybe one of them just runs wild, and hogs cpu time. That also includes any *.cpx that are active.

[milthorst]

Link to photos (I hope):

https://photos.app.goo.gl/ZTqocN6zm8xuto7G7

1. Boot messages after hang at keyboard.tbl install (there is none). Next boot attempt worked.
2. What I typed in QED (took more key presses than this)
3. Console window after typing this.
4. Processes part 1 of 2
5. Processes part 2 of 2

[joska]

Ok, you're using N.AES and not XaAES, that's useful to know. I have not used N.AES since 2006-2007. I can confirm that keyboard is not working with N.AES and the 1.19 kernel, just tried this combination now on my Milan. But I'm not sure if the keyboard is the real problem here, the entire system is extremely slow and sluggish. They keyboard sort of work, e.g. I can kill applications/accessories by Control-clicking on their entry in the desk menu. But typing does not work, nor does hotkeys/keyboard shortcuts in any GEM apps.

That aside, I see a lot of issues with your setup:
- Memory protection is disabled.
- ...probably because you are also using Jinnee and OLGA, both programs that behaves badly.
- Don't use nohog2.acc, that's just when using MiNT with the ROM AES.
- WDialog. Don't ever use this with anything else than plain TOS with NVDI 5. At best, it does nothing under MiNT/N.AES, but my experience is that it causes lots of problems. Also, you are already using NDialog which is the N.AES implementation of the WDialog features (which again is a TOS hack that implements some MagiC-only AES features).

[joska]

Btw I just tested on my Falcon/CT60, N.AES behaves exactly the same there. So it's not Milan-specific.

[Rustynutt]

And I just purchased the CD version from Woller....

I don't recall issues with "MAES" then I've not really used the Milan a lot. Was caught up in getting the SCSI to work with Michael's driver, testing a prototype 060 adapter and playing with various video cards before you sent the ATI (yet tested) driver

Since, have the docs and photos off Atari forum de for the IC upgrade to enhance performance, and hopefully allow the Amiga 060 adapter to be pretty much drop in. The bread board a member and I was testing just had too many issues.
Soon

[milthorst]

I put WDIALOG back in (but forgot to take out N.Dialog) because without it NVDI was locking me out if I tried to start up without MiNT in order to fix MiNT setup problems. Other than the keyboard problem, my system was definitely not "slow and sluggish." I could run my setup with MiNT 1-16 memory protection on, without WDIALOG, without problems. NOHOG2 was only in for testing and it didn't help. Is the OLGA function built in now, or what takes it's place? If I try XaAES, can I still use Jinnee for my desktop? I don't want to use Thing or anything the resembles it.

[Playmobil]

If I try XaAES, can I still use Jinnee for my desktop? I don't want to use Thing or anything the resembles it.

Yes ! You can ! Just edit XaAes or Mint config file, and replace Teradesk or Thing by Jinnee !

In my memory, it's at the end of the config file of XaAes... If not it's at the end of Mint config file...

Sorry for my poor english...


And if you put your hands into XBOOT3, you can boot under multi config...
Plain TOS
Mint=>XaAes=>Thing
Mint=>MyAes=>Thing
Magic=>Thing
Mint=>XaAes=>Jinnee
etc etc etc


Something like that in one of mine configuration...



EDIT : MyAES & Jinnee are not very friendly... But XaAes & Jinnee no problems... Magic & Jinnee, Bhaaaaa they are friends !

[mikro]

Yes, the N.AES regression is a known bug: https://github.com/freemint/freemint/issues/143

As for the other things, I just say that if it appears to work with WDIALOG, NOHOG2.ACC, JINNEE, OLGA and all the others, it doesn't mean it is working properly. At some point in time you are going to get strange crashes, redraw errors or worse and you are going to blame FreeMiNT/XaAES for it.