Open source 14MHz 68000 accelerator

[Mathesar]

Originally Posted by GadgetUK

Yes - built all OK =D sparxUK built a few and sent me parts to build one, which was very kind of him =D


All works OK - was just trying to use the A590 to add SCSI and a bit of RAM.
I tried disabling the fast RAM on the A590 and it fails to boot at all. So I suspect the issue there is an incompatibility with the A590 - since it should fall back to PIO mode.

Cool Glad that it works. It's a pity though that it doesn't play nice with the A590. One thing to remember is that the fast ram on the accelerator is not DMA capable. that might be a reason for crashing and could be solved by setting the correct masks if the fallback to PIO mode doesn't happen automatically. Did you also try disabling the fast ram on the accelerator by holding ctrl-a-a down? Does it work then with the fast ram on the A590 enabled?

[Mathesar]

Also, the accelerar always runs @14Mhz. However, when it accesses the Amiga bus the cpu is slowed down so much tools that like Sysinfo will report a slower clock speed.

[GadgetUK]

If you disable fast RAM it doesnt boot at all - the A590 fails to work in PIO mode with your board. LIV2 took a look an thinks its related to the AS7 and AS. I will take a look later, he suggested adding an AND or NAND there to solve that problem, but I've not had time to look in detail.

[Mathesar]

Originally Posted by GadgetUK

If you disable fast RAM it doesnt boot at all - the A590 fails to work in PIO mode with your board. LIV2 took a look an thinks its related to the AS7 and AS. I will take a look later, he suggested adding an AND or NAND there to solve that problem, but I've not had time to look in detail.

Just so I understand correctly, with the fast ram on the accelerator disabled ($C00000 ram), the system does not boot?

[GadgetUK]

Originally Posted by Mathesar

Just so I understand correctly, with the fast ram on the accelerator disabled ($C00000 ram), the system does not boot?

No, it seems the video goes just as the LED flickers on the A590, when RAM is disabled on the A590. Maybe I need to "tune" that resistor you mention in the design.

[patrik]

Originally Posted by Mathesar

Cool Glad that it works. It's a pity though that it doesn't play nice with the A590. One thing to remember is that the fast ram on the accelerator is not DMA capable. that might be a reason for crashing and could be solved by setting the correct masks if the fallback to PIO mode doesn't happen automatically. Did you also try disabling the fast ram on the accelerator by holding ctrl-a-a down? Does it work then with the fast ram on the A590 enabled?

How hard would it be to make the accelerator memory DMA'able?

I don't know of any DMA peripherals/drivers that detects un-DMA:able memory, but please correct me if I am mistaken.

It could of course be fixed by setting the mask to only allow transfers to/from chipmem for all partitions (0x1FFFFE). However, it is rather user-unfriendly and it will be extremely slow as buffers allocated by software will always be in highest priority ram - fastram, so the filesystem fixes the transfer by showing them via chipmem in very small blocks. Some drivers will also do pio on such small blocks to make it even worse speed wise then .

[hooverphonique]

Well, C00000 ram is normally not dma-able, and since this accelerator relies on the OS adding it (thinking it is regular slowram), it will get marked non-dma. Also, an A500 doesn't have anything on the mobo supporting dma, it all happens inside the A590.

[Mathesar]

Originally Posted by GadgetUK

No, it seems the video goes just as the LED flickers on the A590, when RAM is disabled on the A590. Maybe I need to "tune" that resistor you mention in the design.

Could you do a test and see if the system boots with just the $C00000 ram on the accelerator disabled? The A590 should be fully enabled with ram. This way we can check whether the problem lies with the A590 trying to DMA into the $C00000 ram or whether the problem lies with any AS/DTACK timing of the bus interface.

Well, C00000 ram is normally not dma-able, and since this accelerator relies on the OS adding it (thinking it is regular slowram), it will get marked non-dma. Also, an A500 doesn't have anything on the mobo supporting dma, it all happens inside the A590

Doesn't that apply to the chipset only? I assume the A590 DMA chip (dmac?) does bus cycles similar to the 68000 so that doesn't rule out chip ram nor slow ram I think.

How hard would it be to make the accelerator memory DMA'able?

Maybe not that hard. The problem is that the accelerators "fast" ram address decoding overlaps with Gary decoding of slow ram. Normally that is not a problem as AS is hidden from gary but when a DMA master takes over the bus it will be a problem. The easiest solution is to move the ram to some other address and manually add it to the system via addmem. Edit: and we need an extra gate to allow external AS into the ram controller.

[hooverphonique]

Originally Posted by Mathesar

Doesn't that apply to the chipset only? I assume the A590 DMA chip (dmac?) does bus cycles similar to the 68000 so that doesn't rule out chip ram nor slow ram I think.

Hmm, maybe you're right - the comments about PIO made me think the A590 can only DMA to its internal memory, but maybe that's not true.

The chipset is actually able to "dma" to trapdoor C00000 ram, it just appears to it as chipram (if you have a 1MB+ agnus).

[Mathesar]

I have raised an issue on GitHub. One thing I just now realize is that this design does not tristate the AS signal when the 68000 grants bus access. This inhibits any DMA transactions on the 68000 bus. So, even DMA transactions between the A590 ram and the SCSI chip will fail. Basically this accelerator does not support DMA controllers.

Could you do another test? Try setting the mask to 0x000000 for all partitions. This will hopefully prevent the driver from doing any DMA at all. It will be slow but if it works it can help us pinpoint the exact problem.

[Yulquen74]

The A590 works with the entire 24 bit memory range, if the logic in the accelerator is wired correctly. With my CPLD based 68000 accelerator, I can use every bit of memory range not used by the mainboard, together with the A590. Regarding the local C0 memory access, it is important that Gary is not aware of it while accessed by the A590, as you said; you need to pull down the OVR then, but it will require a wire out of the board. And
you also need to supply a 7MHz synced DTACK as well to the A590 for C0 accesses, since Gary is not providing it in this scenario. If you move the fast-ram over to the Z2 area, it will have to be added during boot, but then some stuff will go into chip-ram before you are able to do so, both slowing down the system and eating precious chip-ram.

[patrik]

Originally Posted by Mathesar

Doesn't that apply to the chipset only? I assume the A590 DMA chip (dmac?) does bus cycles similar to the 68000 so that doesn't rule out chip ram nor slow ram I think.

Correct, the A590 (or other peripherals for the 68000 bus) should be able to access everything the 68000 CPU can, when they are mastering the bus.

[Mathesar]

Let me think aloud here. First thing to change is to make AS7 a tristate signal when another busmaster is active. Easy in a CPLD but on this design it would mean an extra (tristate) buffer gate. Or make it an open collector output, that would require just a schottky diode... (bat54?). What do you think of that? In the spirit of keeping things simple...
Second thing to fix is to feed AS7 (when driven by an external bus master) into the ram controller. That one could be easy I think. We can just feed AS7 into pin 10 of gate U8C. Done!
Third thing to fix is to prevent Gary from interfering.... Without any additional logic the ram could be moved to $300000, $500000, $600000 or $900000.

So, with a bit of luck it could be fixed with just some rewiring and the addition of a diode and a pullup. Any things I'm overlooking?

See here for the current schematic: https://github.com/Mathesar/14mhz-ac...schematics.pdf

[Mathesar]

Originally Posted by Yulquen74

The A590 works with the entire 24 bit memory range, if the logic in the accelerator is wired correctly. With my CPLD based 68000 accelerator, I can use every bit of memory range not used by the mainboard, together with the A590. Regarding the local C0 memory access, it is important that Gary is not aware of it while accessed by the A590, as you said; you need to pull down the OVR then, but it will require a wire out of the board. And
you also need to supply a 7MHz synced DTACK as well to the A590 for C0 accesses, since Gary is not providing it in this scenario. If you move the fast-ram over to the Z2 area, it will have to be added during boot, but then some stuff will go into chip-ram before you are able to do so, both slowing down the system and eating precious chip-ram.

My accelerator does not tristate AS7 currently. As for DTACK, you are right! Perhaps the easiest way to make this work is to just move the ram to zorro space and accept the speed penalty.
Doing everything with discrete logic has it's price.

[patrik]

Originally Posted by Mathesar

My accelerator does not tristate AS7 currently. As for DTACK, you are right! Perhaps the easiest way to make this work is to just move the ram to zorro space and accept the speed penalty.
Doing everything with discrete logic has it's price.

If you would make it autoconfig the memory though, there would be no speed penalty.

[LIV2]

Originally Posted by Mathesar

Or make it an open collector output, that would require just a schottky diode... (bat54?). What do you think of that? In the spirit of keeping things simple...

One potential concern here is rise time. I see the A500 schematics show a 470 ohm pull-up for AS and 2.7K on the A2000. Might be worth trying & watching with the oscilloscope I guess.

[GadgetUK]

Originally Posted by Mathesar

Let me think aloud here. First thing to change is to make AS7 a tristate signal when another busmaster is active. Easy in a CPLD but on this design it would mean an extra (tristate) buffer gate. Or make it an open collector output, that would require just a schottky diode... (bat54?). What do you think of that? In the spirit of keeping things simple...
Second thing to fix is to feed AS7 (when driven by an external bus master) into the ram controller. That one could be easy I think. We can just feed AS7 into pin 10 of gate U8C. Done!
Third thing to fix is to prevent Gary from interfering.... Without any additional logic the ram could be moved to $300000, $500000, $600000 or $900000.

So, with a bit of luck it could be fixed with just some rewiring and the addition of a diode and a pullup. Any things I'm overlooking?

See here for the current schematic: https://github.com/Mathesar/14mhz-ac...schematics.pdf

That might work! LIV2 suggested feeding AS7 into pin 10 of U8C, which I did this morning - didn't work on its own, but I wasnt aware of that tristate issue and the need for a schottky. I left it with pin 10 lifted so I could revisit later (as I assumed this would be required from LIV2s comments). I will try with a diode shortly!

EDIT: Catching up with comments about DTACK though, I see there's that to deal with too. For the moment I will leave it as is. Works fine as a standalone update though - nice boost in performance, lovely neat board!

[keithamiga1200]

@Mathesar


I noticed IC U5 has a solder bridge? Is the bridge pins 8,9 and 10? Or Pins 8 and 10? It looks like the latter, but could you confirm? (Accelerator part only)


Thanks

[Mathesar]

Originally Posted by keithamiga1200

@Mathesar


I noticed IC U5 has a solder bridge? Is the bridge pins 8,9 and 10? Or Pins 8 and 10? It looks like the latter, but could you confirm? (Accelerator part only)


Thanks

The picture is from an older revision. The revision on GitHub doesn't need a solder patch!

[keithamiga1200]

Originally Posted by Mathesar

The picture is from an older revision. The revision on GitHub doesn't need a solder patch!

No lifted pins? Brilliant. Thanks