billkendrick Posted March 31, 2021 Share Posted March 31, 2021 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!) 1 Quote Link to comment Share on other sites More sharing options...
bob_er Posted March 31, 2021 Share Posted March 31, 2021 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'? Quote Link to comment Share on other sites More sharing options...
billkendrick Posted March 31, 2021 Author Share Posted March 31, 2021 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. Quote Link to comment Share on other sites More sharing options...
bob_er Posted March 31, 2021 Share Posted March 31, 2021 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 ). Quote Link to comment Share on other sites More sharing options...
billkendrick Posted March 31, 2021 Author Share Posted March 31, 2021 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!) Quote Link to comment Share on other sites More sharing options...
Yaron Nir Posted March 31, 2021 Share Posted March 31, 2021 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? Quote Link to comment Share on other sites More sharing options...
pps Posted March 31, 2021 Share Posted March 31, 2021 (edited) 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 March 31, 2021 by pps added summary at the end ;) 2 Quote Link to comment Share on other sites More sharing options...
danwinslow Posted March 31, 2021 Share Posted March 31, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
apc Posted March 31, 2021 Share Posted March 31, 2021 @billkendrick IMHO your DLI routine takes too much time. Your DLI must be very fast to handle DL interrupt on every line. Jan 1 Quote Link to comment Share on other sites More sharing options...
sanny Posted March 31, 2021 Share Posted March 31, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
TGB1718 Posted March 31, 2021 Share Posted March 31, 2021 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 1 Quote Link to comment Share on other sites More sharing options...
apc Posted March 31, 2021 Share Posted March 31, 2021 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... Quote Link to comment Share on other sites More sharing options...
pps Posted March 31, 2021 Share Posted March 31, 2021 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... Quote Link to comment Share on other sites More sharing options...
ivop Posted March 31, 2021 Share Posted March 31, 2021 (edited) 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 March 31, 2021 by ivop 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted March 31, 2021 Share Posted March 31, 2021 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 1 1 Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted March 31, 2021 Share Posted March 31, 2021 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... 1 Quote Link to comment Share on other sites More sharing options...
TGB1718 Posted March 31, 2021 Share Posted March 31, 2021 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 ? Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted March 31, 2021 Share Posted March 31, 2021 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 Quote Link to comment Share on other sites More sharing options...
ivop Posted March 31, 2021 Share Posted March 31, 2021 (edited) 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 March 31, 2021 by ivop Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted March 31, 2021 Share Posted March 31, 2021 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)... Quote Link to comment Share on other sites More sharing options...
apc Posted April 1, 2021 Share Posted April 1, 2021 @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: APOD picture vs Atari (my green seems over saturated): vs vs apod-changed-files.tar.gz Jan 2 Quote Link to comment Share on other sites More sharing options...
billkendrick Posted April 1, 2021 Author Share Posted April 1, 2021 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. Quote Link to comment Share on other sites More sharing options...
billkendrick Posted April 1, 2021 Author Share Posted April 1, 2021 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: And also in 80x192 4,096 colors! 3 Quote Link to comment Share on other sites More sharing options...
billkendrick Posted April 1, 2021 Author Share Posted April 1, 2021 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 ) 8 Quote Link to comment Share on other sites More sharing options...
pps Posted April 1, 2021 Share Posted April 1, 2021 ... good to see, that the community could help ? 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.