| |
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 |
@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: 634 |
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: 634 |
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. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Sorry Martin, I thought you were refering to the sprite data fetches.
It's a good question. As the Sprite pointers are loaded in to the VIC the same way the sprite data is, the VIC will fetch the sprite pointers from the same location as usual (the last 8 bytes of the selected video matrix).
The color data pointer, bitmap data pointer and the Character data pointer used by the Magic Box (I really need a name for this circuit, how about "Vic Enhancer" for the moment?) are 16bit pointers that are independent of video banks and the Video Matrix pointer etc., so you could have Video Matrix at $0400 and the character data pointer at $8000 or whatever.
I will just point out that at the moment I only have this addressing scheme implemented and working for color data. I will also point out that you will not be stuck with a linear screen formatting. |
| |
Martin Piper
Registered: Nov 2007
Posts: 634 |
Cheers. That makes sense.
As for a name "VIC-X"? :)
|
| |
WVL
Registered: Mar 2002
Posts: 886 |
How does it work?
I'm imagining that the VIC is asking for bytes from $d800, and that your circuitry changes this address and asks for bytes from colorpointer+adressasked-$d800 instead. And sends the value read back to the VIC.
So a kind of man-in-the-middle attack, where the VIC requests are being modified and 'false' data is being sent back to the VIC..
Is that how it works? |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Martin, VIC-X as in VIC eXpander?
WVL, perfect analogy, the "MAN IN THE MIDDLE ATTACK"!
yeah, pretty much. The VIC-X or Vic Enhancer just sits between the Motherboard and the VIC. VIC puts out the address it wants, but the VIC-X / Vic Enhancer intercepts it and puts it's own address on the bus, allowing allot of freedom in how the C64 uses the VIC.
So with the use of forced badlines, it is now possible to have a unique COLOR nybble for EVERY 8*1 cell on the screen.
My C64 is currently putting a different nybble on the color bus for ever 8*1 cell, pretty cool! That's 8k (nybbles not bytes) of just color data! I have not written any code that takes advantage of this (that's well above my coding skill and I'm trying and convince Oswald to write an editer).
WVL, If you want me to, I can go more in depth with how the address pointer increments. |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Oh, that's OK. But now I understand how you plan to do a linear bitmap (by modifying the adress) and EOR-on-the-fly (by modifiying the data).
It's nice that you're still using the VIC, but now with a smart adress-modifier between the VIC and the bus. Much better idea than creating a video chip by yourself. |
| Previous - 1 | ... | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | ... | 20 - Next |
