vectorgrafik simulieren....von 1983

[sechsrad]

wäre so etwas realisierbar mit python.
diese sprache zu sprechen bzw zu simulieren.
die anforderungen warem damals gering 1,5mhz, 6 kb rom und 3 kb ram.

http://www.heise.de/ct/creativ/08/02/details/

wie kann man es anfangen?

elektronikstrahl beieinflussen ?
zeilenfrequenz von pal ausnutzen?
einen fernsehschirm simulieren bzw elektronikstrahl simulieren?

ab 1gigaherz-rechner?

mfg

[EyDu]

Ich habe es jetzt nur mal kurz überflogen und wenn ich es richtig verstehe, dann sollst du nicht die Anzeige basteln, sondern ein Programm welches sich über Netzwerk mit dem geliefertem Asteroids verbindet und dieses lediglich steuert. Da kann man mit den Modulen struct und socket rangehen.

Vielleicht willst du auch auf etwas ganz anderes hinaus (eigener Emulator, oder so) und ich habe dich einfach nur falsch verstanden .

[sechsrad]

es soll ein emulator werden.

mfg

[STiGMaTa_ch]

Lies dir die Aufgabe nochmals durch

[...]die Aufgabe dieses Wettbewerbs: ein Programm, das übers Netzwerk Asteroids spielt.[...]Wir werden [für] den Wettbewerb [...] den Emulator auf einer separaten Maschine laufen lassen, um Beeinflussungen durch die teilnehmenden Programme auszuschließen.[...] Es gewinnt das Programm mit der höchsten Punktzahl.

Zu gut Deutsch... du sollst - wie EyDu schon richtig bemerkte - lediglich ein Programm schreiben das an deiner Stelle Asteroids spielt.

Lieber Gruss
STiGMaTa

[Leonidas]

Laut dem (halben) c't-Artikel den ich gelesen habe, stellen die schon ein modifiziertes MAME zur Verfügung, welches sich via UDP fernsteuern lässt.

[sechsrad]

Lies dir die Aufgabe nochmals durch...

STiGMaTa_ch....
schau ein höher


ich will das nicht spielen. das sollen andere machen.

geht es , so einem emulator zu proggen mit python?

mfg

[Masaru]

Bestimmt ... aber wie genau, dass musst du schon selber rausfinden.

[BlackJack]

@sechsrad: Was für einen Emulator denn? Nur die Vektorgrafik-Einheit? Das sollte kein Problem sein.

Beim Gesamtsystem müsste man halt sehen, ob man den 6510-Prozessor schnell genug emuliert bekommt.

[sechsrad]

es müssten die befehle abgearbeitet werden können die die vectoren zeichnen. die cpu bräuchte nicht im programm abgebildet werden.

mfg

[sma]

Mir ist nicht so ganz klar, was sechsrad eigentlich will (habe auch nicht den c't-Artikel gelesen), aber wenn es z.B. um einen 6502-Emulator geht, das ist prinzipiell natürlich möglich. Ob der dann die Original-Performance erreicht... keine Ahnung. Ich würde tippen, das ein effizienter Emulator etwa 10 Prozessorbefehle pro emulierten Befehl braucht. Diese Metrik hatte ich irgendwo mal vor Jahren aufgeschnappt. Python selbst ist interpretiert, sodass ich mindestens eine Größenordnung draufschlagen würde. Damit müsste der emulierende Prozessor mindestens 100x schneller sein als der emulierte - Ein 1 MHz Prozessor auf einem 1 GHz Prozessor zu emulieren könnte also klappen.

Es gibt z.B. einen C64-Emulator in Flash. Allerdings halte ich ActionScript 3 für schneller als (interpretiertes) Python, da hier ein JIT benutzt wird. Hier ist nochmal ein 6502-Emulator in JavaScript. Es gibt noch ein Video von jemandem, der einen Z80-Emulator in ActionScript 2 geschrieben hat. Da würde ich eine ähnliche Performance wie bei Python annehmen. Z80-Emulatoren (der rannte üblicherweise mit 2 oder 4 MHz und ist komplizierter aufgebaut als ein 6502) in JavaScript gibt es ebenfalls im Netz. Tja, und dann gibt es noch ApplePy, einen Apple ][-Emulator in Python. Ob der funktioniert? Jedenfalls sieht man dort den einen direkten Ansatz, wie man einen Prozessor-Emulator bauen kann.

Stefan

[BlackJack]

Es geht sechsrad ja gar nicht um den 6502, sondern nur um den Vektor"prozessor", der ist wesentlich einfacher. Das ist nur eine kleine (Maschinen)Sprache um Vektorgrafik zu Zeichnen. Ganz simpel aufgebaut. Die Befehle bestehen aus 16 oder 32 Bit und die ersten vier Bit enthalten den Opcode. Die restlichen Daten sind Koordinaten, Skalierungsfaktor, Helligkeit, Sprungadresse etc.

[sma]

Ach, so. Habe mir jetzt Seite 178 von c't 9/2008 angeschaut. Ohne Gewähr oder das jemals ausprobiert zu haben, biete ich dies:

Code: Alles auswählen

def execute(rom, draw_to, move_to):
	pc = 0
	gsf = 0 # initial value is unspecified
	stack = []
	while True:
		w = rom[pc] + (rom[pc + 1] << 8); pc += 2 # LSB or MSB? It's unspecified
		op = (w >> 12) & 0xf
		if op < 10:
			n = rom[pc] + (rom[pc + 1] << 8); pc += 2 # LSB or MSB?
			x = n & 0x3ff
			y = w & 0x3ff
			z = (n >> 12) & 0xf
			sf = 9 - ((op + gsf) & 0xf)
			x >>= sf
			y >>= sf
			if n & 0x400: x = -x
			if w & 0x400: y = -y
			draw_to(x, y, z)
		elif op == 10:
			n = rom[pc] + (rom[pc + 1] << 8); pc += 2 # LSB or MSB?
			x = n & 0x3ff
			y = w & 0x3ff
			gsf = (n >> 12) & 0xf
			move_to(x, y)
		elif op == 11:
			break
		elif op == 12:
			stack.append(pc)
			pc = w & 0xfff # byte or word address? It's unspecified 
		elif op == 13:
			pc = stack.pop()
		elif op == 14:
			pc = w & 0xfff # byte or word address? It's unspecified
		elif op == 15:
			x = (w & 0x003) << 8
			y = (w & 0x300)
			z = (w & 0xf0) >> 4
			sf = 7 - ((((w & 0x8) >> 2) + ((w & 0x800) >> 11) + gsf) & 0xf)
			x >>= sf
			y >>= sf
			if w & 0x4: x = -x
			if w & 0x400: y = -y
			draw_to(x, y, z)

Ich bin der Meinung, dass die Beschreibung unterspezifiziert ist - siehe Kommentare. Die elif-Kaskade ist sicherlich nicht optimal, doch die Alternative wären Funktionsaufrufe über eine Liste und ich tippe darauf, dass das langsamer wäre. Ich rate, dass die meisten Befehle sowieso von dem ersten if abgehandelt werden. Man könnte die Varianten noch umsortieren, etwa $F, $A, $E, $C, $D, $B nach geratener Häufigkeit der Befehle. Falls es LSB ist, könnte man auch direkt die Bytes auswerten, ich glaube jedoch nicht, dass das bei Python einen Unterschied macht.

Stefan

[BlackJack]

Nur die Beschreibung im Kasten ist etwas wenig, aber es gibt ja auch noch das "Beispielprogramm", das nahelegt, dass Unterprogrammadressen in Bytes angegeben werden.

Und da der 6502 "little endian" arbeitet, nehme ich mal an, dass die Entwickler damit beim Vektorprozessor nicht gebrochen haben.

[sechsrad]

dann gibt es noch ApplePy, einen Apple ][-Emulator in Python.

hallo, ich komm nicht ran zum downloaden.

kannst du die adresse zum downloaden mal posten.

danke.

mfg

[BlackJack]

Das Projekt hat unter Downloads noch nichts veröffentlicht. Aber im CVS Repository ist schon etwas.

[jens]

Also bei dem Wettbewerb geht es ja darum, das ein Programm gegen das original über MAME (Multiple Arcade Machine Emulator) Programm spielt und möglichst viele Punkte sammeln soll...

Ich hätte da eine Idee...

Gestern sah ich eine Doku über einen Mumifizierten Dino. Dabei wurde auch gezeigt, wie man durch Simulation versucht den natürlichen Gang eines Dinos heraus zu finden. Das hatte irgendein Forscher schon an noch lebenden Arten gemacht. Also das Prinzip ist folgendes:
Man erstellt ein Modell des zu simulierenden Tiers. Legt fest so knochen, Gelenke und Muskel sich gefinden und wie weit sich Gelenke bewegen können.
Dann startet man eine Simulation. Soweit ich verstanden hab, wird per Zufall die Muskel/Knochen bewegt. Wenn das Gleichgewicht gehalten werden kann und einen Schritt nach vorne gelaufen wurde, ist es richtig. Wenn es umkippt oder nicht nach vorne kommt, ist es falsch.
Durch viele, viele Versuche/Fehlversuche kristallisiert sich mit der Zeit der natürliche Gang heraus.

Lange rede kurzer Sinn... Das Asteroids spiel könnte ebenfalls nach dem "trial and error" Prinzip funktionieren, oder?

EDIT: Es gibt schon zwei Python Skripte als Startpunkt: http://www.heise.de/ct/projekte/machmit ... rts#Python

EDIT2: So, hab mir das ganze kurz mal angesehen. Brauchbar ist IMHO die zweite Python Implementierung von von Thomas Pani.
Ich denke die Idee mit dem "trial and error" wird schon deswegen nicht gut funktionieren, weil das Spiel ja in Echtzeit läuft. Keine Ahnung ob man das auch ändern kann. So würden Simulationsschleifen aber super lange dauern...