Re: SAM HAM viewer
The Sam does of course have line-based palette changes built into its native SCREEN$ loader (before you say: yes I know that's not quite as sophisticated as what's being discussed). In... oh, 1996, I attempted to write a program that could translate a 256x192 image into a plain Sam screen with palette line changes, though it wasn't hugely successful. It describes itself as follows: Usage: /tmp/ppmtosam [flags] [input] [output] This program converts the named input file (or standard input if none is named) from raw PPM format to a Sam mode 4 screen picture and writes the result in the named output file (or standard output). The resulting file will contain the bitmap (24576 bytes) a palette (40 bytes) and, if required, a line table (4*n bytes) and end with an end marker (character 255). This is the same format as if the picture had been saved to disk on a Sam. If line changes are not requested then the program selects the 16 best colours for the palette. Otherwise the program attempts to calculate a best palette for each line, based on the colours in the surrounding area (the program does not take account of the fact that if several palette changes are made on one line then the later ones will not be available immediately). Alternatively, a picture can be produced using the 14-colour greyscale palette. The picture is not dithered by default, but Floyd-Steinberg dithering may be selected. Valid flags: (default values in brackets) -c Allow line changes -d Produce some debugging information -f Use Floyd-Steinberg dithering -g Produce a greyscale picture instead of a colour one -q Quiet (don't print the number of palette changes) -s Attempt to smooth boundaries caused by palette changes while dithering -A n Look ahead n lines when calculating popular colours for line changes [4] -B n Look behind n lines when calculating colours for line changes [0] -D n Discourage line changes (higher n makes fewer line changes) [4] -k n Keep the first n colours constant when calculating line changes [8] (pen 0 if kept should be a popular dark colour and pen 1 should be light) -L n Use a maximum of L colour changes on a line [2] -M n Use a maximum of n colour changes for the whole picture [127] imc
Re: SAM HAM viewer
Thanks for that Ian — it does sound very similar to what I was aiming for. Though the standard screen$ capabilities seem very limited, with maybe just 1 change per line? (plus flash) I've had a few more ideas about how to handle a running palette, with it tied into knowledge of SAM's display timings. It might be a while before there's anything to show for it though. Si On 3 Apr 2012, at 18:21, Ian Collier wrote: The Sam does of course have line-based palette changes built into its native SCREEN$ loader (before you say: yes I know that's not quite as sophisticated as what's being discussed). In... oh, 1996, I attempted to write a program that could translate a 256x192 image into a plain Sam screen with palette line changes, though it wasn't hugely successful. It describes itself as follows: Usage: /tmp/ppmtosam [flags] [input] [output] This program converts the named input file (or standard input if none is named) from raw PPM format to a Sam mode 4 screen picture and writes the result in the named output file (or standard output). The resulting file will contain the bitmap (24576 bytes) a palette (40 bytes) and, if required, a line table (4*n bytes) and end with an end marker (character 255). This is the same format as if the picture had been saved to disk on a Sam. If line changes are not requested then the program selects the 16 best colours for the palette. Otherwise the program attempts to calculate a best palette for each line, based on the colours in the surrounding area (the program does not take account of the fact that if several palette changes are made on one line then the later ones will not be available immediately). Alternatively, a picture can be produced using the 14-colour greyscale palette. The picture is not dithered by default, but Floyd-Steinberg dithering may be selected. Valid flags: (default values in brackets) -c Allow line changes -d Produce some debugging information -f Use Floyd-Steinberg dithering -g Produce a greyscale picture instead of a colour one -q Quiet (don't print the number of palette changes) -s Attempt to smooth boundaries caused by palette changes while dithering -A n Look ahead n lines when calculating popular colours for line changes [4] -B n Look behind n lines when calculating colours for line changes [0] -D n Discourage line changes (higher n makes fewer line changes) [4] -k n Keep the first n colours constant when calculating line changes [8] (pen 0 if kept should be a popular dark colour and pen 1 should be light) -L n Use a maximum of L colour changes on a line [2] -M n Use a maximum of n colour changes for the whole picture [127] imc
Re: SAM HAM viewer
I think nvg's mail server is on crack... yesterday it responded to an unsubscribe command that I'd sent on April 4*. Thanks Frode, if it was you who kicked it. :-) On Fri, Apr 13, 2012 at 02:54:05PM +0100, Simon Owen wrote: Thanks for that Ian -- it does sound very similar to what I was aiming for. Though the standard screen$ capabilities seem very limited, with maybe just 1 change per line? (plus flash) Sam BASIC's handling of this is tied to line interrupts (i.e., same as when you type PALETTE LINE). The advantage of that is the machine keeps working while the screen is up; the disadvantage is that you can't do much work during the interrupt (and the code isn't written for speed). I think the limit is about 2 before the changes start showing on screen. I've tried this program on a few random images but With 2 changes per line the difference between allowing changes and having no changes is only minimally visible (unless I'm just not using colourful enough images to start with). The other problem it has is that with FS dithering sometimes the error values build up to the extent that when a palette change occurs it might select too much of the new colour just to get rid of the errors - this produces either a visible horizontal line in the output or occasionally a sudden change in shade. The program's -s flag tries to fix this by using a random number to inhibit selection of a colour on the line where it's new, but either that doesn't work very well or I didn't get the randomness quite right. imc * Needed to slightly change the format of my email address so it would let me post.
RE: SAM HAM viewer
Btw... I think the link to the dsk is busted right now...
Re: SAM HAM viewer
On 12/04/2012 23:34, Simon Cooke wrote: Btw... I think the link to the dsk is busted right now... Oops, yes -- fixed now! :) It's possible the broken redirect is cached, so try: http://simonowen.com/sam/shamview/shamview.dsk?x Si
Re: SAM HAM viewer
Quoting Stefan Drissen stefan.dris...@gmail.com: On another note (to hijack the thread), RJ does have some interesting ideas between all his communication issues and his one meg 128k emulator 'pestering' got me thinking - if this is uncontended RAM - how much could I win in the SAM MOD player if I moved code and data to make use of the one meg. Obviously larger mods would be interesting, but I'm more interested in would I be able to increase the sample rate from 10.4 KHz to 15.6 KHz? Or is the gain from uncontended vs contended RAM much too small? I think it would certainly be possible to increase the frequency - but perhaps only a smaller jump... would certainly be perhaps something noticable.
Re: SAM HAM viewer
On 11/04/2012 22:42, Stefan Drissen wrote: Is the palette being adjusted multiple times while the line is being drawn (similar to the rainbow processor effects on the Spectrum) No, only outside the image being drawn, for now. how many t-states are available between line end and next line start There's only 128T for updates in the horizontal border, which is just enough time for 6 updates if positioned correctly. The update OUTI is 24T in the border area and 32T over the main screen, including memory and I/O contention. Even with an unrolled OUTI loop there's still only time to update 13 entries across a full scanline. I did consider using external RAM for the viewer, but it'd probably only allow 1 extra update, so wasn't really worth restricting the hardware it would run on. interested in would I be able to increase the sample rate from 10.4 KHz to 15.6 KHz? Or is the gain from uncontended vs contended RAM much too small? I'm not sure it'd be enough. If you can extract+modify the relevant code snippet it shouldn't be too difficult to check in the SimCoupe debugger... Si
Re: SAM HAM viewer
Jumping in a bit late here, but the results are absolutely stunning! I had an attempt at reading the source on github, but my Z80 has gone a bit rusty. :-) Is the palette being adjusted multiple times while the line is being drawn (similar to the rainbow processor effects on the Spectrum) or is the palette being adjusted in the time between two lines? Please forgive me for talking potential nonsense - I have completely lost any notion of how many t-states are available between line end and next line start but the expensiveness of outs does ring a bell somewhere. On another note (to hijack the thread), RJ does have some interesting ideas between all his communication issues and his one meg 128k emulator 'pestering' got me thinking - if this is uncontended RAM - how much could I win in the SAM MOD player if I moved code and data to make use of the one meg. Obviously larger mods would be interesting, but I'm more interested in would I be able to increase the sample rate from 10.4 KHz to 15.6 KHz? Or is the gain from uncontended vs contended RAM much too small? Regards, Stefan On Sat, Mar 24, 2012 at 3:10 AM, Simon Owen simon.o...@simcoupe.org wrote: Hi all, I've been experimenting with HAM-style tricks on SAM, to try to improve the quality of converted images. I've aimed to modify as many colours as possible between lines, rather than using the traditional compromise static palette. Are there any viewers using that technique already? I've written a Python script to convert regular images to a new .sham format, and a SAM viewer program to display them. Demo: http://simonowen.com/sam/shamview/shamview.dsk Source code: https://github.com/simonowen/shamview You might recognise some of them as SAM or image processing favourites! It still needs work on the dynamic palette selection, which just uses the most-frequent colours, rather than doing proper quantisation. I left the crayons image as an example of this breaking down. Si
Re: SAM HAM viewer
I expect approximately +25% speed gain in uncontended memory. And Simon Owen wrote that he changes palette only “between” lines. Aley From: Stefan Drissen Sent: Wednesday, April 11, 2012 11:42 PM To: sam-users@nvg.ntnu.no Subject: Re: SAM HAM viewer Jumping in a bit late here, but the results are absolutely stunning! I had an attempt at reading the source on github, but my Z80 has gone a bit rusty. :-) Is the palette being adjusted multiple times while the line is being drawn (similar to the rainbow processor effects on the Spectrum) or is the palette being adjusted in the time between two lines? Please forgive me for talking potential nonsense - I have completely lost any notion of how many t-states are available between line end and next line start but the expensiveness of outs does ring a bell somewhere. On another note (to hijack the thread), RJ does have some interesting ideas between all his communication issues and his one meg 128k emulator 'pestering' got me thinking - if this is uncontended RAM - how much could I win in the SAM MOD player if I moved code and data to make use of the one meg. Obviously larger mods would be interesting, but I'm more interested in would I be able to increase the sample rate from 10.4 KHz to 15.6 KHz? Or is the gain from uncontended vs contended RAM much too small? Regards, Stefan On Sat, Mar 24, 2012 at 3:10 AM, Simon Owen simon.o...@simcoupe.org wrote: Hi all, I've been experimenting with HAM-style tricks on SAM, to try to improve the quality of converted images. I've aimed to modify as many colours as possible between lines, rather than using the traditional compromise static palette. Are there any viewers using that technique already? I've written a Python script to convert regular images to a new .sham format, and a SAM viewer program to display them. Demo: http://simonowen.com/sam/shamview/shamview.dsk Source code: https://github.com/simonowen/shamview You might recognise some of them as SAM or image processing favourites! It still needs work on the dynamic palette selection, which just uses the most-frequent colours, rather than doing proper quantisation. I left the crayons image as an example of this breaking down. Si - Mgr. Aleš Keprt, Ph.D. private: a...@keprt.cz, www.keprt.cz office: Moravian College / Moravská vysoká škola Olomouc, ales.ke...@mvso.cz
Re: SAM HAM viewer
On 11 Apr 2012, at 22:42, Stefan Drissen wrote: Jumping in a bit late here, but the results are absolutely stunning! I had an attempt at reading the source on github, but my Z80 has gone a bit rusty. :-) Is the palette being adjusted multiple times while the line is being drawn (similar to the rainbow processor effects on the Spectrum) or is the palette being adjusted in the time between two lines? Please forgive me for talking potential nonsense - I have completely lost any notion of how many t-states are available between line end and next line start but the expensiveness of outs does ring a bell somewhere. On another note (to hijack the thread), RJ does have some interesting ideas between all his communication issues and his one meg 128k emulator 'pestering' got me thinking - if this is uncontended RAM - how much could I win in the SAM MOD player if I moved code and data to make use of the one meg. Obviously larger mods would be interesting, but I'm more interested in would I be able to increase the sample rate from 10.4 KHz to 15.6 KHz? Or is the gain from uncontended vs contended RAM much too small? Regards, Stefan On Sat, Mar 24, 2012 at 3:10 AM, Simon Owen simon.o...@simcoupe.org wrote: Hi all, I've been experimenting with HAM-style tricks on SAM, to try to improve the quality of converted images. I've aimed to modify as many colours as possible between lines, rather than using the traditional compromise static palette. Are there any viewers using that technique already? I've written a Python script to convert regular images to a new .sham format, and a SAM viewer program to display them. Demo: http://simonowen.com/sam/shamview/shamview.dsk Source code: https://github.com/simonowen/shamview You might recognise some of them as SAM or image processing favourites! It still needs work on the dynamic palette selection, which just uses the most-frequent colours, rather than doing proper quantisation. I left the crayons image as an example of this breaking down. Si You should get an increase of 10-20% with the 1Meg. I think in theory you could get as much as 30% if you didn't access internal mem at all. I have done a lot testing with the 1Meg and did a version of fido using it got about 10% extra speed I think. David
RE: SAM HAM viewer
Interesting, I need 50% (1 sample burst per scan line instead of 1 sample burst per 1.5 scan lines), so that would leave 25% lacking. On the other hand, bursting per scan line would get rid of the manual timing to get burst at half lines. To be continued. Got the between, thanks – rereading the source I see that a maximum of 11 palette entries are adjusted between the lines. So there is room for a - cpu intensive – let’s follow the scan line ‘rainbow processor’ on the SAM. Get your act together Si! ;-) From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On Behalf Of Aleš Keprt Sent: woensdag 11 april 2012 23:59 To: sam-users@nvg.ntnu.no Subject: Re: SAM HAM viewer I expect approximately +25% speed gain in uncontended memory. And Simon Owen wrote that he changes palette only “between” lines. Aley From: Stefan Drissen mailto:stefan.dris...@gmail.com Sent: Wednesday, April 11, 2012 11:42 PM To: sam-users@nvg.ntnu.no Subject: Re: SAM HAM viewer Jumping in a bit late here, but the results are absolutely stunning! I had an attempt at reading the source on github, but my Z80 has gone a bit rusty. :-) Is the palette being adjusted multiple times while the line is being drawn (similar to the rainbow processor effects on the Spectrum) or is the palette being adjusted in the time between two lines? Please forgive me for talking potential nonsense - I have completely lost any notion of how many t-states are available between line end and next line start but the expensiveness of outs does ring a bell somewhere. On another note (to hijack the thread), RJ does have some interesting ideas between all his communication issues and his one meg 128k emulator 'pestering' got me thinking - if this is uncontended RAM - how much could I win in the SAM MOD player if I moved code and data to make use of the one meg. Obviously larger mods would be interesting, but I'm more interested in would I be able to increase the sample rate from 10.4 KHz to 15.6 KHz? Or is the gain from uncontended vs contended RAM much too small? Regards, Stefan On Sat, Mar 24, 2012 at 3:10 AM, Simon Owen simon.o...@simcoupe.org wrote: Hi all, I've been experimenting with HAM-style tricks on SAM, to try to improve the quality of converted images. I've aimed to modify as many colours as possible between lines, rather than using the traditional compromise static palette. Are there any viewers using that technique already? I've written a Python script to convert regular images to a new .sham format, and a SAM viewer program to display them. Demo: http://simonowen.com/sam/shamview/shamview.dsk Source code: https://github.com/simonowen/shamview You might recognise some of them as SAM or image processing favourites! It still needs work on the dynamic palette selection, which just uses the most-frequent colours, rather than doing proper quantisation. I left the crayons image as an example of this breaking down. Si - Mgr. Aleš Keprt, Ph.D. private: a...@keprt.cz, www.keprt.cz office: Moravian College / Moravská vysoká škola Olomouc, ales.ke...@mvso.cz
Re: SAM HAM viewer
very big apols simon but lovely top hear from someone with 2 seconds to just explain that something is possible but the do not have the time sorry for all the trouble caused i'm sure pressing the delete key when you are so snowed under is a real pain i'm going to try to keep this short and sweet as the longer they get the more i offend everyone i posted several million annoying questions about how things work which i still dont understand i know rtfm i tried to rtftm technical manual where hmpr bits 56 are supposedly explained i think aley tried to explain it to me and he managed it slightly better thant he technical manual and i was trying to tie this explanation in with the comments to a question i posted on teh world of sam site so maybe some people have been bombarded with questions from me hacing not read the comments on world of sam where i saked in teh palette section how many palette alterations could be made per scan line someone posted that 9 was allowed in internal ram an 18 using external i'm obsessed - that doesnt seem like too many but if a couple fo those were hmpr bits56 changes then surely even if we had to keep one colour the same throughout all the 16 colours available in the clut - now divided into 4x4 colour sections for a mode 3 screen - keeping one colour the same would this help reduce flicker? i assume if you alter all four colours then the one that is on the screen being displayed and having its clut value modified will flicker during the alteration - i do not know i did not design the asic - nor could i! well i just keep thinking that at 512x192 and then inerlacing two 512x192 screens - which technically when you could have 16 screen$ in easy vmpr pointable to ram areas without having to copy form ram to ram or from port to ram - unless you manage to use teh full 4mb external as a video ram page buffer - uncompressed? - which would also necessitate a ram to ram copy and here is where the DMA from the MB-02+ would come in really useful - though yes i agree with everyone that £139.99 for the 28½mhz accelerator from quazar or the 14mhz one from velesoft woudl be much more fun from a progrrammers point of view - mind you if either or both could have a dma - especially if there was one that understood what teffect the bits per pixel of video ram might have on the byte or blocks of ram it copies or compares - in terms of offering rotations or other scaling orientation modifications for things like sprites or scrolled backgrounds - even antialiased lines for 3d vectors or solid shapes- polygons(dead parrot?!) off on another one still 512x384 16 colours per scan line? if bmp2scr output this in its tap/tzx file - prefer an atom hdf file but still only another massive application to spend all day transferring from one place to another only to find it has been hacked on route - for pities sake never use a secure connection with any of the hardware driver update software app sites - it makes sense! shit 20 years ago 512x384 16 coluors per scan line? animations if we'd hada hardrive at the time? DMA interface - evn a basic one - you coudl ahve converted amiga demos and reanimated them on sam - who cares if the processor isnt power ful enough to do it look its running as a video! which is incidentally what most of the ati nvidia demos are which kind of begs the question was it worth spengin several million piounds to install several dozen vga cards with tv encoders that dont work in my pc! - got it in there just at the end - you can ban me from all the forums on the planet now and hack my pc another dozen times please - yours ever restarting my restart reboot rebooot rebt even my sam boots faster than this piece of shit! just think masterdos and masterbasic running with mass storage like atom lite dictonary like spell master on a couple of records 80,000 words - now use that as the basis for the itu t v44+IPR=921600 oh dear another technical term weird you guys can program emulators that dont work properly but dont understand modems! - me ether! On 06/04/2012, Simon Cooke si...@popcornfilms.com wrote: I thought about doing something like this a while back, but as ever didn't get chance to play with the idea. For me, the trick would have been to say screw it and randomly/genetically generate the code required to change the palette. On modern CPUs it shouldn't take more than a few hours to generate/simulate even if you're brute forcing it. Now, of course, once you get to dithering the image and optimizing that, you're starting to explode the solution space but it's not exactly insurmountable. (I've got a 2 year old daughter and enough work to sink a battleship these days, so unfortunately as much as I hate to say it, I think my SAM programming days are done :'( ).
Re: SAM HAM viewer
agree 100% better to take care of your daughter - make sure she goes to the right school here in limavady you 'd have five to choose from! all paid for from tax payers money make sure you choose the right one saw bot! On 06/04/2012, Simon Cooke si...@popcornfilms.com wrote: I thought about doing something like this a while back, but as ever didn't get chance to play with the idea. For me, the trick would have been to say screw it and randomly/genetically generate the code required to change the palette. On modern CPUs it shouldn't take more than a few hours to generate/simulate even if you're brute forcing it. Now, of course, once you get to dithering the image and optimizing that, you're starting to explode the solution space but it's not exactly insurmountable. (I've got a 2 year old daughter and enough work to sink a battleship these days, so unfortunately as much as I hate to say it, I think my SAM programming days are done :'( ).
Re: SAM HAM viewer
An additional observation: this might finally be an application for the Kaleidoscope? On 5 April 2012 17:10, Simon Cooke si...@popcornfilms.com wrote: I thought about doing something like this a while back, but as ever didn't get chance to play with the idea. For me, the trick would have been to say screw it and randomly/genetically generate the code required to change the palette. On modern CPUs it shouldn't take more than a few hours to generate/simulate even if you're brute forcing it. Now, of course, once you get to dithering the image and optimizing that, you're starting to explode the solution space but it's not exactly insurmountable. (I've got a 2 year old daughter and enough work to sink a battleship these days, so unfortunately as much as I hate to say it, I think my SAM programming days are done :'( ). From: Simon Owen Sent: 4/3/2012 2:43 To: sam-users@nvg.ntnu.no Subject: Re: SAM HAM viewer On 2 Apr 2012, at 23:58, Thomas Harte wrote: I think that used a tight loop of something like (i) load next palette index, next colour and next delay length; (ii) push colour to palette index; (iii) perform a busy loop of the desired length; (iv) repeat. That's closer the approach I was originally aiming for, but the conversion is far more complicated. For a first attempt I restricted it to changing the CLUT when the raster was outside the image, which still gives a noticeable improvement over a static palette. My ideal approach would even eliminate steps (i) and (iii), and just use a huge unrolled loop of OUTI instructions. That would update 1 CLUT entry per instruction in reverse order, in a continuous loop. The converter would be tracking a rolling window colours, with knowledge of colours no longer needed and look-ahead to what can be set up in advance. It also needs to understand the instruction timing, which varies across the scanline. Thinking of implementing that still makes my head hurt! but you could instead, say, change a single palette index several times over the course of a single scan line, or anything in between. I considered individual CLUT updates for my current viewer, but it took too much time away from the actual updating — the extra LD B,n needed costs about the same has half an OUTI. Instead I grouped the dynamic colours together and updated them with a small unrolled OUTI block. If you have portions of the image with only four colours (especially once the colour aliasing forced by the 128-colour palette is accounted for) then switching to mode 3 for a portion of a line could be the smarter thing to do, and would presumably cost basically nothing to implement? Unless you need the extra resolution, I don't think there's anything to gain from using mode 3. It uses a subset of the mode 4 CLUT, so it doesn't help with fast access to an alternative colour set. Or am I missing something? Si
RE: SAM HAM viewer
I thought about doing something like this a while back, but as ever didn't get chance to play with the idea. For me, the trick would have been to say screw it and randomly/genetically generate the code required to change the palette. On modern CPUs it shouldn't take more than a few hours to generate/simulate even if you're brute forcing it. Now, of course, once you get to dithering the image and optimizing that, you're starting to explode the solution space but it's not exactly insurmountable. (I've got a 2 year old daughter and enough work to sink a battleship these days, so unfortunately as much as I hate to say it, I think my SAM programming days are done :'( ).
Re: SAM HAM viewer
On 2 Apr 2012, at 02:05, Aleš Keprt wrote:
So how many colours are possible per line in this format? Or what is possible
in this picture format?
The number of colour changes per line depends on the image width, as CLUT
changes are only made outside the image. That gives 6 dynamic and 10 static
for full 256-pixel width, but up to 11 dynamic and 4 static for 96-pixel narrow
images.
Also, I think that the converter could possibly de-noise the picture before
or after the conversion.
Most of the conversion is using traditional methods — Heckbert's median cut to
reduce to the full SAM palette, then Floyd-Steinberg dithering to apply it.
The result of that will be close to what you'd get converting it in a typical
desktop image-editing package. Of course, there's a second step conversion to
reduce to the CLUT size, but it aims to keep the image as close to the original
converted image as possible. Reducing the dithering ('noise') would mean
compromising on pure colours, which is something that should probably be done
interactively on a per-picture basis.
The viewer is quite straighforward, all the colour magic lies in the
converter.
The core viewer code is short, but there's more to it than meets the eye! The
start alignment and dynamic colour count depends on the width of the image
being viewed. There are 6 self-modifying points used to inline counters and
pointers, since there's little time to make decisions at runtime.
The converter is still very important, of course, and my proof-of-concept
script has certain deficiencies. I'm hoping that having a released native
viewer will mean it can be included as an output format in existing SAM image
conversion utilities, where the conversion will get the extra attention it
needs, and by someone that knows more what they're doing!
Si
Re: SAM HAM viewer
On 2 Apr 2012, at 23:58, Thomas Harte wrote: I think that used a tight loop of something like (i) load next palette index, next colour and next delay length; (ii) push colour to palette index; (iii) perform a busy loop of the desired length; (iv) repeat. That's closer the approach I was originally aiming for, but the conversion is far more complicated. For a first attempt I restricted it to changing the CLUT when the raster was outside the image, which still gives a noticeable improvement over a static palette. My ideal approach would even eliminate steps (i) and (iii), and just use a huge unrolled loop of OUTI instructions. That would update 1 CLUT entry per instruction in reverse order, in a continuous loop. The converter would be tracking a rolling window colours, with knowledge of colours no longer needed and look-ahead to what can be set up in advance. It also needs to understand the instruction timing, which varies across the scanline. Thinking of implementing that still makes my head hurt! but you could instead, say, change a single palette index several times over the course of a single scan line, or anything in between. I considered individual CLUT updates for my current viewer, but it took too much time away from the actual updating — the extra LD B,n needed costs about the same has half an OUTI. Instead I grouped the dynamic colours together and updated them with a small unrolled OUTI block. If you have portions of the image with only four colours (especially once the colour aliasing forced by the 128-colour palette is accounted for) then switching to mode 3 for a portion of a line could be the smarter thing to do, and would presumably cost basically nothing to implement? Unless you need the extra resolution, I don't think there's anything to gain from using mode 3. It uses a subset of the mode 4 CLUT, so it doesn't help with fast access to an alternative colour set. Or am I missing something? Si
Re: SAM HAM viewer
I've seen something similar on the Atari Lynx, which also has a 4 bit frame buffer, the only difference being that I think that used a tight loop of something like (i) load next palette index, next colour and next delay length; (ii) push colour to palette index; (iii) perform a busy loop of the desired length; (iv) repeat. The loop was synchronised once with vertical retrace and timings were such that a degenerate case was to change the entire palette once after every scan line but you could instead, say, change a single palette index several times over the course of a single scan line, or anything in between. A better adaption for the Sam might be to allow palette and mode changes, and for simplicity to add a delay length that just means to wait until the next vertical retrace? If you have portions of the image with only four colours (especially once the colour aliasing forced by the 128-colour palette is accounted for) then switching to mode 3 for a portion of a line could be the smarter thing to do, and would presumably cost basically nothing to implement? In terms of image conversion, I guess a heuristic would be the thing. It feels like, even at Sam size, an exhaustive search could take forever. Of course, I didn't disassemble Simon's fantastic work so it's possible he's way ahead of me on this one. On 1 April 2012 18:05, Aleš Keprt a...@keprt.cz wrote: Oh yes, this is nice. I saw similar things in the past, AFAIR this was published on some disk magazine back in 90's. But it will be hard to find it now. So how many colours are possible per line in this format? Or what is possible in this picture format? Also, I think that the converter could possibly de-noise the picture before or after the conversion. Or something like that. Because there are too many dots visible in places where there should be no dots. This is good in high resolution graphics like when printing on printer in 600 DPI, but doesn't look too well on Sam. Especially in emulator with crisp LCD display. ;-) I think the whole de-noising process is extremely important when converting to low resolution and low bitdepth. And each single picture needs a different values for the algorithm, so maybe there should be some kind of WYSIWYG editor or something where users could change some settings and see the result immediately in order to find the best settings for each file. ;-) Maybe a genetic algorithm could help to find at least some local optimum. /--- Aley -Původní zpráva- From: Simon Owen Sent: Saturday, March 24, 2012 3:10 AM To: sam-users Subject: SAM HAM viewer Hi all, I've been experimenting with HAM-style tricks on SAM, to try to improve the quality of converted images. I've aimed to modify as many colours as possible between lines, rather than using the traditional compromise static palette. Are there any viewers using that technique already? I've written a Python script to convert regular images to a new .sham format, and a SAM viewer program to display them. Demo: http://simonowen.com/sam/shamview/shamview.dsk Source code: https://github.com/simonowen/shamview You might recognise some of them as SAM or image processing favourites! It still needs work on the dynamic palette selection, which just uses the most-frequent colours, rather than doing proper quantisation. I left the crayons image as an example of this breaking down. Si - Mgr. Aleš Keprt, Ph.D. private: a...@keprt.cz, www.keprt.cz office: Moravian College / Moravská vysoká škola Olomouc, ales.ke...@mvso.cz
Re: SAM HAM viewer
Actually there is a commented source code on Simon's web. The viewer is quite straighforward, all the colour magic lies in the converter. ;-) I am now planning to create a zx81 emulator, and that computer is quite interesting in that it doesn't push all registers to stack on interrupt. It means that some registers can't be generally used when interrupt is enabled, but the benefit is that the interrupt handelr routine is faster to start. This zx81-way it would probably be possible to change more colours per scanline. That brings me to the question if there exist 64bit TASM compiler. I always used TASM with Z80 mactors to compile my programs, but now I can't run TASM because my version is apparently a 16bit exe from MS-DOS. I would probably need to find at least some 32bit edition, if that's possible. (I don't have any experience with Python and I am not generally happy to install Python in order to run Z80 crossassembler once in a while.) A. -Původní zpráva- From: Thomas Harte Sent: Tuesday, April 03, 2012 12:58 AM To: sam-users@nvg.ntnu.no Subject: Re: SAM HAM viewer I've seen something similar on the Atari Lynx, which also has a 4 bit frame buffer, the only difference being that I think that used a tight loop of something like (i) load next palette index, next colour and next delay length; (ii) push colour to palette index; (iii) perform a busy loop of the desired length; (iv) repeat. The loop was synchronised once with vertical retrace and timings were such that a degenerate case was to change the entire palette once after every scan line but you could instead, say, change a single palette index several times over the course of a single scan line, or anything in between. A better adaption for the Sam might be to allow palette and mode changes, and for simplicity to add a delay length that just means to wait until the next vertical retrace? If you have portions of the image with only four colours (especially once the colour aliasing forced by the 128-colour palette is accounted for) then switching to mode 3 for a portion of a line could be the smarter thing to do, and would presumably cost basically nothing to implement? In terms of image conversion, I guess a heuristic would be the thing. It feels like, even at Sam size, an exhaustive search could take forever. Of course, I didn't disassemble Simon's fantastic work so it's possible he's way ahead of me on this one. On 1 April 2012 18:05, Aleš Keprt a...@keprt.cz wrote: Oh yes, this is nice. I saw similar things in the past, AFAIR this was published on some disk magazine back in 90's. But it will be hard to find it now. So how many colours are possible per line in this format? Or what is possible in this picture format? Also, I think that the converter could possibly de-noise the picture before or after the conversion. Or something like that. Because there are too many dots visible in places where there should be no dots. This is good in high resolution graphics like when printing on printer in 600 DPI, but doesn't look too well on Sam. Especially in emulator with crisp LCD display. ;-) I think the whole de-noising process is extremely important when converting to low resolution and low bitdepth. And each single picture needs a different values for the algorithm, so maybe there should be some kind of WYSIWYG editor or something where users could change some settings and see the result immediately in order to find the best settings for each file. ;-) Maybe a genetic algorithm could help to find at least some local optimum. /--- Aley -Původní zpráva- From: Simon Owen Sent: Saturday, March 24, 2012 3:10 AM To: sam-users Subject: SAM HAM viewer Hi all, I've been experimenting with HAM-style tricks on SAM, to try to improve the quality of converted images. I've aimed to modify as many colours as possible between lines, rather than using the traditional compromise static palette. Are there any viewers using that technique already? I've written a Python script to convert regular images to a new .sham format, and a SAM viewer program to display them. Demo: http://simonowen.com/sam/shamview/shamview.dsk Source code: https://github.com/simonowen/shamview You might recognise some of them as SAM or image processing favourites! It still needs work on the dynamic palette selection, which just uses the most-frequent colours, rather than doing proper quantisation. I left the crayons image as an example of this breaking down. Si - Mgr. Aleš Keprt, Ph.D. private: a...@keprt.cz, www.keprt.cz office: Moravian College / Moravská vysoká škola Olomouc, ales.ke...@mvso.cz - Mgr. Aleš Keprt, Ph.D. private: a...@keprt.cz, www.keprt.cz office: Moravian College / Moravská vysoká škola Olomouc, ales.ke...@mvso.cz
Re: SAM HAM viewer
Coincidentally I've just recently written a ZX81 emulator for the PC. The way it uses refresh cycles to create a display counter is very clever indeed and definitely what I found most interesting. I didn't end up doing much prying into the software side of things since it was a PC-side thing, but I guess a lightweight handler was necessitated by the way the slow mode timer was added to the ZX80 hardware? Have you considered giving DOSBox a go for TASM? It interacts fully with the native filing system so you just end up with a cmd.exe alternative that runs a different set of software. On 2 Apr 2012, at 16:32, Aleš Keprt a...@keprt.cz wrote: Actually there is a commented source code on Simon's web. The viewer is quite straighforward, all the colour magic lies in the converter. ;-) I am now planning to create a zx81 emulator, and that computer is quite interesting in that it doesn't push all registers to stack on interrupt. It means that some registers can't be generally used when interrupt is enabled, but the benefit is that the interrupt handelr routine is faster to start. This zx81-way it would probably be possible to change more colours per scanline. That brings me to the question if there exist 64bit TASM compiler. I always used TASM with Z80 mactors to compile my programs, but now I can't run TASM because my version is apparently a 16bit exe from MS-DOS. I would probably need to find at least some 32bit edition, if that's possible. (I don't have any experience with Python and I am not generally happy to install Python in order to run Z80 crossassembler once in a while.) A. -Původní zpráva- From: Thomas Harte Sent: Tuesday, April 03, 2012 12:58 AM To: sam-users@nvg.ntnu.no Subject: Re: SAM HAM viewer I've seen something similar on the Atari Lynx, which also has a 4 bit frame buffer, the only difference being that I think that used a tight loop of something like (i) load next palette index, next colour and next delay length; (ii) push colour to palette index; (iii) perform a busy loop of the desired length; (iv) repeat. The loop was synchronised once with vertical retrace and timings were such that a degenerate case was to change the entire palette once after every scan line but you could instead, say, change a single palette index several times over the course of a single scan line, or anything in between. A better adaption for the Sam might be to allow palette and mode changes, and for simplicity to add a delay length that just means to wait until the next vertical retrace? If you have portions of the image with only four colours (especially once the colour aliasing forced by the 128-colour palette is accounted for) then switching to mode 3 for a portion of a line could be the smarter thing to do, and would presumably cost basically nothing to implement? In terms of image conversion, I guess a heuristic would be the thing. It feels like, even at Sam size, an exhaustive search could take forever. Of course, I didn't disassemble Simon's fantastic work so it's possible he's way ahead of me on this one. On 1 April 2012 18:05, Aleš Keprt a...@keprt.cz wrote: Oh yes, this is nice. I saw similar things in the past, AFAIR this was published on some disk magazine back in 90's. But it will be hard to find it now. So how many colours are possible per line in this format? Or what is possible in this picture format? Also, I think that the converter could possibly de-noise the picture before or after the conversion. Or something like that. Because there are too many dots visible in places where there should be no dots. This is good in high resolution graphics like when printing on printer in 600 DPI, but doesn't look too well on Sam. Especially in emulator with crisp LCD display. ;-) I think the whole de-noising process is extremely important when converting to low resolution and low bitdepth. And each single picture needs a different values for the algorithm, so maybe there should be some kind of WYSIWYG editor or something where users could change some settings and see the result immediately in order to find the best settings for each file. ;-) Maybe a genetic algorithm could help to find at least some local optimum
Re: SAM HAM viewer
Oh yes, this is nice. I saw similar things in the past, AFAIR this was published on some disk magazine back in 90's. But it will be hard to find it now. So how many colours are possible per line in this format? Or what is possible in this picture format? Also, I think that the converter could possibly de-noise the picture before or after the conversion. Or something like that. Because there are too many dots visible in places where there should be no dots. This is good in high resolution graphics like when printing on printer in 600 DPI, but doesn't look too well on Sam. Especially in emulator with crisp LCD display. ;-) I think the whole de-noising process is extremely important when converting to low resolution and low bitdepth. And each single picture needs a different values for the algorithm, so maybe there should be some kind of WYSIWYG editor or something where users could change some settings and see the result immediately in order to find the best settings for each file. ;-) Maybe a genetic algorithm could help to find at least some local optimum. /--- Aley -Původní zpráva- From: Simon Owen Sent: Saturday, March 24, 2012 3:10 AM To: sam-users Subject: SAM HAM viewer Hi all, I've been experimenting with HAM-style tricks on SAM, to try to improve the quality of converted images. I've aimed to modify as many colours as possible between lines, rather than using the traditional compromise static palette. Are there any viewers using that technique already? I've written a Python script to convert regular images to a new .sham format, and a SAM viewer program to display them. Demo: http://simonowen.com/sam/shamview/shamview.dsk Source code: https://github.com/simonowen/shamview You might recognise some of them as SAM or image processing favourites! It still needs work on the dynamic palette selection, which just uses the most-frequent colours, rather than doing proper quantisation. I left the crayons image as an example of this breaking down. Si - Mgr. Aleš Keprt, Ph.D. private: a...@keprt.cz, www.keprt.cz office: Moravian College / Moravská vysoká škola Olomouc, ales.ke...@mvso.cz
Re: SAM HAM viewer
Very impressive... and seeing an old favourite picture from Flash with the effect was quite an improvement.
SAM HAM viewer
Hi all, I've been experimenting with HAM-style tricks on SAM, to try to improve the quality of converted images. I've aimed to modify as many colours as possible between lines, rather than using the traditional compromise static palette. Are there any viewers using that technique already? I've written a Python script to convert regular images to a new .sham format, and a SAM viewer program to display them. Demo: http://simonowen.com/sam/shamview/shamview.dsk Source code: https://github.com/simonowen/shamview You might recognise some of them as SAM or image processing favourites! It still needs work on the dynamic palette selection, which just uses the most-frequent colours, rather than doing proper quantisation. I left the crayons image as an example of this breaking down. Si
