14Mhz Accelerator

[Mathesar]

Originally Posted by hooverphonique

How does the generated E-clock relate to the orignal 7MHz clock as compared to a standard amiga?

You mean the phaae/timing of the e clock relative to the 7mhz cpu clock? Will have to check. The vma timing looks great, going low when e is low and then staying low when e goes high again. Only when e goes low again does vma go high again. It looks like a proper peripheral cycle that the cia's should understand. The only real difference is is that e is now a 50% duty cycle signal. I will post some scope images tonight. I will also hook up a logic analyzer to capture some more signals at once.

On a positive note, a lot of stuff is working now! It boots into diagrom @14MHz, passes the extended chip memory test and I can see video, hear audio (Chucky's diagrom anthem ) and use the keyboard. Just one tiny (i hope) issue to solve.....

EDIT: one more thing to mention is that in Diagrom, the joystick fire buttons work fine (they are routed over the CIA's) as does the power LED, ROM overlay, etc, etc. These are all ODD CIA IO lines. This CIA is on int2.
Also the keyboard works although sometimes it misses a keystroke or release event. Disk drive is completely messed up but that is mainly an EVEN CIA function. Also, the EVEN CIA is on int6.
So one theory I have is that there is skew on the IPL0..2 lines and that by sampling too early INT6 gets recognized as INT2....

[Mathesar]

Quick update:
It is not interrupts. It couldn't be because diagrom does not use interrupts during the CIA tests. . EDIT: I was confused, it depends on the test. The CIA test DOES use interrupt. Level 3 in fact and it says so on the screen
So it is indeed E clock timing. I am using ACT logic and the E clock circuit is 100% like the Livio Plos version. Thinking my logic might be too fast I loaded some lines with up to 1nF of capacitance and that made things better with 4 out of 6 CIA test passing.

I am now measuring all relevant signals (E, VPA, VMA, AS, address setup, etc) on the accelerator and a stock A500. We will fix this

[PR77]

Do you have an oscilloscope or logic analyser plot of /VMA, /VPA, E with respect to /AS?

[Mathesar]

Originally Posted by PR77

Do you have an oscilloscope or logic analyser plot of /VMA, /VPA, E with respect to /AS?

Here is a rough diagram I drew up from the scope measurement.
It's the de-assertation that worries me. E,VMA and AS are all de-asserted a few ns from each other. I got it working better by loading the VMA7 and E7 lines giving me some a bit better data hold timing.
VPA is released very slowly on my Amiga. It seems like an open collector driver with a pullup.

I should find a way for the CPU to sample early on a CIA read cycle... preferably with very little logic.

Attachment 71633

EDIT: previous image had inverted version of E14 drawn

[hooverphonique]

Yes, I meant phase/timing of E compared to 7M

ACT has strong output drive, so make sure that it's not just the speed/tpd causing problems - you could have reflections on signals generated by you if they connect to a long Amiga trace. Using a 33-47ohm series resistor may help, or using logic with limited output drive (e.g. AHCT).

[Mathesar]

Originally Posted by hooverphonique

Yes, I meant phase/timing of E compared to 7M

ACT has strong output drive, so make sure that it's not just the speed/tpd causing problems - you could have reflections on signals generated by you if they connect to a long Amiga trace. Using a 33-47ohm series resistor may help, or using logic with limited output drive (e.g. AHCT).

I will have a look. I have a Rigol DS1052E 50MHz scope with some 60MHz probes. I din't see any reflections but it might indeed be a problem. The only reason for having ACT logic is for the RAM controller. To be able to block _AS the RAM address $C00000 must be decoded *before* _AS hits the Amiga itself. Looking at the worst case timing in the 68HC000 datasheet there is not much time. However, looking at the real timing on my Amiga here I might have more time. So, maybe HCT logic would be good enough.

[Mathesar]

Here is vma vs E on a standard amiga 500 with an 68010 cpu@7Mhz

And here with the 68HC000@14Mhz and the divided E clock

Vma is in yellow, E is in blue.

First thing to notice is the signal levels.
But the main difference is that e is de-asserted way earlier on the original. Also, there is quite some severe ringing on the VMA signal and E signal. These signals come from ACT jk flipflops so Hooverphonique has a point here.
Slower logic with less drive should cause less ringing and delay VMA so that it transitions after E has risen.

I have ordered some HCT parts to find out...

EDIT: uploaded the wrong screenshots. General story is the same though. E is de-asserted too late (or VMA too early) and there is severe ringing.

[Mathesar]

Progress! It's all in the E vs VMA timing. It seems like writes to the CIA registers go wrong. The CIA's latch data on the falling edge of E while CS is low. CS is controlled by the address decoding and VMA. if VMA rises too quickly after E has fallen the write will fail. By mixing and matching some different logic families I get this:

I can run the single most important application for any accelerated Amiga . (In fact, this application is so important that at one point it was even hacked to run on certain bloodsucking accelerators. Luckily it has been updated since.)

No fast RAM still. That is the next step. And timing is still iffy, sometimes the Amiga doesn't boot. I need even better and more robust E/VMA timing. But hey, slowly getting there!

[Mathesar]

Ok. How did this ever work way back in 1990-something?

I was able to fix the E vs VMA timing and now the system is consistently booting into diagrom and passing CIA tests. By resetting the second JK flipflop with the delayed AS I get a nice margin between the falling edge of E and the rising edge of VMA.

However.... booting into kickstart depends on how the E clock starts in relation to the internal 68000 S0...S7 states and thus _AS timing. Sometimes it works and then everything works fine but sometimes it doesn't.
The way synchronization to E clock works means that sometimes you can access the CIA immediately but sometimes the processor will have to wait an extra E clock cycle. With this circuit it seems to depend on how the E clock started how often the CPU has to wait this extra cycle. And somehow that messes up Kickstart. I have tested 1.2 and 3.1 and they both behave the same.

Does anyone have some insight in this?
Here is my version of the bus interface so far:
bus_interface.pdf
Not the full schematic because I don't want anyone to build it just yet (and be dissappointed ). This is a work in progress... But, the schematic does include my 4046 based clock doubler and the elimination of the hex inverter ic. The whole circuit is just 4 IC's now.
This is how VPA7 vs E7 look like (vpa7 in yellow, E7 in blue):

In this capture, the system booted fine.

[Mathesar]

Originally Posted by hooverphonique

How does the generated E-clock relate to the orignal 7MHz clock as compared to a standard amiga?

After some more debugging I think I now know what you are referring too. There are 2 problems with the circuit from Richter / Livio:

1) VMA is deasserted almost at the same instance as E is falling. This causes writes to the CIA's to fail sometimes. This I have fixed now.

2) On a standard 68000, E should toggle some time after the falling edge of the 7MHz clock. On this circuit however, it can toggle after either the falling edge or the rising edge of the 7MHz clock . It depends on how the E clock started as opposed to the clock doubler and/or internal state of the CPU. It is a 50% chance after every power cycle. I have now confirmed using the scope that this is indeed the problem.
Now, the CIA's have no notion of the 7MHz clock. However, Gary has a notion of the clock. And Gary has to register the interrupts from the CIA and latch them.... I have also seen that timer interrupts occur about 80ns after the falling edge of E. My guess: Gary does priority encoding of all incoming interrupt lines and then latches the 3bit IPL0..2 value at the rising edge of the 7MHz clock..
When interrupts change too close too the rising edge, skew in the priority encoder causes the wrong interrupt to be latched and boom, a visit from the Guru (#00000004)...Edit: Interrupts go into Paula. I must have been too tired when I made this up. And from what I measured Paula does a pretty good job of avoiding metastability and managing skew. The problem is somewhere else, see some posts further down.

[Mathesar]

Originally Posted by Mathesar

With this circuit it seems to depend on how the E clock started how often the CPU has to wait this extra cycle. And somehow that messes up Kickstart. I have tested 1.2 and 3.1 and they both behave the same.

To clarify, my latest theory is thus that it is probably not the extra wait cycle that causes Kickstart to guru, it is the timing of the interrupts into gary that causes the problems. Root cause remains the E clock phase though. It is probably fixable by further mixing and matching of logic families to make use of their propagation delay. That is not a very robust solution though.

Problem is that all this is easily fixable with a CPLD or FPGA with gates to spare. However, the charm of this accelerator is that it uses only a few standard logic IC's.

[Mathesar]

one more thing ()
I added the fast ram chips to the board. That part worked out of the box so when the system boots this is what Sysinfo reports (under Kickstart 1.2):

[Mathesar]

I think I fixed it.
It was not interrupts but it was related to how the E clock relates to the 7MHz clock, or even more specific: the 3.54MHz CCK clock which governs access to the chipram and thus the timing of DTACK.

Normally, the 68000 will align itself more or less to the chipset, running it's bus cycles in sync with DTACK. However, every time the CPU accesses the CIA's it will sync up with the E clock. The next chipram cycle after a CIA cycle is thus out of sync with the CCK clock.
Now, there are 4 possible "phases" of E vs CCK after a cold start. Only one of these possible phases caused timing problems with this "chipram cycle after CIA cycle" because of the design of the AS/DTACK sync logic.
You can imagine how this was so hard to find...
I have fixed it now by changing the AS/DTACK logic and it seems stable now although I would have to do some more testing.

Board revision will follow as the board is currently looking like this :

[amigasith]

I have to admit that I admire people with hardware designing / debugging skills - this is awesome stuff, @Mathesar

[AJCopland]

This has been really cool to follow along with, I don't think I've understood anything, but thankyou for posting it all!

Also congratulations on figuring out the problems!

[Mathesar]

Originally Posted by amigasith

I have to admit that I admire people with hardware designing / debugging skills - this is awesome stuff, @Mathesar

Thanks, but from my side as a hardware guy I really admire the coders and artists on the software side of things

[Mathesar]

Originally Posted by AJCopland

This has been really cool to follow along with, I don't think I've understood anything, but thankyou for posting it all!

Also congratulations on figuring out the problems!

Nowadays I don't have much time to do any big hardware projects from scratch outside of work. But this little project was just too tempting!

[hooverphonique]

Originally Posted by Mathesar

I think I fixed it.

Congratulations, great stuff! Now I guess i need to try to build one of these (when you release it) for my recently acquired A500
Is there an option to switch to 7MHz (or use A500 AS/DTACK) in order to slow the machine down to something like original speed without removing the board?

[Mathesar]

Originally Posted by hooverphonique

Is there an option to switch to 7MHz (or use A500 AS/DTACK) in order to slow the machine down to something like original speed without removing the board?

There will be solder jumpers so one can build the card without fast ram if desired. It's a bit of a useless option as without fast ram the 14MHz 68000 is barely faster than a standard 68000. But it allows one to build the original design as it was once intended.

To go back to a more compatible state the easiest option would be to just disable fast ram. The onboard $C00000 ram overrules any trapdoor ram. But once disabled that slow trapdoor ram will be there again. I could do that by using a 74HCT27 chip instead of the 74HCT02 (triple input nor instead of 2 input nor). These chips are a little less common nowadays but there can than be a jumper (or a switch connected to it) to disable/enable the fast ram. Not ideal though. Drilling holes for switches is out of fashion and opening the case to set a jumper is a bit awkward.

What do you think? Useful?

[hooverphonique]

Well, yes, I did mean a way to switch it on and off using a switch or similar, but I understand your comment about drilling holes, etc.
I still think it's a sensible idea to have this option somehow, though, so you won't have to remove the board in case some old games/demos don't work correctly at the faster speed.