Gemeinschaftsprojekt?

[m0n0]

...anmerkung:

Man kann auch die PCEXTlib ( bei purec dabei, also gehe ich davon aus das AHCC es auch hat....  ) für die EInlesefunktion nutzen - diese bietet die von tuxie besagt einlese methode...

[m0n0]

so, gemeinschaftsprojekt hin oder her, ich habe auch schon mal was gemacht, zunächst mal eine Projekt Datei für PureC:

Code: [Auswählen]

;************************************************************
;
;                       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

Code: [Auswählen]

/* 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

[tuxie]

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.

[tuxie]

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

[m0n0]

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. 

[Arthur]

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?

[m0n0]

das ist eigentlich egal... Man kann ja in den optionen einstellen fuer welches system kompiliert werden soll.

[simonsunnyboy]

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!

[m0n0]

Das ROM VDI steht sehr wohl zur verfügung. Bezüglich des AES gebe ich dir recht, aber das nutzt ja auch keiner.

[m0n0]

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

[m0n0]

mein momentaner stand benutzt VDI zum zeichnen eines Logos ( Monochrom bitmap ) mittels der VDI rasterfunktionen und das funktioniert tadellos.

[m0n0]

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

[Arthur]

(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?

[m0n0]

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.

[Arthur]

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?

[m0n0]

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.

[m0n0]

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.

Code: [Auswählen]

/* 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

[m0n0]

Wie - hat schon keiner mehr lust weiter zu machen? Kein wunder das C Anfänger dingsbums das hier stattfand gestorben ist

[afalc060]

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.

[m0n0]

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.