| |
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 |
Thanks for the link. 2x2, 4x4 and 8x8, why would you want this? speed? effects?
Just incase you havn't noticed, I'm not in the Demo scene :)
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
speed and memory efficiency. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Thanks Graham. I had to give a preliminary demonstration of my 8051 hardware today (Final presentation will be in a couple of weeks). The cct is really low spec but should give you an idea of what I've got so far. The 8051 cct will be the basis of the C64 cct, just modified allot.
8051 GRAPHICS CARD SPECS
OUTPUT: PAL (none interlaced)
COLORS: 2 (B&W) Yeehhaaa
RESOLUTION: 320x200
GRAPHICS DATA: HORIZONTALY FORMATED
RAM: 8K
IC COUNT: 6 ICs (could be bought down to less but won't be)
LINES: 312
CYCLES PER LINE: 63
This graphics card is connected to an 8051 microcontroller board (with microcontroller, RAM, ROM, address decoder etc) to make a simple micro computer system. I have never heard of someone else interfacing an 8051 to a TV before, although maybe it's been done hundreds of times.
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
i had a nice idea: if you have different color depths like 1, 2 and 4 bits per pixel, it would be very nice to extend the adress lines to the "bottom" (below A0) to have some kind of soft scrolling. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
I've been on holidays the last few days so I finally interfaced my graphics cct to my 64, now my C64 has a brand new graphics mode :) There is a small problem with the static ram that I still have to iron out, about 1 in every 1000 writes does a partial write (invalid data) to a random address as well as writing the correct byte at the correct address. But other then that it's working fine :)
|
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Hey, I got the problem with that static RAM sorted out :)
I guess the next step for me is to decide what featues will make it into the redesign of the video cct and then actually start the redesign. So it will probably be a while before I have anything more to post. |
| |
Death Demon
Account closed
Registered: Feb 2005
Posts: 68 |
I'm going through this trying to figure out exactly what you want to do. The question posed is really simple enough, but the responses thus far are confusing to me.
1) Do you want to come up with a memory controller for the VIC chip that manages memory transfers better?
2) What memory chips are you using? Are you able to use more than one?
3) Can you do front/back buffer rendering?
Things you should consider:
1) Memory chips have different latencies associated with addressing different segments of memory. Figure out what those crossover points are and map them to the application you are doing. For instance, it may make sense to address memory in "tiles" versus lines or columns in order to avoid page flips.
2) Using multiple memories may aid in that you can map alternating lines and use the LSB of the line number to indicate which memory you are reading from. This also helps with tile mode rendering or any other mode. It allows you to hide memory accesses for one RAM while you are processing the request from the other RAM.
3) Try to avoid full frame blits. It's best to use a pointer that changes to point at the new frame once it's ready for display. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Hey Death,
Q1: What I'm designing is a simple PAL (possibly NTSC later) graphics cct that will have it's own RAM. The idea is to have the VIC II still running as normal. The two ccts will be synced so that the raster will be at the same point weather being generated by my cct or the VIC II. The programmer can switch between VIC II (default) or my graphics cct. The main idea is to have a graphics cct in a C64 were the user would not even have to be aware of it's existence. I want this cct to be transparent to the user (no additional video cables, no extra switches or anything).
Q2: At the moment I'm just using an 8k static RAM but this is only for trialing my current design. When my design progresses there will be a very large amount of RAM for the graphics cct (It will be necessary for the graphic modes). The idea I'm thinking about for RAM is to be able to bank in 8k sections of graphics RAM (which there will be a lot of) to the 6510. Alright I'll try to explain this as best as I can. I'm thinking of designing the cct so the programmer can, for each 8k block (banked into the 6510) choose too either "Read C64 RAM / Write C64 RAM" (normal operation), "Read C64 RAM/ Write Graphics RAM", "Read Graphics RAM / Write Graphics RAM" or "Read Graphics RAM / Write C64 RAM". OK that might not have made sense, basically you can change weather the 6510 will read from it's C64 RAM or the graphics RAM and if it will write to C64 RAM or to the Graphics RAM. You could even write to both C64 RAM and Graphics RAM at the same time if you wanted to. Anyway thats what of got in mind, it will be very flexible for the programmer.
Q3: What is front/back buffer rendering?
Point 1: Could you go into a bit more detail with the tiles thing. Is it common for graphics ccts to use this method? Is the size of the tiles normally defined by the programmer or set in hardware?
Point 2: Do you mean so that something like a graphics processor can be accessing more then one RAM at a time?
Point 3: With the blitter thing, I agree with what you say but I dont think there was a lot of demand for a blitter, how important do you think having the blitter is?
If you havent noticed I dont know much about 3D graphics or rendering so sometimes I will need some stuff (even simple stuff) explained to me. Also I want to keep this cct very basic, I dont want this to be one of them projects that never get finished because the person doing it got to carried away and set themselves an unachievable goal (thats why Im making no promises with the specs).
Thanks Death, please keep the suggestions coming.
P.S. I've started work on the color cct, It may take me a while to complete this part of the cct since I probably won't have much spare time for a while.
|
| |
Death Demon
Account closed
Registered: Feb 2005
Posts: 68 |
The questions you're asking can't necessarily just be answered with a right or wrong answer. Mostly, it depends on your specific requirements. So I can give you some pointers for general system architecture with some caveats so that you can make an intelligent choice as to whether or not that particular application makes sense for your use or not.
If you are using an on-die 8K SRAM, then you should be able to access data per clock regardless of the address. There's really no speedup associated with paying attention to banks. You may want to look at the total number of available ports on the RAM, though. For instance, a dual ported RAM will allow write and read access on the same clock. A multi ported RAM can allow multiple addresses to be read or written on the same clock. The area increase is minimal. I'm not sure what your particular application has available though. If this is an ASIC you are designing, it should be easy enough to use whichever RAM you want.
Also, since you're using an internal SRAM, I don't see any real need to worry about how the addressing is lined up. As long as you make sure you are dealing with contiguous chunks, there's really not going to be an issue here. No slick addressing scheme is going to provide you any tricks. If you're dual ported, you may want to make sure that you have things set up so that your 8K blocks aren't in danger of being written while being read (write-thru hazard).
For the last question:
Q3) Front/back buffers are essentially two copies of the screen. You render to the back buffer while displaying the front buffer. This gives you one extra frame to render the scene. Once it's done, you flip a bit so that the back buffer "becomes" the front buffer and vice versa. Not sure if this application would be of use to you since I think you want something that's completely compatible with the C64 VIC.
1) Tile mode rendering is really a trick to help optimize the utilization of external RAMS. You set up your "tiles" in footprints that correspond either to texture formats or your rasterizer's output swath configuration as well as the bank layout for your external DRAMs. It doesn't apply to SRAMs. The goal with a tile mode design is to make sure that your rendering to memory and pulling from memory is done in a tile that fits into the fastest accessible block of memory. DRAMs have latency penalties for page faults. You're trying to avoid those. Again, none of this applies to static RAMs.
2) Yes. Most modern graphics will access multiple RAMs. You spread the frame buffer across these multiple RAMs so that you can pull X lines out of ram A up until a page fault, then start accessing lines X+Z from ram A which causes a page fault. While you're waiting for the page fault to complete, you start accessing Y lines ot of ram B up until the page fault at which point ram A should be ready. This is for optimizing external DRAM accesses, but if you are using internal RAMs, it could allow you to use single ported RAMs in which you could be rasterizing the next ten lines to RAM B while reading the first 10 lines to display out of RAM A.
3) Could be entirely unimportant. Dunno. Sprites should be done with blits though. Anything that's an "overlay", so to speak, should be done with blits. That's going to be a fairly optimal way of managing them. Should be much faster then the way C64 originally handled them. Been a long time, but I seem to remember a lot of latency around the actual drawing of the sprite. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Death,
I'm not planning on using Dual Port RAM and at the moment the design has been done in discrete logic (and a couple of GALS) on bread boards (very messy and quite large) and also in a CPLD, at some time in the future I will probably have to look at going to an FPGA or something. I would like to use SRAM but I havent looked at prices or availability yet so that could change. The Ram doesn't need to be fast as this cct is low performance, it only needs to run at 8Mhz (although I may change that latter but even then the dot clock will still be 8Mhz). The cct is similar to the VIC II cct and will have a very similar output (same sync signals, same boarder area, same resolution etc) but I'm planning to have 256 colors available and a new way of formatting the screen so that 3D graphics can be rendered a little bit quicker, also I'm planning on having the graphics cct able to do things like clear portions of memory fast (in C64 terms anyway). Like the VIC II, the cct will only need to access RAM for half every clock cycle, this will allow me to use the other half of the cycle to do the clearing and stuff like that (as long as the 6510 isn't using that same half of the cycle which it will sometimes, but no more then 1 out of 8 pixel clock cycles anyway). Even if I don't use the other half of the cycle I can use the cycles above and below the boarders for these things since the cct doesn't need to access RAM at that time. Another thing that seems to be in demand is for the hardware to be able to fill graphics as they are being drawn.
As for buffers, my idea is to have a pointer that points to the start of where the cct will get the screen data from in RAM. In other words you can get your screen data from anywhere in RAM just by changing the pointer (so you could build up 1 or more screens in RAM while displaying a completely different one). Is this the same as using buffers?
I should point out that none of these ideas are set in concrete.
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | ... | 20 - Next |
