| |
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....
|
| |
PopMilo
Registered: Mar 2004
Posts: 145 |
P.S. And Char screen memory can be set in 1Kb steps...
By the way I like what you are trying to do, keep up the good work!
|
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
UPDATE ON 3D CCT.
I've settled of the final specs of the cct.
Columns with 256 byte offset
Memory fill (clear)
EOR fill (on screen draw)
2 buffers
16 colors (normal c64 palette, normal 4*8 cell limitations)
The cct has completely changed. I want to make the cct as simple and cheap as possible while including the main features that ppl want. There seemed to be three main features that kept coming up in the discussions, the column formatting, fast memory clear and EOR fill. I want the cct to be simple enough that anyone can buy the parts from an electronics shop and put it together. When the cct is finished I will release the schematic so that anyone who wants to build one (not for profit) can. Also if anyone wants to write some code for the cct might want to have a look at the schematic.
I have given my video ctt the flick, the cct now just uses the vic II and the RAM already inside the C64. In fact the cct will just be a bit of logic between the address and data buss of the C64 and the VIC II. This is a lot simpler. Basically when the VIC goes to get character data from xxxx location the cct jumps in and puts a different address on the buss corresponding to the column address. The memory fill will need address and data placed on the busses and a write signal during the Vic's part of the clock cycle. The EOR fill will use forty bytes and some EOR logic to put the appropriate byte on the data buss to VIC while drawing the screen. The If commodore where thinking about 3D graphics when they designed VIC II they probably would have added these simple features to the vic II but off course Commodore where not thinking about 3D graphics for the C64 back in 1982.
The column address formatting part of the cct is 90% finished.
Anyway, I would be interested to know what anyone thinks of those specs.
|
| |
Oswald
Registered: Apr 2002
Posts: 5026 |
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. |
| |
WVL
Registered: Mar 2002
Posts: 886 |
yes! EOR-on-the-fly :) that really speeds things up dude! :)
btw, could the cct clear frames in the background? (not stealing cycles from cpu?) if so, the c= only has to give orders to clear the screen, (while the screen clears it can do 3d rotations), when screen is cleared the cpu draws the lines, swaps the buffers and enables EOR-display mode..
real fast. cpu only has to do rotations and line drawing.. neat. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
The memory fill (Screen clear) doesn't use any cpu cycles (except a few to set it up). The VIC has about 10 000 wasted cycles per screen (a bit less with sprites) which will be used by the cct to write to memory. The VIC II doesn't have a W/R output so there are still a couple of things Ive got to work around for this but it should be very doable.
Also there will be a control bit that you can set to make the memory fill only fill the screen memory. In other words it will only fill 200 bytes of each column. So this way if you are clearing a screen there is no time wasted filling the none viewable portions of memory which exist due to the 256 offset of each column (so you can easily clear one buffer per frame). But if you just want to fill a large continuous chunk of memory this will also be possible. But no window fills.
The EOR on the fly (which will also have a control bit to enable it) should be very easy to implement in hardware (that's easy for me to say now, because I havent started designing it yet). It should just be a case of having 40 bytes. At the start of each new screen the forty bytes get cleared. As each byte of character data gets fetched by VIC the cct will intercept it and EOR the data with the corresponding byte for that column, draw that byte on the screen and leave the result in the corresponding byte waiting for the next line. Does that make any sense? will that do what you all mean by EOR fill?
|
| |
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 thats 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. |
| Previous - 1 | ... | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | ... | 20 - Next |
