bugbiter

Hi! my first approach was exactly like youre saying. I thought I could just make a greyscale pic of the bmp of luminance and one of the chrominance and voila, i could display that easily because gr. 9 is lum and gr.11 is chroma, but it didnt look right. Firstly, high lumina colors on the atari are all nearly white, i.e. they have low saturation. A high intensity red for example has 100% lumina, 100% saturation and chroma 1 on the pc bmp file. You translate that to chroma 3 (red) on the atari and luma 15 and what do you get? Not at all a pure red but nearly white. So I tried all sorts of correction curves, to give all the pure colors lower max luminas, and turn all the lower saturated areas to grey (chroma 0), but the results were not satisfactory... Then I had the idea of comparing bmp rgb values to the atari pallette and that was the breakthrough. HSB model I think will get better results with dithering. But the palette files are all in rgb.....

a8ia, I have an 800 myself and I know the current version will not run under 48K simply because there is too little memory left with frost basic. The Atari Basic module gives you enough free user memory but the loader makes great use of the turbo basic features (Bload etc). I am currently working on substituting these routines with assembler so it is possible to get a working 48 version soon. If you can't wait i can dig up one of the earlier versions which run with 48 k but it wont have the menu based loader though... I love my 800 and I want to have it the bgp loader also :-)

WOW-these look very good! You seem to really dig deep into colour theory! Thanks for the link, thats really advanced stuff! The orthogonal colour distance I really worked out myself, nice to see it here again :-) I haven't read through all the link's content. One Idea that I came across earlier already is that it might be better to deal with a source BMP in HSB(hue,saturation,brightness) colourspace rather that rgb. The dithering algorithm handles the three channels completetly independant from each other, meaning that a dithering 'spot' will occur once in a while in R or G or B individually, leading to those colour 'speckles' especially in almost grey areas. If you use a hsb model, you dont get red blue or green dithering 'speckles' but the color dithering will just shift the hue into an adjacent colour occasionally which might look better. Most pics (specially the pinups :-) are in portrait mode, so there is need for a ratio handling. Of course you can always crop a bmp to 'landscape' before converting, but automatically fitting it to size is very cool. Filling the border with zeroes in the border is just fine now but in the long term I feel the urge we should not just pad the picture out but make a bgp pic with a genuinely smaller x resolution and set it into the center in the viewer. (save disk bytes and loading time) If you look at my header configuration you will see that the first header double bytes after the 'mgic string' include the x/y size and an x/y position for the bgp pic. I was trying hard to put as much useful information into the header to begin with. Only my viewer doesnt use the size and position info yet. But I will add it some time :-) I'd really like to make the header guarantee backward compatibility with future improvements. Thats why I also added the 'auxbyte'-block in the header which is just being skipped now but could hold further infos in the future. For example I think the header should also keep infos about which source pic was used and how and with which parameters it was converted.. Any suggestion about this are very welcome, I'm working this all out myself for the first time now, maybe there's a better way?

Hmm, when I add an endless loop after closing everything is ok. seems like its normal behaviour of ddt, jumping to strange areas after rts of the code..

FOUND IT! FOUND IT! line 0330 STA ICBAH+1,X must read 0330 STA ICBAH,X ICBAH is the high byte alrady, no +1 needed.. :-))) Now its loading but it still hangs... Oh, well...

Hi! I'm trying to transfer my APAC239i picture viewer from Turbo Basic to assembler bit by bit. I want to start with the disk loading routine which will make loading the pic faster. (Instant rewarding when I'm done :-) I came across the book 'Peter Finzels Hexenküche' which gives an example for using the CIOV routine, However there are some misprints in the OCRed web version, but I think I found them all out now. I wrote a straightforward routine in MAC/65 for opening any file on D:*.*, transferring 960 bytes from file to the screen RAM and closing the file. When I execute the code in DDT (G8000) open doesnt work. You hear the familiar purr and then it stops with the pc at 0000 (BRK).. I guess I cannot run the code properly step by step in ddt because of time critical behaviour, so I cant find out what is going on. This is the most basic thing anyone does with a disk drive, I mean come on, I cant even find one single standard example routine for that on the web... grrr.! can someone please look at my code and tell me what I'm doing wrong? OK, here goes: iocb6.txt 10 ; SAVE#D2:IOCB6.M65 20 ; 30 .OPT OBJ 40 ; .OPT NO LIST 50 ; 60 CIOV = $E456 70 IOCB = $0340 80 ICCMD = IOCB+2 90 ICBAL = IOCB+4 0100 ICBAH = IOCB+5 0110 ICBLL = IOCB+8 0120 ICBLH = IOCB+9 0130 ICAX1 = IOCB+10 0140 ; 0150 *= $8000 0160 ; 0170 ;------------------ 0180 JSR OPEN 0190 JSR BGET 0200 JSR CLOSE 0210 RTS 0220 ; 0230 ;------------------ 0240 OPEN 0250 LDX #16*2 ;16*CHANNEL 0260 ; 0270 LDA #3 ;3=OPEN 0280 STA ICCMD,X 0290 ; 0300 LDA # <FILENAME 0310 STA ICBAL,X 0320 LDA # >FILENAME 0330 STA ICBAH+1,X 0340 ; 0350 LDA #4 ;4READ,8WRITE 0360 STA ICAX1,X 0370 ; 0380 JSR CIOV 0390 ; 0400 RTS 0410 FILENAME .BYTE "D:*.*",$9B 0420 ; 0430 ;------------------ 0440 BGET 0450 LDX #16*2 ;16*CHANNEL 0460 ; 0470 LDA #7 ;7=GET CHAR 0480 STA ICCMD,X 0490 ; 0500 LDA 88 ; DESINATION 0510 STA ICBAL,X 0520 LDA 89 ; SCREEN 0530 STA ICBAH,X 0540 ; 0550 LDA #960&255 ; LENGTH 0560 STA ICBLL,X 0570 LDA #960/256 ; 960 BYTES 0580 STA ICBLH,X 0590 ; 0600 JSR CIOV 0610 ; 0620 RTS 0630 ;------------------ 0640 CLOSE 0650 LDX #16*2 :16*CHANNEL 0660 LDA #12 ; 12=CLOSE 0670 STA ICCMD,X 0680 ; 0690 JSR CIOV 0700 ; 0710 RTS

Thanks a lot! great pics.. luckily I have an ntsc 1200 xl and monitor :-)

Your pics are running in an endless loop for the millionth time on my PAl crt and I'm beginning to think that your dithering algorithm gives better results than mine. Less colour speckles. How did you do it? can't wait to see your code...

Andreas, I think your question is answered. Take a look at the Happy-computer Sonderheft scans from Irgendwer- in the title picture you can see the purple two-line menu at the top of the screen like in his paint256 program. I remember too that the Happy-Computer one was in the flicker mode...

Aahh, memories.. wunderbar! this started it all for me.

looking very good without dithering. Those pictures are quite colourful, Floyd steinberg will help a lot with less saturated areas.. keep on coding, I can't wait!!

I was thinking of combining with shifted Gr.10 lines as well to achieve the HIP effect. To get the HIP effect, you have to alter gr.9 and gr. 10 on each line, but we are also forced to alter chroma and luma each line for APAC mode so either luma or chroma will always be gr.10. for example: even fields: 1: gr.9 luma 2: gr.10 chroma 3: gr.9 luma 4: gr.10 chroma etc... odd fields: 1: gr.10 chroma 2: gr.9 luma 3: gr.10 chroma 4: gr.9 luma etc.. That being the case, the HIP effect will not show because luma is always the same mode and therefore never shifted 1 color clock.. SAD! Where's JAC! ? I think he was the first to discover the gr10 shift. Perhaps he has an idea about that.

Boy, you are fast! Looking forward to it

i get an error from windows, archive is invalid.. I'm at work, will try again at home, maybe some restrictions here...

Thanks a lot, Stephen! Please repost, it's still broken. I hope I can use it with my sio2sd :-)) My viewer only supports up to I think 56 entries for the menu, as dos2.5, APE and AspeQt only show the standard 64 files in the dir.

Awesome! well, youll probably need the source code for the colourmatch routine. Ive still got the slow basic colourmatch routine somewhere as well.. The math is trivial. For each pixel you just compare all 256 palette entries from the laoo.act palette file to the original bmp rgb color. The distance of these two colours in rgb colourspace is sqrt(delta_red^2+delta_green^2+delta_blue^2) the colour with the smallest distance to the original one is chosen. (as we are just looking for the smallest distance you can as well skip the square root and thus save time..) Add floyd-steinberg dithering and youre done. If youve got any questions, I'm here :-)

Thanks for the post, Charlie I'll check them out! So the flicker APAC Mode has not been named officially in all those years?? I'd love to have a fast converter for all the pc file formats. Too bad I don't know how to code C or Java or else what you need for that.. So- well, here's my Turbo-Basic solution for BMP to flicker APAC: TurboBasicXLv1.5 - BGP Maker.atr You need a windows .BMP File. Take irfanView for example to.. - resize/resample it to 80x239 pixels - flip it upside down (bmp is encoded last line first, normally) - save it to H: uncompressed, byte order should be blue,green,red In the converter, enter filename without .bmp extender You can enter an optional description of the picture, Return will be registered as eol, backspace is working within one line. START starts conversion. During that, the border will show the converted colour of the current pixel. The white missile is the 'progress bar' :-)one step to the right for each finished line. USE AN EMULATOR AT FULL SPEED! Default drive for source .bmp and output file is H: You can change that in line 360. If you want to try without dithering, change dither to zero in line 660. After conversion the hue and bri files on the H: drive can be deleted. The .bgp file is the output picture! enjoy!

..and here are the files: BGP-PICS1.rar

Here are some more: And I just love that one almost 3D... if you want to load from D2: or H: , just change H$ in line 180.

I remember that Issue! I think it was a type-in program, right? I have lost the disk with that program though. Thats exactly the mode Im talking about. Do you know if the programs are available somewhere? Didn't have diditized images then-I think I doodled around with the painter a while but didn't amount to very much. It was running awfully slow as I recall...

Thanks a lot. I'll post more pics and I'll also give you my Turbo Basic converter.. :-)

Don't worry - it'll look fine on NTSC. The image will be a little taller though.. Most important is that your machine has a decent GTIA chip. I've seen HUGE differences there. Most GTIAs show those nasty dark gaps between certain Gr.9 luminances which cause the pictures to have ugly 'shadow areas' (And I don't mean the faulty chinese ones) I have 13 Atari machines in my basement collection but only 2 of them have a really clean GTIA Gr.9 image without any gaps.

I've got a small 10" PAL/NTSC multimode CRT monitor which makes the 80 horizontal pixels look very nice and small :-) In any case its good to stand back from the monitor a bit with gtia modes... I was really surprised to see NTSC in full colour here! It works! But maybe only on a 1200xl as it has the notoriously high colour saturation anyway? (good thing: 60hz nearly makes it flicker-free:-) @ Rybags: just turning one blank line in and out wouldnt give me 240 resolution, just duplicating the 120. I ve got luma and chroma here 240 lines each! :-) Thanks for the luma 2 hint, I will try it!

I wanted to do this since the 80s... In all those topics about APAC modes I only ever see the 'static' mode with 96 lines Gr.9 (lumina) and 96 lines Gr.11 (chromina). I always hated the dark lines and the resulting low vertical resolution in that mode. So I swap the Gr.9/Gr.11 lines in every VBI, showing a picture with full vertical resolution of 240 lines(239 really because of the 240 line bug). I dont think the flicker is so bad, it just reminds me of an ordinary interlaced tv picture. What do you guys think about it? Actually, it works fine with NTSC on my 1200xl - I always thought you need PAl to blend the line colours on a crt. I always wanted to be able to see my own photographs on the good old atari.. I therefore wrote a converter for windows BMP pictures in basic. On atari800Win Emulator in warp mode conversion of one picture with dithering takes 3 minutes.. :-) I've read about this mode but I've never seen it anywhere. If it is already here somewehere you may well bash me about it :-) Its so great having all the tools and emulators these days, makes coding and debugging for the atari so much more effective and fun! I really enjoy coding like in the old days but now with every resource and information available to me. I didn't have that in the old days... The disk starts the autorun.bas file automatically. after the memory overview press any key to start initializing the Display List and the LMS adresses. You can then choose the picture file with the cursor keys of a real atari, meaning up and down on an emulator would be "-" and "=". Only two pictures fit on the disk, sorry.. they're each 19KB after all! Return loads the file. Greetings, Martin TurboBasicXLv1.5 - BGP Viewer.atr

I just spotted an 850 on ebay. Is there anything useful you can do with it today? Or has it only collector's value?