On 5/29/2021 12:37 PM, tokafondo wrote: > my logical thinking says that if I run the '816 at ~8mhz or even ~14mhz (fed > by one of the clocks the VIC-II is also fed with), for everytime the VIC-II > does /one/ memory accesses, the '816 would be able to do eight or fourteen > times that memory accesses. > > Is it like that? Not really. For the example, let's assume an 8MHz '816. So, for every 1MHz VIC-II cycle, there are 8 '816 cycles. But, half of those '816 cycles occur during the low portion of the 1 MHz cycle, the same part of the cycle the VIC always uses. So, the '816 can really only use the 4 cycles during the high portion of the 1MHz cycle, as the bus is busy during the 4 cycles that occur during the low portion of that cycle. But, there's more (or less, as it pertains to your ask). 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. 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) 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) > > Also, I'm thinking that a sort of address decoding mechanism could be used > in a way that the VIC-II would be only allowed to stop the '816 for its > additional fetches /when they both are accessing the same memory locations/, > but not when the '816 is somewhere else, like doing I/O or calculations in > some other memory space. 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. JimReceived on 2021-05-29 21:00:02
Archive generated by hypermail 2.3.0.