| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
FASTER 3D GRAPHICS
I've heard it said before that the way the VIC chip addresses memory (8x8 cells) makes it slower fo rendering graphics because of the extra calculations needed. So what way would you have had the Commodore engineers design an alternative addressing mode so that 3D graphics could be calculated quicker? I would realy appreciate your ideas on this. |
|
... 185 posts hidden. Click here to view all posts....
|
| |
Oswald
Registered: Apr 2002
Posts: 5026 |
stingray: yes eor fill works that way, kewl solution :) |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
awsome, thanks. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Quote: it would have been nice to have line drawing, segment fill...
on the fly eor fill is hardcore :) wont it steal cycles from the cpu ? I mean if the cct fills the screen at each refresh, it would be nice if it wont steal each time cycles. If the case is so I would vote for only once fill in memory, then it wont again steal cycles in each frame. (leaving more time for the cpu to calc the next frame)
it would be also nice to have more than 2 buffers. guess its not much extra work to make it able to use all possible bitmap location.
Good point about the buffers. With the addressing hardware for the column formatting the lower 8 bits give the row location (0-199) the next 6 bits give the column (0-39) leaving two bits. So thatÂ’s four buffers for the column formatted screen (one in each bank). Well at least that is what I though until I started designing that part of the cct. The VIC sees the character rom In banks 0 & 2 which means my cct does as well. So that kills two of the buffers. You can still display the buffer but 16 of you columns will be character ROM :(
There are a couple of ways around this.
#1, add some logic between the PLA and the ram/rom control lines (at least I think that would fix it) but that could get very messy.
#2, Use 64k ram on the cct. Much simpler (this wouldn't add 64k to your C64, it would just reflect what is already in the 64's RAM). This would also make the cct a little more expensive.
If the extra work can be justified by the advantages I might consider doing it. I guess It all depends on how beneficial having the two extra buffers would be.
Oh yeh, and the EOR on the fly has no cpu overhead.
|
| |
Oswald
Registered: Apr 2002
Posts: 5026 |
leave the char rom stuff as it is. 2 visible buffers (excluding where char rom comes in) / vic bank is ok.
I thought only 2 fixed buffer is possible / whole 64k. That would be not good when it comes to designing memory usage.
btw, attribute memory reading (0400/d800) will be compatible? |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
It is only two usable buffers for the entire 64k (one at 16k - 26k and one at 48K - 58k each taking up 10k instead of the normal 8k).
Hey, could you explain your question about "attribute memory reading" a bit more, I don't really understand what you mean but it sounds importaint. |
| |
Oswald
Registered: Apr 2002
Posts: 5026 |
I mean that if you will translate the adresses when the vic wants to read color info from screen memory or d800.
btw would it be too big problem to use really onle 200 byte columns ? so more buffers would fit.
and if we stay with 256, it would be nice to be able to set where the 200 lines in that 256 starts, how about a wrap around system, so an offset 0-255 is definable into each 256 byte column ? |
| |
A Life in Hell
Account closed
Registered: May 2002
Posts: 204 |
Quote: I mean that if you will translate the adresses when the vic wants to read color info from screen memory or d800.
btw would it be too big problem to use really onle 200 byte columns ? so more buffers would fit.
and if we stay with 256, it would be nice to be able to set where the 200 lines in that 256 starts, how about a wrap around system, so an offset 0-255 is definable into each 256 byte column ?
isn't $d800 actually physically inside the vic? that is to say, if you were going to translate accesses to that, wouldn't you need to translate them as cpuwrite->vic rather than vic->memread like the otherstuff?
just a thought that is probably embarrassingly wrong :) |
| |
Oswald
Registered: Apr 2002
Posts: 5026 |
you're a bit right, prolly stringray wont translate d800 adresses, since those are done on a BUS dedicated to the vic. This means vic doesnt needs extra cycles to read d800, as it has an own bus to it. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
There is only one bus to the VIC with 14 adress pins and 12 data pins. |
| |
Oswald
Registered: Apr 2002
Posts: 5026 |
explain why it does not need extra cycles to read d800 ? |
| Previous - 1 | ... | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | ... | 20 - Next |
