You are not logged in.

afalc060

Unregistered

1

Tuesday, April 17th 2012, 1:34pm

Stolz: Erste Raster

für plus/4 8)



Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
.setcpu "6502"
.org $1001-2
.word $1001

.word link
.word 2012	; zeilennummer
.byte $9e	; sys-token
.byte "4109"	; adresse
.byte $00	; zeilenende
link:
.byte $00,$00

		sei
		lda #<raster
		sta $314
		lda #>raster
		sta $315
		lda #$02
		sta $ff0a
		lda pos
		sta $ff0b
		lda 65286
		and #%01101111	
		sta 65286	
		cli
		rts

raster:
		lda $ff09
		sta $ff09
	;	lda $ff0b
	;	cmp pos
	;	bcc rastersik

		ldx #98
loop:
		lda colors,x
spalte:
		ldy $ff1e
		cpy #176
		bmi spalte
		sta $ff19
		nop
		nop
		nop
		nop
		nop
		nop
		nop
		nop
		nop
		nop
		nop
		nop
		nop
		nop
		dex
		bpl loop
rasterende:
		lda flag
		bne auf

		clc
		lda pos
		adc #2
		sta pos
		cmp #100
		bne raus
		lda flag
		ora #$ff
		sta flag
auf:
		sec
		lda pos
		sbc #2
		sta pos
		bne raus
		lda flag
		and #$00
		sta flag
raus:
		lda pos
		sta $ff0b
rastersik:
		;jmp $fcbe
		pla
		tay
		pla
		tax
		pla
		rti

colors:
	 .byte 0
	 .byte 6,6,6,6,6,6
 	 .byte 22,22,22,22,22,22
	 .byte 38,38,38,38,38,38
         .byte 54,54,54,54,54,54
         .byte 70,70,70,70,70,70
         .byte 86,86,86,86,86,86
         .byte 102,102,102,102,102,102
         .byte 118,118,118,118,118,118
	 .byte 118,118,118,118,118,118
         .byte 102,102,102,102,102,102
         .byte 86,86,86,86,86,86
         .byte 70,70,70,70,70,70
         .byte 54,54,54,54,54,54
	 .byte 38,38,38,38,38,38
 	 .byte 22,22,22,22,22,22
	 .byte 6,6,6,6,6,6
         .byte 0,0,0

counter:
	.byte 0,0
pos:
	.byte 0,0
flag:	
	.byte 0,0

daybyter

Intermediate

  • "daybyter" is male

Posts: 390

Date of registration: Oct 14th 2011

Location: Kaiserslautern

  • Send private message

member since 18 member since

2

Tuesday, April 17th 2012, 3:21pm

Glückwunsch! An sowas (für den 64er) bastle ich auch gerade...

  • "internium" is male

Posts: 4,482

Date of registration: Aug 30th 2008

Location: Berlin

  • Send private message

member since 54 month member since 54 month member since 54 month

3

Tuesday, April 17th 2012, 3:27pm

Super, mein erster Rastereffekt auf dem C64 steht noch aus. Ich bin immer noch am studieren der ganzen Zusammenhänge.

daybyter

Intermediate

  • "daybyter" is male

Posts: 390

Date of registration: Oct 14th 2011

Location: Kaiserslautern

  • Send private message

member since 18 member since

4

Tuesday, April 17th 2012, 4:30pm

Man muss halt die ganzen Timings des VIC verstehen, weil man wissen muss, wie lange man in der Zeile brauchen darf/muss. Bei mir wird mittendrin noch ein Sprite geladen, wo ich auch noch nicht genau weiss, wie lange das braucht. Einfach nur eklig...in OpenGL wär das viiieeel einfacher... :)

  • "internium" is male

Posts: 4,482

Date of registration: Aug 30th 2008

Location: Berlin

  • Send private message

member since 54 month member since 54 month member since 54 month

5

Tuesday, April 17th 2012, 4:46pm

Ja, dass viel mit Zykeln zählen dabei ist, lese ich auch überall. OpenGL habe ich auch mal angefangen, aber das neue ab 3.x ohne glbegin und glend mit den ganzen Buffern und Objekte, bin aber über die Initialisierungsroutine und Grundshadern nicht hinweg gekommen bis jetzt. Was soll, jetzt hat mich halt der 64er wieder gepackt und das macht mir viel mehr Spaß als die moderne Programmierung oder Webentwicklung.

afalc060

Unregistered

6

Tuesday, April 17th 2012, 5:27pm

im grunde ist es ja: irq in zeile x auslösen, gewünschte aktion ausführen (hintergrundfarbe ändern), restzeit verplempern.

Ernie

Unregistered

7

Tuesday, April 17th 2012, 5:36pm

Glückwunsch, da bist du deutlich weiter, als ich je kommen werde!

  • "Gerrit" is male
  • »Gerrit« is a verified user

Posts: 4,403

Date of registration: Mar 27th 2011

Location: Holzgerlingen

  • Send private message

member since 18 member since

8

Tuesday, April 17th 2012, 6:18pm

Durchaus beeindruckend, speziell, dass dir die doppelten Badlines des TED keinen Ärger machen... Wobei man leider einen 'grey dot' am oberen Ende sieht, den müsste man noch irgendwie rausoptimieren.

afalc060

Unregistered

9

Tuesday, April 17th 2012, 6:27pm

doppelte badlines?
was bedeutet das?

  • "Gerrit" is male
  • »Gerrit« is a verified user

Posts: 4,403

Date of registration: Mar 27th 2011

Location: Holzgerlingen

  • Send private message

member since 18 member since

10

Tuesday, April 17th 2012, 6:35pm

doppelte badlines?
was bedeutet das?


TED hat keinen extra Bus zum Farb-RAM wie der VIC, er muss alles über den normalen Datenbus erledigen. Also braucht er pro Zeichenzeile 2 Badlines (1 x Zeichencodes und 1 x Farbinfo) Als kleine Entschädigung versorgt TED die CPU mit dem doppelten Takt wenn er den Bus nicht braucht (Rahmen und Strahlrücklauf minus 5 Refreshzyklen pro Zeile).

Edit: Wenn du den Bildschirm abschaltest, also nur Rahmen ausgibst, läuft die CPU fast die ganze Zeit mit doppeltem Takt (Refreshzyklen ausgenommen) so das im TED nicht abgeschaltet ist.

afalc060

Unregistered

11

Tuesday, April 17th 2012, 7:57pm

Ah ok.

Hab das jetzt ausprobiert.



Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
.setcpu "6502"
.org $1001-2
.word $1001

.word link
.word 2012	; zeilennummer
.byte $9e	; sys-token
.byte "4109"	; adresse
.byte $00	; zeilenende
link:
.byte $00,$00

		sei
		lda #<raster
		sta $314
		lda #>raster
		sta $315
		lda #$02
		sta $ff0a
		lda pos
		sta $ff0b
		;lda 65286
		;and #%01101111		; Bildschirm aus
		;sta 65286		; Nur Hintergrund
		cli
		rts

raster:
		lda $ff09
		sta $ff09
	;	lda $ff0b
	;	cmp pos
	;	bcc rastersik

		ldx #98
loop:
		lda colors,x
spalte:
		ldy $ff1e
		cpy #156
		bmi spalte
		sta $ff19
		nop
		nop
		nop
		nop
		nop
		;nop
		;nop			; 4 NOP gespart
		;nop
		;nop
		nop
		nop
		nop
		nop
		nop
		dex
		bpl loop
rasterende:
		lda flag
		bne auf

		clc
		lda pos
		adc #2
		sta pos
		cmp #100
		bne raus
		lda flag
		ora #$ff
		sta flag
auf:
		sec
		lda pos
		sbc #2
		sta pos
		bne raus
		lda flag
		and #$00
		sta flag
raus:
		lda pos
		sta $ff0b
rastersik:
		jsr $ff9f		; oder $db11 ;Zurück ins BS
		pla
		tay
		pla
		tax
		pla
		rti

colors:
	 .byte 0
	 .byte 6,6,6,6,6,6
 	 .byte 22,22,22,22,22,22
	 .byte 38,38,38,38,38,38
         .byte 54,54,54,54,54,54
         .byte 70,70,70,70,70,70
         .byte 86,86,86,86,86,86
         .byte 102,102,102,102,102,102
         .byte 118,118,118,118,118,118
	 .byte 118,118,118,118,118,118
         .byte 102,102,102,102,102,102
         .byte 86,86,86,86,86,86
         .byte 70,70,70,70,70,70
         .byte 54,54,54,54,54,54
	 .byte 38,38,38,38,38,38
 	 .byte 22,22,22,22,22,22
	 .byte 6,6,6,6,6,6
         .byte 0,0,0

counter:
	.byte 0,0
pos:
	.byte 0,0
flag:	
	.byte 0,0

afalc060

Unregistered

12

Tuesday, April 17th 2012, 8:33pm

hab gerade mal auf hardware getestet und dieser 'grey dot' ist dort nicht zu sehen

  • "Gerrit" is male
  • »Gerrit« is a verified user

Posts: 4,403

Date of registration: Mar 27th 2011

Location: Holzgerlingen

  • Send private message

member since 18 member since

13

Tuesday, April 17th 2012, 8:46pm

Im Video ist er an der oberen Kante recht deutlich zu sehen... Zu genauer Emulator? Baut 'grey dots' ein wo sie gar nicht sein sollten? :)

Ansonsten produziert jeder mir bekannte TED diese 'grey dots' beim Umschalten einer Farbe.

afalc060

Unregistered

14

Tuesday, April 17th 2012, 9:00pm

was soll ich sagen? jetzt ist der punkt eben weg. vice und plus4emu und orig hardware zeigen keinen punkt.
afalc060 has attached the following file:

15

Tuesday, April 17th 2012, 11:20pm

Wenn das ähnlich ist wie beim neuen VIC dann heisst es nicht, dass sie nicht da sind, wenn man sie nicht sieht. Beim C64 mit neuem VIC sind die nämlich auch unvermeidbar. Man muss eben zusehen die Rasterbarfarbe irgendwo 'weit draußen' im Border zu ändern, damit die 'grey dots' nicht im sichtbaren Bildbereich auftauchen.

  • "internium" is male

Posts: 4,482

Date of registration: Aug 30th 2008

Location: Berlin

  • Send private message

member since 54 month member since 54 month member since 54 month

16

Wednesday, April 18th 2012, 7:01am

Bei der Demo Edge of Disgrace ist mir aufgefallen dass da auch mal ca 8Pixel mal 1Pixel flackert, wenn man wirklich den ganzen Border sich anschaut, sowohl im Vice als auch auf dem richtigen C64. Das sind aber keine GreyDots sondern was anderes, hast du ne Ahnung wie das Flackern da zustande kommt?

17

Wednesday, April 18th 2012, 9:51am

Bei der Demo Edge of Disgrace ist mir aufgefallen dass da auch mal ca 8Pixel mal 1Pixel flackert, wenn man wirklich den ganzen Border sich anschaut, sowohl im Vice als auch auf dem richtigen C64. Das sind aber keine GreyDots sondern was anderes, hast du ne Ahnung wie das Flackern da zustande kommt?

Müsstest schon dazu sagen in welchem Part. Denn doch: Edge of Disgrace hat sogar einige sichtbare GreyDots (z.B. beim bunten 3D-Schachbrett, und beim Terminatorweib), weil das tatsächlich nur auf nem alten VIC getestet wurde. Die Info findet sich irgendwo in den Untiefen der endlosen Kommentare auf der csdb.
Aber ich schau es mir gleich mal im DebugBorder Modus an. Ist immer total spannend das mal bei Demos zu machen.

EDIT: achso, ich schätze mal Du meinst das sogar teilweise bis zu 16px/2chars breite Flackern im Border. Das passiert einfach, wenn der Raster-IRQ gerade nicht stabil ist. Das heisst der IRQ wird dann manchmal einen Zyklus früher oder eben später getriggert oder man hat eine Routine, die mal mehr und mal weniger Cyclen verbraucht. Gerade beim Wechsel zwischen zwei Parts tritt das häufig auf, weil man von einer zur anderen IRQ-Routine umschaltet, die man vielleicht so programmiert hat, dass sie in Zeile X stabil ist, aber man lässt die meinetwegen von Position Y von oben oder unten 'reinkommen' und ändert $d012 in jedem Frame bis $d012 = X ist.

  • "internium" is male

Posts: 4,482

Date of registration: Aug 30th 2008

Location: Berlin

  • Send private message

member since 54 month member since 54 month member since 54 month

18

Wednesday, April 18th 2012, 10:29am

Ich meine gleich zum Anfang, hier mal ein Screenshot.

Unseen

Hätte gerne 'n Virtex 7 ;)

  • "Unseen" is male
  • »Unseen« is a verified user

Posts: 4,565

Date of registration: Jun 16th 2007

Location: Debara Hamtar

  • Send private message

member since 72 month member since 72 month member since 72 month member since 72 month

19

Wednesday, April 18th 2012, 10:37am

Manche der Probleme in Edge of Disgrace (mindestens das Flackern beim "Discoboden" IIRC) liegen wohl daran, dass die Umschaltung der VIC-Bank auf 250469er-Platinen (die mit dem Sharp-IC) im Vergleich zu den anderen C64-Platinen (mit PLA und einigen Logikchips) um einen CPU-Takt verschoben ist und das Phänomen erst nach (bzw. wegen) EoD genauer untersucht wurde.

Quellcode

1
2
3
10 x=rnd(-1963):fori=1to81:y=rnd(1):next
20 forj=1to5:printchr$(rnd(1)*16+70);:next
30 printint(rnd(1)*328)-217

sd2iec Homepage

20

Wednesday, April 18th 2012, 10:40am

Ahja: Der Kringel oben ist wie gesagt: nicht stabiler Raster-IRQ.
Beim Kringel unten ist der Raster-IRQ stabil, und was sichtbar wird ist eben exakt der Zyklus, in dem das STA $d020 ausgeführt wurde.

BTW: wir sollten jetzt hier nicht den Thread kapern.

Deswegen mal BTT:
@afalc060:
Hat es einen Grund, weshalb Du hier jeweils zwei Bytes reservierst?

Source code

1
2
3
4
5
6
counter:
	.byte 0,0
pos:
	.byte 0,0
flag:	
	.byte 0,0

Soweit ich erkennen kann, wird doch immer nur das erste davon benutzt oder?