Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > How does linecrunch work ?
2003-02-17 11:49
Majikeyric

Registered: Sep 2002
Posts: 83
How does linecrunch work ?

Hi everybody !!!!

Can someone explain or point me to a web site where I could find information about linecrunch ???
I think it allows to scroll bitmaps but I don't know how ???

thanks.
2003-02-17 13:41
Nightlord
Account closed

Registered: Jan 2003
Posts: 131
there is an article called bfli by pasi ojala in c hacking issue 10. check it out at:
http://www.ffd2.com/fridge/chacking/
there is some info about linecrunch in there about the vic fooling by d011 trickery. the best overall vic source in my opinion is vic-ii compendium at:
http://www.informatik.hu-berlin.de/~koethnig/vicii/eindex.html

all kinds of vic-ii counter fooling stuff is well explained in there
2003-02-17 14:26
Majikeyric

Registered: Sep 2002
Posts: 83
Thanks nightlord I gonna read this ;o)
2003-02-17 14:38
CyberBrain
Administrator

Posts: 392
The VIC-article is also in nice text-format, so you can download it:
http://ftp.martnet.com/martnet/commie/documents/chipdata/VIC-Ar..
2003-02-18 12:55
tecM0

Registered: Jan 2002
Posts: 41
another great VIC_infopage:
http://www.minet.uni-jena.de/~andreasg/c64/vic_artikel/vic_arti..

point 3.1.14 explains linecrunch...a little bit...

tecM0/+H
2003-02-19 09:30
Majikeyric

Registered: Sep 2002
Posts: 83
Thanks everybody !!!
2003-02-19 12:48
Graham
Account closed

Registered: Dec 2002
Posts: 990
be aware that linecrunching causes trouble on some machines. when doing linecrunching on these some bits in memory will be randomly cleared in most cases. on my flat c128 linecrunching only works after testing it several times and turning the machine off and on again between each test.... but IF it runs, all linecrunching demos and games do run.
however this is not a c128 problem like some people believe. it's a problem of VIC revisions. machines with 8562/8565 VICs don't have this problem (C64C, C64G and C128DCR). problems only occur on the flat c128, the old c128d and old c64's. i even have seen one c64 which wasn't able to do plain FLI.
2003-02-19 17:05
Ninja

Registered: Jan 2002
Posts: 418
a c64 that cannot do FLI? Wooow, wanna have, ULTRA-RARE, big bucks on ebay!! ;))
2003-02-19 23:46
algorithm

Registered: May 2002
Posts: 707
It might be a power supply problem. I know it sounds very unusual.

All demo's and games which shift the screen horizontally using a graphic trick (placing specific byte combinations in $d011 followed by a self modified delay and yet another value in $d011) would seem to randomly crash the entire system.

During my C64 days (A very long time ago) I had created a small utility which would test this and give a report on the amount of bytes that were corrupted. If it did this or crashed (Due to the very possible corruption of program data) I would find that switching the system off and on would sometime solve the problem.

Mind you, this would sometimes have to be done 7 or 8 times.

After a while, I got a new power supply unit and guess what. This problem never happened again!!

I had previously read somewhere that the the linecrunch routine causes the VICII chip to draw in more power and a faulty or weak powersupply would cause memory corruption. Who knows...


2003-02-20 08:50
Shadow
Account closed

Registered: Apr 2002
Posts: 355
I have this problem with my C64 (new model, not the breadbox).
Many demos that have graphic scrolling lock up after just a few seconds. Never had any issues with games though, and FLI etc. works perfectly.
2003-02-20 14:01
Graham
Account closed

Registered: Dec 2002
Posts: 990
"new model" doesn't mean anything except for the casing. it most likely still has an old board inside with 65xx ic's.
2003-02-21 19:01
raven
Account closed

Registered: Jan 2002
Posts: 137
well none of my machines have this problem (old,new,flat 128, 128D) but i've seen it happen on one machine (c64c) at X2001..

Thats one very interesting problem
2003-02-22 12:44
Cybernator
Account closed

Registered: Jun 2002
Posts: 154
I've tested all my C64s, and the only thing that doesn't work on old ones, is $DE00 programs.

One of my new C64s works fine, except with Insomnia (of course there must be something else, but this is what I have found so far). The computer simply locks up at the beginning. I suspect that CIA2 is blown. One old C64, gives me a message saying something like: "Disk drive not present", although it works with other programs as well.

@Raven: What does your code do at the beginning? (Before the screen fader). I guess it installs the fastloader into the 1541s memory. So most probably it's CIA2. But strange thing is that everything else I've tried so far, works perfect.

@Graham: Btw, on your site I've read that the 8500 is 6510 with different pin layout. I haven't tried to swap the processors, but I've seen an old C64 with 8500 processor (it didn't seemed to be resoldered at home). It worked normally. Are you sure it's the pin layout? I assumed it was the voltage difference here.

Btw, anyone knows the difference between 6526-A (used in new C64s), and 6526 (used in old C64s)?
2003-02-22 22:27
Stryyker

Registered: Dec 2001
Posts: 469
I think the A means 2MHz mode available too.
2003-02-25 12:59
yago

Registered: May 2002
Posts: 333
Concerning different CIAs:
There is a way of detecting them, one type needs longer for an IRQ (mist's diag-prg did this)

I also discovered memory-faintings when fidling with D011 on a "all-new" c64, and concluded that this does only happen when the c64 is not switched on a long time.
Don't know if this due to power-supply or other things..

Murphys Law regarding linecrunching:
It works on all machines, except on the organizers one.
2003-02-25 19:57
Cybernator
Account closed

Registered: Jun 2002
Posts: 154
Stryyker wrote:
"I think the A means 2MHz mode available too."

I understand using this chip in C128, but why would someone use it in a C64C ??? I've even seen CIAs like "6526A-1" and "6526B". What teh heck does this mean? :/

Yago wrote:
"Concerning different CIAs:
There is a way of detecting them, one type needs longer for an IRQ (mist's diag-prg did this)"

You mean the IRQ occurence is delayed? (In case I understood you right). I just made a little test-routine which uses double raster interrupt to stabilize, and then starts timer A of CIA1, which then generates interrupt and changes the border color. (DEN is set to 0, btw).
Then I've used both version of CIA, and the color change happened exactly at the same place.
I've probably misunderstood ya. Where can I find the routine you mentioned?

Yago wrote:
"I also discovered memory-faintings when fidling with D011 on a "all-new" c64, and concluded that this does only happen when the c64 is not switched on a long time.
Don't know if this due to power-supply or other things.."

Ok, I realize my English sux :P Do you mean the C64 was NEW-VERSION, or it was new (NOT RAPED)? :) Or maybe all NEW-VERSION _C64s_ you have tried?
Never noticed such a problem. Only that those grey dots (when changing border/paper color) may appear or disappear when switching the C64 on/off.

Yago wrote:
"Murphys Law regarding linecrunching:
It works on all machines, except on the organizers one."

Hehe :-)
2003-02-27 12:56
yago

Registered: May 2002
Posts: 333
To recognize the both CIAs (6526 & 8???), try the Program "diag" which might be found here:
http://www.weihenstephan.org/~michaste/mxass/
If it not included inside the Assembler anymore, contact me.

My "new C64" has all new Chips, SID, VIC, everything.
It has also a green LED, and msmakelas shiftlock-detection does not work as reliable as on other C64s (which seems to be an attribute of the mainboard/cia, NOT the keyboard).
I have also other "new version" c64 (to be honest, I use only non-breadbox-c64), but most of them have "old" chips.

The "dot"-problem can be used to manually detect a new VIC.
lda #0
sta $d011
loop: sta $d020
jmp loop


PS: "old" chips = 6xxx
"new" chips = 8xxx
2003-02-28 19:47
Cybernator
Account closed

Registered: Jun 2002
Posts: 154
Yago wrote:
"To recognize the both CIAs (6526 & 8???), try the Program "diag" which might be found here..."

Wait a minute, I've never seen 85xx CIA. New C64s are based on 85xx chips, except for the CIA. It still 6526 with "A" after the number. Or maybe there're some 85xx based CIAs which are unknown to me? If possible, please check the number of the CIAs in your C64.

Btw, please explain something more about the "shiftlock detection" you mentioned (or send me a link if there's any).
2003-02-28 23:26
Stryyker

Registered: Dec 2001
Posts: 469
My newer C64 had red LED.
2003-03-10 13:18
yago

Registered: May 2002
Posts: 333
Quote: Yago wrote:
"To recognize the both CIAs (6526 & 8???), try the Program "diag" which might be found here..."

Wait a minute, I've never seen 85xx CIA. New C64s are based on 85xx chips, except for the CIA. It still 6526 with "A" after the number. Or maybe there're some 85xx based CIAs which are unknown to me? If possible, please check the number of the CIAs in your C64.

Btw, please explain something more about the "shiftlock detection" you mentioned (or send me a link if there's any).


Concerning differences between left shift and shiftlock:

This is an excerpt from C=Hacking #7:

You can use this feature to distinquish between the left
shift and the shift lock keys, although they are connected
to same hardware lines. The shift lock key has smaller
resistance than the left shift. If you make both CIA 1
ports to outputs (write $FF to $DC03 and $DC01) prior
reading the left shift key, only shift lock can change the
values you read from CIA 1 port B ($DC01).)

Have Fun,
Zed Yago
2013-10-26 08:25
ChristopherJam

Registered: Aug 2004
Posts: 1424
So I've been playing with line crunch a little, but if I try to do it within the display area, I've only managed to crunch every second row of characters.

(eg, I can get VIC to display 8 lines of row 3, then 1 line of row 4, then 8 lines of row 5, then 1 line of row 6)

Within row 3, I tell VIC to delay row 4 by a line, then trigger row 4 at the time I would for FLI (ie with the three char bug area visible). I can then start row 5 in any of the next 7 lines.

Is crunching multiple adjacent rows down to single adjacent lines only possible if you start in the upper border, before the first char row has been displayed?
2013-10-26 15:43
ChristopherJam

Registered: Aug 2004
Posts: 1424
Never mind, got it working now :D
2022-06-15 08:58
Raistlin

Registered: Mar 2007
Posts: 771
I'm starting to code my first linecruncher (!) .. and hitting some snags. I can only get it to scroll 0-14px (!) instead of the 0-15px that I of course want...

Across 16 frames, I'm doing these D011 writes (VSYNC, HSYNC):-

Frame0: V01, H15 (D011 = $30) and V48, H09 (D011 = $31)
Frame1: V01, H15 (D011 = $31) and V49, H09 (D011 = $32)
...
Frame6: V01, H15 (D011 = $36) and V54, H09 (D011 = $37)
Frame7: V01, H15 (D011 = $37) and V54, H09 (D011 = $30)
Frame8: V01, H15 (D011 = $30)
Frame9: V01, H15 (D011 = $31)
..
Frame15: V01, H15 (D011 = $37)

These are the only $d011 writes that I do...

Frame7 and Frame8 end up the same .. so it seems that I have something out of step somehow - both frame 7 and 8 of course have a final $d011 value of $30... so I assume I'm doing -something- wrong here..?

Any help/advice at all would be great............
2022-06-15 10:40
Raistlin

Registered: Mar 2007
Posts: 771
One more small note with what I'm trying to do here ... I'm -hoping- that I can do 0-15px linecrunch-based scrolling without losing any of the vertical height of the screen .. ie. retaining all 24chars (192px).
2022-06-15 11:06
Krill

Registered: Apr 2002
Posts: 3098
Still not quite sure what you want to achieve, tbh. :)

Linecrunching does not lose you any char rows, but the wrapping point (screen offset $03ff->0 mid-row) and shifted screen contents below that become a bit cumbersome to handle.

One crunched char row equals upscrolling by 7 rasterlines, and you'd normally combine linecrunching with FLD (empty lines filled with $3fff idle pattern) for pixel-wise hardware Y-scrolling.
2022-06-15 12:00
Raistlin

Registered: Mar 2007
Posts: 771
Ahhh, thanks Krill! That was the last piece of the puzzle - and explains why I could only get 0-14px working instead of 0-15px (0-7px coming from the smooth scroll of D011 plus 0px or 7px depending on whether I crunched a line).

I have it working in my test function now... tomorrow I'll see whether I can get it working in a more useful way :-)
2022-06-15 12:37
Krill

Registered: Apr 2002
Posts: 3098
Glad i could help!

So the missing piece of the puzzle was that you'd set YSCROLL again after the crunched line, so you'd have 0..7 pixels of scroll-range above plus another 0..7 pixels of scroll-range below the crunched rows?
Or that you'd need to crunch 3 char rows (not just 2) in order to scroll up by 15 pixels? =)
2025-01-14 09:52
Digger

Registered: Mar 2005
Posts: 448
2025 and finally I am getting my head around to deepen my understanding of $d011 trickery.

So, is it possible to shorten all char lines to be 7 pixels high?
But WITHOUT charline duplication?

I want to force a badline every 7 rasterlines, and make VIC to read the new charline there. Possible? How?
2025-01-14 11:13
Krill

Registered: Apr 2002
Posts: 3098
Shortening a char row to 7 (or fewer) rasterlines will prevent the row pointer from advancing to the next 40 chars.

You can still feed new char data by switching screen base via $D018/$DD00 prior to triggering the next badline.

The screen memory layout will be somewhat funky, with 40 chars at N*$0400 scattered all over the memory space.

$D800 colours will remain the same, though, unless you overwrite them between the occurance of two badlines.
2025-01-14 13:16
Digger

Registered: Mar 2005
Posts: 448
Yeah, I know this mode and that's exactly what I do NOT want.
So no way to force advance the row pointer earlier?
2025-01-14 21:25
chatGPZ

Registered: Dec 2001
Posts: 11523
its called FLI :)
2025-01-14 22:06
Oswald

Registered: Apr 2002
Posts: 5127
this is an xy problem whatever you can solve with 7 pixel high char rows should be solvable with 8 line high ones
2025-01-15 00:42
Krill

Registered: Apr 2002
Posts: 3098
Quoting Oswald
this is an xy problem whatever you can solve with 7 pixel high char rows should be solvable with 8 line high ones
I thought XY problem as well, but for other reasons. =)

Digger: As in really, why is a scattered memory layout such a big problem that it invalidates the entire technique for your purposes?
2025-01-15 06:13
ChristopherJam

Registered: Aug 2004
Posts: 1424
You could possibly do something ungodly with alternating 6 line rows with 8 line rows, so RC would go 01234501234567, but do a FLI fetch on the 8th line to fetch from a second char screen.

In char mode you'd be alternating between two screens, and using the first 14ish rows of each screen. You'd have to use a couple of charsets, where the second one is rotated down a line, and also duplicates line 7 into line 0 for use on line 7 of the even char rows.

(so, you only move on to the next row address every second char row, but it's a lot closer to what you're asking for than never advancing)
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Frozen Fire
Andy/AEG
celticdesign/G★P/M..
aeeben
Guests online: 322
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Codeboys & Endians  (9.7)
4 Mojo  (9.6)
5 Coma Light 13  (9.6)
6 Edge of Disgrace  (9.6)
7 Signal Carnival  (9.6)
8 Wonderland XIV  (9.5)
9 Uncensored  (9.5)
10 Comaland 100%  (9.5)
Top onefile Demos
1 Nine  (9.7)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.5)
6 Scan and Spin  (9.5)
7 Onscreen 5k  (9.5)
8 Grey  (9.5)
9 Dawnfall V1.1  (9.5)
10 Rainbow Connection  (9.5)
Top Groups
1 Artline Designs  (9.3)
2 Booze Design  (9.3)
3 Performers  (9.3)
4 Oxyron  (9.3)
5 Censor Design  (9.3)
Top Organizers
1 Burglar  (9.9)
2 Sixx  (9.8)
3 Tim  (9.7)
4 Irata  (9.7)
5 hedning  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2025
Page generated in: 0.178 sec.