Hi, after some "purge" I made it and the DEB package is installed. However thumbnails are still not presented... I am using XUbuntu 25.10 (6.17 kernel, X11, GeForce RTX5060) with the latest XFCE.
Gnome thumbnails not working in XFCE
Nice. I am also very happy for the linux support, I personally use Linux MX, in my family and friends I install Linux Mint. I also use XnView.
Hi, Piotr! after several weeks of usage I can say, all these formats work!!! Many thanks for support! I personally appreciate hires formats and two VRAMs combinations. I wish you a wonderful summer time! Looking forward to RECOIL 6.4.6 :-) Kind regards Josef
Hi, Piotr! after several weeks of usage I can say, all these formats work!!! Many thanks for support! I personally appreciate hires formats and two VRAMs combinations. I wish you a wonderful summer time! Kind regards Josef
Hi, Piotr! after several weeks of usage I can say, all these fromats work!!! Many thanks for support! I wish you a wonderful summer time! Kind regards Josef
Hi, Piotr! after several weeks of usage I can say, all these fromats work!!! Many thanks for support! I wish you a wonderful summer time! Kind regards Josef
Why do TIME3.!s and OBJ2.!s look better with black paper and white ink? Sorry, I am not sure about it. Moroz told me that according to your reports he immediately repaired and inverted all monochrome pictures. https://zxart.ee/eng/graphics/database/pictureType:monochrome/sortParameter:date/sortOrder:desc/resultsType:zxitem/ PS. I repaired (inverted) my 23-PIC.SCR
SS3> thanks, I also spotted this, but have no time to check ... till now as far as I can remeber, SSx were unsettled years ago, so I started to use SS3 with length of 24580 and SS4 with 24592, expecting that a "higher level" format like SSX will cover screen types and also palette/line changes currently the SimCoupe emulator can produce raw files with 24580 and 24592 bytes as the SSX and paradoxically the old SS3 and SS4 were unified to 24617 bytes, a full SAM SCREEN$ file, with a palette tables,...
SS3> thanks, I also spotted this, but have no time to check ... till now as far as I can remeber, SSx were unsettled years ago, so I started to use SS3 with length of 24580 and SS4 with 24592, expecting that a "higher level" format like SSX will cover screen types and also palette/line changes currently the SimCoupe emulator can produce raw files with 24580 and 24592 bytes as the SSX and paradoxically the old SS3 and SS4 were unified to 24617 bytes, a full SAM SCREEN$ file, with a palette tables,...
SS3> thanks, I also spotted this, but have no time to check ... till now as far as I can remeber, SSx were unsettled years ago, so I started to use SS3 with length of 24580 and SS4 with 24592, expecting that a "higher level" format like SSX will cover screen types and also palette/line changes currently the SimCoupe emulator can produce SSX files with 24580 and 24592 bytes and paradoxically the old SS3 and SS4 were unified to 24617 bytes, a full SAM SCREEN$ file, with a palette tables, although colour...
SS3> thanks, I also spotted this, but have no time to check ... till now as far as I can remeber, SSx were unsettled years ago, so I started to use SS3 with length of 24580 and SS4 with 24592, expecting that a "higher level" format like SSX will cover types and also palette/line changes currently the SimCoupe emulator can produce SSX files with 24580 and 24592 bytes and paradoxically the old SS3 and SS4 were unified to 24617 bytes, a full SAM SCREEN$ file, with a palette tables, although colour changes...
yes, the formula is OK and the value is the same for both eLeMeNt ZX and MB hardware, plus the LnxSpectrum emulator
Why do TIME3.!s and OBJ2.!s look better with black paper and white ink? Sorry, I am not sure about it. Moroz told me that according to your reports he immediately repaired and inverted all monochrome pictures. https://zxart.ee/eng/graphics/database/pictureType:monochrome/sortParameter:date/sortOrder:desc/resultsType:zxitem/
SS3> thanks, I also spotted this, but have no time to check ... till now as far as I can remeber, SSx were unsettled years ago, so I started to use SS3 with length of 24580 and SS4 with 24592, expecting that a "higher level" format like SSX will cover types and also palette/line changes currently the SimCoupe emulator can produce SSX files with 24580 and 24592 bytes and paradoxically the old SS3 and SS4 were unified to 24617 bytes, a full SAM SCREEN$ file, with a palette tables, although colour changes...
SS3> thanks, I also spotted this, but have no time to check ... till now as far as I can remeber, SSx were unsettled years ago, so I started to use SS3 with length of 24580 and SS4 with 24592, expecting that a "higher level" format like SSX will cover types and also palette/line changes currently the SimCoupe emulator can produce SSX files with 24580 and 24592 bytes and paradoxically the old SS3 and SS4 were unified to 24617 bytes, a full SAM SCREEN$ file, with a palette tables, although colour changes...
ad5) yes, ZX-Uno was the first: https://www.zxuno.com/ht2e/ + see the attachement. I also opened a Radastanian thread on the SpecComp forum, in order to support the RAD format and its older converter, https://spectrumcomputing.co.uk/forums/viewtopic.php?p=77038#p77038 ad3) ??? imho, in the monochrome should be pixel set (binary 1) in black as an ink. white is 0, a paper. MANY THANKS, let me go with some testing :-)
ad5) yes, ZX-Uno was the first: https://www.zxuno.com/ht2/ + see the attachement. I also opened a Radastanian thread on the SpecComp forum, in order to support the RAD format and its older converter, https://spectrumcomputing.co.uk/forums/viewtopic.php?p=77038#p77038 ad3) ??? imho, in the monochrome should be pixel set (binary 1) in black as an ink. white is 0, a paper. MANY THANKS, let me go with some testing :-)
ad5) yes ZX-Uno was the first: https://www.zxuno.com/ht2/ + see the attachement. I also opened a Radastanian thread on SpecComp forum, in order to support the RAD format and its converter, https://spectrumcomputing.co.uk/forums/viewtopic.php?p=77038#p77038
ad5) yes ZX-Uno was the first: https://www.zxuno.com/ht2/
ad5) yes ZX-Uno was the first: https://www.zxuno.com/ht2/
1) The format of HRXC attributes is: bits 0-3 INK and 4-7 PAPER , 16+16 colours, no bright and no flash 2) THR examples are here: https://zxart.ee/eng/graphics/database/pictureType:timexhr/sortParameter:date/sortOrder:desc/resultsType:zxitem/ the last byte should hold a colour information, however, the standard is not settled yet, I think... sometimes this byte holds a number 0-7, sometimes takes a form of the timex hw port (bits 3-5) eg. see page 34 of the ProgRef https://docs.google.com/document/d/1NJB_z3zVorTfmEj2JAS3QtAx_zbpkdCAAptHSnOOzkU/edit?tab=t.0...
The format of HRXC attributes is: bits 0-3 INK and 4-7 PAPER , 16+16 colours, no bright and no flash THR examples are here: https://zxart.ee/eng/graphics/database/pictureType:timexhr/sortParameter:date/sortOrder:desc/resultsType:zxitem/ the last byte should hold a colour information, however, the standard is not settled yet, I think... sometimes this byte holds a number 0-7, sometimes takes a form of the timex hw port (bits 3-5) eg. see page 34 of the ProgRef https://docs.google.com/document/d/1NJB_z3zVorTfmEj2JAS3QtAx_zbpkdCAAptHSnOOzkU/edit?tab=t.0...
The format of HRXC attributes is: bits 0-3 INK and 4-7 PAPER , 16+16 colours, no bright and no flash THR examples are here: https://zxart.ee/eng/graphics/database/pictureType:timexhr/sortParameter:date/sortOrder:desc/resultsType:zxitem/ the last byte should hold a colour information, however, the standard is not settled yet, I think... sometimes this byte holds a number 0-7, sometimes takes a form of the timex hw port (bits 3-5) eg. see page 34 of the ProgRef https://docs.google.com/document/d/1NJB_z3zVorTfmEj2JAS3QtAx_zbpkdCAAptHSnOOzkU/edit?tab=t.0...
videos: https://www.youtube.com/@jankucera6443/videos Pouet: enhanced ZX... https://www.pouet.net/prodlist.php?platform%5B%5D=ZX%20Enhanced
the highest eZX resolution + programming example attached
eLeMeNt ZX graphics support
Sorry, I have no special link. VICE was installed from the flatpak section of the standard Linux Mint Software Manager.
Flatpack version: Failed to save settings...