@Signal

If you can't explain it, why would anyone buy it?

And of course I don't mean a cheaper Win/Mac machine. I meant a cheaper MorphOS/AROS machine. What advantage does a machine like his have over cheaper existing Amiga-like solutions?

@Nameless

I'm pretty sure that the Pi idea would work (using FPGA
board for Pi to emulate chipset) and booting some light
invisible Linux to run modified UAE.

Problem is that nobody wants to write that modified UAE
and FPGA code and that's the only problem I see because
you would need really small FPGA.

If we went ASIC route I noticed some nice Chinese game
consoles that have Amiga compatible joyports (physicly
not pin-to-pin) that get sold for about 20 Eur to end user
with keyboard (motherboard is in keyboard) and light gun
+ 2 joypads and judging by the games that come with them
are on par with PS1.

Problem is that they tend to break apart very fast (I mean
really fast and not just joypads and keyboard).

@Nameless

Quote:

Nameless wrote: @Signal If you can't explain it, why would anyone buy it? And of course I don't mean a cheaper Win/Mac machine. I meant a cheaper MorphOS/AROS machine. What advantage does a machine like his have over cheaper existing Amiga-like solutions?

Oh, Good Lord.

IT is not about cheaper. IT has naught to do about hardware, software, and CHEAPER.
IT, is the curse of a busy mind looking for a place to settle for awhile.
You can not buy IT. And nobody can explain IT to you, as evidenced by your reply.

You just don't get IT, and never will.

Bye now.

_________________
Tinkering with computers.

@Signal

Thanks for your informative post there. Not sure why I bothered to ask... it's been a while since I've been active on this board and forgot how some people can be here.

I think that some things should be fixed before continuing with the discussion.

What do you want to get? An Amiga clone "with steroids" (computing power; a lot of memory; RTG has a basis)?

If this is the goal, then you have to fix the target price.

After that you can evaluate the possible solutions, and what kind of performance, memory, and RTG video card is it possible to get.

Then you can chose one.

@cdimauro

Defining goals is what the Amiga community is worst at

(on a COMPLETELY different note, I wonder if a small FPGA + 53C80 could be used to implement a proper DMAing SCSI controller. As there certainly is a market for SCSI with DMA, but 53C80 is the only controller I can find and it doesn't do DMA. EDIT: it does but it's just 8 bit wide, not a good fit for a 16 or 32 bit bus).

I sometimes wish Jens would be a bit less of an individual and share his insights

Edit2:
Evil master plan, make a clock port 53C80 SCSI 1 controller? That shouldn't be more than a weeks work. Now to find someone who knows anything about driver programming.

Last edited by olegil on 22-May-2015 at 09:38 AM.
Last edited by olegil on 22-May-2015 at 09:37 AM.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@olegil

Quote:

olegil wrote: @cdimauro Edit2: Evil master plan, make a clock port 53C80 SCSI 1 controller? That shouldn't be more than a weeks work. Now to find someone who knows anything about driver programming.

Computers should be about having fun and programming.
Makers should be creators and not consumers.
A computer won't be original until we make it.. When others make it, you get vanilla programming and I want a banana split instead.

@olegil
@Chuckt
@cdimauro (except for the price comment.)

There you go. Now we are looking for IT.

The thing that will bring people, that will compel people to to think "I gotta have one of THOSE."

Not what is wrong in someones opinion or any of that crap. It does not matter if its inside the box, added to the box, or outside the box.

IT!

_________________
Tinkering with computers.

@Signal

Quote:

Signal wrote: @olegil @Chuckt @cdimauro (except for the price comment.) There you go. Now we are looking for IT. The thing that will bring people, that will compel people to to think "I gotta have one of THOSE." Not what is wrong in someones opinion or any of that crap. It does not matter if its inside the box, added to the box, or outside the box. IT!

The developer versions for users wanting to get the $9 computer first already sold out. They're doing something. Everyone else is just talking about it.

@cdimauro

Quote:

The only thing that you need for emulators/JITer to run at full speed is the ability to transparently read/write data with the same endianess of the guest architecture. Transparently means the host works "natively" with the same endianess, without any conversion. And ARM architecture can do it, so setting the big-endianess for memory accesses solves that problem and makes it to work exactly like a 68K or a PowerPC processor. You don't need to have everything big-endian. What only counts for an emulator/JITer is the data. It doesn't make sense and therefore it's absolutely not required that opcodes should be stored in big-endian.

You load an Amiga program, which in this context basically is an unknown and unpredictable 68k binary blob that can be anything, executables, data... The translator starts at an entry point in the blob and "recompiles" what is perceived as executables into the new native ISA. Code is run natively on the CPU, but during runtime the "blob" is dynamically changed, it morphs, it can grow, etc, etc, changed in totally unpredictable ways by the program that simply presumes big endian addressing mode. On a TRUE big endian architecture, this is not a problem, and "the binary blob" (ever changing mix of code and data and pointers/references) can run natively after translation. If the CPU is NOT of a TRUE big endian architecture, where addressing modes is little endian, this concept will crash and burn. In this case, H/W emulation is required (instead of "instruction set emulation" or whatever you may call the translator), and the native idea fails.

AFAIK, the ARMv7 architecture (as well as ARMv8) does NOT support TRUE big endianness (emphasis on the word "TRUE"). If you have sources of information saying otherwise, I'd be happy if you shared it!

I think we can agree on that this (these) architecture(s) is (are) the interesting one(s), right?

@TRIPOS: Signal asked to go back IT, and that's why I stopped writing.

/OT

@cdimauro

Eeh?



Edit: OK, I didn't read the rest of the thread past your response until know...

But please respond if you know more than me about the ARMv7 architecture! I don't want to sound lecturing or such here, I genuinely want to know and learn, and if you know better, then please post any links you have!

Last edited by TRIPOS on 23-May-2015 at 08:23 PM.

@thread

Can a minimig fit into this ?

http://www.alibaba.com/product-detail/High-quality-ALTERA-FPGA-CycloneII-EP2C5T144_1915002041.html


Would be nice if they can put AmigaOS on this

http://www.alibaba.com/product-detail/android-4-1-operation-system-4_1728884839.html

http://store.gadgetfactory.net/

_________________
Download 499.26 Mbps, 659.94 Mbps Upload :)

@TRIPOS

Quote:

TRIPOS wrote: @cdimauro Eeh? Edit: OK, I didn't read the rest of the thread past your response until know... But please respond if you know more than me about the ARMv7 architecture! I don't want to sound lecturing or such here, I genuinely want to know and learn, and if you know better, then please post any links you have!

Very quickly, since we are OT (but FPGAs et similia are OT also ).

From the ARM site, ARMv6 support for mixed-endian data. Pay attention to the BE-8 memory access mode, which is exactly what is needed for implement an emulator or 68K -> ARM JIT .
You can find some examples here: Endianness conversion in ARM.

Now try to imagine what happens when the following 68020 instruction has to be executed:
[code]add.l #$deadbeef,(a0,d0.l*4,$c0dedbad)[/code]
with the location pointed by a0 + d0.l*4 + #$c0dedbad holding the (longword) value #$babef00d.

If you convert the emulated or JITed code to PowerPC, ARM/BE-8, and x86/x64 (using the MOVBE instruction) you can see yourself that the ARM/BE-8 is pretty close to the PowerPC one, whereas the x86/x64 is quite different.

/OT

P.S. Not time to fix errors, sorry.

@cdimauro

Quote:

Now try to imagine what happens when the following 68020 instruction has to be executed: [code]add.l #$deadbeef,(a0,d0.l*4,$c0dedbad)[/code] with the location pointed by a0 + d0.l*4 + #$c0dedbad holding the (longword) value #$babef00d.

You'll find that once you treat the x86/64 with "MOVBE" instruction the same way as the ARM/BE-8, i.e. as a simple load/store architecture without complex addressing modes, that the x86/64 translation looks remarkably similar to the ARM one.

Of course, you could argue that treating the x86 as a load/store architecture and ignoring the complex addressing modes and the direct-to-memory arithmetic and logic instructions is a bit of a cheat; But when you start looking into what actually gets executed in the execution units, quite often you end up with exactly the same stuff either way.

One issue to keep an eye out for is unaligned memory access, though. AmigaOS structures are notoriously mis-aligned at times, having 32 bit words odd 16 bit boundaries. Traditionally, RISC architectures would cause exceptions for that; But over time, they seem to have all either allowed such accesses in general, or at least added special memory instructions that do. x86 never had an issue with that. Of course, for any processor, things get interesting when such an unaligned access crosses an MMU page boundary... not something AmigaOS traditionally had to worry about (what with running on a non-virtualised memory model), but which needs to be kept in mind for any supposedly modern and future-oriented continuations.

@asymetrix

Most likely that device is too small. And there's no RAM.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@umisef

Quote:

umisef wrote: @cdimauro Quote: Now try to imagine what happens when the following 68020 instruction has to be executed: [code]add.l #$deadbeef,(a0,d0.l*4,$c0dedbad)[/code] with the location pointed by a0 + d0.l*4 + #$c0dedbad holding the (longword) value #$babef00d. You'll find that once you treat the x86/64 with "MOVBE" instruction the same way as the ARM/BE-8, i.e. as a simple load/store architecture without complex addressing modes, that the x86/64 translation looks remarkably similar to the ARM one. Of course, you could argue that treating the x86 as a load/store architecture and ignoring the complex addressing modes and the direct-to-memory arithmetic and logic instructions is a bit of a cheat;

Absolutely. And that's a shame, because x86/x64 is losing part of its strong points: code density and more "useful work" per instruction, which come from the features that you cited.
Quote:

But when you start looking into what actually gets executed in the execution units, quite often you end up with exactly the same stuff either way.

Maybe, considered that even x86s & x64s have an internal RISC inside. But, at the end, they will lose some performance due to "flattening" their behavior to RISCs.
Quote:

One issue to keep an eye out for is unaligned memory access, though. AmigaOS structures are notoriously mis-aligned at times, having 32 bit words odd 16 bit boundaries. Traditionally, RISC architectures would cause exceptions for that; But over time, they seem to have all either allowed such accesses in general, or at least added special memory instructions that do. x86 never had an issue with that.

Modern RISC usually allow unaligned accesses also, or have specific instructions, as you already stated. I think that we can forget this kind of issues.
Quote:

Of course, for any processor, things get interesting when such an unaligned access crosses an MMU page boundary... not something AmigaOS traditionally had to worry about (what with running on a non-virtualised memory model), but which needs to be kept in mind for any supposedly modern and future-oriented continuations.

I understand the scenario, but I don't think that it might cause issues. I mean, at the end if one of the pages are not available, it's because the emulator/JITer has hit a memory location which is not present even on the original machine, so a bus fault exception is expected, and will be generated accordingly by the emulator/JITer.

That's unless I misunderstood you, of course.

@cdimauro

https://translatedcode.wordpress.com/2012/04/02/this-end-up/

Isn't the challenge the runtime self-modifying code/data in RAM in big-endian 68000/68020 Amiga programs (in other words - completely unpredictable), and wouldn't BE32 be the answer to this?

@thread

AmiDuino would be interesting.
A600HD kind of HW on FPGA and arduino shields compatible.
One could use full blown & FAST OS (WB3.1/betterWB) & GUI to run the stuff...
(PowerDuino would be expensive...)

Last edited by KimmoK on 29-May-2015 at 10:10 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@TRIPOS

Quote:

TRIPOS wrote: @cdimauro https://translatedcode.wordpress.com/2012/04/02/this-end-up/

It doesn't say nothing which isn't already well known, and no help for our discussions.
Quote:

Isn't the challenge the runtime self-modifying code/data in RAM in big-endian 68000/68020 Amiga programs (in other words - completely unpredictable),

No, that isn't the challenge. When we talk about accelerating the execution of 68K code, I strongly focus on o.s.-friendly code: applications. And applications MUST OBEY to the official guidelines. It means that self-modifying code MUST flush the caches, either by directly executing the proper instructions or (better) calling the o.s. API (which itself execute the proper instructions, but you don't have to care about the processor and what's the proper instructions list to execute).

In such conditions you are able to intercept the self-modifying code, flush translated instructions, and restart the JITer. It's not optimal, but it's perfectly manageable and predictable.

Games don't need to be JITed, because usually they are hardware-bound (e.g.: Blitter speed-bound). Only for 3D games might make sense, but it's a bit messy. Maybe WHDload versions can get some good result, but it should be investigate. However, personally I wouldn't spend time in this direction, since very cheap hardware today is perfectly able to emulate any Amiga game with very good speed.
Quote:

and wouldn't BE32 be the answer to this?

No, BE32 is the classic "solution" for which in Italy we say "non è né carne né pesce" (it's not meat neither fish). It solves only one problem (e.g.: homogeneous longword access/view), but leaves a BIG door open: words (16-bit) access are messed-up.

BE8 is the correct and only tool which makes sense to use for handling 68K (or any big-endian architecture) emulation.