I made a modified accelerator, it works, but has a problem

[r00tb33r]

I made modifications to this simple 14MHz accelerator by Dennis:
https://github.com/Mathesar/14mhz-accelerator

It runs at either 21 or 28MHz with a configurable PLL.  Photo attached, along with SysInfo and problem shown in ATK.

It's quite speedy (approximately 16MHz 030 A3000 equivalent according to SysInfo result), largely thanks to the zero waitstate memory at that processor frequency, games like Hard Drivin' and 4D Sports Driving (Stunts) have a nice frame rate, and DREAD demo is super smooth.  Every game that runs on the unmodified 14MHz accelerator also runs with the 28MHz modification.  The problem is that music routines run too fast in most games.  A Goggle search pointed me to a gentleman with similar sound symptoms caused by a weak /DTACK pullup, which ultimately led me to discover that my Amiga is having much higher interrupt frequency as measured in ATK.  This problem is not present with unmodified 14MHz accelerator.

My mind isn't as sharp as it was after I finished my university computer engineering degree more than a decade ago, so I'd like to ask for some help figuring out what causes the higher interrupt count and figure out what I should do to improve it.

The Amiga board I am using here is an NTSC 500 rev.5, and the only modifications I made to the accelerator are substituting a configurable PLL, a 10ns delay line to line up the clock edges, and using the buffered 7MHz reference clock from the PLL instead of the one from the system to feed the /DTACK and /AS synchronizing flip-flops because it has a nicer waveform with less skew.

Help is appreciated.

[r00tb33r]

I re-read Dennis's project notes and found that this statement may have been a clue.

AS is now delayed before being fed to the motherboard fixing issues when the CPU does a chipset cycle after a CIA cycle.

I put a variable 0-60ns delay line on /AS output of the U5 JK flip flop and found no value that made a difference with respect to the interrupt counts.  No success here, at least the way I did it.

Earlier I also came across the following resource:
https://sites.google.com/one-n.co.uk/amiga-guides/amiga-interrupt-signals

And noted that the pullups on the interrupt lines became stronger on newer revision Amigas, from 10Kohm on earlier models to 1Kohm on newer.  I did try adding 1Kohm resistors from 5V VCC to /INT2, /INT3, and /INT6 lines, but that made no difference in my case.

Ideas?

[Thomas]

I am not a hardware guy and cannot help much. I just wonder, shouldn't the vblank frequency be 60Hz for NTSC? Yours runs at half speed. As all the following tests depend on the number of vblanks it would explain why your numbers are so far off. As the vblank runs at half speed, these 100 vblanks will last twice as long as expected and therefore the number of ticks per 100 vblanks is almost twice as high as expected, just because it counts twice as long. So IMHO your CIA timers might be ok, your problem is the vblank.

OTOH it is not clear how it measures the vblank frequency. If it uses CIA timers for that, the problem could be the other way round. Because the timers are running too fast, the measued frequency is too low.

[r00tb33r]

shouldn't the vblank frequency be 60Hz for NTSC? Yours runs at half speed.

Yep, exactly half reported by ATK.  With the unmodified accelerator at 14MHz it reports a reasonable 59.83Hz.  Interestingly SysInfo measures the correct 60 unlike ATK, presumably using a different timer.  At 21MHz ATK measures some even crazier number like 39Hz.  So the faster it goes the lower vblank frequency it measures.

Because the timers are running too fast, the measued frequency is too low.

That is my understanding.

Something I hadn't tested up until this point, I had KS 1.3 ROM in there this whole time, because 500 rev.5 has the oopsie mistake on the board, I finally installed and wired up correctly the KS 3.1 ROM, and unlike 1.3 this one does not boot from the Gotek floppy at either 21 and 28MHz...  So that's a newly discovered problem #2, though very high likelihood it is related to the same interrupt/timer problem.  Obviously I will need to revert to KS 1.3 ROM to run ATK for further testing until these interrupt timers are ironed out.

I feel like I'm so close...  Just wish I knew what rogue signal causes the speedup.

[SpeedGeek]

Yep, exactly half reported by ATK.  With the unmodified accelerator at 14MHz it reports a reasonable 59.83Hz.  Interestingly SysInfo measures the correct 60 unlike ATK, presumably using a different timer.  At 21MHz ATK measures some even crazier number like 39Hz.  So the faster it goes the lower vblank frequency it measures.
That is my understanding.

Something I hadn't tested up until this point, I had KS 1.3 ROM in there this whole time, because 500 rev.5 has the oopsie mistake on the board, I finally installed and wired up correctly the KS 3.1 ROM, and unlike 1.3 this one does not boot from the Gotek floppy at either 21 and 28MHz...  So that's a newly discovered problem #2, though very high likelihood it is related to the same interrupt/timer problem.  Obviously I will need to revert to KS 1.3 ROM to run ATK for further testing until these interrupt timers are ironed out.

I feel like I'm so close...  Just wish I knew what rogue signal causes the speedup.

Did you forget about the E clock? All 68000 CPU based Amigas use the E clock generated by the CPU. So with a 14 MHz CPU clock you should divide the E clock by 2 and a 28 MHz CPU clock divide it by 4.

Don't mess with odd asynchronous clock frequencies unless you have the extra logic to generate the proper E clock. This is exactly what the 68020+ CPU based Amigas do.     

[r00tb33r]

Did you forget about the E clock? All 68000 CPU based Amigas use the E clock generated by the CPU. So with a 14 MHz CPU clock you should divide the E clock by 2 and a 28 MHz CPU clock divide it by 4.

Right.  That's a good point.  So I read earlier that E is 1/10 of the clock input of the 68000.  I guess the thing I didn't understand there is the importance of E frequency relative to the chipset versus the processor, and yes, I did not touch it going from 14 to 28MHz.

From the beginning, stock (NTSC) 68000 Amigas have a clock input of 7.15MHz on the processor, the resulting E clock is 715KHz.  I measured the E pin on Dennis's unmodified 14MHz accelerator and it is 715KHz, because he divides it in half with a flip flop.

The 28MHz processor in my modification generates 2.8MHz E clock, which is divided in half by the flip flop per Dennis's design.  This results in a 1.4MHz E output to the Amiga, which is presumably not good.  But like this the machine is mostly working, with KS 1.3 it boots into games and they work, aside from fast music.

So today, after your reminder, I added another flip flop to cut the 1.4MHz E to get 715KHz, as in the original Amiga circuit.  I measured the E pin output with my scope and saw 715KHz.  But my Amiga now only displays a bright green screen.  It doesn't work, yet anyway.  (I re-checked and reverted to prior condition to test, I didn't break anything else.)  My bodge wires added about 6-7 inches of length (15cm, give or take), from what I see on the scope the 1.4MHz and 715KHz edges are aligned, there is no more than 1ns delay in there.  It's possible, but hard to believe this is a timing problem here.

Looking at Dennis's schematic I can see that the E clock from the processor also drives the clock pin of the flip flip flop synchronizing the /VPA signal.  So my 28MHz modification drives that flip flip clock at 2.8MHz.  Since the first divider flip flip outputs 1.4MHz, I tried driving that flip flop clock with 1.4MHz like in Dennis's 14MHz design.  This doesn't necessarily seem right, but I tried it anyway.  Still bright green screen.  I don't think this change was right, it makes more sense to leave it 2.8MHz, but was worth a try.

Your post is helpful and you pointed out a thing I hadn't done.  What do you think I should change next?

Don't mess with odd asynchronous clock frequencies unless you have the extra logic to generate the proper E clock. This is exactly what the 68020+ CPU based Amigas do.     

Yeah, I agree, looking at the division of the E clock it does look inconvenient to do 21MHz, but I can do the division by 3 circuit, it is just more complicated.  It's definitely better to get 28MHz working first.

I'm going to take a closer look at timings tomorrow, and I might have some faster flip flops on hand.  If all else fails I will connect a logic analyzer and record signals on the two versions of the accelerator and compare to see what isn't right.

[SpeedGeek]

Right.  That's a good point.  So I read earlier that E is 1/10 of the clock input of the 68000.  I guess the thing I didn't understand there is the importance of E frequency relative to the chipset versus the processor, and yes, I did not touch it going from 14 to 28MHz.

From the beginning, stock (NTSC) 68000 Amigas have a clock input of 7.15MHz on the processor, the resulting E clock is 715KHz.  I measured the E pin on Dennis's unmodified 14MHz accelerator and it is 715KHz, because he divides it in half with a flip flop.

The 28MHz processor in my modification generates 2.8MHz E clock, which is divided in half by the flip flop per Dennis's design.  This results in a 1.4MHz E output to the Amiga, which is presumably not good.  But like this the machine is mostly working, with KS 1.3 it boots into games and they work, aside from fast music.

So today, after your reminder, I added another flip flop to cut the 1.4MHz E to get 715KHz, as in the original Amiga circuit.  I measured the E pin output with my scope and saw 715KHz.  But my Amiga now only displays a bright green screen.  It doesn't work, yet anyway.  (I re-checked and reverted to prior condition to test, I didn't break anything else.)  My bodge wires added about 6-7 inches of length (15cm, give or take), from what I see on the scope the 1.4MHz and 715KHz edges are aligned, there is no more than 1ns delay in there.  It's possible, but hard to believe this is a timing problem here.

Looking at Dennis's schematic I can see that the E clock from the processor also drives the clock pin of the flip flip flop synchronizing the /VPA signal.  So my 28MHz modification drives that flip flip clock at 2.8MHz.  Since the first divider flip flip outputs 1.4MHz, I tried driving that flip flop clock with 1.4MHz like in Dennis's 14MHz design.  This doesn't necessarily seem right, but I tried it anyway.  Still bright green screen.  I don't think this change was right, it makes more sense to leave it 2.8MHz, but was worth a try.

Your post is helpful and you pointed out a thing I hadn't done.  What do you think I should change next?
Yeah, I agree, looking at the division of the E clock it does look inconvenient to do 21MHz, but I can do the division by 3 circuit, it is just more complicated.  It's definitely better to get 28MHz working first.

I'm going to take a closer look at timings tomorrow, and I might have some faster flip flops on hand.  If all else fails I will connect a logic analyzer and record signals on the two versions of the accelerator and compare to see what isn't right.

Yes, you can divide by 3 but your resulting clock still may not be a proper E clock because of the 60/40 duty cycle. So you would be better off with logic counting 10 (7 MHz) clocks and creating the proper duty cycle. You don't need to worry about VPA timing but the VMA timing may need some wait states or at least latching with the 7 MHz clock.

Also, you need logic (often described as 68000 state machine logic) to guarantee at least one 7 MHz wait state on the 68000 Address Strobe, Dtack sampling on the third 7 MHz clock and cycle termination on the falling edge of the last 7 MHz clock. The reason I am warning you about Dtack sampling on the third 7 MHz clock is because Commodore allowed sloppy Zorro2 designs with early Dtack generation. Note: The Upper and Lower Data strobes may or may not need to be delayed on write cycles. 

Now, just in case that's not enough to consider, the 68000 state machine logic needs to handle the bus arbitration signals with the proper 7 MHz timing too!      

       

[Boing-ball]

Yes, you can divide by 3 but your resulting clock still may not be a proper E clock because of the 60/40 duty cycle. So you would be better off with logic counting 10 (7 MHz) clocks and creating the proper duty cycle. You don't need to worry about VPA timing but the VMA timing may need some wait states or at least latching with the 7 MHz clock.

Also, you need logic (often described as 68000 state machine logic) to guarantee at least one 7 MHz wait state on the 68000 Address Strobe, Dtack sampling on the third 7 MHz clock and cycle termination on the falling edge of the last 7 MHz clock. The reason I am warning you about Dtack sampling on the third 7 MHz clock is because Commodore allowed sloppy Zorro2 designs with early Dtack generation. Note: The Upper and Lower Data strobes may or may not need to be delayed on write cycles. 

Now, just in case that's not enough to consider, the 68000 state machine logic needs to handle the bus arbitration signals with the proper 7 MHz timing too!      

     

Great info shared… Thanks 🙏🏻

[r00tb33r]

may not be a proper E clock because of the 60/40 duty cycle

So about that...  I've been looking at these signals with my scope (and also read some more of the 68000 datasheet), and the shocking observation I made regarding the 14MHz accelerator in OP that the flip flop (74x112) used to divide the E frequency from the processor is falling edge triggered!  Meaning the E signal it outputs is delayed by the 4 processor clock cycles (of the 10 in the 6/4 duty cycle split) and rises on the falling edge of processor E! (That doesn't seem right, but somehow it works.)  Likewise it is not 60/40 duty cycle but 50/50 as generated by the flip flop divider.  This raises a lot of questions...  Why does it work like this (50/50) and how important is the 60/40 duty cycle?  Does it not matter that the edges of the E clock that the Amiga sees are not edge aligned with the E generated by the processor, or does 68000 just not care?

VMA timing may need some wait states or at least latching with the 7 MHz clock.

What I read in the 68000 datasheet is that it's synchronized with E, I'll need to check with the scope which edge it's in sync with because the datasheet doesn't say.
The 14MHz accelerator in OP latches VMA/VPA on the 1.4MHz E clock from the processor.  That's probably not right either.

Also, you need logic (often described as 68000 state machine logic) to guarantee at least one 7 MHz wait state on the 68000 Address Strobe, Dtack sampling on the third 7 MHz clock and cycle termination on the falling edge of the last 7 MHz clock. The reason I am warning you about Dtack sampling on the third 7 MHz clock is because Commodore allowed sloppy Zorro2 designs with early Dtack generation. Note: The Upper and Lower Data strobes may or may not need to be delayed on write cycles. 

Now, just in case that's not enough to consider, the 68000 state machine logic needs to handle the bus arbitration signals with the proper 7 MHz timing too!  

Wow, lots useful info, thanks!

There are likely a lot of timing violations in the 14MHz accelerator in OP.  But somehow it was working even at 28MHz.  But so far my attempts at changes to the E signal generation all resulted in a bright green or a black screen.  I even tried positive edge triggered flip flops for the divider so the rising edge would be aligned with the rising edge of E from the processor, but that did not produce a working result.  I will try a few more things I thought of and also make a timing diagram of what I see and what I did, or maybe a picture from my scope for the next post.

The only things I have been changing right now is the generation of the E signal and sometimes latching of VMA/VPA.  Just this change alone causes the breakage, I think it's best I focus on this one thing at a time?

[r00tb33r]

I made progress.  I think all this just might work out.

I made screenshots with my scope of what is going on with the E signal.

Initial shows the E from processor (yellow), vs the half divided E output of the modified accelerator.  This is the condition at the beginning of this thread.

I was able to hide every other E pulse with an AND gate with inputs from two diver flip flops, the resulting E signal is 25/75 duty cycle.  This produced a white screen, by itself this was not enough.

Another attempt was to just use the divider output with 50/50 duty cycle, as in Dennis's design, but likewise by itself it produced a white screen.

Last (working) picture shows E from processor (yellow), 1st divider flip flop (green), and the E output from AND of two divider flip flops (pink).  There is about 8ns delay of the pink pulse vs yellow, and a 4ns delay relative to green.  I was able to boot to Workbench with a physical floppy (Epson SMD-300), but not the Gotek, although I was able to run ATK from Gotek and do the timer tests, they all passed.  No game tests because I don't have any on hand on a physical floppy, need to get the Gotek working.  I think it's a timing problem, I think I need to shave at least 4ns with faster flip flops, which I don't have on hand, will need to order some.  This is all the progress I can make until then.
So what got it working is feeding this E signal into the NOR gate (U4C on the schematic), as well as using this E to trigger the /VPA and /VMA latching (U5B).

I have an idea for how to generate proper 40/60 duty cycle, by doing an AND of the 1st divider flip flop and the E from processor, then XOR with 2nd divider flip flop.  The cycle math works out as follows, at 28MHz the period of E the Amiga chipset expects is 40 cycles (4x10), so the 50/50 pulse generated by the divider is 20 cycles.  The E pulse from the processor is 4 cycles.  By using the circuit I described I cut off 4 cycles from the pulse of 20.  The result is a pulse of 16 cycles, which is 40% of the 40 cycle period.  I am not going to try this until I get faster divider flip flops because this isn't the source of my problem at the moment.

observation I made regarding the 14MHz accelerator in OP that the flip flop (74x112) used to divide the E frequency from the processor is falling edge triggered!  Meaning the E signal it outputs is delayed by the 4 processor clock cycles (of the 10 in the 6/4 duty cycle split) and rises on the falling edge of processor E![/b] (That doesn't seem right, but somehow it works.) 

I kept thinking about this, and what I read in the 68000 datasheet.  The datasheet says the beginning of the E period is not guaranteed, so it wouldn't matter if the generated E pulse is delayed by whole cycles.  This is likely why this "just works".  I did still have a concern whether it's a problem when externally generated E is somewhere else relative to the processor state machine, but I realize the divided E frequency wouldn't coincide with any processor state machine anyway, so it seems this doesn't matter either since I already know that works.

[SpeedGeek]

I made progress.  I think all this just might work out.

I made screenshots with my scope of what is going on with the E signal.

Initial shows the E from processor (yellow), vs the half divided E output of the modified accelerator.  This is the condition at the beginning of this thread.

I was able to hide every other E pulse with an AND gate with inputs from two diver flip flops, the resulting E signal is 25/75 duty cycle.  This produced a white screen, by itself this was not enough.

Another attempt was to just use the divider output with 50/50 duty cycle, as in Dennis's design, but likewise by itself it produced a white screen.

Last (working) picture shows E from processor (yellow), 1st divider flip flop (green), and the E output from AND of two divider flip flops (pink).  There is about 8ns delay of the pink pulse vs yellow, and a 4ns delay relative to green.  I was able to boot to Workbench with a physical floppy (Epson SMD-300), but not the Gotek, although I was able to run ATK from Gotek and do the timer tests, they all passed.  No game tests because I don't have any on hand on a physical floppy, need to get the Gotek working.  I think it's a timing problem, I think I need to shave at least 4ns with faster flip flops, which I don't have on hand, will need to order some.  This is all the progress I can make until then.
So what got it working is feeding this E signal into the NOR gate (U4C on the schematic), as well as using this E to trigger the /VPA and /VMA latching (U5B).

I have an idea for how to generate proper 40/60 duty cycle, by doing an AND of the 1st divider flip flop and the E from processor, then XOR with 2nd divider flip flop.  The cycle math works out as follows, at 28MHz the period of E the Amiga chipset expects is 40 cycles (4x10), so the 50/50 pulse generated by the divider is 20 cycles.  The E pulse from the processor is 4 cycles.  By using the circuit I described I cut off 4 cycles from the pulse of 20.  The result is a pulse of 16 cycles, which is 40% of the 40 cycle period.  I am not going to try this until I get faster divider flip flops because this isn't the source of my problem at the moment.
I kept thinking about this, and what I read in the 68000 datasheet.  The datasheet says the beginning of the E period is not guaranteed, so it wouldn't matter if the generated E pulse is delayed by whole cycles.  This is likely why this "just works".  I did still have a concern whether it's a problem when externally generated E is somewhere else relative to the processor state machine, but I realize the divided E frequency wouldn't coincide with any processor state machine anyway, so it seems this doesn't matter either since I already know that works.

The only reason this sloppy E clock timing works at all is because the 8520 CIA is not a Motorola 6800 peripheral chip. If it was, this 14 MHz accelerator design would fail. Commodore designed these custom chips for the Amiga and using the E clock to drive them somewhat simplified the Amiga's I/O hardware design.

But just because you can sometimes get away with sloppy timing does not means it's often good idea to do so.

The fundamental timing problem is still not corrected because @ 28 MHz the CPU's E clock cycle will end in one 7 MHz clock. A more reliable way to handle this problem is to disable the 68000 E clock CPU cycle by disconnecting VPA and connecting a pull-up resistor. You then add logic to generate VMA when the E clock is low and keep it latched when the E clock is high. Here are some example boolean logic equations:

/VMA = /E * /VPA # /VMA * E

Next you need to generate ETERM to terminate the cycle:

/ETERM.D = E * /AS * /VMA
/EDTACK.D = EDTACK * /AS * /ETERM
/DTACK.D = DTACK * /AS * /EDTACK
/DTACK.T = DTACK * /AS * /EDTACK
 
NOTE: ETERM and EDTACK are registered on the rising edge of the 7 MHz clock (but you can experiment with the falling edge). DTACK.D is registered on the 14 MHz clock. Also, DTACK.D is a Tri-State signal.

As far as creating the proper 60/40 duty cycle, that's probably not as important as having the E clock at the proper frequency and having the rising edge synchronized with the 7 MHz clock. The main reason to keep the correct duty cycle is performance concerns.

Then when you get the E clock timing problem solved, you can worry about the other timing problems listed in my previous post.        

BTW, some 68020+ systems can be modified for improved performance. Here is the link:

https://forum.amiga.org/index.php?topic=74945.msg850556