16 April 2021, 08:19 | #101 | |
Registered User
Join Date: Aug 2014
Location: Netherlands
Posts: 699
|
Quote:
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.... Last edited by Mathesar; 16 April 2021 at 13:12. |
|
18 April 2021, 21:46 | #102 |
Registered User
Join Date: Aug 2014
Location: Netherlands
Posts: 699
|
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 Last edited by Mathesar; 22 April 2021 at 08:30. |
18 April 2021, 22:45 | #103 |
Registered User
Join Date: Oct 2017
Location: Germany
Posts: 193
|
Do you have an oscilloscope or logic analyser plot of /VMA, /VPA, E with respect to /AS?
|
19 April 2021, 09:12 | #104 | |
Registered User
Join Date: Aug 2014
Location: Netherlands
Posts: 699
|
Quote:
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 Last edited by Mathesar; 06 May 2021 at 14:43. |
|
19 April 2021, 10:09 | #105 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,637
|
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). |
19 April 2021, 10:25 | #106 | |
Registered User
Join Date: Aug 2014
Location: Netherlands
Posts: 699
|
Quote:
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. Last edited by Mathesar; 19 April 2021 at 11:05. |
|
21 April 2021, 21:30 | #107 |
Registered User
Join Date: Aug 2014
Location: Netherlands
Posts: 699
|
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. Last edited by Mathesar; 22 April 2021 at 08:27. |
25 April 2021, 22:40 | #108 |
Registered User
Join Date: Aug 2014
Location: Netherlands
Posts: 699
|
Progress!
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! Last edited by Mathesar; 26 April 2021 at 06:40. Reason: data is latched on the falling edge of E |
03 May 2021, 21:34 | #109 |
Registered User
Join Date: Aug 2014
Location: Netherlands
Posts: 699
|
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. Last edited by Mathesar; 04 May 2021 at 11:45. |
06 May 2021, 12:29 | #110 | |
Registered User
Join Date: Aug 2014
Location: Netherlands
Posts: 699
|
Quote:
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. Last edited by Mathesar; 11 May 2021 at 21:25. Reason: Does anyone actually read this? Interrupts are not handled by Gary |
|
06 May 2021, 13:15 | #111 | |
Registered User
Join Date: Aug 2014
Location: Netherlands
Posts: 699
|
Quote:
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. Last edited by Mathesar; 07 May 2021 at 09:02. |
|
06 May 2021, 14:45 | #112 |
Registered User
Join Date: Aug 2014
Location: Netherlands
Posts: 699
|
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): |
11 May 2021, 21:42 | #113 |
Registered User
Join Date: Aug 2014
Location: Netherlands
Posts: 699
|
I have found the problem!!!!!
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 : Last edited by Mathesar; 11 May 2021 at 22:08. |
11 May 2021, 23:24 | #115 |
Registered User
Join Date: Sep 2013
Location: Beeston, Nottinghamshire, UK
Posts: 240
|
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! |
12 May 2021, 19:43 | #116 | |
Registered User
Join Date: Aug 2014
Location: Netherlands
Posts: 699
|
Quote:
|
|
12 May 2021, 19:45 | #117 |
Registered User
Join Date: Aug 2014
Location: Netherlands
Posts: 699
|
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!
|
12 May 2021, 22:29 | #118 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,637
|
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? |
13 May 2021, 14:37 | #119 | |
Registered User
Join Date: Aug 2014
Location: Netherlands
Posts: 699
|
Quote:
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? |
|
13 May 2021, 23:21 | #120 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,637
|
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. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
DMA debugger and 14Mhz 68K | ovale | support.WinUAE | 3 | 10 June 2014 15:10 |
AGA on 14mhz 68000 | little | request.UAE Wishlist | 6 | 03 May 2012 23:09 |
A2620 Accelerator Card 12mhz instead of 14mhz. Problem? | kjmann14 | support.Hardware | 1 | 19 May 2011 00:35 |
A500 MTEC 68030/14Mhz | bebek | Hardware mods | 9 | 20 January 2010 22:30 |
|
|