Announcement

Collapse
No announcement yet.

Amiga vragen die je nooit durfde te stellen...

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Amiga vragen die je nooit durfde te stellen...

    Op EAB loopt een leuk draadje "Amiga questions you've always been too embarrassed to ask". Dat mondt inmiddels uit in een enorme developers discussie in oneindig veel details. Het topic is juist bedoeld voor eenvoudige vragen waarop je het antwoord altijd al graag had willen hebben, maar die je niet durfde te vragen. Omdat Amiga Cafe steeds meer bezoekers krijgt, lijkt het mij een goed topic dat hier ook niet mag ontbreken.

    Een voorbeeld. Wat ik nooit wist dat de mapnaam 'C" staat voor 'Commands". Op zich best logisch, als je beseft dat in die map alle handige commands staan zoals dir, delete, avail, etc :)

    Maar dan in het verlengde hiervan: waar staat de mapnaam "L" voor? (niet te verwarren met de map Libs)

    Iemand een idee?

    #2
    Die L: (Library) is feitelijk de directory waarin de handlers/drivers voor de hardware-ondersteuning van het OS komen te staan.

    In de mountlist staan de verwijzing naar de mogelijke bestanden van de L: directory.

    Hoe zit het precies met die MaxTransferRate?
    Last edited by Berry; 20-11-2019, 21:55.

    Comment


      #3
      Die L: (Library) is feitelijk de directory waarin de handlers/drivers voor de hardware-ondersteuning van het OS komen te staan.
      In de mountlist staan de verwijzing naar de mogelijke bestanden van de L: directory.
      Dus L staat voor Library... en de maps Libs is dan libraries? Of heb ik dat dan al verkeerd?

      Comment


        #4
        Originally posted by mendark View Post

        Dus L staat voor Library... en de maps Libs is dan libraries? Of heb ik dat dan al verkeerd?
        Klopt. Nogal vreemd, toch? Zie ook https://wiki.amigaos.net/wiki/AmigaDOS_Introduction#L:

        In mijn geheugen was L: vooral voor de “handLers”. Ze hadden het dan ook beter H: kunnen noemen.
        It's a wonder tall trees ain't layin' down

        Comment


          #5
          Ok, nog eentje dan:

          In hoeverre heeft de stack waarde werkelijk invloed op de werking van een game of programma?

          ​​​​​

          Comment


            #6
            goeie vraag. ligt dat er niet vooral aan hoe het programma geschreven is?

            Comment


              #7
              Originally posted by rvo View Post
              goeie vraag. ligt dat er niet vooral aan hoe het programma geschreven is?
              dat denk ik ook, de stack verhogen in de Shell om een programma beter of iig te laten draaien haalde nooit veel uit.
              Amiga 500, 600 Vampire 2, 1200, 4000, Minimig, Blizzard PPC, CyberstormPPC, AmigaOS4.1 Classic, PowerBook G4 Morphos 3, AmigaONE 500 Amiga OS4.1, CD32

              Comment


                #8
                Originally posted by Benny View Post
                dat denk ik ook, de stack verhogen in de Shell om een programma beter of iig te laten draaien haalde nooit veel uit.
                Normaal gesproken heeft een stack genoeg ruimte of juist niet... zolang er genoeg stack ruimte is kan het programma werken (niet beter of slechter, werkt gewoon) ... bij tekort (call stack te diep of teveel variabelen op stack) mag je hopen dat het OS of CPU hierop trapped... zoniet dan heb je een probleem aangezien het programma dan mogelijk andere geheugen gebieden corrumpeert

                Comment


                  #9
                  Originally posted by LuzUo View Post
                  Normaal gesproken heeft een stack genoeg ruimte of juist niet... zolang er genoeg stack ruimte is kan het programma werken (niet beter of slechter, werkt gewoon) ... bij tekort (call stack te diep of teveel variabelen op stack) mag je hopen dat het OS of CPU hierop trapped... zoniet dan heb je een probleem aangezien het programma dan mogelijk andere geheugen gebieden corrumpeert
                  De oorzaak zit hem erin dat de Amiga nog geen automatische stack resizing heeft.
                  Amiga 500, 600 Vampire 2, 1200, 4000, Minimig, Blizzard PPC, CyberstormPPC, AmigaOS4.1 Classic, PowerBook G4 Morphos 3, AmigaONE 500 Amiga OS4.1, CD32

                  Comment


                    #10
                    en heeft een util als stackattack dan zin? ik weet wel dat je bij veel PPC apps de stack moet verhogen voor je de ppc exe opstart. dit komt zeker doordat de ppc cpu niet door het OS wordt afgevangen als het buiten de stack treedt?

                    Comment


                      #11
                      Originally posted by rvo View Post
                      en heeft een util als stackattack dan zin? ik weet wel dat je bij veel PPC apps de stack moet verhogen voor je de ppc exe opstart. dit komt zeker doordat de ppc cpu niet door het OS wordt afgevangen als het buiten de stack treedt?
                      Geen antwoord op je vraag, maar Stackattack klinkt als de titel van een early-mid jaren 90 rap-album.
                      It's a wonder tall trees ain't layin' down

                      Comment


                      • rvo
                        rvo commented
                        Editing a comment
                        haha, eens! toch heb ik die wel standaard draaien op mijn systeem.

                      #12
                      Originally posted by LuzUo View Post
                      Normaal gesproken heeft een stack genoeg ruimte of juist niet... zolang er genoeg stack ruimte is kan het programma werken (niet beter of slechter, werkt gewoon) ... bij tekort (call stack te diep of teveel variabelen op stack) mag je hopen dat het OS of CPU hierop trapped... zoniet dan heb je een probleem aangezien het programma dan mogelijk andere geheugen gebieden corrumpeert
                      Als ik het me goed herinner is de bron van alle ellende dat de Amiga geen memory protection heeft. Dus kun je niet zien wanneer een programma buiten z'n eigen memory bereik gaat rotzooien en dus ook niets afvangen. Als ik het me goed herinner heb je daarvoor heb je een MMU nodig die er niet was (is ook een requirement voor Amiga Unix). Lijkt me een grote en complexe wijziging in het OS om dat alsnog toe te voegen.

                      Comment


                      • Benny
                        Benny commented
                        Editing a comment
                        Complex maar maakbaar ? De nieuwe 3.2 leent ook al code van OS4.x en in OS4 is al een begin gemaakt met gebruik van de MMU als bv. virtual memory https://wiki.amigaos.net/wiki/Exec_Memory_Allocation
                        Trouwens Thor, de ontwikkelaar van 3.2, is de auteur van de mmu.libray voor OS3.x

                      • LuzUo
                        LuzUo commented
                        Editing a comment
                        Hier werd op het Apollo forum ook door iemand tot vervelends toe naar gevraagd ... Gunnar gaf een prima antwoord:

                        For those which not understand anything about OS.

                        AMIGA OS is designed like a skinny 50 KG marathon runner.
                        UNIX Memory Protected is designed like a 200 KG huge Sumo wrestler.


                        If you add 150 KG more weight to the marathon guy - he will not be the same person and never run a marathon as before.

                        You would NOT have AMIGA OS anymore after you added 150KG/300 pounds of memory protection to it.
                        You can decide what you like:
                        Do you like the skinny AMIGA OS guy,
                        or do you love the fat Unix guy.

                        Pick one of those.

                        But asking for a 200 KG, marathon guy - is just ridiculous

                      • Guest's Avatar
                        Guest commented
                        Editing a comment
                        Ik vraag me af waarom ze daar "tot vervelends toe" naar vragen op het APollo forum ? Wat heeft Gunnar nu van doen met hoe het OS in elkaar zit ? Het heeft weinig te maken met " we doen het niet omdat anders het OS traag wordt " , de vraag - die ondertussen als 20 jaar gesteld wordt zonder resultaat in ELK AmigaOS kamp - is "hoe doen we het of kan het ? ".

                      #13
                      Dan een vraag van mij die al bijna 30 jaar blijft knagen:
                      Toen de virussen welig tierden op de bootblocks was het mijn gewoonte om floppies meteen op write protect te zetten.

                      Maar toch ging begin jaren 90 het gerucht dat er virussen waren die de write protect op floppies konden omzeilen.
                      (ging niet om specifiek Amiga, maar ook om ST en PC floppies)

                      Bangmakerij of een kern van waarheid?

                      Comment


                        #14
                        Originally posted by PMS View Post
                        Dan een vraag van mij die al bijna 30 jaar blijft knagen:
                        Toen de virussen welig tierden op de bootblocks was het mijn gewoonte om floppies meteen op write protect te zetten.

                        Maar toch ging begin jaren 90 het gerucht dat er virussen waren die de write protect op floppies konden omzeilen.
                        (ging niet om specifiek Amiga, maar ook om ST en PC floppies)

                        Bangmakerij of een kern van waarheid?
                        Bangmakerij, want (eerlijk gejat van Quora):

                        On one side of the disk (inside the drive) is a light source, on the other side is a light sensor (iirc infra red is used in there to be less affected by stray light from the slot you put the disk in).
                        If the sensor can “see" the light it considers the disk read-only and sets pin 24 on the interface to logic 0 (assuming I'm reading my old spec sheet correctly, could be the opposite).
                        It's a wonder tall trees ain't layin' down

                        Comment


                          #15
                          Wat Rene zegt. Er waren ook virussen die zogenaamd je monitor of harddisk konden opblazen.

                          Comment

                          Working...
                          X