New Universal Agnus 8372, 75 etc

[QuikSanz]

Amigakit and AOTL maybe but, Amiga Store EU I bet would sell them, they like niche stuff.

[Exodous]

Originally Posted by Bruce Abbott

That was the Power Computing XL 1.76MB high-density floppy drive.

Review by Paul Toyne in Feb 1994

Digressing I know, but I'd forgotten I'd even written that review

[kipper2k]

Originally Posted by QuikSanz

Amigakit and AOTL maybe but, Amiga Store EU I bet would sell them, they like niche stuff.

I believe Nonarkitten has UK and Canada sorted, others are to be sorted

[salteadorneo]

Originally Posted by Bruce Abbott

That was the Power Computing XL 1.76MB high-density floppy drive.

Review by Paul Toyne in Feb 1994


Photos of the interface board

I remember that they had put a GAL inside the SONY floppy drive that did much of the magic. Unfortunately, I don't have the code for that GAL.

http://eab.abime.net/attachment.php?...1&d=1277937563

The issue of HD floppy drive support in Paula was one of those things that commodore engineers had already thought of, but never implemented. What I never understood is why they didn't put it in the AGA.


Implementing it now would be nice, if possible, as it would be easier to change the floppy drives on the Amigas.

[Bruce Abbott]

Originally Posted by salteadorneo

I remember that they had put a GAL inside the SONY floppy drive that did much of the magic. Unfortunately, I don't have the code for that GAL.

http://eab.abime.net/attachment.php?...1&d=1277937563

The Power Computing drive didn't use that hack. It is designed to do the job of several TTL logic ICs that were added to the Chinon FB-357A high density Amiga drive. The circuit for this is known, so it should be possible to recreate the GAL code (or just use discrete TTL ICs).

The issue of HD floppy drive support in Paula was one of those things that commodore engineers had already thought of, but never implemented. What I never understood is why they didn't put it in the AGA.

It wasn't needed., and might not have been that easy to implement (they had enough trouble getting AGA to work properly as it was!).

Implementing it now would be nice, if possible, as it would be easier to change the floppy drives on the Amigas.

You will think it's great until you realize you now have some disks that can't be read in a standard Amiga drive.

[salteadorneo]

The idea is to make it easy to change the floppy drives themselves. Using high-density floppies is a plus, not a necessity. I have two Amiga 357A and I use them regularly. Although, in real life, it is more useful to have USB ports. Great software the Posiedon. :-)

[Magic]

I just uploaded HD Floppy Fix to the Zone. It is a collection of information that I gathered years ago about making a small pcd that adapts some pc hd floppy drives to work on an Amiga in HD mode.

It works without any software drivers. I have 2 Teac drives so equipped and they work fine. I hope that someone finds it useful.

[QuikSanz]

How goes the battle on this project, any headway?

Chris

[nonarkitten]

Originally Posted by QuikSanz

How goes the battle on this project, any headway?

Chris

Yes.

On the matter of the iCE65, Lattice refuse to grant access to developing for them. The combination of the original software AND license is impossible to get, Lattice blames Synopsys, and vice-versa, so we're giving up on that one. Which is too bad, they're cheap and plentiful. If anyone knows of an archaic (c. 2011) crack for iCEcube2, please let everyone know, but for now, the iCE65 is a dead end (1).

On the matter of the iCE40, we believe we've confirmed that the HX variant is still 5V tolerant at least in as much as is needed on the Amiga, which isn't "really" a 5V device, it's TTL 5V which, by it's nature, provides strong resistors against the 5V anyway (from the pull-ups). I don't know yet if it will sustain against 5V CMOS for prolonged periods without a series resistor, but right now, all signs point to "yes."

We also finally got the chips, boards and programmers all lined up. The iCE40 HX is not 100% pin compatible with the iCE65 as it adds dual PLLs with their own mini ground circuit. So we respun the boards and, being unwilling to pay more for shipping than the boards cost, get hit with a 6-ish week turn around. Sigh.

So we have some boards in hand, 50-ish iCE40 chips of various sizes and we're just starting to assemble them. I'm getting the latest iCEcube2 set up and I'll import Denise first (low hanging fruit and all) to just get the basics up and running.

(1) There are still two possibilities. Synopsis Synplify may still support the iCE65. It's insanely expensive though. Second is Yosys. Supporting the iCE65 might be fairly easy and supposedly, the initial versions were tested against it, and, with Lattice rather abruptly killing it, Clifford decided to move on. But we might be able to get some traction there.

So that's where we're at.

[QuikSanz]

Still keeping a look out for these Chips every where. Should be nice and snappy.

[Mathesar]

Questions/thoughts,

I have been probing signals around Gary lately trying to figure why E-clock phase matters in making my 14MHz accelerator work or not (spoiler: It may have to do with ROM access time of all things) and I noticed something: The _DBR/_BLIT signal going from Agnus into Gary lets Gary know whether there is a free bus slot available for the 68000. We were always told that at maximum, only half of the bus slots are available for the 68000. But is this really true? Because _DBR/_BLIT is often negated during several consecutive slots. Most noticeably during the blanking period. The reasons the 68000 doesn't get these slots is because at 7MHz the 68000 can't use any more and (probably) because of Gary's timing. So, these slots remain idle.

Would it be possible with this new Gary to run the 68000 at 14MHz and allow ALL idle slots to be used by the CPU? Without any bitplane DMA the performance would be double that of 7MHz and even with bitplanes the 68000 would run faster as it could use the idle slots during the blanking period. Any thoghts?

[Niklas]

Originally Posted by Mathesar

Would it be possible with this new Gary to run the 68000 at 14MHz and allow ALL idle slots to be used by the CPU? Without any bitplane DMA the performance would be double that of 7MHz and even with bitplanes the 68000 would run faster as it could use the idle slots during the blanking period. Any thoghts?

The normal Agnus chip doesn't allow the CPU to do accesses in back-to-back DMA slots. In the post on the top of this page http://eab.abime.net/showthread.php?t=111733&page=3 Toni gives his reasoning as to why that could be.

Of course, if Agnus and Gary are reimplemented then the protocol between them could be changed arbitrarily. Perhaps an easy(-ish) way to experiment with that is using the Minimig core in the MiSTer project: https://github.com/MiSTer-devel/Minimig-AGA_MiSTer.

[Samurai_Crow]

Originally Posted by Niklas

The normal Agnus chip doesn't allow the CPU to do accesses in back-to-back DMA slots. In the post on the top of this page http://eab.abime.net/showthread.php?t=111733&page=3 Toni gives his reasoning as to why that could be.



Of course, if Agnus and Gary are reimplemented then the protocol between them could be changed arbitrarily. Perhaps an easy(-ish) way to experiment with that is using the Minimig core in the MiSTer project: https://github.com/MiSTer-devel/Minimig-AGA_MiSTer.

Or any FPGA setup. I have Minimig running on my SiDi for much cheaper but would like to sell it.

Maybe I can save up for a MISTer myself one day. I'd like to hack up a CPU core for MiniMig that's actually pipelined someday.

[Mathesar]

Originally Posted by Niklas

The normal Agnus chip doesn't allow the CPU to do accesses in back-to-back DMA slots. In the post on the top of this page http://eab.abime.net/showthread.php?t=111733&page=3 Toni gives his reasoning as to why that could be.

Of course, if Agnus and Gary are reimplemented then the protocol between them could be changed arbitrarily. Perhaps an easy(-ish) way to experiment with that is using the Minimig core in the MiSTer project: https://github.com/MiSTer-devel/Minimig-AGA_MiSTer.

I don't want to challenge an authority like Tony but are we really sure about Agnus not allowing back-to-back CPU accesses? To me it seems like it's only about the 68000. I have been doing a LOT of probing lately and it seems like Gary just samples the _AS at every positive edge of CCK. Now, when _BLIT(_DBR) is also de-asserted, gary will assert _DTACK. It does not matter whether the slot is "odd" or "even". As long as _BLIT is not asserted and _AS is asserted on the rising edge of CCKQ, Gary will assert _DTACK and a memory access into chipram will be initiated. See the scope traces below:

I have numbered the memory slots by counting the CCKQ cycles and colored the CPU access cycles in red. You can see that the CPU happily uses both the odd and even cycles. This happens because sometimes the 68000 does some internal cycles throwing it "out of sync".

Now, with a 14MHz CPU Gary would not prevent us from doing back-to-back cycles. And maybe Agnus would not prevent us either. I have to do some more measurements here but I hope Agnus just multiplexes the CPU address bus onto the chipram address bus without any latches involved. I say "hope" because address setup time is the last thing that could prevent back-to-back cycles (and latches would certainly prevent that!).

PS: @nonarkitten: the code for Gary that is currently in the github repo is not the latest version I think?

[Mathesar]

Just another note. According to the Amiga Hardware reference manual:

The 68000 uses only the even-numbered memory access cycles. The 68000
spends about half of a complete processor instruction time doing internal
operations and the other half accessing memory. Therefore, the allocation
of alternate memory cycles to the 68000 makes it appear to the 68000 that
it has the memory all of the time, and it will run at full speed.

Some 68000 instructions do not match perfectly with the allocation of even
cycles and cause cycles to be missed. If cycles are missed, the 68000 must
wait until its next available memory slot before continuing. However, most
instructions do not cause cycles to be missed, so the 68000 runs at full
speed most of the time if there is no blitter DMA interference.

This is a simplified explanation and not completely true.

[nonarkitten]

Originally Posted by Mathesar

I don't want to challenge an authority like Tony but are we really sure about Agnus not allowing back-to-back CPU accesses?

This is mostly hearsay, but I've heard that some accelerators tried pushing two accesses into that 280ns window with variable success rate. At 14MHz, the 68000 is probably too slow still to do that reliably and you need to have really fast chip RAM installed.

Originally Posted by Mathesar

Now, with a 14MHz CPU Gary would not prevent us from doing back-to-back cycles. And maybe Agnus would not prevent us either. I have to do some more measurements here but I hope Agnus just multiplexes the CPU address bus onto the chipram address bus without any latches involved. I say "hope" because address setup time is the last thing that could prevent back-to-back cycles (and latches would certainly prevent that!).

Well now, that it the problem, isn't it. The latches lock the CPU out for 50% of the cycles regardless -- that's it's best case access. The BLIT signal is to steal the remaining 50% from the CPU as well.

Originally Posted by Mathesar

PS: @nonarkitten: the code for Gary that is currently in the github repo is not the latest version I think?

Why would you think this?

[Mathesar]

Originally Posted by nonarkitten

Well now, that it the problem, isn't it. The latches lock the CPU out for 50% of the cycles regardless -- that's it's best case access. The BLIT signal is to steal the remaining 50% from the CPU as well.

_BLIT is not limiting us. If you look at the first set of scope traces I posted you can see that _BLIT is low for every free slot. It is not only low during the even cycles as suggested by the HRM. Also, Gary allows (and Agnus accepts!) even and odd slots to the CPU. So, there is no locking out of 50% of the cycles. The only question is whether we can do it back-to-back.

Why would you think this?

Because I was looking at your _DTACK code and noticed it is clocked at 14MHz while my measurement suggest it is clocked at just C3. Also, I think DTACK is released asynchronously and not synchronously.

[Niklas]

Originally Posted by Mathesar

Now, with a 14MHz CPU Gary would not prevent us from doing back-to-back cycles. And maybe Agnus would not prevent us either.

Something to think about: Imagine Agnus running in a normal 7 MHz Amiga. And consider the situation when the CPU is doing an access in slot n. The CPU's AS signal will be negated some time after the access is complete, so AS will still be asserted some time after the end of slot n. The time when slot n ends is the time when slot n+1 starts. At what point should Agnus decide if the CPU actually wants to do an access in slot n+1, or just haven't negated AS yet? The resolution (I claim) is that if slot n was used by the CPU then slot n+1 may not be used by the CPU, even though slot n+1 is not assigned to any DMA channel.

[Mathesar]

Originally Posted by Niklas

Something to think about: Imagine Agnus running in a normal 7 MHz Amiga. And consider the situation when the CPU is doing an access in slot n. The CPU's AS signal will be negated some time after the access is complete, so AS will still be asserted some time after the end of slot n. The time when slot n ends is the time when slot n+1 starts. At what point should Agnus decide if the CPU actually wants to do an access in slot n+1, or just haven't negated AS yet? The resolution (I claim) is that if slot n was used by the CPU then slot n+1 may not be used by the CPU, even though slot n+1 is not assigned to any DMA channel.

I understand what you mean. But I think (and not claiming the truth either) that Agnus does not decide that (blocking the next slot after a CPU slot). It's all governed by Gary.
There are 2 signals to consider:
BLIT - goes from Agnus to Gary to indicate there is a free slot.
BLISS- goes from Gary to Agnus to indicate the CPU is going to use the free slot.
See below scopetrace where you can see BLISS being asserted in sync with DTACK:

When BLISS is not asserted, the CPU is not using that cycle, regardless of AS.

[Mathesar]

Originally Posted by Mathesar

Because I was looking at your _DTACK code and noticed it is clocked at 14MHz while my measurement suggest it is clocked at just C3. Also, I think DTACK is released asynchronously and not synchronously.

Never mind, I see how it works now. You wanted to avoid latches and are using C3 in you DTACK in another way