HIP/Visdom2

[emkay]

 

the clock is at 17.734475 mhz and all other clocks needed in the c64 are generated from that.

 

 

Well I have some problems by reading the schematics of the C64. It's in the different norm it is made in.

Your 17,73MHz are the so called "color-clock" and the "DOT Clock" is at 7,80MHz. This looks to me like the VIC has some internal work to do, so that this high clocking is necessary. Perhaps it is depending on the Sprite Hardware.

 

 

btw, fetching 40 bytes doesn't cost 40 cpu cycles... it costs 41-43 (depending on the opcode executed when the dma is started).

 

Fetching one byte in one cycle is given by the accurate bus speed which must be the same than the CPUs speed.

 

Your more in cycles can be calculated if you assume the additional DMA by the graphicschip or anything else...

 

 

I would really like to view a full explanation...

[Fröhn]

Well I have some problems by reading the schematics of the C64. It's in the different norm it is made in.

Your 17,73MHz are the so called "color-clock" and the "DOT Clock" is at 7,80MHz. This looks to me like the VIC has some internal work to do, so that this high clocking is necessary. Perhaps it is depending on the Sprite Hardware.

 

that the dot-clock is much higher than the cpu clock is a natural thing... it's also 8 times the cpu clock on 800xl.

 

the pal color carrier is calculated by 17.734475 mhz / 4 = 4.43 mhz.

the cpu clock is 17.734475 / 18 and the dot clock is cpu clock * 8 again.

 

 

btw, fetching 40 bytes doesn't cost 40 cpu cycles... it costs 41-43 (depending on the opcode executed when the dma is started).

Fetching one byte in one cycle is given by the accurate bus speed which must be the same than the CPUs speed.

there's one problem you perhaps don't know: 6502 cpus cannot be stopped in the last cycle of a store operation or the last two cycles of a fetch-modify-write operation (i.e. INC $1234). that's why the RDY line of the processor is pulled high 3 cycles before, so a fetch-modify-write can finish it's last two cycles before the dma owns the bus.

 

also the bus speed doesn't need to be the same as the cpu speed for 6502 processors since they can finish a memory access in half a cycle.

 

I would really like to view a full explanation...

here's an article for in-depth information:

 

http://www.minet.uni-jena.de/~andreasg/c64...ticle_2.htm#2.2.

 

from that article:

 

"ø2

Processor clock output

This clock signal is the reference for the complete bus timing. Its frequency is 1022.7 kHz (NTSC models) or 985.248 kHz (PAL models). One period of this signal corresponds to one clock cycle consisting of two phases: ø2 is low in the first phase and high in the second phase (hence the name 'ø2' for "phase 2"). The 6510 only accesses the bus in the second clock phase, the VIC normally only in the first phase."

[emkay]

Well I have some problems by reading the schematics of the C64. It's in the different norm it is made in.

Your 17,73MHz are the so called "color-clock" and the "DOT Clock" is at 7,80MHz. This looks to me like the VIC has some internal work to do, so that this high clocking is necessary. Perhaps it is depending on the Sprite Hardware.

 

that the dot-clock is much higher than the cpu clock is a natural thing... it's also 8 times the cpu clock on 800xl.

 

the pal color carrier is calculated by 17.734475 mhz / 4 = 4.43 mhz.

the cpu clock is 17.734475 / 18 and the dot clock is cpu clock * 8 again.

 

 

 

Ok... Your explanation before did let me think you would consider a 17MHZ bus ... or else.

 

 

there's one problem you perhaps don't know: 6502 cpus cannot be stopped in the last cycle of a store operation or the last two cycles of a fetch-modify-write operation (i.e. INC $1234). that's why the RDY line of the processor is pulled high 3 cycles before, so a fetch-modify-write can finish it's last two cycles before the dma owns the bus.

 

Thats what I thought first...

But the Sally(6502) and later the 6510 are especially build to stop directly on the graphic-chip's request...

 

 

 

"ø2

Processor clock output

This clock signal is the reference for the complete bus timing. Its frequency is 1022.7 kHz (NTSC models) or 985.248 kHz (PAL models). One period of this signal corresponds to one clock cycle consisting of two phases: ø2 is low in the first phase and high in the second phase (hence the name 'ø2' for "phase 2"). The 6510 only accesses the bus in the second clock phase, the VIC normally only in the first phase."

 

This is not a 2MHz Bus... it is similar to the DDR-RAM technique.

[Fröhn]

Ok... Your explanation before did  let me think you would consider a 17MHZ bus ... or else.

there's several different clocks (bus clock, phi2 clock, dot clock, color carrier) but all are generated out of that 17.73 mhz.

 

Thats what I thought first...

But the Sally(6502) and later the 6510 are especially build to stop directly on the graphic-chip's request...

yes, but they can only be stopped immediately on read cycles.

 

This is not a 2MHz Bus... it is similar to the DDR-RAM technique.

the ram itself doesn't transfer 2 bytes in one clock cycle. it is standard 4164, 4264 or similar ram which transfers 1 byte per clock cycle, but it's clocked with 2mhz. the cpu has a 1 mhz clock and is able to do it's ram access in half a clock cycle, but that has nothing to do with the ram.

[emkay]

 

Thats what I thought first...

But the Sally(6502) and later the 6510 are especially build to stop directly on the graphic-chip's request...

 

yes, but they can only be stopped immediately on read cycles.

 

 

So...if you are right, a midline colorchanging would flicker... sometimes. But it does not.

 

 

This is not a 2MHz Bus... it is similar to the DDR-RAM technique.

the ram itself doesn't transfer 2 bytes in one clock cycle. it is standard 4164, 4264 or similar ram which transfers 1 byte per clock cycle, but it's clocked with 2mhz. the cpu has a 1 mhz clock and is able to do it's ram access in half a clock cycle, but that has nothing to do with the ram.

 

By reading the text again and again I come allways to the conclusion of a 1MHz bus with two reads in one cycle, because different phases are a part of one cycle

But ... it's alike... the C64s CPU is less interfered by DMA or RAM-refresh....

[analmux]

But ... it's alike... the C64s CPU is less interfered by DMA or RAM-refresh....

 

Well, another point of view is to say that the C64 CPU runs at 2 MHz (it CAN run at that frequency!!) but every other cycle is stolen by VIC2. So in practice it's interfered by DMA all the time (even when VIC2 doesn't read memory in the VBlank/Hblank time).

 

When we compare the C64 and Atari 8bit:

 

PAL:

C64:

1 MHz/50 - 40*24 - 63*8 (Screendata + Spritedata) = 18536 cycles

 

And now for Atari 8bit:

1.79 MHz/50 - (40 * 9 + 9*7+1)*24 - 5*256 = 24344 cycles

 

relative speed: Atari is 31 % faster than C64

 

NTSC:

C64:

1 MHz/60 - 40*24 - 63*8 = 15202 cycles

 

Atari 8bit:

1.79 MHz/60 - (40*9 + 9*7 + 1)*24 - 5*256 = 18377 cycles

 

relative speed: Atari is 20 % faster than C64

 

So, on both TV systems the atari 8bit is Significantly faster!!

 

-----

mux

[Fröhn]

When we compare the C64 and Atari 8bit:

 

PAL: C64:

1 MHz/50 - 40*24 - 63*8 (Screendata + Spritedata) = 18536 cycles

hmm a few mistakes. 0.985 mhz @ 50.12 Hz, 40*25 (well, 43-41) and sprites only use cpu cycles in the lines where they are displayed. so if you create a 192x189 sprite layer you lose about 3500 cycles... 1 sprite is ofcourse only few cycles.

 

So, on both TV systems the atari 8bit is Significantly faster!!

i didn't say anything else: about 30%. but most atari people usually make the claim that it's 1.77 mhz vs 0.98 mhz which is ofcourse not what you really have.

[Fröhn]

yes, but they can only be stopped immediately on read cycles.

 

So...if you are right, a midline colorchanging would flicker... sometimes. But it does not.

huh? why should there be any flicker? colors are fetched every 8 rasterlins and you cant stop the dma once it's running.

 

By reading the text again and again I come allways to the conclusion of a 1MHz bus with two reads in one cycle, because different phases are a part of one cycle

depends on what you look at. if you look at the 6510 cpu, it's ofcourse the second phase of the phi2 clock... but for the bus it's every 2nd cycle.

[emkay]

i didn't say anything else: about 30%. but most atari people usually make the claim that it's 1.77 mhz vs 0.98 mhz which is ofcourse not what you really have.

 

Here comes the DL into play

For a big animation just switch to a double lined Mode an reduce the DMA to the half in a range.... So you have

 

-less screen Data

-less CPU usage

-more CPU time

 

...

[emkay]

yes, but they can only be stopped immediately on read cycles.

 

So...if you are right, a midline colorchanging would flicker... sometimes. But it does not.

huh? why should there be any flicker? colors are fetched every 8 rasterlins and you cant stop the dma once it's running.

 

 

Sorry... I was talking about the ATARI...

[Fröhn]

Here comes the DL into play

For a big animation just switch to a double lined Mode an reduce the DMA to the half in a range.... So you have  

 

-less screen Data

-less CPU usage

-more CPU time

you can also reduce the resolution on c64, so you can also have less screen data there. but ofcourse you must do it with raster interrupts, so you need some cpu load to create new graphics modes.

 

for example, the 16 color mode with 4x4 sized pixels is created in this way:

 

the c64 is forced to fetch new colors every 4 rasterlines, this means you need a raster irq every 8th rasterline (switch dma to that line and immediately switch it back to the "normal" lines) and additional 40x25 color fetches. you end up with about 17000 cycles left instead of 18581.

 

FLI is created by forcing dma every rasterline which only leaves about 7000 cycles unused, but you get a very colorful picture .

 

huh? why should there be any flicker? colors are fetched every 8 rasterlins and you cant stop the dma once it's running.

Sorry... I was talking about the ATARI...

still i don't understand. if you use WSYNC there is no flicker because every time you have exactly the same position of register changes.

[emkay]

 

 

for example, the 16 color mode with 4x4 sized pixels is created in this way:

 

the c64 is forced to fetch new colors every 4 rasterlines, this means you need a raster irq every 8th rasterline (switch dma to that line and immediately switch it back to the "normal" lines) and additional 40x25 color fetches. you end up with about 17000 cycles left instead of 18581.

 

FLI is created by forcing dma every rasterline which only leaves about 7000 cycles unused, but you get a very colorful picture .

 

 

 

One possibility of a fullscreen 16 color plasma is in using Antic 3 and GTIA Mode Overlay. But The CPU is not going slower it is going faster, because the DMA is reduced to near the half compared to Antic 2.

 

The best resulting in resolution and colors would be a ANTIC D mode and on the fly register changing....which would mean 24 colors at last per Line

A screen similar to FLI would be possible by using DL-Interleave and color interlace....

 

But only when those modes are done, they will be authentic.

 

huh? why should there be any flicker? colors are fetched every 8 rasterlins and you cant stop the dma once it's running.

Sorry... I was talking about the ATARI...

still i don't understand. if you use WSYNC there is no flicker because every time you have exactly the same position of register changes.

 

By using a "kernal" you only have to set one wsync at the first line. then try to change registers until the end of the screen. Even by the unregular DMA and refresh when using Antic 2, every change ist allways exact on the same position.

As I understood what you were explaining, the Graphics-chip does wait until the RDY signal is high. Additional you said, the cycles can var. by 40 DMA reads up to 43 cycles.... this would mean a continous variation of the finished opcodes too. So you must see sometimes registerchanges moving on the screen.

[Fröhn]

By using a "kernal" you only have to set one wsync at the first line. then try to change registers until the end of the screen. Even by the unregular DMA and refresh when using Antic 2, every change ist allways exact on the same position.  

As I understood what you were explaining, the Graphics-chip does wait until the RDY signal is high. Additional you said, the cycles can var. by 40 DMA reads up to 43 cycles.... this would mean a continous variation of the finished opcodes too. So you must see sometimes registerchanges moving on the screen.

the RDY line is high for 43 cycles, but if you place an STA in a way that the store cycle is at the first cycle of those 43 cycles, the cpu will be halted a cycle later. this always happens, so if you execute the STA always at the same position, you will always have 42 cycles cpu halt. there is no "flicker".

[Bryan]

Thats what I thought first...

But the Sally(6502) and later the 6510 are especially build to stop directly on the graphic-chip's request...

yes, but they can only be stopped immediately on read cycles.

 

That's not true. Atari's way of stopping the CPU is not the same as Commodore's. Atari uses the 1st half of the cycle trick, but stops the CPU clock (extends the 1st half) until the next cycle. In this way Antic gets access on ANY cycle, regardless of what the CPU is doing. Atari does not use the 6510 and it's RDY line.

 

-Bry

[analmux]

....there is no "flicker".

 

That's not quite true too:

 

the first time a Wsync is used you can see flickering in the far right edge of screen, when making f.e. a setcolor change in the background.

 

(Or my Atari is screwed up )

 

-----

mux

[emkay]

....there is no "flicker".

 

That's not quite true too:

 

the first time a Wsync is used you can see flickering in the far right edge of screen, when making f.e. a setcolor change in the background.

 

(Or my Atari is screwed up )

 

-----

mux

 

 

Wasn't there something about Antfuckers

[Fröhn]

That's not true. Atari's way of stopping the CPU is not the same as Commodore's. Atari uses the 1st half of the cycle trick, but stops the CPU clock (extends the 1st half) until the next cycle. In this way Antic gets access on ANY cycle, regardless of what the CPU is doing. Atari does not use the 6510 and it's RDY line.

 

are you sure? i think the atari does it the same way as the plus/4 does. it also has different clock speeds to have free cycles for bitmap dma, and the RDY line is used for stopping the cpu for longer amounts of cycles. afaik 6502 cpus can be stopped for short times by leaving out clock cycles, but for longer times the RDY line is used because parts of the store mechanisms cannot keep their data for too long.