Felix Palmen

it's very comprehensive...

you know this document? zimmers.net/cbmpics/cbm/c64/vic-ii.txt

I'd have to research this myself, but that's what I assume...

not sure I understand what you mean. It is impossible to have more than 25 text rows, it is possible to move text rows down the screen (and where you do that, the VIC might display what it already has (repeating the text row) or nothing ($3fff idle gfx)

so, scrolling the screen down always means delaying badlines. as for what's displayed, this might be the same data again or "nothing" ($3fff).

well, the VIC will not fetch the same data twice during one frame, right. It might display what it fetched multiple times, but when there IS a badline, new data is fetched :)

I'd have to experiment. I know this outcome is possible (repeated lines), but triggering idle mode is possible as well... in any case, what you do is delaying the next badline :)

but in any case, you delay one badline by the amount of lines you want the rest of the screen scrolled down ;)

yeah, makes sense cause it's getting into details now I guess. I'm not sure right now how you can achieve "repeated display" instead of idle mode, my guess is it's a matter of exact timing when you change y-scroll

That's impossible. Each badline fetches the next row from screen/color ram.

Huh? Me, just because technically, scrolling down the screen is delaying badlines ;)

1.) which is exactly the same -- the badline fetches the new data (from screen AND color RAM), to delay this until you're further down the screen, you avoid the badline condition by fiddling with y-scroll.

well, see my answer ;) ok, I just assumed opening the border doesn't have to be explained :o -- still two things: 1.) avoiding the badline by fiddling with y-scroll can also leave the vic-ii in idle mode, depending on your timing, 2.) the color ram is read in the same fetch as the screen ram, so it will be organized the same way (and displayed "scrolled down")

@mbomb007 the tips tag was added later, and not by the OP. It wasn't entirely clear, although it looked like a tips question.

Is this a challenge or asking for tips?

To me, this doesn't look like a challenge, more like asking for theoretical knowledge. I think there is a SE site dealing with algorithms?

@DLosc good idea, will do when I'm on the pc!

Hmm ok I see. Yes, input must be valid C, so if the constellation can't happen, you're fine. I just have the problem that I want to keep the challenge accessible without knowing C and further complicating the rules would be bad...

@DLosc in valid C, this can only appear inside a string literal, but therefore you have to handle it, so I don't see why it would make a difference?

@DLosc yes to your first question. I don't quite understand the second one :o

@Lynn this is modeled after a tool I created for myself a long time ago. The few nitpicks from the comments here were quite simple to add (you still have to look only at the single characters surrounding the whitespace sequence), otherwise I wouldn't have added them at all. The more complicated part still is handling line continuations and preprocessor directives correctly. But as I said, there won't be any more refinements to the rules by now :)

@Lynn there won't be any more rules by now. Steadybox found a test case that might have a practical relevance, but that's for it. If the tool with the current set of rules creates something invalid from a valid input, so it be.

@TobySpeight is this even allowed? Yes, you can assume that, as I commented earlier, I expect the input to be a reasonable "pre-golfed" source. Just as stated in the rules, the first character has to be a #.

@Steadybox ok, then it should be in the rules as well. I hope this isn't too complex yet

@Steadybox good catch, that's probably worth another special rule indeed.

@Steadybox That's true, but I assume "pre-golfed" input. Handling edge-cases like this would make the tool too complex, especially for implementing it in a challenge. In practice, you'd probably just write ++i+n instead anyways.

@EriktheOutgolfer C code may contain "extended" characters, but it's safe to ignore them and for the purpose of this tool, supporting the basic character set is enough.

@NahuelFouilleul indeed I missed that one :o Thanks! I adjusted this rule and hope it doesn't bug anyone already working on a submission :) (also a bugfix for my existing tool ...)

@Arnauld regarding your question, I added a paragraph to clarify. The input is assumed to be valid C source, this also means it only contains printable ASCII, tab and newline.

@HyperNeutrino it's of more practical use than just removing comments (and also more complex), and it's (hopefully) exactly specified, something I didn't find in other related challenges yet.

(or I'll make my girlfriend happier by taking her to the furniture store ... she needs another wardrobe ... ahem ...)

@ASCII-only good idea :D already thought that this looks like something that can be optimized/golfed quite nicely in 6502 assembly for a C64, I should probably try (yes, I'm crazy about this machine)

Hmm, quick approximation from what I observe, I expect a result in another 3 hours ... dammit ...

30 minutes and running .... tired

gonna take a shower and let the virtual 6502 work like crazy :)

measuring runtime on a C64 makes me sleepy right now ...

finally, "findclique" for the C64 :D (unfortunately quite large....)

damn, I crashed my C64 emulator :o

nevermind

ah sorry, misread

huh? checking for a prime is a a computable problem ...

@Mego alright ... "golfing" is more-or-less a must do for any reasonable C64 code ... limited resources :)

I'm aiming for minimal code size, but for my challenge, it will be MUCH larger than some other languages...

ok thanks all! @Mego that won't be a problem, there are already 11 answers and I seem to be the only crazy guy here trying to find solutions on a C64 ...

btw question to all ... is it ok to add an answer to an own challenge? nothing competitive, just for the fun?

@EriktheOutgolfer cleaned up here :)

@EriktheOutgolfer should we clean up the comments about the wrong results I got only with this strange msys2 python implementation?

The interesting thing is that I get the same result with your python2 implementation :o Ok I'll have to leave now, but I'll definitely have a closer look at this

@EriktheOutgolfer I tested on a surface book with python3 from msys2 ...

I'm curious now :) It doesn't look like your program has a bug, I fed it several "randomly" generated 16-edges graphs and got the correct result every time...