But the "Print At" and RST routines uses lines then columns which I would have said in Y,X as you say. Then Jonathan refers to them as X,Y.

As I mentioned, it’s not a good idea to think of the print position as having coordinates in the conventional sense. Jonathan’s tutorial is probably reflective of his peculiar paradigm. No need to rack your brain over it. Just remember that it’s “at row R, column C.” Forget the X and Y. Leave them strictly to pixel coordinates.

Another important aspect regarding coordinates on the Spectrum is that the graph in your picture is, well, also misleading. While you could set up an arbitrary origin point in your code (and, in fact, the BASIC PLOT routine does just that), the easiest and most natural way is to pin it to the top left corner. This way, increasing an address in the display file will also naturally increase the coordinates.

0 x

Every man should plant a tree, build a house, and write a ZX Spectrum game.

I never really bothered with any ROM routines. I just checked my commit history, and the first thing I wrote before the initial commit was a table-based level renderer.

It was a little different because Nirvana has a well-optimised character print routine. In that respect it was a little like R-Tape’s “call but don't worry about yet” idea. But having the source accessible actually encouraged me to pore over the code endlessly, until I was able to understand it well enough to write my own specialised adaptations.

I gave some thought to how I wanted to store level data compactly, and being a db programmer in real life it was interesting to Approach it that way. I ended up with some kind of almost relational structure that stored characters and multicolour attributes in their own tables, and composed combinations of those plus coordinates into another table, then added another table referencing a set of those records for each level.

It’s still serving me well now. I even extended it other day in a new project to allow the data to be split up across RAM banks.