Re: Independent CPU/VIC-II setup

Sat, May 29, 2021 at 01:04:26PM -0500, Jim Brain wrote:
>Every badline, the VIC takes the OTHER HALF of the 1MHz cycle as well.  
>That means, for 63-65 1MHz cycles, the '816 gets no cycles to operate 
>at all.

It is not that bad. On bad lines where no sprites are enabled, the 
VIC-II will steal the bus for 3+40 cycles. The extra 3 cycles are stolen 
because the NMOS 6502 processor family would be unstoppable during a 
write cycle, and the maximum number of consecutive write cycles is 3, 
when BRK, IRQ or NMI pushes the status register and the return address 
to the stack.

If all 8 sprites are enabled, then further 2*8 cycles will be stolen 
from the CPU, for fetching the sprite data. If I remember correctly, 
those cycles would be right after the character data fetch, and thus the 
maximum loss would be 3+56 cycles. That would leave 4 cycles to the 
processor in the worst case in a PAL system (63 cycles per line) and 5 
or 6 on NTSC (64 or 65 cycles per line).

By the way, if you enable all sprites on a PAL system, LOAD from the 
1541 will hang. Does that occur on NTSC systems as well?

>If we assume (again, just for comparison's sake) that the badline 
>happens 25 times per 1/60 of a second, or 25*60 times a second = 1500 
>(25*50 in PAL land, so there's that as well), we will lose 65 * 1500 
>1MHz cycles per second.  And, we lose half of the rest. So, we get
>
>(8M - (8 * 65 * 1500))/2 cycles to run in a given second:
>
>=3.61MHz(effective)

Here is a little more accurate calculation, assuming that the NTSC video 
chip is something newer than 6567R56A, and has 65*262 cycles per video 
frame, and that sprites are disabled.

Total number of cycles per frame: 65 * 262 = 17030
CPU cycles available per frame: 65 * 262 - 25 * 43 = 15955

Frame rate: 14318181 Hz/14/65/262 = 60.05 Hz

Fast CPU cycles per frame: 4*(65*262 - 25*43) = 63820

Effective clock speed: 63820/17030 * 14318181 Hz/14 = 3.832675 MHz

>For NTSC.  I think it's a bit better for PAL (I forget if PAL takes 65 
>cycles or 63, so I'll use 65 for now):
>
>(8M - (8 * 65 * 25 * 50))/2
>
>=3.675MHz(effective)

Total number of cycles per frame: 63 * 312 = 19656
CPU cycles available per frame: 63 * 312 - 25 * 43 = 18581
  
Frame rate: 17734472 Hz/18/63/312 = 50.12 Hz

Fast CPU cycles per frame: 4*(63*312 - 25*43) = 74324

Effective clock speed: 74324/19656 * 17734472 Hz/18 = 3.725458 MHz

You see, even though there are proportionally fewer badlines on PAL, the 
lower clock speed more than compensates for it.

>This will work, if you create 2 address/data busses.  Put some '541s 
>and '245s on the VIC-II bus to only connect it to the main Address/Data 
>bus when the CPU is accessing the VIC-II memory space.  Then, your 
>number above will get much closer to 8MHz.

I understood that external accelerators are doing exactly that. They 
only access the main bus in the computer for I/O and for video memory.  
Everything else is cached in the local RAM. They might cheat and keep 
track on which 16KiB RAM bank is mapped to the VIC-II, and avoid 
updating the internal RAM for anything that is outside that 16KiB bank.  
Even for the first and third RAM bank, they could avoid writing to the 
internal RAM, because the character ROM would always be mapped at 
0x1000..0x1fff and 0x9000..0x9fff. Does some accelerator work on the 
Commodore 128 in 128 mode? In the 128 mode, the character ROM can be 
disabled.

	Marko