Seite 2 von 5

Re: Nu bloß nicht GEARig werden...

Verfasst: Mo 5. Jun 2017, 06:31
von yeti
PIC18F2550 hat geschrieben::oops: Zu früh gefreut GEAR schmiert ca. 10s nach RUN ab.
:-(
Wie wär's, ein aktuelleres System auf USB-Stick oder externer Platte zu benutzen bis Zeit für ein Upgrade in Ruhe da ist?

Re: Nu bloß nicht GEARig werden...

Verfasst: Mo 5. Jun 2017, 08:58
von PIC18F2550
Denke ich auch. :SCHRAUBEN

Re: Nu bloß nicht GEARig werden...

Verfasst: Mo 5. Jun 2017, 09:10
von yeti
PIC18F2550 hat geschrieben:Denke ich auch. :SCHRAUBEN
Apropos schrauben...
Ich kratz bei GEAR noch völlig an der Oberfläche: Eben hab ich versucht in PASM zu multiplizieren aber irgendwie den Code nicht in GEAR wiedergefunden...
:SCHREIEN

Später nochmal mit mehr Koffein im Blut weiter üben...
:TIPPEN

Re: Nu bloß nicht GEARig werden...

Verfasst: Mo 5. Jun 2017, 11:04
von yeti
PIC18F2550 hat geschrieben: :oops: Zu früh gefreut GEAR schmiert ca. 10s nach RUN ab.
Hmmm... eben wieder... ich krieg GEAR nicht sauber durch zuklixxen terminiert... die Menüs klemmen aber das Fenster läßt sich bewegen... es klemmt alsi definitiv nur GEAR und nicht das ganze GUI...

Derweil im StdIO-Kino:

Code: Alles auswählen

(yeti@kumari:12)~/wrk/propeller/spinsim/tmp-spin$ ../../gear/gear-20140703/Gear.exe 
*** Error in `/usr/bin/cli': free(): invalid pointer: 0x0000000002460fd8 ***
Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) System.Drawing.GDIPlus.GdipDeleteGraphics (intptr) <0xffffffff>
  at System.Drawing.Graphics.Dispose () <0x00067>
  at (wrapper remoting-invoke-with-check) System.Drawing.Graphics.Dispose () <0xffffffff>
  at System.Drawing.Graphics.Finalize () <0x0001b>
  at (wrapper runtime-invoke) object.runtime_invoke_virtual_void__this__ (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:

        /usr/bin/cli() [0x4b5ca0]
        /lib/x86_64-linux-gnu/libpthread.so.0(+0xf890) [0x7f15ee660890]
        /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37) [0x7f15ee2db067]
        /lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7f15ee2dc448]
        /lib/x86_64-linux-gnu/libc.so.6(+0x731b4) [0x7f15ee3191b4]
        /lib/x86_64-linux-gnu/libc.so.6(+0x7898e) [0x7f15ee31e98e]
        /lib/x86_64-linux-gnu/libc.so.6(+0x79696) [0x7f15ee31f696]
        /usr/lib/x86_64-linux-gnu/libcairo.so.2(cairo_surface_destroy+0x5e) [0x7f15ea9070fe]
        /usr/lib/x86_64-linux-gnu/libcairo.so.2(+0x2d050) [0x7f15ea8c6050]
        /usr/lib/x86_64-linux-gnu/libcairo.so.2(+0x29aad) [0x7f15ea8c2aad]
        /usr/lib/x86_64-linux-gnu/libcairo.so.2(+0x29b29) [0x7f15ea8c2b29]
        /usr/lib/libgdiplus.so.0(GdipDeleteGraphics+0x85) [0x7f15eaed48f5]
        [0x417d15fb]

Debug info from gdb:
...bloß nicht darüber nachdenken... das kappier ich eh nicht!
:shock:

Re: Nu bloß nicht GEARig werden...

Verfasst: Mo 5. Jun 2017, 11:25
von yeti
yeti hat geschrieben:Eben hab ich versucht in PASM zu multiplizieren aber irgendwie den Code nicht in GEAR wiedergefunden...
:SCHREIEN
Ah jetzt ja... ich hatte beim Start des Cogs wohl das "@" bei der Adresse vergessen... dadurch wurd der phöllig phallsche Schrott in den Cog geladen und sah natürlich auch nicht aus wie das, was ich dort erwartete.

Ich brauch definitiv noch viel mehr Warming-Up mit PASM... oder mehr Koffein!

...und nebenbei kam ich mit Inline-ASM bei FastSpin ooch nicht weit... das scheint noch nicht alle PASM-Details zu beherrschen und benörgelt auch anderer Leute Code, der ok sein sollte... es liegt also dort nicht (nur) an mir beim Rumstoplern mit (LMM-Inline-)PASM+FastSpin... ich bleib besser erstmal bei OpenSpin...

Re: Nu bloß nicht GEARig werden...

Verfasst: Mo 12. Jun 2017, 20:08
von yeti
PIC18F2550 hat geschrieben: :oops: Zu früh gefreut GEAR schmiert ca. 10s nach RUN ab.
Mir schmiert bei fehlerhaftem Code GEAR immer mal wieder ab und bei korrektem Zeuchs rennt's Stunden stabil...

Zur Zeit schaffe ich es immer wieder, GEAR abschießende VGA-Routinen zu verzapfen... aber ok.. so merk ich, daß da noch was nicht stimmt... ;-)

Re: Nu bloß nicht GEARig werden...

Verfasst: Di 13. Jun 2017, 08:22
von PIC18F2550
Ich verwende gerade keine XML Erweiterungen.

Es sind vollkommen einfacher PASM Code.

Ich Tippe da eher auf den WAITCNT der den Absturz verursacht.
Das lässt sich aber nicht sicher nachweisen.
Mal absturz ein anderes mal absturz später :SCHREIEN

Re: Nu bloß nicht GEARig werden...

Verfasst: Di 13. Jun 2017, 10:51
von yeti
PIC18F2550 hat geschrieben:Ich Tippe da eher auf den WAITCNT der den Absturz verursacht.
Das lässt sich aber nicht sicher nachweisen.
Mal absturz ein anderes mal absturz später :SCHREIEN
GEAR kann ja Läuse und Flöhe gleichzeitig haben:
Wir triggern vielleicht unterschiedliche Bugs.

Re: Nu bloß nicht GEARig werden...

Verfasst: Di 13. Jun 2017, 14:48
von PIC18F2550
Da habe wir ja richtig Glück das sich die Zecke mein Bein ausgesucht hat.

Kleine Fortschittlichkeiten...

Verfasst: Di 6. Nov 2018, 17:14
von yeti
Ich hab mal lange genug den Code des Interpreters der VGA-Pins angestarrt und die Stelle entdeckt, wo man die Pixel in horizontaler Richtung verdoppeln muß, damit das Bild wieder hübsch ausschaut:
gear-vgamonitor-double-x.xml
(2.72 KiB) 558-mal heruntergeladen
Das wurd brisant, weil ich anfange mit Graphik in FastSpin(-BASIC) zu spielen und noch immer nicht den Hintern hoch bekam, ein Board auszugraben, das mal an einen VGA-Monitor anstöpseln kann. Ok, aber so mehrt sich der Lerneffekt mit GEAR. ;-)

Die erste Demo malt einen Bildschirmschnappschuß eines monochromen Klassikers:
20181106-110220-GMT--FastSpin-BASIC--Surprise.png
Das geht noch zügig, denn das Bild ist als Konstante im BASIC-Quelltext eingebettet:
surprise.zip
(6.19 KiB) 552-mal heruntergeladen
Eine echte Geduldsprobe ist das Warten auf die Fertigstellung des 16-Bit-Fixpunkt-Mandelbrötchens. Ich hab's wieder nicht geschafft! Dieser Schnappschuß zeigt nach 5 Stunden Laufzeit noch immer weniger als ein halb berechnetes Apfelbrötchen:
20181106-160207--FastSpin-BASIC--mandelbrot-fixed16-vga-512x384x1.png
Der Quelltext enthält keine Überraschungen:
mandelbrot-fixed16-vga-512x384x1.zip
(2.3 KiB) 563-mal heruntergeladen
Sicher wär das Malen mit einem Echtpropeller mit PAL- oder NTSC-Farbe auf Bitleinwand und das Einfangen des Bildes mit dem rumliegenden Bildgrabscher doch weniger meditativ... :-)

EiiiGÄHNtlich wollte ich auch noch ein 320x240x2 (also 4-farbiges) Apfelbrötchen in GEAR malen lassen und die GEARsche Simulation eines AnalogTVs testen, aber das fällt nun erstmal wegen einer Überdosis an erlittener Ungeduld aus. :-(