The Sinclair QL Forum

Hi there guys,

I'm interested in taking on development for the ql. I'm coming from atari st demo coding (m68k assembly) and figured it wouldn't be a major leap to start on the ql. But I'm currently trying to validate that claim .

I am wondering what you assembly coder guys development setup is for the ql. I'm used to cross assembling, debugging on an emulator and using the real machine for testing on atari, to keep development iteration time as low as it can be. Which cross assembler would you recommend?

Being completely new to the ql, I have a few more questions; how accurate is emulation of the ql (cycle accurate or not, are there certain areas of the hardware that are worse emulated than others)? Is there an emulator that has a debugger and/or memory/instructions viewer?

Kind regards
Wietze

Being completely new to the ql, I have a few more questions; how accurate is emulation of the ql (cycle accurate or not, are there certain areas of the hardware that are worse emulated than others)? Is there an emulator that has a debugger and/or memory/instructions viewer?

I can answer for uQlx/sQLux emulators. They are basically QDOS emulators, they don't really emulate the hardware at all, and run at full speed of host all the time!

If your interest is swift turnaround, I'd definitely recommend not cross-assembly, but rather native builds on an emulator - for two reasons:

• There's no fixed addresses in QDOS except the hardware, everything is floating. This requires QL programs to be 100% position-independant code (there are exceptions, but that complicates things unnecessarily). Cross-development tools I know just aren't very good at producing such programs, they would assume a relocating loader which QDOS simply hasn't. Native tooling is aware of these restrictions and will warn you if broken or work around these.
• If there's one thing the QL was exceptionally good at at its time, it's its development tooling. You're coming from an Atari ST background, so you might know the GST Assembler and linker - Its ancestor is available on the QL and does a really nice job here.

You probably wouldn't want to use native editing tools, so you should work on an emulator that has direct access to its host file system - most current ones do.

How I work: I'm using MS Visual Studio Code as development environment, but run "make" on the emulated QL directly on the host FS. That saves me from tedious transfers of source code or binaries back and forth, and also allows modern Editors and CM systems like SVN or Git. The binary is directly available to be run in the emulator using native tooling like QMon (The best QL Monitor program).

Choice of emulators: Even if there are more emulators, the ones of choice really are QPC2, SMSQmulator and Q-Emulator. The former two are free, the latter is shareware. The former two are emulating "modern", SMSQ/E based "high-end"-QLs with lots of memory and better and faster CPUs, while the latter is more to the real thing, the closest you can get to in the QL world (don't expect it to be a 100% cycle-exact emulator like you might know from the ZX Spectrum scene, however). QPC expects a Windows environment (runs well on Wine or Parallels, however), while SMSqmulator is Java-based and doesn't expect an X86 system. Q-Emulator is available for both Windows and MacOS, its Windows version is free as long as you emulate a non-expanded QL (so ideal as a canary test environment).

Limits of emulation: There is no 100% emulator for the QL - all have their limits, Q-Emulator probably the closest to the real thing. It does, however have limits when emulating sound, and some peculiarities with the video hardware (it is, for example, the only emulator that supports the video page flipping the QL has, but on my systems with very noticeable delay.) Programming close to the silicon requires in fact real hardware.

Thanks for the elaborate answer. Ive taken a little time to download the Q-emuLator and it works like a charm!

The approach to have a shared directory into the emulator is key for a fast cycle time, I agree. This should also allow you to assemble outside the emulator and just run the file inside the emulator.
I took a quick peek at the `Its in our DNA' binary file. And it seems to me like headerless raw assembler output, that is in turn loaded by some boot script. So I suppose generating the binary raw machine code and generating a basic boot script around it should be sufficient to then run it inside the emulator. I will put this approach to the test when I can.

In order to do so, I first need to be able to write some code that display stuff to the screen . So Im off to the tutorials sections and see if I can learn some way to poke data into screen address and display it!

Thanks again for the pointers, they are really useful!

spkr wrote:Is there an emulator that has a debugger and/or memory/instructions viewer?e

The Windows version of Q-emuLator has a built-in debugger (disclaimer: I'm the author). It's very crude, but can be useful as it's non-intrusive.

M68008 wrote:

spkr wrote:Is there an emulator that has a debugger and/or memory/instructions viewer?e

The Windows version of Q-emuLator has a built-in debugger (disclaimer: I'm the author). It's very crude, but can be useful as it's non-intrusive.

Im on OSX, but Ill install it under wine and give it a go!

Some newbie question;

Im writing 128 bytes to screen locations in a loop, which is throttled by vsync (effectively, assumingly writing 1 row of pixels every vsync). Vsync is done as described at https://www.chibiakumas.com/68000/sinclairql.php

I _assume_ that vsync occurs at 50hz, and I would thus assume that the screen is filled in 5-odd seconds.

When testing my code on Q-emulator, it takes considerably longer.

Would anyone have an idea what the cause of this could be?

M68008 wrote:

spkr wrote:Is there an emulator that has a debugger and/or memory/instructions viewer?e

The Windows version of Q-emuLator has a built-in debugger (disclaimer: I'm the author). It's very crude, but can be useful as it's non-intrusive.

This is wonderful! Thanks so much. Im curious as to why this feature did not make it into the OSX version; would you care to elaborate?

<edit> I suppose it has to do with the debugging capabilities being provided be a windows specific other party dependency

spkr wrote:

M68008 wrote:

spkr wrote:Is there an emulator that has a debugger and/or memory/instructions viewer?e

The Windows version of Q-emuLator has a built-in debugger (disclaimer: I'm the author). It's very crude, but can be useful as it's non-intrusive.

This is wonderful! Thanks so much. Im curious as to why this feature did not make it into the OSX version; would you care to elaborate?

<edit> I suppose it has to do with the debugging capabilities being provided be a windows specific other party dependency

The debugger is a separate component I wrote as a Windows DLL and the UI uses Win32 API calls. It didn't seem worth porting it as I don't know of anybody other than me using it.

spkr wrote:Some newbie question;

Im writing 128 bytes to screen locations in a loop, which is throttled by vsync (effectively, assumingly writing 1 row of pixels every vsync). Vsync is done as described at https://www.chibiakumas.com/68000/sinclairql.php

I _assume_ that vsync occurs at 50hz, and I would thus assume that the screen is filled in 5-odd seconds.

When testing my code on Q-emulator, it takes considerably longer.

Would anyone have an idea what the cause of this could be?

In order to get the accurate speed I had to enter supervisor mode and turn off the interrupts.