News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Xlife-8 for CPC6128 is released

Started by litwr, 20:01, 09 August 14

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

litwr

Xlife-8 is a port of 32/64-bit cellular automaton (artificial life) laboratory program.  Now it has features which allow conveniently to create new life forms.  Of course, it supports the famous Conway's game of life.  It is maybe the fastest for 8-bit computers.  It has open sources.  The disk images, sources, library of patterns, screenshots, links to youtube's videos are at http://litwr2.atspace.eu/xlife/xlife4cpc.html - it at the free hosting...




SyX

Jejeje, i remember well the first time that i saw in a CPC magazine the "Game of Life", i was a child and did not understand anything and the use of words like IA in the article didn't help too much, jajaja... but those hipnotic patterns always looked really great  :)

Bryce

Very cool, these type of simulations were a favourite of mine too (along with Mandelbrot graphics programs).

Bryce.

litwr

Quote from: SyX on 21:49, 11 August 14
... but those hipnotic patterns always looked really great  :)
Is it time to create the new artificial life?  ;) IMHO the natural one is only a big disappointment.  To make things easier I've just converted all library of patterns to Amstrad CPC format.

SyX

@litwr: I have been looking your +4 programs in plus4world :)

PS: In case you want to make the CPC more russian friendly or at least using cyrillic chars, the CPC font (in mode 2 format,  8 bytes/char) is in the offset $3800 of the firmware rom (OS464, OS664 or OS6128), more exactly $3A08 for upper case and $3B08 for lower case.

litwr

Quote from: SyX on 13:23, 13 August 14
@litwr: I have been looking your +4 programs in plus4world :)
Thank you for your attention to my humble works.  Commodore had unique technologies but used them a bit odd.  They had 6502 (3Mhz even at 1981), sid, vic-2, 1MB disk drive for DD (!) diskettes, ... Plus/4 has many interesting features: the very flexible raster control allows to use more than 40KB RAM as video memory (320x496 121 color picture), the fastest 8-bit CPU at the "super turbo" mode (2.21 MHz), fast RS-232 (19200 baud is the standard speed), ... 

Quote from: SyX on 13:23, 13 August 14
PS: In case you want to make the CPC more russian friendly or at least using cyrillic chars, the CPC font (in mode 2 format,  8 bytes/char) is in the offset $3800 of the firmware rom (OS464, OS664 or OS6128), more exactly $3A08 for upper case and $3B08 for lower case.
I don't see any problem with the localization of CPC.  Even  Basic supports the font change! 

Sykobee (Briggsy)

Nice videos - one thing I found a bit odd was the use of MODE 0 sized pixels (i.e., fat pixels) for something that would be better shown as square pixels ...

dcdrac

I recall typing in a mandlebrot generator called Dragon think it was in ACU

litwr

Quote from: Sykobee (Briggsy) on 21:39, 14 August 14
Nice videos - one thing I found a bit odd was the use of MODE 0 sized pixels (i.e., fat pixels) for something that would be better shown as square pixels ...
Thanks.  Xlife-8 uses two scales 2:1 (zoom out) and 8:8 (zoom in).  It is easy to replace 2:1 (mode 0) to 1:1 (mode 1).  Xlife-8 in the mode 1 will use only half of the screen - will this be better?  It will also be limited to 4 colors - it uses up to 11 colors now.   Mode 1 pixels will also be probably too small to edit.  Mode 1 gives one advantage - it gives about 3% speed gain because Xlife-8 uses the split screen at zoom out mode -  the status line is always at mode 1.
Quote from: dcdrac on 09:39, 18 August 14
I recall typing in a mandlebrot generator called Dragon think it was in ACU
GoL is a bit other thing.  It is the pure discrete mathematics.  ;)

opqa

#9
Hi litwr, first of all, congratulations, your program is awesome and full of features.


Now, about the youtube video, when you say at the beginning that the Amstrad CPC is slower than the Commodore due to the video system... Well, I know that this wasn't your intention, but I personally took it as a challenge, and this is the result:


This two videos are from a first version which only worked in monochrome mode:
Amstrad CPC - Glider Gun - YouTube
Amstrad CPC - Acorn - YouTube

And this one is from an improved version, slightly faster and with colors!
Amstrad CPC - Acorn coloured - YouTube


I haven't made thorough tests, but I've the impression that this code outperforms your CPC version, and probably the Commodore one. No extra features though, only works in mode 0 and there is no possibility to add zoomed mode in its current state (it should be possible on the CPC6128 using bank switching at the cost of some speed in mode 0 and quite some more in zoomed mode).


Also it has no interactivity at all neither a proper loader to run on real hardware (although I believe that this two could be added without penalty in speed). It can be assembled and run directly on WinAPE (just open main.asm and click Assemble - Run).


The code is extensively commented, feel free to study and use it as you wish.


PS: I edit just to add two more videos, I've tested the same patern you used to make the Amtrad CPC vs. Commodore benchmark, it performs at approximately 5.25 gen/sec while showing  the evolution (this code isn't faster without showing it). So the conclusion is that yes, it definetly outperforms the Commodore. :P

Xlife-8 benchmark pattern running on Amstrad CPC - YouTube

Xlife-8 benchmark pattern running on Amstrad CPC (coloured version) - YouTube

ZbyniuR

In STARS, TREK is better than WARS.

litwr

#11
Hi, opqa!  Thank you very much for your results - I like to see any GoL implementation.  ;)
Quote from: opqa on 14:33, 10 September 14
Now, about the youtube video, when you say at the beginning that the Amstrad CPC is slower than the Commodore due to the video system... Well, I know that this wasn't your intention, but I personally took it as a challenge, and this is the result:
Thank you!  However there is no any challenge.  I am performing my personal "crusade" to test three completely different architectures of the home computers released at 1984 (BTW I am also a big fan of the great writer George Orwell  :D ).  You cited my phrase but it has context - Xlife-8.  ;) My results show that CPC6128 at the 2:1 scale mode is slightly slower (about 16%) and at the 8:8 scale is slightly faster (about 2%). So if you want to prove you point you should improve CPC6128 xlife algorithm realization.  ;)

Quote from: opqa on 14:33, 10 September 14
This two videos are from a first version which only worked in monochrome mode:
Nice videos.   :)  They show that your program algorithm is several times faster than Xlife's for the medium sized pattern.  I estimate it up to 35 gen/sec.  However for the small patterns Xlife may be much faster and it may handle bigger patterns.  I am not sure about the last words.  Is your program capable to handle up to 128x256 grid?  Xlife-8 is limited to 160x192 grid.

Quote from: opqa on 14:33, 10 September 14
And this one is from an improved version, slightly faster and with colors!

Wow!  Very nice!  :) Xlife-8 may also show such mode but Commodore+4 has only 4 free colors and I don't plan to make the special version for CPC.

Quote from: opqa on 14:33, 10 September 14
The code is extensively commented, feel free to study and use it as you wish.

Thank you for the sources.  ;)  I ran your example with ep128emu under Linux. Do you want me to convert them for Commodore +4?  ;) I want to find time for this...   :(

Quote from: opqa on 14:33, 10 September 14
PS: I edit just to add two more videos, I've tested the same patern you used to make the Amtrad CPC vs. Commodore benchmark, it performs at approximately 5.25 gen/sec while showing  the evolution (this code isn't faster without showing it). So the conclusion is that yes, it definetly outperforms the Commodore. :P

No.  :D The conclusion only is that your algorithm with this pattern is about 4 times faster than Xlife-8 algorithm.  ;) BTW I am preparing the update for Xlife-8...  I know how to accelerate its algorithm up to about 25% (it used by Xlife-32/64 which supports hashlife too) but I doubt that it will be realized - no time again. 

Commodore +4 vs Amstrad CPC6128.  IMHO they are very different but perfectly match each other.  CPC is slightly faster with normal 40x25 screen but +4 is much faster at the screen off mode.  CPC has more free colors but +4 has more total number of colors.  CPC has faster Basic but +4's Basic gives more memory.  CPC is a very good 8-bit text processor for the monitor system but +4 might be the same for the tv based system. Etc, etc, ... Of course, CPC has happier fate, Commodore gave +4 line up.  :(

litwr

I began to work with the sources.  I have to note that life.bin at the disk image is compiled from a bit different sources. ;) However they are eventually was converted to Pasmo6 assembler format (the result of the conversion is attached below).  BTW, opqa, please give a name to your program.  I had to use a temporary one - NBSGOL - Nothing But Speed GoL.  ;D  Is your work linked somehow with amstrife - Conway's Game of Life for CPC—very fast+many features coming! New: QuadLife! ?  It looks a bit similar.
It is not easy to test a new pattern with this very fast GoL.  I've added the several new patterns and the countdown counter to stop the evolution and to check the time of the execution.
The results are shocking - the speed is at the edge of impossible.  :o I got the next results for the speed of the evolution:
glider - 862 (139)
beacon - 1524 (268)
toad - 560 (294)
blinker - 819 (310)
lwss - 390 (151)
2blinkers - 420 (267)
benchmark - 5.5 (1.33)
The number at the brackets are for Xlife-8.  So NBSGOL at CPC6129 is faster than Xlife-8 at C+4 at the 1.57 times minimum and at the 6.2 times maximum.  The attached disk contains all the mentioned patterns ready for the execution.
NBSGOL supports even slightly larger cell grid than Xlife-8 128x256=32768 vs 160x192=30720!
However NBSGOL can only handle up to 4096 living cells.  This doesn't allow to use the agar patterns (zebra, onion rings, venetian blinds, ...) and the other big pattens.  Xlife-8 may handle any number of the living cells up to 30720.  So Xlife-8 is still the fastest (?) for the big patterns.  :P
I am going to add several ideas to the next Xlife-8 release: to use 3 bits to keep number of neighbors, ...  Thanks. :) BTW I hope that opqa's life will get the proper title and improvements.  ;)

opqa

#13

Hi litwr, I didn't see your answer three days ago, sorry. Much information and many questions  :)


About the name, well, it hasn't got any because it's still a work in progress, I still don't consider it a program by its own right. At first I even didn't think I would finish it but surprisingly I'm still working on it. At this moment of development I've made it interrupt-compatible and I'm trying to add some interactivity and an information panel.


About amstrife, no, it's not related to this program in any way. I started it as a challenge as I told you. Of course feel free to port the code to any other architecture or use it in your own programs. I would love to check whether this algorithm can run faster on the Commodore or not. ;D
As you may have noticed in the comments, this algorithm isn't mine, I took it from here:
http://www.nondot.org/sabre/Mirrored/GraphicsProgrammingBlackBook/gpbb18.pdf


About the limitations of the algorithm:


- Effectively it is limited to 128x256 grid in its current form, by making use of RAM banking it MIGHT be possible to double this size, but it would slow down a lot, and it will not be a trivial change.


- It's limited to work in mode-0, no zoomed mode is possible. As you may have noticed the video RAM is not separated from the grid state storage/calculation. It'd be perfectly possible to separate it, but of course it would lose speed and would need more memory.


- About the "living cells" limitation, well... yes and no.


The algorithm in its current state is able to handle up to 4096 of what I call ACP's (active cell pairs), this is, cell pairs that are changing.


The "static" debris isn't included in this limitation (neither processed by the algorithm in any way, this is its strong point and what it makes it so fast).


Again, by using RAM paging, the maximum size for the ACP list could be doubled (at the cost of some speed), this time the changes needed in the code are simple and small. But I believe that it's not worth doing this because with it's current size is OK for most patterns, and anyhow, when it gets close to completion the speed is no longer so good and can't compete with other algorithms.


However, in the "version" you have got, there is effectively a "living cells" limitation in the initial pattern. But this is just because of the way the initialization routine I wrote at first works.
It just adds all the starting "living cell pairs" to the ACP list. Although this method works and is relatively fast, it is far from being space-optimal, and can cause ACP completion on big starting patterns.


But the good news are that I've already solved this limitation by writing another initialization routine that calculates a complete first generation in a slow but memory-safe way, thereby generating a "normal" ACP list for the second generation and subsequents. You can find it in the attached file (please note that this version isn't the interrupt-compatible I told you before, this code is still not mature to be released).


And that's all... Good work with the benchmarks by the way. I know it's not easy to add patterns to the program in its actual state, they must be coded in CPC-screen format and in a non-standard resolution, and there are still no available tools making this work properly. I should also solve this in future versions, maybe making it compatible with Xlife8 pattern format. Is it complicated/documented anywhere?

litwr

#14
Sorry, your program has title - lifecolour!  :o Sorry, again...
Thank you for your explanation of ACP.  Lifecolour has very good algorithm.   :-* :D Xlife used one dated 1989.
Quote from: opqa on 23:31, 23 September 14
But the good news are that I've already solved this limitation by writing another initialization routine that calculates a complete first generation in a slow but memory-safe way, thereby generating a "normal" ACP list for the second generation and subsequents. You can find it in the attached file (please note that this version isn't the interrupt-compatible I told you before, this code is still not mature to be released).
Did you try it with agar patterns like VenetianBlinds provided with the converted to Pasmo Lifecolour's sources?  It requires the support for 16384 living cells.

Quote from: opqa on 23:31, 23 September 14
I should also solve this in future versions, maybe making it compatible with Xlife8 pattern format. Is it complicated/documented anywhere?
Of course, see manpage.  It is just a (x,y)-pair for the every cell.

opqa

#15
Quote from: litwrSorry, your program has title - lifecolour!  :o  Sorry, again...

No, don't worry, this is not a distinctive name, it's just that I needed to name the file somewhat. :D


I'm not very original with names, if I have to name it now... let's say it'll be called YaGoLi4CPC (Yet another Game of Life implementation for CPC, as it's the third recently published in the forum in less than a year).
Quote from: litwr
Did you try it with agar patterns like VenetianBlinds provided with the converted to Pasmo Lifecolour's
sources?  It requires the support for 16384 living cells.

Yes, but not this one though. I've just tried it right now and no luck, this pattern has many active cells even from the beginning, so it's not just an initialization problem. I think that I'll make a version with the needed changes to double the size of the ACP list.* But it'll not perform fast at all.


* Now way, I've just rechecked it and even with double-sized ACP list it won't fit.

But to take an idea about what I said about ACP completeness (with its current size) and speed, you can take a look at the pattern "pacomix" (monochrome and double buffered) and "pacomixc" (colored without DB) included in this dsk:
http://amstrad.es/forum/download/file.php?id=2912
(It has been generated from the same sources I provided before (lifecoulour03.dsk))


It is a stable agar pattern composed of several 2x2 squares filling the whole area with a "virus" at the center (more or less).
At first is very fast, but as soon as the ACP begins to fill (and it reaches about 80% of its current size) the speed drops around 1 gen/s or even less. In those situations Amstrife for instance (and probably Xlife too) would be significantly faster.

litwr

#16
Quote from: opqa on 21:16, 24 September 14
I'm not very original with names, if I have to name it now... let's say it'll be called YaGoLi4CPC (Yet another Game of Life implementation for CPC, as it's the third recently published in the forum in less than a year).
Is it your final word?  :o IMHO `lifecolour' is much better.  ;)

Quote from: opqa on 21:16, 24 September 14
*Now way, I've just rechecked it and even with double-sized ACP list it won't fit.
This pattern uses all the cells.  ;D So only Xlife (?) may handle it at the 8 bit world.  ;)  IMHO Lifecolour should not crash in the similar cases.  It will be much better to get a message about too big pattern to handle.  I attached a disk with patterns for the Seeds rules.  One pattern is a glider - it works fine with speed about 529 gen/sec - Xlife may reach only 236.  The second pattern creates the chaotic image.  Lifecolors becomes slower than Xlife-8 after 100 generations and then crashes.
I used your older sources - lifecolours02.

Quote from: opqa on 21:16, 24 September 14
But to take an idea about what I said about ACP completeness (with its current size) and speed, you can take a look at the pattern "pacomix" (monochrome and double buffered) and "pacomixc" (colored without DB) included in this dsk:
I tried it.  Thanks.  :) Lifecolour is very good for some rules (ladders will be very good)... I plan to test it with replicators rules.

I have the several suggestions about Lifecolour features:
1) to assign a key to roll the pseudocolor modes - they are 8 natural possibilities.  Xlife-32/64 uses 5 such modes (they are rolled by E-command), Xlife-8 uses only 2;
2) to assign a key to randomize a region;
3) to ask a file to load at the start of the program.  To rotate (to exchange x and y coordinates) the patterns with width bigger than 128 - it is easy - Xlife-8 format begins with x/y-max pair.
4) to assign a key to make a benchmark;
5) to assign a key to run/stop;
6) to assign a key to show the information screen (the cells count, the generation number, ...);
7) to assign a key for one step.

It will be great to see more advanced rules support, e.g. Brian's brain... I wanted to realize its support for Xlife-8 (it is possible) but...
BTW you work inspires me to speed up Xlife-8.  The current unfinished version is 25-100% faster than the released one.

opqa

#17
Quote from: litwr on 12:11, 27 September 14
Is it your final word?  :o IMHO `lifecolour' is much better.  ;) 
Well... almost... let's drop the last 'i', it'll be called "YaGol4CPC", but one can write just "Yagol" for short. I think 'lifecolour' it's too generic and also misleading, IMO having colors is not the main feature of the program. I just called this version of the sources that way to differentiate them form the original only-monochrome ones.

Quote from: litwrI attached a disk with patterns for the Seeds rules.  One pattern is a glider - it works fine with speed about 529 gen/sec - Xlife may reach only 236.  The second pattern creates the chaotic image.  Lifecolors becomes slower than Xlife-8 after 100 generations and then crashes.I used your older sources - lifecolours02.

Jesus!, that's probably the worst set of rules Yagol can handle. Not only it tends to grow indefinitely but also every live cell is also an active cell!
:o


Anyhow, I'm attaching the development version I'm working on with this rules and pattern and with double sized ACP list.  Of course even with double size this pattern finally fills the ACP anyway, but it lasts quite longer.
As I said doubling the ACP size using RAM paging has some penalty in speed (not much), but if the algorithm has to deal with lots of active cells is going to get too slow anyway, so I believe that for a hipotetical final version it'd be better to use "simple sized" ACP list to improve speed in those situations where the algorithm is good at.


Quote from: litwr
IMHO Lifecolour should not crash in the similar cases.  It will be much better to get a message about too big pattern to handle.
I have the several suggestions about Lifecolour features:
1) to assign a key to roll the pseudocolor modes - they are 8 natural possibilities.  Xlife-32/64 uses 5 such modes (they are rolled by E-command), Xlife-8 uses only 2;
2) to assign a key to randomize a region;
3) to ask a file to load at the start of the program.  To rotate (to exchange x and y coordinates) the patterns with width bigger than 128 - it is easy - Xlife-8 format begins with x/y-max pair.
4) to assign a key to make a benchmark;
5) to assign a key to run/stop;
6) to assign a key to show the information screen (the cells count, the generation number, ...);
7) to assign a key for one step.


Yes, yes I know... Please take in account that this is still a WiP, I wouldn't call it even an alpha. I've already been working in some of those features. In the "development" version attached the program no longer crashes when the ACP is full (instead it detects this condition and hangs). And as you'll notice there is a panel where I plan to print information (gen. number, speed in gen/sec, ACP completion)... an other controls.
At this moment there are only three possible actions, show/hide the panel with ENTER (not RETURN) and, while the panel is being shown, scroll with cursor up & down (nice hardware vertical pixel perfect scroll BTW).


If you happen to take a look at the sources please take in account that most comments are outdated and that some important things have changed since the other versions, main ones are:
- Now ACP list is in bank 2* and cell data in bank 3.
- Phase 1 doesn't use the stack to iterate through ACP any more (this was required to make it interrupt-compatible)
- Phase 2 is still using it though (this is possible because we don't mind if old ACP values get overwritten by an interrupt after they've been read during phase 2)
- As a consequence of the above now Phase1 & Phase2 have now some separated macros for moving along the screen (they use different register pairs for that now)

*Bank4 really, but paged in bank2 area. The real bank2 is reserved for the panel video-RAM.


As soon as I have a version that prints something in the panel, with basic controls, and with a way to load patterns other than re-assembling I will publish it as an alpha in another thread.

litwr

#18
Quote from: opqa on 13:44, 28 September 14
it'll be called "YaGol4CPC"
I will wait for YaGol4Commodore+4" too. ;)

Quote from: opqa on 13:44, 28 September 14
Anyhow, I'm attaching the development version I'm working on with this rules and pattern and with double sized ACP list.  Of course even with double size this pattern finally fills the ACP anyway, but it lasts quite longer.
CPC has a lot of memory.  So it is possible to use 32KB for ACP... But I have the other idea.  We may make the combined release for Amstrad CPC: Xlife will provide the editor, the support for the *extreme* patterns and the several other features, YaGol will provide speed.

Quote from: opqa on 13:44, 28 September 14
And as you'll notice there is a panel where I plan to print information (gen. number, speed in gen/sec, ACP completion)... an other controls.
The idea of the toggled status bar impresses me.  I begin to think about its implementation for Xlife - it may even slightly speed up the Amstrad's port and gives 160x200 grid support.

Quote from: opqa on 13:44, 28 September 14
At this moment there are only three possible actions, show/hide the panel with ENTER (not RETURN) and, while the panel is being shown, scroll with cursor up & down (nice hardware vertical pixel perfect scroll BTW).
It looks very good.   :) Sorry, my knowledge of the CPC's hardware is not too deep.  :( I am only a bit disappointed by the fact that the majority of CPC games are just conversion from Spektrum.  So these games for Commodore 64 look much better, e.g. The Last Ninja, ...

Quote from: opqa on 13:44, 28 September 14
As soon as I have a version that prints something in the panel, with basic controls, and with a way to load patterns other than re-assembling I will publish it as an alpha in another thread.
I hope to have opportunity to use it soon.  ;)

litwr

Opqa made his videos about Yagol private. But his program is really marvelous.  So I have just put a short video which demonstrates Yagol's fantastic speed on youtube -
https://www.youtube.com/watch?v=jqi8gqE9cY4

Powered by SMFPacks Menu Editor Mod