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
vectorgrafik simulieren....von 1983
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 .
Vielleicht willst du auch auf etwas ganz anderes hinaus (eigener Emulator, oder so) und ich habe dich einfach nur falsch verstanden .
- STiGMaTa_ch
- User
- Beiträge: 32
- Registriert: Sonntag 14. Mai 2006, 22:58
- Wohnort: Rueti ZH, Schweiz
Lies dir die Aufgabe nochmals durch
Lieber Gruss
STiGMaTa
Zu gut Deutsch... du sollst - wie EyDu schon richtig bemerkte - lediglich ein Programm schreiben das an deiner Stelle Asteroids spielt.[...]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.
Lieber Gruss
STiGMaTa
EDV-Systeme verarbeiten, womit sie gefüttert werden. Kommt Mist rein, kommt Mist raus. (André Kostolany)
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
@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.
Beim Gesamtsystem müsste man halt sehen, ob man den 6510-Prozessor schnell genug emuliert bekommt.
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
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
Zuletzt geändert von sma am Mittwoch 16. April 2008, 10:36, insgesamt 1-mal geändert.
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.
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:
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
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)
Stefan
Zuletzt geändert von sma am Mittwoch 16. April 2008, 12:39, insgesamt 1-mal geändert.
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.
Und da der 6502 "little endian" arbeitet, nehme ich mal an, dass die Entwickler damit beim Vektorprozessor nicht gebrochen haben.
Das Projekt hat unter Downloads noch nichts veröffentlicht. Aber im CVS Repository ist schon etwas.
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
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...
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...