Hi Nauman,

First of all, congratulations! That's impressive. Thanks for sharing your code - I'll certainly try and play around with it a bit.

On your questions:

• I deprecated the pygame interface for several reasons: the immediate cause was that it appeared, at the time, no longer maintained; it was dependent on an old SDL version 1.2 and there seemed to be no plans to upgrade. Meanwhile SDL1.2 was itself being deprecated so this was becoming a support issue. The apparent successor at the time (this was a few years ago) was pygame-sdl2 but this project made a conscious choice not to support 8-bit surfaces, which I heavily used. At that point I considered that what I was using pygame for was a fairly limited amount of functionality, and if an important part of that disappeared it wasn't worth working around it. Moreover this as easily replicated using the SDL2 library directly, at which point it was better to "cut out the middleman". However the interface was still working well so while I developed the replacement I kept it in place. Longer term however I don't want to maintain two separate modules doing essentially the same thing, but needing separate testing, etc. Currently PC-BASIC supports too many platforms, options, interfaces, Python versions etc. and I cannot keep the effort up with testing and releases - between the day job and other interests, I just don't have the time anymore.
• Of course since then, pygame development has picked up again and I noticed they now have a SDL2 version. But given that I've built the SDL2-based code anyway and it works better than the pygame one, I still don't feel like bringing back the dependency.
• In terms of merging this, I think it would be worthwhile: it could be a lower-maintenance path to releases (releasing Windos and Mac packages is a huge pain). But it will not be easy to get there - for example, I don't want to have two replicated code bases living together with much the same code, one async and one not. But perhaps it is possible for the async version to support all use cases/interfaces, including cli, text and graphical on the desktop. Obviously as you point out this is a proof of concept, and it is awesome that it works - further development might perhaps consider that as a target?
• I'm assuming async is needed for I/O related items. There is a potential clash / architectural difference with the interface setup in PC-BASIC which is thread based. I'm not super attached to the thread approach, its main aim was to separate the interface form the core library but non-I/O threads in Python are problematic due to the GIL. (The GIL may be going away, but it'll be a while...) So if an async approach can fully replace the thread approach, that again is interesting as it may address the performance issues with threads.

This turned out to be a long message, hope the background helps