SUB <name> as interrupt
stuff
end sub

would be pretty awesome.

A clever compiler could follow this as a code entry point separate from the main thread and assume any variables or functions called would actually be used.

A really clever compiler would explain that PAUSE was a bad idea. As is HALT in any ASM chained - because it would have disabled interrupts and re-enabled them at the end.

Hi,

I've been working very hard in fixing almost 10 obscure bugs in the -O2 and -O3 options. And they finally seems to be fixed. Apenao's game compiles with -O3 flawlessly and plays well (obviously, -O3 includes -O2 optimizations); but I need more testing. So anyone who has programs to test both -O2 and -O3, and check if it compiles and behaves as it does with no optimization at all.

If everything works ok, I expect the compiler will behave more intelligently than ever before. It's been ultra-hard hock: :roll: but I hope it's worth the hassle.
You can download .zip or .tag.gz 1.2.5 files, or the MSI windows install: <!-- m --><a class="postlink" href="http://www.boriel.com/files/zxb/zxbasic-1.2.5r1513.msi">http://www.boriel.com/files/zxb/zxbasic-1.2.5r1513.msi</a><!-- m -->

This is the final version, unless I /really/ have to mess with it more.

MK III might be better for people that want more time between sprite updates to do things - but they might get flickery sprites. This version is quite a bit slower, because after a halt to sync to the screen it waits for the screen to be drawn, and then plays with the sprites. This is a hold of about 1.5 frames per update doing nothing at all.

A clever programmer could probably steal some of the "wait for the screen to draw" time for their own purposes, if they had code that ran in fixed time.

On the plus side, this version is rock solid flicker free. Which was the point of the exercise, after all.

NOTE: There's an addition to the original useage. It has testing code built into the functions so you shouldn't be able to break them. When you are happy that the program runs fine, put #DEFINE FINAL_CODE into the program early on, and it will remove the boundary checking code. (and thus be a little bit smaller).

So... if I was crazy and wanted to implement an IM2 routine.... how do you think I should do it?

Most of my attempts to put the 257 byte data block in memory have failed spectacularly. I think using ORG in an asm statement tends to upset the compiler; but the thing about setting up interrupts is we NEED to put a 257 byte vector table into a very very specific location in memory, and then need to ALSO have the actual interrupt service routine in the specific place that the vector table points to.

*ponder*

I suppose we could use DIM variable @address to force the issue with an array?

On the whole though, this fixed location code isn't really supported by the compiler at this time. How could we work around it?

Okay, reduced the flicker quite a bit more.

Sadly, because it's erase all four sprites and then redraws all sprites, different sprites start to flicker at different points.

If using 4 sprites:
Sprite 0 starts to flicker at above (pixel) line 10
And every other sprite at about 8 lines further down, per sprite.

If using 3 sprites
Sprites 0 is stable
Sprite 1 flickers above row 6
Sprite 3 starts to flicker at above line 16.

If using 2 sprites
Everything is stable.

I assume this is why the mojon's demonstrations only use 2 sprites...

I can't see any more speed optimizations (and right now it probably completes a redraw cycle in less than half the time of the original). There are probably some left, and no doubt Boriel will spot them immediately because he's a genius. However, right now I'm looking at changing /how/ it works. Things like not redrawing a sprite if it hasn't moved, and rather than erase all sprites and then draw all sprites, perhaps go for an erase-buffer-draw routine that does it on a per-sprite basis; limiting the time in which flicker can hit to areas of the screen.

The only alternative to that is to use a back-buffer screen; and that's a LOT of memory.

So right now, it's perfectly useable, if you think about where your sprites are going to go on the screen. The more sprites you have, the more careful you have to be - and keep the later numbered sprites away from the top of the screen!

So, here's how it stands right now (with a tweaked version of Apenao's demo program):

I'm getting an error in the code "illegal character _ at line xxx"

And there isn't one in line xxx.

I suspect that this line number comes from the assembler, and it's a line number based on the code stripped of comments and white space perhaps?

I've noticed that it's sometimes hard to pin down the correct line number for errors before.

I've never used it at all; but I hear that it's a nice code control system.

How does one get going then?

Do you use windows, or linux?

I've made quite a few changes to the actual FourSpriter code. I have made it significantly shorter, and not a small amount faster in execution, using tricks like LDI to copy directly from (HL) to (DE) as opposed to copying into and out of the A register. I removed at least one redundant section of code that was identical with another one - redirecting calls took care of that. There are also places that use bafflingly long code to do something simple. For example:

I was updating fourspriter to use SUBs as opposed to gotos. Probably slower, but a little cleaner on the interface to the user.

Anyway, as it stands the main program:

Calls initialize for the first sprite
which calls a dummy "data" routine (which is really just for asm. The first line is return. It only calls it to make sure it's not peephole optimized out)
Comes back to main
calls coords for the first sprite
comes back to main
calls initialize for the second sprite
which calls the dummy data routine again......

and then it goes wrong. It never comes back from this data routine this second time, even though it should return immediately. In fact, it restarts the main program again. Over and over - and then after a few cycles, crashes.


I confirmed the code does the same thing with 1.23 and 1.22; and I didn't think they had the stack bugs, so it could be something I'm doing wrong, I suppose. I can't really see what could go wrong with "return" being the only statement, though.

The code is a bit complex, and is unfinished; but hopefully you can see where I'm going. It has testing PRINTs in it. Just copy and paste and see if it behaves the same way for you.

ZXB allows you to do stuff that's pretty crazy.

I had a fancy cls routine - that didn't actually clear the screen, just ran a attribute bar over the screen, and then of course you do a CLS from basic afterwards. The effect is the same, but it looks cool.

It wouldn't compile right - the call to the ZX ROM sound routine kept corrupting things. Probably messing with IX and IY registers in naughty ways.

Then it occurred to me.... just compile a beep into the middle. :-)

Look: