Alle Atari-Programme von Sven Kopacz sind frei!

[Lukas Frank]

Bei mir unter Aranym mit 8,16,24,32bit Farbtiefe will es nicht laufen, keine Ahnung wo das Problem ist/liegt ...

[mfro]

Bei mir unter Aranym mit 8,16,24,32bit Farbtiefe will es nicht laufen, keine Ahnung wo das Problem ist/liegt ...

So wie's (im Sourcecode) aussieht, unterstützt das Programm nur genau ein Format für die Bildschirmorganisation: 8 Bit Farbtiefe, indexed, Byte-interleaved.

Das dürfte das VDI Screenformat von MagiC Mac sein, nehme ich an. Demnach läuft Grape auch nur dort.

[Lukas Frank]

Danke, dachte mir schon so was in der Art ...

Vielleicht nimmt sich ja mal jemand den Quellen an und macht daraus ein für alle brauchbares Programm !

[mfro]

Vielleicht nimmt sich ja mal jemand den Quellen an und macht daraus ein für alle brauchbares Programm !

Viel Spaß dabei! 

Das würde bedeuten, alles (mit Ausnahme der GEM-Oberfläche und ein bißchen anderem Zeugs) VDI-konform neu zu schreiben. Sieht für mich nach einem (ziemlich oberflächlichen) Blick in die Quellen zumindest stark danach aus.

Das dürfte wohl der Grund sein, warum das Programm nie veröffentlicht wurde. Offensichtlich war es dem Autor wichtig, daß es auf genau dieser Plattform so schnell wie möglich läuft. Portabilität war dabei jedenfalls anscheinend kein Kriterium.

Einem geschenkten Gaul...

[m0n0]

Hallo,

ich denke da nicht ganz so negativ...

Also wenn ich denNotizen/Dokumente bei den Sourcen glauben schenke, dann arbeitet grape intern mit 24 Bit, und für die bildschirmausgabe wird das ganze in 8 bit konvertiert.

Meiner Einschätzung nach, wäre der erste Schritt, die Funktion do_dither in pencopy.s anzupassen.

do_dither ist in Assembler geschrieben, so wie einige andere Funktionen auch... das schlimme an Assembler ist, das die Parameter an funktionen nicht deklariert werden (was schon mal für ein mindestmaß an Beschreibender-Semantik mit sich bringen würde), und der Programmierer die eigentlich dokumentieren muss =)

Kann natürlich sein das es hier und da noch andere Direkte Bildschirmzugriffe gibt, z.B. bei der Lupe oder so.... aber trotzdem ist festzuhalten das Grape intern mit 24 Bit arbeitet

Von daher denke ich, müssten "nur"/in erster Linie die ausgabe/dither Funktionen angepasst werden.

[Lukas Frank]

Da hat jemand es gestartet auf einem Atari TT mit MiNT ->   http://www.atari-forum.com/viewtopic.php?f=14&t=26524#p253372

[m0n0]

Hallo,

ich habe jetzt auch die E-Mailer sourcen hochgeladen.

http://monokrom.orion.uberspace.de/sven.kopacz/

Wäre nett wenn Ihr die Infos wieder verbreitet.

Leider hatte ich keine Screenshots vom ASH-Emailer parat. Wenn jemand da noch irgendwas findet, würde ich es dann auf der Webseite einpflegen .

[MJaap]

Prima, ich werde die Meldung noch in die st-c 02/15 reinnehmen und die News dann vorab auf atari-home veröffentlichen. Ich müsste auch noch Screenshots des Programms aus meinem EMailer-Test (einer meiner schwächsten Artikel) haben.

[m0n0]

Was die Sourcen angeht, das ist an einigen stellen NVDI und MagiC lastig, und wenn man dass unter FreeMiNT zum laufen bekommen möchte, dann ist das keine Anfänger Aufgabe =) Umstellen auf den FreeMiNT Stack sollte die leichtere Übung sein... andererseits, die Sourcen erstmal auf GCC umzustellen bedeutet natürlich auch relativ viel sorgfältige Arbeit...

Und AHCC ist sowieso ein Thema für sich Ich bin diesbezüglich Vorsichtig geworden. Ich meine explizit wenn es um bestehende Sourcen geht. Da kompiliere ich einen Haufen bestehenden Code, evtl. mit ein paar "speziallitäten" die sich durch die Nutzung von PureC ergeben haben, Ich passe evtl. einige Stellen an, aber im Großen und Ganzen kann man schlecht feststellen an welchen Stellen es problematisch wird/ist. Nicht zuletzt weil die Gründe dafür so vielfältig sind. Bei GCC hat man meiner Erfahrung nach einfach ein verdammt gutes Fundament...

Wenn man neue Software entwickelt, Stück für Stück, dann trifft man evtl. auf Dinge die einem Probleme im AHCC bereiten, aber kann das besser handeln... Anders ist's beim Portieren: Da hat man viele Stücke gleich von Anfang an. Und insbesondere wenn man dann noch Anpassungen am Source Code vornehmen muss - und damit neue Unsicherheiten einbaut. Ach, und da war ja noch was mit Coldfire

[TheNameOfTheGame]

mehr kommt? 

[Arthur]

Kann man sich die Programme oder Sourcen irgendwo downloaden?

[Arthur]

Zumindest den Code von Grape kann man übers Webarchive noch bekommen..

[djbase]

Gute Frage, ich kann es bei mir auf atariworld.org packen, falls jemand ein Backup hat.

[Arthur]

Gute Frage, ich kann es bei mir auf atariworld.org packen, falls jemand ein Backup hat.

Hier der Link zu Grape

https://web.archive.org/web/20160323023348/http://monokrom.orion.uberspace.de/sven.kopacz/grape.zip

Und Emailer https://www.dropbox.com/s/hyxk4jtz2kpfsky/Emailer_and_IConnect.zip?dl=1

[djbase]

Danke! Beide Programme samt Source eingefügt, werde das am Wochenende vielleicht ein wenig übersichtlicher noch gestalten (Optik sowie Source und PRG trennen).

https://www.atariworld.org/software/anwendungen/

[Arthur]

Wir haben zu danken.

[Thorsten Otto]

werde das am Wochenende vielleicht ein wenig übersichtlicher noch gestalten (Optik sowie Source und PRG trennen).

Interessanter wäre vielleicht dafür zu sorgen daß es läuft Ein bisschen eigenartig daß ein Programm, das angeblich alles in Truecolor macht, ausgerechnet in Aranym nicht funktioniert.

[Atariosimus]

Hallo,

ich habe jetzt auch die E-Mailer sourcen hochgeladen.

http://monokrom.orion.uberspace.de/sven.kopacz/

Wäre nett wenn Ihr die Infos wieder verbreitet.

Leider hatte ich keine Screenshots vom ASH-Emailer parat. Wenn jemand da noch irgendwas findet, würde ich es dann auf der Webseite einpflegen .

Der Link funktioniert leider nicht

[Thorsten Otto]

Der Link funktioniert leider nicht

Nein, aber der von Arthur gepostete geht (zumindest gings gestern noch, irgendwie scheint es da auch Schwierigkeiten zu geben)

Ansonsten halt den neuen von djbase nehmen.

[gh-baden]

Interessanter wäre vielleicht dafür zu sorgen daß es läuft Ein bisschen eigenartig daß ein Programm, das angeblich alles in Truecolor macht, ausgerechnet in Aranym nicht funktioniert.

Wieso ist’s eigenartig, dass ein „eigentlich“ unveröffentlichtes Programm, das noch ziemlich unpoliert und roh aussieht, und das wohl nur unter MagiCMac laufen sollte, unter Aranym nicht läuft?

Code: [Auswählen]

void memtest(void *p)
{
if(!p)
{
form_alert(1,"[3][Nicht genug Speicher!][Quit]");
exit(0);
}
}

Arg viel „defensive“ Fehlerbehandlung ist wohl nicht drin. Es ist halt schlicht nicht fertig, oder ein „Produkt“. Wenn man nur für sich programmiert, kann man Abkürzungen nehmen, die man sonst nicht nehmen würde.

Code: [Auswählen]

vq_extnd(handle, 1, work_out);
planes=work_out[4];
[…]

if(!test_resolution(planes))
{
wind_update(END_UPDATE);
form_alert(1,"[3][Grape:|Fr dieses Bildschirmformat|existiert kein Treiber!][Abbruch]");
return;
}

und

Code: [Auswählen]

int test_resolution(int planes)
{ /* Prft ob Treiber fr den Screen vorhanden sind */
/* Rckgabe: 1=Ja, 0=Nein */

int a, ret=0;
unsigned char pls[64], pld[64];
MFDB src, dst;

src.fd_addr=pls;
src.fd_w=16;
src.fd_h=1;
src.fd_wdwidth=1;
src.fd_stand=0;
src.fd_nplanes=planes;

dst.fd_addr=pld;
dst.fd_w=16;
dst.fd_h=1;
dst.fd_wdwidth=1;
dst.fd_stand=1;
dst.fd_nplanes=planes;

if(planes == 8)
{
for(a=0; a < 8; ++a) pls[a]=1;
for(a=8; a < 64; ++a) pls[a]=0;

vr_trnfm(handle, &src, &dst);

if(pld[0]==255) ret=1;
}

return(ret);
}

Ich bin kein VDI-Grafiker, aber das mit den 8 Planes sieht nicht nach „TrueColor“ aus.