Spaß: Ideen für eine Homecomputer-Serie

[aths]

Obwohl dieser Thread überwiegend Unterhaltungswert haben dürfte, poste ich ihn wegen der starken Technologie-Ausrichtung in dieses Forum.

Die letzten Tage habe ich mal spaßeshalber überlegt, wie man einen frühen Homecomputer hätte designen können, der jedoch ausbaufähig genug ist, um auch einem C64 Paroli zu bieten. Die meisten Homecomputer hatten imo den Nachteil, dass sie zu sehr als Einzelsystem für einen bestimmten Zweck designt wurden. Natürlich habe ich in diesem Posting gut reden, da man sich ja im Nachhinein von mehr oder weniger erfolgreichen Homecomputer inspiereren lassen kann.


Erste Generation

Meine Idee sähe so aus: Das Modell bekommt als CPU einen MOS 6502 oder einen Z80 (ist letztlich wurscht) der ja 64 kiB Adressraum hat. Das Speicher-Layout sähe so aus:

0000 - 1FFF = ROM (8 KiB)
2000 - 2FFF = RAM (4 kiB)
3000 - 3FFF = ungenutzt (vorgesehen für 4-kiB-RAM-Erweiterung)
4000 - 7FFF = ungenutzt (vorgesehen für Highres-Grafik-Erweiterung)
8000 - FFFF = vorgesehen für den Modul-Schacht.

Das hieße, man hätte 8 kiB ROM und 4 kiB RAM (der ZX80 hatte 1 kiB RAM.)

Im ROM wäre der Zeichensatz (128 Zeichen, die anderen 128 sind invertierte Versionen der ersten 128). Außerdem wären im ROM Routinen zur FP-Rechnung (sagen wir FP48 – vergleichbar mit dem "real"-Typ von Turbo Pascal) mit allen Grundrechenarten, und es gäbe die Möglichkeit, den Computer als besseren Taschenrechner zu nutzen.

Das BASIC würde als Modul ausgeliefert. Dies böte die Möglichkeit, ein recht einfaches BASIC (8 oder 16 kiB) dazuzulegen und ein preiswertes Paket zu schnüren, was sich z. B. an Schüler mit betuchten Eltern richtet. Alternativ könnte man ein Luxus-BASIC dazulegen, was 32 KiB ROM auch ausnutzt.

Spiele und Anwendungssoftware kommen auf Modulen und nicht auf Datasette, was Hauptspeicher spart. Natürlich wird ein Kassettenrekorder zur Aufzeichnung eigener Programme unterstützt.

Mit 4096 Byte Hauptspeicher kann man nicht allzu viel machen, zumal neben einigen Systemvariablen, Interruptvektoren und dem Stack auch der Textbildschirm-Speicher reinmuss, aber immerhin ließe sich schon programmieren. Die Erweiterung auf 8192 Byte böte dann richtig Platz.


Grafik

Der "Grafikchip" (soweit man das nennen kann) hat Register für 16 Farben, sowie ein Register für die Cursor-Position (der Cursor soll ja blinken.) Im Textmodus kann man global einstellen, dass die Hintergrundfarbe mit nur halber Helligkeit dargestellt wird.

Beim Textmodus würde ich einen monochromen Modus vorsehen, der jedoch pro Zeile eine eigene Vorder- und Hintergrundfarbe erlaubt. Hierzu bräuchte man ungefähr 1 kiB Speicher. Dazu einen farbigen Textmodus mit pro Zeichen wählbarer Vorder- und Hintergrund-Farbe (was dann doppelt so viel Speicher kostet.)

"Grafik" würde entweder über semirgrafische Zeichen aus dem Zeichensatz realisiert, wobei die Pixel natürlich sehr grob wären (à la Z80). Alternativ kann man den Chip so einstellen, dass er keine Textzeichen, sondern Pixel ausgibt (1 Bit, 4 Bit, 8 Bit pro Pixel.) Der Speicher hält dann aber nur 2 oder 4 Zeilen vor. Man muss also während der Bildausgabe jeweils die neuen Pixel schreiben. Immerhin wäre das eine Möglichkeit, bei Spielen tolle Intro-Standbilder anzuzeigen (der Computer hat in der Zeit ja weiter nichts zu tun.)

Da die Palette nur 16 Einträge hat, würden beim 8-Bit-Modus die anderen 4 Bit als Helligkeitswert interpretiert, so dass man 16 Farben in 16 Helligkeiten nutzen kann (eine vergleichbare Idee, jedoch mit nur einem Helligkeitsbit, gabs auf dem Amiga.)

Für Input-Geräte gibt es nur zwei physikalische Anschlüsse. Per Y-Kabel oder Verteiler lassen sich zusätzliche Geräte anschließen. Dabei sind insgesamt bis zu 8 Geräte möglich, die jeweils in schneller Folge der Reihe nach drankommen. Pro Gerät sind 2 Achsen (jeweils 1 Byte) und 8 Knöpfe (noch ein Byte) vorgesehen. Komplexere Controller wirken also für die Hardware wie mehrere Geräte. Die AD-Wandler (bei analogen Joysticks) müssen jedoch im angeschlossenen Gerät selbst sein.


Zweite Generation

Es wird Zeit, den Computer zu erweitern. Das zunächst für den professionellen Gebrauch entworfene und im dortigen Segment schon verkaufte Highres-Modul wird nun auch für den Privatanwender erschwinglich gemacht. Das Highres-Modul kommt auf einen vorgesehen Steckplatz im Computer. Es bringt in jedem Fall 16 kiB eigenen Speicher mit, sowie einen eigenen Grafik-Chip, welcher jetzt für die Heimanwender um Sprite-Support erweitert wurde. Es gibt auch Modelle mit extra Monitor-Anschluss.

Der Grafikchip bietet single bufferd Modi die bis zu 16 kiB RAM verbrauchen und double buffered Modi, die jeweils bis zu 8 kiB RAM verbrauchen. Dabei gibt es nicht nur einen Grafikmodus. Der Chip kann alle Kombinationen aus 1, 2, 4 und 8 Bit pro Pixel und X- und Y-Auflösung unabhängig voneinander in Verdopplung / Vervierfachung / Halbierung / Viertelung anzeigen, die noch zu einer gültigen Framebuffer-Größe führen.

Spätere Modelle des Computers werden mit integrierter Highres-Grafik und integierter RAM-Erweiterung verkauft (da die Integration Kosten spart.)


Dritte Generation

Zeit für ein ordentliches Upgrade: Die CPU wird nun doppelt so hoch getaktet, kann aber auf den alten Takt heruntergeschaltet werden um 100%-ige Kompatibilität zu bieten. In den ROM-Modulschacht kann nun auch eine RAM-Erweiterung gesteckt werden. So hat man dann 40 kiB RAM. Die Software kommt jetzt von Diskette.

Außerdem gibt es später RAM-Erweiterungen (weiterhin für den Modulschacht) mit 64 kiB, später eine RAM-Expansion mit 128 kiB RAM. In dem Modul steckt neben dem RAM noch ein zusätzlicher Controller, über den die Software das Bankswitching realisiert.

Auf Diskette (oder via Modul, welches Expansions-RAM zusätzlich einen ROM hat) wird dann auch eine grafische Oberfläche mit kooperativem Multitasking angeboten.

Um dem Amiga 500 wirklich Konkurrenz zu machen, hätte es dann natürlich doch einers völlig neu entwickelten Computers bedurft.

[Avalox]

So was wie DMA gibt es wohl dann nicht. Schnittstellen scheinen auch kein Thema zu sein. Wie wird denn die Tastatur abgefragt(gibt es die überhaupt?), macht das die CPU selbst? Wie werden denn externe Interrupts gesteuert? Zur Zeit gibt der Computer auch keinen Mucks von sich.

Multitasking mit absoluten Adressen macht sicherlich auch wenig Spass. Eine MMU hatten obere CPUs noch nicht.

[BAGZZlash]

Ist ein ganz gutes Design, allerdings, und das ist ja klar, kann das System dem C64 erst in der dritten Generation wirklich das Wasser reichen.

Der verwendete 6502 sollte sofort extrem hoch getaktet sein, schon in der ersten Version sollten mindestens 4 MHz verwendet werden. Temperaturtechnisch sollte das kein Problem sein, nur die dann magere Ausbeute würde wohl den Preis hochtreiben. Ob das also wirklich realistisch wäre, weiß ich nicht. Ein solcher Prozessor sollte auch mehr Speicher bekommen. Klar, das Zeug war damals teuer, aber was soll's. 8 Bit Farbtiefe ist toll, aber es ist zu wenig Speicher vorhanden. Selbst in der zweiten Generation ist mit 16 kiB Framebuffer ja gerade mal genug Speicher für 140 x 112 in monochrom. Davon ab: Theoretisch hätte auch auf dem C64 nix gegen 8 Bit gesprochen, oder? Gut, das gab's nicht, aber die Auflösung wäre dann auch zu gering gewesen.

Spiele nur auf Modulen ist nicht praktikabel. Zu teuer in der Herstellung und nicht zu vergessen den Raubkopierfaktor: Software muß verbreitet werden, damit das System sich verbreitet, im Markt etabliert. Das ist es, was den C64 und auch den PC groß gemacht hat: Billige und "kostenlose" Software.

Controller: Die schnelle Folge, mit der diese "drankommen" sollen, könnte ein Problem sein. Das müsste schon seeehr schnell sein, um präzises Steuern zu ermöglichen, bin nicht sicher, ob so ein System das packt. A/D-Wandler im Joystick würden sowas sehr teuer machen (für Verhältnisse Ende der 70er/Anfang der 80er.) Aber egal, vielleicht auch nur was für Betuchte, der C64 kam ja auch mit Digitaljoysticks aus, bzw. als die erste Analogmaus kam, war der C64 praktisch tot, das wäre hier wohl genauso, auch mit den Analogjoysticks.

Insgesamt scheitern wohl alle meine Änderungsvorschläge am Geld: Die CPU auf kokurrenzfähigen Takt zu bringen (im Vergleich zum 6510 des C64) wäre wohl in der Herstellung zu teuer (oder auch Ende der 70er noch gar nicht machbar) und der dringend erforderliche Speicher auch.

Das Ding wäre unterm Strich wohl doch ein VC20, die dritte Generation dann ein C64. Genau überlegt: Wo wäre der Unterschied? :confused:

Noch was: Für Software (Spiele) auf Modulen sollte man vielleicht von Anfang an eine Möglichkeit vorsehen, Samples an den Soundchip zu senden (Streaming). Der Speicher wäre natürlich für Samples viel zu klein, aber an ihm vorbei wäre das schon 'ne Möglichkeit, dem SID des C64 ein Schnippchen zu schlagen.

[aths]

So was wie DMA gibt es wohl dann nicht. Schnittstellen scheinen auch kein Thema zu sein. Wie wird denn die Tastatur abgefragt(gibt es die überhaupt?), macht das die CPU selbst? Wie werden denn externe Interrupts gesteuert? Zur Zeit gibt der Computer auch keinen Mucks von sich.Ach ja, den Sound habe ich vergessen. Da schwebt mir n recht einfacher FM-Synteziser vor, der drei Kanäle hat, bei denen man unabhängig die Lautstärke jeweils für linken und rechten Kanal regeln kann.

An Schnittstellen nur das Übliche (TV via Antenne, später vielleicht SCART, sowie eine generelle Schnittstelle für die später n Drucker angeboten wird.) Die Tastatur ist eingebaut und wird am Ende jeder Bildschirmzeile von der CPU abgefragt, mit maximal 1 Byte Tastatur-Buffer.

Interrupts werden vom Interrupt-Controller gesteuert :) Im Detail hab ich das nicht ausgearbeitet. Selbst eine Ultraprimitiv-Konsole à la Atari 2600 erweist sich im Detail als komplexer, als man zunächst denkt.

Multitasking mit absoluten Adressen macht sicherlich auch wenig Spass. Eine MMU hatten obere CPUs noch nicht.Na für Tasksswitching müssen ja "nur" Register und Rücksprungadressen gespeichert werden. Die Sprünge innerhalb eines Programms müssten natürlich relative Adressen nutzen, da weiß ich jetzt nicht, ob das mit den damaligen CPUs möglich war.

[aths]

Ist ein ganz gutes Design, allerdings, und das ist ja klar, kann das System dem C64 erst in der dritten Generation wirklich das Wasser reichen.Wenn du mit einem voll ausgebauten C64 vergleichst. Am Anfang der C64-Zeit gab es ja noch nicht so viel Zubehör.

Der verwendete 6502 sollte sofort extrem hoch getaktet sein, schon in der ersten Version sollten mindestens 4 MHz verwendet werden. Temperaturtechnisch sollte das kein Problem sein, nur die dann magere Ausbeute würde wohl den Preis hochtreiben. Ob das also wirklich realistisch wäre, weiß ich nicht.Glaub ich eher nicht. Ich dachte da so an ca. 1 MHz, maximal 1,5 MHz. Der Computer, der anfangs natürlich hunderte Dollar gekostet hätte, sollte in absehbarer Zeit erschwinglich werden. Einsetzbar sein sollte er wissenschaftlich (für Berechnungen) wie zur Unterhaltung (für Spiele)

Ein solcher Prozessor sollte auch mehr Speicher bekommen. Klar, das Zeug war damals teuer, aber was soll's.Nee, ein so teuerer Computer wäre nicht in den Volumenverkauf gegangen. 1 KiB halte ich für zu wenig. Auf dem ZX80 z. B. kann man trotz Bildschirm-Textmodus-Sparspeicherung kaum was in BASIC programmieren. Mit 4 KiB wäre imo schon einiges machbar. Wer noch mehr möchte, greift zur Speichererweiterung.

8 Bit Farbtiefe ist toll, aber es ist zu wenig Speicher vorhanden. Selbst in der zweiten Generation ist mit 16 kiB Framebuffer ja gerade mal genug Speicher für 140 x 112 in monochrom.Im Single-Buffer-Modus wäre z. B. 144x112 im 8-Bit-Modus möglich gewesen. Für Standbild-Grafiken durchaus brauchbar.

Davon ab: Theoretisch hätte auch auf dem C64 nix gegen 8 Bit gesprochen, oder? Gut, das gab's nicht, aber die Auflösung wäre dann auch zu gering gewesen.Der C64 war, wie auch der ZX Spectrum, nicht "vollgrafikfähig". Man konnte im Farbmodus die Pixel nicht beliebig einfärben, weil der Speicher zu knapp war. Ich bin Fan von "Vollgrafik", auch wenn man dafür mit geringer Auflösung oder wenigen Farben leben muss. Das Highres-Modul hätte imo für damalige Verhältnisse brauchbare Grafik ermöglicht. Einfache Strategiespiele oder bestimmte Anwendungs-Software wären auch mit Single Buffering im Framebuffer ausgekommen.

Spiele nur auf Modulen ist nicht praktikabel. Zu teuer in der Herstellung und nicht zu vergessen den Raubkopierfaktor: Software muß verbreitet werden, damit das System sich verbreitet, im Markt etabliert. Das ist es, was den C64 und auch den PC groß gemacht hat: Billige und "kostenlose" Software..Auf der anderen Seite ist es für den Entwickler interessanter, wenn er weiß, dass seine Arbeit nicht kopiert wird. Was ich im Text vergessen habe: Ich hätte versucht, mit einigen Referenz-Spielprojekten System-Seller zu schaffen. Ich würde selbst versuchen, auch mit Software Geld zu machen. Da kann es nicht das Ziel sein, dass Software auf einfacher Art kopierbar ist. Kommt die Software auf Tape, müsste sie zuerst in den RAM geladen werden – der sehr knapp ist. Die Modul-Lösung böte schon deshalb bessere Spiele.

Controller: Die schnelle Folge, mit der diese "drankommen" sollen, könnte ein Problem sein. Das müsste schon seeehr schnell sein, um präzises Steuern zu ermöglichen, bin nicht sicher, ob so ein System das packt. A/D-Wandler im Joystick würden sowas sehr teuer machen (für Verhältnisse Ende der 70er/Anfang der 80er.) Aber egal, vielleicht auch nur was für Betuchte, der C64 kam ja auch mit Digitaljoysticks aus, bzw. als die erste Analogmaus kam, war der C64 praktisch tot, das wäre hier wohl genauso, auch mit den Analogjoysticks.Der normale Anwender braucht keinen AD-Wandler, deshalb würde im Computer keiner eingebaut. Aber: Für Autorennen ("Night Driver" als Anfang, später bessere Grafik) hätte man dann z. B. ein Lenkrad als Controller anbieten können. Nur für wenige erschwinglich, aber immerhin.

Insgesamt scheitern wohl alle meine Änderungsvorschläge am Geld: Die CPU auf kokurrenzfähigen Takt zu bringen (im Vergleich zum 6510 des C64) wäre wohl in der Herstellung zu teuer (oder auch Ende der 70er noch gar nicht machbar) und der dringend erforderliche Speicher auch.

Das Ding wäre unterm Strich wohl doch ein VC20, die dritte Generation dann ein C64. Genau überlegt: Wo wäre der Unterschied? :confused:Man muss gucken, wo man sparen kann. Der ZX81 hat zum Beispiel die Bildsignal-Erzeugung mit der CPU gemacht und damit einen Chip eingespart. Folge: Entweder ist man sehr langsam, oder der Bildschirm ist schwarz.

Noch was: Für Software (Spiele) auf Modulen sollte man vielleicht von Anfang an eine Möglichkeit vorsehen, Samples an die Soundchip zu senden (Streaming). Der Speicher wäre natürlich für Samples viel zu klein, aber an ihm vorbei wäre das schon 'ne Möglichkeit, dem SID des C64 ein Schnippchen zu schlagen.An sowas hatte ich auch schon gedacht, zur Sprachausgabe als Verkaufsargument. Aber selbst mit 4-Bit-ADPCM und 8000 Hz Samplingrate kommt man schnell an die Grenzen des ROMs.

[BAGZZlash]

Ach ja, den Sound habe ich vergessen. Da schwebt mir n recht einfacher FM-Synteziser vor, der drei Kanäle hat, bei denen man unabhängig die Lautstärke jeweils für linken und rechten Kanal regeln kann.


C64 konnte auch kein stereo, ob das zu CPU-lastig war?


Na für Tasksswitching müssen ja "nur" Register und Rücksprungadressen gespeichert werden. Die Sprünge innerhalb eines Programms müssten natürlich relative Adressen nutzen, da weiß ich jetzt nicht, ob das mit den damaligen CPUs möglich war.


GEOS konnte das, wie's realisiert wurde, keine Ahnung.

Insgesamt ist's schon komisch: Wenn man mal darüber nachdenkt, waren die Computer damals gut, so wie sie waren. Auch aus heutiger Sicht hätte man nicht viel anders machen können. Alles, was besser gewesen wäre, wäre viel teurer gewesen. Selbst das verhasste und bis heute belächelte BASIC war nötig. ASM war nicht einsteigertauglich und C oder sowas gab's damals noch nicht, außerdem ist das auf 'nen Compiler angewiesen, was Schwierigkeiten mit sich bringt: Compilieren braucht Speicher und CPU-Zeit, außerdem: Immer das Compilat auf Datasette speichern, RAM löschen, Programm von Datasette laden, ausprobieren, debuggen, neu compilieren... Wie war denn das Entwickeln damals so, hat man alles in Assembler gemacht? Was gab's überhaupt für Sprachen?
Sicher, aus heutiger Sicht hätte man am BASIC 'ne ganze Menge besser machen können: Direkterer Zugriff auf Hardware, insb. Schnittstellen, Sound und Grafik (v.a. Sprites auf dem C64), höhere Verarbeitungsgeschwindigkeit, WENIGER BUGS und und und. Schon damals wurde BASIC stiefmütterlich behandelt.

[elianda]

Das mit dem ROM am Anfang des Speichers funktioniert fuer einen 6502 nicht, da der Stack zwischen 0100 und 01ff liegt. Ausserdem verbaust du dir dadurch die Vorteile der Zeropage Adressierung incl. des der ganzen Befehlssatzes fuer die indirekt indizierten Adressierung ala LDA ($xx),Y bzw. LDA ($xx),X.
Du kannst das umgehen indem du fuer die Zugriffe auf diese Speicherseiten eine MMU vorsiehst, wie etwa beim C128, die diese Zugriffe auf andere Speicherseiten umleitet.

Ich wuerde dir empfehle oben mit dem ROM anzufangen.

Achja und ein Grund warum es nicht geht, dass beim 6502 'oben' nichts ist:
IRQ Vektor, NMI Vektor, Reset Vektor.

Und als Erweiterung einen simplen 16 Bit ISA Ausgang, da brauchst du nur einen Timing Converter von MOS auf Intel Timing. Aber das ist recht einfach zu loesen.
Da kann man dann prinzipiell jede ISA Karte und auch ATA Geraete anschliessen.

Was auch ein ungeloestes Problem zu sein scheint ist der DRAM Refresh bei deinem System. Und willst du die erste Taktphase des 6502 noch fuer irgendwas verwenden? Waere doch ziemlich bloed wenn das ganze System 50% der Zeit nichts tut.

Was mir noch eingefallen ist, schaue dir mal das Design des C128 an, da hast du einen 6502 Ableger und eine Z80 im selben System laufen. Da erkennt man sehr gut was den Unterschied ausmacht und wie es geloest ist. In Bezug auf Speicheranordnung, System Timing (VIC / VDC) und die Verbindung mit dem Memory Management und I/O Zugriffe.

[Tigerchen]

Ach ja, den Sound habe ich vergessen. Da schwebt mir n recht einfacher FM-Synteziser vor, der drei Kanäle hat, bei denen man unabhängig die Lautstärke jeweils für linken und rechten Kanal regeln kann.

An Schnittstellen nur das Übliche (TV via Antenne, später vielleicht SCART, sowie eine generelle Schnittstelle für die später n Drucker angeboten wird.) Die Tastatur ist eingebaut und wird am Ende jeder Bildschirmzeile von der CPU abgefragt, mit maximal 1 Byte Tastatur-Buffer.

Interrupts werden vom Interrupt-Controller gesteuert :) Im Detail hab ich das nicht ausgearbeitet. Selbst eine Ultraprimitiv-Konsole à la Atari 2600 erweist sich im Detail als komplexer, als man zunächst denkt.

Na für Tasksswitching müssen ja "nur" Register und Rücksprungadressen gespeichert werden. Die Sprünge innerhalb eines Programms müssten natürlich relative Adressen nutzen, da weiß ich jetzt nicht, ob das mit den damaligen CPUs möglich war.

Ich würde zu einem eZ-80 raten. Zilog bietet auch heute noch eine ganze Prozessorfamilie die auch ROM,Interrupts, I/O und Timer OnBoard hat.
http://www.zilog.com/products/partdetails.asp?id=eZ80L92

Für den Sound wär ein Yamaha YM2149 gut wenn es den noch gibt.

[BAGZZlash]

ISA wäre schon krass. Hat doch IBM gehört, damals, oder? Ist fraglich, ob die das für 'nen Homecomputer lizenziert hätten. Außerdem wäre das Overkill für unseren kleinen Computer: Ein 16-Bit-Bus für 'ne 8-Bit-CPU, der auch noch um den Faktor 8 schneller taktet als die CPU selbst. Nee, nee, unser Homecomputer stammt aus den 70ern, nicht vergessen. Gab's ISA da überhaupt schon?

Aber das bringt mich noch auf 'ne andere Frage: Wie sieht denn das geschwindigkeitsmäßig aus, den Zusatzspeicher der späteren Generationen über den Modulschacht anzubinden? Ist damit garantiert, daß das schnell genug ist? Wie waren damals die Zugriffzeiten überhaupt so? 200 ns?

Und "Bastellösungen" wie MMU direkt im Design einzuplanen, find' ich auch nicht so toll.

Des weiteren versteh' ich das Problem beim DRAM-Refresh nicht und warum die CPU dann die Hälfte der Zeit nicht ausgelastet ist. Kannst Du das bitte noch ein Bißchen genauer erklären?

[BAGZZlash]

Ich würde zu einem eZ-80 raten. Zilog bietet auch heute noch eine ganze Prozessorfamilie die auch ROM,Interrupts, I/O und Timer OnBoard hat.
http://www.zilog.com/products/partdetails.asp?id=eZ80L92

Für den Sound wär ein Yamaha YM2149 gut wenn es den noch gibt.


Nein, die Frage ist doch, wie ein Homecomputer DAMALS besser designed worden wäre, mit dem Wissen, das man heute hat.

[ShadowXX]

Wie war denn das Entwickeln damals so, hat man alles in Assembler gemacht?

Bis auf wenige Ausnahmen hat man quasi alles in Assembler gemacht.


Was gab's überhaupt für Sprachen?

Mehr als man heutzutage vielleicht vermutet: Pascal, Logo, Cobal (nein, nicht Cobol) und sogar einen C-Compiler.

Aber die waren mehr zum Probieren und für kleine (ganz kleine) Hobbyprojekte geeignet (der C-Compiler nicht mal dafür).


Sicher, aus heutiger Sicht hätte man am BASIC 'ne ganze Menge besser machen können: Direkterer Zugriff auf Hardware, insb. Schnittstellen, Sound und Grafik (v.a. Sprites auf dem C64), höhere Verarbeitungsgeschwindigkeit, WENIGER BUGS und und und. Schon damals wurde BASIC stiefmütterlich behandelt.
Bei C64 hattest du durchaus vollen Hardwarezugriff aus dem Basic heraus (Pokes & Peeks).

[Killerspielspieler]

Erinnert mich alles an den 8085 Computer - Bausatz von meiner Lehre.
ging von einfaches speichern bestimmt ram zustände über eine robotersteuerung über eine rs232-schnittstelle, drucker, diskettenlaufwerksspeicherung bis hin zur datenübertragung via glasfaser mit bildschirmausgabe über fbas-signal...
alles mit assembler alles mit dem 8085 und alle module selbst gebaut und gelötet

Edit: MFA hieß das Teil. Jetzt fällt es mir ein!

[BAGZZlash]

Bei C64 hattest du durchaus vollen Hardwarezugriff aus dem Basic heraus (Pokes & Peeks).

Ach ja, stimmt ja, diese tollen Dinger. Das gab's hinterher sogar auf dem PC mit GW-BASIC.
Das Blöde damals war vor allem, daß die Diskettenlaufwerke (1541, 1571, evtl. auch 1581, aber das weiß ich nicht, ich hatte keins) selbst Computer waren, die nur mittels ASM programmiert werden konnten. Außerdem gab's nun wirklich zumindest keinen direkten Zugriff auf Sound und Grafik.

[ShadowXX]

Ach ja, stimmt ja, diese tollen Dinger. Das gab's hinterher sogar auf dem PC mit GW-BASIC.
Das Blöde damals war vor allem, daß die Diskettenlaufwerke (1541, 1571, evtl. auch 1581, aber das weiß ich nicht, ich hatte keins) selbst Computer waren, die nur mittels ASM programmiert werden konnten. Außerdem gab's nun wirklich zumindest keinen direkten Zugriff auf Sound und Grafik.
Doch....mittels Pokes hast du direkt den Grafikchip und den Soundchip angesteuert.

Meine ersten Programme damals auf dem C64 waren Gehversuche in Basic....und da hab ich durchaus aus dem Basic heraus den Hires und/oder Muliticolor-Grafikmodi ein/ausgeschaltet. Darin "rumgemalt". Oder mit Sprites gespielt (incl. Kollisonsabfrage) oder auch Musik abgespielt.

Alles mittels direkten Zugriff auf Den Vic und Sid (per Poke & Peek-Wüsten.....lesen könnte das später kein Mensch mehr....aber es hat funktioniert).

Selbst Poke53280,X (X= wert zwischen 0 und 15 für die Farben -> Das ganze Manipuliert die Hintergrundfarbe) ist ein direkter Zugriff auf den Vic.

[Avalox]

C64 konnte auch kein stereo, ob das zu CPU-lastig war?


Es waren Hardware Synths. Der SID hatte 3 Stimmen wie sollten diese auf Stereo aufgeteilt werden? Einen Mixer gab es zu damaligen Zeiten nicht in der Form. Der war in Hardware fix. Das passte aber auch, denn Stereo Fernseher gab es damals auch nicht. Fernseher waren mono. Einen getrennten Audio Ausgang gab es natürlich auch nicht, der Ton wurde in das HF Signal moduliert. War praktisch, da nur ein Kabel zum TV. Wer Stereo haben wollte musste basteln.

Der Amiga später hatte 4 Stimmen. War dann der erste Home Computer welcher Stereo bot. 2 Stimmen fix links, 2 Stimmen fix rechts.

[Avalox]

Außerdem gab's nun wirklich zumindest keinen direkten Zugriff auf Sound und Grafik.


Das war aber eine Eigenart des C64 mit seinem unterirdisch schlechten Basic. Das Basic wurde ja tatsächlich (der komplette Interpreter) vom VC-20 übernommen. Spezielle C64 Funktionen konnten so ja gar nicht berücksichtig werden.

Die Atari 8Bit Computer hatten in ihren aus dem Jahr 1979 stammenden Basic natürlich umfangreiche Befehle für Sound und Grafik. Aber auch auf dem C64 liessen sich bessere Basic Interpreter verwenden. Simons' BASIC z.B.


Programmiersprachen gab es damals exotisch viele.
Klasse war z.B. Action! (http://www.strotmann.de/twiki/bin/view/APG/LangACTION) für den Atari 8Bit. War sehr wegweisend, aber auch sehr erfolglos. Action! wäre die richtig Sprache für aths Homecomputer. Eine ordentliche Programmiersprache hätte einiges gerissen.
Auch war der C64 auf 40 Zeichen/Zeile beschränkt. Das mit Absicht, da Commodore den C64 von den damals ebenfalls verkauften Bürocomputern abgrenzen wollte. Textverarbeitung war damit gar nicht so richtig möglich.
Ein besserer "C64" sollte von Hause aus einen echten 80 Zeichen/Zeile Modus haben.

Die Computer waren ja damals quasi alle Textmodus basierend. Natürlich boten auch die populären 8Bit Computer Grafikmodi, doch diese hatten kaum Bedeutung (ein paar Programme mit Grafikausgabe..). Der Rest wurde mit umdefinierten Zeichensätzen eben als Grafik im Textmodus dargestellt. Sicherlich wäre es deshalb gut gewesen, wenn der Zeichensatz deutlich mehr als 256 Zeichen umfasst hätte, oder halt entsprechend viele Zeichensätze parallel am Bildschirm darstellbar gewesen wären. (2Byte/Zeichen)

Man könnte auch mal gucken, ob es 1981 nicht doch schon möglich gewesen wäre eine echte Pixelgrafik basierende Ausgabe im Dialog hin zu bekommen. Es gab ja damals z.B. schon Grafiktablets und auch Lichtgriffel. Dieses schon lange vor der Verbreitung der Maus. Eine grafische Oberfläche hätte sicherlich schon damals gut gewirkt und wäre damit möglich zu steuern gewesen.

[aths]

Es waren Hardware Synths. Der SID hatte 3 Stimmen wie sollten diese auf Stereo aufgeteilt werden? Einen Mixer gab es zu damaligen Zeiten nicht in der Form. Der war in Hardware fix. Das passte aber auch, denn Stereo Fernseher gab es damals auch nicht. Fernseher waren mono. Einen getrennten Audio Ausgang gab es natürlich auch nicht, der Ton wurde in das HF Signal moduliert. War praktisch, da nur ein Kabel zum TV. Wer Stereo haben wollte musste basteln. Daran habe ich gar nicht gedacht. Dann hätte dieser Computer natürlich auch nur Mono-Sound geboten.



C64 konnte auch kein stereo, ob das zu CPU-lastig war?Die CPU-Last dürfte da nicht groß mit reinspielen. Entscheidend war wohl, die Soundchip-Größe und die Soundmisch-Technik preiswert zu halten.

GEOS konnte das, wie's realisiert wurde, keine Ahnung.

Insgesamt ist's schon komisch: Wenn man mal darüber nachdenkt, waren die Computer damals gut, so wie sie waren. Auch aus heutiger Sicht hätte man nicht viel anders machen können. Alles, was besser gewesen wäre, wäre viel teurer gewesen. Selbst das verhasste und bis heute belächelte BASIC war nötig. ASM war nicht einsteigertauglich und C oder sowas gab's damals noch nicht, außerdem ist das auf 'nen Compiler angewiesen, was Schwierigkeiten mit sich bringt: Compilieren braucht Speicher und CPU-Zeit, außerdem: Immer das Compilat auf Datasette speichern, RAM löschen, Programm von Datasette laden, ausprobieren, debuggen, neu compilieren... Wie war denn das Entwickeln damals so, hat man alles in Assembler gemacht? Was gab's überhaupt für Sprachen?
Sicher, aus heutiger Sicht hätte man am BASIC 'ne ganze Menge besser machen können: Direkterer Zugriff auf Hardware, insb. Schnittstellen, Sound und Grafik (v.a. Sprites auf dem C64), höhere Verarbeitungsgeschwindigkeit, WENIGER BUGS und und und. Schon damals wurde BASIC stiefmütterlich behandelt.Assembler gabs damals natürlich schon. Zumindest was Spiele angeht wurden die wohl meistens gleich in Assembler geschrieben.

Einige Computer aus der Zeit hatten imo große Schwächen. Meine Überlegungen in diesem Thread sind ein Versuch, wie man größere Schwächen hätte vermeiden können und das System trotzdem noch preiswert wäre.

[aths]

Das mit dem ROM am Anfang des Speichers funktioniert fuer einen 6502 nicht, da der Stack zwischen 0100 und 01ff liegt. Ausserdem verbaust du dir dadurch die Vorteile der Zeropage Adressierung incl. des der ganzen Befehlssatzes fuer die indirekt indizierten Adressierung ala LDA ($xx),Y bzw. LDA ($xx),X.Ja, die unteren 256 Byte sollten beim MOS 6502 natürlich RAM sein.

Du kannst das umgehen indem du fuer die Zugriffe auf diese Speicherseiten eine MMU vorsiehst, wie etwa beim C128, die diese Zugriffe auf andere Speicherseiten umleitet.

Ich wuerde dir empfehle oben mit dem ROM anzufangen.

Achja und ein Grund warum es nicht geht, dass beim 6502 'oben' nichts ist:
IRQ Vektor, NMI Vektor, Reset Vektor.

Und als Erweiterung einen simplen 16 Bit ISA Ausgang, da brauchst du nur einen Timing Converter von MOS auf Intel Timing. Aber das ist recht einfach zu loesen.
Da kann man dann prinzipiell jede ISA Karte und auch ATA Geraete anschliessen.

Was auch ein ungeloestes Problem zu sein scheint ist der DRAM Refresh bei deinem System. Und willst du die erste Taktphase des 6502 noch fuer irgendwas verwenden? Waere doch ziemlich bloed wenn das ganze System 50% der Zeit nichts tut.

Was mir noch eingefallen ist, schaue dir mal das Design des C128 an, da hast du einen 6502 Ableger und eine Z80 im selben System laufen. Da erkennt man sehr gut was den Unterschied ausmacht und wie es geloest ist. In Bezug auf Speicheranordnung, System Timing (VIC / VDC) und die Verbindung mit dem Memory Management und I/O Zugriffe.Solche Hybrid-Design machen das Sytem aus meiner Sicht unnötig teuer. Andererseits überlegte ich schon, zwei CPUs einzubauen von denen eine als Grafikchip fungiert (und à la Z80 die Ausgabe berechnet.) Vorteil wäre ein programmierbarer Grafikchip =) Die Frage ist natürlich, ob ein Extra-Grafikchip (statt Zweit-CPU) nicht doch preiswerter und gleichzeitig stärker ist.

Welche RAM-Arten zu jener Zeit bezahlbar waren, weiß ich jetzt ehrlich gesagt gar nicht. Natürlich wäre es schon, wenn man auf einen Extra-Taktgeber für den RAM-Refresh verzichten könnte. Jeder eingesparte Chip macht den Computer günstiger.




Erinnert mich alles an den 8085 Computer - Bausatz von meiner Lehre.
ging von einfaches speichern bestimmt ram zustände über eine robotersteuerung über eine rs232-schnittstelle, drucker, diskettenlaufwerksspeicherung bis hin zur datenübertragung via glasfaser mit bildschirmausgabe über fbas-signal...
alles mit assembler alles mit dem 8085 und alle module selbst gebaut und gelötet

Edit: MFA hieß das Teil. Jetzt fällt es mir ein!Ja. Ich kenne zwar diesen Bausatz nicht, aber es ist erstaunlich, mit was für aus heutiger Sicht schwachen CPUs man alles machen kann.

[Darkstar]

Einen getrennten Audio Ausgang gab es natürlich auch nicht, der Ton wurde in das HF Signal moduliert. War praktisch, da nur ein Kabel zum TV.Auf dem Video-Ausgang des C64 werden Videodaten und Ton aber getrennt übertragen.

[Avalox]

Auf dem Video-Ausgang des C64 werden Videodaten und Ton aber getrennt übertragen.

Ja. Das kann sein. Der C64 hatte ja einen extra Monitor Stecker. Habe nie in der Praxis einen Monitor am C64 gesehen.
Es gab ja auch so Bastelanleitungen. So konnte man einen zweiten SID in den C64 einbauen, dann gab es auch Stereo. Ein SID links, der zweite SID rechts.


Gibt übrigens auch eine PC PCI Soundkarte mit 4 x den C64 SID drauf. (für den besonderen Sound ;) )

http://www.hardsid.com/modules.php?name=Content&pa=showpage&pid=2

http://www.hardsid.com/hsimg/HSQPCI3.jpg



@aths

Man sollte sich mal die Spielhallen Hardware von 1981/82 ansehen. Diese war ja damals deutlich weiter, als die Spielkonsolen/Homecomputer. Ich denke dort kann man sich einiges an Inspiration holen.

[BAGZZlash]

Assembler gabs damals natürlich schon. Zumindest was Spiele angeht wurden die wohl meistens gleich in Assembler geschrieben.


Is klar. Was anderes: Ich hab' mich nochmal mit dem Problem Analogmaus/Analogjoysticks beschäftigt, und irgendwo gelesen, daß die Analogmaus des C64 auch keinen eingebauten A/D-Wandler hatte, sondern der Wandler des SID benutzt wurde. Kann das sein? Hatte der SID überhaupt 'nen A/D-Wandler? Hatte der nicht nur D/A?

[Avalox]

C64 auch keinen eingebauten A/D-Wandler hatte, sondern der Wandler des SID benutzt wurde. Kann das sein? Hatte der SID überhaupt 'nen A/D-Wandler? Hatte der nicht nur D/A?

Der SID hatte wohl zwei A/D Wandler. Diese aber nicht für die Audiodigitalisierung (das konnten diese mangels Auflösung auch nicht), sondern für analoge Drehregler. Die Chips waren damals multifunktional ausgelegt. So dass diese nie komplett einzel Aufgaben bezogene Anwendungen erfüllten. Der SID war eben auch da um Drehregler (neben dem Joystick damals recht gebräuchliche Spieleingabe Geräte) verarbeiten zu können. Vielleicht hat sich auch der SID Entwickler gedacht, Drehregler könnten zum Musik machen recht nützlich sein. Wenn man nun zwei Drehregler kombiniert hat man die Maus. An eine Maus hat der Sid Entwickler aber ganz sicher nicht gedacht dabei.

[BAGZZlash]

[...]Drehregler (neben dem Joystick damals recht gebräuchliche Spieleingabe Geräte)[...]

Du meinst Paddles. :smile:

Also war das wirklich so, ja? Das bedeutet also, daß die gleichzeitige Benutzung von Analogmaus und Soundausgabe nicht möglich war. Gut, bei Mäusen ist das noch egal, bei Spielen aber doof, da eben Analogjoysticks für Spiele (Flusis) eingesetzt werden und da ist ohne Sound eben schlecht.
Oder war das doch möglich? Eigentlich braucht der SID zur Soundausgabe seine A/D-Wandler ja nicht. Gab's auf dem C64 Analogjoysticks?

[No.3]

Ach ja, stimmt ja, diese tollen Dinger. Das gab's hinterher sogar auf dem PC mit GW-BASIC.
Das Blöde damals war vor allem, daß die Diskettenlaufwerke (1541, 1571, evtl. auch 1581, aber das weiß ich nicht, ich hatte keins) selbst Computer waren, die nur mittels ASM programmiert werden konnten. Außerdem gab's nun wirklich zumindest keinen direkten Zugriff auf Sound und Grafik.

1541 (http://cbmmuseum.kuto.de/floppy_vc1541.html)
Prozessor: MOS 6502
Taktfrequenz: ~1 MHz
RAM: 2 KByte
ROM: 16 KByte

war bei den anderen recht ähnlich, die 1581 hatte z.B. nen grösseres ROM

[elianda]

ISA wäre schon krass. Hat doch IBM gehört, damals, oder? Ist fraglich, ob die das für 'nen Homecomputer lizenziert hätten. Außerdem wäre das Overkill für unseren kleinen Computer: Ein 16-Bit-Bus für 'ne 8-Bit-CPU, der auch noch um den Faktor 8 schneller taktet als die CPU selbst. Nee, nee, unser Homecomputer stammt aus den 70ern, nicht vergessen. Gab's ISA da überhaupt schon?


Du verstehst nicht ganz was ich meine, kein ISA Bus sondern eine PISA - Programmed ISA Anbindung. Das hat nichts mit Takt usw. zu tun, sondern ist einfach ein Standard mit welchem Timing man klassische Intel basierte Chips anspricht. Und wenn die Daten 16 bittig kommen, dann ist das auch fuer einen 8 Bit Prozessor mindestens gleich schnell als wenn sie als 8 Bit kommen, aber in 99% der Faelle eher schneller.
Eben sowas wie der Userport des C64 nur nicht mit Motorola sondern Intel Timing.

Des weiteren versteh' ich das Problem beim DRAM-Refresh nicht und warum die CPU dann die Hälfte der Zeit nicht ausgelastet ist. Kannst Du das bitte noch ein Bißchen genauer erklären?

Ok also zum 6502:
Der 6502 hat einen Zweiphasentakt, also Rechteck mit 50% Pulsbreite und arbeitet im Zweiten Teil, also nach der H -> L Flanke. In der ersten Takthaelfte koennen andere ICs quasi transparent Speicherzugriffe ueber den Bus durchfuehren.

Der Nachteil des 6502 ist, dass man ihn nicht anhalten kann, um zB DMA durchzufuehren oder andere Chips den Bus in den CPU Takthaelften nutzen zu lassen. Das ist der groesste Vorteil des 6510 mit /AEC und /BA.

Zum Z80:
Der Z80 hat einen /IORQ mit dem man (aehnlich wie beim x86) 256 IO Adressen hat. Man muss es also nicht Memory Mapped gestalten.

Und man kann per /BUSRQ den Bus freigeben lassen fuer externe Peripherie.

Der Nachteil ist er hat den BUS zu 100% im Zugriff und nicht wie der 6502 nur zu 50% der Zeit - und die Befehlsausfuehrungszeiten sind teilweise erheblich laenger als beim 6502 bei gleichem Takt.

Ja, die unteren 256 Byte sollten beim MOS 6502 natürlich RAM sein.

Du meinst sicher die unteren 512 Byte - ZeroPage + Stack.


Um mal auf die aktuelle Technik zu kommen - nimm einen FPGA und eine der freien VHDL Vorlagen fuer Z80 und/oder 6502, teilweise gibts auch schon Peripherie. Es gibt da auch noch einiges mehr an 'Remakes'.
zB: http://c64upgra.de/c-one/s_download.htm

Mangels Produktion (bis auf Z80) macht es auch keinen Sinn eine alte CPU zu verwenden. Wenn man sonst so schaut, gibt es von der Vielfalt her kaum Grenzen. Es gibt 8 Bit CPUs schon mit 6 Pins bis hin zu beliebigen Kombinationen aus CPU / DSP / FPGA (auch FPAA) / FLASH / RAM / TPU (benutzerdefiniertes I/O Timing zur Ansteuerung beliebiger externer ICs)
Der C64 DTV hat es vorgemacht, man kann so ein klassisches Homecomputer System in einen Chip packen heutzutage.

[aths]

Gerade eine neue Idee: Ein Gerät, welches Software einscannen kann.

Um die Verbreitung von Software durch Magazine einfacher zu machen, hätte man eine Art Barcode-Leser (nur für einen komplexeren Code) entwickeln können. Dann bräuchte man die Seite nur auszuschneiden (oder zu kopieren, wenn der Kopierer genau genug arbeitet) und durchrollen lassen.

Angenommen, so ein Streifen hätte 4" Breite (ca. 10 cm.) Man müsste gucken, wie teuer Abtast-Sensoren waren, also ob man das Lesegerät auf der vollen Breite abtasten lässt, oder nur auf der linken Häfte (womit ein erneuter Durchlauf bei gedrehtem Streifen notwendig gewesen wäre, um alles zu lesen.) Da könnte man auf die volle Breite bei 1 mm Strichdicke (also 1 Strich = 1 Bit) durchaus 2 Byte hinbekommen (z. B. mit einem 14-zu-8-Code mit Fehlerkorrektur und inklusive Synchronisierungsmarkierungen links und rechts.) Bei 2 Streifen pro Seite à ca. 26 cm Länge könnte man auf eine Din-A4-Seite so 1 kiB Code unterbekommen.

Weiterer Vorteil: Anstatt Programme nur auf Tape zu sichern, könnte man sie auch einfach maschinenlesbar ausdrucken.

[BAGZZlash]

Gerade eine neue Idee: Ein Gerät, welches Software einscannen kann.

Um die Verbreitung von Software durch Magazine einfacher zu machen, hätte man eine Art Barcode-Leser (nur für einen komplexeren Code) entwickeln können. Dann bräuchte man die Seite nur auszuschneiden (oder zu kopieren, wenn der Kopierer genau genug arbeitet) und durchrollen lassen.

Angenommen, so ein Streifen hätte 4" Breite (ca. 10 cm.) Man müsste gucken, wie teuer Abtast-Sensoren waren, also ob man das Lesegerät auf der vollen Breite abtasten lässt, oder nur auf der linken Häfte (womit ein erneuter Durchlauf bei gedrehtem Streifen notwendig gewesen wäre, um alles zu lesen.) Da könnte man auf die volle Breite bei 1 mm Strichdicke (also 1 Strich = 1 Bit) durchaus 2 Byte hinbekommen (z. B. mit einem 14-zu-8-Code mit Fehlerkorrektur und inklusive Synchronisierungsmarkierungen links und rechts.) Bei 2 Streifen pro Seite à ca. 26 cm Länge könnte man auf eine Din-A4-Seite so 1 kiB Code unterbekommen.

Weiterer Vorteil: Anstatt Programme nur auf Tape zu sichern, könnte man sie auch einfach maschinenlesbar ausdrucken.

Klasse Idee. Für den C64 gab's ja auch einen Scanner. Dieser wurde auf den Druckkopf bestimmter, kompatibler Drucker gesetzt und hat dann zeilenweise die Vorlage abgetastet.

[Tigerchen]

Das war aber eine Eigenart des C64 mit seinem unterirdisch schlechten Basic. Das Basic wurde ja tatsächlich (der komplette Interpreter) vom VC-20 übernommen. Spezielle C64 Funktionen konnten so ja gar nicht berücksichtig werden.


Sowas wie das Locomotive BASIC des CPC war dem der 64er bei weitem überlegen. Außerdem. Grundlegene Routinen wie Bildschirmausgabe, Sound, Timer, usw. führte das BASIC nicht selbst aus sondern nutzte eine Sprungtabelle um diese Routinen im unteren ROM aufzurufen. Dadurch hat man leicht die Möglichkeit diese Routinen in eigenen Assemblerprogrammen zu nutzen oder auf eigene Routinen umzubiegen.

[Avalox]

Du meinst Paddles. :smile:

ja. Drehregler und Steuerknüppel. Lichtgriffel finde ich auch gut.




Also war das wirklich so, ja? Das bedeutet also, daß die gleichzeitige Benutzung von Analogmaus und Soundausgabe nicht möglich war.


Doch. Die A/D Wandler waren eben eine zusätzliche Funktion des SIDs.
Der VIC II Videocontroller war ja auch gleichzeitig Taktgenerator für den Systemtakt, den RAM Refresh hat er auch nebenbei ausgeführt.

Ein anderes Beispiel. Der Pokey der Atari 8Biter war nicht nur Soundcontroller, er hat auch gleichzeitig die Tastatur Abfragen ausgeführt. Die Bausteine damals waren eben recht speziell.



Gab's auf dem C64 Analogjoysticks?

habe ich nie gesehen. Aber denkbar natürlich. Ist ja ebenfalls über zwei Achsen zu steuern.

[Avalox]

Sowas wie das Locomotive BASIC des CPC war dem der 64er bei weitem überlegen.

Der CPC kam ja erst sehr spät auf dem Markt. Ich denke 1984 oder so. Zu der Zeit waren die Atari 8Bit Computer schon 5 Jahre da. Der erste MAC ist zur gleichen Zeit erschienen. Der Atari ST zeichnete sich schon am Horizont ab. Diese Geräte waren dann eben doch schon was anderes als die alten 8Bit Homecomputer.

So ein richtig interessanter Homecomputer war der Arcon A. Ein richtig tolles Ding. 1981 auf den Markt gekommen. 2MHz 6502, Grafikmodus only, Auflösung bis 640x256 Pixel, damit echte 80 Zeichen und nun kommts; er konnte mit einem 6MHz Z80 erweitert werden. Ich denke der Arcon A wäre der richtige Knaller Homecomputer für die startenden 80er Jahre gewesen. Leider war er eben nicht auf Spiele getrimmt. Weil kein Textmodus vorhanden war, war es eben doch recht langsam in der Spielegrafik. Mit passenden Spielen, so ist Elite ist für den Arcon A entwickelt worden... die Vectorgrafik war eben klasse für solch ein Gerät. Hab Elite nie auf einen Arcon gesehen. Aber wer es hat schwärmt noch heute davon.

[Avalox]

Gerade eine neue Idee: Ein Gerät, welches Software einscannen kann.
.

Eine tolle Idee. Ich frage mich grade ob es nicht so was in der Art sogar gab, man halt sich nur nicht auf einen Standard einigen konnte. Hmm. Jedenfalls waren viele Seiten lange Listings absolut üblich. Es gab ganze Bücher mit Listings. Später gab es dann Checksummen Eingabehilfen. Ein Problem damals war, dass die Satzmaschinen in den Druckerein natürlich auch nichts mit den eingesendeten Datenträgern hat Anfangen konnten. Der Drucker musste die Listings also selbst abtippen, da schlichen sich eine Menge Fehler in die Listings ein. Zeitschriften haben damals Belohnungen für das Finden von Satzfehlern in ihren Listings vergeben.

[aths]

Ja, Listings waren eine Qual zum abtippen. Auch Hex-Listings waren eeewig lang. Ich bin mir ziemlich sicher, dass auch ein zunächst proprietärer Leser durchaus etwas Erfolg gehabt hätte, sofern man eben auch die Software anbietet, Programme maschinenlesbar auszudrucken.

Klasse Idee. Für den C64 gab's ja auch einen Scanner. Dieser wurde auf den Druckkopf bestimmter, kompatibler Drucker gesetzt und hat dann zeilenweise die Vorlage abgetastet.Den Drucker mitzubenutzen – daran hatte ich gar nicht gedacht. Ein eigenes Gerät wäre teuerer, böte aber ne bessere Datendichte.

Andererseits: Wenn es gelungen wäre, den Grund-Computer so preiswert herzustellen, dass man ihn preiswert anbieten kann und so die installierte Basis verbreitert, hätte man beim Absatz mit Zusatzgeräten wohl nicht die großen Probleme.

Wichtig ist imo auch, dass nicht nur die eigentliche Hardware-Leistung stimmt, sondern dass die Software eine große Breite abdeckt. Sich hier gleich mal "Killer-Applikationen" auszudenken wäre wohl vermessen. Aber folgende Ideen:

- Das BASIC nutzt – à la ZX80-Spectrum – pro BASIC-Befehl nur 1 Byte, um Speicher zu sparen.
- Außerdem gibt es vordefinierte Makros, zum Beispiel: [Zeilennummer] IF INKEY$="" THEN GOTO [Zeilennummer].
- Eben FP48 statt FP40 oder FP32 – die hohe Genauigkeit von 12 Dezimalstellen wäre ein gutes Verkaufsargument =)
- Auf die Hardware müsste sich mit relativ einfachen Befehlen zugreifen lassen. So dass ein versierter Programmierer den gesamten Computer ausnutzen kann.
- Die Grafikbefehle sind so implementiert, dass sie auch mit dem Highres-Modul funktionieren – nur dort eben in höherer Auflösung.


Um die Jugend zu locken, hätte man bestimmte Software im Hause entwickeln können, zum Beispiel etwas wie "Astronomer" für den Specci: Ein Programm, wo man Wohnort und Uhrzeit eingibt und was dann den Sternhimmel berechnet und anzeigt.

Wissenschaftler hätte man mit einem Programm locken können, welches aus Daten Diagramme und Kurven erstellen kann, und vielleicht auch Inter- und Extrapolationen vornehmen kann.

[Gast]

Hi;

wie sieht eigentlich der Zeitplan für deine 3 Homecomputer Evolutionen aus?

Das würde ein wenig helfen die möglichen Technologien einzuordnen.

Der Z80 selber zB ist pro Takt ziemlich langsam, es gab aber (leider viel zu spät) eine Art Nachfolger, den R800.

Wenn du also noch einen Zeitrahmen abstecken könntest wäre das nett.

[Avalox/Gast]

Na wenn es um reine CPU Leistung geht, dann hätte man schon zu C64 Zeiten einen MC68000 verwenden können. Der MC68k ist ja schliesslich schon seit 1979 mit 8MHz auf dem Markt.

War nicht der Nachfolger des Z80 der Z8000? na jedenfalls kam 1986 der Z80000 auf dem Markt. (übrigens eine CPU mit Pipelines)

[aths]

Hi;

wie sieht eigentlich der Zeitplan für deine 3 Homecomputer Evolutionen aus?Beginn so ca. 1980.

Der Z80 selber zB ist pro Takt ziemlich langsam, es gab aber (leider viel zu spät) eine Art Nachfolger, den R800. Der Z80 hat war eine beschämende Pro-Takt-Leistung, benötigt aber für ein 16-Bit-ADD weniger Takte als ein MOS 6502. Dazu ist der Z80 deutlich höher getaktet.

[elianda]

Der Z80 ist auch eine Registerorientierte CPU und der 6502 eine Speicherorientierte. Desweiteren hat schon der 6502 eine 'one step' Pipeline. Das sieht man schon an den Befehlsausfuehrungszeiten.

[aths]

Nur bringt das nix, wenn der 6502 alles in 8 Bit macht, wo der Z80 schon 16-Bit-Operationen unterstützt. Die Pro-Takt-Leistung ist beim 6502 zwar recht gut, dafür ist der Takt im Vergleich zum Z80 viel geringer.

[ShadowXX]

- Auf die Hardware müsste sich mit relativ einfachen Befehlen zugreifen lassen. So dass ein versierter Programmierer den gesamten Computer ausnutzen kann.
- Die Grafikbefehle sind so implementiert, dass sie auch mit dem Highres-Modul funktionieren – nur dort eben in höherer Auflösung.

aths...hast du jemals einen C64 und/oder Atari XL programmiert?

Dann wüsstest du das da ohne ASM nicht, aber auch gar nichts lief und auf die Hardware sowieso einfach zugegriffen werden konnte (Mittels eines einzigen Registers stellt man die verschiedenen Grafikmodi ein, mit einem ASM 4-Zeiler verbiegt man den Interrupt, Scrolling waren auch nur ein paar Zeilen ASM u.s.w.).

Vergiss da mit irgendwelchen "einfachen Befehlen" bzw. vergiss einfach die Programmierung mit Basic oder jeder andern höheren Sprache. Vergiss auch irgendwelche Rom-Firmware-Calls bzw, OS-Calls für sowas....das hat nicht mal auf dem Amiga funktioniert.

Die Devs (und auch Hobby-Programmierer) werden sowieso immer drumherum programmieren.
Leg deshalb lieber ein Rom-Listing und eine ausführliche Doku zu den einzelnen Chips bei, das bringt mehr.


Um die Jugend zu locken, hätte man bestimmte Software im Hause entwickeln können, zum Beispiel etwas wie "Astronomer" für den Specci: Ein Programm, wo man Wohnort und Uhrzeit eingibt und was dann den Sternhimmel berechnet und anzeigt.

Damit hättest du definitiv nicht die Jugend gelockt (sowas gabs übrigens unter "Ferner Liefen" auch für C64 und Amstrad).


Wissenschaftler hätte man mit einem Programm locken können, welches aus Daten Diagramme und Kurven erstellen kann, und vielleicht auch Inter- und Extrapolationen vornehmen kann.
Wissenschaftler hätten mit diesem "Spielzeug" (sorry) nichts anfangen können. Selbst wenn das Ding FP48 gehabt hätte, wäre es zu langsam.

Nur bringt das nix, wenn der 6502 alles in 8 Bit macht, wo der Z80 schon 16-Bit-Operationen unterstützt. Die Pro-Takt-Leistung ist beim 6502 zwar recht gut, dafür ist der Takt im Vergleich zum Z80 viel geringer.
Trotzdem ist der Unterschied nicht so graviered wie sich das auf Datenblättern bzw. theoretischen Tests liesst. Der 6502 des AtariXL war mit ca. 1.6 MHz getaktet und hat damit jeden Z80 mit 4MHz in Grund und Boden gerechnet.
Und selbst der mit nur knapp 1 MHz getaktete 6510 des C64 stand dem 4MHz Z80 des Amstrad in Vectorgames kaum nach....

[aths]

aths...hast du jemals einen C64 und/oder Atari XL programmiert?

Dann wüsstest du das da ohne ASM nicht, aber auch gar nichts lief und auf die Hardware sowieso einfach zugegriffen werden konnte (Mittels eines einzigen Registers stellt man die verschiedenen Grafikmodi ein, mit einem ASM 4-Zeiler verbiegt man den Interrupt, Scrolling waren auch nur ein paar Zeilen ASM u.s.w.).Das war beim C64 oder Atari so, ja. Das heißt nicht, dass es nicht elegantere Lösung hätte geben können.

Damit hättest du definitiv nicht die Jugend gelockt (sowas gabs übrigens unter "Ferner Liefen" auch für C64 und Amstrad).Ja, klar. Aber außer mit Joystick-Killern wie "Party Girls" hätte man auch mit ernsthaften Anwendungen die interessierte Jugend locken können. Was gegen wissenschaftliche Anwendungen spräche, wäre eher der geringe Hauptspeicherplatz. Mit 8 kiB wäre das Problem aber zumindest vorläufig entschärft worden.

Für Spiele hätte man noch FP24- oder FP32-Routinen implementieren können. Vielleicht im erweiterten BASIC-Modul, bzw. als freie Routinene, die jeder Entwickler, der in ASM für ein Modul programmiert, mit ins Modul aufnehmen darf.

Wissenschaftler hätten mit diesem "Spielzeug" (sorry) nichts anfangen können. Selbst wenn das Ding FP48 gehabt hätte, wäre es zu langsam.Langsam, aber billig. Nicht jeder Wissenschaftler oder wissenschaftlich interessierte hat das Geld für einen Großrechner. Die Uni Rostock hat zu DDR-Zeiten (mit unglaublich viel Geld) einen C64 (der auf der Cocom-Liste stand) ins Land schmuggeln können.

Trotzdem ist der Unterschied nicht so graviered wie sich das auf Datenblättern bzw. theoretischen Tests liesst. Der 6502 des AtariXL war mit ca. 1.6 MHz getaktet und hat damit jeden Z80 mit 4MHz in Grund und Boden gerechnet.Aber nicht bei 16-Bit-ADDs. Zumal es den Z80 auch mit mehr als 4 MHz gab.

Und selbst der mit nur knapp 1 MHz getaktete 6510 des C64 stand dem 4MHz Z80 des Amstrad in Vectorgames kaum nach....Das kann mehrere Ursachen haben.

[Gast]

Hi;

dein Homecomputer erinnert mich ein wenig an den TI 99/4A da du die Programme ebenfalls auf Cards ausliefern willst. Der einzige markante Unterschied ist, das dein Homecomputer 8KB hat, der TI 99/4A aber nur 256byte (dafür aber standardmäßig 16KB Video-RAM).

Der Ti99/4A hatte übrigens auch bereits eine 16bit CPU, allerdings nur einen 8bit Bus.

Außerdem hatte er einen VDP (Vorgänger des MSX-VDP) und damit ist auch der Weg für die Upgrades bereits vorgezeichnet.

Übrigens, warum eigentlich nur 8KB? Der C64 ist zwar "erst" 1982 auf den Markt gekommen hatte aber bereits 64KB. Also sollten 1980 16-32KB möglich sein (+16-32KB Video-RAM als spätere Erweiterung).

grüsse

Manfred

Link: http://en.wikipedia.org/wiki/Texas_Instruments_TI-99/4A

[Gast]

ich nochmal;

der TMS9900 im Ti99/4A Homecomputer hatte anscheinend sogar einen Nachfolger:


TMS99000
99000-series microprocessors were used in the 990/10A
TI introduced a 24-MHz TMS99000 MPU, with a $65 price in 100-piece
quantities. (Quotes from the Nov 2, 1981 Electronic News).
It includes an "on-chip macrostore memory with 1K bytes of ROM and 3K
bytes or RAM for storage of frequently-used functions which can then
be accessed at full processor speeds." The company is preparing a
chip version using that macrostore for floating point operations, and
said that part, designated the TMS99110, would be available in
December at $99. The instruction set is a superset of the TMS9995 and
TMS9900, with object code compatibility. There are also new
instructions for multiprecision arithmetic, stack operations, parallel
I/O, and memory bit manipulation. It has "an instantaneous address
reach of 256K bytes of main memory and 120K bytes of internal and/or
external macrostore memory", as well as compatibility with the
TIM99610 memory mapper for control of address space up to 16M bytes.

There was also a 99105, which was similar to the 99110, without floating point

Link: http://dimka.com/daily/external-pages/spies.com-~aek-orphanage.html

Diese CPU war noch nicht einmal so teuer (IMHO) und würde auch von der Zeit gut passen. Und mit 24MHz hätte diese CPU wahrscheinlich wirklich viele Profi's eine ausreichende Leistung geboten.


grüsse

Manfred

[aths]

Hi;

dein Homecomputer erinnert mich ein wenig an den TI 99/4A da du die Programme ebenfalls auf Cards ausliefern willst. Der einzige markante Unterschied ist, das dein Homecomputer 8KB hat, der TI 99/4A aber nur 256byte (dafür aber standardmäßig 16KB Video-RAM).

Der Ti99/4A hatte übrigens auch bereits eine 16bit CPU, allerdings nur einen 8bit Bus.

Außerdem hatte er einen VDP (Vorgänger des MSX-VDP) und damit ist auch der Weg für die Upgrades bereits vorgezeichnet.

Übrigens, warum eigentlich nur 8KB? Der C64 ist zwar "erst" 1982 auf den Markt gekommen hatte aber bereits 64KB. Also sollten 1980 16-32KB möglich sein (+16-32KB Video-RAM als spätere Erweiterung).Der C64 war auch sehr teuer zu Anfang. Mir schwebt vor, bei „meinem“ Computer à la ZX81 die Bildsignalerzeugung zunächst via CPU zu machen, und einen Slow-Modus (CPU rechnet am Programm nur dann, wenn der Kathodenstrahl abgeschaltet ist), wie einen Fast-Modus (sofern die CPU was zu tun hat, berechnet sie kein Bildsignal) anzubieten. Das spart immerhin einen Chip. Spätere Modelle könnten dann mit einem extra-Z80 als „Grafikchip“ kommen. Oder man setzt den „Grafik-Z80“ gleich auf das Highres-Modul, so dass man ohne Highres-Modul eben nur „Software-Grafik“ hat.

Das wäre natürlich alles ziemlich umständlich, die Entwicklung dedizierter Grafikchips könnte sich auch lohnen, vor allem wenn die Stückkosten dann unterhalb der Z80-Kosten liegen.


Der TMS9900 nutzt ein interessantes Design bezüglich Registern. Eigentlich bin ich nicht unbedingt Fan vom Z80, eher vom Motorola Motorola 6809 (geiles Teil!) oder Hitachi 6309 (ultrafettes Teil!!).


edit: Was meinen Ideen ziemlich nahe kommt, ist der TSR-80: http://en.wikipedia.org/wiki/TRS-80_Color_Computer. Auch der dort verwendete primitive Grafikchip hätte erst mal ausgereicht. Ein besserer hätte ja zum Highres-Modul gehören können.

Für wissenschaftliche Anwendungen hätte man auch schon eine FPU entwickeln können. Allerdings sind FP-Rechnungen auf einem 6809 dank des MULs relativ schnell zu berechnen, jedenfalls schneller als auf Chip, die kein MUL haben.

[Gast]

Der C64 war auch sehr teuer zu Anfang.


Stimmt schon. Aber ich dachte das dein Homecomputer auch für Professionelle Sachen benutzbar sein sollte. Wenn du dann zu kurz springst geht das nicht (IMHO).


Das spart immerhin einen Chip


wenn ich das ganze alles richtig verstanden habe, dann hatten nahezu alle alten Homecomputer einen richtigen Grafikchip. Die CPUs waren dafür viel zu langsam.


Der TMS9900 nutzt ein interessantes Design bezüglich Registern. Eigentlich bin ich nicht unbedingt Fan vom Z80, eher vom Motorola Motorola 6809 (geiles Teil!) oder Hitachi 6309 (ultrafettes Teil!!).

Der TMS9900 ist ein Z80-clone? Dafür sieht die Beschreibung aber aus meiner Sicht zu unterschiedlich aus. Vor allem ist soweit ich das sehe der TMS9900 eine 16bit MPU und der Z80 nur eine 8bit MPU.

Übrigens:

Ti99/4a => TMS9900 @ 3MHz (~1981)
Ti99/8 => TMS9995 @ 10MHz (~1983)
für eine dritte Ausbaustufe wäre dann eben auch noch der TMS99000 mit 24MHz verfügbar gewesen.

Laut ein paar älteren Forum-Einträgen die ich mir gestern angeschaut habe soll zumindest der TMS9900 eine bessere proMHz-Leistung gehabt haben als der Intel8086. Der TMS99000 hatte dann sogar Caches um nicht mehr so stark von schnellem RAM abhängig zu sein (der einzige Nachteil des TMS9900 den ich sehen kann).

Links:
http://www.99er.net/998.html
http://en.wikipedia.org/wiki/List_of_home_computers_by_category

[aths]

Stimmt schon. Aber ich dachte das dein Homecomputer auch für Professionelle Sachen benutzbar sein sollte. Wenn du dann zu kurz springst geht das nicht (IMHO).

wenn ich das ganze alles richtig verstanden habe, dann hatten nahezu alle alten Homecomputer einen richtigen Grafikchip. Die CPUs waren dafür viel zu langsam.Der Grafikchip des TSR-80 kann zwar nicht viel, aber dürfte so preiswert sein, dass er sich auf jeden Fall lohnt.

Der 6809 hat ein MUL, damit sind FP-Rechnungen deutlich schneller möglich als hätte er das nicht.

Man kann nicht immer nur mehr Hardware einbauen. Die Möglichkeit zur professionellem Nutzung ließe sich z. B. via einer FPU verbessern. Für den Privatanwender muss das System erst mal erschwinglich sein. Deshalb auch die Idee, standardmäßig nur 4 kiB RAM einzubauen.


Der TMS9900 ist ein Z80-clone? Dafür sieht die Beschreibung aber aus meiner Sicht zu unterschiedlich aus. Vor allem ist soweit ich das sehe der TMS9900 eine 16bit MPU und der Z80 nur eine 8bit MPU. Da habe ich mich wohl missverständlich ausgedrückt. Das mit dem Z80 ist unabhängig vom TI-Chip gemeint.

Laut ein paar älteren Forum-Einträgen die ich mir gestern angeschaut habe soll zumindest der TMS9900 eine bessere proMHz-Leistung gehabt haben als der Intel8086. Der TMS99000 hatte dann sogar Caches um nicht mehr so stark von schnellem RAM abhängig zu sein (der einzige Nachteil des TMS9900 den ich sehen kann).Der 6809 hätte bei dem Computer aber vermutlich ausgereicht. Ich kenne die Chip-Preise nicht, aber vermute, dass der TI-Chip recht teuer war.

[Gast]

Da habe ich mich wohl missverständlich ausgedrückt. Das mit dem Z80 ist unabhängig vom TI-Chip gemeint.


Dachte ich mir schon, trotzdem habe ich noch nach weiteren Informationen über den TMS9900 gesucht. Laut dieser Seite ist der Vergleich zum Z80 vielleicht nicht einmal so falsch:

http://nouspikel.group.shef.ac.uk//ti99/tms9900.htm

Die Execution-Zeiten für die Befehle scheinen mir auf den ersten Blick ziemlich hoch zu sein.


Der 6809 dürfte auch nicht gerade billig gewesen sein. Der 6502, als 6800-Klon hatte ja nur deshalb so viel Erfolg weil er wesentlich preiswerter war als die Konkurrenz:

Quote aus der Wikipedia:

The 6502 was introduced at $25 in September 1975, when the 6800 and Intel 8080 were selling for $179. At first many people thought the new chip's price was a hoax or a mistake, but shortly both Motorola and Intel had dropped their chips to $79. Far from the intended result, these price reductions actually legitimized the 6502, which started selling by the hundreds.

Der Preis ist allerdings von 1975

[aths]

Dachte ich mir schon, trotzdem habe ich noch nach weiteren Informationen über den TMS9900 gesucht. Laut dieser Seite ist der Vergleich zum Z80 vielleicht nicht einmal so falsch:

http://nouspikel.group.shef.ac.uk//ti99/tms9900.htm

Die Execution-Zeiten für die Befehle scheinen mir auf den ersten Blick ziemlich hoch zu sein.


Der 6809 dürfte auch nicht gerade billig gewesen sein. Der 6502, als 6800-Klon hatte ja nur deshalb so viel Erfolg weil er wesentlich preiswerter war als die Konkurrenz:

Quote aus der Wikipedia:


Der Preis ist allerdings von 1975Der 6502 konkurierte mit dem 6800-er, nicht mit dem fortschrittlicherem 6809. Der 6809 ist generell schneller, einfacher zu programmieren, und hat auch noch ein MUL im Angebot. Gerade das MUL macht mich an – das ist in vielen Berechnungen hilfreich.