Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > FASTER 3D GRAPHICS
2004-10-26 06:24
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....
 
2005-07-28 00:34
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?
2009-03-23 13:35
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... :)
2009-03-24 04:34
Martin Piper

Registered: Nov 2007
Posts: 722
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.
2009-04-05 11:24
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.
2009-04-05 12:01
Oswald

Registered: Apr 2002
Posts: 5094
so, after FIVE years, eor on the fly, and auto clr is done ? :)
2010-01-25 12:51
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.
2010-02-26 16:24
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).
2010-02-28 00:17
Martin Piper

Registered: Nov 2007
Posts: 722
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.
2010-02-28 05:21
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.
2010-02-28 12:39
Martin Piper

Registered: Nov 2007
Posts: 722
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
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
tokra/Akronyme Analo..
Acidchild/Padua
MWR/Visdom
Mike
Peacemaker/CENSOR/Hi..
Alakran_64
bexxx
Slajerek/Samar
Andy/AEG
E$G/HF ⭐ 7
lotus_skylight
Guests online: 117
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top Swappers
1 Derbyshire Ram  (10)
2 Jerry  (9.8)
3 Violator  (9.7)
4 Acidchild  (9.7)
5 Cash  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.05 sec.