The Sinclair QL Forum

I have started many QL projects over the years, but don't currently have enough time to make progress on all them.

Which projects do you think I should continue? Thanks for the help and any additional suggestions.

Concentrate on the quick wins. Only if you really finish something you gain motivation to continue with something else.

More info on some of the projects:

MDVRAW format:
viewtopic.php?p=61563&hilit=qlmdvraw#p61563

ZX83 ROM prototype:
viewtopic.php?t=4419&hilit=zx83+eprom&start=70

Pico ROM:
viewtopic.php?p=63980#p63980

Video Card:
https://youtu.be/7EizW3ZWNqc?si=7fqV0pEbczlDRUnv

tofro wrote: Mon Sep 01, 2025 10:12 pm Concentrate on the quick wins. Only if you really finish something you gain motivation to continue with something else.

Good suggestion! Probably the only 'quick' project in the list is MDVRAW. Maybe also Q-emuLator 4 since it is already so close to completion... unless I decide to add more features

As an (almost daily) Q-emuLator user, I would love to see version 4.0, and hope it toinclude Qsound emulation.

Any other of your listed projects sounds really interesting, so I encourage you to go for one after the other. Keep QLing!!!

Hi Daniele,

Will Q-emulator 4 support Apple M-series processors natively?
V3 under Rosetta 2 is working fine for me but I guess an ARM version would future proof it for when Apple ditch R2 like they eventually did for R1.

JY

Sparrowhawk wrote: Tue Sep 02, 2025 10:36 am Hi Daniele,

Will Q-emulator 4 support Apple M-series processors natively?
V3 under Rosetta 2 is working fine for me but I guess an ARM version would future proof it for when Apple ditch R2 like they eventually did for R1.

JY

I work for a company that makes ARM CPUs for Windows, so its not just MacOS in the transition! ARM versions all round

I've put a check by other - it would be good to be able to put ROM's in other locations too - where these are supported by Minverva, and also some easy way to mimic basic hardware in/out for debugging using Qemulator - that may merit further explanation - if a 'fake' I/O device at a set address could splash up a pop up screen and allow values to be read / written - so that driver development could be done within a virtual environment.

Sparrowhawk wrote: Tue Sep 02, 2025 10:36 am Will Q-emulator 4 support Apple M-series processors natively?
V3 under Rosetta 2 is working fine for me but I guess an ARM version would future proof it for when Apple ditch R2 like they eventually did for R1.

Hi Sparrowhawk, and thank you for your help in the past with beta testing!

Unfortunately, version 4 will be Windows only (Intel/AMD). I decided to suspend Mac development for lack of time and resources. The latest version for intel Macs is still available (as you said, it still runs on Rosetta) and there are free registration codes. The file system api I was using no longer exists in macOS, graphics and other APIs are deprecated and probably, to future proof it, it would be wise to rewrite the Objective-C parts in Swift. Major work and I would have to buy a recent Mac (ARM based for testing, and at least 16GB RAM for xcode), with little hope of registrations ever repaying it. For now, I prefer to spend the time on the projects listed here and to add more features to the Windows version. Of course you never know, maybe one day I'll get a Mac again one way or another and would likely not resist the temptation of updating the emulator.

There have been 4 version of Q-emuLator for Mac so far, and only one was a straight recompile:
- 68K: app framework written from scratch based on snippets from the hefty Inside Macintosh printed tomes
- PPC: straight recompile plus a compiler workaround; stopped running months later when Apple discontinued most of the APIs
- Intel x86: major rewrite of the app using Objective-C (not because I wanted, but no choice there), Cocoa and OpenGL. Required buying a new Mac.
- Intel x64: needed to replace some deprecated APIs and work around some undocumented changes in API behavior. Required a new Mac.

On Windows I have been luckier so far, and I have Windows machines around at home anyways. The current version still runs on almost anything since Windows 95 and the only significant breaking change in APIs was when DirectDraw discontinued palette video modes after XP.
For version 4, however, I think I will require Windows 7 or later to simplify development and be able to use newer functionality.

Pr0f wrote: Tue Sep 02, 2025 5:23 pm I've put a check by other - it would be good to be able to put ROM's in other locations too - where these are supported by Minverva, and also some easy way to mimic basic hardware in/out for debugging using Qemulator - that may merit further explanation - if a 'fake' I/O device at a set address could splash up a pop up screen and allow values to be read / written - so that driver development could be done within a virtual environment.

Thank you Pr0f! I think you mean multiple/longer expansion ROMs at C0000 and above? Four 16KB slots are supported internally, but I think you are the first to request it, I will look into adding at least one more to the UI.

For hardware development, there is a sort of C/C++ SDK already, although at the moment it only supports the expansion area addresses and not the back ROM area.