Bild siehe hier:
http://www.ebay.de/itm/200992950158?ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1423.l2649
Evtl. hat wer noch solche Karte(n)?
Peter
Bild siehe hier:
http://www.ebay.de/itm/200992950158?ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1423.l2649
Evtl. hat wer noch solche Karte(n)?
Peter
Ich muesste noch ein paar davon im Keller haben. Bin letzthin darüber gestolpert. Ich guck die Tage mal nach und geb dir Bescheid.
@Gandalph: Prima!
Peter
Suche noch..
Ideal V1 oder V2
V3 könnte evtl. auch noch gehen.
V4 geht nicht (PCI).
Peter
Heute bei Heise gelesen dass AVM die Serie abgekündigt hat. Und dass ein Transputer drauf ist Bin gespannt was du mit dem Transputer vor hast
Bin gespannt was du mit dem Transputer vor hast
schau mal hier, da wirst Du her rausbekommen was er vorhat
http://www.mikrocontroller.net/topic/316479
und als Verweis
http://www.geekdot.com/avm-b1.html
So, ich ward fündig im Regal des Todes... Aber sind leider alles PCI-KArten Dafür zum teil noch OVP Aber bei einem Transputer-Wunsch wird das auch nicht weiter helfen
Suche noch..
Gerade gesehen (müste It. Bild ISA sein, allerdings steht nicht dabei ob V1, V2 oder V3):
http://www.ebay.de/sch/m.html?_odkw=AVM&_osacat=0&_from=R40&_armrs=1&_ssn=bettina-b66&_trksid=p2046732.m570.l1313.TR0.TRC0.H0.XAVM+ISDN+B1&_nkw=AVM+ISDN+B1&_sacat=0
Wg. dem ideelen Wert kann ich meine Transputerboards leider nicht rausrücken
- die erste dürfte die erste Transputerkarte weltweit sein, bei der dem Transputer 4MB zur Verfügung standen
- die zweite ist mein erstes "Baby" - Anekdote am Rand: der Praktikant, der die Karte gelayoutet hat, hat feucht fröhlich, wie er es von den SRAMs gewohnt war, nach seinen Layoutbedürfnissen die Adressleitungen getauscht => und deshalb hab' ich in der Fa. den CAS before RAS Refresh eingeführt!
Werd' mal Anfang nächster Woche bei der Fa. hema vorbei schauen, ob die nicht noch eine TR1SMD-Karte rumfahren haben.
Hi. AVM B1 V2 ISA Karten habe ich inzwischen 5-6 Stk.
V1 wäre noch interessant oder T1(-B)
Peter
Hi. AVM B1 V2 ISA Karten habe ich inzwischen 5-6 Stk.
V1 wäre noch interessant oder T1(-B)
Und so 'ne TR1SMD der Fa. hema (zweites Bild) wäre nicht von Interesse, falls noch vorhanden (wobei ich nicht weiß, ob's die für lau gäbe)?
Solange sich die wie eine B00x ansprechen lassen und (fast) für lau.. immer.
Peter
Solange sich die wie eine B00x ansprechen lassen
Die TR1SMD (zweites Bild) ist die Nachfolge-Platine der TEK 4/8 (erstes Bild) und damit B00x kompatibel.
Nach dem ich Deinen Thread entdeckt habe, bin ich gleich wieder ein wenig ins Transputer-Fieber gefallen
Das Projekt, bei dem ich Assembler intensiv für die inneren Schleifen verwendet habe, fide ich aber partout nicht mehr (unglaublich - ich kann ganze Projekte verlieren ).
Hab' lediglich ein Stück Code gefunden, mit dem ich einem Kunden bei seinem Geschwindigkeitsproblem geholfen habe - dann kannste mal sehen , auf was Du Dich einläßt:
Sehr geehrter Herr ,
der MOVE2D Befehl ist zwar als Maschinen-Befehl im T800 vorhanden,
trotzdem benötigt er in etwa die von Ihnen berechnete Anzahl an
Takten, um ein Byte vom Framegrabber-Speicher zum Videospeicher zu
kopieren. Der Grund für die geringe Transferrate ist mit den
ungünstigen Randbedingungen zu begründen. Wir packen bei einer
Auflösung von 512*512 eine Spalte eines Arrays von [512][4]BYTE
in ein Array von [512][1]BYTE, d.h. wir setzen den Befehl MOVE2D
auf ein zweidimensionales Array mit 512 Zeilen an, bei dem jede
Zeile nur ein Word enthält. Der MOVE2D-Befehl jedoch benötigt
(2p+23)*r Takte (p = number of words per row, r = number of rows),
d.h. der Overhead der Zeilenverwaltung ist auf nur einen Byte-
Transfer "verteilt". Der Speicher auf der TG300-Grafigkarte und auf
dem TF9502-Framegrabber wird mit einem Waitstate (200ns pro Zyklus)
betrieben - er ist also nicht verantwortlich für die geringe
Transferleistung in diesem Fall.
Trotz der vielen Takte, die der MOVE2D beim "Packen" pro Byte
benötigt, ist er schneller als jede in OCCAM programmierte
Schleife. Lediglich eine von mir am Wochenende geschriebene
Assemblerroutine ist, nur für den Kanal 0 ein wenig schneller als
der MOVE2D-Befehl, falls sich der Code und der Workspace der
Routine komplett im internen Memory befinden.
Allerdings läßt sich diese Routine für Ihre Anwendung so
modifizieren, daß sie das Binärbild erstellt und gegenüber dem
reinen MOVE2D nur um 40 - 50 % langsamer ist.
Der Prozedur müssen Sie eine Look up Table übergeben, mit deren
Hilfe jedem Pixelwert ein beliebig anderer Pixelwert zugewiesen
werden kann.
Die Konstante "resolution" in der Fold "... VALs" legt fest,
ob Sie mit hoher oder niedriger Auflösung arbeiten. Sie darf
nicht in eine Variable umgewandelt oder über den Prozedurkopf
übergeben werden.
übersetzen Sie die Prozedur mit dem Compilerparameter
code.inserts IS RESTRICTED:
PROC pack.wlut.image ([][]BYTE target, VAL [#100]INT wlut,
VAL INT ch, nx, ny, sx, sy, tx, ty )
--{{{ USEs
#USE "portlib.tsr"
--}}}
--{{{ HINTs
-- the procedure packs the contents of the framegrabber memory
-- to a image, where every pixel is translated by a look up table (lut).
-- the procedure is written in assembler.
-- the code and the workspace of the procedure should be located in the
-- internal ram.
-- !!! the procedure checks no parameters !!!
--{{{ parameters of the procedure:
-- [][]BYTE target: array for the packed image (for example the video ram)
-- [#100]INT wlut : array of 256 words for the translation of the pixels -
-- every value must be in the range of 0 to 255
-- the wlut should be placed in the internal ram.
-- VAL INT ch : selected channel ( 0 | 1 | 2 )
-- VAL INT nx : x-resolution of the image, the value must be a
-- multiple of 4 and may not be greater than max **
-- VAL INT ny : y-resolution of the image, the value must be a
-- multiple of 4 and may not be greater than max **
-- VAL INT sx : start-x-koordinate of [512][512]INT source, the value must
-- be a multiple of 4
-- VAL INT sy : start-y-koordinate of [512][512]INT source, the value must
-- be a multiple of 4
-- VAL INT tx : start-x-koordinate of [][]BYTE target, the value must
-- be a multiple of 4
-- VAL INT ty : start-y-koordinate of [][]BYTE target, the value must
-- be a multiple of 4
-- ** max is 256 for low resolution and 512 for high resolution
-- (see also: ... VALs)
--}}}
--}}}
--{{{ PORTs
[512][512]INT source:
PLACE source AT p.fgram:
--}}}
--{{{ VALs
VAL low IS 0:
VAL high IS 1:
VAL resolution IS low: -- low | high
-- high resolution uses all pixels of the framegrabber memory to build
-- the image.
-- low resolution uses only every second pixel and every second row
-- of the franegrabber memory for building the image, so only a quarter
-- of the pixel in the framegrabber memory is used.
VAL dh IS [8, 4][resolution]:
VAL dv IS [(((SIZE source[0]) * 4) * 2), ((SIZE source[0]) * 4)][resolution]:
--}}}
--{{{ VARs
INT svp, tvp, uvp:
INT shp, thp, uhp:
INT int:
--}}}
SEQ
--{{{ init
--{{{ svp := pointer(source[sy][sx])
GUY
LDC (SIZE source[0])
LDL sy
PROD
LDL sx
ADD
LDNLP source
WSUB
STL svp
--}}}
--{{{ tvp := pointer(target[ty][tx])
GUY
LDL (SIZE target[0])
LDL ty
PROD
LDL tx
ADD
LDLP target
BSUB
STL tvp
--}}}
--{{{ uvp := tvp PLUS (ny TIMES (SIZE target[0]))
GUY
LDL (SIZE target[0])
LDL ny
PROD
ADC (-1)
LDL tvp
BSUB
STL uvp
--}}}
--{{{ svp := svp PLUS ch
GUY
LDL ch
LDL svp
BSUB
STL svp
--}}}
--}}}
--{{{ oloop
GUY
:oloop
--{{{ init
--{{{ shp := svp
LDL svp
STL shp
--}}}
--{{{ thp := tvp
LDL tvp
STL thp
--}}}
--{{{ uhp := thp PLUS nx
LDL nx
ADC (-1)
LDL thp
BSUB
STL uhp
--}}}
--}}}
--{{{ iloop
:iloop
--{{{ int := lut[(INT source.1dim[shp])]
LDL shp
LB
LDLP wlut -- for lut
WSUB -- for lut
LDNL 0 -- for lut
STL int
--}}}
--{{{ int := int \/ (lut[(INT source.1dim[shp])] >> 8)
LDL shp
ADC dh
LB
LDLP wlut -- for lut
WSUB -- for lut
LDNL 0 -- for lut
LDLP int
ADC 1
SB
--}}}
--{{{ int := int \/ (lut[(INT source.1dim[shp])] >> 16)
LDL shp
ADC (dh * 2)
LB
LDLP wlut -- for lut
WSUB -- for lut
LDNL 0 -- for lut
LDLP int
ADC 2
SB
--}}}
--{{{ int := int \/ (lut[(INT source.1dim[shp])] >> 24)
LDL shp
ADC (dh * 3)
LB
LDLP wlut -- for lut
WSUB -- for lut
LDNL 0 -- for lut
LDLP int
ADC 3
SB
--}}}
--{{{ target.1dim[thp] := int
LDL int
LDL thp
STNL 0
--}}}
--{{{ increment thp --> thp := thp PLUS 4
LDL thp
ADC 4
STL thp
--}}}
--{{{ increment shp --> shp := shp PLUS (dh * 4)
LDL shp
ADC dh * 4
STL shp
--}}}
--{{{ repeat iloop until (thp > uhp)
LDL thp
LDL uhp
GT
CJ .iloop
--}}}
--}}}
--{{{ increment svp --> svp := svp PLUS dv
LDC dv
LDL svp
BSUB
STL svp
--}}}
--{{{ increment tvp --> tvp := tvp PLUS (SIZE target[0])
LDL (SIZE target[0])
LDL tvp
BSUB
STL tvp
--}}}
--{{{ repeat oloop until (tvp > uvp)
LDL tvp
LDL uvp
GT
CJ .oloop
--}}}
--}}}
:
Alles anzeigen
"--{{{" und "--}}}" sind übrigens Fold-Informationen, so dass das Codestück am besten mit Origami.exe in einer DOS-Box betrachtet werden sollte (falls nicht vorhanden, PM mit e-mail-adr an mich).
Alternativ läßt sich auch jedit mit dem ConfigurableFoldHandler plugin oder SciTE verwenden,
wenn entsprechend konfiguriert.
Jedit und SciTE kann ich übrigens allen empfehlen, die wie ich Code Folding schätzen, sich aber an einem "syntax based code folding" stören - beide (SciTE nur für einige Programmiersprachen) können so konfiguriert werden, dass jedwedes syntax based code folding abgeschaltet ist und nur die selbst eingefügten "fold marks" ausgewertet werden ("explicit code folding").
Meine SciTEGlobal.properties Datei:
#Tabs & Indent
use.tabs=0
tabsize=2
indent.size=2
indent.automatic=0
# Folding
# enable folding, and show lines below when collapsed.
fold=1
fold.compact=0
fold.flags=16
fold.symbols=1
fold.on.open=1
fold.comment=1
fold.preprocessor=0
fold.asm.syntax.based=0
#fold.asm.comment.multiline=1
fold.asm.comment.explicit=1
fold.asm.explicit.start=;[
fold.asm.explicit.end=;]
fold.cpp.syntax.based=0
fold.cpp.comment.multiline=0
#fold.cpp.comment.explicit=0
fold.cpp.explicit.start=//[
fold.cpp.explicit.end=//]
fold.basic.syntax.based=0
fold.basic.comment.explicit=1
fold.basic.explicit.start='[
fold.basic.explicit.end=']
file.patterns.freebasic=*.bas;*.bi;*.tig
# COMMENT Directive multiline comment
style.asm.15=fore:#77CC00
#ln
source.files=*.asm;*.c;*.cc;*.cpp;*.cxx;*.cs;*.d;*.h;*.hh;*.hxx;*.hpp;\
*.idl;*.odl;*.rc;*.rc2;*.dlg;*.def;\
*.vb;*.vbs;*.bas;*.tig;*.frm;*.cls;*.ctl;\
*.java;*.js;*.py;*.pl;*.rb;*.cgi;*.lua;*.conf;\
make*;*.mak;\
*.properties;*.html;*.xml;*.iface;*.bat;*.e
font.base=$(font.monospace)
font.small=$(font.monospace)
font.comment=$(font.monospace)
font.code.comment.box=$(font.comment)
font.code.comment.line=$(font.comment)
font.code.comment.doc=$(font.comment)
font.code.comment.nested=$(font.comment)
font.text=$(font.monospace)
font.text=$(font.monospace)
font.embedded.base=$(font.monospace)
font.embedded.comment=$(font.monospace)
font.monospace=font:Courier New,size:10
font.vbs=$(font.monospace)
Alles anzeigen
Wie zu sehen ist, verwende ich "//[" und "//]" statt "//{" und "//}" als Foldmarken, so daß beim Auskommentieren
von Code Zeilen nicht aus versehen Foldmarken entstehen.
Hi Peter,
war vorhin bei der Fa. hema und hab' eine TR1SMD mit T800 und 3MB Speicher erhalten. Da die Karte ewig nicht mehr im Einsatz war, muss man damit rechnen, dass sie erst wieder funktionsfähig gemacht werden muss - insbesondere bei den Fenster-PALs könnte ich mir vorstellen, dass die nicht ihren kompletten Inhalt erhalten haben. Melde Dich deshalb bei mir, falls es Probleme mit der Karte gibt - die PAL-Sourcen und JEDEC-Files werden sich gegebenenfalls in meinen Backups finden.
Brauch' dann Deine Adresse per PM, um die TR1SMD wegschicken zu können.