| |
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.... |
| |
ChristopherJam
Registered: Aug 2004 Posts: 1359 |
Eh, I've never found the SID register stride that big a deal - you just interleave all your voice state at strides of seven as well. Especially now we know we can
TXA
AXS#7
at loop end :) |
| |
Krill
Registered: Apr 2002 Posts: 2804 |
Quoting ChristopherJamEh, I've never found the SID register stride that big a deal - you just interleave all your voice state at strides of seven as well. Especially now we know we can
TXA
AXS#7
at loop end :) Not a big deal, but may cost precious bytes and/or cycles. =D While rearranging them would have no downsides, afaict right now. |
| |
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. |
| |
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? |
| |
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. |
| |
ws
Registered: Apr 2012 Posts: 225 |
@tlr: ah, i understand. thank you for explaining! |
| |
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. |
| |
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? :) |
| |
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 :) |
| |
Jammer
Registered: Nov 2002 Posts: 1288 |
Quoting cadaverOswald: 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 ;) |
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |