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 02:42
Deev

Registered: Feb 2002
Posts: 169
Quote: "You mean changing multicolour char mode, which renders hires chars for colours 0-7, so it would always put out multicolour chars?"

yes :) but not changing the original mode, which is cool as it is, but offer a 2nd multicolor mode which does this.


A very easy improvement would just be to switch:

Light-red/red
Mid-grey/purple
Light-blue/blue

When pixelling char graphics, this would allow for a fixed light colour and a fixed dark colour, with a choice of light-red, mid-grey, light-blue, green and (possibly) cyan inbetween.

I haven't thought about this for too long, so there could be some downsides, but a lot of existing games I have looked at wouldn't need to change much (if at all), whilst this selection of changeable colours also allows for greater flexibility.

You could achieve a look similar to Creatures without using colour splits and you could still use hires chars.
2021-06-08 08:45
ChristopherJam

Registered: Aug 2004
Posts: 1164
A VIC flag that enables each byte of pixel data read (regardless of whether it's from a bitmap or a charset) being XORed with the previous value instead of replacing it.

"previous value" reset to zero at start of each scanline.

Only 8 bits of additional internal VIC state (even then only if the current implementation destructively shifts out the bits read during pixel output), and free EOR fill for left to right polygon plotters.
2021-06-08 09:24
Krill

Registered: Apr 2002
Posts: 1916
Quoting ChristopherJam
A VIC flag that enables each byte of pixel data read (regardless of whether it's from a bitmap or a charset) being XORed with the previous value instead of replacing it.

"previous value" reset to zero at start of each scanline.

Only 8 bits of additional internal VIC state (even then only if the current implementation destructively shifts out the bits read during pixel output), and free EOR fill for left to right polygon plotters.
Nice idea, but mustn't the XOR be bit-wise for a left-to-right filler to work?

No idea how the pixel pipeline works internally, but it sounds like it could be done rather easily with little more gates. Just that they thought of these kinds of thing only a little later, in full-blown blitters. :)
2021-06-08 10:38
wil

Registered: Jan 2019
Posts: 33
Guys, if you plan to go back in time to add improvements to the C64 *please* be careful!

Remember what happened last time when we went back in time to improve C128's VDC. We wanted to add a blitter function instead of the limited hardware sprites and a separate memory to avoid cycle stealing. And we ended up losing the sprites for good and the separate memory is damn slow to access now...
2021-06-08 12:04
Oswald

Registered: Apr 2002
Posts: 4723
that polygon filler will never work, as VICII never reads bytes continously nor vertically nor horizontally
2021-06-08 12:05
Krill

Registered: Apr 2002
Posts: 1916
Quoting Oswald
that polygon filler will never work, as VICII never reads bytes continously nor vertically nor horizontally
Pixels are output one by one along a scan.
2021-06-08 12:30
Oswald

Registered: Apr 2002
Posts: 4723
Quote: Quoting Oswald
that polygon filler will never work, as VICII never reads bytes continously nor vertically nor horizontally
Pixels are output one by one along a scan.


my bad, havent read CJ's suggestion fully... edit: or did I ? CJ talks about eoring bytes, however eoring horizontally per pixel as you suggest would work.

then just max 2 extra onboard bits for the eor mechanism or 1 for hires, should be doable from a few dozens transistors :) or less
2021-06-08 13:01
ChristopherJam

Registered: Aug 2004
Posts: 1164
Quoting wil
Remember what happened last time when we went back in time to improve C128's VDC. We wanted to add a blitter function instead of the limited hardware sprites and a separate memory to avoid cycle stealing. And we ended up losing the sprites for good and the separate memory is damn slow to access now...


No direct access to VRAM on the Commander X16 either. Most un-c64 like.
2021-06-08 13:08
Krill

Registered: Apr 2002
Posts: 1916
Quoting ChristopherJam
No direct access to VRAM on the Commander X16 either. Most un-c64 like.
It does have auto-increment on VRAM pointers, though, so you can pump in sequential data pretty efficiently with a single store per datum.
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)
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - 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
-trb-
Majikeyric/ONS+HF
grass/LETHARGY
wil
eryngi
Sentinel/Excess
zscs
Barfly/Extend
Fabs/HokutoForce/ONS
Nith/TRIÉ…D
Guests online: 256
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 Cover Designers
1 Duce  (9.8)
2 Electric  (9.8)
3 Junkie  (9.7)
4 The Elegance  (9.4)
5 Mermaid  (9.3)

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