English Amiga Board


Go Back   English Amiga Board > Support > support.Hardware > Hardware mods

 
 
Thread Tools
Old 06 May 2020, 18:40   #281
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 1,144
Quote:
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

Last edited by Gorf; 09 May 2020 at 21:38.
Gorf is offline  
Old 07 May 2020, 13:35   #282
AJCopland
Registered User

 
Join Date: Sep 2013
Location: Beeston, Nottinghamshire, UK
Posts: 179
Quote:
Originally Posted by PurpleMelbourne View Post
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
AJCopland is offline  
Old 07 May 2020, 16:08   #283
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 1,144
Quote:
Originally Posted by AJCopland View Post
Got a link to any of that? My Google-fu is weak today it seems
https://amigalove.com/viewtopic.php?...28c64b6c#p7769
Gorf is offline  
Old 08 May 2020, 03:53   #284
PurpleMelbourne
Registered User

 
Join Date: Dec 2018
Location: Melbourne / Australia
Posts: 71
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?
PurpleMelbourne is offline  
Old 08 May 2020, 12:35   #285
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 1,144
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 ....
Gorf is offline  
Old 09 May 2020, 01:56   #286
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 660
Quote:
Originally Posted by Gorf View Post
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.
NorthWay is offline  
Old 09 May 2020, 02:17   #287
kipper2k
Registered User

 
Join Date: Sep 2006
Location: Thunder Bay, Canada
Posts: 4,006
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

Last edited by kipper2k; 09 May 2020 at 02:32.
kipper2k is offline  
Old 09 May 2020, 06:51   #288
PurpleMelbourne
Registered User

 
Join Date: Dec 2018
Location: Melbourne / Australia
Posts: 71
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.
PurpleMelbourne is offline  
Old 09 May 2020, 14:52   #289
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 804
Quote:
Originally Posted by NorthWay View Post
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


Quote:
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.


Quote:
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.)
robinsonb5 is offline  
Old 09 May 2020, 19:26   #290
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 660
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.
NorthWay is offline  
Old 09 May 2020, 21:44   #291
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 1,144
Quote:
Originally Posted by NorthWay View Post
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 ....

Last edited by Gorf; 10 May 2020 at 18:20.
Gorf is offline  
Old 10 May 2020, 02:09   #292
Fastdruid
Registered User
 
Join Date: Apr 2020
Location: UK
Posts: 144
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.
Fastdruid is offline  
Old 10 May 2020, 07:52   #293
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,878
Quote:
Originally Posted by Fastdruid View Post
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.
meynaf is offline  
Old 10 May 2020, 09:15   #294
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 23,954
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..
Toni Wilen is online now  
Old 10 May 2020, 18:04   #295
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 1,144
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.
Gorf is offline  
Old 11 May 2020, 05:53   #296
PurpleMelbourne
Registered User

 
Join Date: Dec 2018
Location: Melbourne / Australia
Posts: 71
Quote:
Originally Posted by Gorf View Post
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.
PurpleMelbourne is offline  
Old 11 May 2020, 08:14   #297
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,878
Quote:
Originally Posted by PurpleMelbourne View Post
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 ?
meynaf is offline  
Old 11 May 2020, 12:48   #298
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 45
Posts: 1,485
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by meynaf View Post
This sounds interesting ! I can't the heck imagine how this could possibly work. Do you have links on the subject ?
[ Show youtube player ]
Samurai_Crow is offline  
Old 11 May 2020, 13:13   #299
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,878
That's just an analyst speaking. Anything official from Intel or others ?
meynaf is offline  
Old 11 May 2020, 13:57   #300
Fastdruid
Registered User
 
Join Date: Apr 2020
Location: UK
Posts: 144
Quote:
Originally Posted by meynaf View Post
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/
Fastdruid is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Emulators List for Amiga 68000 -based (A500/600) superturrican2 request.Apps 6 11 April 2020 16:42
Amiga FPGA and video signal, is there any good FPGA? balrogsoft support.Hardware 8 15 June 2019 17:55
First Amiga 600 FPGA Accelerator - Vampire 600 majsta Hardware mods 736 18 July 2016 18:31
Which A500 SCSI interfaces are DMA-based? Photon support.Hardware 21 19 September 2009 19:32
A500 disk based games to cd rom backtoskooldaze Retrogaming General Discussion 7 23 October 2003 04:01

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 21:50.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.10589 seconds with 16 queries