Started by opqa, 19:16, 25 October 14
0 Members and 1 Guest are viewing this topic.
QuoteThis version only works in CPC6128 (sorry)
Quote from: opqa on 19:16, 25 October 14litwr's Xlife-8 for the Commodore/+4
Quote from: litwr on 18:32, 27 October 14It is not true. Xlife-8 is multiplatform. One of its major port is Amstrad CPC.
Quote from: litwr on 18:32, 27 October 14However it is a bit sad that it doesn't allow to use directly the big pattern library of Xlife-8. This makes the play more difficult.
Quote from: litwr on 18:32, 27 October 14I also missed the sum of cells and the rules indication. I hope they will be added.
Quote from: litwr on 18:32, 27 October 14IMHO to show the dead cells should be the last options with C-command. It is also possible to add the fifth color mode which shows the only changed cells like at Xlife-32/64.
Quote from: litwr on 18:32, 27 October 14Do you plan to publish Yagol's sources?
Quote from: MacDeath on 14:54, 27 October 14I fail to understand how it goes from 50hz to 50.20 hz with one less line...Not sure CPC is supposed to work that way : the video circuit stays at its 50hz (or 25Hz if you want) and the pixels displayed are constant in size and height...You just tell the video to display less lines and it just adjusts the border. but on CPC you don't magnify the pixels to fill a fixed surface on screen, just that the pxiels ratio changes depending on Video mode used, not screen resolution set.When a CPC displays a Spectrum-like 256x192... you just get a freaking huge border, not those 256x192 filling the same space on screen as the 320x200 and so on.I understand that this software uses vertical scrolling and hereby manages more lines than displayed... still fail to see how it can impact the CRTC-Gate array video circuit...
Quote from: opqa on 23:42, 27 October 14it is one of the defects of the CPC design, a lot of Video RAM to manage but a rather slow processor to do it without extra hardware help.
Quote from: opqa on 23:42, 27 October 14I'm still thinking about which will be the "main" load format for the program. I could adopt Xlife-8 one but I'm also tempted to add support to read directly the RLE format for life patterns which is widely used over the internet, of course supporting the two of them would be great but I have to prioritize... In order to save the maximum possible disk space it would also be great to add the possibility to store several patterns over the same file, so when a user selects a multi-pattern file the program would scan it and offert the option to select which one to open. This would save a lot of disk space because with the DATA and SYSTEM formats each file takes a minimum of 512 bytes of disk space (or was it 1K?) no matter how much it really occupies the data inside.
Quote from: opqa on 23:42, 27 October 14The (total) sum of live cells is not something that can easily be added, I would have to insert some extra code in the core of the algorithm to keep track of this count thereby slowing it down a bit. I'm not sure whether it is worth to do so. If this is an important parameter it could be added an option to count them while in paused state.
Quote from: opqa on 23:42, 27 October 14About the rules, at this moment they are fixed to these of the classical Conway game, I would like to add support to change them in the future but this is not among my first priorities.
Quote from: opqa on 11:18, 28 October 14To complement, you may like to know that in the CPC firmware there is provision to increase this frequency to 60 Hz, which suits the NTCS standard. There is one bridge in the board for this setting, the firmware detects its state when it boots and re-programs the CRTC to match the selected frequency (either 50(.08)Hz or 60(.someting)Hz). In real practice I believe this wasn't used as long as the computer came with its own monitor, but I'm not sure, maybe in the USA market they came configured for 60Hz.
Quote from: TFM on 19:42, 29 October 14I can confirm this. I brought my 6128 to the USA and used an original CTM644 (made for the US market). The CPC has a switch (LK 4) to select 50 or 60 Hz. And both do run well with the US CTM644 (see my thread about it). Sadly after six years of searching for a US CTM644 it worked only six weeks then if went dead. So I can't make further tests.
Quote from: TFM on 22:42, 29 October 14No speed increase, the CPU runs still at 4 MHz. In contrast, when using 60 Hz the CPU has more work to do
Quote from: litwr on 19:36, 29 October 14Where is the problem? Yagol uses table defined by rules, it only needs the 256 bytes table generator. This table format is the same (?) as in updated Xlife-8. I attached this table for the Conway's rules. If it is the same I may attach the subroutine-generator for it. The different rules - the different life and the different games.
Quote from: litwr on 19:36, 29 October 14My point is to provide a converter from the common formats (RLE, L, ...) to an 8 bit format. It is provided - its name is lifeconv.
Quote2) the file size may be bigger up to 2-3 times than the binary equivalent;
Quote5) RLE doesn't allow to make a file container with the multiple patterns,
Quote6) it doesn't provide the bounding box size for the pattern.
Quote from: opqa on 15:21, 30 October 14Shouldn't a regular CTM664 support 60Hz just by adjusting it's VHOLD pot. at the back? I thought it could.
Quote from: opqa on 15:18, 30 October 14my CPC development time has dropped near to zero
Quote from: opqa on 15:18, 30 October 14I know, this is a good point of your format, but having to (necessarily) use a command-line converter can also be a barrier. I would be great if lifeconv could be compiled also for the CPC and used from there.
Quote from: opqa on 15:18, 30 October 14I don't see it, it is somewhat compressed (RLE is a basic kind of compression), and aside from some little overhead it's storage density could be at worst around 1 byte per live cell (normally it should be quite less due to the RLE compression). IIRC xlife-8 format needs two bytes per cell and it doesn't implement any compression.
Quote from: opqa on 15:18, 30 October 14As it is just plain text my plan was to simply concatenate files, which can be done from any command line or text editor. RLE has rather defined text separators to mark when a pattern starts and it has even some provision to assign it a name, so I believe that it could be done, maybe not easy, but feasible.
Quote from: opqa on 15:18, 30 October 14I believe that it does, at the beginning in the form "x=10,y=15".
Quote from: opqa on 15:18, 30 October 14But anyhow back to the beginning, at this moment I have no time to add any more features, I shouldn't even be writing this, so feel free to add support for xlife-8 format if you want, it shouldn't be hard. The file "loadpattern.asm" first loads the file from the disc to the &4000- memory area, then there is small routine that copy the loaded image into the video region &c000 reordering the lines (the images in the disc have a linear layout). Just replace this routine for a xlife-8 parser that "paints" the live cells in the memory area with ink 10 and you're done.
Quote from: opqa on 15:18, 30 October 14Just replace this routine for a xlife-8 parser
Quote from: litwr on 16:33, 31 October 14The binary format doesn't require parser, just loader.
Quote from: litwr on 16:33, 31 October 14BTW if Yagol will be stopped then the current Xlife for Commodore will be the fastest complete GoL application.
Quote from: opqa on 15:33, 01 November 14I'm not sure what you mean with this, Is it that you have managed to make the current Commodore version faster than Yagol?
Quote from: litwr on 21:27, 01 November 14I mean that the current state of Yagol is the demo level only. It is impossible to do full check with it. No pattern loader for the common formats or the converter, no sum of cells calculation, no rules support, ... So it requires one or two steps that make it the true application. So technically Xlife-8 for Commodore is still the fastest GoL application. Yagol looks like a very fast demo program only.
Quote from: opqa on 23:37, 01 November 14Probably about in one month I will have some time again.
Quote from: opqa on 23:37, 01 November 14Meanwhile there is no conversion program, but there are ways
Quote from: TFM on 04:56, 02 November 14don't you overdo it a bit here?
Page created in 0.206 seconds with 53 queries.