FPGA based A500 accelerator

[Lemaru]

Whilst it is looking good, the concern here is by locating the dip socket in that position you are limiting what can be connected by the distance to the rear of the case. For example the TerribleFire TF536 will not fit. If you rotate the dip 90degrees (although it will cover sit above the IDE) you will have much more room.

You should still be able to use the IDE if there's enough clearance for for a cable to connect underneath. Or make a passthrough like you have for the KS ROM as you can then move the IDE connector to a more convenient location.

[kipper2k]

Originally Posted by Lemaru

Whilst it is looking good, the concern here is by locating the dip socket in that position you are limiting what can be connected by the distance to the rear of the case. For example the TerribleFire TF536 will not fit. If you rotate the dip 90degrees (although it will cover sit above the IDE) you will have much more room.

You should still be able to use the IDE if there's enough clearance for for a cable to connect underneath. Or make a passthrough like you have for the KS ROM as you can then move the IDE connector to a more convenient location.

Rotating the DIP 90 degrees will make the routing harder and the TF series of boards will probably interfere with the odd cia, MPU and the keyboard header. People are using either the mpu/odd CIA for their addons. I do not have a TF i can use to test, from what i see the physical dimensions and height of components will cause a problem with the underside of the keyboard. The A600 is very limited in height.Once the project is done i will release the brd files so people could alter the design.


hmmm, just thinking, maybe i will add a plcc socket so that the MPU is included in the board then that would help those with addons and also the fit

[Lemaru]

I'm just throwing a few ideas out there whilst it's a work in progress. Whatever you knock up will be great and like you say, others can always adapt for their needs.

It is about time something like this existed, just hope the compatibility is good.

[scu98rkr]

what is required is a 3D printer "step" and some longer screws.

ie a piece of plastic which would sit in between the bottom of the case and the top of the case and raise the height of the case.

[kipper2k]

Originally Posted by scu98rkr

what is required is a 3D printer "step" and some longer screws.

ie a piece of plastic which would sit in between the bottom of the case and the top of the case and raise the height of the case.

i do have thje screws to secure the pcb to the motherboard, they are 1.6mm, you can get the screw and nut on ebay dirt cheap. Raising the back of the case is possible although cant do it too much, and the front i dont think can be touched

[8 Bit Dreams]

Originally Posted by kipper2k

Just playing Thinking ahead a bit

This is great!!! I like this idea!
This means that A1200 and also CD32 can be used with fpga accelerator.. Good days are coming!

[kipper2k]

Originally Posted by 8 Bit Dreams

This is great!!! I like this idea!
This means that A1200 and also CD32 can be used with fpga accelerator.. Good days are coming!

yupper
the adapter is done, just waiting for tests

[mkstr]

On the topic of the actual accelerator, not much done again this week due to day-job work, but through some optimisation of the instruction cache this is where we are now:



I won't shout too loudly about this because it doesn't quite close timing over temperature, but it works fine and the final FPGA will be quite a bit faster so I would expect to be at least at this level of performance and probably higher. No D cache yet either.

Mike

[kipper2k]

amazing, just amazing, awesome speed, low power consumption and i think it is pretty well in a class of its own

[PR77]

Originally Posted by kipper2k

amazing, just amazing, awesome speed, low power consumption and i think it is pretty well in a class of its own

I have to agree. Please consider open sourcing. I know this has been raised many times so I don't want to get into that again. I would donate to some $$$ just to have this open to the masses.



As a kid growing up (12- 13) I never really understood digital electronics. Now as a professional I do so I have to chance to make the stuff for the Amiga I always wanted to do. I've built my own 68SEC000 accelerator, no where near the performance of this and it is open. For me, I want to spread that knowledge to all the others who were (or still are) in the same position as I was.



The decision if finally up you you and Mike, I will never question it. Whatever is decided doesn't change how impressive your work is so far.


Keep up the excellent work! Great work!

[fpgaarcade]

Hey Mike,we chatted a very long time ago!
I open sourced my M68K variant a while back which supports all 020 ops, but now Tobias has woken up again there is focus on backporting to the TG68K on github.

You can use my I/D/prefetch subsystem if you wish. It's all going open source quite soon anyhow, ping me if you are interested.

MikeJ
www.fpgaarcade.com
mikej@fpgaarcade.com

[kipper2k]

i cant speak for Mike as regards what can/can't be open source. My thoughts are that eventually it can be opened up, We intend to port this design to all the 16bit and 32 bit machines. If anyone has a 3k/4k for sale etc let us know as Mike would need for testing later. I know some of you hoarders (including me) have them hidden in the loft

Mine are all 16 bit Amigas so i cant help. I think the RAM cache is the most difficult portion left to do, after that the other features shouldn't be that bad (so i'm told lol). it is just a case of getting the time to get this done. For those who haven't checked Mike's blog it is a good read. Working with FPGAs and other logic devices are his bread and butter as this is his day job. He builds logic/process boards for clients for custom use in many fields, have a read

see correct link below...

[hooverphonique]

Here's the correct link
https://www.mike-stirling.com/2020/0...the-amiga-500/

[kipper2k]

Originally Posted by hooverphonique

Here's the correct link
https://www.mike-stirling.com/2020/0...the-amiga-500/

hehe, oops. i know at least 1 person has checked it out now lol

[mkstr]

Originally Posted by fpgaarcade

Hey Mike,we chatted a very long time ago!
I open sourced my M68K variant a while back which supports all 020 ops, but now Tobias has woken up again there is focus on backporting to the TG68K on github.

You can use my I/D/prefetch subsystem if you wish. It's all going open source quite soon anyhow, ping me if you are interested.

MikeJ
www.fpgaarcade.com
mikej@fpgaarcade.com

Hi Mike. Something I was going to look at with TG68 was widening the bus to 32-bit and splitting the I and D buses so that fetches can be done in the same tick. This would have meant changes to the TG68 itself so would be open source from day one in accordance with LGPL. If this is similar to what you've already done in your fork then it would definitely be worth switching over. I will drop you an email to discuss. The above numbers are still using unmodified TG68 with the 16-bit bus.

Regarding the overall open-source plan, since people are asking: I would like to do so, but at the same time the hardware is going to be quite dense, requiring contract assembly for which there will be significant initial investment. It is likely that a subset of the full functionality will be open sourced once the boards go on sale, with more features being released as the product (and development community) matures. The hardware will not be open source, but it will be reasonably priced and I will make the pin assignments available. I hope that this approach will strike a fair balance between supporting the community and making the investment worthwhile.

[fpgaarcade]

I'll add you to the currently private repos and take a look, use what you fancy.

I've been working on widening the bus, but we are taking a new approach based on a RiscV core at the moment. I may go back to the M68K/TG68K.

I don't open source my boards, they are 6 or more layers and I don't see anybody else making them. I open the schematics and daughter board design and completely agree with your approach.


The M68K code is here, although it's fallen slightly behind the TG68K in bug fixes. I'm working on a regression test. It's my attempt at unwinding the loops and potentially pipe lining the core.

https://github.com/FPGAArcade/replay...r/lib/cpu/m68k


The split I/D and prefetch wrapper is in my Amiga repos which I can give you access to.

[mkstr]

Originally Posted by fpgaarcade

I'll add you to the currently private repos and take a look, use what you fancy.

I've been working on widening the bus, but we are taking a new approach based on a RiscV core at the moment. I may go back to the M68K/TG68K.

I don't open source my boards, they are 6 or more layers and I don't see anybody else making them. I open the schematics and daughter board design and completely agree with your approach.


The M68K code is here, although it's fallen slightly behind the TG68K in bug fixes. I'm working on a regression test. It's my attempt at unwinding the loops and potentially pipe lining the core.

https://github.com/FPGAArcade/replay...r/lib/cpu/m68k


The split I/D and prefetch wrapper is in my Amiga repos which I can give you access to.

Thanks Mike I will take a look. I've started looking at SD card interfacing and other IO first, so I will get in touch about access once I get back to performance improvements. Once there is a plan for IO features I'll be making a start on the design of the production board.

[indigolemon]

Very excited about this whole project. Nice to see good progress here

[kipper2k]

Originally Posted by mkstr

Thanks Mike I will take a look. I've started looking at SD card interfacing and other IO first, so I will get in touch about access once I get back to performance improvements. Once there is a plan for IO features I'll be making a start on the design of the production board.

Looking forward to see what can be done with the SD card features

[Sim085]

First of all big thank you to all those working on this project.

With regards to SD card feature; is there any advantage of having an SD slot instead of an IDE header?
I ask as for the IDE header there are multiple adapters available to many different mediums such as SD, micro-SD, CF, HDD, SSD, etc.

Originally Posted by kipper2k

Looking forward to see what can be done with the SD card features