Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by zilog_z80a

  1. Hi, i don't have that but i'm a timex sinclair collector, i just collect boxed official timex sinclair games, how this game looks like? cheers
  2. ty Dear @masschamber !! i have all this titles, even i have found bat cage title!! you are a very good person thanx again for remember me!! hey!! if you see again more titles of ts1000 or 2068 pls!! please!! Name me again. cheers!!
  3. Hi!! do you have still some ts1000 cassette? if not, can you send me the buyer via private msg? may be since 2012 now he wants to sell.. ty.
  4. hi, did you sell it? you still have it? do you want to sell at $6? do you have more titles for ts1000? ty!
  5. http://web.archive.org/web/20040627231026/http://www.taswegian.com/TwoHeaded/Atari2600/GreetingCart/GreetingCart.html GreetingCart - Interleaved ChronoColour™ in Action! Your GreetingCart™ demonstrates, for the first time on Atari 2600 hardware, an arbitrary colour image of reasonable quality. This cartridge uses software techniques ('Interleaved ChronoColour'™) to give the impression of full-colour images when, in fact, the rigid and limited capabilities of the Atari 2600 hardware still apply. The hardware of the Atari 2600 is not capable of displaying a TV frame with the image you see produced by this cartridge! The image displayed by this GreetingCart™ is 48 pixels wide by 128 pixels deep, and actually consists of just four colours - red, green, blue and black. There is only a single intensity of each colour (that is, there is a single red available, etc.) By changing the colour of each pixel in the image between red, green, blue or black (in various combinations) in a dynamic fashion (ie: over time), the image is perceived by the human eye as being composed of multiple colours. The two hardware sprites available on the Atari 2600 are each a single (independently) selectable colour, 8 pixels wide and one pixel deep. These sprites may be positioned anywhere on a horizontal line, and automatically repeat their shape and colour at the same position on the next line. The Atari 2600 allows a sprite to be displayed up to three times on any scanline - with preset spacing between each sprite instance. However, the shape displayed remains the same, unless it is changed mid-scanline by software. The famous 6-digit score routine - used for most of the scoring systems on Atari 2600 games - does just this, dynamically modifying the sprite shapes to achieve 6 independent 8-pixel wide sprites per scanline. It's a very neat trick, and forms the basis for the Interleaved ChronoColour™ system. Unfortunately, each of the sprites on the line must be a single colour - there is not enough processing time to change the shape of the sprites and the colour of the sprites- yet alone the colour of individual pixels. In fact, there's barely enough time to even change the shape of the sprites! So, how does Interleaved ChronoColour™ manage to produce a full-colour image? As it turns out, the system uses characteristics of the limitations of the human eye and your TV screen to give the impression of many colours when, in fact, the colour resolution (in both time and space) is quite limited. Your eye does not have high temporal colour resolution, so colours that vary rapidly tend to merge together and are perceived as a single blended colour. The colour resolution of the eye viewing a TV image appears (just from my experiments with the ChronoColour™ effect) to be roughly 18-20Hz - that is, above this rate the eye is unable to discern individual colours as they change. This is slow enough to allow the ChronoColour™ system to display reasonable images. As noted, there is barely enough time to display different shapes for each 8-pixel-wide sprite on any scanline - yet Interleaved ChronoColour™ appears to be displaying different shapes and colours! It appears to be, but it isn't... it just looks like it is. The Interleaved ChronoColour™ system is still using just a single colour for all of the sprites on any scanline - red, green, or blue. The same colour is used for the whole of any scanline. The system is varying the both colour used for any individual line (a single colour for the whole line) and the shapes displayed on that line. Every 3 sequential TV frames you see firstly red components of the pixels on the line, then the green components of the pixels on the line, then the blue components of the pixels on the line. So, any scanline consists of a single colour change for each sprite (to blue, green, or red), followed by (essentially) the body of the standard 6-digit score routine, which changes the shape of each sprite on-the-fly. Subsequent frames display the other colour components for that line. Each scanline must display on successive TV frames the blue, green, and then red components of the image for the ChronoColour™ effect to work. By also varying the colour of scanlines within a TV frame (one red, the next blue, the next green, the next red, etc), and displaying the right shapes for the sprites on those lines (the red pixels, etc), the alternation of red/green/blue is done at the frequency of display of scanlines (ie: many times per TV frame) instead of the frequency of display of the TV frames themselves (ie: at 60Hz). As there are only 4 colours available for any pixel (blue, green, red or black) of a single intensity, shading is achieved by dithering the original separated colour planes to two colours (black or non-black). This dithering distributes the pixels such that the eye perceives different intensities of the original colour. If you look very closely at the image, you may be able to detect a rolling band of red/green/blue scanlines marching up the screen - especially in the white areas of the image, if present. If you move your finger up the TV at the correct speed, watching your finger as you go, this effect becomes much more pronounced. This demonstrates clearly the alternating of colours on a per-line basis, and the interleaving of the colours on a per-frame basis for any scanline. So, that's how the Interleaved ChronoColour™ system works! Behind the display system itself are tools developed to produce data in the correct format. These tools, and the Interleaved ChronoColour™ technology itself, were developed during early 2003 by Andrew Davie, with input from various sources, including helpful advice and suggestions from members of the [stella] mailing list and the AtariAge community. Creating Interleaved ChronoColour™ Images This example shows the process used for creating data for the Interleaved ChronoColour™ system. First, a suitable image is chosen, and resized to 48 wide by 128 pixels deep. The resizing process should use a filter to preserve as much of the original image colour and detail as possible. This stage of the process may also involve adjusting the brightness and contrast of the image to improve the final image as shown on the Atari 2600. It is sometimes an iterative process to find settings which are pleasing to the eye. The 48 x 128 pixel image shown at right, above, is separated into three component images - the red, green and blue components of the original image. These components are shown below. These component images are each 256 shades of a single colour (red, green or blue). The Interleaved ChronoColour™ system is capable of displaying just a single shade of red, green, or blue, and black, so the images are colour-reduced to just 2-colours (including black). By dithering the images during the colour-conversion, detail and shading information is preserved. The images below show the component images after they have been dithered (in this case using error diffusion and 'Stucki' weighted dithering method). Dithered Red Component Dithered Green Component Dithered Blue Component Animated RGB These three images (left, above), displayed on successive TV frames, would essentially appear to the human eye like the original image. However, left at this stage the 20Hz 'flicker' introduced by only displaying each colour on every third TV frame is quite noticeable and annoying. The eye can clearly detect the individual colour frames, though the brain is able to reconstruct the merged colours. The animated GIF, above right, shows the 2-colour dithered images displayed one after the other. Your browser will probably not display this image at full-speed (it should display 1 frame every 1/60th of a second) - but in any case, if it is animating quickly enough you may see that the combination of the separate 2-colour images does give a reasonable reconstruction of the original image, but the flicker is distracting. The next stage in the process, then, is to 'interleave' the red, green and blue images to produce hybrid frames which contain on successive lines a line from the red, a line from the green, and a line from the blue image, etc. Tools written for the purpose create data for these hybrid frames. The result of the interleaving is three frames, the first of which starts with a line from the red image, then a line from the green image, then a line from the blue image, etc. The second image starts with a line from the green, then a line from the blue, then a line from the red, etc. And finally, the third image starts with a line from the blue, then a line from the red, then a line from the green, etc. Interleaved RGB Interleaved GBR Interleaved BRG Animated Interleaved Frames This process produces three images (left, above) which, seen on their own almost appear like the original colour image. But note, each scanline of these images is still only a single colour and intensity (with pixels either red, green or blue). The animated GIF, above right, shows the same 2-colour dithered images as before, but with the lines interleaved as described above. Now, even at a low frame rate, the flickering is much less apparent and the colours easier to discern. A close-up of a section of the one interleaved image, below, shows the interleaved scanlines. When the three interleaved images are displayed on consecutive TV frames, the flickering is no longer noticeable - because each image includes red, green, and blue components. That's the essence of the Interleaved ChronoColour™ process. Close-up of RGB Interleaving The images below show a digital camera image from a monitor, alongside the original image. It's clearly not photo-quality - but given the hardware capabilities of the Atari 2600, Interleaved ChronoColour™ opens up exciting new opportunities in graphics display for future games. This 4K Binary will run on the real thing, and under emulators such as Stella and Z26. Copyright ©2003 Andrew Davie
  6. @Thomas Jentzsch wait, the horizontal reposition has a sta.wx i have removed the x. what has changed? now the compiler works, must i do something to replace that x for other thing? works the same sta.wx than sta.w with just one dummie? i know that .w is some kind of delay.
  7. Hi @Thomas Jentzsch sorry, what is x or y? please teach me, in that lines i just have found a jump bank table. ty.
  8. Hi @SpiceWare !! thank you so much for your work like always. I'm trying to compile this source code sf_source071123 on linux ubuntu with DASM 2.20.14 I'm using this command line to do the job: dasm frosty.asm -lfrosty.lst -f3 -v5 -ofrosty.bin and i get: frosty.asm (473): error: Illegal forced Addressing mode on 'sta'. frosty.asm (1286): error: Illegal forced Addressing mode on 'sta'. Fatal assembly error: Source is not resolvable. Am I doing or writing something wrong? all it's in the same directory, vcs.h, macro.h, graphics.h, frosty.asm ty in advance.
  9. hi @Andrew Davie i laugh of my self, the example was in front my eyes in 2017 and me asking for an example. cheers. Sokoboo ty for that!!
  10. Hi mate, let you here some help. /path/thru/folders/to/executable/of/dasm /path/thru/folders/to/my/source/file/kernel.asm -lkernel.txt -f3 -v5 -okernel.bin if dasm and your source code are in the same folder yo can use ./ ./dasm kernel.asm -lkernel.txt -f3 -v5 -okernel.bin you must have vcs.h and macro.h files in the same folder where your source code it's. try some easy example inside your kernel.asm, if you do everything like it's posted here should work fine. cheers. PD: bear in mind, in linux you are allowed just to work inside your user folder if you are not the root user: /home/YOUR_USER_NAME_FOLDER
  11. @CPUWIZ I hope you are well soon, get well, that surely in addition to many people who appreciate you here in the forum... many must also be waiting for your health improvement there in your land. great greeting from Argentina. get well !! yeh!!🙂
  13. hi, thank you so much for your work @RevEng question: this dynamic labels can be used to pass a dynamic argument to a macro? cheers.
  14. zilog_z80a


    Hi Thomas!! glad to see you here, I think that 10 members (not me included) are Masters in a Temple, colleting anwers this place will be an incredible reference in the net (google searches) for everybody wanting to know about dasm syntax. i did a reference to this forum at facebook too. https://www.facebook.com/pg/DASM-Macro-Assembler-CLUB-100808128199075/posts/ cheers!!
  15. Hi Andrew, i mean a c programmer to add some examples in my spanish version of your tutorial at http://atari.rf.gd examples to some pseudo ops with no examples available(BEING ABLE TO READ DASM C SOURCE CODE). i know dasm's documentation it's done by professionals, but there are too not advanced programmers that don't know how to interpret certain references to pseudo ops in that short document. if you take a look in a search about this subject(into atari age forum) you will find several people asking for examples, and there we are, not always a document is enough for everybody. e.g you are using pseudo ops and there is something you cannot understand, then you search and search with that opcodes at google... and there are no examples in the internet. i love dasm and im really greatfull about it, but there is a lack of examples in some cases. then you are stuck like this user needing more examples so sometimes this is really harsh and you know, you can get out of answers and not wanting to write to the forum a zillion times. i had an issue about macros, talking about macros arguments, then years after i have found Thomas in the dasm forum talking about that. https://github.com/dasm-assembler/dasm/issues/15 and here recently(recently found this old post) then i was trying to understand with this examples if it is possible to do some kind of array or table of macros so i have found this post https://stackoverflow.com/questions/51217465/dasm-directives-pseudops and found this same user here asking for it(what i think it's near what i need, really dunno) ok, that's all Andrew, thank you for answering and for your work. i would love to be able to write some examples for dasm being able to read it's code in this cases where you feel that I NEED AN "EXAMPLES FOR DUMMIES." cheers!! pd: sometimes when i think about examples or documentation i remember dasm's preface from peter in 2008 and when you look all the documentation versions you will find that there is not a stack of examples or documentation added until this days since peter said that. 😱 PREFACE FROM PETER (APRIL/2008) Everything Andrew says above is still true, there have been a few sporadic updates to the documentation but no major ones, not even Olaf Seibert's changes from 1995 have been integrated, to say nothing of Thomas Mathys' F8 backend from 2004. We are urgently looking for volunteers to help with the documentation!
  16. this is crazy, i'm looking since days and days, and nope!! there is no exclusive tutorial about dasm, there is the great tutorial by Andrew Davie about atari 2600, but there is no "exclusive" "dasm tutorial" this is so sad, there are a lot of good ideas not being fully explored with lack of examples, i would love to help doing some dasm documentation but i'm not a c programmer!! and i see... your post is from 2009, all this years with no new examples or tutorials about dams is craziness!!
  • Create New...