| |
Krill
Registered: Apr 2002
Posts: 2822 |
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....
|
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Quote: 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
I understand the logic behind the 'one control register for each sprite' but I would miss easy sprite stretching. |
| |
dyme
Registered: Nov 2018
Posts: 14 |
Gravedigging, but one easy change rarely gets mentioned:
It would have been fairly easy to enable changing the hi-byte of the memory bus for accesses to the zeropage (and stack) by writing it into a fixed memory address akin to $01, or maybe some cia register.
Being able to treat every single 256byte block as zeropage would bring such a performance boost, not only because of the 3 instead of 4 cycles per lda/sta, but being able to stx addr,y and sty addr,x saves a lot of swapping registers through memory. Also SO MUCH more zeropage-pointers for zeropage indirect addressing.
Also chaining / interleaving functions by stack combined with switching the stack page midchain could... ah... I don't know, something awesome, I guess. |
| |
Deev
Registered: Feb 2002
Posts: 206 |
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. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
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. |
| |
Krill
Registered: Apr 2002
Posts: 2822 |
Quoting ChristopherJamA 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. :) |
| |
wil
Registered: Jan 2019
Posts: 42 |
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... |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
that polygon filler will never work, as VICII never reads bytes continously nor vertically nor horizontally |
| |
Krill
Registered: Apr 2002
Posts: 2822 |
Quoting Oswaldthat polygon filler will never work, as VICII never reads bytes continously nor vertically nor horizontally Pixels are output one by one along a scan. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Quoting Oswaldthat 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 |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Quoting wilRemember 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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
