| |
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....
|
| |
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: 1995 |
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: 646 |
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: 5029 |
so, after FIVE years, eor on the fly, and auto clr is done ? :) |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
@Oswald
It will be smaller when completed, so it should fit nicely inside your C64, into the VIC II socket.
Screen is the C64 start up, color memory placed at $0400 (same as character memory) but I could place it anywhere. Doesn't have to be at $0400 offsets or anything, I could have made it start at $0401 if I wanted, so it will be possible to hardware scroll. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
The circuit now allows you place COLOR RAM anywhere in the 64's RAM.
This allows hardware scrolling of the COLOR data and no more 16k bank limitations (the COLOR RAM pointer is 16bit).
Because COLOR RAM is no longer 1k fixed at $D800, it is now possible (By forcing badlines) to have a unique COLOR nybble for EVERY 8*1 cell on the screen. In other words, it is possible to have images with color combinations in a single character cell that were not possible before.
Also, it is not necessary to change the COLOR RAM pointer if you are forcing badlines as you would usually be required to do for the Video Matrix pointer when forcing badlines for an FLI. So no cycles need to be wasted if you want to FLI? the COLOR RAM.
It is even possible to place COLORS on the VIC'S 4 bit color bus in the first three columns of a forced badline and for ALL CYCLES OUTSIDE THE BORDER area. However I am not sure what effect doing these things has on what you see on the screen as I am unsure what VIC does with whats on the color bus during the first 3 columns of a forced badline and also outside the border area.
Can anybody please tell me if there is or if they know of any advantage at all to being able to place colors on the VIC'S 4 bit color bus in the first 3 columns of a badline or outside the border area? (can this be used for anything?)
BTW, I do plan on implementing this same technic for the Video Matrix and the Bitmap data, if I am successful in doing this, it will mean full hardware scrolling of Video Matrix, bitmap and COLOR RAM. It will also mean FLI etc. can be done with out cpu overheads of switching the Video Matrix etc. (you will still need to force a badline though). Also no more 16k bank limitation.
My main goals are to have a circuit that very discretely fits in the C64 between the VIC socket and the VIC II itself and to mantain 100.00% compatibility (i.e. circuit is completely inactive unless invoked by software). |
| |
Martin Piper
Registered: Nov 2007
Posts: 646 |
What happens with the sprite pointers? Hardware scrolling of screen data is nice but if there are sprite pointers in the middle of the screen data you'll get rubbish chars. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Martin, The sprites work the same they always have.
just to clarify, you would not normally be placing data on the VIC bus outside the boarder area, but if you want to for some reason, the circuit does makes it possible to do so. |
| |
Martin Piper
Registered: Nov 2007
Posts: 646 |
What I mean is:
The VIC has sprite pointers that are just after the visible screen data and on a known fixed boundary after the start of the screen memory.
So lets say the VIC thinks it is displaying a screen starting at $400 the sprite pointers will be $7f8-$7ff.
However lets assume with your magic box the screen display fetch is actually hardware scrolled to start at $0700.
As each screen line is drawn then when we eventually get to displaying chars from $7f8 the screen data will start display from the sprite pointers. This produces weird graphics for the eight sprite pointers.
Unless the sprite pointers are continuously relocated to be $3f8 after the start of hardware scrolled screen memory. In which case the eight sprite pointers will have to be updated each time a hardware scroll happens.
Or unless the sprite pointers are fetched from some other memory location not related to screen address. |
| Previous - 1 | ... | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | ... | 20 - Next |
