RaspARI - ein ATARI im Scheckkartenformat (Emulator für Raspberry PI)

[Gaga]

Ich will den Enthusiasmus ja nicht schmälern, aber das Gesamtergebnis wird doch durch die beiden herausstechenden Werte Integer Division und RAM Access geschönt.

Dennoch ne tolle Sache!

[dbsys]

Flüssig? Im Schnitt ist der 4x so schnell wie ein Falcon, doppelt so schnell wie ein TT. Allerdings scheint er deren Grafikauflösungen nicht zu unterstützen, was aber grundsätzlich machbar sein sollte,

Die nächste Version wird einen falcon-videl-shifter haben. Außerdem eine FPU.

ardi

Toll.

Ich bin angenehm überrascht, wie schnell es hier Fortschritte gibt.

[ardi]

Hi

es gibt eine neu Version.

Jetzt mit falcon-videl-shifter und einem gepimpten VDI

Download wieder hier.

[1ST1]

Huiiii, und jetzt bitte noch höhere Aulösungen, z.B. über die Emulation eines Screenblasters, oder SuperVidel! Wenn das so weiter geht, brauche ich bald eine Himbeere!

Noch ein Wunsch: Ein IKBD-Interface auf freien IO-Pins, so dass man eine originale ST-Tastatur/Maus anschließen kann!

[Arthur]

Alter Schwede, das ist ja ein Tempo bei Dir und dem RaspARI. Eine original Tastatur/Maus würde ich nicht vermissen... solche Kleinigkeiten passen nicht zum Konzept.
Einzig wenn man den RaspARI in ein original Atari ST/STE/Falcon Gehäuse packen möchte dann könnte man jemanden damit verblüffen.

[Gaga]

Doch, die Idee der Möglichkeit eines direkten Anschlusses einer Atari Tastatur mit Maus- und Joystickunterstützung wäre eine wunderbare Sache.

Da es zum Thema passt: bei www.pollin.de ist der Raspberry Pi, Modell B, gerade für nur 29,95 Euro im Angebot.

[1ST1]

Einzig wenn man den RaspARI in ein original Atari ST/STE/Falcon Gehäuse packen möchte dann könnte man jemanden damit verblüffen.

Genau das ist mein Gedanke dahinter! Ich habe noch einen irreparablen 520ST.

[ardi]

Noch ein Wunsch: Ein IKBD-Interface auf freien IO-Pins, so dass man eine originale ST-Tastatur/Maus anschließen kann!

Warum freie IO-Pins. Der RPI hat ja eine Serielle-Schnittstelle. Allerdings wird die für Kernel-Meldungen verwendet.
Aber das läßt sich abschalten. Auch die Möglichkeit sich per serieller Verbindung einzuloggen kann abgeschaltet werden.
Dann ist der serielle Port frei (P1-08 TxD und P1-10 RxD) ABER ob sich der UART auf 7815,5 Bits/s einstellen läßt, habe ich keine Ahnung.

ardi

[1ST1]

Lieber welche von den freien IO-Pins nehmen, den seriellen Port kann man sicher nett als Hintertür zum Debugging oder so brauchen.

[ardi]

Lieber welche von den freien IO-Pins nehmen, den seriellen Port kann man sicher nett als Hintertür zum Debugging oder so brauchen.

Eine serielle Schnittstelle an x-beliebige Ports in Software ist nicht ohne.
Da man sowieso eine Pegelanpassung 3.3V auf 5V braucht, kann man auch gleich einen AVR o.ä. zwischenschalten, der eine Protokoll-/Interfacewandlung auf ein weniger Zeit-kritisches Protokoll macht z.b. seriell auf spi oder ein PS/2 ähnliches Protokoll.
Irgend was bei dem der RPI den Tackt angibt und dieser auch nicht genau zu sein braucht.

ardi

[1ST1]

Kannst du dir bitte mal Gedanken machen, ob/wie du das umsetzen kannst? Das wäre große Klasse! Ein 520ST mit der vielfachen Performance eines Falcon, das wäre nämlich traumhaft!

[ST-Oldie]

Hi,

mich würde immer noch interessieren, ob und wie eine Unterstützung anderer ARM basierender Boards möglich ist. Die Himbeere ist ja nicht das einzige ARM Board.

Tschüß
Michael

[Börr]

Nice, ich habe gerade keinen pi zur Hand, werde aber gleich mal testen. Wie sieht es mit LAN aus? Ist dein emu open source?

[mfro]

Hallo Ardi,

ich finde deine Initiative prima - auch bei mir liegt ein Pi rum und wartet auf eine vernünftige Beschäftigung.

Allerdings solltest Du auch die Rechte der Programmierer respektieren, deren Produkte Du verwendest.

Dein Tun wird gerade auf der EmuTOS Mailingliste einigermaßen kritisch beäugt.

EmuTOS ist OpenSource, lizensiert nach der GPL. Das heißt, wenn Du die Sourcen benutzt und veränderst, daß Du die Veränderungen wieder in Quellcode-Form zur Verfügung stellen ("zurückgeben") mußt.
So wie es aktuell aussieht (oder habe ich mich da verguckt?) verwendest Du ein modifiziertes EmuTOS, daß es aber aktuell nur als Binary gibt. Genau genommen ein Verstoß gegen die Lizenzbedingungen.

Nun will keiner Stress anfangen - ist ja schließlich sehr löblich (und auch für die EmuTOS-Programmierer sehr erfreulich), daß da was passiert.

Du könntest die Diskussionen leicht beenden, indem Du entweder den gesamten Emulator als OpenSource nach der GPL freigibst oder - wenn Du das nicht willst - indem Du EmuTOS herauslöst und die Veränderungen separat öffentlich zugänglich machst.

Danke (1. für den Emulator und 2. für die Wahrung der Rechte der EmuTOS-Crew).

Gruß,
Markus

[1ST1]

Ich würde in dem Fall den veränderten EmuTOS-Quellcode erst abliefern, wenn alle Änderungen, die ich vorgenommen habe, auch funktionieren und vollständig sind. An halbfertigem Code herum zu diskutieren bringt nämlich auch nix.

[yalsi]

Hallo

Auch von mir an dieser Stelle die Bitte, die Lizenzbedingungen der GNU GPL einzuhalten. Ansonsten wäre Deine Arbeit schnell "für die Katz", und das wäre schade, das Ding läuft ja gut. Und halte Dich an den Grundsatz: Publish early, publish often- auch wenn Du noch viele Baustellen im Code hast, veröffentliche ihn. Musst Du übrigens auch, weil Du ja das abgeleitete Werk schon veröffentlicht hast... .Am besten wäre natürlich eine GPL Lizenz für das ganze Projekt. Wenn Du  da Fragen hast, helfe ich Dir gern... .

Gruss- Georg B. aus H.

[MJaap]

Auch von mir an dieser Stelle die Bitte, die Lizenzbedingungen der GNU GPL einzuhalten. Ansonsten wäre Deine Arbeit schnell "für die Katz", und das wäre schade, das Ding läuft ja gut. Und halte Dich an den Grundsatz: Publish early, publish often- auch wenn Du noch viele Baustellen im Code hast, veröffentliche ihn. Musst Du übrigens auch, weil Du ja das abgeleitete Werk schon veröffentlicht hast... .Am besten wäre natürlich eine GPL Lizenz für das ganze Projekt. Wenn Du  da Fragen hast, helfe ich Dir gern... .

Dazu hat er sich schon längst auf atari-forum.com geäußert:

RaspARI use a normal EmuTOS only configured with localconf.h
The only changes i have made, i have hooked some VDI-functions to run a native-arm-function to do the same think (but faster) as the hooked m68k-funktion.
RaspARI has currently only a build-in EmuTOS because the Emulator is not perfect and runs only with a small amount of hardware aktivatet in EmuTOS.
A normal full-featured EmuTOS will currently not run.
The emulated m68k cpu currenty don't support Bus- or Adress-Error-Exceptions, important for Hardwaredetection.

"Publish early, publish often": Von einem Code voller Baustellen hat niemand etwas und die Hauptarbeit findet offenbar nicht im EmuTOS statt. Ist ja auch nur ein Betriebssystem und kein Emulator.

[guest867]

Die Idee ist genial!

Ich habe zu Hause auch einen RasPI rumliegen der auf eine sinnvolle Beschäftigung wartet.

Wenn RaspARI irgendwann direkt von SD bootet ist es natürlich noch besser, den Raspi kann man ja überall einbauen, auch in alte Atari-Hardware.

Ich hoffe das das Projekt weiter geht!

Martin

[nobox]

Lieber welche von den freien IO-Pins nehmen, den seriellen Port kann man sicher nett als Hintertür zum Debugging oder so brauchen.

Eine serielle Schnittstelle an x-beliebige Ports in Software ist nicht ohne.
Da man sowieso eine Pegelanpassung 3.3V auf 5V braucht, kann man auch gleich einen AVR o.ä. zwischenschalten, der eine Protokoll-/Interfacewandlung auf ein weniger Zeit-kritisches Protokoll macht z.b. seriell auf spi oder ein PS/2 ähnliches Protokoll.
Irgend was bei dem der RPI den Tackt angibt und dieser auch nicht genau zu sein braucht.

ardi

Am einfachsten ist die Verwendung eines Arduino Leonardo, weil der schon USB-Keyboard-Emulation onboard hat. Und auch TTL Level. Und die 7812.5 baud kann.

Siehe auch: http://www.kevinpeat.com/atari_pi_keyboard_coding.html

[Börr]

Lieber welche von den freien IO-Pins nehmen, den seriellen Port kann man sicher nett als Hintertür zum Debugging oder so brauchen.

Eine serielle Schnittstelle an x-beliebige Ports in Software ist nicht ohne.
Da man sowieso eine Pegelanpassung 3.3V auf 5V braucht, kann man auch gleich einen AVR o.ä. zwischenschalten, der eine Protokoll-/Interfacewandlung auf ein weniger Zeit-kritisches Protokoll macht z.b. seriell auf spi oder ein PS/2 ähnliches Protokoll.
Irgend was bei dem der RPI den Tackt angibt und dieser auch nicht genau zu sein braucht.

ardi

Am einfachsten ist die Verwendung eines Arduino Leonardo, weil der schon USB-Keyboard-Emulation onboard hat. Und auch TTL Level. Und die 7812.5 baud kann.

Siehe auch: http://www.kevinpeat.com/atari_pi_keyboard_coding.html

Geil, gleich mal einen Bestellt, evtl geht das auch umgedreht