[CiP] Macintosh SE/arm

[Sprite_tm]

Macintosh SE/arm

Intro

Om een lang verhaal kort te maken: ik heb een nieuwe thuisserver nodig. Mijn huidige beestje, een Duron 1800, was vroegah kick-ass maar op dit moment qua CPU enigszins overkill, ik heb namelijk een hoop services naar mijn colo-machine verhuisd. Qua HD-ruimte is 'ie enigszins underkill: de bestanden worden er in vergelijking met vroegah niet kleiner op. Verder vreet 'ie idle zo'n 70 watt aan electriciteit: dat was prima toen mijn electriciteitsverbruik nog bij mijn huurprijs inzat maar tegenwoordig heb ik een eigen huis en moet ik elke watt uit eigen zak betalen.

Ik heb altijd de neiging gehad om te weigeren mijn server in een normale ATX-kast te bouwen. Zeven jaar server in een notendop: De machine is in de oudheid eerst opgebouwd op een stel plankjes, daarna heeft de case voor een groot deel uit touwtjes bestaan en als laatste is 'ie in een echte CiP in een televisie omgebouwd.

De CiP is de vorige keer nou niet heel netjes gegaan (ik ben geduldiger met electronica dan met dremels) maar het effect was er wel: genoeg mensen die me vroegen waarom ik in een met redelijk moderne shit gevulde werkkamer een aftandse TV had staan Het is zelfs een tijdje mogelijk geweest om inderdaad video te zien op het ding, dankzij het ingebouwde LCD'tje. Anyway, leuk effect en dat wil ik er graag inhouden. Op naar een volgend semi-anachronistische behuizing om de server heen!

Het slachtoffer

Dit gaat het slachtoffer worden: een Macintosh SE/30


De bedoeling is dat hier het een en ander uitgesloopt gaat worden: het mobo gaat eruit, de oude 40G harde schijf gaat eruit en eventueel gaat ook de voeding nog wat bijgeschaafd worden. In de ruimte die overblijft gaat als belangrijkste object de inhoud van dit beestje komen:


Het is een Seagate Dockstar, en hoewel het niet als zodanig verkocht word is het een embedded systeempje met een ARM-processor op 1.2GHz, een (wat magere, to be honest) 128M aan RAM, een shitload aan USB2-poorten en een GBit Ethernet-poort. Er is al redelijk wat mee gehacked, en hoewel ik niet zeker weet of ik met de features die het dingetje bied als server uitkan, kan ik me er voor de E50 die 'ie kost ook geen buil aan vallen. Er kan verder ook Debian op geinstalleerd worden dus ik hoef zelfs niet van OS te wisselen. Dit doosje is ook meteen de reden voor de naam van de CiP: de SE/30 heette zo omdat er een 68030-processor inzit. Als de cpu omgewisseld gaat worden is het niet meer dan billijk om het modelnummer meteen mee te veranderen.


Hoe gaat het uiteindelijke geplande resultaat eruitzien? Nou, na uren in Sketch-up, Autocad, Maya, een fotostudio en Photoshop kan ik jullie alvast een tipje van de sluier oplichten. Dit is een heel pre-emptive ruwe schets van het uiteindelijke gewensde resultaat:

Heuh?

Je ziet het goed: het idee is dat het apparaat compleet blijft werken als 'klassieke' Mac; de enige toevoeging aan het plaatje is een GBit-Ethernet-kabel naar de rest van mijn netwerk. Het plan de campagne is dan ook als volgt:

• De slachtoffer-mac ergens vandaan halen. Zoals je al ziet aan de foto's is dit ondertussen gebeurd.
• USB-GPU-iets bouwen. Het idee is dat deze aan de monitor van de mac komt te hangen en beeld gaat genereren. De ARM kan via USB2 beeld richting deze chip pompen.
• ADB->USB-converter bouwen. De muis en het toetsenbord van de Mac hebben een ADB-aansluiting, wat een soort verre voorloper van USB is. De ARM praat dat natuurlijk niet en wil liever USB hebben, dus er moet een converter gefixed worden.
• HDs en andere hardware in de machine hangen. Dat kan nog lastig worden: een goede airflow is wel gewensd maar ik wil de originele behuizing natuurlijk zo min mogelijk aanpassen.
• 'Iets' met de diskdrive doen. Wat precies ben ik nog niet achter...
• Software schrijven. Het idee is dat de ARM naast z'n servertaken ook nog even een Mac erbij gaat emuleren als 'ie tijd overheeft. Die geemuleerde Mac gebruikt de via USB aangesloten monitor, toetsenbord en muis. Als alles goedgaat is het zelfs zo dat je alleen 'direct' op het onderliggende Linux-systeem kan komen door op de nep-Mac een terminal-sessie naar een serieele poort op te starten.
• ...
• Profit! Dark Castle!

Stap 1: De Mac

Sja, waar haal je een 20-jarig oude Mac vandaan? Marktplaats natuurlijk. Ik kwam een advertentie tegen die er twee aanbood: een Mac SE/30 en een Mac Plus. Voor mij een mooie combo: de Macintosh Plus was de eerste computer die wij in huis kregen toen ik nog een klein Sprite_tm'etje was. De SE/30 is zo ongeveer het meest kick-ass model wat je in deze form-factor kon krijgen: een machine uit '89 waar je 128M aan geheugen in kon stoppen! Even onderhandeld over de prijs enzo en een paar dagen later kwam de aardige meneer van de TNT langs met een pakketje:



Woei! Meteen maar opzetten en kijken of ze 't nog doen:

Daar staan ze dan: in totaal minimaal $7000-aan-nieuwwaarde aan Macs.


De MacPlus deed het als vanouds: hij pruttelde vrolijk tot leven van de meegeleverde systeemschijf en MacPaint werkte natuurlijk ook gewoon.


De SE/30 leek het wat minder te doen. Hij maakte een geluid wat de klassieke-Mac-kenner herkent als de 'death chime': een geluid wat in de ROM gegenereerd word zodra er iets mis is met de hardware. Het beeld wat verscheen maakte de indruk dat er inderdaad iets niet helemaal lekker was met de logica... openschroeven maar.


Oh-oh, die roestplek aan de onderkant van het chassis voorspelt niet veel goeds...


Ai-ai-ai. Deze Mac is waarschijnlijk tien jaar terug in de opslag beland en nu pas eruit gehaald, waarschijnlijk door mensen die iets hadden van 'hij maakt geluid dus hij werkt'. ondertussen is echter de batterij doodgegaan en heeft z'n schadelijke zuren over het moederbord kunnen verspreiden...


Ik heb nog een dappere reddingspoging gewaagd maar helaas, er zijn waarschijnlijk spoortjes binnenin de multilaags print weggerot. Welke precies kom je nooit meer achter zonder elk individuele spoortje na te meten, en zelfs dan alleen als je schema's hebt die precies met je revisie moederbord overeenkomen. Sunde. Wijze les voor de lezers hier: als je nog een ouwe computer in de opslag hebt staan: haal de batterij eruit!

Dit heeft allemaal wel een voordeel: ik zat aan het begin van het project nog met de keuze tussen het slopen van de capabelere SE/30 of de nostalgischere Plus. Dat is door het doodzijn van de SE/30 meteen opgelost: de Plus blijft leven als jeugdherinnering en de SE/30 gaat een minder authentieke edoch practischere rol vervullen.

[muppet99]

Ben heel benieuwd. Ik moet zeggen ook wel een heel leuk idee. Bookmarked

[Fid3lity]

Ik vind het gaaf

[skoozie]

Ben zeer benieuwd hoe dit uit pakt, ziet er goed uit, maar ehh...
hoort deze officieel niet eerst langs het Schop-Een-Modje forum te gaan voor goedkeuring?

[brinkdinges]

Je hebt wederom flinke plannen qua elektronica en software, de uitvoering ervan is altijd leuk om te volgen

[Touchdomex]

skoozie schreef op donderdag 29 juli 2010 @ 13:22:
Ben zeer benieuwd hoe dit uit pakt, ziet er goed uit, maar ehh...
hoort deze officieel niet eerst langs het Schop-Een-Modje forum te gaan voor goedkeuring?

Ga eens kijken wie hem geplaatst heeft?

[natasdiamon]

Touchdomex schreef op donderdag 29 juli 2010 @ 13:33:
[...]


Ga eens kijken wie hem geplaatst heeft?

een beetje van so what... hij heeft zich toch ook gewoon aan de regeltjes te houden?

[Touchdomex]

natasdiamon schreef op donderdag 29 juli 2010 @ 13:37:
[...]


een beetje van so what... hij heeft zich toch ook gewoon aan de regeltjes te houden?

Hoe moet hij zichzelf beoordelen?

[biertjuh?]

Dit hoeft waarschijnlijk niet langs een schop een modje want hij krijgt voor zo ongeveer al zijn mods toestemming zonder dat wij het weten volgens mij.:) kijk maar eens bij die televisie mod. 3de reactie volgens mij.

**** iets veel te laat.

[ Voor 5% gewijzigd door biertjuh? op 29-07-2010 13:53 . Reden: te late reactie ]

[Sprite_tm]

Heh, geloof het of niet maar dit topic is inderdaad eerst langs SeM geweest en beoordeeld. Mijn mede-mods vonden het goed genoeg om te plaatsen dus heb ik het meteen maar even gemoved. Ik vond het alleen zo lullig om als tweede post te plaatsen dat ik toestemming van o.a. mezelf had om dit te posten

[FloydRaalte]

Geweldig idee! Ik denk dat het alleen, zoals je zelf al wel aangeeft, lastig wordt met de airflow. Als je uberhaupt al je hardware er in gecrammed krijgt! Daarom moest ik meteen aan het volgende idee denken: Waarom haal je die beeldbuis er niet uit, dat scheelt toch zeker 50% 15% tot 25% aan ruimte. Dan kun je de harde waren tenminste fatsoenlijk inbouwen. Je bent dan wel genoodzaakt een klein LCD/TFT scherm ergens vandaan te toveren. Misschien van een laptop of iets dergelijks? Je ziet tegenwoordig zat digitale fotolijstjes. Anyway, keep it up!

[Sprite_tm]

Nope, gaat niet gebeuren: ik wil het uiterlijk echt helemaal hetzelfde houden. Ik wil misschien nog een concessie doen met wat goed verstopte sleuven voor wat meer airflow, maar vooral de beeldbuis, die toch wel het front van het geheel is, gaat niet vervangen worden. De bolling, het vage geknipper, de inkijkhoek: er is geen enkele manier om dat alles met een TFT goed te krijgen.

Komt bij dat ik denk dat je het allemaal te groot inschat Het 'moederbord' hier is een PCB'tje van 10x10 centimeter ofzo; daar komen een tweetal zelfbouw-PCBtjes bij van ook die grootte, twee harde schijven en eventueel nog een klein extra voedinkje als blijkt dat de oorspronkelijke voeding teveel verstookt. De oorspronkelijke HD gaat eruit, evenals het mobo: volgens mij blijven er dan nog zeeen aan ruimte over om iets mee te doen.

[frickY]

Ga je de 'grafische kaart' op losse hardware bouwen, of is het de bedoeling dat de ARM processor dat zelf gaat doen? Lijkt me dat die het nogal druk gaat krijgen met en server zijn, en Mac emuleren, en dan ook nog je in- en output devices converteren?

[Sprite_tm]

Het hangt ervanaf. In principe zit er een SPI-eenheid in de processor die door DMA z'n data kan krijgen. Als ik dat werkend wil en ga krijgen, hoeft de CPU daar maar heel weinig aan te doen; a la IGP op een x86-systeem. Punt is alleen dat het nogal iffy is qua drivers en daadwerkelijke werking: SPI is niet bedoeld om precies te kunnen timen en de beeldbuis heeft wel tot op de bit nauwkeurige timing nodig.

Het alternatief waar ik naar zit te kijken is om iets inelkaar te zetten met een aparte uC etc, en daar dan door middel van USB de framebuffer-veranderingen heen te sturen. Het probleem daarvan is dat 't kreng snel genoeg moet wezen om op 15MHz de pixels naar de beeldbuis te sturen, maar daarnaast ook nog eens via USB de binnenkomende requests moet processen... dat gaat je met een simpele AVR niet lukken Alsof het allemaal nog niet genoeg is wil ik ook nog de optie hebben om grijstinten inplaats van alleen monochroom naar de CRT te sturen; ik weet dat er voor de SE/30 videokaarten bestonden die dat konden en het lijkt me wel kick-ass om ook geimplementeerd te hebben. In het allerslechtste geval ga ik er gewoon een tweede, weliswaar veel minder krachtige, ARM bijproppen (ik heb nog een LPC1343 liggen) en die zo programmeren dat 'ie hard z'n best gaat doen om als GPU te werken.

In- en output-devices is niet zo moeilijk: de planning is om 1 of 2 AVRretjes zo te programmeren dat ze net doen alsof ze een USB-toetsenbord en -muis zijn.

[Xiphalon]

Oude 8-bit ISA kaart geen optie?

[Sprite_tm]

Theoretisch gezien wel; in de praktijk issie te groot en wil ik wel de 512x384-resolutie van het origineel hebben. Dat betekent een ISA-VGA-kaart met een PLL vinden en da's volgens mij ook nog niet zo makkelijk. Komt bij dat ik er met zelfbouw met 2 IC'tjes klaar mee kan wezen, da's een best eind kleiner dan een isa-kaart.

[DJ-Visto]

Ziet er vet uit, maar er moet toch wat meer opslag in hoor!

[Sprite_tm]

Mini-update: Ik heb de SE/30 toch maar even wat verder uitelkaar geschroefd: ik wil zeker weten dat er genoeg opslagruimte is. Dat was niet altijd even makkelijk met schroeven zoals dit:


Electronisch gezien lijkt alleen het mobo aangetast te zijn: de HD en op mysterieuze wijze zelfs de FDD zijn compleet ongeschonden.



En om even te showen dat er meer dan genoeg ruimte is. De ruimte van de tafel tot de onderkant van het chassis was bedoeld voor het mobo, die daarboven gaven plaats aan de HD, FDD en een eventuele uitbreidingskaart. Naast de mac ligt het nieuwe 'moederbord': het printje van de Dockstar, alsmede een 1.5T HD die er naast de 750GB die later uit mijn server moet komen, in de Mac komt te zitten. Ik zit er trouwens aan te denken om de oude mobo-locatie te gebruiken om de HDs in te schroeven: de koeling daarvan is het kritiekst en op die plek zitten er aan alle kanten koelsleuven naast in de plastic behuizing.

Hebben jullie trouwens enig idee wat ik met het chassis kan doen? Natuurlijk wil ik de roest erafschuren, maar daarna? Blijft het onbehandeld een beetje goed, of kan ik doordat een of ander beschermingslaage weg is over een jaar dan weer de roest ervanafkrabben?

[ Voor 8% gewijzigd door Sprite_tm op 31-07-2010 12:06 ]

[rohaantje]

veelbelovend

[frickY]

Die voeding

[wâldpyk]

kan je de roest er niet afschuren en dan met blanke lak behandelen?

[tafkaw]

Hammerite?

[[Remmes]]

anti roest spul erop spuiten, zoals hammerite bijv idd

[Verwijderd]

Beste is ruim schuren en dan menie gebruiken, let wel op dat je loodvrije neemt...

[_ferry_]

Of galvaspray/galvazinc/zinkspray. dat kleurt ook nog eens redelijk hetzelfde(namelijk zoals gegalvaniseerd metaal), en is een prima roestbeschermer.
Maar als het alleen voor 1 zo'n plekje is, dan is de aanschaf van een spuitbus daarvan misschien wat overkill. Dan gewoon opschuren en er $random lak overheen. Ding staat droog, dus snel roesten zal ie niet.

[Sprite_tm]

Klinkt wiedes. Ik ga in ieder geval het roest er maar es afschuren, later maar es blanke lak halen. om eroverheen te spuiten.

Het lijkt erop dat de voeding vervangen trouwens een optie is, mocht ik nog meer ruimte nodig hebben. Dat ding is doorgelinkt via de print die de monitor aanstuurt, maar de schema's (1, 2) geven aan dat alleen de +12V gebruikt is. Als ik daar dus een random 12V PSU die minimaal 1.25A kan leveren aanhang ben ik er al. Aan de andere kant: het lijkt erop dat ik ruimte genoeg heb... ik moet die psu maar eens onderzoeken op efficientie bij lage belastingen, misschien dat 't voldoende is om te blijven gebruiken.

[Sprite_tm]

Nou, ik denk 'in het weekeind maak ik wel even een flink begin met de GPU; ik wil toch in ieder geval beeld hebben'... Ik heb besloten om de GPU rond een LPC1343 op te bouwen, da's een 72MHz 32bits uC die ingebouwd USB heeft. Cool en shit en stuff, maar dan moet ik die wel eerst werkend krijgen; dev-omgeving opzetten etc. Eitje: ik heb al ervaring met een andere ARM van NXP... athans, dat dacht ik.

Een dag later: crosscompileren is een bitch, voorbeelden zijn van nivo-Arduino terwijl ik die-hard bare-metal moet gaan coden om de snelheid te halen, de usb-bootloader blijkt niet helemaal compatibel te zijn met Linux, kortom: aanprutsen, aanprutsen en nog es aanprutsen. Nja, het punt waar ik nu ben kan samengevat worden in twee plaatjes:





Ik kan in ieder geval _eindelijk_ aan de code beginnen en hopen dat ik binnenkort video uit het bordje weet te krijgen.

[Verwijderd]

Blinking led hello world FTW!

Geweldig om te zien hoe dat dat altijd het begin is van een microcontroller avontuur.

[Rob Coops]

Het is duidelijk te zien dat je weet wat je aan het doen bent, een blinkende led en dus een werkende compiler en zo'n beetje het simpelste beetje code dat je kunt schrijven.

Nu alleen nog even al die andere dingen aan de praat kijgen natuurlijk

[GNOOM172]

Het is leuk en misschien wel leerzaam om van een Moderator een mod te volgen. Ik heb echter nagenoeg weinig verstand van electronika en dat ga ik jammer genoeg ook niet krijgen in deze topic omdat je wel heel erg in het vakjargon praat. Misschien beter, correct me if im wrong, om deze electronicamod te verplaatsen naar het electronika forum.

Even ter verduidelijking;
"crosscompileren is een bitch, voorbeelden zijn van nivo-Arduino terwijl ik die-hard bare-metal moet gaan coden om de snelheid te halen"

LPC1343 op te bouwen, da's een 72MHz 32bits uC die ingebouwd USB heeft. Cool en shit en stuff, maar dan moet ik die wel eerst werkend krijgen; dev-omgeving opzetten etc. Eitje: ik heb al ervaring met een andere ARM van NXP

Is het nu popiejopie straattaal of zijn het echt componenten waar je het over hebt
Ik hoop dat je misschien je uitleg, ook voor NoNo's misschien iets uitgebreider wil doen.

[RadiantThunder]

Meer info over de LPC1343:
http://www.keil.com/dd/chip/4919.htm

Meer info over Arduino:
http://www.arduino.cc/

Met niveau Arduino wordt dus waarschijnlijk beginners/hobby niveau bedoeld.

Dev-omgeving opzetten: Zorgen dat alle instellingen juist staan in je Developer-omgeving om te kunnen compileren voor het gekozen platform (vb. juiste libraries aanspreken enzo)

[GNOOM172]

Dankjewel, weer iets wijzer!

[Noxious]

Ojee deze ga ik wel volgen, retromods zijn altijd goeeed

[Sprite_tm]

Fair nuf, de laatste post is ook vooral frustratie wegwerken over een stel dingen en ik heb idd niet erg goed naar de precieze tekst die ik neerzette gekeken Zo nu en dan zou je bijna denken dat ik naast een mod ook nog eens een mens ben

RadiantThunder schreef op maandag 02 augustus 2010 @ 15:42:
Met niveau Arduino wordt dus waarschijnlijk beginners/hobby niveau bedoeld.

Ook, maar dat was niet helemaal waar ik problemen mee heb. De Arduino-omgeving legt developers in de watten door een erg makkelijk te begrijpen interface aan te bieden. Het probleem is dat het gemak onderhuids vertaald word in redelijk veel werk voor de processor. Ik moet met deze toepassing minimaal 15 miljoen keer per seconde een pixel uitpoepen en daarnaast ook nog eens USB begrijpen en interfacen met een stukje extern geheugen, dus de 'makkelijke' aanpak gaat veeeel te traag voor me zijn.

[ Voor 4% gewijzigd door Sprite_tm op 02-08-2010 17:46 ]

[Sprite_tm]

Nou, dat was een avondje productief wezen. Nadat ik de Arduino-achtige crap zoveel mogelijk weggesloopt had (WtF, 100 instructies nodig voor de routine om een pin hoog te maken? Ik kan 't in 2!) begon de ervaring en de routine van vroegah weer terug te komen. Nog even een kabeltje solderen en een paar testjes later had ik de signaaltimings goedzitten. Kostte al met al alsnog wel iets langer, de timings van zo'n Mac-monitor zijn zo hier en daar flink afwijkend van die van een normale VGA-monitor, en nergens echt 100% goed beschreven. Maar uiteindelijk had ik 'm toch:



Leuk, maar alleen de scanlines (inclusief retraces) zien doen we het niet voor. Eens kijken of we ook daadwerkelijke pixels uit kunnen pompen met die ARM. Eerst maar eens random data uitspugen:



Oooh, prachtig Nou nog interrupts regelen, die zijn namelijk nodig voor een 'echt' beeld, en dan zorgen dat we het hele scherm vol kunnen plempen:


Mooi, het display-gedeelte werkt. Het plaatje hierboven komt nog direct hardcoded uit het flashgeheugen van de processor en is niet te veranderen. Wat ik moet doen is een stukje extern RAM eraanbakken waar het beeld in komt te leven, en daarna nog de USB-routines zodat het beeld ook daadwerkelijk naar de GPU gegooid kunnen worden. Maar voor een avondje flink doorbikkelen is dit lang geen slecht resultaat.

Samenvatting voor de niet-diehard-ELlers: ik kan een plaatje laten zien op de monitor. Nu nog zorgen dat ik het plaatje over USB kan veranderen...

[ Voor 7% gewijzigd door Sprite_tm op 03-08-2010 00:40 ]

[GNOOM172]

Mooie update en begrijpelijk voor Noobs

[Noxious]

Wow wat awesome met jou skills krijg je volgens mij alles aan de praat bij mij falen dat soort projecten altijd door een gebrek aan kennis en vindbare info

[Verwijderd]

Kun je eens beschrijven hoe je die timings goed hebt gekregen? Ik ben daar al eens vaker op vastgelopen dat het vrijwel onmogelijk leek om goede timings te krijgen waardoor een trillend of lopend beeld het beste was wat er te krijgen was.

[skoozie]

ZIet er zeer goed uit! Dit is bijna geen casemodden meer, gaat meer richting Computerbuild-In-Progress
ook bedankt voor de duidelijke uitleg, dit is een heel leuk project oom te volgen.

[Rob Coops]

Ik ben ook wel geïnteresseerd in die timing info, ik heb wel eens met dit soort dingen gespeeld maar over het algemeen kwam ik niet veder dan TRRoads met een nog al onstabiel beeld.

Wel een heel erg leuk project, ik heb vele uren met de Apple SE en Apple+ mogen spelen en ik denk er nog met veel plezier aan terug (ook al noemde ik het toen nog wel eens vervelend school werk en zo ) Het lijkt me heel erg leuk om een oude Apple weer als echt bruikbaar systeem terug te zien ook als er geen Apple OS meer opstaat

[freak-ish]

I am impressed!

[Sprite_tm]

Nou, nog een update en wel dat er geen update is Details: Ik lijk de ARM niet zo geprogrammeerd te krijgen dat de code snel genoeg is om het hele beeld van een extern stukje RAM naar de monitor te sturen. Dat externe stukje RAM heb ik echter wel nodig: het interne gedeelte is niet groot genoeg om het hele beeld in vast te houden (is namelijk 8K; ik heb 21K ofzo nodig.) Komt bij dat ik daarnaast ook nog eens tijd moet hebben om data van USB naar het externe stukkie RAM te gooien, dat gaat nu helemaaaal niet meer lukken. Lijkt erop dat die LPC1343 een dead end is... en ik ben er nog niet uit of ik een proc ga bestellen die het hele geheugen intern heeft (zodat alles wel snel genoeg kan gaan) of of ik een compleet andere aanpak ga kiezen. Misschien ga ik toch nog een poging wagen met de interne SPI van de ARM die Linux gaat draaien, misschien dat ik gedwongen word om een videokaart uit veel losse onderdelen te maken... we zien wel.

TL;DR: Het mooie printje wat hierboven plaatjes uitspuugt gaat nooit werken als videokaart... uithuilen en iets anders proberen dus.

[ Voor 6% gewijzigd door Sprite_tm op 05-08-2010 23:09 ]

[Looney11]

Parallax heeft de propeller microcontroller, een 8 core microcontroller waar (volgens mij) een stukje PAL e.d. in zit. Deze zijn zeker snel genoeg om video te genereren. In hoeverre deze zich via USB laat aansturen is mij niet bekend, het is wellicht een optie?

[Sprite_tm]

Jah, ik ken ze (heb er zelfs ergens eentje thuisliggen) maar had er eerlijk gezegd nog niet aan gedacht. USB erin krijgen gaat inderdaad niet zomaar, maar misschien kan ik daar met een FT245 wegkomen; die heb ik nog wel. Er staat me verder ergens bij dat het RAM voor het grootste gedeelte op een niet al te efficiente manier gedeeld werd tussen de cogs; misschien is dat een beer op de weg. Ik zal er in ieder geval eens naar kijken, bedankt voor de hint!

[Joen]

Mooi idee! Ik blijf dit topic zeker volgen!

Ik kan me deze MAC-jes nog goed herinneren van de bassisschool. Vooral "tafels" geleerd er mee. Waren altijd fijne machines om mee te werken.

[Zjosh]

Kan je niet iets doen met een cpld en een stuk ram wat je controleert met je atmel of arm? Dat je die cpld de snelle dingen laat afhandelen met een interface naar het ram, plus een methode om je ram aan te passen met een bus naar je atmel of some kind. Als je kijkt hoe zo'n bult spul jij thuis hebt liggen, zal je vast ook wel ergens een max liggen

[djgerry300]

Man, Ik wou ik zo'n kennis van zaken had

Ben wel geïnteresseerd om zo meuk te maken waar niemand iets aan heeft xD

Maar verder is het wel VET wat je aan het doen bent !!

[Resistor]

Het 'iets' met de diskdrive doen: Zoiets maken, maar dan op disketteformaat?

Diskette 'uithollen', zo veel opvullen dat je een SD-kaartje er stevig in kan zetten (dat de contactstrips wel bereikbaar zijn), in een leeggehaalde diskdrive (waar alleen het 'eject' mechanisme nog in zit) de printplaat van een kaartlezer met de contactvingers er in lijkt mij wel een idee in de goede richting.

[Corn]

Je zou kunnen denken aan die dual ported ram (VRAM) dingen, zijn met goed zoeken wel ergens te vinden. Kun je 1 LPC gebruiken voor het vullen via USB, en de andere voor het scannen naar CRT.
Andere optie is een vroege VGA kaart scoren en daar een RAMDAC vanaf slopen.

[Napsju]

Echt een gaaf idee van die Seagate 'server'. Ik ben benieuwd naar je eindresultaat!

[the_nasty_one]

om je vingers van af te likken

[TD-er]

Resistor schreef op vrijdag 06 augustus 2010 @ 21:58:
Het 'iets' met de diskdrive doen: [afbeelding] Zoiets maken, maar dan op disketteformaat?

Diskette 'uithollen', zo veel opvullen dat je een SD-kaartje er stevig in kan zetten (dat de contactstrips wel bereikbaar zijn), in een leeggehaalde diskdrive (waar alleen het 'eject' mechanisme nog in zit) de printplaat van een kaartlezer met de contactvingers er in lijkt mij wel een idee in de goede richting.

Je kunt precies die dingen in een floppy plakken en dan de contactpennen doorverbinden naar de aansluitingen elders in de machine. Dan hoef je het niet eens op te vullen en blijft je micro-SD kaartje er goed in zitten. Nadeel is wel dat de floppy eruit moet om het micro-SD kaartje te wisselen.
Dan kun je micro-SD kaartjes lezen en die lijken steeds meer beschikbaar te komen en ook in leuke formaten (16 GB voor minder dan 30 euro)

[TD-er]

@Sprite_TM:
Hoe dicht zit je qua timings bij een NTSC signaal?
Anders zou je hier misschien nog wat ideeën op kunnen doen.
Als ik het goed begrepen heb, gebruikt hij dezelfde CPU(familie) als wat jij hier probeerde te doen.

[Sprite_tm]

@TD-er: Jah, ik ken 'em. Het probleem bij mijn signaal is zowiezo dat de frequenties net iets hoger liggen, maar het belangrijkste is dat ik elke pixel uit een extern stukkie RAM moet halen, wat vrij traag werkt. Die console kan gewoon veel on-the-fly genereren en dat werkt net even iets sneller.

Omdat ik verder nog geen echt duidelijke opties overheb ben ik toch maar weer eens gaan prutsen met mijn huidige hardware: ik kan het niet hebben dat ik met een 72MHz 32-bitter niet even een framebuffer zou moeten kunnen spelen. Een shitload aan optimalisatie later ben ik iets verder gekomen: het lukt me nu om een plaatje vanuit het externe RAM naar de Mac-monitor te sturen:



Dit plaatje is trouwens een screenshot wat wederom 'hardcoded' in het arm-programmageheugen zit, maar het word tijdens het opstarten van de ARM snel even naar het externe VRAM gegooid. Het geeft in ieder geval aan dat deze ARM snel genoeg te krijgen is om een plaatje van extern ram naar de monitor te gooien

Het probleem is dat de cpu met deze aanpak 70% van de tijd bezig is met pixels naar het scherm duwen. In de resterende 30% moet ik de USB-communicatie af gaan handelen en de data van USB naar VRAM stoppen. Deze routines mogen ook niet al te lang duren: als ik nog bezig ben met USB op het moment dat ik een nieuwe lijn naar het scherm zou moeten gooien, verneuk ik feitelijk gewoon mijn beeld. Ik hoop dat het me lukt om met die restricties iets te schrijven... Ik heb gelukkig misschien ook nog een hardwarematig geintje liggen om me iets meer ademruimte te geven, tho'.

SD-kaart-in-floppy: Heb ik aan zitten te denken. Het probleem is dat ik nou niet echt vaak SD-kaarten in mijn server hoef te drukken... Nja, misschien kan ik 't op de een of andere manier direct doorlussen naar de Mac-emulator; zie je er daar gewoon een schijf bijkomen.

[brinkdinges]

Dat je naast het opbouwen van het beeld nog andere dingen moet doen is inderdaad een flinke beperking. Is de enige tijd die je hebt om bijvoorbeeld met USB te communiceren, tussen de verschillende lijnen door? Niet dat ik je verder kan helpen hoor, ben gewoon benieuwd

[Sprite_tm]

Ik heb het net even bekeken: Tijdens het uitspugen van video is de CPU 100% bezig; misschien dat er zo hier en daar een cycle'tje gewacht word op de hardware maar omdat dat maar enkele, geisoleerde cycles zijn kan ik er niets mee. De tijd die overblijft zijn de hsync en vsync: de tijden waarop de elektronenstraal van de monitor teruggaat van rechts naar links resp. van onder naar boven, en er geen video geschreven word. Ik kan zien dat per lijn de tijd die ik door buffering en de hsync-tijd niet aan video-genereren hoef te besteden, iets meer dan 25% van een hele lijn is. Daarnaast heb ik nog eens een lijn of 30 aan VSync-tijd over.

Als ik nu stel dat het beschrijven van het vram ongeveer even snel is als het lezen ervan en dat de usb-communicatie an sich een te verwaarlozen tijd in beslag neemt, betekent dat dat ik na elke lijn die ik naar de beeldbuis doorstuur, ongeveer een kwart lijn vanuit USB naar het geheugen kan schrijven. Verder heb ik de 30 lijnen VSync nog over waarin ik 'vrij' kan schrijven naar het vram. Als ik dat allemaal optel kan ik per compleet scherm wat ik teken op de beeldbuis, 340*25%+30=115 lijnen vanuit USB in het vram plaatsen. Dat betekent dat mijn refreshrate over USB op maximaal (115/340)*60Hz=20Hz kan liggen. Dat is trouwens de frequentie waarmee bijvoorbeeld een full-screen spelletje waarbij elk stukje beeld verandert, op de CRT weergegeven word; de CRT word zelf wel altijd met 60Hz ververst en bij animaties waar niet het hele beeld verandert zal een gedeelte van het scherm niet ververst hoeven te worden.

Nja, 20Hz is in principe overleefbaar, maar ik had liever dicht in de buurt van de maximale 60Hz gezeten; dan had ik zeker geweten dat de geemuleerde Mac niet te onderscheiden zou wezen van de echte. Verder maak ik in het bovenstaande stukje een stel aannames; de uiteindelijke hoeveelheid data die ik erheen kan sturen kan een stuk groter of kleiner uitvallen.

Ow, trouwens, misschien ook wel leuk om te vermelden: Doordat de klok van de GPU-ARM niet helemaal lekker deelbaar is tot de 15.nogwat MHz pixelclock die de originele Mac had, valt de verversingsfrequentie van mijn CRT iets hoger uit dan het origineel: 68Hz ipv de originele 60Hz. De CRT zelf lijkt het niet rampzalig te vinden en ik vind het persoonlijk ook wel OK: mijn keistrak-TFT-beeld-gewend-zijnde ogen zagen de 60Hz van het origineel knipperen. Die 8Hz erbij zorgt voor een veel dragelijker beeld; dat die waarde niet helemaal 100% retro is ziet toch niemand

[ Voor 13% gewijzigd door Sprite_tm op 09-08-2010 00:19 ]

[TD-er]

Op mijn werk zijn we bezig met vrijwel hetzelfde, alleen dan andersom.
Van een CMOS sensor naar USB, met een SRAM als buffer voor het geval de PC de data niet snel genoeg uit de USB kan trekken.
Daar gebruiken we een FPGA om een FIFO te maken voor 1 beeldlijn zodat we 2 pixels tegelijk kunnen schrijven naar de (16 bit) SRAM en dus in de tijd van 1 beeldlijn 2 beeldlijnen kunnen wegschrijven.
In de idle-tijd van die 1e beeldlijn (wanneer de FIFO dus weer gevuld wordt) kan de SRAM weer geleegd worden via de USB. Uiteraard is daarop een aantal varianten mogelijk, zoals de FIFO als voorsprong gebruiken die dan gedurende de volgende lijn weer leeggelezen wordt.
De extra tijd in de blanking gebruiken we dan om de achterstand van het uitlezen van de SRAM weer in te lopen.
Mogelijk dat je op de cpu ruimte hebt om ook zo'n fifo achtig iets te maken?

FPGA klinkt hiervoor als overkill, maar dat ding wordt uiteraard ook nog ingezet om imageprocessing te doen en nog allerlei andere leuke dingen.

[M4RTiN]

Elke keer weer leuke vooruitgang, vindt dit heel erg leuk om te lezen, ga zo door!

[Sprite_tm]

TD-er: Jah, als ik een stapeltje Virtexen ofzo had liggen had ik het wel geweten in de meeste enigszins OK'e FPGA kan je alles stoppen wat ik zou willen. Het probleem is een beetje tweeledig: ten eerste heb ik hier geen FPGA's op een klein genoeg bordje liggen (enkel wat losse CPLDs die eigenlijk te klein zijn) en ten tweede heb ik atm eigenlijk helemaal geen zin om mijn VHDL weer op te halen

Ik ga eerst eens kijken hoever ik hiermee kan komen. Mocht de setup zoals ik hem nu heb niet lukken kan ik altijd nog wat ruimte winnen door de databus naar mijn dram wat te verbreden: die is nu slechts 4 bit en als ik die oprek naar 8 scheelt dat me al veel overhead.

CM'mers hier: sorry voor de tech-talk, als de gpu klaar is ga ik wel verder met iets wat makkelijker te volgen is

[TMon]

Ik vind die techtalk wel interessant. Klinkt hocuspocus en des te gaver de mod is. Weer eens wat anders dan wat hardware passend maken in een kleine case.

Ik ben ontzettend benieuwd naar het resultaat.

[ Voor 13% gewijzigd door TMon op 09-08-2010 19:27 ]

[brinkdinges]

TMon schreef op maandag 09 augustus 2010 @ 19:26:
Ik vind die techtalk wel interessant. Klinkt hocuspocus en des te gaver de mod is. Weer eens wat anders dan wat hardware passend maken in een kleine case.

Ik ben ontzettend benieuwd naar het resultaat.

Wat hij zei

[Sprite_tm]

And now, for something completely different.

Ik was al het gepruts aan de GPU even zat, en toen zag ik ineens de MacPlus die me in een hoekje zielig aan zat te staren... Ik had nog onderdelen van de SE/30 over en was vrij nieuwsgierig of er nog wat nuttigs op de HD stond.

De HD

De 40MB HD was ooit in de SE/30 gestopt, maar ik had geen idee of 'ie ook in de Plus zou werken, en of 'ie het uberhaupt zou overleven... ik had wat enge zaken gehoord over verschillende interleave-factoren en dergelijke... Eerst maar even een backupje trekken dus.

Gelukkig had ik nog een antieke SCSI-PCI-kaart in mijn rommelbak liggen:

De kaart komt ergens uit 1997 ofzo en mensen met een ander OS zouden zich dan rot moeten zoeken naar drivers, maar zelfs de meest recente Linux-kernel heeft nog gewoon kernel modules voor deze chipset in de mainstream versie zitten. Even later had ik dus een net backup-bestandje van wel 40 hele megabytes.

Puntje 2: het aansluiten van de 50-pins SCSI-HD op de DB25-aansluiting van de Mac Plus. Deze heeft namelijk in tegenstelling tot de latere Macs nog geen interne HD-aansluiting... Daar moet dus een verloopje voor gemaakt worden. Makkelijk, toch?



Wil je geloven dat ik niet voor mezelf insta als ik de bedenker van de pinout van die DB25-SCSI-variant tegenkom? Mijn god, wat zit dat een portie onlogisch inelkaar... Anyway, mijn snelle soldeerwerk werkte direct de eerste keer... maar de software op de HD moest mijn mooie Plus niet



Grmbl, nieuwerwetse systeemsoftware.. 1 megabyte is genoeg voor iedereen! Nja, gelukkig kwam de SE/30 met 8MB aan simmetjes; het moet dus te doen zijn om 4 ervan naar de Plus te verhuizen en zo het geheugen te verviervoudigen.

Het geheugen

Ouwe simmetjes eruit...


...nieuwe erin...


(slecht leesbaar, klik ff om het te kunnen zien) En profiiwheu? Waarom maar 2M? *denk* Ow, wacht, er was iets met jumpers ofzo.


Daar is het boefje wel. Die moet volgens het wijze Internet doorgeknipt worden.


En jawel: 4M aan geheugen en Systeem 7.1 start als een zonnetje. Nja, wel een traag zonnetje, je kan merken dat 't niet echt voor een Mac Plus meer bedoeld is.

De software

De HD zelf bevatte niet echt schokkende data, maar wel nog een stel old-skool spelletjes die ik vroegah ook gespeeld heb:




Bijkomend voordeel van deze hele setup is dat ik nu een mogelijkheid heb om de ouwe floppies die nog bij mijn ouders thuis liggen te backuppen. Geen enkele PC kan het rare formaat van de 800K-floppies lezen, maar als ik ze naar die 40M HD kopieer en die dan via de SCSI-kaart op mijn PC mount, kan ik alsnog bij de data komen Geen idee meer wat er op alle flops staat en of het me nog kan boeien, maar het is in ieder geval leuk om de mogelijkheid te hebben.

[TD-er]

Die floppen kun je toch wel via Linux lezen, of desnoods via VGAcopy? (oude DOS tool die echt elk wazige formaat op floppies kwijt kon.

@FPGA:
Je hoeft toch niet een FPGA te gebruiken om een FIFO te maken? of kom je niet uit met het aansturen van een ram-chip?

[Sprite_tm]

Nope, die Mac-floppies gebruiken een rare indeling en een variabele read/write-snelheid om de 800K per floppy te halen. Dat haal je met een normale floppy-drive en/of fdd-controller niet; is gewoon fysiek niet mogelijk. De latere 1.44M HD-floppies zijn iirc wel te lezen, maar de eerdere dus echt niet.

Ik kom verder niet uit met mijn CPU-tijd als ik alles tegelijk moet doen: ik ben nu zover dat de CPU het RAM-uitlezen/pixels-schrijven net aankan. Daarnaast moet ik ook nog eens USB afhandelen, en mijn proc kan maar 1 ding tegelijk... (Niet dat het zou helpen om 2 cores te hebben: mijn RAM kan namelijk ook maar 1 row tegelijkertijd schrijven of lezen.)

[GNOOM172]

Quote;
Geen idee meer wat er op alle flops staat en of het me nog kan boeien, maar het is in ieder geval leuk om de mogelijkheid te hebben.
quote.

Misschien wel hele oude babyfoto's van je, gemaakt met de eerste digitale camera?

Of volledige schema's van allerhande apparatuur

[Daedalus]

Mocht je het nog willen proberen, een aantal antieke Mac OS versies (of System Software zoals het voor Mac OS 7.6 heette) kun je bij Apple downloaden via Older Apple software downloads. Op een Mac Plus kun je officieel tot 7.5.5 gaan, dus je zou System Software 7.5.3 kunnen downloaden met de update naar 7.5.5. Mocht dat allemaal wat teveel geheugen vreten, zou je ook voor System Software 6.0.8 of zelfs 6.0.3 kunnen gaan. De Nederlandse versies van Mac OS zijn ook nog te downloaden, mocht je dat liever hebben dan de US English versie

[tricksel]

In ieder geval draai 6.0.8 als een zonnetje op een Plus; zelf ooit nog een aantal jaar gedaan :-)

[Noxious]

Oldskool jonguh

Gaaf zo, ik vermaak me prima met deze mod

[LinuX-TUX]

Noxious schreef op dinsdag 10 augustus 2010 @ 10:39:
Oldskool jonguh

Gaaf zo, ik vermaak me prima met deze mod

offtopic:
Viezerik, blijf eens van ons modje af

Ziet er PUIK uit Sprite_tm! Origineel en zie uit naar het uiteindelijke resultaat hij is nagenoeg af .

[ Voor 4% gewijzigd door LinuX-TUX op 10-08-2010 10:53 ]

[windwarrior]

wat is dat trouwens een prachtig PCB, niets SMD, allemaal normale IC verpakking!

[Noxious]

LinuX-TUX schreef op dinsdag 10 augustus 2010 @ 10:51:
[...]

offtopic:
Viezerik, blijf eens van ons modje af

offtopic:
Jamaar

[Verwijderd]

Sprite_tm schreef op maandag 09 augustus 2010 @ 23:49:
Nope, die Mac-floppies gebruiken een rare indeling en een variabele read/write-snelheid om de 800K per floppy te halen. Dat haal je met een normale floppy-drive en/of fdd-controller niet; is gewoon fysiek niet mogelijk. De latere 1.44M HD-floppies zijn iirc wel te lezen, maar de eerdere dus echt niet....

Tip:

Wikipedia: Individual Computers Catweasel

[Sprite_tm]

Linux_Tux: Nee, nog niet Die laatste grote post was een 'echte' mac, ik moet nog verder met mijn server/emulator-geval.

Windwarrior: Jah, echt leuk; zelfs de originele SIMs hebben DIP-chips erop.

Krusher: Joah, wel eens van gehoord, maar ik heb geen zin om honderd euro uit te geven voor de mogelijkheid mijn ouwe disks in te lezen. Voor de moeite van een db25 solderen wil ik 't wel eens proberen, tho'.

[NaoPb]

Nice. Dit project heeft mij geïnspireerd om me ook weer eens te gaan verdiepen in Arduino e.d.

[daft_dutch]

nu wachten tot het op hackaday komt.

[TD-er]

daft_dutch schreef op dinsdag 10 augustus 2010 @ 17:47:
nu wachten tot het op hackaday komt.

Ik denk dat wat je hier te lezen krijgt en eerder en uitgebreider is

[Radiant]

Sprite_tm schreef op maandag 09 augustus 2010 @ 17:23:
TD-er: Jah, als ik een stapeltje Virtexen ofzo had liggen had ik het wel geweten in de meeste enigszins OK'e FPGA kan je alles stoppen wat ik zou willen. Het probleem is een beetje tweeledig: ten eerste heb ik hier geen FPGA's op een klein genoeg bordje liggen (enkel wat losse CPLDs die eigenlijk te klein zijn) en ten tweede heb ik atm eigenlijk helemaal geen zin om mijn VHDL weer op te halen

Ik ga eerst eens kijken hoever ik hiermee kan komen. Mocht de setup zoals ik hem nu heb niet lukken kan ik altijd nog wat ruimte winnen door de databus naar mijn dram wat te verbreden: die is nu slechts 4 bit en als ik die oprek naar 8 scheelt dat me al veel overhead.

CM'mers hier: sorry voor de tech-talk, als de gpu klaar is ga ik wel verder met iets wat makkelijker te volgen is

Misschien een idee om dual ported RAM te gebruiken en die aan de adresbus plakken van die andere ARM of nog een ARM te pakken die puur je USB gaat regelen?

[Zsub]

[b][message=34490333,noline]
CM'mers hier: sorry voor de tech-talk, als de gpu klaar is ga ik wel verder met iets wat makkelijker te volgen is

Zo heeel tech-y is het toch nog niet? Ik kan het in ieder geval volgen met best weinig EL-achtergrond

[Marijn100]

Wow wat een idee ik vind het echt geweldig Af en toe een beetje re tech-y maar ik lees er wel tussendoor Veel succes in ieder geval!

[gibraltar]

Sprite_tm schreef op zondag 01 augustus 2010 @ 22:05:
Ik heb besloten om de GPU rond een LPC1343 op te bouwen, da's een 72MHz 32bits uC die ingebouwd USB heeft. Cool en shit en stuff, maar dan moet ik die wel eerst werkend krijgen; dev-omgeving opzetten etc. Eitje: ik heb al ervaring met een andere ARM van NXP... athans, dat dacht ik.

Een dag later: crosscompileren is een bitch, voorbeelden zijn van nivo-Arduino terwijl ik die-hard bare-metal moet gaan coden om de snelheid te halen, de usb-bootloader blijkt niet helemaal compatibel te zijn met Linux, kortom: aanprutsen, aanprutsen en nog es aanprutsen. Nja, het punt waar ik nu ben kan samengevat worden in twee plaatjes:

Ben eigenlijk wel erg nieuwsgierig naar de dev-omgeving van die LPC. Zelf was ik nog op zoek naar een beetje een goedkope 32-bitter, maar de meeste goedkope ARM's uit die LPC serie werken alleen onder Windows. Welke toolchain heb je gecross-compiled, en wat moest je doen om die bootloader werkend te krijgen?

[superwashandje]

V&A aangeboden: Apple MAC LC uit 1992

[Sprite_tm]

Ahrg, ik word gek. Ik ben begonnen met de USB-code. Ik wil de code die NXP als voorbeeld levert eigenlijk niet gebruiken: die is interrupt-based en verder heb ik geen idee wat die precies uitvreet qua cpu-cycles ofzo. Ik ben dus bezig gegaan met een barebones eigen stack, maar ik kom geen steek verder: het allereerste USB-pakketje komt van de PC prima aan op de controller, maar hoewel de controller daarna zweert de response erop verstuurt te hebben, blijft de PC wachten tot 'ie data binnen heeft...

Wat wel practisch is is dat het werkend hebben van de GPU-code debuggen iets makkelijker maakt: het kost het toevoegen van een font en een schrijfroutinetje maar dan heb je een mooi groot oppervlak waar je je foutzoek-berichtjes op kwijt kunt:


Anyway, misschien zie ik al de hele dag iets over het hoofd, dus kan ik er beter een nachtje over slapen. Zoniet dan ga ik misschien toch de voorbeeld-code gebruiken en ombouwen naar non-interrupt-based. Mocht dat alsnog niet werken weet ik in ieder geval wat beter waar ik de fout moet zoeken.

@CIStem: Ik heb een random scriptje van het 'Net geplukt om een toolchain inelkaar te epibreren. Geen idee meer of ik er veel aan moest aanpassen, if any. Als startpunt voor het devven heb ik dit geheel uit SVN getrokken en lichtelijk aangepast naar mijn setup, en daarna besloten het meeste compleet niet te gebruiken. Daar zit ook een tooltje bij om de crc van je binaries te correcten; dat is nodig om ze via de mass-storage-bootloader te uploaden. Zoals ik al zei gebruik ik voor het daadwerkelijke uploade mtools; het belangrijke regeltje daarvoor is 'sudo mcopy -o -i /dev/sda firmware.bin ::/; sudo blockdev --flushbufs /dev/sda'. Genoeg info?

[ Voor 24% gewijzigd door Sprite_tm op 12-08-2010 00:36 ]

[gibraltar]

Sprite_tm schreef op donderdag 12 augustus 2010 @ 00:30:
@CIStem: Ik heb een random scriptje van het 'Net geplukt om een toolchain inelkaar te epibreren. Geen idee meer of ik er veel aan moest aanpassen, if any. Als startpunt voor het devven heb ik dit geheel uit SVN getrokken en lichtelijk aangepast naar mijn setup, en daarna besloten het meeste compleet niet te gebruiken. Daar zit ook een tooltje bij om de crc van je binaries te correcten; dat is nodig om ze via de mass-storage-bootloader te uploaden. Zoals ik al zei gebruik ik voor het daadwerkelijke uploade mtools; het belangrijke regeltje daarvoor is 'sudo mcopy -o -i /dev/sda firmware.bin ::/; sudo blockdev --flushbufs /dev/sda'. Genoeg info?

Heel erg bedankt! Tijd om te bestellen en mijn huidige 8-bits PD-regelaar om te gaan schrijven. Na het doorkijken van die LPC1343 codebase heb ik ook al besloten die te droppen (op de linker scripts en register definities na), vooral omdat ik liever een avr-libc achtige oplossing zoek die aan weinig hardware abstractie doet.

[Alpha89]

Respect man. Uitermate vet idee om de originele host werkend te houden en vervolgens een media server ervan te maken. Hoe kom je erop!

[Sprite_tm]

Nou, gister en eergister was het mooi weer en had ik andere dingen te doen, maar vandaag heb ik de hele dag gehad om aan de firmware van de unit te hacken. Die had ik nodig ook: zoals ik al vermoedde lag het bugje waardoor ik niet verder kwam aan een heel klein dingetje waarvan ik de documentatie keer op keer verkeerd begrepen had Dan is de enige manier waarop je erachter komt gewoon prutsen tot je een keer een inconsistentie opmerkt die je op het juiste pad zet. Tijdrovend, maar het voelt wel gigantisch goed als je het eindelijk werkend hebt.

En dat is dus ook het goede nieuws: USB-transfers werken! Daardoor was ik meteen weer zo enthousiast om de hele avond ook nog verder te hacken: ik wilde de code schrijven die daadwerkelijk pixels van de PC waar de unit aanhangt, kan laten zien op het beeldscherm. Wat ik al vermoedde: het geheel is best traag Ik kom helaas niet verder dan 4FPS als ik alle pixels op het beeldscherm moet veranderen. Ik heb er al wel code ingezet die de niet-veranderende pixels zo veel mogelijk niet doorstuurt.

En dan wil je testen. Waar haal je nou even veel beelden vandaan waardoor je snel het zooitje kan testen? Het antwoord was snel gevonden: mplayer kan een film, naast afspelen, ook mooi in plaatjes opdelen. Nog wat code later, een stukje dithering, en dit is het resultaat. Let vooral op het feit dat de framerate ineens omhoogschiet zodra het beeld niet meer al te veel verschuift of verandert: dit is de compressie waar ik het over had. Ook is de code nog niet helemaal 100%: er zijn glitches te zien waar ik nog achteraanmoet... maar dat is voor een volgende keer.

Nog een dingetje: Het lijkt in de video misschien alsof ik grijstinten gebruik. Da's niet waar; ik gebruik een simpele dithering wat door de blur van de camera op grijswaarden lijkt. De monitor en aansturing is nog steeds 100% zwart-wit.

[windwarrior]

Waar je eigenlijk in dit voorbeeld last van hebt, is dat The Simpsons keurig in 24fps(?) opgenomen is, en je controller soms maar 4 fps uit kan spugen, hierdoor loopt het filmpje te traag. Is het niet mogelijk de plaatjes die je uit het geheugen haalt een soort van "tijdcode" mee te geven, zodat je wel de juiste timing hebt, ondanks de 4 fps.

Om mijn (warrige) verhaal uit te leggen neem ik een voorbeeld van een klok, die tot op de 1/24 van een seconde (wat toevallig) tikt. (mijn klok heeft een extra wijzertje voor de milliseconden ofzo) Nu spuugt jouw systeem zovaak als hij kan een beeld uit, maar dat zou betekenen dat de klok verkeerd gaat lopen, toch? Hij loopt immers slechts met 4fps, terwijl de klok 24 beeldjes per seconde maakt. Ruwweg loopt het systeem 6 keer zo traag.

Misschien dat dit minder uit maakt, in jouw geval, maar het viel me op, toen ik de intro van The Simpsons keek.

En voor de rest, echt super veel respect, ik krijg het nog niet eens voor elkaar een arduino een nokio 6100 scherm van pixels te voorzien.

[ Voor 10% gewijzigd door windwarrior op 16-08-2010 00:31 ]

[Sprite_tm]

Klopt, het gaat traag as hell maar dit is op zich maar een demo van hoe ver ik gekomen ben, het uiteindelijke doel is niet om filmpjes op het display weer te geven dus alle hippe sync-code zou in principe waarschijnlijk weggegooid zijn. Komt bij dat ik vandaag al genoeg gecoded had, dus jullie moeten het hiermee doen

[windwarrior]

Wat ik er van begrijp, stuurt jouw freeagent beelden over de usb(?), doet hij dit niet op een bepaalde rate (b.v. 24 fps?), zou jouw systeem dan niet onmogelijk traag worden? En op den duur, nadat de achterstand duizenden frames is, verschikkelijk achterlopen?

Correct me if i'm wrong

*windwarrior vindt jouw project stiekem supervet

[ Voor 9% gewijzigd door windwarrior op 16-08-2010 00:47 ]

[Sprite_tm]

Dit is nog even mijn normale workstation maar dat freeagent-bordje zou het net zo goed moeten kunnen doen. Op dit moment stuurt 'ie gewoon door wat 'ie kan, wat vaak te weinig is en soms teveel. Als ik de beeld-logica in de emulator ga bouwen ga ik daar nog wel wat intelligents op verzinnen; misschien dat het frameskip word, misschien dat ik het op een andere manier ga oplossen.

[TD-er]

Welke resolutie haal je nu?
320x240x1 ?
En welke verticale resolutie zou haalbaar zijn? (hoeveel beeldlijnen dus)
Ik neem aan dat er een geheeltallige factor tussen beide verticale resoluties zit, zodat je extra tijd hebt om USB-transfers te doen.
Wat je trouwens zou kunnen doen in de code is detecteren of er weinig transfers zijn en dan gaandeweg verzoeken om het beeld opnieuw op te bouwen. Dit om artefacten door verloren transfers te compenseren/repareren.
Op die manier kun je dan ook enige intelligentie qua compressie in de host inbouwen.

[Sprite_tm]

Ik haal gewoon de volledige resolutie, namelijk 512x342x1@68Hz. Ik kan dus alleen niet ook elk frame nieuwe data laten zien, dat trekt de ARM niet. Transfers zouden uberhaupt niet verloren moeten kunnen gaan, daar heeft USB teveel handshaking voor; het feit dat ik artefacten heb is naar alle waarschijnlijkheid gewoon een bug in mijn code. Ik gok zelf dat ik iets te enthousiast geweest ben met mijn ram-timings; we zullen zien.

[Noxious]

Awesome zeg, afhankelijk van wat je op het scherm wil tonen kan dit natuurlijk al meer dan genoeg zijn qua snelheid.

[djneo-nl]

Hoe ga je het mac os eigenlijk emuleren, Mini vMac poorten naar je arm bordje.

Heb je dan wel trouwens een ROM bestandje nodig van je SE of plus (of google).

[Sprite_tm]

Beeld! En floppies upgraden.

Nou, het kostte even, maar ik heb nu daadwerkelijk beeld zonder dat een snel inelkaar geschreven programmaatje de enige tool in de wereld is die het op mijn beeldscherm kan zetten.

Hierboven staat dat de planning was dat ik van plan was 1 van de Mac-simulatoren te pakken en daarvan de beeld-uitspuug-routine aan te passen en te laten schrijven naar mijn device. Op het laatste moment heb ik toch besloten het niet te doen: het leek me universeler om een framebufferdriver voor de linux-kernel te schrijven. Zo'n driver zorgt er feitelijk voor dat Linux je apparaat als een 'gewone' niet-geaccelereerde GPU ziet. Het voordeel is dat als ik zover ben, ik makkelijk van emulator kan switchen als ik dat wil: als 'ie beeld via een normale PC-monitor kan uitspugen kan ik dat beeld ook naar mijn 9" CRT'tje sturen.

Meteen even minivmac opgestart:


Woei, da's waarschijnlijk een hele tijd terug dat die Mac-monitor een spelletje heeft gezien:


Hmm, ik draai feitelijk gewoon X; er is niets wat mij tegenhoud om even lekker anachronistisch te doen (En ja, ik draai T.net onder de Silver-template.)

De floppy-drive

Zoals ik al zei is het ook de bedoeling om met de FDD wat te doen. Uiteindelijk leek me het idee om er een overgrown cartreader van te maken toch het best. Dus we beginnen met een ouwe floppy uit elkaar te slopen:


Woei, dat heb ik in mijn jeugd vrij vaak gedaan. Nog nooit zo voorzichtig, tho'.

Ik wilde er een SD-cartreader van maken, dus ik had een SD-slot nodig. Die had ik nog wel op een oud printje zitten, dus daar meteen maar even de verfafbrander opgezet...

...Mental note: Als er condo's op een print zitten die je met een verfafbrander bewerkt, schrik dan niet van de eventuele knallen

De floppy was wat dunner dan het SD-slot, dus het geheel moest aan de onderkant door de behuizing heensteken.


En zo gaat het geheel contact maken: aan de onderkant waar normaliter de leeskop contact maakt met de schijf, zit een stukje print gebouwd waar contact mee gemaakt kan worden.


Spul weer inelkaarzetten en je hebt iets wat op de bovenkant nog enigszins op een floppy lijkt...


...maar aan de onderkant toch net iets anders is.


Puntje 2: De floppy drive. Hier zit een heleboel op wat overbodig is voor de nieuwerwetse manier van portable data-opslag...


Dus halen we dat eraf



Hoe gaan we nou contact maken met de SD-kaart in de floppy? Daar hebben we deze bad boys voor:

Dit zijn zogenaamde pogo-pins: in het gouden gedeelte zit een veer zodat het zilverkleurige pinnetje naar binnen kan schuiven. Deze dingen worden gebruikt om printplaten te testen door contact te maken met bepaalde plekken op zo'n printplaat. Laat dat nou precies zijn wat ik ook voor ogen heb

Even solderen later zitten ze allemaal netjes naast elkaar op een printplaatje vast.


En zo komen ze uiteindelijk in de drive te zitten:

Het werkt prachtig: je laad een floppy en het mechanisme drukt de hele flop netjes op de pogo-pins. Dat zou goed contact moeten maken.

Het enige motortje wat ik heb laten zitten is die van het eject-mechanisme. Werkt die nog? Maar natuurlijk!

En, werkt het geheel ook daadwerkelijk als card reader? Ik ben bang dat ik 't je niet kan zeggen. Ik zou zweren dat ik hier nog honderd miljoen miljard van die el-cheapo micro-sd-cardreaders had liggen waar ik die pogo-pins met gemak even aan zou kunnen solderen, maar ik geloof dat ik ze in een hongerige bui allemaal opgegeten heb ofzo. Ik heb een stel nieuwe besteld, maar die moeten uit China komen en dat duurt even... Nou ja, 't is niet zo alsof de casemod zelf morgen al af is.

[Pronezz]

wooo, dat is super vet !!!!

[Marijn100]

Die dingen zou je op de markt moeten brengen! Echt heel vet. Dat eject geluidje brengt echt herinneringen boven

[Dutch-gabber]

Pronezz schreef op woensdag 18 augustus 2010 @ 22:53:
wooo, dat is super vet !!!!

Helemaal mee eens!
Sprite

[TD-er]

Wat is de snelheid van je mac-emulator?
Geeft het beeld en verder onbruikbaar, of zit het qua snelheid in de buurt van de oude mac? Beeld-opbouw-snelheid zal wel minder zijn gok ik.

[Sprite_tm]

Op dit moment is de framerate in de kernel driver nog hard gecapped op 6FPS; ik wil dat omhoog trekken naar 30 of misschien wel 60FPS maar met de huidige structuur gaat het beeld dan ongelovelijk laggen als er te veel te updaten is. Hetgene waar ik bang voor was, was dat als een programma opgestart word en dus het hele beeld verandert, het traag zou aanvoelen. Dat valt echter mee; de ervaring lijkt hetzelfde te zijn als op mijn Plus.

[Noxious]

Haha errug gaaf dat je gewoon X kan draaien er op nu op het moment dat er geen games/emulator draaien kun je daar nog allemaal hippe stats langs laten komen

Conky draaien ofzo, of zelf iets bakken ervoor