| |
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: 5086 |
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: 5086 |
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: 5086 |
explain why it does not need extra cycles to read d800 ? |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
All the reads from the video matrix (color ram and screen matrix) will be done in the normal way, The cct will only convert character fetches (the 8k bitmap data) to the column format. This isn't because it's not possible but only because it's extra work which at this stage I don't see enough benifit to justify it. Is only having the bitmap column formmated going to cuase any major problems? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: explain why it does not need extra cycles to read d800 ?
Sorry for unbury such an old thread, but to answer your question: The bus is 12-bits wide. At a badline it will steal 40 cycles and on each cycle it'll fetch 12 bits (8 bits of char data and 4 bits of color data from D8xx). Purely based on my assumptions of course... :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 718 |
If I remember correctly the colour RAM uses a 2114-30L which is 4-bit SRAM compared to the 8-bit DRAM main memory. Four bits of course provide the sixteen colours and are read by the VIC via a little bit of chip selection logic tied to the other address lines. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Everything going as scheduled :)
I have actually gotten someway on this cct but only in a very very early prototype form and with very limited features so far (but it is working). I have been very very busy but I'm hoping I will have some more time soon to finnish this off. |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
so, after FIVE years, eor on the fly, and auto clr is done ? :) |
| Previous - 1 | ... | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | ... | 20 - Next |
