Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Alt-history no-cost design changes with great value
2021-05-01 22:49
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....
 
2021-05-03 12:54
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.
2021-05-03 13:10
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!
2021-05-03 13:21
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
2021-05-03 14:00
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)
2021-05-03 14:24
Krill

Registered: Apr 2002
Posts: 2804
Quoting Copyfault
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)
Er... you mean writing twice, to two different memory locations on page boundary crossing?
2021-05-03 14:27
chatGPZ

Registered: Dec 2001
Posts: 11088
How would that be nice and not just be a major WTF?
2021-05-03 14:48
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.
2021-05-03 14:49
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 Groepaz
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.
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. =)
2021-05-03 14:55
ChristopherJam

Registered: Aug 2004
Posts: 1359
Quoting Groepaz
How 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!
2021-05-03 14:57
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
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Matt
A3/AFL
Brittle/Dentifrice^(?)
jmin
Guests online: 369
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 No Bounds  (9.6)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 Party Elk 2  (9.7)
2 Cubic Dream  (9.6)
3 Copper Booze  (9.5)
4 Rainbow Connection  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Onscreen 5k  (9.5)
7 Dawnfall V1.1  (9.5)
8 Quadrants  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Nostalgia  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Original Suppliers
1 Derbyshire Ram  (9.5)
2 Black Beard  (9.4)
3 hedning  (9.2)
4 Baracuda  (9.1)
5 Irata  (8.5)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.047 sec.