Infos sur la Vampire (suite)
-
@Sébastien : je n’ai pas essayé avec des électrochimiques, mais celui-ci de chez Kemet me parait pas mal : ESY476M025AC3EA
Après j’ai d’autres références, mais il faut savoir souder les CMS.
Sylvain aka goodchip
Merci goodchip
Bon j’ai résolu mes problèmes avec l’émulateur mac
Tout marche du feu de dieu avec le core 2.7 x11 et R48 sur ma v500
reste plus les fameux condo pour voir avec le x12
Amiga 1200 -blizzard 68060@50mhz-Mediator+Voodoo 3 +64Mo+ SB128 + fastIDE +Spider usb et indivision Mk2.
MAC G4 (morphos)
Amiga 1200 Blizzard ppc 333mhz et 68060@50mhz (en panne)
Amiga 500+512ko en chipRam (En panne)
Amiga 2000 ks 1,3 / 3.1 68030 16 Mo
Rasperry Pi 3 et 4
Vampire V2 et V4
Amstrad 6128
@Sébastien, puisque tu as trouvé la solution, partage sur le forum, ça pourrait toujours servir à quelqu’un 😉
A500+ACA500 - A600+Vampire 2+indivision ECS - A1200+Vampire V2 1200 - Mac Mini 1.42 sous MOS - Just CPC 128k - CPC 6128 - Atari STE 4Mo/CosmosEx - Atari Falcon CT60/SuperVidel 🙂
C64C + 1541-II + Lecteur K7 + SD - Sharp X68000 CZ-601C 4Mo + CF - Sharp X68000 CZ-611C 10Mo + CF + ext. MIDI
Ca fait le mac 68k le plus rapide c’est ca?
Amiga 2000 en attente de Vampire V4
Amiga 1230
Atari 520/1040 STF/E et mega STE
Amstrad cpc 464/6128/6128+
TO8 / C64 / V20 / lazer / Alice 90 / Oric Après relecture de mes posts, je tiens à préciser que le mod de condensateur n’est absolument pas systématique, c’est même tout le contraire (quasiment toutes les cartes acceptent le x11).
Bref, pas besoin de prendre des risques inutiles à vos Vampires qui fonctionnent surement parfaitement bien 😉
Après pour le x12, peut-être que moins de cartes l’accepterons, mais il faut considérer cela comme un bonus.
Pour ma part, je n’ai pas modifié ma V500 dans le but qu’elle accepte le x12, elle fonctionnait avec de manière stable et sans la modification. J’ai uniquement fait ceci dans un but d’expérimentation et afin d’offrir un retour à la team sur une carte lambda (la mienne) en faisant des mesures à l’oscilloscope avant et après modifications.
Je pense qu’il était nécessaire que j’apporte ces précisions 🙂
Sylvain aka goodchip
@hugg
Simple j’ai juste utilisé la version précédent (R43) pour l’émulation mac
@marcel
je sais pas si ça fait le mac 68k le plus rapide mais en tout cas nickel super réactif
@Goodchip : je suis dans la même optique que toi et le X11 me vz très bien mais j’aime bien aussi les expérimentations et comprendre le pkAmiga 1200 -blizzard 68060@50mhz-Mediator+Voodoo 3 +64Mo+ SB128 + fastIDE +Spider usb et indivision Mk2.
MAC G4 (morphos)
Amiga 1200 Blizzard ppc 333mhz et 68060@50mhz (en panne)
Amiga 500+512ko en chipRam (En panne)
Amiga 2000 ks 1,3 / 3.1 68030 16 Mo
Rasperry Pi 3 et 4
Vampire V2 et V4
Amstrad 6128
@ <span style=”font-size: 16px;”>huggyone76, </span>Discor, TameBest
dsl c’est un peu hors topic mais concernant le XRGB-mini,
– ça prend tout ce qui sort sur peritel (avec l’adaptateur européen), atari ST, STE, Falcon, Amiga etc ?
Les tests sont surtout orientés consoles.
Oui oui, tout ce qui a une peritel (et pas que, composite, RGB, Svideo) pour te ressortir tout ca en HDMI, et avec de très chouettes scanlines, sans input lag.
Les consoles (et les micro japonais genre X68000) ont des presets tout fait mais on peut en importer pleins d autre via une carte Sd ou bien les faire soit même a sa convenance.
J’utilise mon 1200 avec une indivision mais mon 500 fonctionne à merveille sur le XRGB mini
*fin de digression sur le fil vampire* 🙂
@MarcelPentium : déjà avec une blizzard 1260, Shapeshifter etait le Mac 68k le plus rapide du monde puisque le mac sest arrêté au 68040.
Je n’ose imaginer combien une vampire avec Shepashifter éclate le mac le plus rapide.
RyZen Rulez 😉
Mod Je me demandais quelle somme de travail serait nécessaire pour passer d’un FPGA à une implémentation ASIC. Il apparait que ce n’est pas une tâche triviale du tout. Je cite :
Typically ASIC design is a team endeavor due to the complexity and quantity of work. I’ll give a rough order of steps, though some steps can be completed in parallel or out of order. I will list tools that I have used for each task, but it will not be encyclopedic.
1. Build a cell library. (Alternatively, most processes have gate libraries that are commercially available. I would recommend this unless you know you need something that is not available.) This involves designing multiple drive strength gates for as many logic functions as needed, designing pad drivers/receivers, and any macros such as an array multiplier or memory. Once the schematic for each cell is designed and verified, the physical layout must be designed. I have used Cadence Virtuoso for this process, along with analog circuit simulators such as Spectre and HSPICE.
2. Characterize the cell library. (If you have a third party gate library, this is usually done for you.) Each cell in your library must be simulated to generate timing tables for Static Timing Analysis (STA). This involves taking the finished cell, extracting the layout parasitics using Assura, Diva, or Calibre, and simulating the circuit under varying input conditions and output loads. This builds a timing model for each gate that is compatible with your STA package. The timing models are usually in the Liberty file format. I have used Silicon Smart and Liberty-NCX to simulate all needed conditions. Keep in mind that you will probably need timing models at “worst case”, “nominal”, and “best case” for most software to work properly.
3. Synthesize your design. I don’t have experience with high level compilers, but at the end of the day the compiler or compiler chain must take your high level design and generate a gate-level netlist. The synthesis result is the first peek you get at theoretical system performance, and where drive strength issues are first addressed. I have used Design Compiler for RTL code.
4. Place and Route your design. This takes the gate-level netlist from the synthesizer and turns it into a physical design. Ideally this generates a pad-to-pad layout that is ready for fabrication. It is really easy to set your P&R software to automatically make thousands of DRC errors, so not all fun and games in this step either. Most software will manage drive strength issues and generate clock trees as directed. Some software packages include Astro, IC Compiler, Silicon Encounter, and Silicon Ensemble. The end result from place and route is the final netlist, the final layout, and the extracted layout parasitics.
5. Post-Layout Static Timing Analysis. The goal here is to verify that your design meets your timing specification, and doesn’t have any setup, hold, or gating issues. If your design requirements are tight, you may end up spending a lot of time here fixing errors and updating the fixes in your P&R tool. The final STA tool we used was PrimeTime.
6. Physical verification of the Layout. Once a layout has been generated by the P&R tool, you need to verify that the design meets the process design rules (Design Rule Check / DRC) and that the layout matches the schematic (Layout versus Schematic / LVS). These steps should be followed to ensure that the layout is wired correctly and is manufacturable. Again, some physical verification tools are Assura, Diva, or Calibre.
7.Simulation of the final design. Depending on complexity, you may be able to do a transistor-level simulation using Spectre or HSPICE, a “fast spice” simulation using HSIM, or a completely digital simulation using ModelSim or VCS. You should be able to generate a simulation with realistic delays with the help of your STA or P&R tool.
Starting with an existing gate library is a huge time saver, as well as using any macros that benefit your design, such as memory, a microcontroller, or alternative processing blocks. Managing design complexity is a big part as well – a single clock design will be easier to verify than circuit with multiple clock domains.
Il y a d’ailleurs des sociétés spécialisées pour faire cette conversion.
Les avantages de l’ASIC sont nombreux : vitesse bien plus élevée, consommation très réduite, taille bien plus faible…
Prédateur Chess | Amiga 500 + ACA500 | Amiga 1200 + ACA1233
@Jul: les etapes que tu decris sont celles pour un projet partant de 0. Ici on part d’un design fonctionnant deja sur fpga donc en gros tu as deja les etapes 1 à 5 de faites (ça fait deja du taf n’est-ce pas !). Et il faut aussi savoir qu’il existe plusieurs types d’asics. Certains sont completement vierges et offre le plus de libertées mais il faut tout faire / tout maitriser. Mais dans un premier temps, il y a aussi une solution intermediaire. Les fabricants de fpga proposent depuis longtemps des ASICS contenants les memes ressources que leurs fpga, sur lequels ont vient “imprimmer” seulement la/les derniere(s) couches pour faire la connexion entre les elements. On y gagne deja beaucoup en performances et surtout ça demande beaucoup moins d’effort de design puisque l’architecture aura deja pu être testée sur fpga….
A600 + 604n + RTC + Vampire V2 600, Coffin R54 / wb3.1.4.1
A1200 + Vampire V2 1200, wb3.1.4.1
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Matériel › Infos sur la Vampire (suite)