Jump to content
billkendrick

Attempting to make a Colorview (4096 color) viewer in cc65; Help Wanted

Recommended Posts

So a few months back I made a very simple little web app (just a PHP script) which would fetch the latest Astronomy Picture of the Day (APOD) and convert it to a few Atari 8-bit formats, so you could fetch it over #FujiNet.  It was as simple as OPEN'ing the URL, GET'ing the bytes, and POKEing them to screen memory.

 

The other day, I started putting together an actual 'client', in cc65, which does the same thing, with a slightly friendlier interface (than "type all this in BASIC").  Then I decided to spruce things up even more and added the ability for the server to spit out three greyscale images (GRAPHICS 9, 16 shades), after breaking the image into red, green, and blue components.  It should be obvious that my goal then became creating a ColorView mode on the Atari in cc65.

 

Welp, this is where my utter inexperience with this stuff comes to light. I've struggled with memory management (but I think I'm getting there, thanks to some posts by @Wrathchild in a thread @Yaron Nir started a few months back). And I'm also struggling with my actual Display List Interrupt.

 

So far I have a display list that invokes an interrupt (DLI) on every scanline (so each line is a different color: red, green, blue, red, green, etc.), and invokes a load memory scan (LMS) to interleave the three bitmaps (image 1, image 2, image 3, image 1, image 2, etc.).  Then I have a Vertical Blank Interrupt (VBI) that flips between three versions of this display list (an RGB one, a GBR one, and a BRG one).

 

My problem is I'm doing something that's causing a crash in my display list interrupt. (It's straight assembly code, currently as inline assembly within the C source.)

 

I'd love if someone could look at this and tell me everything I'm doing wrong with it, because I'm sure there's a LOT to unpack here. :) If you want to see the code, you can peruse it over in the #FujiNet github project: https://github.com/FujiNetWIFI/fujinet-apps/tree/master/apod

 

Thanks in advance!  I really need to learn more of these dark arts.  I was seriously spoiled by BASIC, TurboBASIC XL, and Action! back in the day, and C under more modern systems, these days. (Even C on BREW cellphones, almost 20 years ago, didn't really require any thought when it came to memory management!)

  • Like 1

Share this post


Link to post
Share on other sites

I'm not sure about cc65 (never used that) but first thing to check for me is branch correctness. Did you check jump value of 'bne'?

Share this post


Link to post
Share on other sites
3 minutes ago, bob_er said:

I'm not sure about cc65 (never used that) but first thing to check for me is branch correctness. Did you check jump value of 'bne'?

Well, right now, the `bne` isn't even happening.

 

If I add only ONE more opcode to the dli() function -- say, uncommenting the `asm("inc %v", rgb_ctr);`, or even just repeating that `sta` to COLBK, Atari800 emulator crashes. :(

Share this post


Link to post
Share on other sites

Please add for instance 'nop' inside the DLI. If that will still crash - check your memory/linker config. Maybe there is something wrong?

If that will pass - add next 'nop' just to check. Next step is to replace two 'nop's with one 'inc zp', etc... Do many small steps. That may help... (i hope :) ).

 

Share this post


Link to post
Share on other sites

Yeah, even just adding a NOP causes the crash. (Thanks for the idea!  Did I mention I'm extremely new to assembly language, too!? :) )

 

So it's almost certainly something about the memory set up. The memory configuration stuff is kinda black magic, so I think I'll need help from a cc65 guru. (I'd really love some kind of "cc65 on the Atari primer", or blog series or something!)

Share this post


Link to post
Share on other sites
Quote
/* FIXME: Still crashing */
  // asm("inc %v", rgb_ctr);
  // asm("lda %v", rgb_ctr);
  // asm("cmp #4");
  // asm("bne %g", __dli_done);
   
  // asm("lda #0");
  // asm("sta %v", rgb_ctr);
 

on which line does it crash?

Share this post


Link to post
Share on other sites

Phew, when I look into this lines of code, I never would use CC65 for doing asm. There are so many additional things you have to type in. That not even looks complicated, that for sure IS complicated 😳

 

But if I get it right, there seems to be no error in code at all. Maybe some of the additional stuff is wrong and results in unwanted asm code?!? EDIT: read further to get the bug.

 

My guess, what these lines stand for is:

dli
	pha
    tya
    pha
    
    ldy rgb_ctr
    lda rgb_table,y
    
    sta wsync
    sta colbk
    
//now the disabled code
	inc rgb_ctr
    lda rgb_ctr
    cmp #4
    bne __dli_done
    
    lda #0
    sta rgb_ctr
//end of disabled code

__dli_done
	pla
    tay
    pla
    rti

Maybe your rbg_table is to short, you need 4 bytes (0...3) for it's length...

Ahh found this:

unsigned char rgb_table[3] = { 0x40, 0xC0, 0x80 };

Just a length of 3 bytes defined. So I think this is the error.

 

I think when you always go for one line more, your DLI will run to far, so the screen crashes.

Edited by pps
added summary at the end ;)
  • Like 2

Share this post


Link to post
Share on other sites

you don't need to type it all those embedded asm() calls just because you need the variable linkages. You can see C symbols just fine in your .s files, just do the correct externs and .imports. That said, sounds like pps might be on to something.

 

  • Like 1

Share this post


Link to post
Share on other sites

I normally don't use inline assembly (neither in cc65 nor in other compilers). Try to put your asm routine in an assembler source file.

  • Like 1

Share this post


Link to post
Share on other sites
15 minutes ago, apc said:

IMHO your DLI routine takes too much time

That routine is not going to cause a crash due to the time it takes, all that may happen is you will see

unnecessary things on screen, as long as the DLI finishes before the next line starts it should be ok.

 

I think De-Re-Atari has a good paragraph on how long you can have 

  • Like 1

Share this post


Link to post
Share on other sites

 

47 minutes ago, TGB1718 said:

as long as the DLI finishes before the next line starts it should be ok

Yes, this is our case. For the combination of display list with interrupt on every scan line the routine must be really quick otherwise it will be entered again and again (new DLIs coming with each new line). Stack will be overwritten many times. Maybe at the end of the screen (no more DLIs) the end of DLI routine will be finally reached, but PLA and RTI is unlikely to get proper data from stack...

 

Share this post


Link to post
Share on other sites

It's not the length of the DLI, as it seems now, after looking deeper into the sources. But it might have to do with the wrong length or better wrong switch when y runs to 4. It should just run till 3, so values 0 till 2 will be choosen to look into the colors table, what is OK. So at least then the colors should be correct. 

 

Sorry that I can't help more. C never been my language... 

Share this post


Link to post
Share on other sites

To shorten your DLI, you invert the order of your table. Then it's just

 

    dey

    bpl __dli_done

 

   ldy #2

   sty rgb_ctr

 

Edited by ivop
  • Like 1

Share this post


Link to post
Share on other sites

If I were you, I'd really move the vbi and dli to its own .s file, so you can get rid of all the asm("") stuff.

 

dli
    pha

rgb_cnt = *+1
    lda rgb_table+2		; be sure rgb_table is page aligned!
    
    sta wsync
    sta colbk

    dec rgb_cnt
    bpl __dli_done

    lda #2
    sta rgb_cnt

__dli_done
    pla
    rti

Live coding in forum software :)  So, it should work ;)

  • Like 1
  • Haha 1

Share this post


Link to post
Share on other sites

Had only a very brief look, but your dlist_setup() already looks suspicious to me:

Your screen mem starts at $2C00 and by adding constantly 40 you come to a start address where ANTIC has to cross a 4k boundary, which breaks the display...

  • Like 1

Share this post


Link to post
Share on other sites

One thing to be aware of cc65 can sometimes alter your "in-line" code so that it doesn't look/run quite the same,

although for short code segments it might be ok, I think it's the optimiser that does this.

 

Have you checked the output to ensure it's as expected ?

Share this post


Link to post
Share on other sites

Hmmm, a little bit off-topic, but anyways...

 

Colourview is supposed to have up to 4096 colours (16x16x16) and that sounds fantastic. I have approx. 26 disk images with Colourview RGB pictures on them, none of them, really NONE of them has anything near 4096 colours, not even 256 colours.

 

So I am asking, what is wrong or does not work with Colourview ? The Gr. 9 Colourview pics I have do show approx. 3-4 colours each with 16 shades (thats 48-64 colours, not more) and most of these colours are greys, browns and violets in all their shades, the colours blue, red and green are rarely (almost never) seen in those pics. Is it because I am using PAL Ataris and Colourview works better/best on NTSC ? Or what else could be wrong ? The Gr. 15 Colourview pics (4x4x4) seem to work better, they easily reach 16-32 colours, but rarely 64 colours. Gr. 8 Colourview pics should get 2x2x2 = up to 8 colours or greys, but all I get is 2-4 greys with all of them. As said before, the most disappointing mode is Gr. 9 Colourview...

 

-----

 

Regarding a Colourview R,G,B (uncompressed) or .RGB (compressed) viewer, think I have 3 or 4 in my collection. One of them is by Clay Halliwell and written in Atari Basic (+MC, for compressed RGB pics), maybe this one or some of the others might help when programming yet another viewer ?

 

 

RGB_pics.zip RGB_SRC.zip

Share this post


Link to post
Share on other sites
20 minutes ago, CharlieChaplin said:

I have approx. 26 disk images with Colourview RGB pictures on them, none of them, really NONE of them has anything near 4096 colours, not even 256 colours.

That sounds like either bad source material (probably 256 color GIFs), or a bad converter.

 

BTW is this a flicker mode? I find flickering two screens barely bearable. Especially on PAL. Or does this mode keep a stable three lines "per line" display list? Then you just have to move your chair a couple of meters back to see the RGB illusion :)

 

Edit: ran one of CharlieChaplin's ATR images. It's indeed a flicker mode. Let's say I'm not a big fan of flicker modes, or sometimes erroneously called interlaced. PAL blending, I like (without flicker). I believe visually the same hapens on NTSC if you just sit a bit back from the monitor.

Edited by ivop

Share this post


Link to post
Share on other sites
1 hour ago, ivop said:

That sounds like either bad source material (probably 256 color GIFs), or a bad converter.

 

 

Well, since I converted some of the RGB pics myself (and indeed used 256 colour GIFs) I would say both. Jeff Potter's Apacview and Jview (they use NTSC colour palettes afaik) do only convert GIF87a into R,G,B or .RGB. I do not know of any JPG, PNG, BMP, TIF, etc. converter that converts into A8 Colourview R,G,B or .RGB mode.

 

Maybe a nice programming work for PC programmers: Make a program that converts JPG or PNG or BMP or TIF (e.g. max. 640x400 res., e.g. max. 65k colours) into three separate R, G, B pictures with a max. resolution of 80x192 pixels (16 red, 16 green, 16 blue tones)...  ;-)

 

 

Share this post


Link to post
Share on other sites

@billkendrick I believe DLI problem can be addressed 🙂

 

This is your linked display list with DLI running (+fixed start of screen to work with 4K boundaries), overlapping R-G-B stripes:

P1120437_1024.thumb.JPG.b4db596470542c39ea1ff77335195eaf.JPG

 

APOD picture vs Atari (my green seems over saturated):

APOD-20210331.thumb.JPG.91d104f4d73e932357a905d91f5495f7.JPG vs P1120443_1024.thumb.JPG.b01bfd97a94c2021d0063ad674add46a.JPG

 

APOD-20210331-RGB.thumb.JPG.3d75e85f2030ddb2aebda23003899dde.JPG vs P1120443_1024-RGB.thumb.JPG.57d7f1f426d8f5f6637a78c69db48267.JPG

 

 

apod-changed-files.tar.gz

 

Jan ;-)

 

  • Like 2

Share this post


Link to post
Share on other sites
12 hours ago, CharlieChaplin said:

Maybe a nice programming work for PC programmers: Make a program that converts JPG or PNG or BMP or TIF (e.g. max. 640x400 res., e.g. max. 65k colours) into three separate R, G, B pictures with a max. resolution of 80x192 pixels (16 red, 16 green, 16 blue tones)...  ;-)

This is exactly what my web app does (it's very dumb PHP that fetches the image from the APOD website and uses ImageMagick and some other stuff to convert the images to something the Atari can read 'directly'). :)

 

WRT APAC modes (both flickery 80x192 and non-flickery 80x96), that certainly could be done as well.  The main issue is mapping the hues from the source image to the 16 hues the Atari provides (and no doubt fiddling with gamma, etc.)

 

Not only am I not good at assembly yet, I'm also (ironically -- since I'm lead developer of Tux Paint) not that great with these low-level intricacies of graphics. :-D

Share this post


Link to post
Share on other sites

Awww yeaaahhhh!  Thanks again!  Here's a screenshot of the "gate" from Alternate Reality: The City, that I swiped from a Google image search and plopped in as a test image.  First, in 320x192 black & white:

 

20210401_003145.jpg

 

And also in 80x192 4,096 colors!20210401_003036.jpg

 

  • Like 3

Share this post


Link to post
Share on other sites

And here's a quick vid of the app loading a parrot sample image over #FujiNet. (I'm actually running the XEX of my program off of an Ultimate Cart, since I don't have a local TNFS server set up yet, and I hate dealing with microSD ;) )

 

 

  • Like 8

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...