| |
Krill
Registered: Apr 2002
Posts: 2825 |
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....
|
| |
Krill
Registered: Apr 2002
Posts: 2825 |
As for re-grouping registers, i always thought the SID's 7 per-voice registers should have been interleaved.
Then updating registers in a per-voice loop could be done with, e.g., X = 2, 1, 0 rather than subtracting 7. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
Quote:parallel drive interface (we know it was compatibility decision, not cost decision)
it was pure cost decision, the cable and connectors for ieee488 cost a small fortune back then. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
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: 2825 |
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: 5017 |
"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: 228 |
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: 1702 |
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: 228 |
@tlr: ah, i understand. thank you for explaining! |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
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: 1702 |
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? :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
