FPGA based A500 accelerator

[Gorf]

I thought it was specifically the bandwidth of Paula that was the problem and this was why although the AGA machines replaced Gary with Gayle they were still limited for floppy drive access speed as they're still using the old Paula. Hence the half speed HD drives for the A4000.

yes that is the reason. This could have been fixed for AGA if Paula was updated for 32bit access ...
or: decode the mfm stream from/to floppy between Paula and Gary (or in Gary) - the encoding ratio is 2:1

[AJCopland]

Originally Posted by PurpleMelbourne

People in Australia have been working on adding ExtraHD floppy drives (4MB/2.88MB) to Amiga and hit a problem with the low Amiga floppy bandwidth.

Matze has successfully reverse engineered Gary and put onto a Xilinx CPLD.

Got a link to any of that? My Google-fu is weak today it seems

[Gorf]

Originally Posted by AJCopland

Got a link to any of that? My Google-fu is weak today it seems

https://amigalove.com/viewtopic.php?...28c64b6c#p7769

[PurpleMelbourne]

Mike at FPGA Arcade got several of the Custom chips microscope scanned.

Denise : https://siliconpr0n.org/map/csg/8362r8/mz_mit20x/
Paula : https://siliconpr0n.org/map/csg/8364r4/mz_mit20x/
Alice : https://siliconpr0n.org/map/csg/8374r3/mz_mit20x/

We should be able to figure out how to recreate these. I don't know how to do it, but I bet its possible to learn how to map out the chips, and from that perhaps the MiniMig implementation can be improved/streamlined.
Does anyone know where to start with that kind of thing?

[Gorf]

Someone called "igor" did his cycle exact 68k-FPGA-core from a scan like this - he would be the one to ask. (Minimig forum).
But I am not sure if the is the right way to go for the Amiga chipset since this internal design might still be under copyright ....

[NorthWay]

Originally Posted by Gorf

But I am not sure if the is the right way to go for the Amiga chipset since this internal design might still be under copyright ....

What would be under copyright?
The layer images? That would be fine as you don't want to use those, you want to extract the logic inherent and recreate it in VHDL or similar?

IIRC Jens Schönfeld said that his recreations of the chips became more lean when he used the same "unified" or "don't care"(my interpretation) expressions for the chip logic as the originals. I understood him to have de-lided the chips and photoed them.

[kipper2k]

I have finished the layout of the A500 board and it is pretty well all populated. I am doing a final error check this weekend and then will be submitting it for assembly on Monday so should have it in 7 - 10 days. No pictures yet, once i get the assembled boards in my hand i will show some pictures, I am planning on getting 5 boards for assembly and will be willing to allow people who are willing to test etc to have a board at a reasonable cost. This will keep my dev costs down and help with my future projects. Due to the cost of mailing i can only do this for people who are living in Canada/USA.

There is no guarantee that this board will work so anyone interested would have to accept the risk that there would be some work to figure out errors etc, and still not be able to get it to boot. The board should take no more than 2 hours to build to get to the splash screen as most of the work is done.

The cost of decapping chips is not cheap as far as i can tell, to go to the hassle of decapping, extracting and recreating them without selling clones seems like a wasted expenditure. Copyright for such old chips is a grey area (look at the amount of arcade machine chips used in Mame), i am thinking that if you produce code to copy a hardwired chip then i dont think the copyright is infringed... just my pennies worth

[PurpleMelbourne]

From what I understand, the rule in engineering is that a 15% change makes for a legally "new" design.

Looking at the real chips to improve the FPGA simulation would be more like a 1% replication.
Glad to hear that it can be done. It'd be great if there is some software to do it.

And on a more relevant to the thread note... how about doing the same with 060?
I've got a friend who has the gear to burn off the chip and scan it. I've been TRYING to persuade him it'd be a worthy effort... Not persuaded yet.
But there must be some other friendly fanatics out there with this kind of equipment also.

I'm betting that TG68 would start to catch up to 68080 with a peek inside the real 68060.

[robinsonb5]

Originally Posted by NorthWay

IIRC Jens Schönfeld said that his recreations of the chips became more lean when he used the same "unified" or "don't care"(my interpretation) expressions for the chip logic as the originals. I understood him to have de-lided the chips and photoed them.

There was an interesting interview about the Clone-A project where he said that "everytime we’re fixing a bug, we discover that the fix actually produces a smaller design. It’s really amazing what Jay Miner and his colleagues crammed into about 20.000 transistors per chip!"


However, the article makes no mention of de-lidding and talks instead about analyzing the chips on a cycle-by-cycle basis with a logic analyzer, and fuzzing the chips with unexpected inputs.
https://www.totalamiga.org/files/TA2...iewExtract.pdf

Originally Posted by PurplePelbourne

From what I understand, the rule in engineering is that a 15% change makes for a legally "new" design.

That seems like a very low bar to me - especially compared with how copyright works in other fields. But software expressions of hardware are a new enough concept that I don't think the law has fully caught up yet with regards to what might or might not count as a derivative work.

I'm betting that TG68 would start to catch up to 68080 with a peek inside the real 68060.

Given that the '060 is around 2,500,000 transistors, I'm not sure what insights could be gained from seeing inside it? Perhaps some kind of automated tool could be written to do some kind of "OCR" process and turn the image back into some kind of netlist - but even then how useful would it be? I wouldn't have thought a human could extract much meaningful information from eyeballing such a huge amount of information - I'd love to be proved wrong though!

However, I think the things that were state of the art when the '060 and Pentium came out (longer pipelines, result forwarding, superscalar execution units, branch prediction) are well enough understood now that the only thing stopping someone creating a new core with '060 performance levels is the man-year or two required to do it. Those things are not features that can be easily retrofitted to an existing core, however - the core kind of has to be designed around them.
(For comparison, the MIPS-compatible core at https://github.com/f32c/f32c has a 5-stage pipeline, forwarding and branch prediction - isn't even superscalar - but has integer performance comparable to an '060 while being only a third of the size of TG68.)


(Please don't think I'm in any way knocking TG68 - I'm a big fan - I just think it's best appreciated for what it is.)

[NorthWay]

I'm not sure I see much value in looking at the masks of a 68060. Recreating the behaviour in a descriptive language sounds like a much better idea, and something like the work done for UAE that shows the actual operations is more valuable as you can recreate that easily.

Mike(?) of FPGAArcade has AFAIK actually recreated the 680_0_0 with its firmware rom, but that is for extreme compatibility and not speed. It is not an approach that favours speed.

[Gorf]

Originally Posted by NorthWay

What would be under copyright?
The layer images? That would be fine as you don't want to use those, you want to extract the logic inherent and recreate it in VHDL or similar?

IIRC Jens Schönfeld said that his recreations of the chips became more lean when he used the same "unified" or "don't care"(my interpretation) expressions for the chip logic as the originals. I understood him to have de-lided the chips and photoed them.

I was not sure ... Igors 68k-core is exact down to the microcode of the original ... so at least there might be some issues. I doubt Motorola/Freescale cares.

I have no clue if a certain arrangement of gates could be copyrighted - probably not (except for patents that are now gone).

I should probably not worry

Wow - it has been now 14 years since the Clone-A interview with Jens ... this shows how imported it is to do things like this as an open source project ....

[Fastdruid]

I'm not sure exactly where I saw it (might have been on the Atari forum where the MiSTer developers sit) but there was a suggestion of instead of creating a faster soft core '030,'040 or '060 to instead to use the ARM processor (Dual core ARM Cortex-A9 @800MHz) on the DE10-nano to create a (software) emulated processor.

Ignoring any considerations over if this would be viable and looking at is purely from a connectivity perspective the DE10-Nano has 80 GPIO pins (3.3V of course) on the FPGA side which are nicely brought out to two 2x20 connectors.

The 68k (in the A500) is a DIP-64 package with 2 GND and 2 VCC leaving 60 data pins which leaves 20 GPIO pins "free" for various uses. Equally if you would rather use it instead the expansion slot is 86 pins, 12 are GND, 2 VCC, 1 12V, 1 -12V and 3 are NC, leaving 67 in actual use.

So on the face of it from an utter amateur perspective this appears doable on the actual A500 as well by using those GPIO pins to connect either in place of the 68k or on the expansion bus and still leaving a number of GPIO pins "free". Obviously there would need to be 3.3v to 5v buffering and a bunch of clever coding.

I wonder if someone was really clever if you could maybe even do something akin to what Taos/planned did and translate opcodes on the fly (except using the FPGA).

Ignoring what a massive piece of work this would be, feel free to tell me why I'm an idiot and this wouldn't work and/or it's pointless because you could do xyz much quicker and easier for better performance.

[meynaf]

Originally Posted by Fastdruid

Ignoring what a massive piece of work this would be, feel free to tell me why I'm an idiot and this wouldn't work and/or it's pointless because you could do xyz much quicker and easier for better performance.

Software emulation can be done in two ways, and both have problems.
Either a JIT is made, and in that case there are compatibility issues (f.e. a lot of software doesn't work properly under UAE with JIT active).
Or it is simple interpretation, which means you need multi-Ghz cpu to barely reach the 060 range of performance (800Mhz ARM is perhaps in 030 range here).
Depending on the target, these may be acceptable -- or not.

[Toni Wilen]

JIT in software emulator vs in hardware as a separate CPU module is in my opinion totally different thing with different good and bad side-effects.

When software emulator JIT runs, hardware emulator is basically stopped which makes timing wonky. JIT batch runs (can be hundreds of instructions "instantly"), then some amount of hardware cycles, then JIT again and so on.

This is not a problem with "hardware JIT" because chipset stuff is completely separate and runs simultaneously and all CPU chipset IO accesses will (have to) keep original timing.

"Hardware JIT" simply becomes fast CPU that has a big instruction cache. It also needs internal fast RAM or it would become really slow or need a data cache but I think data cache would make internal logic far too complex and lose lots of speed. Also you would need Amiga software side support to handle cache properly. No one wants to code that..

JIT<>outside IO handling most likely is the tricky stuff..

[Gorf]

I think the FPGA and hard-core RISC combination would a allow for a very fast interpretive mode:

what if we implement the decoding of the 68k-CISC instructions to the FPGA part - but instead of implementing the ALU also in FPGA, we decode into RISC instructions and send them the the ARM or RISC-V core.

That is not so different from how pipelined CPUs are generally designed, except we would have an "external" instruction decoder.
(68k-instruction fetching and caching would also be external - while there would be still a second i-cache within the ARM/RISC-V for already translated instructions ...)

This way we could take advantage of fast superscalar out-of-order CPUs.
Michal Schulz said about Emu68 for ARM it takes about two ARM instructions per 68K instruction - since the ARM hard-core would run at hundreds of MHz the speed limit would only be the decoder unit in FPGA.
So how fast we could decode the instruction stream in the FPGA part, would determine the overall execution speed.

There we could also try to do as many things in parallel as possible and could also resort to "speculative decoding" after conditional jumps.

[PurpleMelbourne]

Originally Posted by Gorf

This way we could take advantage of fast superscalar out-of-order CPUs.
Michal Schulz said about Emu68 for ARM it takes about two ARM instructions per 68K instruction - since the ARM hard-core would run at hundreds of MHz the speed limit would only be the decoder unit in FPGA.

Another coder told me that its about four RISC instructions per 68K CISC.
Either way, that sounds fast if you have a fast enough RISC chip, which are plentiful for small money.

Putting a 68K decoder in FPGA and then feed to the RISC is an interesting idea!
Someone developed some new technology, who's name I forgot, which "splits" instructions so that they may be spread across many cores. With that Intel will be soon going the other direction of SMP with many cores pretending to be only one core.

I also saw a demo of that being done on an eight core Android phone showing more smoothness. So it can certainly be done with ARM.

If that tech were applied to 68K and then us something like a Rockchip RK3399 @ 2GHz, then we'd be looking at a 1GHz 68060 on a $100 board.

[meynaf]

Originally Posted by PurpleMelbourne

Someone developed some new technology, who's name I forgot, which "splits" instructions so that they may be spread across many cores. With that Intel will be soon going the other direction of SMP with many cores pretending to be only one core.

This sounds interesting ! I can't the heck imagine how this could possibly work. Do you have links on the subject ?

[Samurai_Crow]

Originally Posted by meynaf

This sounds interesting ! I can't the heck imagine how this could possibly work. Do you have links on the subject ?

[ Show youtube player ]

[meynaf]

That's just an analyst speaking. Anything official from Intel or others ?

[Fastdruid]

Originally Posted by meynaf

That's just an analyst speaking. Anything official from Intel or others ?

Soft Machines is mentioned in that talk and Intel acquired them a few years ago.

https://www.theregister.co.uk/2016/0...soft_machines/