Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

30 Jaar Commodore Amiga - De invloed van de eerste multimediacomputer

Door , 293 reacties

We ondervinden wat problemen met ons videoplatform. Daardoor doen alleen de 720p- en 1080p-versie het goed. Voor de 270p- en 360p-versie voor mobiele apparaten klik je hier.

Het is deze maand dertig jaar geleden dat de eerste Amiga uitkwam: de Commodore Amiga 1000. De introductie was spectaculair en werd opgeluisterd door kunstenaar Andy Warhol en zangeres Debby Harry. Hoewel de Amiga nooit zo populair werd als de Commodore 64, koesteren veel gebruikers nog altijd warme herinneringen aan de homecomputer. De Amiga 1000 zorgde voor een flinke technische stap vooruit, op zowel grafisch vlak en audiogebied als wat multitasking betreft.

Tijdens een evenement in Amsterdam ter ere van het dertigjarig bestaan van de Amiga, ondervroegen we enkele oudgedienden wat de Amiga zo speciaal maakte. De val van Commodore wordt over het algemeen toegeschreven aan mismanagement en slechte marketing, maar de oud-medewerkers geven aan dat er ook andere factoren, zoals op software- en hardwaregebied aan te wijzen zijn.

Onder andere RJ Mical komt aan het woord, die destijds leiding gaf aan de software-tak van Commodore. Ook Dave Haynie blikt terug. Hij had in de nadagen van Commodore de technische leiding en wilde met geavanceerde technologie de voorsprong van de Amiga ten opzichte van de pc behouden. Niet alleen op gebied van multitasking en foto- en video-editing speelde de Amiga een belangrijke rol, maar vooral ook bij games. We spreken met de bedenker van een van de populairste games op de Amiga, Lemmings, die ook de basis van GTA bedacht. Over de muziek bij de games geeft Allister Brimble zijn mening, hij componeerde onder andere voor Alien Breed en Project X.

Reacties (293)

Wijzig sortering
Zelf voelde ik mij in die tijd meer aangetrokken tot de Atari ST. Terecht of niet, haar gestoken zwart wit beeldscherm sprak mij toen aan, Apple Macintosh like. Als OS had de Atari TOS, Nick named als Tramiel operating system, genoemd naar Jack Tramiel de geÔnspireerde leider van Atari van dat moment. Achtereenvolgens heb ik een 260ST, een 520ST en een 1040ST gehad, die laatste was een apotheose apparaat met een hard disk van wel 20 Megabyte. Die laatste is verkocht, een van de andere twee heb ik nog met het plan haar uit de doos te halen en weer op te stellen.

Rond 1985 verkeerden Commodore en Atari in een stevige concurrentie met elkaar. De merken hadden echter meer met elkaar gemeen dan je op het eerste gezicht zou aannemen. Een smeuÔge blog is hierover is hier te vinden. Tramiel maakte in 1984 een transfer van Commodore naar Atari. Zijn kennis van de Amiga heeft zeker de ST beÔnvloedt. Maar Amiga is zelf ook niet altijd Commodore geweest. Commodore heeft Amiga Corporation opgekocht. Amiga Corporation was in 1992 opgericht door Jay Miner, nadat die was weggelopen bij.... Atari.... Jay Miner is mede verantwoordelijk geweest voor de iconische Atari 400 en 800 gamecomputers.

Commodore kocht niet voor niets deze Amiga Corporation op, waarmee ze de chipset van dit bedrijf bemachtigde. Zelf zat Commodore in een inspiratie dipje, na de 64 had het bedrijf een opvolger nodig en kwam met Commodore 128, haar laatste 8 bits computer. Op zich was de C128 een pracht apparaat, met twee processors (MOS 8502 en een Zilog Z80A). Het apparaat was in alle opzichten een sprong vooruit ten opzichte van de Commodore 64. Fascinerend is dat door vertragingen deze C128 gelijk werd uitgebracht met de Amiga 500. Productie technisch was ze weinig goedkoper als de Amiga, maar bracht door haar positionering maar de helft op van de Amiga. Hoe technisch mooi ze ook was, was de 128 toen al een computer van gisteren. In die zin zegt het veel over het toenmalige Commodore management dat het niet haar onverdeelde focus op de Amiga lijn richtte, wat achteraf bekeken meer effectief was geweest.

En dan Commodore versus Atari....Om deze thread niet te laten vervallen een een welles nietes tussen de fan boys (ehhmm.... boys?... 40+) van beide merken wil ik het belang aanstippen van deze computers. Gemeenschappelijke factor was het gebruik van een grafische user interface (GUI). ST en Amiga vormen samen met de Macintosh van Apple boodschappers om een andere interface tussen computer en mens te propageren. Toen deze computers midden jaren '80 de markt bestormden doorliep MS-DOS de versies 2.1 - 3.1. MS-DOS was uitermate betrouwbaar, maar wat saai, dus prima voor het bedrijfsleven van dat moment. Met allerlei customisaties als snelstartmenu's was MS DOS ook adequaat om de tot 10 verschillende bedrijfsapplicaties op te starten. De oplossing was binnen dit kader zeker snel en effectief: "Grafische interface, nergens voor nodig, allemaal winderigheid". In 1983 had MS-DOS nog 10 jaar van ontwikkeling te gaan tot haar finale uberversie 6.1, die in 1993 uitkwam.

Met andere woorden, na de steen in de vijver van Apple, Commodore en Atari duurde het nog 10 jaar voordat met Windows 3.11 echt een kantelpunt ontstond dat ook voor PC-gebruikers een grafische gebruikersinterface als alternatief bestond. In 1990 was Microsoft wel met Windows 3.0 begonnen, gevolgd door Windows 3.1 in 1992. Beide voorgangers overtuigden nog niet echt en werden daarom nog gratis aan het publiek aangeboden. Met Windows 95 kwam Microsoft tenslotte met een echt overtuigend op een GUI gebaseerd OS dat ook innovatief was. Waarom heeft die acceptatie zo lang geduurd? Amiga en ST waren af te doen als home computers, niet te vergelijken met "serieuze" bedrijfscomputers. Apple had daarentegen wel degelijk de pretentie het computerend bedrijfsleven te innoveren. Dat alles wat Apple aanraakt in goud veranderd ging in dit geval niet op. Microsoft behield heel lang met MS-DOS de hegemonie, en pas toen dit bedrijf er rijp voor was werd de switch naar een GUI gemaakt. Dit is niet alleen Microsoft te verwijten. Het publiek stelde haar hiertoe in de gelegenheid, als dat massaal Macintoshes, Amiga's en ST's was gaan kopen had Microsoft wel versneld. Het publiek was ook nog niet rijp voor de verandering. Vanuit deze optiek was het 16bits GUI drietal hun tijd zeker een decennium vooruit.

[Reactie gewijzigd door teacup op 19 juli 2015 14:46]

Terecht of niet, haar gestoken zwart wit beeldscherm sprak mij toen aan, Apple Macintosh like. Als OS had de Atari TOS, Nick named als Tramiel operating system, genoemd naar Jack Tramiel de geÔnspireerde leider van Atari van dat moment.
De Atari ST werd daarom ook wel de 'Jackintosh' genoemd.
Prachtig, die kende ik nog niet. Mijn vermoeden is wel dat de man een beetje op een schild is geheven. Maar voor dit soort klussen heb je zo'n massieve kartrekker wel nodig die met zijn rauwe energie het maken van zo'n GUI homecomputer realiteit maakt. Een klus die best bijzonder was omdat op dat moment een Home Macintosh niet bestond, en zeker niet voor het budget wat voor die homecomputers beschikbaar was. Een Macintosh was in 1984 2500 dollar!! Ik kan mij herinneren dat ik toentertijd in een Kijk (pop. wetenschappelijk maandblad) een artikel over de Macintosh zag en toen dat ding als een onbereikbaar ideaal zag. Dat moet voor 1984 zijn geweest, de Macintosh was er toen nog niet.

Hoe belangrijk Tramiel ook is geweest, laten we toch ook de invloed van de ontwerpers niet uitvlakken. Tramiel was een boegbeeld, maar kon niet bestaan zonder de ontwerpers die de computers vorm gaven, en ook op het vlak van visie speelt de man leentjebuur bij zijn ontwerpers. Zij bedenken, hij communiceert, zendt, te boodschap alsof hij hem zelf heeft verzonnen, via een versterkertrap de wereld in. Dit is ook helemaal niet erg, zo heeft ieder zijn rol. Mensen als die Jay Miner zijn waarschijnlijk meer geestelijk vader van het IP van en de Amiga en eigenlijk indirect ook van de ST.

Hoe langer ik zelf werk hoe meer ik erachter ben gekomen dat dit soort ontwikkelingen bijna meer met mensen te maken hebben, dan met organisaties. Mensen hebben de visie, ideeŽn (Miner) of het momentum (Tramiel) om iets te bewerkstelligen. Toevallig bevinden ze zich samen op een zeker moment in de tijd in organisatie A of B, en dan, in dat kostbare moment zij de randvoorwaarden allemaal aanwezig en produceren ze iets schitterends. Tijd, ideeŽn, budgetten (organisatie) komen toevallig op het goede moment samen. Kijken we hypothetisch twee jaar verder, zet diezelfde mensen in diezelfde organisatie bij elkaar en er gebeurt niets.... De werkelijkheid en setting kan dan een hele andere zijn. Die bijzondere homecomputers uit de jaren '80 waren vanuit deze optiek echt iets bijzonders. Het feit dat we het 30 jaar na dato nog steeds over die dingen hebben zegt op zich ook al veel ;) .

Edit: Typo's

[Reactie gewijzigd door teacup op 20 juli 2015 17:11]

Tramiel stond er vooral om bekend dat hij iedere cent van het ontwerp probeerde af te schaven. Hierdoor heeft hij de VIC-20 en de C64 veel goedkoper kunnen krijgen dan de concurrentie, wat leidde tot gigantische verkoopsuccessen.

Bij de ST zette hij wederom in op minimale kosten, maar ook minimale ontwikkeltijd. Hij wilde koste wat kost eerder op de markt zijn dan de Amiga.
Hierdoor zijn helaas wat features van de ST gesneuveld, waaronder de audio-chip. Men viel terug op de matige AY-3-8910, die eigenlijk nog minder klonk dan de betere 8-bit computers, zoals de C64.
Maargoed, de ST was inderdaad eerder op de markt, en was ook zeer goedkoop voor het gebodene. Hierdoor heeft de Amiga het vooral in de begintijd lastig gehad met de ST. Veel software was in eerste instantie geschreven voor de ST, en werd daarna naar de Amiga geport, waarbij de extra features van de Amiga niet benut werden. Omdat de Atari ook nog eens op 8 MHz was geklokt, en de Amiga op 7 MHz, leek de ST in de praktijk soms zelfs de betere van de twee.
LEEK de St de betere. De praktijk (en dat is waar het om draait) was dat zelden zo.
De ST ontbeerde gewoon de vele dedicated chips en de enorme flexibiliteit die de Amiga had.
Uiteindelijk was de ST enkelt de betere voor wat Midi zaken en mischien wat zwart/wit high res DTP en dat was het.

Been there, done that !
Dat Windows pas met de 95-versie goed werd had met Intel te maken die haar cpu's een nieuwe modus moest geven.
Motorola-cpu's leende zich veel beter voor een GUI.
Da's niet waar. Windows 95 heeft niet meer dan een 386 nodig, en die werd al in 1985 gelanceerd.
Windows 95 heeft een 486 nodig voor de installatie. Daarna kan je de hdd wel terugzetten naar een 386 en draait het nogsteeds maar de installatie draait niet op een 386. ;)
Is dat zo?
Volgens Microsoft is een 386 namelijk genoeg: https://support.microsoft.com/en-us/kb/138349
Wel met de opmerking http://technet.microsoft.com/en-us/library/cc751081.aspx: "You cannot install Windows 95 on a 80386 computer that has a B-step processor (that is, with ID 0303)"
Ik meen dat ik het ooit succesvol op een 386SX-16 heb geinstalleerd :)

Win98 heeft blijkbaar wel een installer die 486+ is, maar daarna terugzetten in een 386 werkt: http://winhistory.de/more/386/386vers.htm

[Reactie gewijzigd door Scalibq op 21 juli 2015 13:36]

Dat heb ik wel eens gedaan. Maar hij had al moeite op de clock snel genoeg te refreshen.
...en als eerste verkocht in een Compaq met een adviesprijs vanaf $6.500,-

Niet de prijsstelling voor een 'home'-computer dunkt mij.
In 1995 had iedereen al een 486 of Pentium, en was een 386 niks meer waard.
Dat Windows pas met de 95-versie goed werd...
Goed? Ik herinner me Win95 vooral als het ideale malwareplatform. Zoals honderdduizenden criminelen ontdekten. Zoals het automatisch stiekum bellen naar 0900-nummers.
...
Op zich was de C128 een pracht apparaat, met twee processors (MOS 8502 en een Zilog Z80A). Het apparaat was in alle opzichten een sprong vooruit ten opzichte van de Commodore 64. Fascinerend is dat door vertragingen deze C128 gelijk werd uitgebracht met de Amiga 500.
De Amiga 1000 kwam uit in 1985, de A500 pas uit in 1987.
De C128 kwam ook uit in 1985, dat wordt zelfs genoemd in het artikel waarnaar je verwijst.
Yep, my wrong, ik heb het zelf nota bene gelezen. Ik moet zeggen dat het verhaal eromheen trouwens behoorlijk vaag was. Heb een moment in twijfel gestaan of de C128 nu was omgedoopt tot Amiga 1000, maar het bleken toch wel degelijk verschillende computers te zijn. Vermoedelijk was het toenmalige management ook flink in verwarring over welke koers te varen en wilden ze een moment de C128 laten meevaren op de Amiga naam.
Op zich prachtig, en de Z80A was om CP/M software te draaien, maar volgens mij werd dat minimaal benut omdat CP/M gebruikers al lang en breed op de 8088 / 86 / 286 waren overgestapt. Waarom ze dat ding hebben ingebouwd is mij dus een raadsel.

Volgens mij zat er ook een 6510 voor de C64 software. Of was dat de 8502 in emulation mode?
Microsoft behield heel lang met MS-DOS de hegemonie, en pas toen dit bedrijf er rijp voor was werd de switch naar een GUI gemaakt. Dit is niet alleen Microsoft te verwijten. Het publiek stelde haar hiertoe in de gelegenheid, als dat massaal Macintoshes, Amiga's en ST's was gaan kopen had Microsoft wel versneld. Het publiek was ook nog niet rijp voor de verandering. Vanuit deze optiek was het 16bits GUI drietal hun tijd zeker een decennium vooruit.
De hoofdreden was dat voor MS-DOS bergen "illegale" software te krijgen was. Ook bij bedrijven werd volop illegale software gekopieerd en gebruikt. Downloaden was op dat moment nog geen optie omdat het erg duur was via een inbel verbinding (BBS) internet bestond voor de gemiddelde burger niet/zo goed als niet.
Voor de Atari ST en de Amiga 500 was er anders ook zat te krijgen. Ik en mijn vrienden gingen bijna iedere maand naar een game kopieerboer die gewoon met een advertentie in de krant of de Via Via stond, om vervolgens met een stuk of 40 diskettes vol met games terug te komen. En vervolgens die dan zelf weer met X-Copy kopiŽren om ze weer te ruilen met mensen die weer andere games hadden. Soms zat je dan gewoon een hele middag te kopiŽren... ;)
Ja, was ook nog eens erg gezellig. Tussendoor uitproberen..
Precies. Good times... ;)
Zoals VHS het van Betamax en VCC gewonnen heeft omdat het de enige videoband was waarop porno uitgebracht mocht worden.

Vergelijkbare situatie.
Zoals VHS het van Betamax en VCC gewonnen heeft omdat het de enige videoband was waarop porno uitgebracht mocht worden.

Vergelijkbare situatie.
Ware het niet dat het een broodje aap is dat porno alleen op VHS mocht worden uitgebracht.
Dat niet alleen, VHS banden waren ook simpeler/goedkoper en VHS vroeg veel minder royalties dan Sony, waardoor alle andere electronica fabrikanten massaal VHS spelers gingen produceren. Video 2000 van Philips was gewoon te laat, dat kwam pas op de markt toen VHS al lang en breed dominant was.
Je had ook wel een ontzettend dure computer nodig om win3.x een beetje goed te laten draaien. Daarnaast was er weinig voor win3.x. Ja, MsOffice, maar wie gebruikte nou MsOffice? We zaten massaal op WordPerfect.

Bovendien was de muis er voor Day of the Tenticle. Daar ga ik met je mee. Het was er niet voor serieuzer werk. (SAP!)

WordPerfect 5.1 en DBase 3. Een muis? Ben je gek!

[Reactie gewijzigd door dvanmaanen op 20 juli 2015 21:01]

Leuk stukje!
Een stukje paradijs op aarde. Vooral in nostalgische zin.

Bedankt voor de report. Erg leuk om te zien en horen wie achter de ontwikkeling zat. Legendes zoals Allister Brimble aan het woord laat me meteen verwant voelen.

De Amiga ervaring is voor mij echt gigantisch geweest. Ik was 12 toen mijn ouders beslisten dat een geavanceerdere opvolger van de C64 goed voor mijn toekomst zou zijn 8)7 Ik kreeg mijn eerste (met potdomme duits toetsenbord!) in '88 en rammelde vre-se-lijk hard door tot ongeveer '92. Behoorlijk wat games en demo's zijn simpelweg op net- en hoornvlies gebrand en hoeveel interesanter die waren als school en huiswerk is nauwelijks uit te drukken. Locale ''computerclubs'' ofwel meets bezoeken variŽrend van 5 tot 150 man om op flinke schaal te piraten en broodjes frikandel weg te werken hadden de voetbal zaterdag of zondag al snel vervangen. Gamen was mijn ding maar nog meer was het de demo-scene die me enorm intrigeerde. De producties, met name muziek had mijn interesse en de legendarische groepen met hun artiesten die erachter zaten. Was er iets nieuws uit van ik noem een Phenomena, Cryptoburners, Rebels, Red Sector, Anarchy of zoveel anderen dan werd het tot in den treure afgedraaid. Ook crack intro's waren interessant en werden steeds mooier en kleiner. Skid Row, Quartex en Angels is maar een handjevol die ik me goed herinner die heel hard piraten toendertijd.

De meeste tijd bracht ik nog door met sound/noise tracker zoals je die ook ziet rond 9:00. Wel de caps-lock roze variant haha. Hoeveel uren ik heb doorgebracht met alleen al het kijken naar hoe de meesters het deden?

Wat een tijd. Geen woorden.. _/-\o_

PS: BBS-sje @2400 baud inbellen anyone?

[Reactie gewijzigd door croiky op 19 juli 2015 10:14]

Ik heb ook het idee dat er toen veel beter en effiecenter geprogrammeerd werd. Het maximale werd uit de beperkte hardware gehaald. Zo wist Chris Heulsback (muziek van oa Turrican, R-type, Epidia) software matig 3 geluidskanalen aan de Amiga toe te voegen, waar de Amiga maar 4 (hardware matige) kanalen ondersteunt. Door 4 kanalen door de cpu te laten afhandelen en door het eerste geluidskanaal te sturen, bleven er nog 3 hardware matige kanalen over. De intro muziek van Turrican 2 maakt hier gebruik van. Knap staaltje programmeer werk en creativiteit IMHO.

Verder ben ik ook nog steeds verbaasd wat er op of twee diskettes 'geperst' werd. Bijvoorbeeld Powermonger en Elite. Twee gigantische spellen enkel op 1 of twee diskettes.

[Reactie gewijzigd door shredder op 19 juli 2015 12:58]

Dat niveau van programmeren bestaat nog steeds, maar eigenlijk alleen op de consoles. Echter er zijn nog maar weinig mensen die dat kunnen, dat kan niet met iets als Java of .NET. Het is af en toe gewoon bizar hoe groot eenvoudige applicaties zijn, en hoeveel belachelijk veel geheugen ze gebruiken. Maar Intel, AMD en geheugenfabrikanten vinden dat geen probleem :)
dat komt omdat men vroeger voor 1 machine kon programmeren die overal dezelfde hardware had..

bv voor de gfx is dat erg belangrijk welke functies en registers men aanspreekt... stel je voor dat men dit vandaag ook zou doen; hardware rechtstreeks programmeren... dan zou die demo enkel werken op de hardware waarvoor die geprogrammeerd is, zijnde een amd OF intel OF nVidia chip (en naargelang de gebruikte functies moet deze van een bepaalde generatie of nieuwer zijn)... De oplossing hiervoor is gebruik maken van een interface die de vertaalslag maakt van functie naar hardwaretaal op eender welke onderliggende hardware; en daarvoor hebben we voor video 2 interfaces beschikbaar; Direct3D (onderdeel van directx en dus winonly) en OpenGL (multiplatform)
Hetzelfde geldt voor sound, waarbij men op de c64/CPC Amstrad/Amiga/... rechtstreeks de audiochip aanspreekt hebben we nu in de pc's enorm veel varieteit van audiochips; een hele hoop gebruikt onboard realtek en c-media chips maar er bestaan ook nog steeds een hele hoop discrete geluidskaarten van onder andere Creative Labs (soundblaster kaarten), Asus, m-audio, terratec enzomeer.
het spreekt voor zich dat voor de geavanceerde functies bepaalde merken eigen gepatenteerde zaken gebruikt die op een andere kaart niet of op een andere manier werken waardoor ze dus via een interface als directx (dSound om precies te zijn) moeten werken ipv rechtstreeks de hardware aan te spreken.

Uiteraard spreekt het voor zich dat zo'n 'interface' enkele nadelen heeft tov rechtstreeks coden;
1> je verliest performance omwille van de vertaalslag die directx naar je driver doet en welke je driver dus naar je hardware stuurt (= Directx Overhead, bij dx12 kan men rechtstreeks via dx12 naar de videokaart gaan, men slaat de vertaalslag naar driver dus over wat een lagere overhead en hogere performance ZOU moeten opleveren, Mantle leert ons dat dit ZOU moeten zijn en niet persť altijd zo is)
2> het is mogelijk dat bepaalde functies niet beschikbaar zijn omwille van directx te gebruiken; denk bv aan het gebruik van een directx 12 kaart op een windows 7 of vista computer (of directx 9 op een XP); die zal nooit directx 12 krijgen en dus mis je die functies; bij rechtstreeks naar de hardware te coden heb je hier geen last van aangezien je de hardware zelf aanstuurt ipv dat directx dat voor je doet.

bij mac's is het bv eenvoudiger om hardware-coded demo's te schrijven die op veel computers werken dan voor pc; simpelweg omdat een bepaalde mac een jaar lang dezelfde hardware heeft en dus een jaar lang mensen met dezelfde hardware naar huis komen... als een demo dus geschreven wordt op een 15" mbp uit 2013 dan zal die werken op alle mbp 15" model 2013. Dit kan je niet zeggen over bv "een dell latitude 17" ... alleen al binnen die reeks zijn meerdere modellen tegelijk beschikbaar met soms totaal verschillende hardwareplatforms (intel/amd).
1> je verliest performance omwille van de vertaalslag die directx naar je driver doet en welke je driver dus naar je hardware stuurt (= Directx Overhead, bij dx12 kan men rechtstreeks via dx12 naar de videokaart gaan, men slaat de vertaalslag naar driver dus over wat een lagere overhead en hogere performance ZOU moeten opleveren, Mantle leert ons dat dit ZOU moeten zijn en niet persť altijd zo is)
DX12 is nog steeds een hardware-abstractielaag, en je kunt nog steeds niet direct de hardware aanspreken (als dat zo was, zou je nog steeds aparte code moeten schrijven voor Intel, nVidia en AMD, want ze gebruiken verschillende architecturen met verschillende instructiesets etc. Dit itt CPUs waar zowel Intel als AMD de x86-instructieset gebruiken, waar x86 dus in feite de abstractielaag is).
De abstractie is alleen een iets andere vorm dan bij DX10/11, en een deel van de functies van de driver zijn meer naar de applicatie gepusht, zoals resource management.
DX12 heeft dus nog steeds een driver een een vertaalslag.
Als je ziet wat de demo scene in 4k aan assembler weet weg te proppen dan wordt je inderdaad wel even stil

https://www.youtube.com/watch?v=pLr22rq2dz4
Vind het goed dat je dit aanhaalt, zelf heb ik daar ook wel wat over geschreven met name bij website ontwikkeling o.a. Je hebt nu veel programmeurs die verzinnen niet meer zelf, weten hoe ze iets voor elkaar moeten krijgen maar weten niet meer van de hoed en de rand. Dus wat er op een lager niveau gebeurd, dat kennen ze niet. Dus steeds meer modelling en dat levert meer human logic code op maar dat is vaak overhead voor het systeem waarvoor het bedoeld is. Nadenken wat er gebeurd in het systeem/geheugen wanneer bijvoorbeeld een grote array declareert is, dat weten ze niet. Nu is het 'Het werkt toch' goed maar of het efficiŽnt is.....

Ik vind dat ontzettend jammer. Word over het algemeen niet begrepen in het webwereldje omdat ik op een andere manier programmeer. Hoe komt dat, omdat ik een andere achtergrond heb, denk anders na over een vraagstuk en efficiŽntie speelt daarbij een belangrijke rol. Gelukkig kennen ze dat bij google wel, dat efficiŽntie belangrijk is met name op mobile apparaten maar gek genoeg weten weinig programmeurs dat. Wanneer ik het heb over responsetijden, cache-headers, het optimaliseren van code en plaatjes, het terugdringen van server requests en waarom dat goed is (en dat je met dit alles ook kosten kunt besparen) en daar ook wat tools voor gebruik om dat te verbeteren met bijbehorende resultaten dan staan ze te kijken alsof "Jezus over water loopt".

Snellere computers hebben zin maar als daardoor 'slordiger'/ineffectief wordt geprogrammeerd dan neemt het effect van snellere computers ook weer af. Dan krijg je dat je snellere/betere hardware nodig hebt om hetzelfde in geoptimaliseerde vorm te bereiken. Je zou verwachten dat wanneer je nieuwe hardware hebt ťn nieuwe software hebt dat het dan sneller werkt. Dat is in de meeste gevallen niet waar, dat is heel spijtig want de kwaliteit van de software speelt een grote rol in de beleving van de nieuwe hardware. Er valt zoveel te halen met optimaal programmeren, dat zou in eerste instantie geleerd moeten worden.

[Reactie gewijzigd door Erwines op 20 juli 2015 08:13]

Dat is simpelweg een teken van succes van de samenleving. Je gaat ook niet meer op jacht naar je eigen eten, je gaat het gemakzuchtig ophalen in een winkel en veel mensen koken al niet eens meer zelf. Overgewicht en obesitas en toch een lang leven genieten dankzij geneeskunde zijn meer tekenen van dat succes. Het is niet mooi en niet fijn, maar dat terzijde.

Diezelfde vooruitgang zie je ook in software ontwikkeling. Ja tegenwoordig wordt meer gedaan met minder domeinkennis en dat kan allemaal veel sneller met veel minder precisie; een groot succes!

[Reactie gewijzigd door gimbal op 20 juli 2015 13:29]

Je beschrijft het precies, de "who cares, i don't" het-werkt houding. Vergeet niet dat succes niet eindeloos is, niets is eindeloos. Maar als je lang van het succes wil blijven genieten moet je jezelf in blijven zetten voor kwaliteit. Het is net als met stelen, in het begin secuur en oplettend, dan ontstaat het moment van gemakzucht en dan gaat het opvallen. Wanneer het dan teveel gaat opvallen, ja dan ben je het haasje.

Je ziet zodra we succes hebben denken we niet meer te hoeven focussen, niet meer hoeven investeren, dat is echt een vervelende menselijke eigenschap. Daarom zijn er ook maar slechts een 'aantal' die het langdurig volhouden succesvol te zijn en dat is niet door stil te zitten en de focus te verliezen door succes.

Bij programmeren is het precies hetzelfde. Nu wordt vaak een lijst aan kunsjes gevraagd, je moet het kunnen toepassen. Nou, kun je dit en snel heb je werk. Tot het moment dat er andere eisen worden gesteld, wanneer je niet meegaat (daar niet zelf voor zorgt) dan heb je ineens geen werk meer. Kan aantal jaar goed gaan maar kan zomaar afgelopen zijn wanneer je niet alert bent, door succes = door hoeveelheid werk. Programmeren is productie geworden en kwaliteit is ondergeschikt, zichtbaar eindresultaat is belangrijker dan de kwaliteit onder de motorkap, 'zolang het maar werkt', zolang er maar geproduceerd kan worden. Een wegwerp product.

Hoe vaak ik al gezien dat een project dat veelal langer gaat bestaan dan gedacht weer helemaal opnieuw moet worden gemaakt, dat is niet meer op twee handen te tellen, heel veel dus. Traag, fouten in de software echt omdat er geen tijd is voor kwaliteit, het gaat om productie. Niet verder kijken dan je neus lang is dus, succes op kort termijn voor een kort termijn.

Kwaliteit is ondergeschikt aan commercieel belang, stoor mij hier ontzettend aan. Het gaat niet meer om programmeren, het is een truukje, programmeur is eenheidsworst, je hoeft niet meer te kunnen dan het truukje en nadenken tot in de kern is niet gewenst want het werkt toch? Domme ontwikkeling, neemt de uitdaging weg, niet interessant.

[Reactie gewijzigd door Erwines op 20 juli 2015 19:52]

Nostalgie... De trots die ik voelde toen ik met mijn jonge leeftijd wel 1200 gulden uitgaf voor een HST modem (14K4, factor 15.000 keer langzamer dan wat ik nu heb), neusje van de zalm. Eindelijk niet meer aanhikken tegen de 230cps (karakters per seconde) die de 2400baud me gaf.
Maar nog steeds zat ik de hele avond 'online' en kon niemand mijn moeder bereiken per telefoon. 'Mam, niet bellen nu, ik ben zo klaar'.... Not.

Hoe ik op een Duits BBS de Red Sector Demo Maker vond en importeerde naar NL, die hier verspreide en spontaan eventjes beroemd werd daardoor, enkel vanwege die ene zogenaamde 0-Day warez.

Mijn Tracker modules heb ik nog allemaal en geven mij nog zo veel plezier met die 4 kanaals plingeltjes. Cybernoid, Commando, Green Beret, Monty on the run! en natuurlijk Turrican!

(Zie ook YouTube voor moderne varianten van deze classics)
Het HST modem met snelheden van 14.4 en 19.2 was het summum als ik het goed herinner. Een US Robotics was er ook een om na te streven maar nadat ik thuis de telefoon rekening omhoog had gejaagd moest ik mijn 2400'er verkopen en dat was meteen het einde van de BBS fun. Heel herkenbaar wat je zegt over de telefoonlijn bezetten. Ze vonden het maar niks :)

Heb sinds jaar en dag een archiefje van zo'n 200 favoriete tracker modules waarvan ik het merendeel kan dromen en zeker graag nog eens op zet. Ook wat ''exotisch'' werk waaronder Future Composer, Hippel, Oktalyzer, TFMX formaten etc.

Hier wat favoriete tunes:

Red Sector/Tristar
Agile
The Company/Vision Factory
Paradox

En deze. Misschien de epitoom uit cracktro tunes. Heel indrukwekkend.
https://www.youtube.com/watch?v=PSwgZ7wGus0

Of meteen maar een paar uurtjes terug in de tijd?
Vergeet Giana Sisters niet met de track van OMD (Enola Gay)!!
I love Giana Sisters! Hoe kon ik deze vergeten...
En Rick Dangerous 8-)
http://rickdangerousflash.free.fr

[Reactie gewijzigd door nexhil op 20 juli 2015 08:50]

niet voor niets de besten ... quasi allemaal belgische intro's/demo's ....
wij waren op dat moment ook de uitvinders van de huidige dancescene met onze talloze discotheken die elke week volzaten en die eigenlijk dezelfde muziek draaien (instrumental, synth)

als jonge kerel was ik ook verknocht aan hoe goed sommige intro's / demo's hun muziek klonk... zelfs op de c64 die ik toen had...
Ik blijf de muziek van Last Ninja ontzettend vet vinden. Dat heeft toen zo'n indruk gemaakt!

https://www.youtube.com/watch?v=CWmqoEdjKR4
Geweldig omschreven. Ging bij mijn ouders precies zo.... :*) Ik heb mijn Amiga500 met HDD van 40 MB nog steeds staan en werkt perfect.
Dat was dan denk ik een A500+ of een A500 die gepimped is, naar mijn weten had de kickstart (en bijbehorende workbench) van de originele Amiga 500 geen ondersteuning voor het mounten van een HDD.
Jawel hoor, WB1.3 ondersteunde prima een externe schijf ala type A590.
JA, ik heb heb er zelfs 2 waar de ťťn kickstart 1.2 en de ander 1.3 heeft. Maar die HDD werkt prima. Maar heb in die 1.3 wel een geheugenuitbreiding met schakelaar, zodat ook andere programma's die "zoveel" geheugen niet aan kunnen, toch kunnen werken. 8)7
Het eerste waaraan ik dacht was zelfs nog een stapje verder terug dan het inbellen via de telefoonlijn, Packet Radio (AX25/PR). De tijd waarin bij ontzettend veel woningen nog de welbekende antenne's aan de gevels bevestigd waren en spraak via CBRadio (27Mc) al uit begon te raken en data op 300Bps in opmars raakte. Te danken aan de zendamateurs die dit al langer deden via de 2 meter band (144-145Mhz) en 70cm band (430-440MHz).

Later kwamen meer en meer toegangspoorten tot BBS'n en maakte Nederland al niet veel later kennis met het grootste hufterbedrijf genaamd CompuServe (met een uitgemolken (tot wat men nu) internet verbinding (noemt) :/ )
Packet radio werd gedaan op 1200 bps, zeker in de tijd dat het populair was op 27Mc. (Alhoewel de effectieve snelheid natuurlijk veel lager was door de lange TXDelay, hoge packet loss en half-duplex eigenschappen van het protocol). Ik heb de computer wel eens een hele nacht aan gehad om 1 MB te downloaden, het was veel sneller geweest om 10km te fietsen met een floppy :). Ik had zelf ook het typische BayCom modem van die tijd.

Volgens mij is voor packet op CB/27Mhz nooit een populaire 300 baud methode geweest, alleen voor op de lagere HF banden.

Edit: Grappige is trouwens dat 1200 Baud Packet radio nog steeds best veel gebruikt wordt. Ik ben zelf zendamateur tegenwoordig en ik gebruik het regelmatig. Het wordt niet veel meer gebruikt om met BBS'en te verbinden of te chatten zoals vroeger, maar wel voor korte positierapporten, APRS genaamd. Er is een wereldwijde infrastructuur om deze door te geven (zie aprs.fi voor het resultaat. Zelfs op het ISS hangt een APRS node. De meeste APRS apparatuur kan ook 9600 baud maar 1200 komt nog steeds het meeste voor.

Ik vind het wel grappig om te zien hoe voor zo'n oude techniek nog steeds toepassingen worden gevonden.

[Reactie gewijzigd door GekkePrutser op 20 juli 2015 01:04]

Dat had ik zelfs ook gehad van dat we in deze tijd moesten doen met internet via telefoonlijn. Wat ons ook voor torenhoge telefoonrekening heeft gezorgd hoe lang we online aan het internetten waren. Modems waren in deze tijd best wel erg duur en op een andere moment waren ze nog niet in veelvuldig gebruik genomen door de massa. En dan heb je ook te maken wat het ook met haperende snelheid van verbinding over de telefoonlijn.
Prachtig omchreven, was bij mij allemaal een beetje weggezakt. Thanks voor het ophalen van al die mooie herinneringen.

Nog steeds mijn oude Amiga500 met een shitload aan diskettes, in een niet-al-te-droge schuur staan. Sluit hem om de zoveel jaar even aan, om te kijken of hij het nog doet. En verrek... telkens weer O+
Ik heb oprecht spijt dat ik alles heb weggedaan. Niet zo zeer vanwege de software zelf maar vanwege de diskettes, de volgorde, de kleuren, de bakken, de manier van opschrijven, de stickers en waar ze zaten en de indeling... Dat verzamelen en beheren, die collectie gaf een directe link met het verleden en ik zie nog voor me; het bureau met in de onderste lade de 5,25" floppies waar linksvoor de leuke zaten en linksachter een mindere sectie...

Ach.. verleden, waarom al die drukte om met de toekomst bezig te zijn als aan het verleden denken je zoveel genot geeft.

[Reactie gewijzigd door Tijgert op 19 juli 2015 12:37]

Ik heb mijn eerste serieuze computer (Commodore 64) nog, inclusief alle floppies. Helaas is er geen enkele floppy meer leesbaar. Wel erg jammer, want er staan programma's op die ik bijna 30 jaar geleden heb geprogrammeerd.

De beste was nog wel hartenjagen. Aangezien de computer ook de kaarten uitdeelde, wist die precies wat je in de hand had. Winnen was dan ook vrijwel onmogelijk :)
Dat geen enkele floppy leesbaar is kan ook aan je diskdrive liggen, dus niet alles wegdonderen :). Heb je meerdere diskdrives geprobeerd?
Dit inderdaad. Diskettes gaan eigenlijk belachelijk lang mee. De diskdrives van de C64, vooral het oudere model de 1541 (dus niet de 1541-II) had nog wel eens head alignment nodig om goed te blijven werken. Zal denk ik dus eerder aan de drive liggen dan aan de diskettes zelf.

Heb zelf jarenlang de C64 gehad (en sinds een paar jaar weer 1 in bezit :P ) en daarna overgegaan op PC en Atari ST die veel toffere spellen in kleur had dan die suffe monochrome pc spelletjes van toen . Ook het OS van de ST vond ik intuitiever werken ook al kon het in essentie minder.

Als je iemand nu achter een ST of Amiga zet dan kan de gemiddelde persoon veel sneller werken met TOS dan met workbench. Workbench kon echter meer (mutlitasking bv al kan dat tegenwoordig in TOS ook met multiTOS )

De amiga had wel betere graphics en geluid maar voor bv officeapplicaties vond ik de ST weer beter en niet te vergeten: Voor midi toepassingen was (en is) de ST nog altijd onovertroffen.

Beide machines hadden hun target audience. De ST voor office, games en muziek en de Amiga voor games, multimedia en later zelfs videoediting.

[Reactie gewijzigd door Metro2002 op 20 juli 2015 09:18]

Als je echt wilt kan je dit er vast nog wel van af lezen door een gespecializeerd bedrijf o.i.d.
... sja.. good times... 1x in de maand op zondagmiddag naar Hilversum, alleen maar beeldschermen met XCOPY en een bar waar je naast de frikandellen ook vooral heel veel diskette's en floppy's kon kopen :*) En eens in de zoveel tijd op de zolder een meeting waar met een modem naar een BBS in de VS werd gebeld om de nieuwste games te downloaden... hehehe... toen al }>

Straks maar weer even een rondje langs mijn ouwe 500 en 4000 doen in mijn hobbyhokje, blij dat ik die nog heb om af en toe mee te pielen. Die 4000 heeft een Retina kaart en een VLAB motion van macrosystems. Toendertijd het absolute summum, maar mijn smartphone doet het beter bij wijze van spreken 8)7 Techniek is ver gekomen, maar nooit meer met de sprongen van toen...

[Reactie gewijzigd door involver op 19 juli 2015 19:24]

Ik heb een werkende 500 en 2000 staan.
Niks boven zo af en toe Lemmings in het origineel te spelen :-)

A500: Met A520 (full RAM), KCS V30 PC board, ECS upgrade.
68030 turbo-board (50 Mhz) met 68881 (66 Mhz) en 8 MB Fast-RAM. (Board was een afdankertje op mijn werk. Was eigenlijk voor een 68000 VME bus industriele computer maar dank zij het asynchrone ontwerp werkte dat dus gewoon in een Amiga.)
Een paar GB aan SCSI schijven in een extra behuizing (van een Sparc station).

De A2000 heeft een Picasso board, Ariadne netwerk-card, Apollo 68030 (25 Mhz) met 8 M Fast-Ram, het 286 AT board. en een IDE interface kaart.

Destijds de absolute top.
Nu leuk voor jeugd-sentiment en het museum ...
Mijn 500 zou ook nog moeten werken. Niks uitgebreids, gewoon een 500 met 1MB en floppy drive. Heb toen wel ooit een 4 floppy controller board gebouwd (nagemaakt van een commerciele externe floppy controller; 4 voudig nagemaakt), en daar 2 5.25" en 2 3.5" floppy drives aangehangen :)

Maar goed dat ding ligt in de opslag, samen met nog 2 c64's en een Mitsubishi 32kB MSX computer :)
Ik heb ook ergens op zolder nog een originele Philip VG8020 MSX 1 staan.
Geen idee of hij het nog doet...
Ik moet eerst een archealogische opgraving uitvoeren om hem onder de rest van de zooi terug te vinden :*)
T blijft toch spijtig,.
Commodore was op dit vlak jaren vooruit op de PC - echt jammer.

T enige wat me toch wel tegen zat was die rare nummering.
Eerst een 1000,. en dan is 500 de opvolger - huh? <->
En dan was er 1200,. 600,. etc. was moeilijk te volgen.

[Reactie gewijzigd door bbr op 19 juli 2015 13:35]

De 500 was een beetje het budgetmodel zonder los toetsenbord .e.d. Vandaar de lagere prijs t.o.v. de Amiga 1000
Inderdaad de 500, 500+, 600 en de 1200 behoorde tot de budget/home reeks. De 1000, 2000 en de 3000 behorende tot de duurdere/professionele reeks.
Naar mijn weten was de Atari 520ST eerder dan de Amiga A500 ( juni 1985 vs juli 1985 vlg wiki) dus dan was de Atari toch de eerste multimediacomputer. De beruchte concurrent van Commodore en strijdtoneel van vele "battles"...

[Reactie gewijzigd door bonus op 19 juli 2015 17:08]

Dit klopt volgens mij. De Atari ST was in Europa populair met monochroom scherm met een top resolutie van 640x400 ;-) en de ST met kleurenscherm (standaard resolutie 320x200)meer populair in de VS. De ST had ook een MIDI aansluiting. In de VS kwam de nadruk meer op games te liggen en in Europa werden er meer zakelijke toepassing gedraaid, hier was de ST meer een goedkope kloon van de Mac(Intosh) van Apple.

[Reactie gewijzigd door tinoz op 20 juli 2015 09:04]

Als ik naar mijn vriendenkring in de jaren 80 kijk was we toch echt een scene rondom de ST met kleurenscherm en games. Wellicht niet zo groot als de Amiga, maar zeker groot. Ik had 500+ floppies met compact discs = diskettes met gecomprimeerde games.
Helaas had mijn vader een 1040ST met zwart wit scherm ;-)
Ik was ook rond die leeftijd toen ik mijn eerste Amiga kreeg, iets jongen, de 500 was toen net uit en heb hele jaar gewacht voordat ik hem kreeg, geld bij elkaar gehouden van verjaardag en wat klusjes en zo en ouders hebben toen de rest erbij gelegd. Dat was mijn eerste computer, daarvoor alleen spelcomputers gehad, zoals atari2600 en sega.

Had je er ook een sound sampler bij? Blokje wat je achter in de Amiga moest steken. Daarmee kon je samples opnemen die je dan kon gebruiken in onder andere sound tracker. Heb heel veel muziek gemaakt, house muziek wel te verstaan, heb ik nog tot halverwege jaren 90 gebruikt.

Ging geregeld na beurzen, kon je voor paar gulden een tafel huren waar je dan je Amiga kon aansluiten, we deelde met elkaar de software, illegaal downloaden bestond nog niet. wij moesten fysiek aanwezig zijn om de software te delen met elkaar. :D Voor Robocop 3 had daar iets op bedacht, kreeg bij het spel een soort van dongle die je in de tweede gamepoort moest steken anders werkte het spel niet.

En 512KB RAM uitbreiding was groot blok, helemaal afgeschermd met metaal, en moest je onderin steken. Had je een volle 1MB RAM en kon je alle software draaien. :)
Ik had niet specifiek een sampler maar wel een zogenaamde Action Replay die links aan de zijkant erin ging. Daarmee ripte ik als een malle modules en samples uit demo's om ze in de tracker te krijgen. Had geen besef van dat ik daarmee de makers geen plezier deed :)

Je zegt het. Die beurzen, clubs, meets werden ook wel copy party's genoemd en daar was het veelal om te doen. Nieuwe waren kopiŽren en X-Copy was het programma. Het geluid wat het produceerde na succesvol kopiŽren ken ik zo goed als het Pac-Man ''af'' geluid. Vet haha!
Yup, voor mij is Amiga vooral ook synoniem met demoscene.
Ik had daarvoor al een C64, en was al in aanraking gekomen met cracktros, en hier en daar zelfs al wat vroege demos, oa van 1001 Crew. Maar op de Amiga ging het pas echt los.
Op de C64 programmeerde ik al een beetje in BASIC, en ik had wel iets van assembly geproefd, maar op de Amiga begon ik serieus met programmeren. Met oa AMOS en Blitz Basic, later ook C en asm.
En ik heb van m'n hobby m'n werk gemaakt, en ik maak ook nog steeds demos (al was de laatste op een IBM PC, niet Amiga :)).

Ik was er uiteraard ook bij op deze dag.
Vesuri van Da Jormas had voor deze dag trouwens ook nog Poing gemaakt: https://youtu.be/OK_U9UnZoNs
Als tribuut aan de originele Boing demo.

[Reactie gewijzigd door Scalibq op 19 juli 2015 10:49]

Locale ''computerclubs'' ofwel meets bezoeken variŽrend van 5 tot 150 man om op flinke schaal te piraten en broodjes frikandel weg te werken hadden de voetbal zaterdag of zondag al snel vervangen.
En de hele middag door dat voortdurende pingggg pingggg pingggg van al die schermen met XCopy Pro overal :D

Bij ons stonden die meets ook wel bekend als 'kopieerbeurs' :D
Prachtige tijd.
Ha... Met Allister heb ik ook nog een tijdje samen gewerkt. Ik heb toen de Sound drivers geleverd voor o.a. Alien Breed en de Dizzy serie (fantasy island dizzy, treasure island dizzy etc.). Mijn eerste inkomsten ooit uit software ontwikkeling.

Maar gouden tijden dat, die Amiga tijd.

Amiga Expo, Cebit en dan de Scene parties nadertijd. Een top tijd.

[Reactie gewijzigd door Deathstrike op 20 juli 2015 12:05]

Was echt een geweldige tijd _/-\o_

Swappen van disks, 3M tape iemand :P
Bossche Computer Club iedere maand
Amiga vs Atari ST
Copy parties
Scoopex, Vision, Tristar , Red Sector, Rebels, Spaceballs.
https://www.youtube.com/watch?v=89wq5EoXy-0
BBS-en niet te vergeten, inclusief schreeuwende ouders omdat je je modem aan had laten staan :P

[Reactie gewijzigd door Nosfera7u op 20 juli 2015 11:01]

Mijn C64 heb ik 1984 (was toen 13) van mijn ouders en oma gekregen. In 1990 heb ik met spaargeld een amiga 500 gekocht.
Naast dat de Amiga (en in mindere mate de Atari ST) multimedia computers waren voordat multimedia computers uberhaupt bestonden is de Amiga uiteraard ook goed gekend van de scene. Door de open architectuur (Geen API's of wrappers, maar gewoon direct met de hardware praten) werden er al gauw visuele en technische hoogstandjes bedacht welke tot op de dag van vandaag voortduren. Een kleine greep uit mijn persoonlijke favorieten:

Hardknee Lotus by Dekadence: http://www.pouet.net/prod.php?which=51161 en https://www.youtube.com/watch?v=MiK-2HebRD0 - Wie had gedacht dat je Amiga 500 PSX achtige graphics op het beeld kon toveren? (Oke, je hebt iets meer geheugen nodig dan de meeste A500's hebben, maar toch. Met afstand de meest indrukwekkende 3D texturemap implementatie die ik heb gezien voor OCS/ECS hardware)

Rink A Dink: Redux by Lemon. - http://www.pouet.net/prod.php?which=61182 en https://www.youtube.com/watch?v=7cOjC-nhs_o - Wie zegt dat alleen oude demos fantastische copper effecten kunnen laten zien? Wil je een effectenvuurwerk, dan is deze demo voor jou.

Desert Dream by Kefrens - http://www.pouet.net/prod.php?which=1483 en https://www.youtube.com/watch?v=jziQBWQxvok - Een echte classic, met een ronduit fantastische soundtrack van Laxity. En ook nog eens een demo met een verhaal erin. Alleen al vanwege de muziek een tijdloos stuk kunst.

Naast Amiga 500 had je ook de Amiga 1200 met diens AGA chipset. En ook daar zijn vele kunststukjes op verschenen. Ook hier een paar persoonlijke favorieten:

Lapsuus by Maturefurk - http://www.pouet.net/prod.php?which=3284 - http://www.youtube.com/watch?v=ikED1OxWmsM - Qua visuals noem ik deze de absolute nummer 1. De demo's hieronder zijn weliswaar veel constanter, maar Lapsuus (Gemaakt door Futuremark ontwikkelaars, hence the naam) toont dingen die je eerder verwacht bij PC's met pixel/vertex shaders. Bumpmapping, water effecten, postprocessing en zelfs realtime sunshafts op hardware (Vrijwel elke highend AGA demo is gemaakt voor een 68060 accelerator met 64 MB ram, Lapsuus echter niet!) die vergelijkbaar is met een 486/Pentium zonder noemenswaardige 3d acceleratie. Was er maar een shooter met dergelijke graphics op de Amiga..

Human Traffic by Ghostown & Loonies - http://www.pouet.net/prod.php?which=56883 en https://www.youtube.com/watch?v=QzBW2MQu9YA - Fantastische 2D graphics en heerlijke soundtrack. We Are Just Machines!

Starstruck by The Black Lotus - http://www.pouet.net/prod.php?which=25778 en https://www.youtube.com/watch?v=bBzdPtJumEE - The Black Lotus bestaat o.a uit medewerkers die bij DICE aan de Frostbite 3 tech werken. Niet zo wonderlijk dus dat vrijwel al hun producties 3D vuurwerken zijn. Starstruck is daarbij hun meest gewaardeerde demo op Pouet, en met reden. Een ongeloofelijk solide productie die de Amiga hardware in al zijn facetten laat zien.

We Come In Peace by Elude - http://www.pouet.net/prod.php?which=54648 en http://www.youtube.com/watch?v=k_2P31K9mRs - Hoewel The Black Lotus jarenlang de alleenheerser was op het gebied van AGA demo's, verdwenen zij na 2008 uit het beeld. (Inmiddels hebben ze vorig jaar weer een nieuwe demo uitgebracht, check Rift). In de tussentijd was Elude een sterke concurrent. Verwacht hier dus ook veel 3D flyby's. We Come In Peace is maar 1 van de vele Elude demo's, en hun recentere werk is misschien wel meer indrukwekkend (Individuele particles dmv voxel rendering anyone?) daar ze heel goed moderne graphics technieken weten te reproduceren op ronduit antieke hardware. We Come In Peace toont prachtige 3D rendering en meer.

Uiteraard zijn er veel meer van zulke demos te vinden op Pouet, stel dus dan ook je eigen lijstje samen en ontdek een kant van computer programmeren zoals je dat niet vaak ziet :)

Afsluitende met een heuse Amiga game die helaas weinig aandacht heeft gekregen in de pers. Oxyron was, naast een demogroep, ook een maker van spellen. Aangezien zij alles weten van de Amiga hardware kwamen zij met een game die eens moest laten zien wat het kon. Trapped 2 is het resultaat: - https://www.youtube.com/watch?v=-05s0UaMxoU - Een volledige 3D RPG met dynamic lighting die op allerlei configuraties uit de tijd werkte (Van een 68060 tot een 68020, waardoor het zelfs speelbaar zou kunnen zijn op de CD32, de Amiga console). Visueel stelt het vandaag de dag niet zoveel voor maar vooral de special effects waren en zijn nog steeds erg bijzonder. Voor een game uit 1997 zonder 3D acceleratie zeer indrukwekkend!
Voor mij is DE Amiga-demo Enigma van Phenomena: https://youtu.be/iGpU3DicbLQ
Deze draaide destijds ook vaak in computerwinkels, en als je dan die graphics zag en die muziek hoorde, dan dacht je echt: "Wat is dit!?"
Toen kreeg een vriend van mij een Amiga 500, en toen zag ik daar die demo ook op, en nog meer demos en games, en ik wist dat ik een Amiga moest hebben.

Over games door Amiga sceners gesproken...
Pinball Dreams: https://www.youtube.com/watch?v=6UNGMiPETXo
Dit was de Zweedse tak van demogroep The Silents, die deze game hebben ontwikkeld, en hiervoor het bedrijf Digital Illusions, CE hebben opgericht.
Ja inderdaad, dat is dezelfde DICE die nu oa Battlefield ontwikkelt.

Een ander bekend voorbeeld is het Engelse DMA Design (naam duidelijk geinspireerd op de Amiga met z'n DMA-architectuur), oa bekend van Lemmings: https://www.youtube.com/watch?v=7SgDS-16UFA
Deze kennen we nu als Rockstar Games, oa van GTA.

[Reactie gewijzigd door Scalibq op 19 juli 2015 14:14]

Enigma demo, wie kent hem niet. Wat een soundtrack :-)
Op 3:23 begint Spaceballs, State of the Art demo : https://www.youtube.com/watch?v=aykuVMf4uIQ
(niet rsi mega demo)
Trouwens toen ik die voor de eerste keer zag viel mn mond wel open ;-)
je bent me voor, het viel mij ook op. Toen ik die demo zag viel ook mijn mond open en dat was voor de reden om de amiga te kopen :)
Ik vond het Amiga event erg leuk. Mijn Amiga 500 laten signeren door de drie Amiga developers en mijn Amiga Boing Ball demo port voor de Lynx aan RJ Mical laten zien, die behalve developer van de Amiga en de Boing Ball Demo ook mede-ontwerper van de Atari Lynx chipset was. Zijn enthousiasme was geweldig en hij heeft ook mijn Lynx gesigneerd.

Vreemd dat er in de video met geen woord over de AGA chipset van de Amiga 1200 en 4000 wordt gerept. Ook was de Amiga dť computer voor de TV industrie, in Amerika vooral met de Newtek Video Toaster, waar ook de 3D animatie software Lightwave vandaan komt. Ik heb zelf nog gewerkt aan de graphics en software van de TV kwis Lingo, dat ook op de Amiga draaide, zoals zoveel TV graphics toen. De Amiga kon namelijk standaard gesynchroniseerd (genlock) worden aan het TV signaal waardoor de graphics ervan gemakkelijk met het live beeld gecombineerd kon worden.

De Amiga was zijn tijd ver vooruit, inderdaad gaat de vergelijking met Apple behoorlijk mank, dat was in de tijd van de Amiga een enorm achterlopend systeem, met maar twee kleuren en geen multitasking, je moest zelfs wachten totdat een systeemgeluidje klaar was met afspelen voordat je verder kon werken. Ook Windows 95 was op een aantal vlakken nog niet zo goed als de Amiga, met name kwa multitasking en het gebrek aan auto-config. Met auto-config kon je een uitbreidingskaart in je computer stoppen die bij het booten onmiddelijk werkte, geen enkele driver nodig, die zat in een ROM op de kaart zelf.

En toen kwam het PC privť project, waardoor mensen goedkoop of zelfs gratis een PC van hun werkgever kregen en dus niet van de Commodore 64 naar een Amiga gingen, maar naar een PC.
En ook was daar Doom, die een byte per pixel modus gebruikte om 3D levels te simuleren, terwijl de Amiga dat niet kon op die manier. Kwa geluidskwaliteit heeft het nog een tijd geduurd totdat de PC de Amiga inhaalde, de eerste soundblaster kaarten klonken nog enorm slecht.

Maar uiteindelijk heeft het management de Amiga de nek omgedraaid door het prototype van de Amiga met AAA chipset af te keuren vanwege kinderziektes, iets dat mij normaal lijkt voor een prototype, en vervolgens iemand aan te nemen die alleen maar geflopte producten op zijn naam had staan. Die bracht vervolgens producten als de Amiga 600 uit die ook weer flopten.
De financiŽle geschiedenis van het management was niet te achterhalen aangezien dat allemaal via de Bahama's liep. Persoonlijk sluit ik niet uit dat er mensen door concurrerende bedrijven zijn omgekocht om de boel te saboteren.

Ik heb hier nog de white papers van de AAA chipset liggen, wederom technologie die zijn tijd ver vooruit was. De AGA chipset was oorspronkelijk slechts bedoeld als een tijdelijke overbrugging.
Vreemd dat er in de video met geen woord over de AGA chipset van de Amiga 1200 en 4000 wordt gerept.
Die bestaat nog geen 30 jaar :)
Hebben we een mooi excuus om in 2022 weer feest te vieren :)
Ben altijd grafisch georiŽnteerd geweest, mijn ouders haalden mij uit bed voor de premiŤre van Pixar's Luxo Jr. op de Nederlandse TV. Zal wel door de SIGgraph in de belangstelling van de media zijn gekomen.

In de renderwereld gebruikte men dure Unix-workstations, dit gebeurde ook op universiteiten vanwege de wiskunde hierachter).
Het AmigaOS is onder Unix/C ontwikkeld vandaar dat C een favoriete programmeertaal was op de Amiga.

De A1000 kostte iets van 4000 gulden wat ik als tiener niet kon betalen,
later kwam dus de A500 in huis.
Met een Philips-monitor ipv de traditionele Amiga-monitor, deze had een zwartere beeldbuis dus meer contrast bij omgevingslicht, later nog een aparte TV-tuner bij gekocht, zo had ik veel beter beeld dan menig kleuren-TV (scherper en meer contrast).
In die tijd was een PC veelal beprekt tot 16 kleuren tegelijk op het scherm, later 256 met VGA.

De Amiga had een HAM (Hold And Modify) modus waarmee je alle 4096 kleuren op het scherm kon toveren (16 gradaties voor rood, groen en blauw).
Een pixel besloeg 6 bits, 2 'command' bits en 4 data bits, de command-bits bepaalde of de 4 data-bits een kleur uit een palette waren, of een wijziging van ťťn van de drie basiskleuren van de vorige pixel op het scherm.
https://en.m.wikipedia.org/wiki/Hold-And-Modify
Heb in deze HAM-modus Sculpt-3D en later Sculpt 4D Animate nog nachtenlang plaatjes laten renderen.
Als je een scene had met een paar spiegelende bollen, en dan zeker in de HAM-interlace modus met Overscan aan was je Amiga bijna een dag bezig op 1 plaatje.

Wat al eerder genoemd was stoorde dat de Amiga geen MMU (Memory Management Unit) had. Ieder programma had toegang tot het geheugen van de andere programma's en kon dus de boel verstoren (guru meditation tot gevolg). waardoor er zeer correct geprogrammeerd moest worden. Je ging tijdens het renderen geen andere programma's draaien.

Later kocht m'n zus een 386DX25 met later ik hiervoor de 387coprocessor om erin te prikken om 3DStudio flinkt te versnellen. Met m'n 486DX2-80 (1996) werd de A500 verkocht.
De 386 was de eerste fatsoenlijke CPU voor de IBM-compatible PC's, met zaken overkopiŽerd van Motorola.

Behalve de Amiga vaker met de Motorola MC680x0 processoren te maken gehad: Sun workstation in 1991 (stage). VME-bus systeem met 68020 tijdens de opleiding. En later op het werk een VME-bus systeem met 68030 voor realtime visuele foutendetectie tijdens produktieproces.

De Apple's hadden 'm natuurlijk ook, maar Intel heeft deze slag gewonnen omdat ze goedkoper waren voor IBM. Als IBM direct in het begin voor Motorola had gekozen had dat een hoop elende bespaard in het MS-DOS en vroege Windows-tijdperk.


In 30 jaar tijd is er extreem veel veranderd.
Het grafische is me bijgebleven, heb nu thuis voor de PC een LG31MU-B Real 4K scherm met 10-bits ondersteuning per basiskleur. En m'n Titan X (kon niet wachten op de 980Ti) heeft die ondersteuning ook in de Nvidia control panel.
Want 256 gradaties per basiskleur is bij synthetische beelden door rendering (met een duur woord Image-synthesis) te weinig. Geeft nog altijd color-banding.
En zelfs 4K op 31 inch benodigt nog anti-aliasing technieken, dus 8K voor de PC zal er ook nog wel komen.
En dan graag geen IPS-LCD techniek meer maar OLED of iets vergelijkbaars. Het menselijk oog is de grens.
Dus een soort OLED met extreem kleurenbereik, 10- of zelfs 12-bits nodig per basiskleur en dan minstens 8K en dat met minimaal 100 of 120Hz.
Wil je dan ook nog met 3D-shutterbril werken heb je minimaal 200Hz nodig.

[Reactie gewijzigd door MadButcher op 19 juli 2015 17:17]

Erg leuke video! Ik heb nog een 500 staan met midi interface en protracker. Wat veel mensen niet weten is dat de commodore ook aan de basis heeft gestaan van de elektronische muziek. Nummers als 'Felix - Don't you want me' zijn tracks die gemaakt zijn op een 500, en op ťťn diskette passen. Daar werden maar 4 sporen voor gebruikt.

De stabiliteit van deze machines is nog steeds niet geŽvenaard. Waar Cubase, Pro Tools, Fuityloops, Reason of Renoise nog altijd kampen met stabiliteit, was dat op een 500 helemaal niet aan de orde.
"Wat veel mensen niet weten is dat de commodore ook aan de basis heeft gestaan van de elektronische muziek."

Dat is slecht ten dele correct, want veel electronische muziek werd gemaakt op een Atari ST m.b.v. midi & externe synths/samplers

Echter: Amiga's werden regelmatig gebruikt bij de productie van o.a. gabberhouse. https://www.youtube.com/watch?v=Evkcq8lQ8Mw
http://synthforum.nl/foru...157290&highlight=hoe+werd
Ook gebruikte de Osdorp Posse (in het begin) een Amiga voor de beats: https://www.youtube.com/watch?v=vKNQNXqbscg Let op de tekst !
Ook ene Ad Visser gebruikte Amiga's (met Midi): http://www.discogs.com/ar...dam-Computer-Ensemble-The

[Reactie gewijzigd door borchen op 19 juli 2015 11:47]

Een ander aspect van Commodore in de muziek is de SID-chip uit de C64. Ten eerste wordt deze nog steeds wel toegepast in elektronische muziek.
Ten tweede heeft de ontwerper van de SID-chip, Bob Yannes, het synthesizer-bedrijf Ensoniq opgericht. Deze is later weer overgenomen door Creative (oa van Sound Blaster en E-mu).
Dat is slecht ten dele correct, want veel electronische muziek werd gemaakt op een Atari ST m.b.v. midi & externe synths/samplers
Het verschil is dat de *muziek* daar gemaakt werd via externe synths/samplers. De Atari ST was slechts de sequencer waarmee je de midi-data opnam, afspeelde en bewerkte. Dit kun je op iedere computer doen met een midi-interface (De voorloper van Steinberg's Cubase op de ST was op de C64 gemaakt met een midi-kit). De ST had toevallig standaard midi aan boord.
De Atari ST zelf produceerde niet echt goede geluiden voor die tijd. Een verschil dus met de C64 en de Amiga waarbij het geluid dat uit die computers kwam daadwerkelijk is gebruikt in hits.

Een Amiga icm met ProTracker was een hele goedkope manier voor een beginnende muzikant om oa house-platen te maken. Meer had je niet nodig. Een midi-installatie is een heel ander verhaal.

[Reactie gewijzigd door Scalibq op 19 juli 2015 12:13]

Amiga en Atari hadden beide een zeer solide midi dat nu nog steeds qua snelheid en stabiliteit de huidige midi op multi-task OSen kan verslaan omdat deze zo dicht op de hardware zat. Of je moet speciale midi hardware kopen die de data buffert zodat de timing op de millieseconde nauwkeurig geregeld kan worden. Niet voor niets dat die computers nog heel lang in de diverse geluidsstudios over de hele wereld hebben gestaan.
Dat Amiga op de goede weg zat bewijst wel dat Atari met de Falcon uit kwam waar men hardware in zat die ook in de Amiga's zat (blitter,68020, ad/da). En in die tijd was de Acorn Archimedes ook een concurrent die zich grafisch kon meten met de Amiga.

Na de komst van de '3d' shooters zoals Wolfenstein en Doom was er het omslagpunt dat de PC sneller aan het innoveren was. En dat de PC mod trackers veel meer konden dan met de Amiga mits je er een dure geluidskaart in zette.
En in die tijd was de Acorn Archimedes ook een concurrent die zich grafisch kon meten met de Amiga.
De Archimedes is juist een voorbeeld van een systeem dat vooral om de CPU draait, en niet veel aan chipset heeft, net als de vroege PCs.
De 32-bit RISC ARM in de Archimedes was enorm snel vergeleken met een 68000, dus daar kon je een hoop mee compenseren (dat is de reden dat ik zelf ook een A3010 heb aangeschaft).
Maar de Archimedes had geen copper, blitter, sprites of dat soort dingen.
Ook multitasking was te hoog gegrepen, net als de Macs uit die tijd.
De ARM chip is zo ontworpen door oa 32 32 bits registers die allemaal full feature zijn (dus kunnen rekenen) en conditionele instructies dat de functie van de blitter chip in de CPU hw ondersteund is. Een losse blitter chip met ARM zal geen enkel voordeel hebbten omdat de bottlenek het memory access is. Wanneer er een blitter in zal zitten moet de ARM stil staan todate de blitter klaar is. De 68000 heeft veel clocks per instructie nodig waardoor de geheurgen bus vaak vrij is voor de blitter. De Acorn Arhcimedies was zijn tijd ver voorruit maar heeft het niet gered doordat ze te weinig marketing power hadden. Acorn was simpel te klein om de USA vanaf het begin Archimedesen aan te bieden.
De ARM chip is door Acorn zelf ontwikkeld en hete oorsprongkelijk Acorn Risc Machine. Na het failisement van Acorn hebben een aantal managers de ARM techniek gekocht en via een licentie uitgiftengroot weten te maken. De ARM is nu de meest gebrukte CPU ter wereld. De ARM is zo succesvol omdat hij goedkoop en snel is. Met name de IRQ repsonse tijd is wereld record houder waardoor real time taken op de CPU kunnen ipv met losse processoren. Hierdoor zijn de kosten van een ARM oplossing veel lager dan een alternatief systeem met ondersteunende hardware (zoals een blitter :-)
De ARM chip is zo ontworpen door oa 32 32 bits registers die allemaal full feature zijn (dus kunnen rekenen) en conditionele instructies dat de functie van de blitter chip in de CPU hw ondersteund is. Een losse blitter chip met ARM zal geen enkel voordeel hebbten omdat de bottlenek het memory access is. Wanneer er een blitter in zal zitten moet de ARM stil staan todate de blitter klaar is. De 68000 heeft veel clocks per instructie nodig waardoor de geheurgen bus vaak vrij is voor de blitter.
Daar ben ik het dus niet mee eens.
De blitter is een goed voorbeeld van *multiprocessing*: de CPU kan andere dingen doen terwijl de blitter bezig is. Inderdaad, de blitter vreet bandbreedte op, dus de CPU loopt trager (en er is een modus waarbij de blitter zelfs alle geheugencycles kan krijgen ('blitter nasty'), waardoor de CPU vrijwel stilstaat, in chip-mem)... Maar er zijn genoeg instructies die weinig geheugenbandbreedte nodig hebben, maar wel veel CPU-cycles. Neem bv mul/div instructies. Die zijn ook op een ARM relatief traag.
Daarnaast is er het concept van fast-mem: geheugen dat niet toegankelijk is voor de chipset, maar wel voor de CPU. Hierdoor heeft de CPU geen 'last' van de blitter, en kan hij op volle snelheid doordraaien (vandaar de naam).

Bij een Amiga kun je dus heel mooi 3d renderen door een copperlist te bouwen met commando's voor de blitter voor de polygons van het huidige frame, terwijl de CPU alvast rekent aan het volgende frame, wat voor een groot deel uit matrix-operaties bestaat, dus veel multiplies, en weinig geheugentoegang (en zodra de CPU klaar is, kan hij 'blitter nasty' aanzetten, voor maximale performance).

De CPU hoeft zeker niet stil te staan, dat is nu JUIST het punt van de Amiga, en dat had met een ARM ook best gekund.
Het is allemaal een kwestie van memory-pools, DMA-channels en prioriteiten stellen.
Zie hier voor meer info: http://amigadev.elowar.co...anual_guide/node012B.html
Zoals je ziet, zolang je niet 'blitter nasty' aanzet, zal de chipset de CPU af en toe voorrang verlenen op de blitter, als hij 3 cycles heeft moeten wachten.

Dus nee, niet mee eens. De Amiga zit beter in elkaar dan jij dacht, ben ik bang.

Daarnaast gaat je argument niet zo heel goed op, want moderne ARMs zijn vrijwel allemaal SoCs, met een GPU aan boord, wat in feite een zeer geavanceerde vorm van een blitter is :)

[Reactie gewijzigd door Scalibq op 20 juli 2015 12:15]

de ARM2 van de Archimedes heeft geen cache zoals moderne processors nu hebben, dat betekent dat de ARM met een instructie per clock 100% van de tijd de memorybus bezet houd. Door de conditionele slimme instructie set bevat elke instructie dus een conditie en data in 32 bits. Dus al zal er een blitter in zitten, hij kan niet bij de memory bus. De ARM kan zelf net zo snel geheugen copieren als een blitter door de 1 clock per instructie dus de blitter voegt hier niets toe Bij de 68000 is de blitter juist een groot voordeel omdat de 68000 zelf te traag is om full speed met clipping geheugen te copieren. De ARM3 van de latere Archimedesen en RiscPC heeft wel een cache van 8Kb (!!) maar die is weer 4 x zo hoog geclocked dus die memory bus is nog steeds 100% bezet. De cahce zorgt er voor dat wanneer de instructies en data in de cpu core zijn hij dus op 32 Mhz kom lopen ipv van 8Mhz en later 12Mhz wat de memorysnelheid van de archimedes was.
Dus al zal er een blitter in zitten, hij kan niet bij de memory bus.
Natuurlijk wel, want de blitter heeft een hogere prioriteit dan de CPU.
Daarnaast negeer je het genoemde verschil tussen chipmem en fastmem. Ook al is de blitter vol bezig in chipmem, heeft de CPU het fastmem nog voor zichzelf.
De ARM kan zelf net zo snel geheugen copieren als een blitter door de 1 clock per instructie dus de blitter voegt hier niets toe
De blitter doet wel iets meer dan 'geheugen kopieren'. Hij kan ook linedrawing, floodfill, masked blits etc, en dat alles met adressering op bit-niveau, niet op byte/word-niveau. Dat zijn dingen die je niet zo snel kunt op een ARM CPU.

Jammer maar helaas. Kennelijk heb je m'n vorige bericht gewoon niet goed begrepen, want ik had alles al uitgelegd. Nogmaals, de Amiga zit beter in elkaar dan jij dacht, ben ik bang.

[Reactie gewijzigd door Scalibq op 20 juli 2015 14:56]

De blitter chip is een hele simplele RISC CPU. De ARM is een complete RISC CPU. Alles wat de blitter kan (snelle repeterende selectieve operaties op geheugen) kan de ARM ook net zo snel. Het is immers een CPU die te programmeren is om line drawing, floodfill, masked bits etc te doen. De bottelnek is de geheugen bus. Dus het maakt niet uit of de ene "CPU" of de andere "CPU" dezelfde bewerking uitvoerd.

In Moderne ARM architecturen wordt net zoals bij intel gebruik gemaakt van grote caches, level 2 caches, complexe memory controllers, slimme DMA en dedicated geheugen (GFX) zodat de geheugen bandbreedte gecreerd wordt om met meerde CPU's in een systeem te werken. de Archimedes stamt uit 1987 en die had al een "slimme" geheugen conroller die geheugen kan remappen en virtualizern. Alleen de bandbreede was beperkt tot single channel 8 Mhz * 32 bits met alle beperkingen die dat geeft. (Net zoals de Atari, Amiga en Apple en IBM systemen van die tijd)

[Reactie gewijzigd door tweakerspim op 20 juli 2015 15:07]

De blitter chip is een hele simplele RISC CPU. De ARM is een complete RISC CPU. Alles wat de blitter kan (snelle repeterende selectieve operaties op geheugen) kan de ARM ook net zo snel. Het is immers een CPU die te programmeren is om line drawing, floodfill, masked bits etc te doen. De bottelnek is de geheugen bus. Dus het maakt niet uit of de ene "CPU" of de andere "CPU" dezelfde bewerking uitvoerd.
Nee, dat is dus niet waar.
Ten eerste is de blitter chip geen RISC CPU. Het is een ASIC, geoptimaliseerd voor operaties op bitmaps. Hij kan alles op volle bandbreedte uitvoeren, omdat de operaties hardwired zijn. Net zoals bv een GPU, die bv hardwired logica heeft om textures te filteren op volle bandbreedte. Een CPU, of die nu RISC is of niet, kan niet alle operaties op maximale bandbreedte doen, omdat er ook bandbreedte verloren gaat aan het lezen van de instructies zelf, en in sommige gevallen heb je meerdere instructies nodig om een bepaalde operatie te doen, waardoor je dus kostbare bandbreedte verspilt.

Dus nogmaals, jammer maar helaas. De ARM CPU is een mooie CPU, maar het blijft een CPU, general purpose. Er zijn niet voor niets ASICs, DSPs, GPUs, en andere dedicated chips ontwikkeld, geoptimaliseerd voor specifieke taken. Zo ook de blitter in de Amiga.

En dan hebben we het nog niet eens over de copper. Het niet hebben van een copper maakt het een stuk lastiger en minder efficient om strak getimede raster-operaties te doen.

[Reactie gewijzigd door Scalibq op 20 juli 2015 15:10]

ASIC = custom chip, dat heeft niets met de functionalieit te maken maar met de manier waarop de chip is ontworpen
hardwarired betekent niets anders dan dat de logica niet is om te programmeren maar het maakt voor de operatie en snelheid niets uit of het nu hardwired of SW only is met een RISC (1 instructie per clock) De ARM instructie set intern is nl ook hardwired in tegenstelling tot de microcode op de 68000 die kan niet 1 instructie per clock uitvoeren. De Blitter heeft hier dus 2 voordelen 1) De onbenutte geheugenbandbreedte benutten, 2) Dingen sneller kunnen dat de trage 68000. Dus voor de Amiga is de blitter heel belangrijlk, met name voor multi media waarbij je veel data moet verplaatsen / bewerken. De Amiga kan dit sneller dan andere 68000 oplossingen dankzij de bliter. De RISC architectuur van de ARM benut de geheugen bandbreedte al maximaal en is sw geheel programmeerbaard waardoor de ARM nog complexere dingen op maximum bus snelheid kan doen dan de voorgeprogrameerde operaties in de blitter. Een mooi voorbeeld van een sw complexe taak op de ARM is de 1 seconde mandelbrot op 720 * 512 *256 demo in de tijd dat een amiga een uur nodig heeft op de trage 68000 voor hetzelde plaatje

[Reactie gewijzigd door tweakerspim op 20 juli 2015 15:20]

ASIC = custom chip, dat heeft niets met de functionalieit te maken maar met de manier waarop de chip is ontworpen
ASIC == "Application-specific integrated circuit"
Speciaal ontworpen voor een bepaalde toepassing. In dit geval dus bitmap-operaties.
hardwarired betekent niets anders dan dat de logica niet is om te programmeren maar het maakt voor de operatie en snelheid niets uit of het nu hardwired of SW only is met een RISC (1 instructie per clock)
Dat maakt wel uit, zoals ik al zei.
Ten eerste voer je de blitter geen instructies voor iedere operatie. Je initialiseert de registers eenmalig voor een heel blok. Je verspilt dus geen bandbreedte aan het lezen van instructies zoals ik al zei.
Ten tweede, een ARM-CPU kan niet alles wat de blitter kan in 1 cycle. Voor bepaalde operaties heb je meerdere instructies nodig.
De ARM instructie set intern is nl ook hardwired in tegenstelling tot de microcode op de 68000 die kan niet 1 instructie per clock uitvoeren.
We hebben alleen niet te maken met de 68000, we hebben het over de blitter.
De Blitter heeft hier dus 2 voordelen 1) De onbenutte geheugenbandbreedte benutten
Zoals al gezegd, de blitter heeft hogere prioriteit dan de CPU. Dus de blitter krijgt de meeste bandbreedte, niet de CPU.
2) Dingen sneller kunnen dat de trage 68000.
Zoals al gezegd, dit gaat op voor ELKE CPU, hoe snel ook. Dat is ook de reden dat we vandaag de dag GPUs hebben.
Als wat jij zegt waar zou zijn, dan heeft een GPU geen nut, omdat een CPU het net zo snel zou kunnen.
Dat klopt niet, zoals we hopelijk allemaal wel weten. Een GPU kan veel operaties veel sneller uitvoeren dan een CPU, omdat hij daar speciaal ontworpen circuits voor heeft.

Als laatste negeer je voor de zoveelste keer het feit dat de Amiga zowel chipmem als fastmem heeft, en door deze scheiding kunnen zowel de blitter als de CPU beiden de volledige bandbreedte benutten.

Ik snap dat je fan bent van ARM, ik vind het zelf ook een van de mooiste CPUs. Maar verlies de realiteit niet uit het oog.
Je denkt verkeerd. Wanneer de geheugen bandbreedte de berpekende factor is en de CPU die 100% kan vullen met een operatie dan is er geen toegevoegde waarde voor een externe chip die hetzelfde gaat doen binnen dezelfde bandbreedte. Waarom de ARM CPU still zetten om een blitter aan het wekk te zetten. De ARM instructie set bevat conditionele insructies met auto incr duis een for(mem=10;mem<1000;mem++) addr[mem]=addr[mem+10); Heb je maar 1 instructie nodig. dus 100% van de mem bandbreedte = read/write van geheugen. De ARM heeft ook instructiies om een adres uit te rekenen als add=R0+R1*R2 dus x * y omzetten in een geheugen address en daar een bewerking opzetten in 1 clock cycle Nu zullen er vast theoritische dingen zijn die de blitter mischien 1 of 2 clock ticken op het totaal sneller doet maar voor de praktijk is de inverstering van een blitter voor een ARM oplossing dus verspilling. Bij de 68000 heeft hij dus wel waarde en daarom zit er wel een blitter in een Amiga en is er geen enkle ARM oplossing met een blitter (of iets vergelijkbaars). De ARM2 heeft een soort van cahce voor 3 instructies dus met de bovenstaande instructie set kan je heel veel doen met 100% bandbreedte op 32 bit

[Reactie gewijzigd door tweakerspim op 20 juli 2015 15:40]

Je denkt verkeerd. Wanneer de geheugen bandbreedte de berpekende factor is en de CPU die 100% kan vullen met een operatie dan is er geen toegevoegde waarde voor een externe chip die hetzelfde gaat doen binnen dezelfde bandbreedte.
Nee, jij denkt verkeerd.
Want:
1) Een CPU gebruikt niet alleen bandbreedte voor het verplaatsen van geheugen, maar ook voor het lezen van instructies. Stel bv dat je 1024 bytes wil kopieren, en je kunt per instructie 4 bytes kopieren. Maar iedere instructie is ook 4 bytes groot. Dan moet je dus in totaal 1024 bytes lezen, 1024 bytes schrijven, en 256 instructies a 4 bytes lezen.
Je hebt dus in totaal niet 2048KB maar 3072KB aan dataverkeer.
Zelfs in het ideale geval gebruik je dan 50% meer bandbreedte, dus ben je bij voorbaat al af. Nog afgezien van extra overhead van loop-constructies en dergelijke.

2) Voor de zoveelste keer, een generieke CPU kan niet iedere blitter-operatie in 1 cycle doen. Als je bv een mask-blit doet, moet je ipv 256 instructies ook nog de masking doen, en dat kost je dan misschien ook nog 1 a 2 instructies. Dus meer bandbreedte die verstookt wordt aan andere dingen dan puur de operaties op source en destination.
En dan heb ik het nog niet over het bit-exact adresseren van data, waar je dus op een CPU moeilijk moet gaan lopen shiften en masken van data.

3) Voor de zoveelste keer, met chipmem en fastmem gaat het hele argument van "CPU gebruikt bandbreedte, dus blitter heeft geen bandbreedte" niet op.
Waarom de ARM CPU still zetten om een blitter aan het wekk te zetten.
Omdat dat sneller is! En nogmaals, dat is niet van toepassing bij fast-mem!
Nogmaals, waarom hebben we anders GPUs?

Ik heb hetzelfde verhaal nu al 3 keer uitgelegd, maar het registreert gewoon niet bij je!
Bij de 68000 heeft hij dus wel waarde en daarom zit er wel een blitter in een Amiga en is er geen enkle ARM oplossing met een blitter (of iets vergelijkbaars).
Alle moderne ARM-oplossingen hebben een GPU.
Het is te simpel om te concluderen dat de Archimedes geen blitter heeft omdat hij deze niet nodig heeft. Dat zou impliceren dat de Archimedes perfect is zoals hij ontworpen is, en dat is niet het geval.
Sterker nog, de Archimedes is ontworpen omdat men geen markt had voor de ARM (men wilde hem eerst marketen als een coprocessor voor de BBC). Het was nogal een haastklus. Als er meer tijd/budget was geweest, had men vast een completere custom chipset geimplementeerd. Want naast de blitter heeft de Amiga nog vele andere custom chipset features die het systeem zo uniek en vooruitstrevend maakten.

[Reactie gewijzigd door Scalibq op 20 juli 2015 16:07]

Je wil het niet snappen. Met meerdere chips in een geheugen werken heeft alleen zin als er of een memory controller is die geheugen bandbreedte kan splitsen of je met caches kan werken. Een GPU is een heel ander soort ding dan een blitter. Een GPU is een paralele processor met honderden rekenunits die weer 1024 (simpele) instructies tegelijk kunnen uitvoeren per rekenunit. Dat is geen general perpose CPU maar een massive parralel processor. Een GPU heeft dus meer geheugen bandbreedte nodig en heeft daarom zijn eigen memory met een veel hogere clock en busbreedte dan de CPU. In een PC zie je dan ook nooit de CPU bewerkingen doen in het GPU gedeelte al kan het wel maar het is traag en dus niet slim om dezelde redenen dat een blitterr niet slim is in een ARM architectuur.

In de Amiga zijn twee truckjes relevant, gesplits geheugen en een trage CPU (= die niet 100% van de tijd de memory bus bezet houdt) Dat gesplitse geheugen is meer een kosten reductie geweest die dankzij de blitter ook een voordeel opleverd.

Een ARM moet af en toe wel een instructie lezen maar de overhead hiervan is heel klein door de conditionele instructie set. Dus een intructie extra lezen per 4000 bytes verwerken zet geen zode aan de dijk. Masking kan de ARM intern. Als een blitter een voordeel heeft zal hij zeker in ARM architectuur opgedoken zijn want ook de Archimides heeft Asics nl VIDC1, MEMC en IOS en ARM2 zelf is een Acorn ASICs.

Een blitter is een innovatie uit het 68000 CISC tijdperk die overbodig is geworden dankzij RISC architectuur

[Reactie gewijzigd door tweakerspim op 20 juli 2015 16:27]

Je wil het niet snappen. Met meerdere chips in een geheugen werken heeft alleen zin als er of een memory controller is die geheugen bandbreedte kan splitsen of je met caches kan werken.
Nee, JIJ wil het niet snappen.
1) Je hebt chip-mem en fast-mem, dus je hebt niet '1 geheugen', maar twee. De chipset (waaronder blitter) kan niet in fast-mem komen, en dus hoeft de CPU geen cycles af te geven aan de chipset zolang deze in fast-mem werkt.
2) Er *is* een controller die bandbreedte splitst. Er zijn vele DMA-kanalen binnen het Amiga-ontwerp, met verschillende prioriteiten.
3) Een CPU verstookt ook bandbreedte aan de instructies zelf, het nadeel van een generieke processor tov een ASIC.
Een GPU is een heel ander soort ding dan een blitter.
Want? Beiden doen operaties op een stuk geheugen zonder tussenkomst van de CPU. Voor deze discussie maakt het niet uit dat een GPU geavanceerder is dan een blitter. Voor de verdeling van bandbreedte tussen GPU en CPU blijft het verhaal hetzelfde.
Een GPU heeft dus meer geheugen bandbreedte nodig en heeft daarom zijn eigen memory met een veel hogere clock en busbreedte dan de CPU.
Niet in het geval van een SoC, daar worden geheugen gedeeld tussen CPU en GPU, net als bv in het chipmem van de Amiga.
Maar je zou chipmem vs fastmem wel kunnen vergelijken met videogeheugen vs systeemgeheugen.
In een PC zie je dan ook nooit de CPU bewerkingen doen in het GPU gedeelte al kan het wel maar het is traag en dus niet slim om dezelde redenen dat een blitterr niet slim is in een ARM architectuur.
We hebben het hier niet over PCs, maar over ARM SoCs met ingebouwde GPU.
Een ARM moet af en toe wel een instructie lezen maar de overhead hiervan is heel klein door de conditionele instructie set. Dus een intructie extra lezen per 4000 bytes verwerken zet geen zode aan de dijk.
Van dit verhaal klopt zo weinig dat ik er niet eens meer eens meer op in wil gaan. Laat eerst maar eens een stuk ARM-code zien waarbij je 1 instructie per 4000 bytes gebruikt.
Bovendien negeer je steevast de adressering per bit vs per byte/word.
Als een blitter een voordeel heeft zal hij zeker in ARM architectuur opgedoken zijn
Nee, want een blitter is een heel specifiek ding, en het kost veel tijd om die te ontwikkelen. De Atari ST heeft ook pas na een paar jaar een update gekregen met een blitter. Deze blitter was overigens nog steeds minder krachtig dan die in de Amiga (oa maar 3 kanalen ipv 4).
Je kunt beter naar de PC-wereld kijken. Daar heeft men ondanks de snelle CPUs (die ook veel sneller waren dan de ARMs ten tijde van de 486/Pentium) toch blitters op videokaarten geintroduceerd, daarna ook linedrawing en meer geavanceerde teken-operaties op de zogenaamde 'Windows accelerator' videokaarten. En uiteindelijk dus de 3d accelerators, tot aan de GPUs van nu.

[Reactie gewijzigd door Scalibq op 20 juli 2015 16:39]

Als je niet snapt hoe memory bandbreedte een bottelnek is dan houdt het op,
Als je niet weet wat een DMA controller doet dan houdt het op
Alsj je niet weet wat een GPU is dan houdt het op
Als je niet weet hoe de Amiga architectuur er uit ziet en snapt dat slow mem een manier is om goedkoper geheugen te gebruiken waar de blitter niet bij kan/ niet veel toevoegd dan houdt het op

>1 instructie per 4000 bytes gebruikt.

stmia r0!, {r3,r4,r5,r6,r7,r8,r9,r10}
Als je niet snapt hoe memory bandbreedte een bottelnek is dan houdt het op,
Als je niet weet wat een DMA controller doet dan houdt het op
Alsj je niet weet wat een GPU is dan houdt het op
Tsja, ik weet dat allemaal wel, ik denk ook niet dat ik dat nog hoef te bewijzen, met de demoscene-dingen die ik door de jaren oa op Amiga en PC heb gedaan.

De dingen die ik zeg, lijken echter totaal niet bij jou te registreren, alsof je het gewoon niet begrijpt.
>1 instructie per 4000 bytes gebruikt.

stmia r0!, {r3,r4,r5,r6,r7,r8,r9,r10}
Dat is geen 4000 bytes, maar slechts 32 bytes. Bovendien is dat alleen een store, dus geen blit. Je hebt nog een instructie nodig die leest. Dus in dit simpele geval hebben we dan al minimaal 2 instructies voor 32 bytes. Dat is 8 bytes op de 32, dus 25%. En dan hebben we het dus nog niet over bit-exact adresseren, mask blits, linedrawing, floodfill etc.

[Reactie gewijzigd door Scalibq op 20 juli 2015 17:13]

nog een keer dan:
>>Dat is geen 4000 bytes, maar slechts 32 bytes.
Klopt, maar met een confitional jump auto decrement kan je dus n * dit doen met 2 instructies en die passen in de pijplijn van de ARM2. ARM3 heeft cache dus je kan hele complexe dingen schrijven binnen de cache die de geheugen bandbreedte maximaal benutten. Vanaf 1989 is de Archimedes voorzien van een ARM3 (en de oude zijn allemaal geupgrade naar ARM3 voor 100 gulden)

>>Bovendien is dat alleen een store, dus geen blit.
De blitter kan raden wat er in het geheugen staat zonder het te lezen en dan goed wegschrijven?? De blitter moet ook eerst lezen voordat hij kan schrijven !!!

>>bit-exact adresseren, mask blits, linedrawing, floodfill etc.
Allemaal varianten van X*Y+Z=condistional mask value (mem addr). met auto encr value van X Y en Z.

De blitter is een prima aanvulling op de 68000 en de Amiga stal de show met grote sprites (images) die allemaal (max 4 geloof ik) door het beeld kunnen bewegen met effecten. De Amiga demo scene stond er vol mee incl goede muziek.

De Archimedes demo scene was meer gefocused op geometry en 3D projecties met high frame rates die de RAW power van de ARM lieten zien. Dus grote grahpics in 3D door het beeld heen laten komen inc muziek. Precies de dingen die een blitter niet kan. De stoerste blijf ik de 1 seconden Mandelbrot vinden op een 8Mhz ARM. In die tijd was elke PC minimaal 10 minuten bezig met een Mandelbrot.

En de afsluiter:
Alle huidige CPU's zijn intern RISC (1 instructie per clock) en alle computer architecturen hebben meerdere geheugen kanalen zodat meerdere Cores van CPU, GPU, FPU, IOControllers en wat dan ook met cache geheugen bandbreedte kunnen delen. De ARM is nu verruit de meest gebruikte CPU ter wereld. Of de 68000 nog bestaat in een moderne variant weet ik niet en boeit me niet. Met het einde van de 68000 is de voor die tijd inovatieve blitter overbodig geworden. De functies zijn op andere manieren in de HW gekomen oa in south bridges, IO controllers of vervangen door andere technologie zoals GPU's. (GPU werkt totaal anders dan een blitter dus is geen variant van)
>>Bovendien is dat alleen een store, dus geen blit.
De blitter kan raden wat er in het geheugen staat zonder het te lezen en dan goed wegschrijven?? De blitter moet ook eerst lezen voordat hij kan schrijven !!!
Nee, het punt is dat je dus meer instructies, en dus meer bandbreedte moet verstoken om zelfs de meest triviale blit te doen (een memcpy).
Een blitter bewerkt hele blokken geheugen ineens (en die blokken zijn 2-dimensionaal, dus je hoeft niet per scanline opnieuw pointers te zetten. Je geeft een rechthoek op waarbinnen hij werkt).
Je hebt dus veel minder overhead.
>>bit-exact adresseren, mask blits, linedrawing, floodfill etc.
Allemaal varianten van X*Y+Z=condistional mask value (mem addr). met auto encr value van X Y en Z.
Nou, het is wel iets ingewikkelder dan dat, want je moet gaan lopen bitshiften, en meerdere registers samenvoegen etc.
Volgens mij begrijp je niet dat pixels geen words zijn, maar in het geval van de Amiga zijn het bits. Je wilt dus iedere bit afzonderlijk kunnen adresseren, en als je iets pixel-perfect over het beeld wil laten bewegen, moet je dus de bits in het geheugen verschuiven.
De blitter kan dit allemaal op volle snelheid. Een normale CPU is niet efficient in het verschuiven van data op bit-niveau.

Ook de Acorn gebruikt geen pixels van een word, dus ook daar zul je binnen words moeten gaan schuiven met bits om pixel-perfecte animatie te krijgen.
Doe je dat niet, dan krijg je dingen als dit: https://youtu.be/cA8Xgjlqcdw
Je ziet dat alles een paar pixels verspringt bij iedere beweging, en dus rommelig beweegt.
Dus grote grahpics in 3D door het beeld heen laten komen inc muziek. Precies de dingen die een blitter niet kan.
Blijkbaar weet je niet wat de blitter kan.
3D op Amiga wordt JUIST met de blitter gedaan. Dat doe je door eerst met de blitter de polygon outlines te tekenen, en daarna met de blitter een floodfill uit te voeren.
Daarom hebben veel Amiga demos ook 3d scenes die op 50 Hz draaien. Dat zou met alleen een 68000 op 7 MHz vrijwel niet te doen zijn (al had men in de Atari ST-scene wel wat trucjes).
Alle huidige CPU's zijn intern RISC (1 instructie per clock) en alle computer architecturen hebben meerdere geheugen kanalen zodat meerdere Cores van CPU, GPU, FPU, IOControllers en wat dan ook met cache geheugen bandbreedte kunnen delen. De ARM is nu verruit de meest gebruikte CPU ter wereld. Of de 68000 nog bestaat in een moderne variant weet ik niet en boeit me niet. Met het einde van de 68000 is de voor die tijd inovatieve blitter overbodig geworden. De functies zijn op andere manieren in de HW gekomen oa in south bridges, IO controllers of vervangen door andere technologie zoals GPU's. (GPU werkt totaal anders dan een blitter dus is geen variant van)
Tsja, we hadden het hier over de blitter, niet over de 68000. Je lijkt die zaken niet te kunnen scheiden.
Maarja, je snapt ook al niet dat je voor blitten geen operaties op words moet doen, maar op pixels, dus bits. En je snapt niet dat de Amiga blitter polygons kan tekenen.

Verder werkt een GPU helemaal niet 'totaal anders' dan de blitter op een Amiga.
Sterker nog, zoals ik al eerder zei: je kunt de copper en de blitter combineren, en op die manier heb je een vroege vorm van een 3d-accelerator.
Een copperlist zou je kunnen zien als een vroege variant van een 'pushbuffer' zoals op moderne GPUs: een buffer met GPU-instructies.
Die vul je van tevoren met de CPU, en de copper voert die dan zonder verdere tussenkomst van de CPU uit.
De copper-instructies kunnen op hun beurt weer de blitter aansturen, dus je kunt in de copperlist zowel de instructies voor de lijnen als voor de floodfill-operaties opnemen, waardoor de copper/blitter dus volkomen zelfstandig polygons tekenen op je scherm, terwijl de CPU vrij is voor andere taken. Die kan alvast aan het volgende frame beginnen.

In feite werken GPUs vandaag de dag nog exact zo.
>Een blitter bewerkt hele blokken geheugen ineens (en die blokken zijn 2-dimensionaal, dus je hoeft niet per scanline opnieuw pointers te zetten. Je geeft een rechthoek op waarbinnen hij werkt).
Je hebt dus veel minder overhead.

De memory bandbreedte is de beperking. De ARM kan sneller lezen en schrijven dan de blitter omdat er sneller geheugen in de Arhcimedes zat.. De Amiga had dan weer 32 kleuren modes waardoor er minder geheugen bewerkt moet worden dus minder data verplaatsen.

>Volgens mij begrijp je niet dat pixels geen words zijn, maar in het geval van de Amiga zijn het bits. Je wilt dus iedere bit afzonderlijk kunnen adresseren, en als je iets pixel-perfect over het beeld wil

Jij kent de ARM instructie set niet. Just dingen als schuiven + optellen en mask is een enkele ARM instrucktie. Dit was het slimme van de ARM. 1 instructie per cycle en dan ook nog een hele effectieve. BV uitrekenen van een pixel mem address en dan die ene (of 4) bit (s) bewerken kan met 1 instructie.

>Je geeft een rechthoek op waarbinnen hij werkt).
Dat heet clipping en dat kan de VIDC1a binnen de Archimedes. Is nl handig voor je window manager. RISCOS was nl het eerste OS dat real time solid windows kon verslepen met een framerate van 25 frames/s Amiga en Atari en Apple versleepten enkel wire frames in die tijd. RISCOS deet dit dmw van clipping, caching en blocksgewijs memcopy. Het video geheugen in de Arhcimedes is zo ingedeeld dat je een blox van x by y linear kan benaderen. Dus in een keer 32 bytes schrijven in een x by y blok.

>Dat zou met alleen een 68000 op 7 MHz vrijwel niet te doen
Exact. De blitter heeft dus veel toegevoegde waarde als het gaat om memory fils en de commodore ontwerpers hebben dit prima uitgevoerd. Een 8 Mhz ARM heeft in tegenstelling van de 68000 wel de capaciteit om full speed het geheugen te vullen en wordt geholpen door de geheugen indeling die geconfigureerd wordt door Memc en IOC (cam mapping). Door de geheugen indeling kan de ARM sequentieel doorschrijven.

>Tsja, we hadden het hier over de blitter, niet over de 68000. Je lijkt die zaken niet te kunnen scheiden.
Maarja, je snapt ook al niet dat je voor blitten geen operaties op words moet doen, maar op pixels, dus bits. En je snapt niet dat de Amiga blitter polygons kan tekenen

Ik snap heel goed dat een blitter is nl een ding die voorgeprogameerde akties op het geheugen kan doen. Een floatfill is niets anders dan de juist pixels kleuren. De blitter heeft de registers om polygonen te snappen dus kan zowel geheugen andressen als pixel bits masken. Een polygoon is het simpelse wiskundige figuur dat er is en kan je defineiren door mem = Y*n+X*n waarbij N een stepping is. Commodore heeft hier goed over nagedacht maar het blijft een slimme memory fill chip die de 68000 versterkt op de punten waar hij zwak is en dus geen waarde heeft in een RISC architectuur

>Verder werkt een GPU helemaal niet 'totaal anders' dan de blitter op een Amiga.

Een GPU heeft een totaal andere architectuur waarbij je twee hoofd onderdelen moet onderscheiden NL heel veel paralelle data processors en paralelle pixel shaders. (De Voodoo1, de eerste echte GPU werkte al zo) Bijde zijn zelstandige cores die instructies kunnen uitvoeren en dat heel snel doen. Hierdoor kan je bv de geometrie laten berekenen door de data processors en die geometrie bewerken met de shaders. Je kan ook bv UNRAR draaien in de data processors van een GPU of video encoderen. Doordat een video kaart veel rekenkracht heeft gaat dit veel sneller dan op de main CPU. Alleen het resultaat valt altijd tegen omdat de generieke geheugen bandbreede te laag om snel genoeg data aan te voeren aan de GPU. De GPU staat dus te wachten op het geheugen in dit soort toepassingen. Dit is een algemeen probleem voor elke "Super" computer. Hij is zo snel als er data aan en afgevoerd kan worden. Preceies hetzelde probleem als de blitter die niet sneller kan zijn dan het geheugen. De ARM kan het geheugen maximaal aansturen dus is net zo snel als een blitter. De blitter moet ook instruckites lezen voordat hij aan de slag kan. In ARM store je die in de cache/pipeline en in de blitter in de registers. daarnaa full speed het geheugen te lijf.
De memory bandbreedte is de beperking. De ARM kan sneller lezen en schrijven dan de blitter omdat er sneller geheugen in de Arhcimedes zat.
Dat is een onzin-argument natuurlijk. De blitter in een A1200 was ook sneller dan die in de A500/1000/2000, omdat er sneller geheugen in zat.
Je ontwerpt natuurlijk je systeem dusdanig dat alles op elkaar aansluit qua performance.
Jij kent de ARM instructie set niet. Just dingen als schuiven + optellen en mask is een enkele ARM instrucktie.
Die ken ik wel. En *binnen een register* kun je dat leuk doen ja. Maar als je een hele bitmap een paar bits moet verplaatsen, moet je dus meerdere registers shiften en met elkaar combineren.
Je hebt dus, zoals ik al zei, *meer* instructies nodig dan alleen load/store. Dus gaat je efficientie omlaag.
Bij de blitter is dit niet het geval, het doorschuiven van bits is 'gratis'.
Dat heet clipping en dat kan de VIDC1a binnen de Archimedes.
Nee, dat heet geen clipping, dat betekent dat een hele loop van:
for (y = lowy; y < highy; y++)
{
for (x = lowx; x < highx; x++)
{
ProcessPixel(x, y);
}
UpdatePointersToNextScanline();
}

1 blitter-operatie is. Geen instructies, geen loops, niks. Dit hele gebeuren doet de blitter als 1 operatie. Alle pointer-updates, het masken van bits aan de randen, het verschuiven van bits om de juiste pixels van source naar destination te kopieren, wordt allemaal automatisch door de blitter gedaan, zonder dat het tijd kost.
Is nl handig voor je window manager. RISCOS was nl het eerste OS dat real time solid windows kon verslepen met een framerate van 25 frames/s Amiga en Atari en Apple versleepten enkel wire frames in die tijd.
De Amiga kon het wel (in games wordt het wel gedaan, en dan wel op 50 fps natuurlijk, ipv 25 fps), maar dat zou het systeem trager maken. Itt RISCOS was AmigaOS namelijk multitasking, en al je bandbreedte verstoken aan het verplaatsen van windows, zodat achtergrondtaken stil komen te liggen, is niet wat je wil.
Exact. De blitter heeft dus veel toegevoegde waarde als het gaat om memory fils en de commodore ontwerpers hebben dit prima uitgevoerd. Een 8 Mhz ARM heeft in tegenstelling van de 68000 wel de capaciteit om full speed het geheugen te vullen en wordt geholpen door de geheugen indeling die geconfigureerd wordt door Memc en IOC (cam mapping). Door de geheugen indeling kan de ARM sequentieel doorschrijven.
Dit is dus een drogreden. Maargoed, je zult het nooit toegeven, hoe vaak ik ook aantoon dat:
1) Een general purpose CPU NOOIT zo efficient is als een blitter (zie nogmaals hierboven).
2) Je dit probleem niet hebt met chip-mem en fast-mem naast elkaar.
3) Dat sequentieel doorschrijven is natuurlijk maar beperkt. Als je echt sprites/karakters/etc op het scherm gaat kopieren en bewegen, dan heb je te maken met de grootte van die sprites/karakters/etc, en de positie waarop ze moeten komen te staan. En dan is je leuke swizzled memory layout ineens niet zo handig.
De blitter is hier al op voorbereid, je kunt per channel aangeven wat de modulo is voor iedere scanline, dus zoals ik al zeg, het kopieren van een 2d-blok naar een willekeurig ander 2d-blok, met verschillende indeling qua scanline-lengte, is geen probleem. Allemaal 1 operatie.
Commodore heeft hier goed over nagedacht maar het blijft een slimme memory fill chip die de 68000 versterkt op de punten waar hij zwak is en dus geen waarde heeft in een RISC architectuur
Nee, want zoals zo vaak aangetoond, ook met een RISC-architectuur, zelfs als die zo slim is als de ARM, zit je meerdere instructies te verstoken om een enkel word met pixels te processen.
Je verbruikt dus WEL de maximale bandbreedte, maar die wordt NIET compleet gebruikt om de daadwerkelijke operaties uit te voeren, maar ook door inefficientie van de general purpose CPU.
Een blitter heeft deze beperking niet.
Een GPU heeft een totaal andere architectuur waarbij je twee hoofd onderdelen moet onderscheiden NL heel veel paralelle data processors en paralelle pixel shaders. (De Voodoo1, de eerste echte GPU werkte al zo) Bijde zijn zelstandige cores die instructies kunnen uitvoeren en dat heel snel doen.
En hoe is dat anders dan de copper+blitter in de Amiga?
De copper en blitter zijn namelijk ook zelfstandig, zoals ik al eerder uitlegde.

Ik kan niet anders doen dan steeds maar weer de conclusie trekken dat je gewoon uit je nek kletst. Zelfs van de kant van ARM/Archimedes klopt je verhaal voor geen meter (de 'code' die je aangeeft voor een blit bv is niet eens een blit, en ook over pixel-adresseren heb ik je nog niet gehoord).
Daarnaast snap je al HELEMAAL niet hoe een Amiga werkt met z'n copper, blitter en fastmem, gezien je uitlatingen over polygons tekenen etc.
Wat doe je eigenlijk in deze discussie?
En hoe lang denk je dit vol te kunnen houden?
Heb je me al gegoogled? Misschien moet je dat eens doen, dan kun je zien wat ik zoal zelf gecode heb op oa de Amiga, en ook op de GP2X, welke twee ARM SoCs gebruikt.
Je denkt toch niet dat je mij kunt overbluffen? Ik weet wel waar ik het over heb.
(De Voodoo1, de eerste echte GPU werkte al zo)
Nee, de Voodoo1 had helemaal geen vertex-processing, en 'pixel shaders' waren niet veel meer dan wat hardwired texturing en gouraud interpolators en een saturated multiply (het is dan ook niet de eerste echte GPU, die kwam pas veel later in de vorm van de GeForce256).
Eigenlijk niet heel anders dan een blitter dus. Behalve dat er geen copper bij zat om hem aan te sturen, dus de CPU dat moest doen, met screen-space paralellograms, stuk voor stuk.
Pas later kon je lijsten van geometrie tegelijk pushen.

[Reactie gewijzigd door Scalibq op 22 juli 2015 15:27]

Een fiets is hetzelfde als een auto er zitten ook wielen onder en het is een vervoersmiddel ;-)
De Archimedes modellen hadden inderdaad een relatief eenvoudige audio- en videochip, maar wel sinds het eerste model in 1987 standaard in staat tot 8 (volledige) kanalen stereo geluid en 640 ◊ 512 met 256 kleuren of 800 ◊ 600 met 16 kleuren (zelfs 1152 ◊ 896 met 2 kleuren). Toch wel aardige capaciteiten voor een homecomputer uit die tijd.

Niettemin moest Archie het inderdaad geheel hebben van z'n 32-bits RISC ARM2, later ARM3, voor z'n prestaties. Maar enkel bemeten op de CPU, veegde deze de vloer aan met de Motorola 68000 en Intel x86 reeks uit die tijd...

Het zou ontzettend gaaf zijn als Tweakers eens een artikel doet over Acorn, met name de relatief onbekende Archimedes en later Risc PC machines. Niet alleen de bakermat van de ARM architectuur, maar tevens een Europese computerfabrikant wanneer bijna alle andere jongens vanuit de overkant van de oceaan kwamen :)
Had ook te maken met de robuustheid van de Atari ST bv als het om bv de tempratuur en vochtigheid gaat . Ik weet niet of het een algemeen probleem was, maar ik ken iig wel wat annekdotes over oververhitte Amiga's. Eind jaren 80 waren ook wel kits voor de MSX2 waar je hetzelfde mee kon.
Zolang je de processor nergens anders voor gebruikte kon je uit Atari ST overigens best redelijke samples halen dat was voor de C64 te hoog gegrepen , maar de Amiga kon dat natuurlijk beter.
Had ook te maken met de robuustheid van de Atari ST bv als het om bv de tempratuur en vochtigheid gaat . Ik weet niet of het een algemeen probleem was, maar ik ken iig wel wat annekdotes over oververhitte Amiga's.
De Atari ST is juist legendarisch vanwege z'n slechte betrouwbaarheid, omdat hij zo goedkoop geproduceerd moet worden.
Een bekend verhaal aan de ST is dat de chips na verloop van tijd niet goed contact meer maakten in hun socket. De oplossing was om de computer gewoon op te tillen en plat op de tafel te laten vallen, zodat de chips weer goed kwamen te zitten.
Zie ook hier: https://en.wikipedia.org/wiki/Atari_ST
"Atari Twist" en "Atari Drop"
Zolang je de processor nergens anders voor gebruikte kon je uit Atari ST overigens best redelijke samples halen dat was voor de C64 te hoog gegrepen , maar de Amiga kon dat natuurlijk beter.
Op een C64 kun je anders 8-bit samples spelen op 44 KHz, zoals in Mahoney's Musik Run/Stop demo: https://youtu.be/bDuwh2HOkKA

[Reactie gewijzigd door Scalibq op 19 juli 2015 13:56]

Check filmpje vanaf ongeveer 12:30 wat iemand ie het kan weten over crashen e.d. van de Amiga ;) HW misschien okay, alleen de software was minder...

[Reactie gewijzigd door bonus op 19 juli 2015 17:31]

Ja, dat is het OS, dat was in de eerste versies niet zo robuust. Maar dat heeft niets te maken het overhitting van de hardware of wat er verder geclaimd werd.
Dat geldt alleen voor de eerste generatie ST 's (toen de amiga nog niet eens uit was) en was eenvoudig op te lossen. Daarnaast waren de eerste amiga's zo ongeveer onbruikbaar doordat het OS om de haverklap crashte.
Huh? Nooit problemen mee gehad. Maar dat kwam dat dat alleen voorkwam bij de EARLY Atari ST's geldde. (leer aub Wiki's lezen) In de tijd dus dat de Amiga 1000 nog behoorlijk veel duurder was en niet in een werkbare configuratie voor muzikanten beschikbaar was. Pas na de vereenvoudige versie ... de Amiga 500 werd die computer betaalbaar, draagbaar en dus populair
Knappe demo! Maar sommige samples klinken veel te slecht voor 44 KHZ (4.4KHZ eerder) en een deel is gewoon chiptune. Maar met 1 echte 44 KHZ sample zou de 64Kb ook al vol zitten natuurlijk :D
Heb je nog andere voorbeelden ?
Ik kan hier een welles niets spelletje van maken, maar deze flame nonsens laat ik maar verder over aan het oordeel van de lezer. Op de wiki staat alleen maar dat in het begin de 520ST daar last van had.
Het truukje wat wsl gebruikt wordt bij de demo is precalc op een veel snellere computer om de Sid van z'n hardwarematige 4KHz omhoog te tillen. Knap truukje , maar eind jaren 80 niet bruikbaar waar we het hier het eerst over hadden
Erm, de SID heeft helemaal geen 'hardwarematige 4 KHz'.
De SID is uberhaupt niet ontworpen om samples te spelen. Het zijn C64-hackers die bugs/glitches hebben ontdekt in de SID, en deze uitbuiten om samples te spelen.
Dit doe je door met de CPU op het juiste moment naar de juiste SID-registers te schrijven (er is dus geen 'sample rate', behalve dan hoe snel je je CPU-code laat lopen).
Met de 6510 CPU in de C64 kan dat in theorie met maximaal ~75 KHz, maar Mahoney heeft gekozen voor 44 KHz omdat dat 'goed genoeg' is (CD-kwaliteit), en omdat hij zo CPU-tijd over had voor wat decompressie van samples, en het updaten van graphics.
Mahoney heeft dit allemaal heel duidelijk gedocumenteerd. Dit alles is op een standaard C64, en had in 1982 ook gekund, men wist toen alleen nog niet hoe. De eerste sample-methode leverde 4-bit geluid op in plaats van latere methoden met 8-bit. Maar ook toen al kon je hoge samplerates halen, ten koste van veel geheugen, en uiteraard CPU-cycles. Dus samples tijdens een game voor geluidseffecten oid waren niet zulke hoge kwaliteit om die redenen. Niet omdat de SID het niet kan.

Verder constateer ik dat:
1) Jij begint met het ophemelen van de Atari ST, en ongefundeerde claims over slechte betrouwbaarheid van de Amiga in een topic dat gaat over een feest ter ere van de Amiga.
2) Je dingen roept oa over de C64 die aangeven dat je niet weet waar je het over hebt.

Ik denk dat beiden in dit topic niet zo heel handig zijn van je.

[Reactie gewijzigd door Scalibq op 19 juli 2015 14:50]

https://www.c64-wiki.com/index.php/SID
De tone generators van de SID hebben een frequentie bereik van 0-4KHz... daarboven is al gauw flauwekul. Met truukjes vast uit te breiden (daarom heb ik het ook over precalc) , maar dat geeft nog geen daadwerkelijke 75 KHz output
https://en.wikipedia.org/wiki/General_Instrument_AY-3-8910
De chip van Atari ST heeft 125KHz tone generators. Daar is de tone generator niet de beperkende factor.

Verder constateer ik dat:
1. Ik niet degene was die Atari ST ter sprake bracht. Het een vrij bekend gegeven is dat muzikanten heel lang ook op podia diezelfde Atari ST's zijn blijven gebruiken. Wat mijn punt ... de robuustheid op het gebied van tempratuur en vochtigheid onderstreept.
2. Jij meer op de hoogte van flame onzin lijkt te zijn dan daadwerkelijk onderzoek te doen naar de feiten over de Atari ST. Leer begrijpend lezen.

[Reactie gewijzigd door AtariXLfanboy op 19 juli 2015 15:19]

https://www.c64-wiki.com/index.php/SID
De tone generators van de SID hebben een frequentie bereik van 0-4KHz... daarboven is al gauw flauwekul. Met truukjes vast uit te breiden (daarom heb ik het ook over precalc) , maar dat geeft nog geen daadwerkelijke 75 KHz output
Leuk geprobeerd, maar jij maakt hier de aanname dat samples spelen via de tone-generators gaat. Dit is niet het geval.
Je hebt dus niets te maken met het frekwentiebereik van die tonegenerators.
Je kunt dus WEL daadwerkelijk 75 KHz output krijgen (zoals te lezen valt in de beschrijving van Mahoney: http://www.livet.se/mahon..._Mahoney_Tufvesson_v2.pdf).

In het digitale domein betekent '75 KHz' niets meer en niets minder dan dat je 75000 keer per seconde een sample afspeelt. Dus, 75000 keer per seconde de juiste SID-registers zetten om een 8-bit sample af te spelen, dat is mogelijk.
Zoals je kunt lezen, hoeft bij de methode van Mahoney de SID alleen maar 1 keer geinitialiseerd te worden, waarna je met het schrijven van 1 byte naar een register een nieuwe sample kunt triggeren.
Wat mijn punt ... de robuustheid op het gebied van tempratuur en vochtigheid onderstreept.
Vind je? Ten eerste zegt het weinig. Je ziet ook overal Marshall gitaarversterkers staan, maar die zijn echt niet zo betrouwbaar. Muzikanten hebben gewoon een reserve bij zich, en laten ze vaak repareren (ik heb er zelf twee, de ene doet het vaker niet dan wel).
Misschien gaat dat met de Atari ST ook zo.
Ten tweede, het feit dat men daar Atari ST gebruikt, zegt nog niet dat alle andere computers dat NIET zouden kunnen.
Voor een computer zijn die omstandigheden echt niet zo extreem. En als er per ongeluk een glas bier overheen gaat, gaat een Atari ST net zo hard stuk als alle andere computers.

Wat mij betreft is het enige dat duidelijk is dat de Atari ST de standaard was voor midi omdat Cubase prima software was, en omdat je op de Atari ST standaard midi had, dus je hoefde geen extra hardware mee te slepen.
2. Jij meer op de hoogte van flame onzin lijkt te zijn dan daadwerkelijk onderzoek te doen naar de feiten over de Atari ST. Leer begrijpend lezen.
Ik heb toevallig zelf zo'n Atari 1040STe met Cubase (want naast demos coden maak ik ook muziek). Ik weet exact wat voor computer dat is, en hoe goed of slecht ie in elkaar zit, en hoe betrouwbaar ie is. Dat hoef ik niet op internet te lezen.

[Reactie gewijzigd door Scalibq op 19 juli 2015 15:29]

Interessant leesvoer thx (nu ff geen tijd voor... ik zal het nog eens doorlezen) Maar ik lees iig in het begin erin dat dit soort truukjes pas ver na de hoogtijdagen van de Atari ST bekend zijn geworden.
Ik heb nooit een Atari 1040STe gehad, maar nooit met de Atari 1040STfm problemen gehad (behalve slijtage van de muis en het toetsenbord na 10 jaar ofzo, maar eh.. laten we het daar niet over de Amiga 500 hebben :D )
Die annekdotes over de Amiga zijn vooral uit eigen waarneming bij anderen thuis. Enthousiaste Amiga fans die hun computer toonden die toch niet zo goed en stabiel bleken te werken als ze eerst claimden. (Zelfs met eigengemaakte koeling erop)
Tja zoals wat ik wel vaker hier op tweakers lees vindt je jezelf alwetend, maar juist dan sla je de plank vaak mis.

[Reactie gewijzigd door AtariXLfanboy op 19 juli 2015 15:49]

Maar ik lees iig in het begin erin dat dit soort truukjes pas ver na de hoogtijdagen van de Atari ST bekend zijn geworden.
8-bit samples zjin relatief nieuw ja.
Maar de beproefde 4-bit techniek is al heel vroeg ontdekt, die zat bv al in Imposible Mission uit 1984. Dat is dus nog ouder dan de Atari ST zelf.
En zoals je daar ook kunt lezen, ook die techniek heeft maar 1 register-write nodig (en werkt dus via het volume-register, niet via de tone-generator), dus ook daar zou je die 75 KHz mee kunnen halen.
Die annekdotes over de Amiga zijn vooral uit eigen waarneming bij anderen thuis. Enthousiaste Amiga fans die hun computer toonden die toch niet zo goed en stabiel bleken te werken als ze eerst claimden. (Zelfs met eigengemaakte koeling erop)
Dan vraag ik me af wat ze ermee gedaan hebben, want een standaard Amiga wordt helemaal niet heet. Zeker een simpele 500 niet, met een bescheiden 7 MHz CPU. Dat is allemaal passief gekoeld. Een Atari ST wordt veel heter, omdat zoals ik al zei, de PSU in de systeemkast zit, ipv erbuiten (en ook passief gekoeld).
Ik heb nog nooit iemand gezien die op een standaard-Amiga koeling had gebouwd.
Alleen mensen die er supersnelle CPUs in bouwen, allerlei harddisks etc, waar het systeem natuurlijk nooit op ontworpen was (zeker de passief gekoelde A1200 niet).
Tja zoals wat ik wel vaker hier op tweakers lees vindt je jezelf alwetend, maar juist dan sla je de plank vaak mis.
Waar is deze opmerking nu weer voor nodig?
Ik sla de plank nooit mis, het zijn vooral mensen als jij die dat beweren als ze voor de zoveelste keer erop gewezen worden dat ze onzin verkopen. Zoals ook hier. Jij bent hier degene die uit z'n nek loopt te kletsen over wat de SID wel of niet zou kunnen. Ik had die paper van Mahoney al eerder genoemd, had alleen zelf de link nog niet opgezocht. Had je zelf al moeten doen. Maar nee, je bleef drammen dat je gelijk had. En nu huilen dat toch blijkt dat je onzin praatte, dus dan mij maar weer aanvallen.

Ik zorg tenminste dat ik weet waarover ik praat. Als jij dat ook zou doen, dan zou je ons allebei dit gedoe besparen.

[Reactie gewijzigd door Scalibq op 19 juli 2015 16:18]

'Ik sla de plank nooit mis' Pff je lult net zo lang uit je nek tot anderen opgeven bedoel je ? Ik blijf niet drammen dat ik gelijk had waar doe ik dat dan?
Jij creŽert desnoods je eigen bijzondere realiteit. Waar muzikanten twee Atari ST's kopen om ze om en om te kunnen repareren. Dan zou ik zeker nog aan moeten tonen dat ze niet deden ? Dat soort redenaties volslagen flauwekul zijn laat ik maar verder weer over aan het oordeel van de lezer.
En wat blijft er dan over van je hele onzin verhaal dat Atari ST's niet robuust zou zijn ? Een uit het verband gerukte wiki quote en een persoonlijke ervaring met 1 STe en Cubase.
Dat ik niet op de hoogte was van ťťn demo die blijkbaar een zeer bijzondere truuk heeft gevonden (ik kan het niet horen aan de kwaliteit) die theoretisch dat haalt ja. Ontken ik dat je daar ongelijk heb? Maar jij bent daarna gelijk weer zo kinderachtig om gelijk mij maar te typeren als geen verstand heb van de SID. Dat die demo niet de 1e prijs gewonnen en ook geen speciale aandacht op Pouet zegt mij wat dat de claims wat overtrokken zijn.
Die ventilator was puur voor een geheugenuitbreiding (en geen spectulaire) Dat was vermoedelijk geen Amiga 500. Maar daar heb ik verscheidene van eind jaren 90 gezien waar van fysiek van alles aan mankeerde.
En dit is niet de eerste keer dat een discussie met jou zo eindigt.
'Ik sla de plank nooit mis' Pff je lult net zo lang uit je nek tot anderen opgeven bedoel je ?
Waar klets ik uit m'n nek dan? Alles wat ik beweerde over de SID, is te lezen in de paper van Mahoney. En dat spreekt dus alle claims tegen die jij over de SID maakte.
Ik blijf niet drammen dat ik gelijk had waar doe ik dat dan?
Je begon met dit:
Zolang je de processor nergens anders voor gebruikte kon je uit Atari ST overigens best redelijke samples halen dat was voor de C64 te hoog gegrepen.
Vervolgens verwijs ik naar een demo van Mahoney die 8-bit 44 KHz speelt op een C64. Daar ga je tegenin, omdat je toch je gelijk wilt halen... Ik zeg erbij dat Mahoney dit allemaal gedocumenteerd heeft, en dat zelfs 75 KHz haalbaar is in theorie, maar vanwege allerlei limieten, voornamelijk geheugen, in de praktijk niet handig is.
En NOG heb je een paar posts eraan gewijd, om het te ontkennen ('trucje' dit, 'precalc' dat, 'hardwarematige 4 KHz' zus...)
Dat vind ik drammen ja. Na mijn eerste verwijzing naar Mahoney's Musik Run/Stop had je dit punt al moeten laten varen, en liefst zelf ook even opgezocht hoe Mahoney dit gedaan heeft.
Jij creŽert desnoods je eigen bijzondere realiteit. Waar muzikanten twee Atari ST's kopen om ze om en om te kunnen repareren. Dan zou ik zeker nog aan moeten tonen dat ze niet deden ?
Je hoeft helemaal niets aan te tonen. Ik zeg alleen dat de bewering dat muzikanten alleen maar betrouwbare apparatuur gebruiken onjuist is. Dus aan het feit dat een muzikant bepaalde apparatuur gebruikt, kun je niet afleiden of die apparatuur betrouwbaar is of niet, laat staan dat andere apparatuur minder betrouwbaar zou zijn.
Daar is overigens niets flauwekul aan, dat is gewoon simpele logica.

Muzikanten zijn juist bij uitstek mensen die naar een specifiek geluid zoeken, en daarbij allerlei problemen op de koop toe willen nemen. Kijk bv eens naar analoge synthesizers, Rhodes piano's, Hammond-orgels, of gitaristen met buizenversterkers en vintage analoge effecten.
Die zijn allemaal veel storingsgevoeliger dan moderne apparatuur, maar het geluid vinden ze belangrijker dan het praktische aspect.
En wat blijft er dan over van je hele onzin verhaal dat Atari ST's niet robuust zou zijn ? Een uit het verband gerukte wiki quote en een persoonlijke ervaring met 1 STe en Cubase.
Nee, dit is een drogreden. Het feit dat het op wikipedia staat, toont aan dat er bekende problemen zijn met de betrouwbaarheid van bepaalde STs. Als je zou willen, zou je hier nog veel meer over kunnen vinden op het internet. Jij wil nu net doen alsof het ALLEEN op wikipedia staat, en dat het dan ook nog eens 'uit het verband gerukt is'.
Dat verhaal van de Atari ST laten vallen om de chips te re-seaten ken ik nog van uit de tijd lang voordat wikipedia bestond.
Maar jij bent daarna gelijk weer zo kinderachtig om gelijk mij maar te typeren als geen verstand heb van de SID.
Dat is niet kinderachtig, dat is een constatering uit het feit dat jij de tonegenerator aanhaalt, terwijl wij het hier over sample-playback hebben.
Jij weet blijkbaar niet hoe samples gespeeld worden op een SID.
Dat terwijl je je presenteert alsof je er alles van weet, en strooit met dingen als 'tonegenerator 4 KHz' etc.
En dit is niet de eerste keer dat een discussie met jou zo eindigt.
Jij bent ook niet de enige die z'n ongelijk niet kan toegeven.

[Reactie gewijzigd door Scalibq op 19 juli 2015 19:40]

Jeemig wat een lekkere ouwerwetse Atari<->Amiga war ! ;)

En ik ben notabene degene die als eerste de 'ST' vermelde hierboven...sorry...zal ik niet meer doen :+
Het ťťn sluit het ander niet uit ;)

Ik ben zelf in het bezit van ťťn van de 3 amiga's waarop deze track is gemaakt:
https://www.youtube.com/watch?v=7oS0fTCYvqc

Ik heb zelf ook jarenlang op de amiga geproduceerd. Ik heb bakken vol met 'gabber' samples. Daarnaast heb ik veel copy'tjes van house tracks die toendertijd gemaakt zijn. Het leuke van toen was dat je creativiteit getriggerd werd, ipv de ontelbare mogelijkheden die vst(i)'s nu met zich meebrengen.

De amiga staat nu veilig opgeborgen ;)
Neophyte, altijd goed _/-\o_
DIY

OCTAMED STUDIO!

1 van de eerste trackers waarmee ik gewerkt heb!
En het leuke is, Protracker heeft sinds kort ook een Windows port! De ontwikkelaar, Eightbitbubsy, heeft een aantal jaar (!!) geinvesteerd in het emuleren van de Amiga sound in een replayer, en vervolgens heeft hij maar gelijk de hele editor erook bij geport. Tijdje terug heb ik het geprobeerd en toen werkte het al prima, dus wie weer muziek wilt maken met het programma uit hun jeugd, dit is jullie kans.

http://16-bits.org/pt.php
Leuk! Ik heb een tijd Renoise gebruikt, maar dat is het toch niet helemaal. Jaren met Cubase gewerkt, en is leuk, maar evenaart niet het rauwe van trackers itt sequencers. Ik ga hem zeker even proberen :)
Mocht je nu toch terug willen keren naar Renoise, misschien is Revisit dan iets voor je? Gebaseerd op, inderdaad, de Protracker en aanverwante trackers (Impulse Tracker) ;) (Kost wel centjes trouwens)

http://revisit.info/

[Reactie gewijzigd door Redneckerz op 19 juli 2015 14:42]

Leuk die port. Ga misschien weer eens wat klooien. Er zal qua samples veel te krijgen zijn op het net maar als jullie nog een goede bron weten.. graag!
Nou, wat dacht je van alle Amiga Soundtracker sample packs? Allemaal als Wave File, dus zo te gebruiken :)

https://archive.org/detai...ndtrackerSamplePacksst-xx
Oh ja. Meteen prijs met die originele samples. Thanks! :)
Als je nog iets anders nodig hebt betreffende trackers, samples, tools - Drop een PM :)
Kam trouwens deze leuke timeline tegen. Informatief:
https://chipflip.wordpress.com/timeline/
Yep, die is mij bekend - Ik heb deels bijgedragen aan diens geschiedenis van trackers een aantal jaar terug :) Bedankt voor de link, altijd leuk om het weer eens terug te zien.
Kan het me nog wel goed herinneren. Een Amiga 1000. De demo's, geluiden, graphics. En ondertussen speelde je op de PC nog met een monochrome scherm en kwam het geluid niet veel verder dan een "bleep" uit de PC speaker.

Het verschil in prijs in deze 2 systemen was dan ook enorm. Er was niets wat de Amiga niet kon toen.
Leuke reportage. "Brings back memories :)"
Als pc hersteller zie ik soms gekke dingen ... ergens in de lente van vorig jaar kwam ik bij een oudere dame die problemen had met haar laptop; ik loste haar problemen op en toen kwam haar man binnen; die zij tegen z'n vrouw: 'schat ik zit in de videokamer, ik heb nog veel videowerk te doen' ..
ik vroeg dan aan die vrouw of ze dus een workstation of krachtige pc gebruiken en die vrouw antwoordde doodleuk:'neen, hij werkt nog steeds op z'n computer van meer dan 25 jaar oud om die dingen te doen; hij is blijven hangen in de tijd met zijn computer'. en dat gaf me wel een beetje een interesse om die 'oude computer' eens te zien; tenslotte hoor je niet elke dag dat iemand op zo'n oud systeem zit te werken... ik verwachte dan ook een oude windows bak of een oude apple. de dame vroeg me of ik het 'ding' eens wilde zien, uiteraard zei ik meteen ja...
ik kom daar in een bijkamer (eigenlijk slaapkamer 2 maar zonder bed) en die man had daar een 2 meter lange tafel omgebouwd tot bureau en daar stonden dan 2 monitors, enkele diskdrives (extern) een matrix printer, A/V-kabels, een DAT audio-reel en helemaal in het midden van die tafel stond hij dan; een amiga 2000!
De man was bezig met het aansluiten van een videocamera aan de av-inputs van het toestel en ik vroeg hem ondertussen; "wow, een amiga 2000; na al die jaren bent u zeker gehecht aan deze computer?"
De man vertelde me toen dat hij over de jaren heen de A2000 een paar upgrades heeft gegevens zoals cpu+ram en een speciale video-edit kaart (toast), hij werkt al meer dan 25 jaar met die computer om oa video te bewerken en surfte er ook mee op het internet totdat flash is beginnen op te komen. De originele opzet was dat hij hem zou gebruiken totdat het toestel kapot zou gaan... maar hij werkt dus nog steeds en het is zijn favoriete omgeving om videobewerking te doen, al gaf hij toe dat de computer wel traag is in vergelijking met zijn laptop met windows 7 erop... ik vertelde de man dat ik het enorm knap vond dat een systeem na zoveel jaar nog steeds gebruikt wordt en dat ik had gelezen dat amiga's nog steeds worden gemaakt, weliswaar met modernere hardware erin; de man wist dit niet en zei me dat hij dat enorm interessant vond; hij bedankte me voor de tip, ik antwoordde daarop dat hij wel z'n 'oude' systeem niet mag weggooien want dat zou enorme zonde zijn... 'kijk eens hoeveel plaats er nog op die tafel is' was zijn antwoord!
ik bedankte de man om in zijn kamer te mogen kijken en wenste hem nog veel succes met z'n amiga; maar ik moest verder naar de volgende klant...
Tweakers zou aan deze man een eigen interview video kunnen besteden ! Ik denk dat een boel mensen dat erg leuk zouden vinden en hij zelf ook als waardering voor zijn volharding.
denk je??? het is geen verzamelaar, noch een tweaker...
de man kent volgens mij tweakers.net zelfs helemaal niet...

hij gebruikt gewoon al jaar en dag een amiga om video's te bewerken... ik denk dat je dat wel nog vaker zult terugvinden, en mogelijk dat je ook verzamelaars hebt die hun amiga nog steeds gebruiken (mogelijk de a2000x ofzo; deze is veel sneller/nieuwer/moderner).
Tweakers.net had gerust zulke mensen kunnen vinden op de meeting die ze bijgewoond hebben; dus ik denk niet dat ze echt geinteresseerd zullen zijn in die oudere man die het systeem nog altijd gebruikt omdat het gewoon doet wat hij ervan verwacht en hij door de jaren heen weliswaar een band met de machine heeft opgebouwd (zou iedereen doen die zo lang hetzelfde systeem blijft gebruiken; ik vond het bv indertijd heel spijtig om mijn radeon 9700 pro te vervangen omdat die zo lang zo goed werk heeft geleverd; achteraf zelfs dik spijt van gehad omdat de nieuwe kaart (nvidia) zo snel stuk ging; beruchte 8800 reeks die nvidia nooit correct heeft behandeld ondanks ze op een gegeven moment wisten dat er een mankement was)

Moest t.net alsnog interesse hebben; ze kunnen me gerust pm'en, ik zal dan eens opzoeken of ik die klant z'n naam nog kan terugvinden (haar naam eigenlijk, want de vrouw was de klant) en indien ja zal ik dan contact nemen met de vraag of ze akkoord zouden gaan met een video-interview over die amiga-setup door de grootste technologiesite v/d benelux.
indien geen vraag van tweakers, dan start ik zelfs niet met opzoeken uiteraard...
Tja dan niet jij zegt het, je zult het wel beter weten dan hijzelf ;(

Het was goed bedoeld, want neem van mij aan mensen die zolang met hun spullen doen, praten er graag over.

[Reactie gewijzigd door Vinzz op 19 juli 2015 20:15]

Dat verschil begreep ik toen ook nooit goed. Totdat ik een 286 kreeg met 640K en Turbo Pascal erop. Met groen monochroom beeld en pc-speaker, maar de prestaties overtroffen alle home-computers.

Ik denk het verschil tussen de computer als entertainment of voor "zakelijk" gebruik.
Ik zou verwachten dat de 68000-processor van de Amiga meer rekenkracht heeft dan een 286: De 32-bit brede registers en gescheiden data- en adresregisters maken het een stuk efficiŽnter dan een 286. De 286 had wel de protected mode, waarmee de stabiliteit enorm verhoogd kon worden, maar daar werd in die tijd juist geen gebruik van gemaakt.
De 286 was wel een paar jaar moderner dan de 68000. De 68000 een generatiegenoot van de 8088 en 8086. De 286 is puur qua rekenkracht dan ook sneller. Maar vanwege beperkingen zowel aan het 16-bit geheugenmodel, en aan de rest van de PC (gebrek aan goede DMA, interrupt-driven hardware, en custom chips, zoals Dave Haynie in het filmpje al uitlegt), kon je met een PC veel minder met dezelfde CPU.
Veel spellen die op een standaard Amiga 500 goed draaiden, hadden in de PC-versie een VGA-kaart en geluidskaart nodig en een 286 of 386SX nodig op 16 MHz of meer. En dan nog hadden ze meestal minder kleuren op het scherm, minder soepele scrolling, en minder goede muziek.
Waar komt die rekenkracht dan vandaan? Voor een 32-bit vermenigvuldiging heb je op een 286 bijvoorbeeld een flinke hoeveelheid instructies en registers nodig, waarvan ik me amper kan voorstellen dat een enkele MULS-instructie op de 68000 meer tijd zou kosten.

Het is wel zo dat Intel in 1986 al met de 386 kwam en de 386 was wel (dankzij 32-bit ťn hoge kloksnelheid) een stuk krachtiger. Die was echter zo duur dat er destijd nog weinig apparaten mee uitgerust werden.
Waar komt die rekenkracht dan vandaan? Voor een 32-bit vermenigvuldiging heb je op een 286 bijvoorbeeld een flinke hoeveelheid instructies en registers nodig, waarvan ik me amper kan voorstellen dat een enkele MULS-instructie op de 68000 meer tijd zou kosten.
Een 68000 kan net als de 286 alleen 16*16 = 32-bit multiplies (MULS.W, andere varianten zijn pas op 020 en later).
De 286 kan dit in 21 cycles, omdat er een gepipelinede implementatie in zit (wat veel meer transistors kost, dat is het verschil tussen 1979 en 1982, wet van Moore enzo).
Een 68000 heeft een mul geimplementeerd in microcode (net als bv de 8088/8086), en dat kost 70 cycles.

De 68000 is dan ook een CPU met een 16-bit databus, grotendeels 16-bit ALU, 32-bit registers en een 24-bit adresbus. Hij is niet volledig 32-bit.

[Reactie gewijzigd door Scalibq op 19 juli 2015 12:25]

Ik was daar ook en het was erg leuk op de show, allen was het vervelend dat er geen stoelen waren tijdens het spreken.

Ben daar bijna 6 uur lang geweest met een goed vriend, ik sta ook op deze filmpje.

Leuk om weer met al die Amiga fans te wezen, en bijzonder dat mensen met hun Amiga kwamen voor handtekeningen.
80386 25Mhz gehad.
Maar ipv 80387 er Weitec Copro bij gezet.
Voor de Falcon game.
De MC68000 is de tegenhanger van de 80286, waar de 68000 veel efficiŽnter is. Die efficiŽntie-voorsprong bleef Motorola (later met IBM in de PPC) houden totdat Intel met de Core 2 architectuur kwam.

Wat ik denk dat blorf bedoelt, is dat de IBM PC en zijn afgeleiden veel sneller waren dan de Z80 / MC65xx / MC68xx homecomputers (C64, ZX Spectrum, BBC, …).
Dat Motorola zo lang efficiŽnter is gebeleven dan Intel is zeker niet waar. Zo rond 1990 werd de 386 populair en die maakte het aanbod van Motorola behoorlijk in. Dat is ook een achterliggende reden van de ondergang van Commodore. Atari idem dito en bij Apple heeft het ook niet veel gescheeld: Die zaten nog op 68000 toen Intel de Pentium uitbracht. Het is dat Apple door deel te nemen in het PowerPC-monsterverbond weer een concurrerende processor kon krijgen, anders was het voor Apple ook afgelopen geweest.

De IBM PC, zoals hij in de jaren '80 meestal geleverd werd, was dan weer extreem traag: Ze werden geleverd met een 8088-processor waarvan de bus bovendien nog afgeknepen was dat er maar ťťns in de 4 klokpulse en byte van/naar het geheugen kon gaan. Met 4,77 MHz gedeeld door 4 bleef er dan erg weinig snelheid over. De PC was nog steeds wel een stuk krachtiger dan de 8-bit computers, maar een Commodore 64 hoefte zich kwa rekenkracht zeker niet te schamen t.o.v. een IBM PC.
Dat Motorola zo lang efficiŽnter is gebeleven dan Intel is zeker niet waar. Zo rond 1990 werd de 386 populair en die maakte het aanbod van Motorola behoorlijk in.
Zoals Scalibq al had gezegd: de MC680x0 reeks kon tot aan de pentium goed meedoen. Tot en met de 68040 / i486DX liep Motorola voor, de 68060 kon de Pentium net bijhouden.

En dat het daarna met de 68000 serie over was, is duidelijk. Maar Motorola ging toen in zee met IBM (en Apple), wat ik ook al had vermeld:
Die efficiŽntie-voorsprong bleef Motorola (later met IBM in de PPC) houden
De IBM XT met 8088 of 8086 CPU was traag. De IBM AT met 80286 was qua rekenkracht sneller dan alle eerder genoemde 8-bits homecomputers, maar langzamer dan de MC68000 gebaseerde systemen (Atari ST/TT/Falcon, Amiga, Sinclair QL).

Toen de Pentiums de 4 GHz klokfrequentie haalden, toen was koeling een probleem. Het leek wel of de primaire functie van zo'n systeem een oven was, en dat rekenen op de tweede plek kwam. Intel had door dat het anders moest, en bedacht de Core architectuur (die enige gelijkenis met de PPC heeft overigens). De klok ging terug naar 1,6 GHz, maar de prestaties bleven. Op dat moment had Intel de PPC van Motorola en IBM ingehaald.
ikweet het beter vrees ik ...

de core achitectuur kwamen we bij intel al eerder tegen... deze is namelijk gebaseerd op de Pentium M. (centrino any1?); en die is op zijn beurt weer een doorontwikkeling van die goede oude Pentium 3; deze had namelijk een vťťťťl betere performance/clockratio dan de netburst P4's (die waren puur ontwikkeld om de megahertz race te winnen van AMD; welke de 1GHz cpu namelijk voor intel op de markt had gebracht en daarmee een belangrijke mijlpaal had gewonnen met bijhorende verkoopcijfers (AMD Athlon); door die netburst technologie te kiezen werd intel gedwongen om cpu's minimum op 1,7 ghz en hoger te klokken omdat ze anders tť traag zouden presteren tov de P3, bovendien leverden de athlons op dat moment meer performance/hz en waren ze nog eens goedkoper dan intel cpu's)
Uiteraard was de P3 een doorontwikkeling van de PPRO; welke risc bevatte ...
je kan vandaag niet zeggen dat de x86 cpu's RISC zijn, maar evenmin dat ze CISC zijn... ze zijn beide en daarom noemen we het hybride cpu's (yup, zoals hybride auto's)
Nou nee. Ten eerste brengt elke Dieshrink meer transistors per Die oppervlak die hoger geklokt kunnen maar dan wel met meer vermogen.
De grens van performance wordt verlegt maar wel met meer vermogen.
We zijn van Passief 8086 tot 100+wat aktieve koeling gegaan. Door dieshrinks.

Maar P4 is een anderverhaal. Dat Netburst met dieper pipeline met kleiner tussen stappen zodat er veel hoger geklokt kan worden. Alleen beginnen de lekstromen parten te spelen. En ook alleen omdat er een referentie punt is de concurrent die stuk zuiniger is. Eigenlijk normal verbruik. Tegen veel meer verbruik.
Maar iNtel had ook naast de P4 op 130nm ook tulatin 130nm op Pentium basis.

Een 8086 of 68000 op 14nm zou zo klein zijn en amper iets verbruiken dat knopcell genoeg is. Misschien zoiets minimalistisch in huidige digitale horloges van Casio.

Maar er is een streven naar meer performance bij bepaald vermogen en prijs. Cores zijn groter complexer en er passen nu een veelvoud op een die. Met FPU en GPU eventueel.

Daarbij de PC gamemarkt kwam op. En de meest complete CPU heeft dan voordeel. Nu al Jaren met dedicated GPU speeld dat geen rol meer.

Wist nog Dat ik PIII 450Mhz upgrade kocht voor Voxel base game kocht Comanche Overkill van novalogic. Een van de latere games die nog leunde op software rendering.
Dat Motorola zo lang efficiŽnter is gebeleven dan Intel is zeker niet waar. Zo rond 1990 werd de 386 populair en die maakte het aanbod van Motorola behoorlijk in. Dat is ook een achterliggende reden van de ondergang van Commodore. Atari idem dito en bij Apple heeft het ook niet veel gescheeld: Die zaten nog op 68000 toen Intel de Pentium uitbracht.
Da's ook weer niet helemaal waar.
Motorola kon jarenlang goed meekomen met Intel, met hun updates van de 68k-serie. Zo waren de 020, 030 en 040 best goede alternatieven voor de 286, 386 en 486, en de 060 was misschien iets minder dan een Pentium, maar nog steeds een behoorlijk snelle superscalar CPU, met een RISC-achtig backend, wat we in de Pentium Pro later ook zouden zien.

Het probleem was vooral dat Commodore en Atari op de thuismarkt inzetten, waardoor de prijs laag moest blijven. Daardoor werden helaas de professionele modellen die wel de snelle CPUs hadden, niet zo serieus genomen. Voor een 'professioneel' systeem kocht men dan een PC met een 386 of 486, in plaats van bv een Amiga 4000/040 of een Atari Falcon.
De 68000 is uit 1979 (volgde dus vrij kort op de 8086 uit 1978), de 286 is uit 1982. De 286 is wel degelijk efficienter met het uitvoeren van instructies. Het grote nadeel is de beperkte 16-bit x86-instructieset, waardoor je vaak meer instructies nodig had, dat het weer enigszins compenseerde.
Maar vergis je niet, een 68000 an sich is niet zo heel snel. Bij de Amiga is het vooral de custom chipset die het grote verschil maakte met de PC.

[Reactie gewijzigd door Scalibq op 19 juli 2015 20:33]

De Intel x86 architectuur is een CISC instructieset op een (voor die tijd) complexe processor, met een zeer complex geheugenbeheer (er zijn 32 bits nodig om een 20 bits adres samen te stellen).

Het revolutionaire aan de 68000 serie was dat het ook een complexe instructieset heeft, maar dat deze uitgevoerd worden door een RISC core.

En de 68000 reeks had visie. Intern was alles 32-bits (in een tijdperk dat de rest van de wereld nog geheel 8-bits was!!!), extern waren er verschillen. Er was een 8-bits versie (68008; Sinclair QL), 16-bits (68000; Atari, Amiga, Mac), en 32 bits (68010/020/030/040/060).

De 68000 was wel snel, maar is natuurlijk wel beperkt. Het is niet voor niets dat audio en video door andere, dedicated, processoren werd gedaan. Bij de Amiga hadden ze dat door; fabrikanten die dat niet doorhadden, maakten computers die hooguit wat bliepjes konden laten horen ipv muziek.
Een Office werker die eerst met typemachine werkte is 8086 XT als veredelde typemachine een zeer extreme stap vooruit.

Maar zat je toen in grafische sector dan is Amiga juist de inovatie.
Maar ja de massa kan zonder.
Alleen voor thuis gebruik breekt wat het meest bekend is. Juist die veredelde type machine.

Ik denk dat iNtel het gewoon zo ziet. Die Office bakken is volume markt.
De oorsprong dat iNtel de OEM markten ook zo heerst. En extra chips maken het duur en specialistisch. Daar is de Add-on markten voor.
Dat is niet helemaal hoe het zat. Een PC was destijds veel en veel duurder dan een Amiga. Als je de moederborden van die tijd bekijkt begrijp je waarom: De PC van die tijd bestond uit chips die van de plank gekocht werden en er waren hordes aan hulpchips nodig om de boel aan elkaar te lijmen. Een Herculeskaart bevat tientallen chips, de Amiga deed meer met een enkele chip.

De grote hoeveelheid chips maakte zowel de hoeveelheid materialen hoog, alsook de printplaten erg complex. Commodore daarentegen had maar weinig chips nodig, kon met eenvoudige printplaten werken. De eigen chipfabriek zal de productiekosten ook enigzins gedrukt hebben. En daarom waren PC's duur en Amiga's goedkoop.
Het revolutionaire aan de 68000 serie was dat het ook een complexe instructieset heeft, maar dat deze uitgevoerd worden door een RISC core.
Dat is niet correct. Alleen de 68060 heeft een RISC core. De eerdere varianten zijn net zo CISC als de x86s uit die tijd.
Wel had de 68000 in tegenstelling tot de x86 een orthogonale instructieset. Daarmee staat hij in ieder geval 1 stap dichter bij RISC dan x86.

Verder is het nogal lastig vergelijken, omdat de 68000 z'n naam ontleent aan het feit dat hij uit ongeveer 68000 transistors bestaat.
De 8086 daarentegen bestaat uit 29000 transistors.
Met een dergelijk verschil in complexiteit is het ook logisch dat de CPUs nogal van elkaar verschillen.
Door de jaren heeft Intel de schade grotendeels ingehaald, vooral met de stap naar de 32-bit protected mode in de 386.
Ik had een Amiga500 en een 286 12Mhz naast elkaar staan. Ik programmeerde ook voor beide assembly, de Amiga was een stuk sneller. De Amiga had alleen geen tekst modus, dus het dir/ls commando en alles met tekst was een stuk sneller op de PC. Later de PC geupgrade naar een 386DX 40Mhz van AMD, die was een stuk sneller dan de Amiga.

Ook had ik de printerpoort van de PC 1 op 1 doorverbonden met die van de Amiga. Die van de Amiga kon nl gebruikt worden als sampler (geluid opnemen). En veel PC games konden samples uitsturen via de printerpoort (Covox). Met een eigen stukje assembly stond de Amiga dan de wav form op het beeld te tonen en de audio weer te geven :).
Lang geleden op MTS ook 68000 machine code voor 68000 based Embeded controller.
En ook Z80. Geen flauw benul van Amiga.
Programmeren als hobby weer opgepakt toen er DX2 was. Tja op 3DFX banshee kaart met 16MB.
Nu mis ik wel dat ik mij toen niet zo in verdiep had. Dat beetje Basic op ZX81 later GWbasic op MSDOS. Is mij helemaal weg gevlogen.
Maakte in turboPascal6.0 wat Dos utility's met BGI? Library.
ook te lang geleden.

Nu kijk ik uit naar DX12 W10
En dan naar vooral procedural generatie voor games
En is het C++ met Visual studio pro als IDE
Herkenbaar, ik zat op de MTS toen de amiga uitkwam en eigenlijk ken ik niemand die er toen ťťn heeft aangeschaft ook de school niet, die schaften apple II systemen en een IBM XT aan.
Wel veel mensen schaften een ZX81 en later een spectrum aan, de Z80- was toen verplichte kost (microprofessor). Commodore 64 was later ook populair. later op de HTS was alles 80286 met hier en daar een verdwaalde prime of DEC PDP
Als de marketing van de amiga anders was geweest en niet op multimedia, kunst etc was gericht dan had het een van de eersta cad computers in het technisch onderwijs kunnen worden.
Op de HTS met de Prime heb ik ook nog gewerkt, als je alleen was ingelogt ging het wel, maar als de hele klas was ingelogt....
Op de middelbare school met AutoCAD 1 getekend op een Zenith PC, En BASIC zitten programmeren op een Exidy Sorcerer.

[Reactie gewijzigd door MadButcher op 19 juli 2015 19:00]

Volgens een oude ACM artikel is de 80286/8 MHz an sich sneller dan een 68000/16 MHz, maar dat is puur op CPU niveau, niet op architectuur niveau (geheugen/bus breedte/snelheden etc.).

De Amiga had een aantal custom chips die vele zaken kon offloaden en versnellen, dus zodra je meer dan ťťn ding deed of iets met grafiek (b.v. beeldscherm scrollen, sprites, meer kleuren) of geluid, of periferie toegang (floppy etc.) was de Amiga vele malen sneller. Als je het puur bij 40x25 karakters tekst scrollen in monochroom in een enkele applicatie hield dan kon je PC sneller zijn, maar daar nam je dan een enorme beperking in de mogelijkheden op de koop toe.

Bovendien was de Amiga enorm uitbreidbaar, naast een autoconfigurerende bus (Zorro, geen ellende met interruptconflicten) waren o.a. de CPU leidingen beschikbaar naar buiten zodat je een complete nieuwe architectuur kon inprikken (voorbeelden waren combinatiekaarten met 68060/PowerPC, grafische kaart, sneller geheugen, SCSI bus in processor slot). Een dergelijk systeem kon zelfs met alleen 68k CPU tot in ca. 1994 (Pentium 90) sneller zijn dan een PC (of Macintosh, via ShapeShifter).
Ach ja, de Amiga. De hardware werd al snel ingehaald, jammer genoeg, en het is nog maar zeer de vraag of het ontwerp de stormachtige ontwikkelingen aan de PC-zijde met VESA Local Bus, PCI, AGP, PCI/e en whatever er nu current is, zou hebben overleefd. Of de steeds sterkere nadruk op 'chunky' displays in plaats van bitmap-geŲriŽnteerde. Destijds waren in de arcadehallen scrollers heel populair (waarvoor bitmaps ideaal zijn): nu zijn die hooguit nog te vinden in appjes op je smartphone. De software heeft het beduidend langer uitgehouden: zeer veel concepten uit de multitasking-wereld vind je ook terug in de Amiga. Messages, semaphores, asynchronous event handling: best wel knap voor een machine die teruggaat naar 1985-1987 (met de A500 begon het allemaal pas goed). Maar helaas geen memory protection, waardoor als je ging programmeren om de haveklap met een Guru Meditation werd geconfronteerd. En als je pech had je filesystem opnieuw kon worden gevalideerd, jottem.

Mooie tijden, dat wel; heel veel geleerd over computers waar ik nu nog steeds profijt van heb, zeer zeker; maar op een gegeven moment, door diverse factoren, ingehaald door de tijd.
Maar helaas geen memory protection, waardoor als je ging programmeren om de haveklap met een Guru Meditation werd geconfronteerd.
Dat was een beperking van de 68000, die had geen MMU.
Op de PC had je hetzelfde probleem, de 8088/8086 hadden het ook niet. De 286 had een hele beperkte protected mode, die nooit populair is geworden. Pas met de 386 en Windows 95/NT brak memory protection door op het PC-platform in een mainstream OS (en bij Win95 was dat nog zeer beperkt vanwege legacy).
Toen was de Amiga-tijd al voorbij.

Als je een Amiga 2500 of 3000 kocht in de UX-uitvoering, kreeg je daar AMIX bij, en dat OS had het wel.

[Reactie gewijzigd door Scalibq op 19 juli 2015 11:26]

Dat was een beperking van de 68000, die had geen MMU.
Tuurlijk. Het werd pas pijnlijk toen de officiŽle documenten van Commodore voor Amiga-ontwikkeling melding maakten van de leuke tool Enforcer in geval van nare crashes. Die een volledige 68030 (of 68040, maar die was toen nog niet beschikbaar) nodig had (dus een A3000 in die dagen), met daarin, heewatleukhoekandatnou, een iets aangepaste 68851 MMU. Die de zaak voor de enkele task (of proces als je nog wat AmigaDOS spul nodig had) helemaal omsingelde en isoleerde, en bij een crash waardevolle informatie over de stackframe gaf. Dat ging prima. Het lullige: kocht je een A4000 (wat ik op een gegeven moment deed), kreeg je een 68EC030 CPU erin. Dat is dus een 68030 zonder de MMU, hoezee. En toen ik uiteindelijk voldoende geld bij elkaar had gespaard voor een Cyberstorm met volledige 68040, kwamen de ellendige copyback caches van dat ding om de hoek kijken. Die interfereerden bijna overal met de DMA van de Amiga-hardware, en moesten vaak worden uitgezet.

Nee, mooie tijden, maar op een gegeven moment echt door de tijd ingehaald. Als de Amiga was blijven bestaan was een rewrite van het OS en een herimplementatie van de hardware eigenlijk onafwendbaar. phase 5, makers van de Cyberstorm, hadden daar al last van toen ze hun grafische kaart op de markt brachten, omdat het abstractieniveau van de grafische onderdelen van het OS veel te mager was. In AmigaOS 4, dat veel en veel later uitkwam is een soort halve oplossing gekozen: wel goede abstractie, ook procesisolatie, maar niet meer dan dat. Elk systeem uit die dagen heeft vroeg of laat met grote herimplementaties te maken gehad, of het moet vanaf het begin af aan zo zijn opgezet.
Volgens mij werden in die tijd losse MMU's gebruikt maar de Amiga moest betaalbaar blijven en daarom hebben ze voor een software oplossing gekozen i.p.v. een hardware MMU in te bouwen.
Het besturingssysteem was ook niet echt geschikt voor een MMU. AmigaOS was een ware revolutie, maar op dit punt was het gemaakt om alle programma's in ťťn adresruimte te draaien. Dus ook de duurdere Amiga's deden het daarom zonder MMU.
De duurdere Amiga's hadden een CPU met een ingebouwde MMU, maar AmigaOS heeft er nooit support voor gekregen.
Er is wel third-party software die memory protection toevoegt aan AmigaOS, geleverd bij sommige accelerators met MMU.
Zoals bv Enforcer: http://www.sinz.org/Michael.Sinz/Enforcer/index.html

[Reactie gewijzigd door Scalibq op 19 juli 2015 14:41]

Voor de 68000 was dat nog een probleem, er zaten nog wat probleempjes in de implementatie van de memory protection. Dat werd in de 68010 aangepast.
Er was een systeem, ik meen van Sun, dat een tweede 68000 gebruikt als MMU.
Er was overigens geen 'software-oplossing' in de Amiga, dat kan ook niet met memory protection. Er was gewoon geen memory protection :)
Ik bedoelde dan ook memory management (de MM in MMU) en niet memory protection. Dat laatste kan inderdaad alleen in hardware.
Tsja, maar memory management is niet hetzelfde als wat een MMU doet :)
Een MMU dient om protected memory en virtual memory te kunnen implementeren.
Als je die niet hebt, moet je natuurlijk nog steeds geheugen managen binnen je OS, maar dan gaat het meer om het alloceren en dealloceren, en dat zijn dingen die de MMU sowieso niet doet.
Memory management in die zin doe je dus altijd in software, ook als je wel een MMU hebt (het is nog steeds het OS dat moet aansturen welk geheugen er welke rechten moet hebben, en het OS moet daar uiteindelijk ook de virtualisatie op regelen).
Apart om te lezen HOEVEEL mensen allemaal gave en warme herinneringen hebben aan de Amiga en hun C64, bla bla bla, MAAR als er dan een echte Amiga/C64 party is in Nederland na hele lange tijd met complete demo compo's, sound comp, gfx comp, en alles dan zie je niet meer dan pak hem beet 80 man op een zaterdag middag in de Haven op Scheveningen.

Ik doel hierbij op de 1991 Party die gehouden werd in 2013.

Zo zie je maar weer hoe betrekkelijk alles soms kan zijn.
Ik denk dat de generatie van toen inmiddels een gezinsleven heeft opgebouwd en vol met verplichtingen jegens werkgever, gezin en partner. Ik wel in elk geval. Ook heb ik alle spullen van die tijd verkocht en zou het vooral bekijken zijn, in plaats van zelf doen. Niet zo leuk meer.
Daarbij was het mij in elk geval niet bekend dat er een party was, anders had ik het wellicht nog overwogen.
Natuurlijk er zijn allerlei redenen voor en dat is ook helemaal geen issue.
Wat ik meer wil aangeven is dat alles relatief is.
Een dergelijk video roept dus ook de nodige gevoelens op maar niet meer dan dat bij de meesten.

Vergelijk het als vakantie foto's. Heel leuk om naar te kijken, en zeker komen de herinneringen naar naar boven maar hoe vaak kijken we er nog eigenlijk na ?


Maar goed, mij viel het het destijds iig erg tegen. Ik had meer echte liefhebbers verwacht. Het zijn er dus veel minder dan je zou denken.
Heb al geen tijden daadwerkelijk een Amiga meer in huis maar als ik had geweten dat daar toen een party was (waar je ook naar binnen zou mogen zonder hardware/software mee te nemen) was ik zeker gegaan. Een een vriend van mij ook.

Waar kan je dit soort dingen biijhouden dan, mocht er weer zoiets komen?
Dat is een kwestie van af en toe googlen en contact onderhouden met mensen die destijds ook in de scene zaten.
Soms loop je hier op Tweakers ook tegen dingen aan en er is zelfs een aparte sectie op het forum voor dit soort Vintage zaken.
Dat is wat kort door de bocht, denk ik. Het heeft ook te maken met hoeveel bekendheid er aan een evenement wordt gegeven. Hier stond geen grote organisatie achter die via allerlei media en met geld voor reclame en campagnes de boel aan het grote publiek kon introduceren. Uiteindelijk waren er op dit event veel meer mensen dan in eerste instantie rekening mee was gehouden. Daarom werd er nog uitgebreid met een party-tent buiten. Kun je nagaan als er echt promotie was gedaan, zoals Radio 538 met zijn evenementen doet, om maar wat te noemen. Bovendien was het op deze manier voor de ťchte fans en dat was ook de bedoeling.
Te kort door de bocht ? Ik denk juist dat het de lading precies dekt, namelijk:
De mensen met Amiga in het hart hebben doorgaans wel een beetje in de gaten wat er leeft in de scene en weten dus ook dat er events komen. Vaak wordt je ook nog door oude bekenden en vrienden er ook op gewezen enzo.
Zeker anno 2013 met overal internet, tablets, smartphones, google, whatsapp en 1000 andere manieren om dingen in de gaten te houden is het niet weten een kwestie van een keuze.

Kortom, als je dus niet op de hoogte bent van dit soort zaken dan kan je mijn inziens de conclusie trekken dat je niet een echte Amiga liefhebber meer bent.
Daar is niets mis mee maar laten we nu niet melangolisch doen na het zien van een filmpje.
Er zullen er niet veel meer regelmatig actief zijn met het spul, maar wel degelijk geinteresseerd zijn in een evenement juist als dat een beetje de nostalgie uitbuit ;). Maar dan moet je die personen wel zien te bereiken.
Dat zie ik wat genuanceerder. Op dit evenement (450 bezoekers) hebben we een zo breed mogelijk publiek geprobeerd te trekken, en dat is gelukt. 1991 had een heel andere; kleinere doelgroep, namelijk de demoscene.
Dat de demoscene ook warme herinneringen aan die tijd heeft begrijp ik maar al te goed, maar veel van de mensen die bij het evenement aanwezig waren kwamen niet uit de demoscene.

Onze poging is geweest om juist alle verschillende soorten gebruikers te trekken, of je nu creatief met de Amiga bezig was (zoals de demoscene daar misschien nog wel het beste voorbeeld van was), alleen spelletjes speelde of beroepsmatig met de Amiga bezig was, de common factor in deze was de liefde voor en herinneringen aan de Amiga als bakermat voor je verdere toekomst.

Door een vergelijk te trekken tussen dit evenement en 1991 doe je beide evenementen te kort.
1 2 3 ... 9

Op dit item kan niet meer gereageerd worden.


Nintendo Switch Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*