New Universal Agnus 8372, 75 etc

[Niklas]

Originally Posted by Mathesar

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.

Have a look at this document: https://github.com/nonarkitten/amiga...gnus/AGNUS.pdf. On page 4 it says: RGEN* "Active low. When this signal is asserted along with AS*, the processor uses A1 to A8 to access one of the device registers or put a value on the RGA outputs to select registers outside the device." Then on page 14 is Figure 4, Processor Access, where AS and RGEN/RAMEN are indicated.

In Minimig's implementation, the BLISS signal is used only to count the number of DMA slots that the CPU request to use the slot, but was rejected: https://github.com/MiSTer-devel/Mini...l/agnus.v#L400 (bls is the BLISS signal).

[Mathesar]

Originally Posted by Niklas

Have a look at this document: https://github.com/nonarkitten/amiga...gnus/AGNUS.pdf. On page 4 it says: RGEN* "Active low. When this signal is asserted along with AS*, the processor uses A1 to A8 to access one of the device registers or put a value on the RGA outputs to select registers outside the device." Then on page 14 is Figure 4, Processor Access, where AS and RGEN/RAMEN are indicated.

In Minimig's implementation, the BLISS signal is used only to count the number of DMA slots that the CPU request to use the slot, but was rejected: https://github.com/MiSTer-devel/Mini...l/agnus.v#L400 (bls is the BLISS signal).

The implementation in Minimig might be wrong But seriously, if you probe the signals it doesn't make sense. BLISS is asserted all the time by Gary whenever DBR is not asserted and the CPU wants to do an access. It is not asserted every 4th cycle (blitter nasty = 0) or so.
Nonarkitten's github contains a lot more interesting information besides the Agnus datasheet, including a schematic for the early Agnus (A1000?) but unfortunately the address multiplexer for the CPU is external on that version The schematics do show however how DBR is generated as part of the register address encoder. Basically DBR is asserted for every DMA access, be it blitter, copper, bitplanes, etc. It is also used to tristate the register address bus when not used by Agnus so that the CPU can taken over. This is consistent with what I see on the scope.
So, I think we can be sure of DBR's function: to indicate to Gary when the slot is free. But that also means that Gary does not know what kind of DMA is going on when DBR asserted. It could be bitplanes, audio, blitter etc. So, it is impossible for Gary to "slowdown" the blitter and steal a cycle from Agnus because Gary does not know when a blitter cycle is occuring. Only Agnus knows that. So that leaves the function of BLISS a little unsure although I think it is to indicate to Agnus the CPU will be using the cycle because, as you also noticed, AS/RAMEN/REGEN are not really suitable for that as these might be asserted to early or to late regarding the cycle of relevance. I will do some more measurements when I have time...

[nonarkitten]

Originally Posted by Mathesar

_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. 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.

I agree that the Verilog code doesn't *FEEL* right. Looking at PALCAS and PALEN, it's a fair bit off, but when I tried copying the old PLA logic verbatim, that didn't work and this does. When I have some more spare time, I'd love to revisit Gary and see if it's possible to adhere to something more "in spirit" of the original PAL logic.

On the Amiga 1000, there were four clocks each phase shifted. A 45-degree phase shift at 3.5MHz coincides with a single edge of a 14MHz clock. The C4 signal (LATCH) on the Amiga 500/2000 is regenerated using C3 delayed by one 14MHz clock. This is one reason for using 14MHz clock internally.

The two LS373's are the read latches, they are transparent when OEL (aka CDR) is high. When CDR is asserted, they attach to the data bus with either the current chip bus data (LATCH is high) or prior chip bus data (LATCH is low). Since LATCH is just C4, it's impossible to read from chip RAM faster than 1/2 the bus speed.

[nonarkitten]

Originally Posted by Mathesar

The implementation in Minimig might be wrong

Yeah... no dissing the amount of work that's been put into MiniMig, but having worked with it, it would be a very poor reference model for how an Amiga actually works.

[nonarkitten]

Side note: the timing diagrams in Gayle (https://github.com/nonarkitten/amiga...ifications.pdf) are MUCH more useful than any other document on there.

[Niklas]

Originally Posted by Mathesar

So that leaves the function of BLISS a little unsure although I think it is to indicate to Agnus the CPU will be using the cycle because, as you also noticed, AS/RAMEN/REGEN are not really suitable for that as these might be asserted to early or to late regarding the cycle of relevance. I will do some more measurements when I have time...

Here's an experiment you can try. Put a piece of tape on the BLISS pin on Agnus so that the pin becomes disconnected. Then try running the Amiga. According to your reasoning, as I understand it, the Amiga shouldn't work now.

Then try doing the same thing but with the AS pin disconnected instead.

I tried this, and with the BLISS pin disconnected everything works as before. This is consistent with the behavior implemented by Minimig, i.e. that BLISS is only used by Agnus to count how many slots the CPU was blocked, and then prohibit the blitter from using a slot that it would otherwise use. Disconnecting the AS pin makes the Amiga stop working.

[Mathesar]

Originally Posted by Niklas

Here's an experiment you can try. Put a piece of tape on the BLISS pin on Agnus so that the pin becomes disconnected. Then try running the Amiga. According to your reasoning, as I understand it, the Amiga shouldn't work now.

Then try doing the same thing but with the AS pin disconnected instead.

I tried this, and with the BLISS pin disconnected everything works as before. This is consistent with the behavior implemented by Minimig, i.e. that BLISS is only used by Agnus to count how many slots the CPU was blocked, and then prohibit the blitter from using a slot that it would otherwise use. Disconnecting the AS pin makes the Amiga stop working.

Just tried disconnecting BLISS and pulling it up. Amiga still worked so you are absolutely right! Well, there goes my hope of doing back to back accesses.....

I do think that the design is a bit ugly as functions seem to be split between devices. Agnus handles the bus and Gary just handles DTACK. And Agnus should be able to know without BLISS whether it is blocking the CPU right? It almost seems like BLISS is a hack, an afterthought.

The whole reason for doing all this probing was that I wanted to have a deeper understanding of why my 14MHz accelerator fails to work with certain E clock phasings. I currently fixed it by latching AS to the 7Mhz clock but I was looking for a cleaner way. I learned a lot

[nonarkitten]

Originally Posted by Niklas

Here's an experiment you can try. Put a piece of tape on the BLISS pin on Agnus so that the pin becomes disconnected. Then try running the Amiga. According to your reasoning, as I understand it, the Amiga shouldn't work now.

Then try doing the same thing but with the AS pin disconnected instead.

I tried this, and with the BLISS pin disconnected everything works as before. This is consistent with the behavior implemented by Minimig, i.e. that BLISS is only used by Agnus to count how many slots the CPU was blocked, and then prohibit the blitter from using a slot that it would otherwise use. Disconnecting the AS pin makes the Amiga stop working.

Without BLISS, access to chip RAM and registers, as well as ranger RAM, may be slower under heavy use of the blitter. It's only intended to give SOME time back to the CPU. But correct, it should work fine.

[nonarkitten]

Originally Posted by Mathesar

Just tried disconnecting BLISS and pulling it up. Amiga still worked so you are absolutely right! Well, there goes my hope of doing back to back accesses.....

I do think that the design is a bit ugly as functions seem to be split between devices. Agnus handles the bus and Gary just handles DTACK. And Agnus should be able to know without BLISS whether it is blocking the CPU right? It almost seems like BLISS is a hack, an afterthought.

The whole reason for doing all this probing was that I wanted to have a deeper understanding of why my 14MHz accelerator fails to work with certain E clock phasings. I currently fixed it by latching AS to the 7Mhz clock but I was looking for a cleaner way. I learned a lot

Gary does a bit more than generate DTACK.

BLISS isn't a "hack" it's a feature. Though a clumsy one. Honestly, I always found the whole arbitration to be so over-baked. I think it comes from when the Amiga was still a games console and would never have had "fast RAM" -- BLISS was meant to ensure the CPU always has SOME time, unless you set the nasty bit, which not only locks out the CPU entirely, but was useful for timing (and something WHDload exploits for a lot of game compatibility).

Adding Gary's functionality to Agnus would have required a larger package and at 84 PLCC, that was already HUGE for its time.

I'm still not sure what this whole obsession with "back to back" means. The latches are controlled by C4, a clock. Not BLIT. Not BLISS. Not the phase of the moon, a clock. It is a perfect 50% split. So if you mean writing in an even then odd cycle from the CPU, then no, that's impossible without a custom Agnus and Gary. Period.

Unless you pull the four latches and pop in some 33-ohm series resistors. Have fun with that one.

If you mean performing more than one operation within a single cycle, then that's possible as the 68000 is asynchronous. But you'll need a fast CPU, smart controller that uses the OVR signal to control DTACK itself as well as fast-enough chip RAM. By fast enough, I mean 70ns FPM or better.

[Niklas]

Originally Posted by Mathesar

And Agnus should be able to know without BLISS whether it is blocking the CPU right? It almost seems like BLISS is a hack, an afterthought.

Yeah I agree that the arrangement seems a bit redundant/superfluous. Instead of the input pins AS, REGEN, RAMEN, BLISS on Agnus I feel it should be enough to have two pins going from Gary to Agnus to signal that the CPU wishes to do an access to either a chip register or to chip memory. In any case, the design is what it is, for whatever reasons it ended up that way, but at least we can understand how it works.

Originally Posted by Mathesar

The whole reason for doing all this probing was that I wanted to have a deeper understanding of why my 14MHz accelerator fails to work with certain E clock phasings. I currently fixed it by latching AS to the 7Mhz clock but I was looking for a cleaner way. I learned a lot

It's always satisfying to experiment and get a deeper understanding.

Happy new year btw!

[QuikSanz]

Hi' how are things going on this project? any clue when some kits will be ready?


Chris

[utri007]

Originally Posted by QuikSanz

Hi' how are things going on this project? any clue when some kits will be ready?


Chris

Git has no updates for a several months. I doubt if these ever actually materialize actual product.

[nonarkitten]

Originally Posted by utri007

Git has no updates for a several months. I doubt if these ever actually materialize actual product.

So I need to make pushes to git more often to keep people like you happy?

Not living in a socialist country means I have to work for a living. That means 40+ hours of my week, every week of the year is spent doing my "job" first. Outside of that, I have family to take care of, and sleep to catch up on. Pile on struggling with depression and yes, it's been a slow go.

And the last thing I look forward to is an email drop that someone wants to play backseat driver and dump on the project.

There's been a lot of work getting the HARDWARE right before the SOFTWARE and since the HARDWARE isn't on the git, you wouldn't be privy to that work and the fact that we're four respins into the latest boards. For the most part, the software is and has been done. Not being an FPGA guru, I've asked for some help and have been stonewalled so far. So be-it, I'll do my best on my own.

As I have done for everything else so far.

So seriously, go lick an outlet.

-----------------------------------------------------------------------------------------------------------

Also, I've been busy trying to wrap up Buffee first and have been plugging away at a lot of updates and an almost complete rewrite of the generator code.

[QuikSanz]

@utri007,

When making an inquiry best to be nice rather than expressing dissatisfaction with the time it takes.

[Promilus]

Ppl tend to forget it's not Phase 5 or Vortex or GVP. Nobody pays kipper or nonarkitten for the work done so far. And it's massive. I have no doubts they'd make more money (than selling buffee etc) going overtime in their regular work instead of the time spent on this project for hobbyist like me and you. So I would appreciate to stop being jacka$$ to the few ppl still doing stuff on Amiga. It won't be any better if we drove them off.

[utri007]

Originally Posted by nonarkitten

So I need to make pushes to git more often to keep people like you happy?

Not living in a socialist country means I have to work for a living. That means 40+ hours of my week, every week of the year is spent doing my "job" first. Outside of that, I have family to take care of, and sleep to catch up on. Pile on struggling with depression and yes, it's been a slow go.

And the last thing I look forward to is an email drop that someone wants to play backseat driver and dump on the project.

There's been a lot of work getting the HARDWARE right before the SOFTWARE and since the HARDWARE isn't on the git, you wouldn't be privy to that work and the fact that we're four respins into the latest boards. For the most part, the software is and has been done. Not being an FPGA guru, I've asked for some help and have been stonewalled so far. So be-it, I'll do my best on my own.

As I have done for everything else so far.

So seriously, go lick an outlet.

-----------------------------------------------------------------------------------------------------------

Also, I've been busy trying to wrap up Buffee first and have been plugging away at a lot of updates and an almost complete rewrite of the generator code.

Hope you get it ready, I wish you best. For me this is most important part. Buffee would be nice, but not that important. But that is just me.

[big F]

An “open source” style Agnus has been on my wish list for years.
Anything that removes the need for me to pay £100+ for a used Agnus for my Amigas.

I wish I had the knowledge to do this or participate in its build but sadly for me I didn't stay in the electronics business after I was made redundant during my apprenticeship so didnt learn enough. Just doing it for a hobby is only so good. Lucky for me being an engineer instead has given me other choices.

[salteadorneo]

This project is one of the best currently on the Amiga. I wish you the best.

[alexh]

Originally Posted by big F

Anything that removes the need for me to pay £100+ for a used Agnus for my Amigas.

https://www.ebay.co.uk/itm/225451090024

[kipper2k]

Originally Posted by alexh

https://www.ebay.co.uk/itm/225451090024

this = $132 CAD to my front door, ouch!