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


Forums > C64 Coding > Alt-history no-cost design changes with great value
2021-05-01 22:49
Krill

Registered: Apr 2002
Posts: 1916
Alt-history no-cost design changes with great value

Which things in the C-64 could have been implemented or connected differently without conceivable extra cost, for coding advantages?

Thinking of things like shuffling the chip register bits like VIC's $d011 and $d016 differently (such that some effects can be achieved with fewer register writes or less twiddling).
Or putting some IO register to $01 (and move the memory configuration somewhere else, somehow).
Maybe also having different PLA memory configurations (not necessarily more).
Or connecting external signals to the CIA port pins in a different order.

Discuss! =)
 
... 65 posts hidden. Click here to view all posts....
 
2021-06-08 13:10
ChristopherJam

Registered: Aug 2004
Posts: 1164
Quoting Krill
but mustn't the XOR be bit-wise for a left-to-right filler to work?

Not at all! It needs to be bytewise for pattern fill to work. This is exactly what I implemented in software for the 3d renderer in Effluvium

Quoting Oswald
that polygon filler will never work, as VICII never reads bytes continuously nor vertically nor horizontally

Well, that's the point - it needs to XOR with the previous byte displayed, not the previous one in memory. The byte immediately before in memory is on the wrong line altogether in bitmap mode. And we need to do a horizontal fill to keep the cost down; a vertical fill would need a 320 byte buffer internal to VIC, and I can't see that being cheap.

(also, it's easier to do pattern fills with a horizontal fill than with a vertical one)
2021-06-08 13:23
Krill

Registered: Apr 2002
Posts: 1916
I see that it needs to be byte-wise (or word-wise) for vertical fill (with a buffer spanning the entirely horizontal width), but i don't see why simple bit-wise from left to right wouldn't work for horizontal fill.

The latter i've done in software in the zoomscroller of +H2K (but of course it uses a 256-entry lookup table to be somewhat efficient).

Edit: Oh, pattern fill... now that's a more complex beast anyways, certainly not a cheap add-on. :)
2021-06-08 15:52
Oswald

Registered: Apr 2002
Posts: 4723
I dont understand how a byte-wise-horizontall eor fill would work in higher res than bytes ? :)
2021-06-08 16:53
Krill

Registered: Apr 2002
Posts: 1916
Quoting Oswald
I dont understand how a byte-wise-horizontall eor fill would work in higher res than bytes ? :)
Filling is performed right-to-left.
Current fill state is held in the N flag.
Pick one out of two lookup-tables according to that state bit.
Read next unfilled input into an index register.
Look up filled output.
Store filled output.
Repeat. =)

(So yeah, two 256-entry tables, actually, but they're just inverted versions of each other. Probably you could use just one with shifting the previously-stored output still in the accu, then conditional inversion of the looked-up next filled value according to carry flag.)
2021-06-08 18:54
Oswald

Registered: Apr 2002
Posts: 4723
Quote: Quoting Oswald
I dont understand how a byte-wise-horizontall eor fill would work in higher res than bytes ? :)
Filling is performed right-to-left.
Current fill state is held in the N flag.
Pick one out of two lookup-tables according to that state bit.
Read next unfilled input into an index register.
Look up filled output.
Store filled output.
Repeat. =)

(So yeah, two 256-entry tables, actually, but they're just inverted versions of each other. Probably you could use just one with shifting the previously-stored output still in the accu, then conditional inversion of the looked-up next filled value according to carry flag.)


I dont get how CJ's HW version would work with only a 8 bit store previous result byte and byte wise eor.
2021-06-08 20:53
Krill

Registered: Apr 2002
Posts: 1916
Quoting Oswald
I dont get how CJ's HW version would work with only a 8 bit store previous result byte and byte wise eor.
Not so sure either. While VIC does have a line buffer, it only buffers screen data worth 40 bytes (whose update you can prevent by disabling badlines).

For vertical filling, the entire width (320 pixels) would have to be buffered for XORing a line later.

Edit: Hmm well, maybe he meant repurposing the line buffer for actual bit/pixel storage. Then the additional bits would only be needed with destructive shifting-out, for buffering that shifted-out byte. But then that extra buffer could well be only one bit, i guess. :)
And colours/screen data would be lost, so... each line a badline? =)
2021-06-08 22:36
ChristopherJam

Registered: Aug 2004
Posts: 1164
Why so complicated you lot? I was pretty clear I only need one additional byte of state.
Here's an extract from the fill code from Effluvium:

rqZapLine0
	lda rqkLBuf +$00
	sta rqkCSet0+$00*64,y
	eor rqkLBuf +$01
	sta rqkCSet0+$01*64,y
	eor rqkLBuf +$02
	sta rqkCSet0+$02*64,y
	eor rqkLBuf +$03
	sta rqkCSet0+$03*64,y
	eor rqkLBuf +$04
	sta rqkCSet0+$04*64,y
	eor rqkLBuf +$05
	sta rqkCSet0+$05*64,y
	eor rqkLBuf +$06
	sta rqkCSet0+$06*64,y
	eor rqkLBuf +$07
	sta rqkCSet0+$07*64,y

Obviously in this instance I was using a contiguous eorbuffer rather than plotting into the charset itself, but you can see how few operations the fill uses.
2021-06-09 00:56
Krill

Registered: Apr 2002
Posts: 1916
Not quite immediately obvious how this translates to hardware.

Can you elaborate?
2021-06-09 07:41
Oswald

Registered: Apr 2002
Posts: 4723
so how does that fill a line horizontally ? if I have

%00001100 %00000000 %00110000

this will fill with your code to:

%00001100 %00001100 %00111100

and not to:

%00001111 %11111111 %11110000
2021-06-09 08:26
Krill

Registered: Apr 2002
Posts: 1916
Okay, so... horizontal pattern fill in hardware, with one additional state byte.

The fill itself would be simple bitwise XOR from one pixel to the next, and that additional state byte is the pattern mask, applied (XOR/AND/OR) to the output with an 8-pixel granularity?
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - 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
Matt
Sander/Focus
Knight Rider/Excess
mutetus/Onslaught
Ghost/Excess
Didi/Laxity
Knut Clausen/SHAPE/F..
adder
Guests online: 254
Top Demos
1 Edge of Disgrace  (9.6)
2 Coma Light 13  (9.6)
3 Uncensored  (9.6)
4 Comaland 100%  (9.6)
5 Lunatico  (9.6)
6 Unboxed  (9.6)
7 Memento Mori  (9.5)
8 Christmas Megademo  (9.5)
9 Wonderland XII  (9.5)
10 The Shores of Reflec..  (9.5)
Top onefile Demos
1 Copper Booze  (9.8)
2 Daah, Those Acid Pil..  (9.5)
3 Lovecats  (9.5)
4 To Norah  (9.5)
5 Dawnfall V1.1  (9.5)
6 Elite Code Mechanics  (9.4)
7 Square Booze  (9.4)
8 Amber Cow - The Real..  (9.4)
9 Quadrants  (9.4)
10 Coma Job 2/3  (9.4)
Top Groups
1 Booze Design  (9.4)
2 Oxyron  (9.4)
3 Censor Design  (9.4)
4 PriorArt  (9.3)
5 Crest  (9.3)
Top Graphicians
1 Mirage  (9.8)
2 Archmage  (9.7)
3 Lobo  (9.7)
4 Razorback  (9.6)
5 Electric  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2021
Page generated in: 0.069 sec.