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 > Cycle count in upperborder
2008-09-23 11:00
Barbarossa

Registered: May 2007
Posts: 31
Cycle count in upperborder

Hi guys,

When trying to put together some timing scheme I noticed something I cannot explain.

When I singlestep trace my rasterinterrupt (I use CCS64) which triggers at raster $000, on the first line everything behaves fine. But on the second line ($001) and furtherdown, the cycle counter jumps from 56-58 to 8-10 as if sprites were active.

Sprites are active on the screen however only from Y=$36 to Y=$76.

What I am missing here? There cannot be bad lines in the border, and I am certain there are no sprites active. Why is the VIC stealing my cycles?

Some insight will be greatly appreciated.

Thanks.

John
 
... 8 posts hidden. Click here to view all posts....
 
2008-09-23 15:23
Barbarossa

Registered: May 2007
Posts: 31
I can check it, but you know how does things go. Digging up the C64 out of a closet and plugging it on takes some time :-) And then I have to write some program to check, because there is not such thing as a cycle monitor on the real thing.

It could be a bug, however I doubt it. I have seen most things work like a charme on CCS64.
2008-09-23 16:22
Ninja

Registered: Jan 2002
Posts: 406
CCS is good, no doubt. Still "most things" is way not enough for a reference, especially as this issue qualifies as a corner-case. I think you get my point :)
2008-09-23 16:25
chatGPZ

Registered: Dec 2001
Posts: 11130
also by now ccs is probably the least accurate of the "big three" when it comes to VIC :)

and yes, please write a testprogram.... wouldnt mind to test it on peters fpga core :)
2008-09-23 17:12
Krill

Registered: Apr 2002
Posts: 2850
Ninja is 100% right.
2008-09-23 17:24
Barbarossa

Registered: May 2007
Posts: 31
@Ninja

I get your point. I will try to do some tests on the real thing when I get the chance. I did do a test with sprite 0 on Y=0. The spritedata is fetched during rasterline $000. And this worked ok in CCS64.
Could it be humble me stumbled on to something new :-)

@Groepaz

I noticed most of your hardcore guys here use Vice. I started out on CCS64 and it is difficult to change your habbits (I glanced at it once and didn't like the interface). I changed crossassembler once, and that was a long proces I would not like to repeat. But you are probably right that you are using the best Emulator. I am not a really hardcore democoder and learned the VIC tricks the last few years, so I guess for my needs CCS64 is suitable.

To sum it al up. I know now why the VIC steals cycles in the upper border, but it should also do that in line $000, which is probably a bug of the emulator. Right?


2008-09-23 18:08
Krill

Registered: Apr 2002
Posts: 2850
Sounds like an emulator bug indeed, though i haven't confirmed it.
2008-09-23 21:06
assiduous
Account closed

Registered: Jun 2007
Posts: 343
Quote:
.pc = $1000

sei
lda #<irq1
sta $0314
lda #>irq1
sta $0315
asl $d019
lda #$7b
sta $dc0d
lda #$f1
sta $d01a
lda #$1b
sta $d011
lda #$20
sta $d012
cli

loop: jmp loop

irq1:
lda #$ff
sta $d015
lda #$24
sta $d001
sta $d003
sta $d005
sta $d007
sta $d009
sta $d00b
sta $d00d
sta $d00f
lda #<irq2
sta $0314
lda #>irq2
sta $0315
lda #$00
sta $d012
asl $d019
pla
pla
pla
rti

irq2:
nop
nop
lda $d012
sta $0400
lda #<irq1
sta $0314
sta $d012
lda #>irq1
sta $0315
asl $d019
pla
pla
pla
rti


verified to give "A" ($01) in the top left corner of the screen on a real C64C, in Hoxs64 v1.0.5.25 and in VICE v2.0. "@" ($00) is displayed in CCS64 v3.6 suggesting a bug in this emulator.

Quoting Groepaz
also by now ccs is probably the least accurate of the "big three" when it comes to VIC :)

this is correct,CCS is a real minefield of emulation flaws as far as i can tell from what i`ve seen. Vice is not flawless either but it has improved abit recently. Hoxs64 remains unbeatable when it comes to these "corner cases" and the overall emulation accuracy.
2008-09-24 06:29
Martin Piper

Registered: Nov 2007
Posts: 637
It is just a shame Hoxs64 doesn't have such good debugging related support as VICE. :(

What would be really useful, which none of the emulators support at the moment, is being able to set a cycle level break point for a position on the screen and inspect CPU/VIC/CIA/SID with single cycle stepping.
2008-09-24 10:03
assiduous
Account closed

Registered: Jun 2007
Posts: 343
these features and many other debugging options would have been added to Hoxs long ago but the emulation accuracy fixes take top priority at all times and theres been alot to fix since the research on the C64 intensified in the late 2007.
2008-09-29 06:32
Martin Piper

Registered: Nov 2007
Posts: 637
Quote: these features and many other debugging options would have been added to Hoxs long ago but the emulation accuracy fixes take top priority at all times and theres been alot to fix since the research on the C64 intensified in the late 2007.

If you need any help improving the debugger I'm more than happy to donate my coding time.
Previous - 1 | 2 - Next
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
Bansai/BSILabs
Guests online: 111
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 Memento Mori  (9.6)
10 Bromance  (9.5)
Top onefile Demos
1 It's More Fun to Com..  (9.7)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Rainbow Connection  (9.5)
7 Dawnfall V1.1  (9.5)
8 Quadrants  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)
Top Groups
1 Nostalgia  (9.3)
2 Oxyron  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Crackers
1 Mr. Z  (9.9)
2 Antitrack  (9.8)
3 OTD  (9.8)
4 S!R  (9.7)
5 Faayd  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.052 sec.