Spectrum Computing

Following like a madman here too, this is fascinating. Bit more of a write-up of what optimisations you make as you make them (with sources so we can follow along) would be gratefully received by the whole community, I'm sure.

I agree, more detailed info on what gets changed is always a bonus, however, I tend to program in such a haphazard way, that its sometimes tricky. For instance, I've just spotted a way that I can save 1 byte. It would involve reversing all of the data. That may seem like a ridiculous thing to do to save 1 byte, however, the smaller it gets, the more significant that 1 byte becomes.

I've also saved an obvious byte in the main BIT placing routine, which is called to place every BIT of the sprite, so every pass is now -4TS too.

I am actively tidying up the source as I go. I've just actually found a neat optimisation thats saved another byte, so we're down to 595 bytes now.

The manager in me is saying "quit mucking around and write the chess logic".
The programmer in me is saying "go for 512 bytes!"

Actually I have been increasingly frequent thoughts regarding 512 myself. I’ve no idea how I might achieve that though as we’re at 593, which is 81 bytes too big!

arkannoyed wrote: ↑Sun Jul 15, 2018 9:06 am I’ve no idea how I might achieve that though as we’re at 593, which is 81 bytes too big!

Reduce the pieces’ dimensions.

The one thing sacred is stayed true to the original design, so though that may save a few bytes, it’s not ethical! Also, the structure of the data means that the pieces would have to reduce to max 16 bits wide (from 22) and the height be probably 1/3rd. That would make them a bit tiddly looking really. Part of the challenge is maintaining the basic footprint of the pieces whilst reducing their size and the code to decipher and print them. I do have many tweeks and ideas still to implement, so the size should steadily reduce. 512 bytes might be possible if I were to not include the initialise the board routine in the overall size, which knocks 40 bytes off straight away. If the data is to get smaller, it’s going to have to do far more algorithm based graphics building, just maybe using the line number and a component to form a line of graphics data. The Standard line model already does that, with 3 bits for length, 4 bits of Pixel data, then puts it all together. Some of the data lines are also constructed in various ways from several components. So far there are 5 distinct line types of 1,1,2,2 or 5 bytes. 5 bytes are obviously the longest and more complex lines, but there are actually only 22 of those anyway. There are patterns even in those which could allow further data reduction, but at the expense of more program code, so currently no point pursuing that avenue.

A lot of re-organising to achieve a bit more size reduction. Also a neat way to store the pieces vector table position, which saved 5 bytes alone.

Now at 588 bytes

Still plenty to do and I really am making good progress on commenting the source at last!

Some decent changes this morning, and now at 586 bytes

I'm now struggling to find any further improvements

If I'm going to achieve that 512 bytes magic number, (586 -40 bytes (initialise board routine and data) = 546 - 512 =34 bytes)

Then I still need to save a further 34 bytes, which is looking rather far away.

I think you've done a great job so far and maybe it's time to start adding a decent (also a memory-efficient) chess engine.
I guess the optimization of board routines is possible later if you find more space for that.

Optimization has to always be done keeping in mind the fact that somehow, some kind of GUI will have to be integrated into it at some point. Once I achieve the best balance of speed and size (hopefully very small!) the routine will then start to grow in size again incorporating several elements such as piece and square selection. once that all works as efficiently as it can, then it will be time to add some kind of logic and error checking into the mix. Fortunately, this iteration seems to allow a lot more flexibility to add new features without it getting all grumpy about it. Thats more by luck than design!
I still intend another redesign of the graphics, as I think there are a few areas that might benefit from alterations, helping a more crowded board appear less cluttered. Certain formations of graphics print faster than others, and can be encoded in less space. The bases of the pieces are all common, but look a little heavy. Shaving just 1 line off them could save 5 bytes! Not huge, but maybe significant in the end.

The nice thing about it is that it all feels very stable as it is, not using registers that it shouldn't, and not creating any huge buffers in memory. Its so efficient now that its even almost relocatable.

..And now 585 bytes!

Well, I've put a good few hours into trying to shave off more bytes in the past 2 weeks, but despite several useful optimisations and slight speed improvements, I've only managed to save one lonesome byte!

I'm working on several areas to try and just squeeze out anything that's wasted, but its become almost impossible.

Now at 584 bytes

Well, maybe it's time to think about installing a engine.
That would be a complete masterpiece...

Not yet, I've still to lose -33 bytes. If I put the board initialising routine and data aside, that loses -39 bytes, so 584 - 39 =545

545 - 33 = 512 bytes!

Thats the goal!

This is a worthy goal.
You obviously intended to overthrow the famous zx81 1k chess in terms of optimization and far better board, ofc.

Absolutely! I'm pretty sure ZX81 chess was 672 bytes actually, but though it displays little more than a bunch of letters representing the pieces, it does do a decent job at playing the game. I've studies the Disassembly at length for pointers!

If I can achieve something in 1k I'd be quite happy.

Getting nearer!

With some flashes of brilliance (maybe overstating a bit!) I've managed to quite easily save another 2 bytes that have long been annoying me!

Only 31 to go! Now at 582 bytes

Its all about the loops!

Saved another 2 bytes by collecting bytes recursively via a loop. Looks messy, but what the hell!

Now at 580 bytes

Just when you though it was safe to look away.......another 4 bytes disappear!!! And a little bonus one too with a 2 byte jump

Now only 575 bytes

Proof that it does still work!

...And with some cheeky byte sharing I've saved another byte

574 now!

arkannoyed wrote: ↑Thu Feb 07, 2019 9:11 am Proof that it does still work!

Sometimes you get so wrapped up in the coding that you fail to see the bigger picture. Can you spot what's wrong here

White queen and king starting at wrong position.

I know, work in progress, it will be sorted!!

Fridays are always good for optimizing code!

Now 568 bytes

Finally re-written the other main line building algorithm and managed to save another 4 valuable bytes.

Possibly uninteresting, but now down to 564 bytes

Technically now only -13 to go!