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 > Alt-history no-cost design changes with great value
2021-05-01 22:49
Krill

Registered: Apr 2002
Posts: 2804
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-05-02 21:33
Oswald

Registered: Apr 2002
Posts: 5007
"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.
2021-05-02 21:42
ws

Registered: Apr 2012
Posts: 225
If, let's say, the screen ram adress would be set, and always the color ram adress would accordingly be set to a mirrored/inverted high adress of that value, like for example:
set screen ram to $0400, color ram would be at $8400,
or if you set screen ram to $8400, color ram would be at $0400 (explanation to make the "mirror" point clear here), thus being able to leave the color ram chips away, wouldn't that actually have reduced cost?
sacrificing just 1000 bytes - while actually, with screen color being read from normal ram, both nybbles could have been used? And even if you didn't change the bus so all 8 bits would be read (i understand that would be necessary?) - why did they add actual ram for the colors in the first place? Just to add 1000 bytes?
2021-05-02 22:03
tlr

Registered: Sep 2003
Posts: 1701
Quote: If, let's say, the screen ram adress would be set, and always the color ram adress would accordingly be set to a mirrored/inverted high adress of that value, like for example:
set screen ram to $0400, color ram would be at $8400,
or if you set screen ram to $8400, color ram would be at $0400 (explanation to make the "mirror" point clear here), thus being able to leave the color ram chips away, wouldn't that actually have reduced cost?
sacrificing just 1000 bytes - while actually, with screen color being read from normal ram, both nybbles could have been used? And even if you didn't change the bus so all 8 bits would be read (i understand that would be necessary?) - why did they add actual ram for the colors in the first place? Just to add 1000 bytes?


The reason is memory bandwidth. The color ram has a separate 4-bit data bus. If you were to read the color data from the main ram instead, then you'd need to find 40 more cycles in every bad line.
2021-05-02 22:26
ws

Registered: Apr 2012
Posts: 225
@tlr: ah, i understand. thank you for explaining!
2021-05-03 08:43
Oswald

Registered: Apr 2002
Posts: 5007
one more pla and one more color ram chip could solve the problem, anyway I dont think we would get much boost from double bufferable color ram. the best scrolling games which milk every performance there is are good enough.
2021-05-03 09:14
tlr

Registered: Sep 2003
Posts: 1701
For the record: the plus4 has color data fetched from the main ram. This is solved by having two bad lines each char row. I guess you wouldn't want that for the c64? :)
2021-05-03 09:22
cadaver

Registered: Feb 2002
Posts: 1153
Oswald: Right, double buffer still means you lose the CPU cycles, and in most cases you can race the raster or split the update in halves. Selective non-update FTW :)
2021-05-03 12:12
Jammer

Registered: Nov 2002
Posts: 1288
Quoting cadaver
Oswald: Right, double buffer still means you lose the CPU cycles, and in most cases you can race the raster or split the update in halves. Selective non-update FTW :)


Yeah. Too bad we can't do anything like this with dedicated sample channel which would handle playback timing internally ;)
2021-05-03 12:49
ChristopherJam

Registered: Aug 2004
Posts: 1359
VSP fix... and a bit that lets you put the sprite pointers at (eg) end of bank regardless of where the screen is, so that AGSP routines don't scroll the sprite pointers onto the visible area.
2021-05-03 12:54
chatGPZ

Registered: Dec 2001
Posts: 11088
Regarding sprite pointers i always wondered how they ended up in regular RAM - you'd think those are registers.
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
Brittle/Dentifrice^(?)
CA$H/TRiAD
AArt1256/MoonShine
Andy/AEG
Max/Flat3
St0rmfr0nt/Quantum
MCM/ONSLAUGHT
Guests online: 368
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 No Bounds  (9.6)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 Party Elk 2  (9.7)
2 Cubic Dream  (9.6)
3 Copper Booze  (9.5)
4 Rainbow Connection  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Onscreen 5k  (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 Booze Design  (9.3)
2 Nostalgia  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Diskmag Editors
1 Jazzcat  (9.4)
2 Magic  (9.4)
3 hedning  (9.2)
4 Newscopy  (9.1)
5 Elwix  (9.1)

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