Spectrum Computing

In my opinion, you have some up with something special here, it is impressive immediately, regardless of size. If I could wish for one feature it would be to have a mode whereby you get to see the moves it is considering and rejecting. 1k chess for the ZX-81 does this. It is a fascinating thing to watch.

Possibly a feature that could be optional. That’s actually not very difficult to implement, but could be a long process when a lot of moves are possible. Move generation is completely separate to the display and piece building part.

Afternoon all!

Been a while, but whilst I’ve a few days off I thought I’d try out a couple of ideas. However, as I was refreshing everything in my brain, I managed to save another byte on the display engine. Bit boring maybe, but it is now 503 bytes.

A coming together and shifting about of two other key routines (might) give the possibility of saving one or perhaps two more bytes too. More time tomorrow, so I’ll get my abstract thinking cap on. Sometimes it’s a case of looking at how things work from a different point of view, so as to figure out the clever methods. That’s why humans will always triumph over machines...even a Speccy!!!

I think theres still some mystical wizardry going on here...

Totally agree.
If this great piece of code gets its equally compact chess engine, it will be one of the biggest events in the Spectrum homebrew scene in the last couple of decades.

Very kind of you to say so I’ve been in awe of Alex’s ChessKelet development for a while now. In fact, what he’s achieved way outshines my efforts, but remains a massive inspiration and guiding light for my future developments. The reason I keep on with the squashing of C2k18 is that as I find ways to implement the logic for the playing part, I sometimes have to alter the display code. That sometimes gives rise to new ideas and ways of achieving the same end, thus saving the odd byte here and there. I’m sure the core display engine will creep down towards -500 bytes eventually. Only 3 bytes to go!!!! The more saved there leaves more for the game and gui which has to all cram into -1k.

I'm amazed by what you've achieved here. When the whole finished thing eventually clocks in at less than 1k, you should hold off on releasing it until you've made another 40 odd similarly amazingly small games that can all be loaded at once, with a front end to choose them. By my calculation it might be ready by the year 2100.

2100 is pushing it a bit. Chess has taken since about 1993 to get to where it currently is
I did adapt the routines that draw the chess board (well, the addressing part anyway) to be used as an isometric room builder, with a compressed block printing routine. That would allow for an isometric game in less than 1k.

Quick question that someone might be able to answer for me, as I’m not in the vicinity of a speccy or emulator to test. When calling a routine from basic (rand usr etc) does using the alternative registers set (exx) cause issues upon the RET? Would the always need to be pushed prior to messing with and obviously have interrupts disabled?

The epic program I've just compiled:

DI
EXX
EI
RET

causes a hang on return to basic.

If that helps at all.

Edit:
DI
EXX
Ld hl, bc, de, a with some arbitrary numbers
EXX
EI
RET

Gave me a "c nonsense in basic" but did return

Yes. You need to save HL’ and restore it before returning to BASIC.

Just HL’ ?

Well, IY, too, obviously, since it holds the base address for all the system variables. But as far as prime registers are concerned, yes, just HL’.

No need to worry about iy. But being able to use one of the alternative register pairs for addressing instead of Ix may give the possibility of saving a few bytes.

I only learned about it by accident (just like you did) when I was perfecting my QuickPrint routine. I even investigated why HL′ in particular was important. I just looked at my source and found this informative snippet:

You may write ld hl,10072:exx:ret, this number doesn't change.

Christmas cheer to all!

After almost an entire year of faffing around trying desperately to save an odd byte here and there and failing, I woke up yesterday morning and came up with a Solution to save 4 bytes!!

..so now my little chess thing has now broken the 500 byte milestone.


499 bytes!

I’ll post some .asm soon, as although the bytes saved are actually only in the part that sets the board initially, there have been performance improvements elsewhere over the past year.

Oh dear!! I always seem to have a habit of premature posting when I think I’ve done something good!

Well, actually I’ve saved more than I thought!

Now

497 bytes!

Now I really didn’t expect to save a whopping 6 bytes!!

The board initialise routine is now 26 bytes with 6 bytes of data

arkannoyed wrote: ↑Mon Dec 21, 2020 7:00 pm Oh dear!! I always seem to have a habit of premature posting when I think I’ve done something good!

Well, actually I’ve saved more than I thought!

Now

497 bytes!

Now I really didn’t expect to save a whopping 6 bytes!!

Like I said, you're a wizard and this is witchcraft.
Is there a chance for some compact chess engine in the near future ?

Yes! Development has definitely slowed, but it has continued.

This is the new routine to set the board;

You are now storing the board sideways! That's clever!

Yes, it suddenly occurred to me that it was so much smaller to code, and there is only 8 bytes of date, two of which are an 06, 04 (ld b,04) at the start of a routine, so technically 6 bytes only.