Poster | Thread |
cdimauro
|  |
Re: some words on senseless attacks on ppc hardware Posted on 6-Feb-2024 21:37:58
| | [ #861 ] |
|
|
 |
Elite Member  |
Joined: 29-Oct-2012 Posts: 4127
From: Germany | | |
|
| @Gunnar
Quote:
Gunnar wrote: @matthey
Quote:
The AC68k V2 FPGA is packed like a sardine. It doesn't even have room for full 68020 integer support let alone a FPU. Without at least FPU registers, |
Matthey for the record.
1) You are claiming the 68080 V2 would have no full 68020 integer instructions support? Your post is absolutely wrong.
The 68080 CPU in V2 and V4 is complete covering all 68K integer instructions. You can nicely run with it Amiga OS 1/2/3/../3.2 .. ApolloOS, MAC-OS and even Emutos / AtariOS. You can enjoy Amiga 060 demos using FPU and also play 3D games like Quake.
There is nothing missing in the Apollo 68080 CPU. And claiming it would miss 020 EA modes is not the trust but a lie.
The Apollo 68080 CPU has 100% all integer instructions including all instructions of 68000/68010/68030/68040/68060 and so on. You can read this here yourself: http://www.apollo-core.com/documentation/AC68080PRM.pdf |
He's right: you haven't implemented some instructions. You also stated that CALLM and RTM aren't implemented.
You can give whatever YOUR personal reason, but the pure fact is that they aren't implemented, so you can NOT claim the above.
You stated the same in your site as well: http://apollo-core.com/index.htm?page=features 68 ISA is full green for the 68020. Which is clearly false and misleading: you're selling a product which is not compliant to what you're advertising, which is cheating... Quote:
2) You are claiming the 68080 V2 would have no hardware FPU registers and no hardware FPU? Your post is again absolutely wrong. The 68080 in the V2 has not only all register it also has a very potent hardware FPU. The V2 happily scores 74 MFlops in Sysinfo test - which is a lot higher than 68040 and 68060 score.
http://www.apollo-core.com/gfx/vampire_sysinfo.gif |
Have you implemented the full FPU instructions of the 68k ISA, or do you miss some? Quote:
Gunnar wrote: @Karlos Quote:
[quote]@Gunnar Quote: The Apollo 68080 CPU has 100% all integer instructions including all instructions of 68000/68010/68030/68040/68060 and so on. |
Interesting. What do CALLM and RTM do on the 68080? |
I can tell you this. As you might know according to Motorola himself, CALLM and RTM were mistakes in the 020 CPU.[/quote] According to Motorola? Source for this claim? Quote:
Motorola did removed them from the 68K family for good reason: No later 68K CPU therefore supports! |
Motorola removed a lot of stuff: all for good reason? Then why you've implemented the full 68k ISA instead of just the 68060 one? Quote:
68030 does not support them, 68040 does not support them, 68060 does not support them, and Apollo 68080 does not support them either. |
Only because YOU decided to don't support them.
Like the FPU, right? How many times to removed comments on your site when people were asking for the FPU implemented, and you even banned them. It was rarely used, not needed, and there was no space in the FPGA, as you clearly stated it several times.
But one day you woke-up and decided to implement the FPU: it suddenly became important and magically some space in the FPGA was found...
Coherence? It's a word not found on your vocabulary. Quote:
As we all know Motorola recommend to never use CALLM/RTM and the Commodore coding guides forbid using them. Apollo 68080 follow the Motorola guideline. |
Source for both claims? Quote:
Matthey posted the 68080 would not support MVZ. And this claim is incorrect too.
The Apollo 68080 does support MVZ and MVS but we call them MOVZ and MOVS, because our coders think these names sound better. |
Those instructions were added only recently, as you published them just some days ago (as well as the other instructions that you've mentioned on the other comment).
Maybe Matt was simply not up to date with your latest, fresh mindset change.
BTW, are the encodings the same as the ones for Coldfire, or new ones? Quote:
Gunnar wrote: @Karlos
CALLM makes no sense. This is crystal clear and there is not doubt here for me (no one doubts this). |
It's crystal clear only that you haven't implemented them because YOU decided that. But this decisions makes your 68080 not 100% compatible, as you're falsely claiming. Quote:
----------------------------------------------------------------------------------
The Apollo 68080 CPU focuses in adding useful instructions.
For example:
68080 offer the best code density of all 68K family CPU members. |
Is the same true for the 64-bit mode? Quote:
68080 offers for this a number of instructions that make code shorter. For example:
ADDIWL CMPIWL MOVIWL MOV3 MOVZ MOVS PERM BRA.B2 BSR.B2 BCC.B2 DBRA.L
These instruction all help to make more compact code and shorter programs.
Apollo 68080 also offers some very useful FPU enhancements. For example : FMOVERZ and FMOVEURZ These instruction fix gabs in the 68K instruction set for operations where compilers needed to insert a number instructions before. Therefore they hep to reduce code size and improve performance.
You can find a complete overview of all 68080 instruction online: http://apollo-core.com/index.htm?page=coding&tl=1 |
The .B2 are missing. |
|
Status: Offline |
|
|
Hypex
 |  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 0:49:08
| | [ #862 ] |
|
|
 |
Elite Member  |
Joined: 6-May-2007 Posts: 11351
From: Greensborough, Australia | | |
|
| |
Status: Offline |
|
|
Hypex
 |  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 0:57:43
| | [ #863 ] |
|
|
 |
Elite Member  |
Joined: 6-May-2007 Posts: 11351
From: Greensborough, Australia | | |
|
| @agami
Quote:
The same cannot be reasonably said for any PPC hardware intended for AmigaOS 4 and its catalogue of apps. |
That's because it's held back by the intended market. Which was Amiga users. So AmigaOS 4 is designed to run as an AmigaOS machine with backwards compatibility. Even though the purpose was to move the OS forward it took with it all the legacy cruft that prevents the core design from upgrading to 64 bit, SMP and being portable. Though it likely would have had as much in common with AmigaOS as AmigaDE did, the Amiga Inc portable AmigaOS4 x86 and AmigaOS 5 ideas would have been more future proof. |
|
Status: Offline |
|
|
Hypex
 |  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 1:09:11
| | [ #864 ] |
|
|
 |
Elite Member  |
Joined: 6-May-2007 Posts: 11351
From: Greensborough, Australia | | |
|
| @Kronos
Quote:
And even in 94 noone was gaming Doom in HAM because it didn�t look that much better than 256 colors to justify the piss poor performance even on elite priced HW. |
No one was running Doom in HAM because an A500 HAM port was pointless. That's worse than even expecting Doom to run on an A500. I say A500 because it can only display a max 64 colour palette so for ECS using HAM6 would a way to get close to those 256 colours. Now AGA, this already had a 256 colour mode, so HAM8 is pointless. Doom was a 256 colour game so a virtual 18 bit pixel mode is rather more pointless, using the same amount of bitplanes, as well as needing more live pixel conversion, unless you wanted to match the 18 bits to match 18 bit VGA, since the Amiga could [slowly] display 256 colours in full 24 bit precision. |
|
Status: Offline |
|
|
Gunnar
|  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 5:42:47
| | [ #865 ] |
|
|
 |
Cult Member  |
Joined: 25-Sep-2022 Posts: 512
From: Unknown | | |
|
| @cdimauro Quote:
Quote:
Gunnar: CALLM makes no sense. This is crystal clear and there is not doubt here for me (no one doubts this). Commodore Programming guidelines forbid using them. Motorola removed them and advice people to not use them. Of course : No Amiga software, No Mac Software and No Atari Software uses this instruction.
All new 68K CPUs do not support this instruction The 68030 CPU does not support it. The 68040 CPU does not support it. The 68060 CPU does not support it. The Apollo 68080 CPU does not support it.
|
It's crystal clear only that you haven't implemented them because YOU decided that. But this decisions makes your 68080 not 100% compatible, as you're falsely claiming.
|
You need to read more careful: As written the 68080 is 100% compatible to 030/040/060 .. The 68080 does not support CALLM, and this is good as its the "demanded" behavior for any 68K CPU as by Motorola.
You need to understand that No Amiga software, No Mac Software and No Atari Software uses this instruction. And No new 68K CPU does support this instruction. So all is good.
Cesare, you misunderstand the topic that Matthey was referring too: Matthey was NOT talking about CALLM. Matthey is not an idiot. Only an idiot would think supporting CALLM is needed.
What Matthey was talking about were the 68020 EA modes. The 68020 introduced major improvements and enhancements on the EA = address modes These 020 EA modes support Index * Scale - which is very nice. And the 020 EA modes support ([]) double indirect memory access. The double indirect mode is accessing data over a pointer to a pointer in a single ASM instruction. The 020 EA modes are pretty strong and allow make shorter code. The 68080 does of course support them - as you also see in the GCC assembler output posted above. The GCC used for the 68080 an double indirect mode automatically. Supporting these 020 - EA modes is absolutely crucial for compatibility.
Historically the "phoenix" core which was use in the around one hundred Beta-V1 cards, did miss some features - as it had to be stripped to fit in the tiny small FPGA of the V1.
The Vampire 1 was produce 10 years ago. If you read the Apollo Website then you can see this information:

You see its very clearly stated that the Phoenix core in the Vampire was limited in features and was not 100% compatible. This was because of the tiny FPGA of the V1.
The problem with Matthey is that he mixes up the 100ish cards of the 10 year old Vampire 1 with the over ten thousand cards of the Vampire2 and Vampire4 - and mixes up their capabilities and features. And his mixup makes Matthey talk a lot of bollocks since years about the Vampire2/4
Quote:
Quote:
68080 offer the best code density of all 68K family CPU members.
|
Is the same true for the 64-bit mode?
|
Yes absolutely - the Apollo 68080 has the best code density by far.
Code density is a very nice feature. Code density makes programs smaller. Smaller code allows you get more code in the Kickstart Rom Smaller programs load quicker and better fit into caches = which makes them run faster.
Quote:
Quote:
The .B2 are missing.
|
B2 is included in the "normal" instruction. B2 allows that short branches jump twice as far. This means the compiler/assembler can more often use .S/.B distance and needs to use less the .W distance. This helps programs getting smaller and better fit into cache = makes them run faster.
This is an automatic feature that Assemblers as GNU-AS, AsmONE, VASM, do support.
Last edited by Gunnar on 07-Feb-2024 at 05:44 AM.
|
|
Status: Offline |
|
|
cdimauro
|  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 6:10:55
| | [ #866 ] |
|
|
 |
Elite Member  |
Joined: 29-Oct-2012 Posts: 4127
From: Germany | | |
|
| @Gunnar
Quote:
Gunnar wrote: @cdimauro Quote:
It's crystal clear only that you haven't implemented them because YOU decided that. But this decisions makes your 68080 not 100% compatible, as you're falsely claiming.
|
You need to read more careful: As written the 68080 is 100% compatible to 030/040/060 .. |
http://apollo-core.com/index.htm Today, 680x0 is still used by industrial machines, planes industry, cars vendors and is still used by retrocomputing fans around the world.
Apollo Core 68080 is the natural and modern evolution of latest 68000 processors. It's 100% code compatible, corrects bugs of 680x0 designs and adds on top most of the cool features which were invented the years after.
http://apollo-core.com/index.htm?page=features Apollo Core 68080 is not only the fastest 68000 series CPU ever, it also is the most fully featured.
68 ISA 68000 68020 68030 68040 68060
All green...
And I haven't even talked about the PMMU instructions here... Quote:
The 68080 does not support CALLM, and this is good as its the "demanded" behavior for any 68K CPU as by Motorola. |
Again, source for this claim? Quote:
You need to understand that No Amiga software, No Mac Software and No Atari Software uses this instruction. And No new 68K CPU does support this instruction. |
That's ok, I've no problem accepting it... Quote:
...but not this, if the claim is to be 100% compatible, because this is clearly not the case. Quote:
Cesare, you misunderstand the topic that Matthey was referring too: Matthey was NOT talking about CALLM. Matthey is not an idiot. Only an idiot would think supporting CALLM is needed. |
Motorola's engineers were the idiots that not only designed, but even implemented CALLM/RTM...
Anyway, this isn't the point: see above. Quote:
What Matthey was talking about were the 68020 EA modes. The 68020 introduced major improvements and enhancements on the EA = address modes These 020 EA modes support Index * Scale - which is very nice. And the 020 EA modes support ([]) double indirect memory access. The double indirect mode is accessing data over a pointer to a pointer in a single ASM instruction. The 020 EA modes are pretty strong and allow make shorter code. The 68080 does of course support them - as you also see in the GCC assembler output posted above. The GCC used for the 68080 an double indirect mode automatically. Supporting these 020 - EA modes is absolutely crucial for compatibility. |
Absolutely. I've used them a lot in my 68020+ code (especially my 80186 emulator).
However, the problem with double-indirections was about performance. How work the 68080 in this case? Quote:
Historically the "phoenix" core which was use in the around one hundred Beta-V1 cards, did miss some features - as it had to be stripped to fit in the tiny small FPGA of the V1.
The Vampire 1 was produce 10 years ago. If you read the Apollo Website then you can see this information:

You see its very clearly stated that the Phoenix core in the Vampire was limited in features and was not 100% compatible. This was because of the tiny FPGA of the V1.
The problem with Matthey is that he mixes up the 100ish cards of the 10 year old Vampire 1 with the over ten thousand cards of the Vampire2 and Vampire4 - and mixes up their capabilities and features. And his mixup makes Matthey talk a lot of bollocks since years about the Vampire2/4 |
I've no problem accepting them, but I leave to Matt clarify his position on this.
Quote:
Quote:
Gunnar: 68080 offer the best code density of all 68K family CPU members.
Is the same true for the 64-bit mode?
|
Yes absolutely - the Apollo 68080 has the best code density by far.
Code density is a very nice feature. Code density makes programs smaller. Smaller code allows you get more code in the Kickstart Rom Smaller programs load quicker and better fit into caches = which makes them run faster. |
I know it very well, and that's the reason why I've decided to design my ISAs to have great code density.
This happens with any kind of code: either in 32 or 64 (or 16 bit) mode, by using the full set of 32 GP registers and/or the 32 SIMD/Vector registers. There's no difference, because the opcodes are substantially the same.
However with the 68080 it's different, because of the prefix that it's needed to enable the 64 bits and for accessing the new registers (besides the AMMX, which uses the normal Line-F opcodes, where all of this was already packed there). So, I expect a great loss of code density in this case.
I mean: 32-bit code and using the regular 68k registers is no problem. You get even better code density with the new instructions. But other than that, I expect a loss in code density. Quote:
Quote:
B2 is included in the "normal" instruction. B2 allows that short branches jump twice as far. This means the compiler/assembler can more often use .S/.B distance and needs to use less the .W distance. This helps programs getting smaller and better fit into cache = makes them run faster.
This is an automatic feature that Assemblers as GNU-AS, AsmONE, VASM, do support. |
OK, so my understanding is that you used the unused odd (bit #0 = 1) encodings in the 8-bit offset to double the branch range.
Nice move. I did the same with my architectures since day 0.
P.S. No time to read again. Work time now... |
|
Status: Offline |
|
|
Gunnar
|  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 6:34:20
| | [ #867 ] |
|
|
 |
Cult Member  |
Joined: 25-Sep-2022 Posts: 512
From: Unknown | | |
|
| @cdimauro
Quote:
OK, so my understanding is that you used the unused odd (bit #0 = 1) encodings in the 8-bit offset to double the branch range. Nice move. I did the same with my architectures since day 0. P.S. |
When we talk about architectures,
Then I understand you talk about the 68080 CPU. * The 68080 is on the market over 10 years. * The Apollo 68080 is very popular both in Amiga and Atari world. * The Apollo 68080 has over ten thousand customer using it since nearly a decade now. * The Apollo 68080 is running any version of Amiga OS from 1.1 to 3.9 including the new ApolloOS, Mac OS 7 and 8 and AtariOS/Emutos. * And the Apollo 68080 running many programs and also ApolloOS compiled using new instructions...
What is your architecture again? Remind me again, your "architectures" only exists on paper, right? How many programs did your architecture ever run? Did it ever boot Mac OS? Did it ever boot AtariOS? Did it ever run any Amiga OS 1.x, 2.x, or 3.x? How many programs did you write using your new architecture? Did you ever use "your fantasy CPU" it the real world ? Did you ever proof that your architecture even works and is not broken by design?
Please help me understand this better. I had the impression that your architecture is only "on paper" and in your fantasy and it was never proven that its encoding are even working.
|
|
Status: Offline |
|
|
kolla
|  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 7:26:08
| | [ #868 ] |
|
|
 |
Elite Member  |
Joined: 20-Aug-2003 Posts: 3357
From: Trondheim, Norway | | |
|
| @cdimauro
Being the math genious, how do you define 100% anyways? At what point do you round up? 99,9% 99,99%
And then there "compatible" - nobody should need to care if a new cpu is 100% compatble with an old cpu, what’s important is that the new cpu is 100% compatible with existing software.
AC 68080 is compatible with nearly 100% of existing Amiga software - that’s what the advertising should say, the current claim is both inaccurate and somewhat nonsensical.
_________________ B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC |
|
Status: Offline |
|
|
Gunnar
|  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 8:01:33
| | [ #869 ] |
|
|
 |
Cult Member  |
Joined: 25-Sep-2022 Posts: 512
From: Unknown | | |
|
| @kolla
Quote:
And then there "compatible" - nobody should need to care if a new cpu is 100% compatble with an old cpu, what’s important is that the new cpu is 100% compatible with existing software. |
I agree. This is the point. You want to be compatible to software - not to a removed instruction.
No 68k software uses CALLM - so no CPU needs to support it.
Dropping an not used instruction is nothing new. People understanding the 68K architecture, will know that early 68000 chips did include instructions that are not supported anymore with later 68000 chips.. and that these instructions are also not supported by 68010 / 680020 or later chips. And that no software uses these instructions. So this is all good and no problem. |
|
Status: Offline |
|
|
Karlos
|  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 9:31:01
| | [ #870 ] |
|
|
 |
Elite Member  |
Joined: 24-Aug-2003 Posts: 4843
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition! | | |
|
| When I asked what CALLM does, the only person who responded appropriately was Hans.
Come on guys, it was a comic relief shitpost! All this argument 
Though I still think it would be cool if it were implemented as a means I'd calling runtime supplied hardware modification (ime. hacking fun) of the FPGA itself. Assuming that's even possible. Last edited by Karlos on 07-Feb-2024 at 09:40 AM.
_________________ Doing stupid things for fun... |
|
Status: Offline |
|
|
Gunnar
|  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 9:39:52
| | [ #871 ] |
|
|
 |
Cult Member  |
Joined: 25-Sep-2022 Posts: 512
From: Unknown | | |
|
| @Karlos
Quote:
When I asked what CALLM does, the only persons who responded appropriately was Hans. |
I agree. Hans post was funny and smart.
I have the feeling that for some people this forum is an alternative reality ... in which they dream or fantasize about being an Amiga coder .. |
|
Status: Offline |
|
|
Hypex
 |  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 12:44:37
| | [ #872 ] |
|
|
 |
Elite Member  |
Joined: 6-May-2007 Posts: 11351
From: Greensborough, Australia | | |
|
| @Hammer
Quote:
John Carmack is aware of the A4000/040 with RTG card capability, but his argument is the installed base with Amiga's 68040+RTG specification. |
I came across this original discussion where John talks about using planar to write the Doom screen. Which is then misinterpreted as being [Amiga style] bit planar. I thought it was funny.
https://groups.google.com/g/alt.games.doom/c/3tMB2UmEBK0/m/m1VR6LiJRQMJ
In my experience, which is using an A4000/060, I found there was only about a 1-2 difference in frame rate. RTG was slightly faster. And in most cases, the screen needed rendering in fast RAM, then copying to the framebuffer for greater speed. Of course an 060 wasn't an average build back then. An 030 was more likely if that.
Even with RTG, the framebuffer tended to be a linear pixel map. But VGA doesn't always use a linear layout since it's byte planar based. And Doom used VGA tricks for parallel pixel writes. So even RTG wouldn't be fully there. Since it really needed direct VGA access for most efficient rendering. |
|
Status: Offline |
|
|
Hypex
 |  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 13:12:02
| | [ #873 ] |
|
|
 |
Elite Member  |
Joined: 6-May-2007 Posts: 11351
From: Greensborough, Australia | | |
|
| @agami
Quote:
For Commodore, a company that was in debt and struggling to find meaningful profitability, the A1200 was about as logical/practical a move as they come |
The A1200 was obviously late. And failed to fix problems like supporting standard HD floppies and faster serial/parallel ports. But it came too late after the A500 as an A500 follow up. Even to this day gamers and game programmers still treat the A500 as king. And the A1200 like a speck of dust on glass.
Quote:
Alas it and subsequent CD32 gambit did not pay off. And I'd go as far to say the world was poorer for it. |
The CD32 was an Amiga game console for Amiga gamers sold in public. Though it was sold along other consoles it didn't belong there. It was made for Amiga users. On top of this was that ridiculous XOR patent. I don't know if Cadtrak targeted Commodore over the C64, Amiga or what. But holding back the CD32 was even more ridiculous since the pointer sprite wasn't a soft cursor as an XOR cursor would be. Though AmigaOS would likely have used XOR for text cursor. In any case, Commodore should have taken the cut and paid them, instead of defending their honour. It didn't mean they was guilty, it was all business in the end, but they seemed to treat it as personal. Oh well. |
|
Status: Offline |
|
|
Hypex
 |  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 13:43:06
| | [ #874 ] |
|
|
 |
Elite Member  |
Joined: 6-May-2007 Posts: 11351
From: Greensborough, Australia | | |
|
| @NutsAboutAmiga
The closest I could compare the AmigaOne/XE G4 too would be an eMac. I prefer to compare like for like as comparing direct with a PC will always fall short on price and power by comparison. Where as with a Mac both were running a PPC and with an eMac, IIRC, the basic model also ran at 800Mhz. However, an eMac was a limited all in one solution, costing $1500 AUD. My A1 setup, which I built myself, cost $2000 AUD for my setup. But it was terrible at running OSX if you could convince it to. 
I can recall 1.8 Ghz PCs but it was a time after I bought my A1. And at the time I thought it would be cool to have an AmigaOne that had a 1.8Ghz CPU. Eventually the X1000 arrived and had a dual core 64-bit CPU running at that 1.8 Ghz! Unfortunately by the time that arrived 1.8 Ghz wasn't exciting for me any more.  |
|
Status: Offline |
|
|
Hypex
 |  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 13:59:58
| | [ #875 ] |
|
|
 |
Elite Member  |
Joined: 6-May-2007 Posts: 11351
From: Greensborough, Australia | | |
|
| @agami
Quote:
Yeah, in respect to the AmigaOS 4 drivers (queue rim shot). |
Actually I was thinking with the hardware itself. Only DDR2, USB2, SATA was ok, 8 or 16GB limit on RAM but no one knows. Firmware was too slow and too easy to crash.
But, drivers, yes. On my A1/XE, a VIA USB2 card kept crashing, while other people with one sharing same PCI ID worked fine. Latest OS4 update freezes my R7 250 but it was fine before the update. The X1000 ethernet, runs too slow, and barely meets 200KB/s while connection can do 1.5MB/s. My XE running OS4 and my X1000 running Linux both max the ethernet port. X1000 needs RTL8139 as OS4 lacks stable onboard driver. But OS4 driver is crippled. Shouldn't be too hard and shouldn't need to fiddle with technical settings. Internet on X1000 OS4 sucks even without the browser.  |
|
Status: Offline |
|
|
Hypex
 |  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 14:28:37
| | [ #876 ] |
|
|
 |
Elite Member  |
Joined: 6-May-2007 Posts: 11351
From: Greensborough, Australia | | |
|
| |
Status: Offline |
|
|
Hypex
 |  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 14:35:56
| | [ #877 ] |
|
|
 |
Elite Member  |
Joined: 6-May-2007 Posts: 11351
From: Greensborough, Australia | | |
|
| @BigD
Quote:
No one is going to buy a ÂŁ1000+ PPC AmigaOne from outside the elitist "Classes not the Masses" AmigaOne fanboydom. |
The Amiga post dated the "Classes not the Masses" Commodore era. It was expensive. Even the C64 cost a bit but the Amiga made it look cheap. |
|
Status: Offline |
|
|
NutsAboutAmiga
|  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 16:35:51
| | [ #878 ] |
|
|
 |
Elite Member  |
Joined: 9-Jun-2004 Posts: 12960
From: Norway | | |
|
| @Hypex
Quote:
Internet on X1000 OS4 sucks even without the browser. |
Can be interesting monitor it with WireShark and see what it does differently.
MC680x0 Amiga uses the same old Sana2 API, so has all the issues MTU etc, RoadShow is considered a good TCP/IP stack on Amiga, because Maimi does not even have working DHCP client. AmiTCP is even older.
https://www.linkedin.com/advice/0/what-best-practices-mtu-discovery-negotiation
funny it uses ICMP, as ICMP is so often disabled this days to avoid ping of death. I think that spy on network traffic to sniff the MTU be better approach, of it can be put in ARP packet, sense its used during IP assignment.
Your router should be able split up network packers if needed, you should not need to set small MTU.
I won’t be surprised if bsdsocket.library in WinUAE bypasses the SANA2 low level API.
Its really up to the SANA2 driver to copy network packets, I expect that its not memory aligned, perhaps is not coping the data with fastest possible methods. Smaller memory blocks is slower if you use DMA transfer, but I expect of driver use 32bit copy routines not 64bit ones, or AltiVec as its up to the drivers.
Because IRQ was mess on AmigaONE-XE, it can be that IRQ is not used or something like that well. If the drivers is generic, and not written for AmigaONE-X1000.Last edited by NutsAboutAmiga on 07-Feb-2024 at 05:26 PM. Last edited by NutsAboutAmiga on 07-Feb-2024 at 05:12 PM. Last edited by NutsAboutAmiga on 07-Feb-2024 at 05:03 PM. Last edited by NutsAboutAmiga on 07-Feb-2024 at 04:59 PM. Last edited by NutsAboutAmiga on 07-Feb-2024 at 04:56 PM. Last edited by NutsAboutAmiga on 07-Feb-2024 at 04:45 PM. Last edited by NutsAboutAmiga on 07-Feb-2024 at 04:43 PM. Last edited by NutsAboutAmiga on 07-Feb-2024 at 04:38 PM.
_________________ http://lifeofliveforit.blogspot.no/ Facebook::LiveForIt Software for AmigaOS |
|
Status: Offline |
|
|
kolla
|  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 17:37:59
| | [ #879 ] |
|
|
 |
Elite Member  |
Joined: 20-Aug-2003 Posts: 3357
From: Trondheim, Norway | | |
|
| @Gunnar
Quote:
Gunnar wrote: @kolla
Quote:
And then there "compatible" - nobody should need to care if a new cpu is 100% compatble with an old cpu, what’s important is that the new cpu is 100% compatible with existing software. |
I agree. This is the point. You want to be compatible to software - not to a removed instruction. |
So will you fix your website to reflect reality? It currently claim 100% code compatibility without specifying that what you mean is compatibilty with nearly 100% of Amiga software.
I have tons of 68k software that for various reasons can not run on AC68080, however this is not Amiga software and hence will never enter your calculations. You simply fix your compatibility numbers by ignoring all software that isn’t compatible. 100% code compatibility with software that is 100% compatible._________________ B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC |
|
Status: Offline |
|
|
agami
|  |
Re: some words on senseless attacks on ppc hardware Posted on 7-Feb-2024 23:22:07
| | [ #880 ] |
|
|
 |
Super Member  |
Joined: 30-Jun-2008 Posts: 1898
From: Melbourne, Australia | | |
|
| @Hypex
Quote:
Hypex wrote: @agami
That's because it's held back by the intended market. Which was Amiga users. |
So in a way, you're saying that "Amiga users", the intended market in the original plans for AmigaOS 4, are not interested in the "right tool being half the work", and are somewhat masochistic in subjugation to a tool which demands that humans do 80%+ of the work, and furthermore pay a premium for their digital S&M sessions.
_________________ All the way, with 68k |
|
Status: Offline |
|
|