atari-home.de - Foren

Software => Coding => Thema gestartet von: afalc060 am Mo 16.05.2011, 19:47:13

Titel: Gemeinschaftsprojekt?
Beitrag von: afalc060 am Mo 16.05.2011, 19:47:13
Mal so als generelle Frage in den Raum geworfen..

Falls ja, wäre dann zu klären was gemacht wird..
Ich denke wir sollten dabei auf dem Teppich bleiben..
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: ragnar76 am Mo 16.05.2011, 20:03:18
Kleiner Vorschlag. Einen nativen in GEM gegossenem Jabber Client :D
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: FrederickMeißner am Mo 16.05.2011, 20:49:10
Jo, Jabber client ;)

Das ist tatsächlich sogar "einfach". Und 175€ stehn dafür auch schon :)
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: Dennis Schulmeister am Mo 16.05.2011, 21:26:22
Wie könnte denn hier die Projektorganisation aussehen? Ich meine Subversion oder Mercurial gibt es für Atari nicht, sind aber für eine geordnete Entwicklung notwendig (meiner Meinung nach). Das Beste wäre wohl, im Emulator zu programmieren und die Verwaltung der Quellcodes im Host System zu erledigen.

Gruß,
Dennis 8)
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: afalc060 am Mo 16.05.2011, 22:01:07
ich dachte eigentlich eher an ein spassiges spielchen für nen kleinen st oder so..
einen ausgewachsenen jabber-clienten in gem halte ich doch für leicht übergewichtig..
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: FrederickMeißner am Mo 16.05.2011, 22:37:15
Quatsch,
das ist einfacher als Du denkst. Ein Spiel würde viel schwerer werden. Denk mal nach, was muss so ein client schon können? Nachrichten empfangen und Nachrichten verschicken. Das Protokoll ist open source. Dann muss er noch User verwalten können. Wirklich viel mehr ist es nicht. Vielleicht nochmal gokmase anschreiben. Der hat ja den AtariCQ gebastelt. Mir hat er leider nicht geantwortet...

Trau Dich und code! Es winken 175€ ;)
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: afalc060 am Di 17.05.2011, 07:35:53
Wenn das so einfach ist, dann mach ma..
Ich bin raus..
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: tuxie am Di 17.05.2011, 07:48:37
Sollte dann ja auch unter GEM laufen! Aber was gibt es denn im Open Source bereich für Clienten? Die man eventuell verwenden könnte und nur eine GEM GUI dafür zurecht bastelt?
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: FrederickMeißner am Di 17.05.2011, 07:56:20
Naja,
CenterIM oder Psi z.B.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: ragnar76 am Di 17.05.2011, 12:31:37
Zitat
Wenn das so einfach ist, dann mach ma..
Ich bin raus..
Nicht böse sein. Wir könnten ja ein kleines Spielchen un den Client einbauen  ;D
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: tuxie am Di 17.05.2011, 13:24:24
Also ich hab mir mal CenterIM angeschaut! Als MiNT port sollte das machbar sein, er kompiliert bis SSL durch aber dann spuckt er einen Fehler aus das er SSL haben möchte Ich muß mal schauen ob ich das Fixen kann.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Di 17.05.2011, 17:15:10
OpenSSL ist bei Keith verfügbar:

http://www.radix.net/~atari/mint/mar2011/

....entweder per rpm installieren oder die entsprechenden libs/includes entpacken und korrekt platzieren.

Ich weiss nicht genau welche LIBs von CenterIM genutzt werden - es ist sicherlich gut schonmal CenterIM als PoC zu haben, aber ich persönlich würde mir defintiv auch finch anschauen. Wenn man das zum laufen bekommt (mit conholio macht es bestimmt einen guten Eindruck - wenn auch kein GEM interface ;) ) - dann hätte man definitv alles an Handwerkszeux was man für einen GEM client braucht.
Aber der schwierigkeitsgrad dürfte höher als CenterIM sein.... um einiges - glaube ich.

Nur... für beide gillt.... TOS kompatibilität ist damit noch lange nicht erreicht. Das wird sogar ein recht großes Problem - bei Finch wird es schon fast unmöglich sein ;) Das Problem ist halt, das es für TOS keine Socket API gibt - ausser für MagiC....

 
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Di 17.05.2011, 19:00:31
centerim verwendet garkein openssl, jedenfalls nicht für jabber.... sondern GNUTLS oder sowas.... - dafür muss man aber mindestens noch 2 weitere libs für mint kompilieren die für GNUTLS benötigt werden....
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Fr 27.05.2011, 00:02:52
Hallo,

ich hätte eine gute Idee: Einen bootmanager - der open source ist - denn für die FireBee gibt es noch keinen.

Man kann ja erstmal klein Anfangen, und man kann dafür absolutes Standard C Verwenden... einfach nur kommandozeilen Programmierung, ohne GUI schnickSchnack.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: tuxie am Fr 27.05.2011, 07:27:38
Oh da wäre ich dabei! Ich glaube das bekomme ich hin!

Nur soeine Idee! Was haltet ihr davon wenn wir das als Gemeinschaftsprojekt machen und richtig beim Urschleim anfangen. Was gehört da dazu? Natürlich ein Programmablaufplan. Zumindest einen groben.

Ich hatte mir damals ein PAP für mein 8Bit Bios Projekt gemacht und es dann in einem AVR umgesetzt, so spart man viel Zeit.

Viele Grüße

Ingo
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: virgo660824 am Fr 27.05.2011, 17:00:25
Also ich schließe mich ragnar und FM an  :D

Versionsverwaltung mit SVN ist auch ne sehr gute Idee.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Fr 27.05.2011, 20:26:52
Man könnte auch so anfangen das man eine liste der benötigten funktionen erstellt. Also prototypisiert.

Ich mach mal - vereinfacht und auf deutsch - würde ich bei einem normalen programm nicht machen ;)


/* füllt eine liste mit den informationen die auf der Partition C: gefunden werden: */
lese_autostart_programme()

/* bennent datei um und updatet die liste */
deaktiviere_autostart_programm( programmname )

/* wartet auf tastendruck und fuert je nach taste ein anderes unterprogramm aus, bzw. beendet den bootmanager */
behandle_benutzereingabe( maximale_wartezeit )

/* listet die programmliste auf dem bildschirm auf */
programmliste_ausgeben( filter );

/* sorgt dafür das nur ein bestimmter typ von autostart programm auf dem bildschirm ausgegeben wird, z.b. .acc, .cpx oder .prg*/
filter_setzen( typ )

/* markiert ein programm innerhalb der liste */
cursor_setzen( y_posiiton )


auf dem bildschirm könnte das dann so aussehen:
SIMPLE BOOT MANAGER

[Filter: PRG]
-----------------
  fastmous.prg
> mint.prx
  nvdi.prg





---------
F1 = prg (default), F2 =  acc, F3 = cpx, Enter = eintrag de/aktivieren, F10 = booten


Titel: Re: Gemeinschaftsprojekt?
Beitrag von: ragnar76 am Fr 27.05.2011, 20:27:16
Einen Bootmanager der Firebee  tauglich ist? Hört sich doch gut. An. Kann zwar nicht Programmieren - naja
printf("hallo welt!\n"); bekomm ich noch hin - aber wenn was ist kann ich trotzdem irgendwie helfen. Dokus schreiben oder so :)
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: tuxie am Sa 28.05.2011, 10:43:03
Ich würde mal mit ein paar Codeschnipsel beginnen.
Zitat
    #include <stdio.h>
#include <sys/types.h>
#include <dirent.h>

string lese_autostart_programme($autodir)
{
  DIR *dp;
  struct dirent *ep;    
  dp = opendir ($autodir);

  if (dp != NULL)
  {
 $i=0;
    while (ep = readdir (dp))
      $autofiles[$i] = ep->d_name;
    (void) closedir (dp);
  }
  else
    perror ("Couldn't open the directory");

  return $autofiles;
}


Der Rückgabewert müßte ja rein theoretisch ein array sein, weiß nur nicht 100pro ob das so funktionieren würde, ist eine ganze weile her wo ich das letzte mal C Programmiert habe so 3 Jahre.



Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Sa 28.05.2011, 14:34:06
Hallo,

wir müssten eigentlich noch festlegen mit welche Entwicklungsumgebung gearbeitet wird. Ich bin für PureC bzw. AHCC. Dann kann sich ein Anfänger auch auf den ersten teil des Programmier-Tutorials hier im Forum beziehen. Und man kann den Bootmanager auch auf dem ST kompilieren :) Aber ich weiss das es mit der dirent struktur und portabilität nicht so weit her ist ( ...ist unter den unterschiedlichen compilern unterschiedlich implementiert... )

Zitat
Der Rückgabewert müßte ja rein theoretisch ein array sein, weiß nur nicht 100pro ob das so funktionieren würde, ist eine ganze weile her wo ich das letzte mal C Programmiert habe so 3 Jahre.

Rein theoretisch ja, soweit ich weiss geht das sogar irgendwie. Aber das werden wir anders machen - ohne Rückgabewert, mit einer Globalen Variable. Denn auf die Liste muss eh auch von anderen Programmen aus zugegriffen werden.

Ausserdem kommen wir bei diesen Überlegungen auch schon zu den ersten unwegsamkeiten von C - das einlesen eines Verzeichnis ist im ANSI C standard soweit ich weiss nicht definiert. In deinem code werden erweiterungen der Sprache verwendet ( DIR Struktur, dirent.h etc. ) - Ich glaube am besten ist es, wenn wir an diesem Punkt nicht auf solche erweiterungen setzen - sondernd auf die Funktionen die uns TOS zur verfügung stellt. Diese können dann zwar nicht unter anderen Betriebs-Systemen genutzt werden - dafür können wir aber relativ sicher sein das jeder Compiler für den Atari diese Funktionen anbietet. (Sehr sicher sogar )

TOS (bzw. GEMDOS) bietet hierfür die Funktionen Fsfirst() / Fsnext().

Aber das ist durchaus noch eine Überlegung, keine Festlegung :)



Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Sa 28.05.2011, 14:37:03
...anmerkung:

Man kann auch die PCEXTlib ( bei purec dabei, also gehe ich davon aus das AHCC es auch hat....  8) ) für die EInlesefunktion nutzen - diese bietet die von tuxie besagt einlese methode...
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Sa 28.05.2011, 16:55:57
so, gemeinschaftsprojekt hin oder her, ich habe auch schon mal was gemacht, zunächst mal eine Projekt Datei für PureC:

;************************************************************
;
;                       PureC Project File for SIMPLEBOOT
;
;************************************************************
SBOOT.PRG  ;ausgabe programm name

; compiler setup:
; allow nested comments
; char is unsigned,
; no string mergin
; use absolute calls
.C [-C -K -M -P]

; Stackgroesse 4096
.L [-S=4096]
=
PCVSTART.O                      ; PureC startup code einbinden
MAIN.C                  ; Hauptmodul

;**********************************
;*                              LIBS
;**********************************
PCTOSLIB.LIB
PCGEMLIB.LIB
PCSTDLIB.LIB
PCEXTLIB.LIB

und einen Programmrumpf, ich hoffe es ist nicht zuviel fuer den Anfang, wenn alle die mitmachen es verstanden haben ( bei fragen, bitte posten) gehts weiter ;)

/* Standard TOS funktionen bekannt machen: */

#include <tos.h>
#include <vdi.h>

/* funktionen wie memcpy, strcpy... bekannt machen: */

#include <string.h>

/* auch die standard funktionen bekannt machen: */
#include <stdlib.h>


/* Erweiterte pureC Funktionen bekannt machen: */

#include <ext.h>

/* Textbildschirm Funktionen bekannt machen */
#include <screen.h>

/* ------------------ */
/* Globale Variablen: */
/* ------------------ */

/* Variable fuer VDI handle */
/* Wenn VDI funktionen aufgerufen werden,   */
/* dann bezieht sich das auf ein Geraet,    */
/* mit diesem handle teilen wir mit das wir */
/* auf den bildschirm ausgeben wollen... */
short vdih;

/* Array zum uebergeben von Parametern */
/* and VDI funktionen: */
short workin[16];

/* Array zum auslesen von VDI */
/* Rueckgabewerten */
short workout[58];

/* intialisiert variablen / umgebung des programms */
void init( void )
{
/* VDI Bildschirm-handle(1) oeffnen: */
memset( &workin, 0, 16*sizeof(short) );

/* VDI soll den Bildschirm nutzen: */
workin[0] = 1;
v_opnvwk( &workin, &vdih, &workout );
}


/* Funktion zur ausgabe von text an bestimmter position */
/* und ausgabefarbe (inv) */
void textxy(short x, short y, short inv, char * str)
{
if( inv ) {
Rev_on();
}
Goto_pos( x, y );
Cconws( str );
if( inv ) {
Rev_off();
}
}
/* Hauptprogramm, wird aufgerufen nach start des Programms: */
int main(void)
{       init();
textxy( 0, 0, 1, "SIMPLEBOOT" );
return( 0 );
}


wenn pc.prj und main.c in ein verzeichnis gelegt werden und man es mit purec kompiliert ( make all ) dann kann man das Programm schonmal in den auto ordner legen und schauen wie es aussieht ;)
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: tuxie am Sa 28.05.2011, 20:53:59
So jetzt habe ich mal versucht den code zu kompilieren. Musste alle libs in das Verzeichnis kopieren sonst hat er diese nicht gefunden! Weiß noch nicht ob ich was falsch konfiguriert habe.

Dann bringt er die Meldung das er die Datei PCVSTART.o nicht finden kann.

Titel: Re: Gemeinschaftsprojekt?
Beitrag von: tuxie am Sa 28.05.2011, 21:10:38
rename PCVSTART.or to AHCSTART.o works.

Aber nun hagelt es fehler das er diese libs nicht finden kann

PCTOSLIB.LIB
PCGEMLIB.LIB
PCSTDLIB.LIB
PCEXTLIB.LIB
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Sa 28.05.2011, 21:27:09
ja, wenn man ahc benutzt... dann muessen die libs anders heissen (uebrigens auch bei purec sollte man pcstart.o anstatt pcvstart.o verwenden ..., war ein fehler )

Wie genau die libs bei ahcc heissen weiss ich jetzt nicht.... muesste so sein:

AHCCSTDI.LIB

wenn das noch nicht reicht,
AHCCGEM.LIB

noch zufuegen


wenn das nochnicht reicht:

GEMF.LIB zufuegen....


AUsserdem enthalten die einzelnen pakete von ahcc (020 etc.) auch noch unterschiedliche libs - da kann wohl nur Henk etwas zu sagen.

Sobald ich das .prj unter AHCC kompiliere kann ich auch mehr dazu sagen. 
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: Arthur am Sa 28.05.2011, 21:30:25
Welche AHCC Version nehme ich auf dem ST wenn die Software später auf allen Ataris und der Firebee laufen soll? Oder muß ich alle AHCC Versionen auf meinem 1040 installieren? Laufen die auf dem überhaupt?
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Sa 28.05.2011, 22:42:24
das ist eigentlich egal... Man kann ja in den optionen einstellen fuer welches system kompiliert werden soll.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: simonsunnyboy am So 29.05.2011, 10:16:24
In einem Autostartprogramm wie einem Bootmanager haben VDI Kommandos, auch init und dgl. dafür, nichts verloren. VDI und AES stehen noch nicht zur Verfügung!
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am So 29.05.2011, 13:11:02
Das ROM VDI steht sehr wohl zur verfügung. Bezüglich des AES gebe ich dir recht, aber das nutzt ja auch keiner.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am So 29.05.2011, 13:34:21
P.S. wenn Du sowas schreibst - dann ist eine Quellenangabe ganz sinnvoll.

Das AES noch nicht geladen ist, ist klar.... aber VDI? Dafür will ich beweise sehen!

Ich weiss nur das es so funktioniert wie ich es gemacht habe ;)
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am So 29.05.2011, 14:27:28
mein momentaner stand benutzt VDI zum zeichnen eines Logos ( Monochrom bitmap ) mittels der VDI rasterfunktionen und das funktioniert tadellos.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Mo 30.05.2011, 17:28:40
Ich habe nun relativ viel gesucht und es klingt so als sei VDI bestandteil von GEM.... in dem Fall ist es dann halt Tabu VDI zu nutzen :( ( obwohl es funktioniert, es ist nicht sauber...) .

Grafikroutinen im BootManager sind damit dann also nichts für ein Anfängerprojekt. Aber das macht ja nicht - dann halt nur Textmodus :)
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: Arthur am Di 31.05.2011, 21:54:23
(uebrigens auch bei purec sollte man pcstart.o anstatt pcvstart.o verwenden ..., war ein fehler )

Kannst Du es mal für uns Noobs näher erläutern?
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Mi 01.06.2011, 00:48:03
Ja, klaro.

Also, die Datei PCVSTART.O ist die Initialiserung der C laufzeitumgebung.

Soweit ich weiss liegt diese bei PureC auch im Quelltext vor (PCVSTART.S).

Was bringt einem die Datei? nun, auch wenn für einen normalen Benutzer das Hauptprogramm main() als der einstiegspunkt erscheint - ganz so ist es nicht.
Der wahre einstiegspunkt liegt in pcvstart.o ( oder je nachdem wie der compiler eben jene Datei benennt, bei AHCC ist es halt AHCSTART.O) - hier werden einige dinge initialisert:

z.b. wird die standardausgabe geöffnet, und - zumindest bei TOS Programmen, wird nicht benötigter Speicher an das Betriebssystem zurückgegenem - denn TOS teilt einem neuen Prozess jeglichen Freien Speicher zu. Es ist dann aufgabe des Programms diesen als "nicht benötigt" zurückzugeben. Wenn der ganze Kram erledigt ist, wir main() aufgerufen.

Das ist eigentlich schon alles. Wenn man ein Programm ganz ohne diese initialisierung haben möchte, dann lässt man diese Datei einfach weg - aber dann muss man alles selber erledigen.... nicht zu empfehlen ... aber es kann durchaus sinnvoll sein. z.b. eine Lib braucht so eine Initialisierung nicht . 

GCC hat ebenfalls so eine Datei.

Wenn es darum geht besonders kleine Programme zu schreiben - z.b. für einen bootsektor - auch dann wird soetwas weg-gelassen.

Was nun der unterschied zwischen pcvstart.o und pcxstart.o und pcstart.o ist - kann ich nicht erläutern. Aber pcstar.o zu nutzen ist wohl der normale weg.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: Arthur am Sa 11.06.2011, 13:51:14
Ich lass das mal sacken. Wie geht es nun weiter wenn wir auf das VDI verzichten müssen? Welche Funktionen hällt das TOS denn dann noch für unser Projekt bereit?
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Sa 11.06.2011, 15:09:38
Hallo,

also... eigentlich muss man nicht auf das VDI verzichten - bisher ist mir nur eine Person bekannt die das benutzen des VDI's während der Autostart Programme als nogo bezeichnet hat ( Simon ). Auf der Firebee funktioniert es aber aus anderen Gründen nicht: Das VDI kann nur einmal geöffnet werden und nie wieder geschlossen - das sorgt dafür das das GEM dann VDI nicht mehr nutzen kann :( (es ist also ein Bug in der FireBee...).

Es gibt mehrere Möglichkeiten damit umzugehen:

- Auf Bilder verzichten und den Texttlichen Bildschirmaufbau so gestallten das es nicht unbedingt notwendig ist die Dimensionen zu kennen.
 (D.h z.b. darauf verzichten in der untersten Textzeile text zu setzen - denn man weiss ja nicht wo die unterste Textzeile ist.)

- Das Programm konfigurierbar machen, so das die Auflösung vorher konfiguriert werden kann - dann könnte man auch z.b. am unteren bildschirmrand eine statuszeile einblenden, und wenn man möchte direkt auf den Bildspeicher zugreifen....

-  warten bis das firetos fvdi gepatch ist ;)

- die Informationen die VsetScreen(-1) zurückgibt parsen und daraus eine Auflösung ermitteln.... das ist schwer und benötigt kenntnis über viele Hardware erweiterungen...

Daher... um es einfach zu halten - sollten wir uns auf Punkt 1 und 2 beschraenken. Zunächst 1 und dann evt. schritt 2. - je nach lust und laune :)

Achso, TOS hält ausser Vsetscreen keine funktion für uns bereit.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Sa 11.06.2011, 16:10:17
OK... fangen wir nochmal von vorne an?

Ich habe nochmal Projektfiles für AHCC und PC zusammengepackt und main.c reduziert.

Es macht nicht viel - ausser die Versionsnummer und das Kompilierdatum ausgeben. Trotzdem sind schon einige Sachen dabei die durchaus erstmal verstanden werden muessen.

/* funktionen wie memcpy, strcpy... bekannt machen: */
#include <string.h>

/* auch die standard funktionen bekannt machen: */
#include <stdlib.h>
#include <stdio.h>

/* Standard TOS funktionen bekannt machen: */

#include <tos.h>
#include <vdi.h>


/* Ein string konstante definieren: */
/* __DATE__ ist standard und wird vom */
/* Compiler auf das aktuelle Datum gesetzt */
#define VERSION "0.1 - (" __DATE__ ")"


/* Hauptprogramm, wird aufgerufen nach start des Programms: */
int main(void)
{
/* Aufrufen der OS Routine Cconws */
/* Diese ist in tos.h deklariert   */
/* und enthalten in PCTOSLIB.LIB   */
/* bzw. AHCCGEM.LIB */
/* und gibt einen Text auf der */
/* Konsole bzw. auf dem Bildschirm */
/* aus. */
Cconws( "SimpleBoot Version " VERSION "\r\n" );
return( 0 );
}

Edit: informationen über die Betriebs-System routine Cconws:
http://toshyp.atari.org/de/005010.html#Cconws

Infos zur nutzung des C Befehls "#define" ( insbesondere um Konstanten zu definieren - man kann damit auch sogenannte macros definieren, aber das brauchen wir noch nicht):

http://www.proggen.org/doku.php?id=c:pre:define


Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Do 23.06.2011, 21:59:22
Wie - hat schon keiner mehr lust weiter zu machen? Kein wunder das C Anfänger dingsbums das hier stattfand gestorben ist ;)
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: afalc060 am Fr 24.06.2011, 11:48:09
Ich denke die Lernkurve ist etwas zu steil.
Wieso nicht auf GFA-BASIC beschränken und dann etwas einfacheres umsetzen? Zudem ist ja überhaupt nicht wirklich klar, was denn nun gemacht werden soll. Jeder hat so seine Vorstellungen.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Fr 24.06.2011, 12:07:21
hm,... Ich denke bei step 1 ist die lernkurve noch nicht so hoch und man kann ja im nachhinein auf diesem code aufbauen, meinetwegen auch ein anderes programm, aber icht dachte bootmanager waere beschlossen ;) erstmal gucken was noch kommt, mit dem code kann man ja auch viele andere programme schreiben... Naechster schritt waere halt koordinierte textausgabe und dann dateiliste ausgeben und dann dateiumbenennen.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: ragnar76 am Fr 24.06.2011, 14:58:55
Mal ne dusselige frage. Wieso nicht printf(); anstelle von Cconws();?
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Fr 24.06.2011, 18:49:48
Weil printf in dem Fall nicht benötigt wird und ich denke Cconws ist ein bisschen performanter.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: ragnar76 am Sa 25.06.2011, 03:31:24
im  grunde genomme hab ich schon kapiert was als nächstes zu tun ist. das währe dann ja wohl den autoordner auszulesen. Von php kenn ich den befehl readdir() und hab mal etwas vergleichbares gesucht.

gefunden hab ich den befehl dreaddir() der in der tos.h definiert wird aber ich bin mir nicht ganz schlüssig. im tos.hyp steht der ohne weitere einschränkungen beschrieben, im compendium wiederum steht dass das ein mint befehl währe. im profibuch hab ich nichts dergleichen gefunden.

Was ist denn nun richtig und währe das was für uns?
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: simonsunnyboy am Sa 25.06.2011, 09:47:47
Der Call ist Mint-only.

TOS kompatibel geht das mit Fsfirst() und Fsnext() . Das sind offizielle GEMDOS-Aufrufe seit 1984/85.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Sa 25.06.2011, 18:09:28
Also ich benutze in meinem Code findfirst(), findnext() das sind PureC funktionen und die sind meiner Meinung nach einfach zu benutzen als die von Atari bereitgestellten.

AHCC stellt diese Funktionen auch bereit.

Titel: Re: Gemeinschaftsprojekt?
Beitrag von: afalc060 am Sa 25.06.2011, 19:14:03
wie war das mit der beschworenen portierbarkeit von c ?? ;D
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Sa 25.06.2011, 21:19:00
ok, was cconws anbelangt gebe ich dir recht - das ein kleines eigentor bezüglich portierbarkeit... aber die nutzung von findfirst() / findnext() ähnelt viel mehr der Dateiauflistung unter linux / unix als die TOS variante.

Ich glaube um es auf einem Linux system zu kompilieren müsste man dann nur eine andere deklaration beachten, das war's dann schon.

Titel: Re: Gemeinschaftsprojekt?
Beitrag von: afalc060 am Sa 25.06.2011, 21:39:29
ich wollte nur sticheln.. das es irgendwie geht war mir schon bewusst.  ;)
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Sa 25.06.2011, 22:09:31
Naja, wenn ich mich recht erinnere habe ich von anfang an gesagt das es in ANSI C keinen standard für das Verzeichnis auslesen gibt.... aber die PureC funktion kommt der Funktion aus dem POSIX standard schon sehr nahe.

Aber darum geht es ja noch garnicht.  ::)
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: ragnar76 am Sa 25.06.2011, 23:14:52
Ob Posix kompatibel oder nicht, hier gehts doch um Atari. Was wil man mit den Bootselector auf Linux oder Windows?  Also von daher sind doch spezielle Atari only funktionen doch gestattet.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Sa 25.06.2011, 23:43:33
Natürlich, aber ich finde die nutzung von den Atari Funktionen bezüglich des Auslesens von Verzeichnissen nicht besser um die Aufgabe zu erfüllen....

Hier noch ein Beispiel für die nutzung:
void file_list( char * path)
{
        /* variable vom typ int anlegen:  */
int err;

        /* variable vom typ ffblk anlegen: */
struct ffblk blk;

        /* erstes element auslesen: */
err = findfirst( path, &blk, 0xff);
while( err == 0 ){

                /* datei name ausgeben: */
Cconws( blk.ff_name );

                /* evt. weitere elemente auslesen ... : */
err = findnext( &blk );
}
}
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: simonsunnyboy am So 26.06.2011, 09:40:29
TOS calls sind deutlich vorzuziehen, denn diese Pure C Calls rufen nichts anderes auf, und dazu noch mit einem unnötigen Overhead (mehr Datenstrukturen, mehr Unteraufrufe, mehr Sprünge -> langsamer als nötig)

Ausserdem sind die TOS Aufrufe auf jeden anderen Atari Compiler portierbar, z.B. auch den gcc.



Titel: Re: Gemeinschaftsprojekt?
Beitrag von: ragnar76 am Di 28.06.2011, 17:45:50
Roger that. Von mir aus kanns weiter gehen
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: Arthur am Di 28.06.2011, 18:45:46
TOS calls sind deutlich vorzuziehen, denn diese Pure C Calls rufen nichts anderes auf, und dazu noch mit einem unnötigen Overhead (mehr Datenstrukturen, mehr Unteraufrufe, mehr Sprünge -> langsamer als nötig)

Ausserdem sind die TOS Aufrufe auf jeden anderen Atari Compiler portierbar, z.B. auch den gcc.

Du möchtest also lieber den kleinsten gemeinsamen Nenner nehmen damit die Portierbarkeit erhalten bleibt und es auch auf Uraltcompilern noch läuft? Ich finde M0n0 wählt einen guten Mittelweg da wir ja Pure C oder AHCC nehmen. Als Hausaufgabe kann man das Programm ja noch mit den alten TOS Calls parallel schreiben...
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: simonsunnyboy am Di 28.06.2011, 19:01:24
Wenn TOS so uralt ist, wieso benutzt ihr dann alle so selbstverliebt seinen Nachfahren Mint, der auch noch erstaunlicherweise komplett kompatibel ist?  :-*

Treibt was ihr wollt, aber sich auf einen Compiler und eine Library festzulegen ist unabhängig vom System immer schlecht. Das macht später nur Arbeit...wenn mal irgendetwas nicht mehr geht.

Ausserdem ist es eine gute Übung, sich mit den TOS Aufrufen vertraut zu machen. Für ein anständiges Atariprogramm (bei euch allen sehe ich ja das Wort GEM und GUI immer groß leuchten) kommt ihr nicht darum herum, systemkonform zu bleiben.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Di 28.06.2011, 19:19:49
Was mich an den TOS funktionen stört:

Zitat
Nach Abschluß der Funktion steht der Verzeichniseintrag unter der Diskettenübertragungsadresse DTA, die mit Fgetdta und Fsetdta ermittelt bzw. festgelegt werden kann. Die Informationen können dann der Struktur DTA entnommen werden.

Es macht also Probleme wenn es Rekursiv aufgerufen wird. Das ein Verzeichnisbuam Rekursiv abgerufen werden soll, ist ja nicht nicht-selte.

Also ich persönlich muss mir das nicht geben, zumal das portieren der purec funktion einfach ist...(Falls es denn jemals gemacht werden sollte.)  Wenn jemand diesbezüglich einen Beispielcode posten kann, dann würde ich die evt. auch verwenden. Das würde den Code aber aufblaehen und nicht unbedingt leichter verständlich halten.

Und davon abgesehen halte ich die PureC Funktion für einfache - insbesondere wenn es darum geht novizen etwas zu zeigen. Bei der PureC version muss ich mich nicht um den DTA kram kümmern. bei der TOS Funktion schon.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: afalc060 am Di 28.06.2011, 19:42:10
irgendwie fehlt hier so ein klein wenig die planung  8)

was soll das programm können?
zusammenstellen mögliche funktionen/prozeduren (pseudo-code)
erklärung der nötigen datenstrukturen (systemintern)
mögliche erweiterbarkeit?
usw

zudem sollte doch lieber basic gewählt werden

also das ist zumindest meine meinung  ::)
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Di 28.06.2011, 22:29:04
Was das programm können soll ist doch eigentlich schon besprochen:

- Bestimmte Programme / ACC / CPX beim booten de/aktivieren und im besten fall auch die Bootreihen folge verändern. Ausserdem muss es Coldfire kompatibel sein.

Zitat
zudem sollte doch lieber basic gewählt werden

Welches ist denn Coldfire kompatibel?

Ich meine, wenn die leute lieber was anderes Programmieren wollen, dann gerne - aber ich bin dann raus. ;)

Zitat
mögliche erweiterbarkeit?

Sowieso - immer - ist ja open-source ;)
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: simonsunnyboy am Mi 29.06.2011, 17:18:34
Die Rekursion ist C ist kein Problem. Mach die DTA in die du die Daten reinholst, immer lokal, auf dem Stack.

D.h. du deklarierst den Speicherplatz innerhalb deiner Funktion. Diese C-Funktion ist i.d.R. dann wieder reeentrant und kann regulär sich selbst aufrufen.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: Arthur am Mi 29.06.2011, 17:24:43
Hast Du mal ein Beispiel-Code dazu?
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: Dennis Schulmeister am Mi 29.06.2011, 21:25:11
Hallo,

Singemäß wäre das so:

void main(int, char**);
void recursive_function(int, int);

void recursive_function(int amount, int max_depth) {
   int count = amount + 1;

   if (count > max_depth) {
      return;
   }

   printf("%i ", count);
   recursive_function(count, max_depth);
}

void main(int argc, char** argv) {
  recursive_function(0, 10);
  return 0;
}

count ist hier eine lokale Variable, die auf dem Stack liegt und somit nur innerhalb der Funktion existiert. Ruft sich die Funktion selbst nochmal auf, entsteht ein neuer Stack Frame, auf dem dieselbe Variable aber mit anderem Wert liegt. Nach Verlassen der rekursiv aufgerufenen Funktion befindet sich das Programm wieder im urpsünglichen Aufruf, wo die Variable wieder ihren alten Wert besitzt.

Die Ausgabe des Programms (wenn der Formatstring für printf stimmt) ist also: 1 2 3 4 5 6 7 8 9 10

Gruß,
Dennis
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: Dennis Schulmeister am Mi 29.06.2011, 21:27:20
PS: Vertauscht man folgende Zeilen, ist die Ausgabe des Programms 10 9 8 7 6 5 4 3 2 1, was den Sachverhalt noch besser verdeutlicht.

   printf("%i ", count);
   recursive_function(count, max_depth);
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: simonsunnyboy am Mi 29.06.2011, 21:54:11
Im tos.hyp steht übrigens alles was ihr braucht %)

http://toshyp.atari.org/de/005014.html#DTA (http://toshyp.atari.org/de/005014.html#DTA)
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Mi 29.06.2011, 22:24:16
Ok, hier ist Teil 2.

Code:
(Vorsicht, kommentare sind etwas abweichend von denen im Zip Archiv, da fehlt ein kleiner absatz - aber sind ja nur kommentare ;) )

/* funktionen wie memcpy, strcpy... bekannt machen: */
#include <string.h>

/* auch die standard funktionen bekannt machen:     */
#include <stdlib.h>
#include <stdio.h>

/* Standard TOS funktionen bekannt machen:          */

#include <tos.h>
#include <vdi.h>

/* Textbildschirm Funktionen bekannt machen         */
/* Diese Datei enthaelt makros (d.h. nichts anderes */
/* als Aliase fuer bestimmte kommandos, wer         */
/* interesse hat, was ich meine, schut einmal kurz  */
/* die Datei hinein                                 */
#include <screen.h>


/* Ein string konstante definieren:                 */
/* __DATE__ ist standard und wird vom               */
/* Compiler auf das aktuelle Datum gesetzt          */

#define VERSION     "0.1 - (" __DATE__ ")"


/* Neue (eigene) funktion textxy,                   */
/* ------------------------------------------------ */
/* Diese Funktion ist im gegensatz zu main() nicht  */
/* Pflicht. Es ist eine völlig eigens definierte    */
/* Funktion die machen kann was sie will, bzw. was  */
/* wir wollen.                                      */
/* man koennte sich auch anders benennen oder andere*/
/* dinge tun lassen....                             */
/* ------------------------------------------------ */
/* mit dieser Funktion kann man einen text an einer */
/* bestimmten stelle am Bildschirm ausgeben.        */
/* Die ersten beiden Parameter bestimmen die        */
/* Postion, sie sind vom typ short - das heisste    */
/* bei purec: 16 bit maximalwert.                   */
/* der parameter inv bestimmt ob schwarz auf weiss  */
/* oder weiss auf schwarz ausgegeben werden soll    */
/* der letzte parameter beinhaltet eine             */
/* Speicheradresse an die auszugebenden buchstaben  */
/* stehen, das ende der buchstaben wird durch ein   */
/* null byte markiert. (Uebernimmt der compiler     */
/* fuer gewoehnlich                                 */
/* Wichtig ist, das diese Funktion ueber main()     */
/* ausprogrammiert wird, bzw. vor jeder anderen     */
/* funktion in der diese funktin genutzt werden soll*/
/* der compiler kann nur aufrufen was er kennt....  */
/* es gibt auch die moeglichkeit funkt. aufzurufen  */
/* die nach dem aufruf ausprogrammiert sind.        */
/* aber das benoetigt eine vorherige "deklaration"  */
/* - darauf verzichten wir in diesem projekt        */

void textxy(short x, short y, short inv, char * str)
{
    /* wenn parameter inv (invertiert) ungleich 0   */
    /* ist-dann wird der reverse mode eingeschaltet */
    /* d.h. weiss auf schwarze ausgabe              */
    if( inv != 0 ) {
        /* Makro das in screen.h definiert wurde:   */
        Rev_on();
    }
    /* Jetzt wird der cursor an die gewuenschte     */
    /* Stelle gesetzt, diese anweisung ist ebenfalls*/
    /* in screen.h definiert                        */
    Goto_pos( y, x );
    
    /* Diese funktion kennen wir schon:             */
    /* wir merken: Cconws gibt immer an der moment. */
    /* cursor-position den text aus.                */
    Cconws( str );
    
    /* wenn inv ungleich 0 ist, dann wird der       */
    /* modus wieder auf normal gesetzt.             */
    if( inv != 0  ) {
        Rev_off();
    }
}

/* Hauptprogramm, wird aufgerufen nach start des Programms: */
int main(void)
{
    /* Anstatt Cconws rufen wir jetzt   */
    /* unsere eigene Textausgabe routine*/
    /* auf! */
    /* Spalte 2, Zeile 1, Invers, Text */

    textxy( 3, 1, 1,"SimpleBoot Version " VERSION );

    
    /* am ende wird nochmal ein Ruecklauf /         */
    /* Zeilenumbruch ausgegeben, damit die Konsole  */
    /* auf der wir ausgeben "sauber" ist.           */
    /* (testet einfach mal was passiert wenn man es */
    /* weglaesst.                                   */

    Cconws("\r\n");

    
    /* da die funktion main() den rueckgabetyp "int"*/
    /* (je nach compiler einstellung 16 oder        */
    /*  32 bit zahl) hat, muss ein entsprechender   */
    /* wert zurueckgegeben werden - 0 bedeutet: kein*/
    /* fehler.                                      */

    return( 0 );
}


P.S.: Wer unter Magic entwickelt, der kann das Programm mit der mitgelieferten Konsole/Shell laufen lassen ( cmd.prg ? ) .  Unter purem TOS kann ich dieses Programm empfehlen:

http://www.umich.edu/~archive/atari/Cli/ashell.lzh

(Aber eigentlich nur weil ich kein anderes kenne .... )

Unter FreeMiNT kann man das ganze gut mit Conholio oder Toswin2 testen.  

Titel: Re: Gemeinschaftsprojekt?
Beitrag von: Arthur am Do 30.06.2011, 00:31:36
Ich hab die Projektdatei für ahcc selbst angepasst und es kompiliert. Da ich keine Konsole benutze hab ich ein getchar (); hinter die Textausgabe gepackt so dass das Programm erst nach einem Tastendruck beendet wird.

    textxy( 3, 1, 1,"SimpleBoot Version " VERSION );
    getchar();


(http://mcp.ignorelist.com/bilder/sboot.gif)
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: ragnar76 am Do 30.06.2011, 10:20:31
Mal kurz nachgefragt, mit wem muss man eigentlich schlafen damit man qed als ide für purec/ahcc benutzen kann?

(http://s3.amazonaws.com/twitpic/photos/full/334171000.png?AWSAccessKeyId=AKIAJF3XCCKACR3QDMOA&Expires=1309422995&Signature=Amn1mMGgC%2FH3SlUMykkzHb%2F4Bhs%3D)
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: simonsunnyboy am Do 30.06.2011, 17:17:12
Mit keinem - bei AHCC einfach den TTP-Compiler benutzen, das ist dann nur noch nicht voll integriert.

Wie man eine volle Integration in qed reinkonfigurieren kann, würde mich allerdings auch sehr interessieren.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Mo 04.07.2011, 19:47:16
Ich bin mir sicher das der geneigte Leser noch nicht alles verstanden hat - z.b. diese Deklaration:

void textxy(short x, short y, short inv, char * str);

das interessante hieran ist der letzte Parameter - hier wird dem Compiler mitgeteilt das es sich hierbei um einen Zeiger handelt ( markierung: * ) und ausserdem auch noch auf was für daten der Zeiger zeigt. Nämlich auf char.

Für den letzten Parameter wird der Funktion also mitgeteilt wo eine bestimmte Zeichenkette liegt.

Anders bei den vorherigen Parametern, hierbei handelt es sich nicht um Zeichenketten und auch nicht um Zeiger. Es sind einfach Werte die der Funktion übergeben werden.

Ein entscheidender Unterschied ist...: wenn wir die short paramter innerhalb der Funktion verändern (z.b.: x=x+10), dann hat das keine Auswirkungen auf das nachfolgende Programm .... die Parameter wurden der Funktion als Kopie übergeben. Anders die Zeichenkette - diese Existiert nur einmal - und anstatt das eine Kopie der Zeichenkette an die Funktion übergeben wird ( geht auch...) wird der Funktion nur mitgeteilt wo sich im Speicher eine bestimmte Zeichenkette befindet. Die funktion könnte nun nach belieben diese Zeichenkette verändern - und nachfolgende Funktionen würden dann mit der veränderten Zeichenkette (das nennt man übrigens String ;) ) arbeiten.

sonst noch fragen ?



 
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: Arthur am Mo 04.07.2011, 22:36:36
Ich bin mir sicher das der geneigte Leser noch nicht alles verstanden hat - z.b. diese Deklaration:

void textxy(short x, short y, short inv, char * str);

Ich frag einfach mal so. Also mit void textxy wird die Funktion textxy deklariert oder definiert....

short x ist bedeutet das die Funktion einen Parameter "x" vom Typ short beim Aufruf erwartet....genau so auch bei y und inv

char ist eine Anzahl von Zeichen und der * besagt das str ein Zeiger auf char ist?

Ist denn str ein reservierter Begriff oder kann das ein belibieger Name sein?
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Mo 04.07.2011, 23:21:55
Zitat
Ist denn str ein reservierter Begriff oder kann das ein belibieger Name sein?

str ist nicht reserviert, man koennte es auch text nennen - es ist dann halt der name des parameters - folglich muss man dann aber natuerlich alle vorkommen von "str" mit "text" - denn sonst wird der kompiler sage das man eine variable verwenden will die nirgendwo deklariert / definiert etc. ist.   

Genauso koennen auch x und y ubennannt werden, z.b. in xpos, ypos oder so....
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Mo 04.07.2011, 23:26:06
Zitat
char ist eine Anzahl von Zeichen und der * besagt das str ein Zeiger auf char ist?

Nicht ganz richtig... char ist eigentlich nur ein zeichen.
es handelt sich hierbei also um einen zeiger auf ein zeichen. daraf folgen aber noch mehrere... der string wird durch 0 terminiert...

Cconws gibt also ein zeichen aus, erhoert den zeiger um 1 ( char = 1 byte) und wenn der speicherinhalt dort keine 0 ist wird das zeichen ausgegeben - wenn es eine 0 ist, beendet die funktion sich....
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: Arthur am Mo 04.07.2011, 23:53:06
Wo hatten wir denn str schon definiert? Oder reichte es aus das es in der Funktion als Parameter declariert wurde?
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Di 05.07.2011, 09:52:13
ja, genau. das reicht aus - jedenfalls für parameter.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: Arthur am Di 05.07.2011, 20:30:08
Ok, wir haben jetzt schon ein Programm das die Versionsnummer und das Compilierungsdatum ausgibt und zwar über unsere Funktion textxy.

In welcher Bildschirmauflösung soll das Programm eigentlich später laufen...oder in welcher besser nicht? Macht es Sinn für textxy die Auflösung vorher abzufragen?
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Di 05.07.2011, 21:23:38
Zitat
In welcher Bildschirmauflösung soll das Programm eigentlich später laufen...oder in welcher besser nicht? Macht es Sinn für textxy die Auflösung vorher abzufragen?

genau das ist ja das Problem das von Simon angesprochen wurde, und was ich auch bei der Firebee bemerkt habe...

Auf den meisten Systemen kann man beim Autostart die Auflösung abfragen. VDI funktioniert und LineA wohl auch... - Simon meint jedoch VDI darf man nicht bzw. das würde nicht gehen. bei der FireBee ist es zur Zeit wirklich nicht möglich.  Aber Didier hat da letztens einen Bug gefixt der es evt. doch möglich macht - nicht über VDI, aber evt. doch über lineA.

Unbedingt notwendig ist das Abfragen der Auflösung nicht. Wenn man jedoch etwas in der letztens Zeile/Spalte Ausgeben will,.... dann sollte man das schon wissen.

Wir werden uns erstmal nicht um die Auflösung kümmern. Im schlimmsten fall - also wenn man x,y koordinaten angibt die zu gross für die Momentane Ausgabefläche sind, dann werden Bereiche Überschrieben, d.h. wenn es nur 20 Zeilen gibt, aber man schreibt auf Zeile 21, dann wird Zeile 20 Überschrieben.

Die x,y koordinaten sind übrigens keine Pixelkoordinaten sondern zeilen/spalten.

Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Di 05.07.2011, 21:36:36
Der nächste Schritt wird sein, in einer Endlosschleife alle Benutzereingaben abzufragen und wenn der Benutzer den Buchstaben Q eingibt dann beendet sich das Programm.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Di 05.07.2011, 23:22:55
Ok, aufgrund der grossen nachfrage - hier ist ist step3.  ;D

#include <string.h>


#include <stdlib.h>

#include <stdio.h>


#include <tos.h>

#include <vdi.h>

#include <screen.h>




#define VERSION     "0.1 - (" __DATE__ ")"





/* Diese Variable vom typ short (16 Bit bei PureC)  */

/* ist neu im Programm!                             */

/* ------------------------------------------------ */

/* Da sie ausserhalb von einer Funktion deklariert  */

/* wird - ist sie berall in dieser Datei erreichbar*/

/* also in jeder Funktion. Variablen die innerhalb  */

/* einer funktion deklariert werden, sind nur so    */

/* lange "am leben" wie die funktion l„uft...,      */

/* solche Variablen nennt man dann "Lokale" Variabl.*/

/* Aber dies hier ist eine "Globale" Variable       */

/* Alle globalen Variablen werden mit 0             */

/* initialisiert - zumindest bei C                  */

/* Das heisst "short quit;" ist gleichbedeutend mit */

/* "short quit = 0;"                                */

/* Das gillt aber nur fr Globale Variablen!!!      */

/* Lokale Variablen enthalten Speicher Schrott -bis */

/* ihnen das erste mal ein Wert zugewiesen wird.    */

/* D.h. - Lokale Variable immer anfangs mit einem   */

/* Startwert versehen!                              */

/* Wir benutzen diese Variable um das Programm      */

/* von verschiedenen Stellen aus beenden zu koennen */

/* aber seht selbst... */

short quit;





/* ------------------------------------------------ */

/* mit dieser Funktion kann man einen text an einer */

/* bestimmten stelle am Bildschirm ausgeben.        */

/* Die ersten beiden Parameter bestimmen die        */

/* Postion (X = Spalte, Y=Zeile)                    */

/* der parameter inv bestimmt ob schwarz auf weiss  */

/* oder weiss auf schwarz ausgegeben werden soll    */

/* der letzte parameter beinhaltet eine             */

/* Speicheradresse an der die auszugebenden         */

/* buchstaben stehen                                */



void textxy(short x, short y, short inv, char * str)

{

    /* wenn parameter inv (invertiert) ungleich 0   */

    /* ist-dann wird der reverse mode eingeschaltet */

    /* d.h. weiss auf schwarze ausgabe              */

    if( inv != 0 ) {

        /* Makro das in screen.h definiert wurde:   */

        Rev_on();

    }

    /* Jetzt wird der cursor an die gewuenschte     */

    /* Stelle gesetzt, diese anweisung ist ebenfalls*/

    /* in screen.h definiert                        */

    Goto_pos( y, x );



    /* Diese funktion kennen wir schon:             */

    /* wir merken: Cconws gibt immer an der moment. */

    /* cursor-position den text aus.                */

    Cconws( str );



    /* wenn inv ungleich 0 ist, dann wird der       */

    /* modus wieder auf normal gesetzt.             */

    if( inv != 0  ) {

        Rev_off();

    }

}







/* Neue Funktion "input()"                          */

/* ------------------------------------------------ */

/* Diese Funktion liest ein Zeichen und reagiert    */

/* darauf...                                        */

void input( void )

{

    /* Zeichen in eine 32 Bit Variable einlesen:    */

    /* hierbei ist wichtig:                         */

    /* sobald GEM geladen wurde, hat diese Funktion */

    /* ein bisschen andere Rueckgabewerte           */

    /* fuer einige Tasten - z.B. Funktionstasten    */

    /* unter GEM bekommen wir immer einen ASCII     */

    /* Wert ...                                     */

    /* Will man also die Funktionstasten abfragen   */

    /* im autostart - dann muss das anders erfolgen */

    /* als unter GEM... aber dazu mehr in den       */

    /* naechsten folgen. Jetzt wird erstmal nur ein */

    /* Buchstabe eingelesen!                        */

    long key = Cnecin();



    /* momentan interessiert uns nur der Ascii wert */

    /* der Taste....                                */

    /* Es gibt auch Tasten bei denen der ASCII Wert */

    /* 0 ist.... da interessiert uns dann ein       */

    /* anderer Bereich der Zahl....                 */

    /* Hier wird jetzt das Ascii Byte des Tasten    */

    /* codes durch eine Bin„re Und verknpfung      */

    /* extrahiert... bzw. alles andere ausgeblendet */

    /* Der Ascii wert befined sich am ersten byte   */

    /* der 4 byte variable ( 4 byte = 32 bit):      */



    char ascii = (key & 0xFF);



    /* Darauf achten das die Buchstaben - anders    */

    /* als Zeichenketten - in einzelne anfhrungs-  */

    /* gesetzt sind!!!                              */

    /* der buchstabe wird daraufhin vom compiler    */

    /* in den "(Atari)-Ascii" Wert gewandelt.       */

    /* anstatt 'Q' koennte man auch die Zahl        */

    /* 81 nehmen - der Ascii wert fuer Q. Aber so   */

    /* ist es besser zu lesen!                      */

/* Hier wird jetzt abgefragt ob der Buchstabe */

/* das Kommando zum beenden enthaelt... */

    if( ascii == 'Q' || ascii == 'q' ){

        quit = 1;

    } else {

        /* hier wird der wert der variablen ausgegeben  */

        /* nur fuer informationszwecke                  */

        /* ich gehe nicht naeher darauf ein             */

        /* es ist nur fuer info zwecke gedacht          */

        /* wer mehr wissen will schaut in andere        */

        /* dokumente....                                */

        printf("ascii: %d - keycode: %lu\n", ascii, key );

    }



}



/* Hauptprogramm, wird aufgerufen nach start des Programms: */

int main(void)

{

    /* Anstatt Cconws rufen wir        */

    /* unsere eigene Textausgabe routine*/

    /* auf! */

    /* Spalte 2, Zeile 10, Invers, Text */



    textxy( 3, 1, 1,"SimpleBoot Version " VERSION );



    /* Hier haben wir ein neues Programm-konstrukt  */

    /* eine schleife! Diese wird solange wiederholt */

    /* bis die bedingung innerhalb der klammern     */

    /* nicht mehr zutrifft                          */

    /* konkret wird hier immer wieder ein Buchstabe */

    /* eingelesen - es sei denn die Variable quit   */

    /* enthaelt den Wert 1 - dann wird nicht weiter */

    /* gemacht...                                   */



    while( quit != 1 ) {

        input();

    }





    /* da die funktion main() den rueckgabetyp "int"*/

    /* (je nach compiler einstellung 16 oder        */

    /*  32 bit zahl) hat, muss ein entsprechender   */

    /* wert zurueckgegeben werden - 0 bedeutet: kein*/

    /* fehler.                                      */



    return( 0 );

}


[code]

[/code]
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: Arthur am Mi 06.07.2011, 02:36:26
Die ahcc.prj im STEP3.ZIP.PDF (http://forum.atari-home.de/index.php?action=dlattach;topic=8532.0;attach=2698) Anhang mag funktionieren aber für den AHCCST muß in der ahcc.prj statt der AHCCSTD.LIB die AHCCSTDI.LIB benutzt werden da erstere dort nicht vorhanden ist und sich der Linker sonst beschwert.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Mi 06.07.2011, 11:10:21
Ich teste vorher alle mit der AHCC020 Version.
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Mo 11.07.2011, 17:10:03
Ok, jetzt gibt es anstatt einer neuen version eine Haus-Aufgabe ;)

Schreibt das Programm so um - das bei Taste 'A' eine Meldung auf dem Bildschirm erscheint ... z.b.: "Taste A gedrueckt.".

Dafür rufe ich nochmal das if-else if-else konstrukt ins Gedächtnis:

Zitat
if( key == 'Q' ){
 // beenden
}
else if( key == 'A' ) {
 // ausgabe machen
}
else {
 // nix...
}


Titel: Re: Gemeinschaftsprojekt?
Beitrag von: ragnar76 am Mo 11.07.2011, 21:06:43
Ich habs so gemacht, läuft mit gcc und Pure C

#include <stdio.h>

int main(void)
{
  char key;

  printf("druecke Taste \"A\", \"a\" oder \"q\" um das Programm zu beenden\n");

  while((key = getchar()) !='q') {
    if (key  == 'A')
    {
      printf("A gedrueckt\n");
    }
    else if(key == 'a')
    {
      printf("a gedrueckt\n");
    }
  }
}

Ganz vergessen, von PHP und Bash kenne ich die Case Anweisungen. Wie stehts damit?
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: simonsunnyboy am Di 12.07.2011, 17:57:34
Die gibts auch in C:

switch(var)
{
case 'a':
/* tu was */
break;
case 'b':
/* tu was anderes */
break;
default:
/* wenn nix zutrifft tu das hier */
break;
}

Wichtig sind die break Anweisungen, sonst bearbeitet er auch immer den nachfolgenden case!
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Di 12.07.2011, 18:13:47
Das Problem hierbei ist nur das der return code von Cnecin() ein 32 Bit Wert ist - in PureC kann aber maximal ein 16 Bit Wert für eine Switch Anweisung verwendet werden. Das würde dazu führen das der Rückgabewert von Cnecin() zuerst in einen 16Bit Wert komprimitert werden muss...

Titel: Re: Gemeinschaftsprojekt?
Beitrag von: simonsunnyboy am Di 12.07.2011, 18:26:29
Ich denke das Problem hast du nur, wenn du volle 32 Bit abfragst.
Ansonsten bau halt einen Typencast ein

switch((uint16_t)my32bit)
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Di 12.07.2011, 18:29:26
Der Abzufragende Wert liegt aber in den oberen 16 Bit... Mir ist es egal - meinetwegen kann auch switch verwendet werden, ich wollte halt ohne solche Details auskommen, wegen Anfängern und so...
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: simonsunnyboy am Di 12.07.2011, 18:32:02
Anfänger sind bei C eh falsch.
Ansonsten shifte halt den Wert runter bevor du ihn auswertest.

(uint16_t)(mein32bitwert >> 16)
Titel: Re: Gemeinschaftsprojekt?
Beitrag von: m0n0 am Mi 13.07.2011, 21:25:46
Ich habe gerade Didiers neueste FireTOS version ausprobiert - das abfragen der Auflösung per lineA funktioniert jetzt.... :)