i486-Board

  • Thread starter Christian Gudrian
  • Start date
Christian Gudrian, meinte...

Mit wieviel Aufwand ist es verbunden, sich sein eigenes kleines 486er-Board
zusammen zu stricken? Von meinem etwas laienhaften Standpunkt aus sollte es
doch mit ein paar Adressdekodern, Portbausteinen, Oszillatoren und RAMs
schon fast getan sein.
[cut]

Ich verwende gerne den DIMM-PC von Jumptec. Der ist so gross wie
Speicherriegel und alles drauf was du brauchst.

bye
Werner
 
Patrick Schaefer schrieb:
Sebastian Kraft schrieb:

Mhm... mal quatsch bei seite... geht das wirklich??
Also einfach Betriebsspannung/Takt anlegen??

Zu den 486ern fehlt mir noch die Erfahrung, es kann sein, daß hier die
Busrequest-Signale noch passend verschaltet und eventuell sogar ein
NOP-Befehl auf die Datenleitungen gelegt werden muß, damit der Proz
nicht in einen Energiesparmodus wechselt.
Update: 486SX25 ziehen mit 5V und 40MHz Takt dran schon gut 800mA pro
Stück. Reset auf Masse bringt ca 100mA mehr. Damit erreichen die Dinger
schon nach kurzer Zeit gute 70°C.


Patrick
 
Patrick Schaefer wrote:

Update: 486SX25 ziehen mit 5V und 40MHz Takt dran
Ähem. SX25 sind für 25MHz Takt spezifiziert. Wenn du die mit 40MHz
jagst, brauchst du dich über übermäßige Erwärmung wohl nicht wirklich
wundern.
 
Was bedeutet für dich jetzt "Genauigkeit"? Genauer sind Fließkommazahlen
natürlich nicht, aber sie haben einen ungleich größeren Wertebereich. Wenn
ich zwei 16-Bit-Zahlen multipliziere, muss die Ergebnisvariable mindestens
32-Bit groß sein. Aber dann ist auch schon Ende Gelände. Mehr schafft der
Prozessor dann nicht mehr.

Christian
Wieso, es muss ja nicht der Prozessor sein, wenn du zu Fuß große
Zahlen multiplizierts machst du es mit dem kleinen Ein X Eins und
schreibts es dir auf einem Blatt, das geht auch mit 8 Bitern. der C64
war ein 8 Biter ohne Fließkomma, konnte aber trotzdem REAL Zahlen
verrechnen, dazu braucht man keinen Co Proc, viele Taschenrechner mit
10 stelligen Display arbeiten mit ner 4 Bit CPU

Wo ist das Problem?

Weist du nicht wie es geht, da gibt es viele Seiten im Netz die einem
in Assembler zeigen wie man mit großen Zahlen rechnet, Alternative für
eine kommerzielle Geschichte ist es mit einem leistungsfähigen 8 oder
16 bitter und einem vernünftigen C Compiler der einem diese Arbeit
abnimmt.

In welcher Sprache programmierst du denn?

Gruß

Lutz
 
Heiko Nocon schrieb:
Patrick Schaefer wrote:

Update: 486SX25 ziehen mit 5V und 40MHz Takt dran

Ähem. SX25 sind für 25MHz Takt spezifiziert. Wenn du die mit 40MHz
jagst, brauchst du dich über übermäßige Erwärmung wohl nicht wirklich
wundern.
Die Idee war ja hier gerade, den Kaffee mit einigen alten Proz. warm zu
halten - ein High-Tech-Widerstand sozusagen :)

Martin
 
"Lutz" <lutz.kather@gmx.de> schrieb

Wieso, es muss ja nicht der Prozessor sein, wenn du zu Fuß große
Zahlen multiplizierts machst du es mit dem kleinen Ein X Eins und
schreibts es dir auf einem Blatt, das geht auch mit 8 Bitern.
Wie ich mit 64-Bit-Variablen hantiere, weiß ich. Ich möchte nur nicht zu
sehr von den Möglichkeiten des Prozessors abweichen. Noch kann ich den
Prozessor an das Problem anpassen und nicht den Code an den Prozessor. Das
wird auf Dauer in der Regel schlecht wartbar.

der C64
war ein 8 Biter ohne Fließkomma, konnte aber trotzdem REAL Zahlen
verrechnen, dazu braucht man keinen Co Proc
Fließkomma kann ich ja. Halt nur ohne FPU. Die Anwendungen, die auf dem
C64er Fließkommazahlen brauchten, hielten sich in Grenzen. Spiele und Intros
wurden eh komplett in Assembler geschrieben (gab's überhaupt einen
Hochsprachencompiler für den C64 -- von Basic einmal abgesehen?), so dass
man sich da richtig austoben konnte. Bei vielen Sachen (Sinus-Scrolling zum
Beispiel) brauchte man garkeine Fließkommaoperationen sondern hat mit
Tabellen garbeitet, die zuvor entweder vor dem Start oder weit vorher mit
dem Taschenrechner gefüllt wurden -- eben aus Geschwindigkeitsgründen.
Damals war man halt scharf drauf zu zeigen, was alles mit dem C64 geht.

Ich muss nicht zeigen, das ich auf 'nem ollen infineon C504 Turrican II ans
Laufen kriege.

Weist du nicht wie es geht, da gibt es viele Seiten im Netz die einem
in Assembler zeigen wie man mit großen Zahlen rechnet,
Bevor ich jetzt auch noch anfange, die Programmiersprache zu wechseln, mich
dort einarbeite und ein großes Maß an Code-Wartbarkeit verliere, nehme ich
doch lieber (so es einen gibt) einen schneller bzw. leistungsfähigeren
Prozessor.

Alternative für
eine kommerzielle Geschichte ist es mit einem leistungsfähigen 8 oder
16 bitter und einem vernünftigen C Compiler der einem diese Arbeit
abnimmt.
Ein Compiler kann mir den Prozosser schneller machen? Wohl kaum.
Wohlgemerkt: mein Problem ist nicht, dass ich nicht mit Fließkommazahlen
rechnen _kann_. Es dauert halt nur so lange. Der Code, der dazu erzeugt
werden muss, ist ohne FPU nicht ohne. Viel Code braucht lange zum
Abarbeiten.

In welcher Sprache programmierst du denn?
C. Compiler von Keil. Eigentlich optimiert der ganz ordentlich. Das
schwächste Glied bei Fließkommaoperationen ist aber wohl eher der Prozessor.

Gruß,

Christian
 
wurden eh komplett in Assembler geschrieben (gab's überhaupt einen
Hochsprachencompiler für den C64 -- von Basic einmal abgesehen?), so dass
Ich hatte nen Pascal-Compiler für den C64, aber der zählt nicht wirklich,
denn er hat bloß P-Code produziert.
In einem 64er-Heft gab es aber mal nen TunyBasic-Compiler, der konnte ein
ganz einfaches Basic programmieren, den habe ich damals noch als HEX-Code
von 12 Seiten oder so abgetippt.

Sabine
 
"Sabine Wolf" <sabine.f.wolf@web.de> schrieb:

In einem 64er-Heft gab es aber mal nen TunyBasic-Compiler, der konnte ein
ganz einfaches Basic programmieren, den habe ich damals noch als HEX-Code
von 12 Seiten oder so abgetippt.
MSE 1.0 oder 2.1? :)

Gruß,

Christian
 
Christian Gudrian wrote:
(gab's überhaupt einen
Hochsprachencompiler für den C64 -- von Basic einmal abgesehen?)
Einen? Lies mal

http://www.npsnet.com/danf/cbm/languages.html

Gruß,
Michael
 
"Michael J. Schülke" <news0310@mjschuelke.de> schrieb:

Einen? Lies mal

http://www.npsnet.com/danf/cbm/languages.html
Öööhhm, heißt das jetzt ja oder nein?

Gruß,

Christian
 

Welcome to EDABoard.com

Sponsor

Back
Top