| |
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.... |
| |
chatGPZ
Registered: Dec 2001 Posts: 11088 |
Regarding sprite pointers i always wondered how they ended up in regular RAM - you'd think those are registers. |
| |
tlr
Registered: Sep 2003 Posts: 1701 |
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: 11088 |
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: 2804 |
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: 11088 |
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: 2804 |
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: 1359 |
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! |
| |
Shadow Account closed
Registered: Apr 2002 Posts: 355 |
Quote: A simpler way to sync the CPU to the VIC-II. Either via some kind of halt facility, or at least having a up-counting timer to measure how far from the time of IRQ assertion we are.
Yeah, this one for sure! So convenient when coding on the Atari 8-bit machines or the VCS/2600 for that matter to just do a STA WSYNC - and you are in perfect sync again.
Cycle/raster-exact code on the C64 is such a nightmare in comparison. First you have to use some convoluted methods with double IRQs or whatnot to actually get in sync, and then it's a struggle to actually keep it once you start having badlines and sprites etc.
That's why my answer when someone makes suggestion on anything I code "But couldn't thing X be in the sideborder?" the answer is always a resolute "NO!" :) |
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |