| |
Krill
Registered: Apr 2002
Posts: 2839 |
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: 1378 |
Agreed on deinterleaving the sprite position registers
Re-arranging the pulse width bits on SID to put the eight high bits in a single register would have saved a fair bit of code - most tunes could happily leave the low four bits untouched during playback.
Putting the lowest bit of sprite X position into a separate register instead of the highest would likely have resulted in a lot of routines that left the LSB zero, but would make full screen sprite positioning a hell of a lot saner if you could live with the slightly coarser movement.
Alternately, instead of seperate registers for sprite x-msb, spriority, sprite x/y expand, sprite MCM, have a mode register for each sprite that combines those five attributes (and probably the collision flags too).
Soooo much saner for multiplexers that actually change modes.
Allow disabling of the character set images in one of the memory maps (surely just a change in PLA programming).
Bugfix stx $xxxx,y and sty $xxxx,x |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
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: 11108 |
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: 1378 |
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: 2839 |
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: 1714 |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
