28-Mar-2024 19:07 GMT.
UNDER CONSTRUCTION
Anonymous, there are 427 items in your selection (but only 227 shown due to limitation) [1 - 50] [51 - 100] [101 - 150] [151 - 200] [201 - 250] [251 - 300] [301 - 350] [351 - 400] [401 - 427]
[Events] Notes about my presentation at the Alchimie 4 showANN.lu
Posted on 29-Sep-2004 10:40 GMT by Stéphane Guillard427 comments
View flat
View list
The html pages I made available was only a starter slideshow for my presentation. Here are a few words about what I shown, and what I said. Hi Gentlemen,

The html pages which are available at my site are just an introduction slideshow that I presented as a starter, it does not relate what I shown and said afterwards. Please find below a couple of notes about my presentation at Alchimie show.

Here is a quick summary of the presentation I did :

- I booted with boot delays set to 1 second for UBoot and for SLB (second level booter), thus less than 20 seconds after power on, we were with a fully loaded Workbench with Amidock.

- I started with the small html slideshow, presented on IBrowse. You can find those pages at the URL above. IBrowse loaded in 2 seconds with its About: page fully displayed. Browsing through the pages of the slideshow was instantaneous.

- While we were at it, I browsed the OS4 install guide, also as fast as can be, must say I also find this responsiveness impressive myself :)

Then I demoed as many things as I had time to during the 2 hours I had. Everything worked, fast & stable, and was smooth and impressed. I showed mainly:

- All os4 system, tools, utilities, prefs & stuff

- MUI, IBrowse, Amitradecenter

- Yam, SimpleMail

- ClassAction (M. Elsner's file manager)

- MakeCD

- MooVid running a DivX

- DVPlayer running an mpeg2

- AudioEvolution 4 with the demo project, cursors auto moving smoothly, the playback was smooth also, with mostly no CPU usage.

- AmiPDF with the AE4 manual and another heavy PDF file, very fast

- USB. I plugged a Microsoft IntelliMouse Optical into my USB hub, and we had 2 mice to control the system

- Crisot's slach5 winning demo (got applauses which it deserved)

- chip's rayrace realtime raytracer demo. When the juggler appeared, audience was impressed, but really took measure of what they were watching when I moved the mouse. Wait for the Altivec version !

- FPSE, AmiDog's PS1 emulator, with an oldskool game which ran nicely ('Cotton')

- some other visual toys I had at hand

The demos only grimreaped twice, and I anticipated the grims before they popped up :

- One was native glsokoban / w3d, when I launch it does a base page access (a “null pointer” bug in glsokoban). I didactically shown the disassembly which is available in the grimreaper window, was a store to r4, r4 was null etc. I clicked on continue, and it all went fine & fast.

- One was frying pan 0.3.1, I shown the app, and at one point I said 'now it should grim’ and it did. It still loaded fine though. I quit the app, clicked on reboot and less than 4 secs after, wb was up with amidock. That was the only reboot of the show.

I forgot to show (because of short time):

- Petunia... Almos, sorry, I had prepared something for that (side by side windowed jit & nonjit runs of voxelspace), but i both forgot, and was asked to stop at this point by the party organizers cause it was already 5:30 pm while I was scheduled until 4pm.

- ArtEffect

- USB with MassStorage (ie USB key or digital camera)

At the end, I had many fair questions to which I answered; my feeling is that the audience really appreciated the effort behind what I shown, and was conscious that we are not far away from a releasable 4.0.

Then came the expected question, 'and why doesn’t DMA work ?'

I said 'All what you saw was DMA since the 1st boot'.

I copied a few 100 MB files in a snap, with zero CPU (thanks to Pete Gordon for the clock/CPU docky, helps a lot). Then I switched to PIO, they saw 4 x slower and 80% CPU.

The audience understood that it was indeed DMA, and that was fast, and that was part of the overall smoothness of what I shown.

Then I explained the things below (this is the reference for my statements, please don’t rephrase or extrapolate or invent or whatever):

- IDE UDMA works on VIA and Articia on AmigaOne SE / XE / µA1 MK2 (as I demoed) ...

- ... except when the Ethernet chip goes online and is used.

- the Ethernet chip only triggers the problem, but it is not at all related to it (a test using a PCI Ethernet shows the same behaviour)

- We have made a driver for a Silicon Image 680 PCI IDE UDMA133 controller chip, this does UDMA 133 nicely, including when Ethernet is used at full speed.

- The fact that a PCI IDE controller solution works, shows that the problem is *not* related to Articia, since PCI DMA is *also* handled by the Articia, and that works.

- The full Alchimie show demo was done using UDMA, both from the VIA and from the Si680, without problem (but with Ethernet off, would the Ethernet have been turned online, I would have had to revert the VIA into PIO before).

- Things are currently under more investigation

In the meantime there are 2 options for existing A1 board owners:

- Use the VIA IDE controller in PIO mode when using Ethernet, and UDMA at other times,

- Purchase a faster (UDMA133) Silicon Image 0680 IDE PCI card (from around $20). This is my personally recommended option as the delivered speed is noticeable faster than the on-board VIA controller in UDMA mode.

Notes about my presentation at the Alchimie 4 show : Comment 201 of 427ANN.lu
In reply to Comment 200 (Lando):
Message removed by Teemu I. Yliselä for violation of ANN's posting rules.
Specific reason from moderator: troll
Notes about my presentation at the Alchimie 4 show : Comment 202 of 427ANN.lu
Posted by STRICQ on 29-Sep-2004 23:40 GMT
In reply to Comment 11 (Nicolas Sallin):
Why don't you admit that you can't admit anything? Oh, wait, even in the face of the facts, you can't do anything but spout out proven falshoods. Guess you can't change.
Notes about my presentation at the Alchimie 4 show : Comment 203 of 427ANN.lu
Posted by Tryo on 30-Sep-2004 01:58 GMT
In reply to Comment 199 (Agima):
> I'm sure 'Fair Use'

See, here start your problems. You have no clue what the Fair Use Law is about and come up with some crap totally unrelated to the case at hand.

To say it with Ben Hermans: "Please [Agima], stop talking about things you are clueless about."
Notes about my presentation at the Alchimie 4 show : Comment 204 of 427ANN.lu
In reply to Comment 201 (Lando likes to lick the shit off of cocks that hav):
Message removed by Teemu I. Yliselä for violation of ANN's posting rules.
Specific reason from moderator: reply to troll
Notes about my presentation at the Alchimie 4 show : Comment 205 of 427ANN.lu
Posted by James Carroll on 30-Sep-2004 03:05 GMT
In reply to Comment 204 (hooligan/dcs):
That does sound pretty dumb.. but he was only trolling anyway. just ignore it.

I'm looking into getting this silicon image card now. It's annoying having to spend the extra money, and being forced to as well. But at least the performance will be slightly better.. (going from ATA100 to ATA133).
Notes about my presentation at the Alchimie 4 show : Comment 206 of 427ANN.lu
Posted by JKD on 30-Sep-2004 03:25 GMT
Call it trolling..call it what you will...

Who now has faith in Eyetech / Amiga Inc / Hyperion(*) to produce a solid working product?

We've gone through:

1. There is no bug

2. There maybe a bug but it's un-related chip/register problem

3. There is a bug but we've got it fixed in the next revision of the chip

4. On-board sound doesn't work, sorry

5. Well..in actual fact there's now a software work-around..

6. The next revision is here and it's great, we have working drivers but now the board layout is wrong

I mean...wtf? This is Amiga Inc's stringent QA that people pay the extra licensing money for?

Do you believe that the u-A1, A1-XC will work as stated.

* I might be a little remiss in including Hyperion in the above sentence because the only person from Hyperion seemingly spreading mis-information or half truths was Ben Hermans and I understand he has now stepped down.

For the sake of balance (and a little fun):

1. The Pegasos is here it's great..

2. but..we want you to sign an NDA and it's called a betatester machine

3. Crap...Articia doesn't work...April 1...anyone can get their board fixed for free, send it in.

4. OK, that was an April fools joke, here's April 2...anyone can get their board fixed for free send it in

5. Upgrade to G4.....oh shit, G4s only work in matched pairs...don't upgrade to G4! (*)

6. Screw Articia, lets do Marvell in 2 months....

7. 4 Months later..here's Pegasos 2 (it's great...)

8.. You can upgrade your Peg1 to a Peg2...no, really you can....well, maybe one day...5 months later... okay we really meant it...now everyone disappointed by No Peg 1 G4 can get a Peg 2 G4 :-)

;-)

* Why doesn't the Peg 1 work correctly with a G4 (or do Eyetech/MAI also do burn-in/matching) ??????
Notes about my presentation at the Alchimie 4 show : Comment 207 of 427ANN.lu
Posted by hooligan/dcs on 30-Sep-2004 03:33 GMT
In reply to Comment 205 (James Carroll):
I know.. was just being sarcastic in a tongue-in-cheek'ish way, suppose he was aswell ;)

The good news is that Alan has now finished licking all stamps and the shipments are ready to go!
Notes about my presentation at the Alchimie 4 show : Comment 208 of 427ANN.lu
Posted by brotheris on 30-Sep-2004 03:52 GMT
Does this mean that Eyetech found most A1 problems and betatester period is over ?
Notes about my presentation at the Alchimie 4 show : Comment 209 of 427ANN.lu
Posted by Nicolas DET on 30-Sep-2004 04:20 GMT
@sg2

So if I understood well:

Linux places BD in cacheable area, and then you need to flush then to
be sure they are really in memory and not in the cache.

But if you do need to do that in a cache coherent environement -> the
hardware is buggy -> it *has* to do it by itself as *documented* and
has *every one else* does.

Is it this the ArticiaS "feature" ? you have to flush the cache
manually.
And by the way, if you are in a cache coherent way, flushing the cache
manually, after the hardware had (maybeà done in hardware is quiet
useless/time consuming.

http://homepage.ntlworld.com/zarniwhoop/kernel/ide-dma.c.patch

If I believe this patch MAI use flush/invalidate_dcache_range. This
call will always flush the cache, whereas if they would have real
hardware they would use dma_wback (or something like that) which is
the same as previously if you compile your kernel in a cache coherent
way or void if not.

Do you really believe that your are speaking ? Because from here it
looks like a load of bullshit, as usually...

Espeacially, after explaination like VIA686 init is wrong ...

Bye
Notes about my presentation at the Alchimie 4 show : Comment 210 of 427ANN.lu
Posted by Anonymous on 30-Sep-2004 04:22 GMT
In reply to Comment 209 (Nicolas DET):
> whereas if they would have real
>hardware they would use dma_wback (or something like that) which is
>the same as previously if you compile your kernel in a cache coherent
>way or void if not.

Sorry,
dma_wback in a cache coherent kernel -> void
dma_wback in a non cache coherent kernel -> flush/invalidate.

I fix my post :-))
Notes about my presentation at the Alchimie 4 show : Comment 211 of 427ANN.lu
Posted by Anonymous on 30-Sep-2004 04:25 GMT
Can those of you who claim OS2.x didn't break compatibility with OS1.x software and/or hardware please explain why someone had to invent, produce and sell kickstart switches? If you are right, such products would be of aboslutely no use at all. (The same goes for relokick and other degraders.)

BTW. With your reasoning, WinXP SP2 isn't Windows compatible and not even WinXP compatible since it breaks a lot of software which worked fine with WinXP *before* SP2.

/me shakes head...
Notes about my presentation at the Alchimie 4 show : Comment 212 of 427ANN.lu
Posted by MikeB on 30-Sep-2004 04:51 GMT
In reply to Comment 197 (XraalE):
> Mike, how many times did we explain to you the Fair Use laws?

You know the most funny part is that I pointed you to the related legal information regarding "Fair Use" exceptions, as you simply had no clue. You thanked me even for pointing towards this info (depsite you apparently didn't understand it) and you restored the abused pictures at Wrongpla.net, eventhough I made it clear to you that such exceptions count when you base your work on these images, instead of copying & modifying them.

For satire it *is* for instance allowed to produce a caricature or recreate a look-a-like and in fact this is often done. That's why I supplied you some alternative look-a-like images I told you you could use for your article. However *you* aren't allowed to modify my images and spread them across the internet to suit your own (any) personal agenda! Point me towards any professional "satire" website abusing news pictures copyrighted by CNN or for instance BBC!
Notes about my presentation at the Alchimie 4 show : Comment 213 of 427ANN.lu
Posted by Anonymous on 30-Sep-2004 05:43 GMT
In reply to Comment 194 (MikeB):
Mike, why bother about that site, they clearly have a different definition of the word "satire" then the average human being. Judging the frequency of the updates it's nearly dead anyway..(I use that site as bookmark page for moobunny)

Maybe they should post some of the Genesi publications and announcements, at least they made me smile...

Or they could have copied and pasted the Seascape announcement, that was a good laugh too.
Notes about my presentation at the Alchimie 4 show : Comment 214 of 427ANN.lu
Posted by myself on 30-Sep-2004 05:53 GMT
In reply to Comment 206 (JKD):
nice sum..
but at least eyetech solution didn't forced you to upgrade to amigaone2, because amigaone was completly wrong.

in my eyes, genesi/blpan/mos team everyone from the blue side needed money, so they did this on purpose.... create a broken peg1 to force ppl to buy a peg2..
indeed, if you consider you bought a peg1 that works like shit, you can't admit pegasos is just shit, so you just upgrade... nice trick, genesi or how to sell twice a computer ;)

and the worst part, is that the peg2 weren't available even after few months, well almost 6 or 7 months.. so ppl were just stuck with their crappy peg ;)

now i can understand why they are so agressive in the blue side;)

at least on eyetech/hyperion side there is problems too, but they don't hide, and they try to get it solved properly. for what i get from that show's report, it's now possible.

i'm definatly looking for an aone/os4 ..
Notes about my presentation at the Alchimie 4 show : Comment 215 of 427ANN.lu
Posted by MikeB on 30-Sep-2004 06:11 GMT
In reply to Comment 213 (Anonymous):
> Mike, why bother about that site

Good question. IMO I am basicly required to do so legally. Else it would be like leaving my front door open with a big sign saying "Come here thiefs, I have a nice stereo set, a DVD player, plasma TV, etc. Come and get it!" ;-)

You should do an effort to protect your property and with regard to this situation nobody can claim otherwise.

I also believe Wrongpla.net's webmasters are likely just being used by bbrv, one of Wrongpla.net most vivid contributors. IMO bbrv is a pretty good smooth talker, seemingly lacking generally shared morals. (He thinks it's OK to release confidential private information to suit his own agenda, speaking for rival companies, pushing people to complain on his behalf, etc) I believe some people like KennyR may just be acting like his puppets, not really knowing what they are being dragged into.
Notes about my presentation at the Alchimie 4 show : Comment 216 of 427ANN.lu
Posted by Don Cox on 30-Sep-2004 06:25 GMT
In reply to Comment 198 (Agima):
"Someone saying that if AOS4 is not 100% backwards compatible it's not Amiga OS is just dumb."

It is still AmigaOS, but the fewer programs it runs, the less useful it is, and if not enough run then there is no point in "updating".
Notes about my presentation at the Alchimie 4 show : Comment 217 of 427ANN.lu
Posted by toll on 30-Sep-2004 06:33 GMT
In reply to Comment 214 (myself):
"genesi/blpan/mos team everyone from the blue side needed money, so they did this on purpose...."

Genesi swapped pre-april peg1 boards to apriled ones. You think that made money from this?

The only reason peg2 was made was because Articia was total shit and MAI couldn't be depended on when making business. I guess Eyetech is learning this the hard way, now...

"at least on eyetech/hyperion side there is problems too, but they don't hide, and they try to get it solved properly."

You are kidding right? Eyetech/Hyperion have done nothing but hide the truth for years. The AmigaONE is fundamentally broken and the bugs need to be worked around with extra hardware / hardware hacks. Funnily most AmigaONE hardware is out of warranty now, and never worked as advertised.

Forcing users to buy two extra PCI cards is "solving properly"? Oh man, that's hilarious.

But with extra PCI IDE card you get faster IDE UDMA 133 for your A1XE anyway!!!!!11 :BANANAS: :BANANAS: :BANANAS:

...Except that peg2 stock VIA UDMA 100 is still faster, due to working northbridge. Tough.
Notes about my presentation at the Alchimie 4 show : Comment 218 of 427ANN.lu
Posted by brotheris on 30-Sep-2004 06:36 GMT
In reply to Comment 214 (myself):
at least on eyetech/hyperion side there is problems too, but they don't hide

You rule dude!
Notes about my presentation at the Alchimie 4 show : Comment 219 of 427ANN.lu
Posted by Stéphane Guillard on 30-Sep-2004 06:50 GMT
In reply to Comment 209 (Nicolas DET):
Uhoh. ns called him for help... Who is next ?

>So if I understood well:

Obviously not. Or is it me ? Your code must be better than your english... Anyway I'm in good mood this morning so let's go for a lecture, you seem to need a serious one (yes I'm pedantic, but I know why).

>Linux places BD in cacheable area, and then you need to flush then to
>be sure they are really in memory and not in the cache.

I don't know what 'BD' is. And I never wrote a Linux driver, so I don't need anything.

Obviously anyway, in the case of a write to drive, data must be in ram at the moment when the DMA controller will fetch it and send it to the drive. This is common sense. Did you note the word 'write' just here ? Ok let's go on, I'll explain for 'read' further on.

This 'data must be in ram' situation (otherwise named 'cache is flushed') should be done in hardware, no doubt. This is the cache snoop feature of both the northbridge and the CPU : when a busmaster (let's say DMA controller, but could be anything else like another CPU) fetches data from memory, if this data is in cache and has not been flushed (ie 'dirty'), the busmaster memory access cycle is held, the CPU flushes the dirty cacheline (32 bytes for the PPC), and then the busmaster cycle is restarted.

This way, no code-driven cache flush is needed, it is provided in real time when needed. Note, 'when needed' means that only dirty cache lines are flushed, not the cachelines which contain data in sync with memory.

It works like that on almost all modern environments, except on some embedded platforms which don't provide the snooping feature (be it a lack of the CPU or a lack of the northbridge, by the way), like a renowned BSD coder pointed out some time ago. On those lower end environments, drivers have to explicitly flush the cache before starting a third party bus actor like a DMA controller. The driver will flush the cache for the whole buffer area, but note again, even with what we will call here a 'manual' flush, only dirty cache lines are physically flushed, not the cachelines that contain data which is in sync with memory, as flushing cachelines which are not dirty does nothing and makes no sense.

A quick digression here, to kill a myth : we thus have 2 situations :
- one where the hardware takes care of cache snooping by holding the DMA transfer each time a cache flush is needed,
- and another where the software flushes the cache and then starts the DMA transfer which will be going uninterrupted.

For a given buffer to write to disk, with a given set of dirty cachelines in it (say the buffer is 512 bytes, say there are 3 32 byte cachelines that have to be flushed), according to what I explained, both methods will end up doing exactly the same cache flushes on the bus : 3 cacheline flushes happening in the middle of the DMA transfer with hardware coherency, and 3 cacheline flushes happening in the beginning of the DMA transfer with manual cache flushing, or software coherency. Guess which is faster ? Tell us a good tale here please.

Ok, now back on track. Hardware coherency should work with the Articia also, it provides signals for that. Unfortunately, as known since long, there is a problem in its implementation on current A1 machines, so it does *not work*.

Thus, for a DMA driver to work on current A1's, it *has* to manually flush the buffer caches before asking the DMA controller to write to device.

This is a problem for Linux, since Linux drivers are assuming that they rely on hardware coherency. There is a very quick and dirty workaround, that needs no change in Linux drivers, it is to mark all memory noncacheable. This is obviously evil and stupid, it will work but it will crawl forever. The only advantage is that you can run untouched Linux drivers. The only other way on current machines, is to modify the Linux driver code, to add a manual cacheflush before stating the DMA write to device. Those are facts.

This is not a problem for OS4 drivers, as anyway we have written those from scratch, and along the AmigaOS device driver writing guidelines... The Amiga has never provided hardware coherency, and all the DMA drivers so far have been doing manual cache flushes. Eat it (I know, its hard, especially when you don't understand anything). Ever heard of CachePreDMA() and CachePostDMA() ? Ever thought about the fact that your beloved Ariadne, FastLane, etc & your blue dog's DMA-capable Classic Amiga board does that since day 1 ?

OK. So we implemented our OS4 drivers relying on the OS4-equivalents of CachePreDMA() and CachePostDMA(), which are StartDMA() and EndDMA(). Don't start jumping up and down, those functions are anyway mandatory otherwise OS4 could NOT run on classic hardware, where there is no hardware coherency. Oh, this reminds me. Your beloved blue OS also does that when running on a Classic machine.

By the way, those new OS4 functions also provide for things which are needed in a virtualized address space (like building scatter / gather lists), this is why we needed new calls in OS4.


Now, a word on the read transfers. For reads, no cache flush is needed at all, neither with hardware snooping nor with software cache handling. Why flush cache to ram when you will be overwriting ram with data read from the device ?

What is needed for read is cache invalidation. That is, telling the CPU that he has to go to real ram to fetch data, because its cache contains invalid data. And as Bernie Meyer pointed out earlier, this cache invalidation has to be done *before* the read and not after, contrary to intuition. Why ? If for whatever reason, the CPU wants to cache other areas, completely unrelated to the DMA read being done, it might decide to flush cached areas of the read buffer, in order to get free cache lines. If this flush, which happens 'in your back', happens after the DMA controller wrote data to ram, you end up with trash. Simple way to avoid that : make sure that no area of your read buffer is cached, ie invalidate the cachelines that might cover your buffer. This was one bug of mine a long time ago. You see, I'm not even reluctant to admit my own bugs.

So for reads, no flush, an invalidation (of course bound to your buffer address range, you're not going to invalidate the whole cache), and before the read.


>But if you do need to do that in a cache coherent environement -> the
>hardware is buggy -> it *has* to do it by itself as *documented* and
>has *every one else* does.

I said above, in truth and faith, that this indeed does not work on current A1's. This is known since long, and it is indeed a hardware bug of the current A1's named 'lack of hadware coherency', nothing new here. No need to shout either like if you were the victim of that thing, as far as I know you don't own a current A1 and never will. So relax, have a beer, and we'll continue here.

Did you note 'current' ? the µA1 'C' alias MK3 (and further machines) has proper snoop signaling implemented. Additionnally, this machine also solves the VIA / Ethernet interaction (and all other A1 oddities, like wrong implementation of the AC97 link between the VIA and the Sigmatel audio codec).

What will you say when you'll see untouched linux drivers work on that machine ? And VIA IDE DMA work on it too ? This with the very same Articia chip we have on current machines ? We might have some fun then.

>Is it this the ArticiaS 'feature' ? you have to flush the cache
>manually.

Read above. The articia is not at fault. It is its integration with CPU on current machines which is, in the 'snooping' department. It is the same kind of integration problem as for the VIA IDE clashing with the Ethernet.

Proof to come (yet to be seen by your own eyes, I admit) :
- for the articia being capable of hardware coherency : µA1 C and above does it with current articia chip.
- for the articia not being at fault in the VIA IDE / Ethernet DMA trouble : µA1 C and above does it with current articia chip, and additionnally, si680 PCI IDE DMA works fine on current A1's.

How's that magic possible ?

>And by the way, if you are in a cache coherent way, flushing the cache
>manually, after the hardware had (maybeà done in hardware is quiet
>useless/time consuming.

No cache flushing has to be done *after* a DMA transfer, makes no sense at all.

Additionnally, even if you would cacheflush before a DMA transfer with working hardware coherency, it would be useless (you're right) but not time consuming (you're wrong) because there would be no cache snoop flushes happening during the DMA transfer, since you flushed the dirty pages before. So at the end, zero perf impact. Get it ? If not, reread from start. Counter reached 100 ? Time to stop.

>If I believe this patch MAI use flush/invalidate_dcache_range. This
>call will always flush the cache, whereas if they would have real
>hardware they would use DMA_wback (or something like that) which is
>the same as previously if you compile your kernel in a cache coherent
>way or void if not.

Sorry, I cannot comment that statement, as I don't understand it.

>Do you really believe that your are speaking ?

I'm not speaking, I'm writing now. So I don't believe I'm speaking. But as to what I'm writing, I do believe in it.

> Because from here it
>looks like a load of bullshit, as usually...

Sure, as usual, what I write (or say, or show) looks like loads of bullshit to you, because you & your mates simply cannot understand things that are beyond your reasoning capabilities, and can only keep repeating the same 'articia does not work' kind of nonsense ad nauseam, even after seeing that pci ide DMA controller working with the same articia.

If I sounded a bit irritating and insulting to this small group of obscurantists who will recognize themselves... Well, then I succeeded.

Regards,
--
Stéphane
Notes about my presentation at the Alchimie 4 show : Comment 220 of 427ANN.lu
Posted by Asemoon on 30-Sep-2004 07:02 GMT
In reply to Comment 212 (MikeB):
WrongPla.net is great! I love it 8-) LOL
Notes about my presentation at the Alchimie 4 show : Comment 221 of 427ANN.lu
Posted by Asemoon on 30-Sep-2004 07:18 GMT
In reply to Comment 219 (Stéphane Guillard):
"OK. So we implemented our OS4 drivers relying on the OS4-equivalents of CachePreDMA() and CachePostDMA(), which are StartDMA() and EndDMA()."

The disadvantage is you have to call StartDMA()/EndDMA() in every driver. AHI drivers, ethernet drivers, gfx drivers, SCSI drivers, IDE drivers, USB drivers, FiWi drivers...

"those functions are anyway mandatory otherwise OS4 could NOT run on classic hardware"

Yet another design flaw from Steffen Haeuser? In real Amiga CachePre/PostDMA() used for SCSI kits etc. only. Floppy DMA operates in the non-cacheable environment (hint).
Notes about my presentation at the Alchimie 4 show : Comment 222 of 427ANN.lu
Posted by Peter Gordon on 30-Sep-2004 07:21 GMT
In reply to Comment 219 (Stéphane Guillard):
> What will you say when you'll see untouched linux drivers work on that machine ?

Ooh. This is news to me. If thats true, it neatly sidesteps all the "Eyetech can't sell the uA1 to industry as linux boxes" arguments.
Notes about my presentation at the Alchimie 4 show : Comment 223 of 427ANN.lu
Posted by Anonymous on 30-Sep-2004 07:40 GMT
In reply to Comment 219 (Stéphane Guillard):
It's nice to hear someone commenting on the issue who actually has the knowledge to be able to comment on the issue.

At the same time, once all this has been proven so no further arguments are possible, it makes quite a fool out of the whole blue camp.

- The hardware engineers for not being able to understand what was going on (but they made already a fool out of themselves for not being able to get the FSB running reliable at 133Mhz and for having to match a G4 CPU card witch each Pegasos).
- The core software engineers lacking the knowledge to handle the situation and therefore drawing and loudly spreading wrong conclusions.

- The manager(s) for pissing off Mai while it's the a lack of talent and capabilities of their own engineers (there's no Mai without April).

- The users who blindly follow the software engineers and managers to help spreading wrong conclusions in trusting the capabilities of the software and hardware engineers (at least the quality of the PowerUP cards, the FSB issue and the G4 issue must have made them to rething their blind trust).

Anyway, when that day arrives it will surely make me laugh in contrary to the "satire" on another blind followers and by managers directed "satire" site.
Notes about my presentation at the Alchimie 4 show : Comment 224 of 427ANN.lu
Posted by Stefan Burström on 30-Sep-2004 07:47 GMT
In reply to Comment 219 (Stéphane Guillard):
Very nice explained! I have yet to see the snooping features on the uA1 mk3 boards since this was completely new to me.
Just had to make a small correction in your reasoning since I guess that some people will dig it up and blow it up into unreasonable big proportions:

>For a given buffer to write to disk, with a given set of dirty cachelines in it (say the buffer is 512 bytes, say there are 3 32 byte cachelines that have to be flushed), according to what I explained, both methods will end up doing >exactly the same cache flushes on the bus : 3 cacheline flushes happening in the middle of the DMA transfer with hardware coherency, and 3 cacheline flushes happening in the beginning of the DMA transfer with manual cache flushing, or software coherency. Guess which is faster ? Tell us a good tale here please.

From a computer archutectural point of view this is not 100% true, although you
are getting quite close to the target. When you manually flush the caches,
a CPU normally halts all pipelines since no concurent cache access can be done to do further instruction fetching. I don't know how this works on the PPC, but
as I said this is more of a theoretical question. This simply means that when
flushing 3 cachelines, the cpu will be halted during the time all 3 cachelines
are fed into the write queue in the northbridge. When hardware is snooping, there is a chance for the cpu to interleave the cache flushing with instruction fetching since the hardware does not block during the whole flush.
However, the most timeconsuming part here is actually the memory access since that is done in the FSB speed. So from that point of view, the time to flush the cache is the same regardless if there is software or hardware flushing.
To summarise this: The speed differences will not be noted since the major
part of the time consumed is the memory access which is the same in both
cases.

regards,
Stefan
Notes about my presentation at the Alchimie 4 show : Comment 225 of 427ANN.lu
Posted by Anonymous on 30-Sep-2004 07:48 GMT
In reply to Comment 219 (Stéphane Guillard):
@sg2

I said: "So if I understood well:"
You reply: Obviously not.

and then : "there is a problem in its implementation on current A1 machines, so it does *not work*. "
Who doesn't undertand ???

You say I'm wrong telling the ArticiaS doesn't work, and then you say it doesn't work. :-P

>Sure, as usual, what I write (or say, or show) looks like loads of bullshit to you, because you & your mates simply cannot understand things that are beyond your reasoning capabilities, and can only keep repeating the same 'articia does not work' kind of nonsense ad nauseam, even after seeing that pci ide DMA controller working with the same articia.

Who doesn't understand: when you contradict yourself in the same post...
I'm sorry but you just wrote than ArticiaS implementation is wrong... so it doesn't work ?

Or maybe wrong implentation provide working solution...

>If I sounded a bit irritating and insulting to this small group of obscurantists who will recognize themselves... Well, then I succeeded.

:-)
From here, it makes us laught a lot, keep going!

And, by the way, you don't need to explain me how DMA/cache cohernecy and computer work...
Notes about my presentation at the Alchimie 4 show : Comment 226 of 427ANN.lu
Posted by Nicolas DET on 30-Sep-2004 07:49 GMT
In reply to Comment 225 (Anonymous):
Last post is from me
Notes about my presentation at the Alchimie 4 show : Comment 227 of 427ANN.lu
Posted by Joël EHRET on 30-Sep-2004 07:52 GMT
In reply to Comment 223 (Anonymous):
@anonymous coward
don't forget these HW engineers fixed some problems into the Articia you're perhaps using into your dongled Teron...
don't forget that MAI were unable to admit there was a problem until these engineers take a fly into MAI office to prove them they were right...
this journey should have taken 3 days... max a week... Gerald Carda spent 10 working days and corrected supplementary bugs for MAI...

now think again before posting...

I wonder why when benchmarking the IDE bus on VIA IDE controller on A1 it can only acheives around 55-60MB...
Notes about my presentation at the Alchimie 4 show : Comment 228 of 427ANN.lu
Posted by Andy Hall on 30-Sep-2004 08:00 GMT
In reply to Comment 88 (Fabio Alemagna):
It's not really AmigaOS compatible in many respects, it seems.

To think that I would have wanted so many times to implement certain things in AROS which, however, I couldn't implement because of compatibility issues, and thus I've had to postpone the moment in which I'll implement them whenever a "boxed" approach is implemented in AROS as well.


Maybe if you had of done, AROS would be a remotely interesting, worthwhile project.

As it stands AROS is a wasted oportunity. AROS could of been used to take AmigaOS further, but instead is just a boring OS3.1 reverse-engineer attempt. Aside from Colorwheel.gadget what research has been done to justify the name?

From and end-user point of view, just where is this compatibility? AROS can run less Amiga software than either AmigaOS or MorphOS. With a bit of vision AROS could have been the conerstone of AmigaOS's future, but it just fails to bring anything to the table.
Notes about my presentation at the Alchimie 4 show : Comment 229 of 427ANN.lu
Posted by Anonymous on 30-Sep-2004 08:00 GMT
In reply to Comment 225 (Anonymous):
"Who doesn't understand: when you contradict yourself in the same post...
I'm sorry but you just wrote than ArticiaS implementation is wrong... so it doesn't work ?"

Your reading skills are sophomore. He said the current batch of A1s have a fault, but the new A1s do not have the fault even though the same Articia is used - meaning the fault is with the A1 board itself not the Articia.
Notes about my presentation at the Alchimie 4 show : Comment 230 of 427ANN.lu
Posted by Amon_Re on 30-Sep-2004 08:03 GMT
In reply to Comment 227 (Joël EHRET):
Did MAI ever confirm this? (About Gerda i mean), we only have one source about it as far as i remember.

To Nicolas DET, read SG2's post again, you missed something
Notes about my presentation at the Alchimie 4 show : Comment 231 of 427ANN.lu
Posted by Anonymous on 30-Sep-2004 08:03 GMT
In reply to Comment 227 (Joël EHRET):
And you should remember that samples of the "fixed" ArticiaS as used on the AmigaONE were "thown into the bin" because they still didn't work for the bPlan.
Instead they invented another April version.
Probably to add hardware coherency, a thing they DID understand.
But they weren't able to track their FSB and G4 problems.
Notes about my presentation at the Alchimie 4 show : Comment 232 of 427ANN.lu
Posted by Stefan Burström on 30-Sep-2004 08:05 GMT
In reply to Comment 221 (Asemoon):
>The disadvantage is you have to call StartDMA()/EndDMA() in every driver. AHI drivers, ethernet drivers, gfx drivers, SCSI drivers, IDE drivers, USB drivers, FiWi drivers...

You mean the disadvantage of these drivers beeing able to DMA to virtual memory?
You need to get the scatter gather list to do that and that is exactly what
you get when doing StartDMA().

"those functions are anyway mandatory otherwise OS4 could NOT run on classic hardware"

>Yet another design flaw from Steffen Haeuser? In real Amiga CachePre/PostDMA()

Huh? Why does his name always pop into your head? Last time I checked, he had nothing to do with this. He is taking a very big hit for trying to explain to people how things work, and now you are accusing him of creating design flaws in the original amiga design.

>used for SCSI kits etc. only. Floppy DMA operates in the non-cacheable >environment (hint).

Well, this may come as a surprise to you, but the Floppy DMA (and all other image and sound dma for that matter) operates from Chip ram on classic machines.
All busmasters sitting on the Z3 bus on classic machines has to manually flush or clean the caches to work properly. No matter if they are OS3, OS4 or MOS drivers.
Now, where was your hint again?

rgds,
Stefan
Notes about my presentation at the Alchimie 4 show : Comment 233 of 427ANN.lu
Posted by itix on 30-Sep-2004 08:06 GMT
In reply to Comment 231 (Anonymous):
"But they weren't able to track their FSB and G4 problems." As it seems, all SDRAMs are not compatible with AmigaOne @ 133MHz.
Notes about my presentation at the Alchimie 4 show : Comment 234 of 427ANN.lu
Posted by Tryo on 30-Sep-2004 08:07 GMT
In reply to Comment 215 (MikeB):
> I also believe Wrongpla.net's webmasters are likely just being used by bbrv,
> one of Wrongpla.net most vivid contributors.

Wrong. Next.
Notes about my presentation at the Alchimie 4 show : Comment 235 of 427ANN.lu
Posted by Joël EHRET on 30-Sep-2004 08:09 GMT
In reply to Comment 231 (Anonymous):
@anonymous coward

"these samples" were delivered after the conception of April2 chip.
there were mounted on the latest peg1 built, and the very few peg1 G4 are using these articia's.
Now if you still think they were put in the bin, ask GGS... or is it too complicated?
Notes about my presentation at the Alchimie 4 show : Comment 236 of 427ANN.lu
Posted by Anonymous on 30-Sep-2004 08:21 GMT
In reply to Comment 235 (Joël EHRET):
>there were mounted on the latest peg1 built, and the very few peg1 G4 are using these articia's.

Since another one representing Genesi said they were thrown in the bin, why should one trust you now?

>Now if you still think they were put in the bin, ask GGS... or is it too complicated?

Well, apparently one have to run around to every dealer ever shipped a pegasos board to get the exact markings on every one?
Don't get me wrong, but you cannot blame people for believing things said by persons representing Genesi can you? People might be missinformed, but then, to
patronize them doesn't really help your cause. Especially since it is Genesi people that are giving out dual messages.
Notes about my presentation at the Alchimie 4 show : Comment 237 of 427ANN.lu
Posted by ikir on 30-Sep-2004 08:23 GMT
1-All the new XE will not have this problem, it is only a Earlybird issue. When you buy a developers/tester motherboard you know the risk.
2-There is a hardware fix for it
3-A pci ATA133 (faster) costs 20 euro
4-Again, the machine for the users don't have this problem. So MicroA1-C, MicroA1-I, and the new XE haven't any via problem.
5-Articia is ok
6-Via is not
Notes about my presentation at the Alchimie 4 show : Comment 238 of 427ANN.lu
Posted by brotheris on 30-Sep-2004 08:33 GMT
In reply to Comment 237 (ikir):
wasn't message the same for this older XE ? 'Only SE has the problem, which was patched'
Notes about my presentation at the Alchimie 4 show : Comment 239 of 427ANN.lu
Posted by Joël EHRET on 30-Sep-2004 08:48 GMT
In reply to Comment 236 (Anonymous):
@anonymous coward
GGS is OWNING this board as it IS his WEBSERVER !! it's NOT a board he
SOLD ! READ AGAIN MY STATEMENTS ! (one of the first in this thread)
Notes about my presentation at the Alchimie 4 show : Comment 240 of 427ANN.lu
Posted by MikeB on 30-Sep-2004 08:57 GMT
In reply to Comment 237 (ikir):
IMO Ikir has a solid point here. The current boards (AmigaOne SE/XE, prototype MicroA1s) have been targeted at early birds like beta-testers and developers. As now is clear, this hardware& software beta-testing has been very important. While the AmigaOS4 developer pre-release has also been proven to be a solid foundation to help getting AmigaOS4 development started.

With all the knowledge we have now, there is no reason to believe that the general consumer targeted versions(with AmigaOS4.0 final) would NOT have all important child diseases cured. That's not to claim this or any future board or any future chip is to be 100% bugless, this was neither ever the case with classic Amigas nor for most much simpler solutions, let alone modern day ultra-complex computer systems (However people mostly simply don't know these bugs, as there is no need for them to know due to software fixes).
Notes about my presentation at the Alchimie 4 show : Comment 241 of 427ANN.lu
Posted by JoannaK on 30-Sep-2004 08:59 GMT
In reply to Comment 237 (ikir):
And it took you (and other goons) over *three* years to find out about VIA bugs...

Man, that chip was known to be buggy since spring 2001 (seach with google) and Eyetech (Mai actually) used it on their systems 2002,2003 and 2004...

You tell me... Didnt they know or didn't they just care???
Notes about my presentation at the Alchimie 4 show : Comment 242 of 427ANN.lu
Posted by asemoon on 30-Sep-2004 09:03 GMT
In reply to Comment 185 (MikeB):
Hello mike this is the real Asemoon,greetings from Italy.

Halet chetoreh? salam beresoon beh hamegi.asemoon yani sky wa asemoon abi yani blue sky.khodahafez.
Notes about my presentation at the Alchimie 4 show : Comment 243 of 427ANN.lu
Posted by MikeB on 30-Sep-2004 09:07 GMT
In reply to Comment 242 (asemoon):
> Hello mike this is the real Asemoon,greetings from Italy.

Hello Asemoon! :-)

> Halet chetoreh?

Man Ghoubam! Have fun in Italy! 8-)
Notes about my presentation at the Alchimie 4 show : Comment 244 of 427ANN.lu
Posted by Anonymous on 30-Sep-2004 09:09 GMT
In reply to Comment 239 (Joël EHRET):
>GGS is OWNING this board as it IS his WEBSERVER !! it's NOT a board he
SOLD ! READ AGAIN MY STATEMENTS ! (one of the first in this thread)

Wow, did I touch a sore spot? No need to shout here! In fact, with all the different 'facts' floating around, it is getting quite hard to know exactly who said what and why. Besides, the statement about through parts in the bin was made after your post so how should one know what to trust? I was just trying to point this out to you. I did _NOT_ claim you are wrong. Is that so hard to understand?
Notes about my presentation at the Alchimie 4 show : Comment 245 of 427ANN.lu
Posted by Anonymous on 30-Sep-2004 09:21 GMT
In reply to Comment 233 (itix):
LOL!!! No where did you get that "knowledge" from? The #MorphOS Irc channel maybe?
Don't make me laugh....

Do you mean unbuffered ones? This is because of the weak busdrivers of the ArticiaS, they just can't drive the capacitice load introduced by the "BGA soldering to the mainboard + the trace + 2 X the SDRAM connector soldered to the mainboard + the SDRAM socket contacts + pins of the Memory IC TSSOP in parallel" at this speed.

If you simplify the matter to only the RC time, then it's quite obvious that when you increase "C" in the equation, the result (time) will also be larger.

Especially the memory IC's introduce a lot capacity.

I did never understand why DIMM manufactures don't use the BGA versions of the memory IC's. BGA's introduce a lot less capacity.
(OK It's harder to correct a production problem.)
Notes about my presentation at the Alchimie 4 show : Comment 246 of 427ANN.lu
Posted by Anonymous on 30-Sep-2004 09:29 GMT
In reply to Comment 235 (Joël EHRET):
>@anonymous coward
>
>"these samples" were delivered after the conception of April2 chip.
>there were mounted on the latest peg1 built, and the very few peg1 G4 are >using these articia's.
>Now if you still think they were put in the bin, ask GGS... or is it too >complicated?

OK, let's assume that you are writing the truth, then you're also admitting that Bill Buck is a plain liar. It was him, who said that they tested these samples and then throwed them into the bin afterwards.

There's a dutch saying which, boldly translated, goes like this: "It doesn't matter how fast the lie goes, the truth will catch up on it."
Notes about my presentation at the Alchimie 4 show : Comment 247 of 427ANN.lu
Posted by MikeB on 30-Sep-2004 09:34 GMT
In reply to Comment 216 (Don Cox):
>> "Someone saying that if AOS4 is not 100% backwards compatible it's not Amiga OS
>> is just dumb."

> It is still AmigaOS, but the fewer programs it runs, the less useful it is,
> and if not enough run then there is no point in "updating".

Yes, but for me OS advancements are more important than backwards compatibility! It is well known that WinXP isn't fully backwards compatible with Win98, nor is MacOSX with OS9, neither is even WinXP SP1 with WinXP SP2 and let's not even get started about the IMO "compatibility hell" platform that's called Linux!

AmigaOS4 is intended to be the biggest step forward for AmigaOS ever! The advancement from version 1.3 to 2.0 already broke alot of compatibility. IMO being able to easily create new or port native and AmigaOS4 optimised software is far more important than having exact classic emulation, as else I already have WinUAE installed on my PC and IMO no other solution will beat this for a long time to come.
Notes about my presentation at the Alchimie 4 show : Comment 248 of 427ANN.lu
Posted by Johan Rönnblom on 30-Sep-2004 09:43 GMT
In reply to Comment 219 (Stéphane Guillard):
Thanks for giving us your thoughts on the matter. Now.. will this
driver (si680 or VIA) be released together with the much-rumoured
update?
Notes about my presentation at the Alchimie 4 show : Comment 249 of 427ANN.lu
Posted by megol on 30-Sep-2004 09:59 GMT
In reply to Comment 219 (Stéphane Guillard):
At last someone that seems to know what they are talking about (ignoring the positive spin), I hope you can answer some questings related to this:

1. How long time does it take to evict a cacheline on a "G3"/"G4" PPC?
2. Does PPC have area flushing with constant execution time?
Notes about my presentation at the Alchimie 4 show : Comment 250 of 427ANN.lu
Posted by itix on 30-Sep-2004 10:03 GMT
In reply to Comment 245 (Anonymous):
"LOL!!!" Oh my god.
Anonymous, there are 427 items in your selection (but only 227 shown due to limitation) [1 - 50] [51 - 100] [101 - 150] [151 - 200] [201 - 250] [251 - 300] [301 - 350] [351 - 400] [401 - 427]
Back to Top