| |
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....
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
Regarding sprite pointers i always wondered how they ended up in regular RAM - you'd think those are registers. |
| |
tlr
Registered: Sep 2003
Posts: 1703 |
Quote: Regarding sprite pointers i always wondered how they ended up in regular RAM - you'd think those are registers.
I guess that would have taken up more die space. They are only needed when the sprite data is fetched, and there are 4 read slots for each sprite anyway. Packing it to 3 slots/sprite would require more logic too.
It's a good thing the pointers can be switched with single writes, we should all be happy! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
Quote:They are only needed when the sprite data is fetched
That could be said about a couple more things with sprites though, so why one ended up in RAM but not the other? :) It DOES make sense though if you think about double buffering the screen content... so who knows |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Maybe someone already wrote this, so sorry in case I missed it: having all the memory-changing opcodes with index in play writing to the non-fixed hi-byte adress first and then writing to the correct adress in the following cycle would really be nice ;) (thinking of INC abs,X; STA abs,X and the like) |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting CopyfaultMaybe someone already wrote this, so sorry in case I missed it: having all the memory-changing opcodes with index in play writing to the non-fixed hi-byte adress first and then writing to the correct adress in the following cycle would really be nice ;) (thinking of INC abs,X; STA abs,X and the like) Er... you mean writing twice, to two different memory locations on page boundary crossing? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
How would that be nice and not just be a major WTF? |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Route CHAREN, HIRAM and LORAM signals to the expansion bus. If you don't want a wider connector (more expensive carts) then just replace one of the +5V and 2 of the 4 GNDs. |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
I guess any changes in the CPU behaviour would have been anything than cheap, though. Picking another existing CPU, ok, if produced in-house at MOS. :)
Quoting GroepazQuote: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. Yes, and with that fast serial failure...
Would have been nice to have a different layout in drive-side $1800 to write to the serial bus.
E.g., with DATA and CLK out on say bits 4 and 0, could bitbang out a byte in just 4+3*6 cycles (not 4+3*8) via STA $1800 : lsr : STA $1800 etc.
And if not that, having ATNA and CLK out on bits 1 and 0 would have been the next best thing. =) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Quoting GroepazHow would that be nice and not just be a major WTF?
You could clear RAM at a hair over 2.5 cycles per byte! Epic! |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
