link

A skąd wyczarować Identify.library wymaganą docpu-a nie mogę zajść na aminecie ?

A w Wampire 68080 nie ma? Ostatnia aktualizacja: 14.02.2025 17:47:16 przez amikoksu

A są tam stosowne czujniki?

Temperaturę też podaje?

Auto "przeniósł" rozwój projektu z GitHub na Codeberg (https://codeberg.org/shred/Identify).

Najnowsza jest 44.1 ze stycznia 2024 https://github.com/shred/Identify/releases

U mnie z wyświetlaniem danych grafiki nie było problemu w tamtej wersji: W wymaganiach dodałbym jeszcze, że program wymaga Identify.library nowszego niż v 8.2, ponieważ gdy próbowałem użyć tej 8.2, to program wołał o inną wersję. Po wgraniu wersji 44.1 uruchamia się. Nie znam się na numeracji wersji tej biblioteki, ale z 8.2 na 44.1 to spory przeskok :)

To najwieksay ból amigowego softu, ze prawie nikt nie publikuje źródeł. Ale akurat Identify.libraray jest opensource, jak ktoś się czuje na siłach może dodać identyfikację kart G4 etc. https://github.com/shred/Identify Poza tym wydaje mi się że właśnie spora ilość źródeł różnego softu do amigi jest dostępna na githubie, albo nawet często załączone wraz z programem na Aminecie lub jako oddzielna paczka. Ostatnia aktualizacja: 15.11.2024 08:51:42 przez Rafael/ARMO

Obecnie identifiy rozpoznaje następujące PowerPC #define IDPPC_NONE (0) /* No PowerPC implemented */ #define IDPPC_OTHER (1) /* Another PowerPC */ #define IDPPC_602 (2) /* 602 */ #define IDPPC_603 (3) /* 603 */ #define IDPPC_603E (4) /* 603e */ #define IDPPC_603P (5) /* 603p */ #define IDPPC_604 (6) /* 604 */ #define IDPPC_604E (7) /* 604e */ #define IDPPC_620 (8) /* 620 */ Więc G4 jest traktowane jako "OTHER". Trzeba pisać do autora .. może doda. https://github.com/shred/Identify/blob/master/report-missing-boards.md

- Potwierdzam w sekcji Graphics jest podana tera i ilość i zajętość i procent VRAMu. - Tak, wyświetlanie informacji o PowerPC teraz już nie powoduje wyrzucania błędu, aczkolwiek na tą chwilę z informacji o G4 które siedzi w karcie Apocalipse została odczytana tylko informacja CoreSpeed, czyli "zegar", pozostałe pola są nierozpoznane/puste, czyli, że mojego CPU nie ma w bazie biblioteki Identify.library?

U mnie niestety nie działa. Mam Identify, MUI 3.8, os3.2 Ostatnia aktualizacja: 12.11.2024 20:36:40 przez sand

Przydałaby się informacja o rewizji 68060, jeśli takowy jest wykryty. Jeśli Identify tego nie pokazuje, to warto dodatkowo sprawdzić rejestr PCR procesora i wyświetlić info w nim zawarte. No po prostu nie wypada żeby pogram z CPU w nazwie nie wyświetlił tak ważnej informacji Myślę, że jeśli Identify tego nie pokazuje, to warto bardziej zrobić PR z taką zmianą do Identify.library, tak żeby wszyscy korzystający z tej biblioteki zyskali. Ogólnie Identify zwraca rewizję, jak jest to pokazuje ją CPU-A.

Przydałaby się informacja o rewizji 68060, jeśli takowy jest wykryty. Jeśli Identify tego nie pokazuje, to warto dodatkowo sprawdzić rejestr PCR procesora i wyświetlić info w nim zawarte. No po prostu nie wypada żeby pogram z CPU w nazwie nie wyświetlił tak ważnej informacji ;-) A odczyt PCR pokazał choćby RomanWorkshop http://romanworkshop.blutu.pl/asm68/chk060.htm A ogólnie to ciekawy pomysł na program, jeśli będzie na MUI 3.8, będzie używany :thumbsup:

Rzeczywiście ciekawe, że powstały równocześnie :) ALB42 jest fanem Pascala, więc jego aplikacja jest napisana w tym języka i korzysta z jego wrapperów na MUI. Jego aplikacja wyświetla wszystko co daje Identify, ja tylko część parametrów. Ja wzorowałem się na CPU-Z/X i taki ma wygląd moja apka, a jego aplikacja po prostu służy do przeglądnięcia całej listy z pełna informacją o każdej z nich. Ja tylko dla części wyciągałem pełniejsze info. Pod tym względem jego pokazuje więcej, ale ja nie miałem takiego zamiaru. Niemniej w CPU-A zbieram dodatkowo informacje z Picasso96 (planuje też pobierać info z CyberGraphX). Dodałem wyświetlanie informacji "encyklopedycznych" o procesorach takie jak data premiery, technologia wykonania, TDP, napięcie rdzenia etc (choć nie wszystkie jeszcze w pełni zweryfikowane).

W ramach oderwania się od moich "dużych" projektów, zabrałem się za coś szybkiego do implementacji. I tak w około tydzień powstała aplikacja o CPU-A. Nazwa pewnie dla części brzmi znajomo, bo wzorowałem się na aplikacji CPU-Z z Windows i CPU-X z Linuxa. Jest to tool MUI który na bazie Identify.library, Picasso96 i jeszcze kilku danych zapisanych wewnętrznie pokazuje informację o aktualnej konfiguracji sprzętu. Tak w sumie CPU-A to pełny przykład wykorzystania moich wrapperów C++ na MUI jak i na sam AmigaOS do stworzenia całej aplikacji (od A do Z). Pełne źródła aplikacji i screeny są tutaj: https://github.com/tdolphin-org/CPU-A Apkę można na razie sciągnąć stad: https://github.com/tdolphin-org/CPU-A/releases CPA-A obecnie cały czas jest w stanie WIP (work in progress), ale większość funkcjonalnośći już działa. Finalna wersja powędruje na Aminet.

Jeszcze mi się kojarzy, że w bibliotece Identify.library dochodzą co chwile nowe sprzęty. Może to to?

Dostępna jest wersja 44.1 z poprawkami błędów.

http://aminet.net/search?readme=%22Identify.library%22

Czy jest gdzieś lista programów, które korzystają z tej biblioteki?

moje propozycje: AmiSSLIBrowse 3.xHippo PlayerAmigaGPTvasmAmiAuthenticatorP96Identify.library 42.xAWeb 3.5.091 z obsługą SSL i coś do cross kompilacji, ale nie wiedziałem gdzie to umieścić?: bebbo/amiga-gcc (miał sporo aktualizacji w repozytorium w 2023)

Chyba panowie (i panie) nie oglądali "Back To The Future" :mrgreen: Więc wystarczy cierpliwe poczekać na te "prawilne AAA" :lol:

Może czegoś nie wiemy :-D

Oraz w jakim modelu biblioteka ta wykryje chipset AAA :-D

Ciekawe, jak autor przetestował wykrywanie chipsetu AAA…

Też coś odpalałem i program tego wymagał... Już wiem. dynamite klon bombermena online

No ale ja instalowałem do czegoś innego niż w newsie.

przecież w newsie jest napisane do czego to służy, to taka baza urządzeń

Ktoś wie do czego to potrzebne? Ja raz instalowałem, nie pamiętam do czego (gra RTG jakaś chyba).

a tym razem email od Gunnara Warning for recent sales of unlicensed Vampire V2 Series accelerators! Apollo Computer Press Release, Tuesday 22th July 2022, We regret to inform our community that negotiations with Igor Majstorovic (former Apollo-Team member) were not successful. Unfortunately, Igor Majstorovic broke existing contracts, stopped paying licence fees, refused to communicate with the Apollo-Team and published parts of old conversations out of context. This neither clears anything, nor helps to revive the Amiga. Therefore, we want to clarify some important facts: Background Info: When Igor Majstorovic joined the Apollo-Team in 2013, he had a barly functional TG68 core used with his PCB board design, and asked the Apollo-Team for help. The 68080 CPU had already been developed by the Apollo-Team/Natami-Team. As it was a significant improvement over TG68, it made sense to use it instead. This required significant changes to the 68080 core. Gunnar von Boehn (teamleader of Apollo-Team) had to both decrease the space required by the core as well as make other functional changes to make this a reality for the Cyclone III FPGA used on Igor's boards. So,there is no question Vampire V1+V2 cards benefit from the previous development, expertise and willingness of the Apollo-Team to support these boards. Since the 68080 CPU core and the SAGA chipset have always been the intellectual property of Gunnar von Boehn, during his time with the Apollo-Team Igor Majstorovic was a licensee of the CPU and Chipset. After Igor Majstorovic left the Apollo-Team in Q2 2021,he violated the agreement with Apollo-Team and sold a significant number of unlicensed cards. What's the problem? Resellers and end customers bought the cards in good faith believing that the core was officially licensed and legal. When asked by resellers, Igor Majstorovic also claimed the cards would be legally licensed. Customers/Resellers who bought these cards must now take action, as the unlicensed cards cannot be updated to new core releases since cores starting with version 2.16, slated for release later this year, will not work on the non-licenced cards. Everyone should be aware that the bugfixes and releases are provided by the Apollo-Team. Igor Majstorovicdoes not support any core maintenance. What’s the Solution? 1. For customers who bought the V2 before Igor left the team: ==> Don’t worry, you will be able to update to any future cores without any issue. 2. For customers who bought the V2 in the last year: ==> Please get in touch with your reseller to check if your card is licensed. If it is not not, we will try to find a solution all together. We are in close contact with the resellers and want to help the customers and the resellers to resolve this situation. 3. For customers wanting to buy a V2 in future: ==> Apollo-Team is working together with Resellers to develop an official Apollo-Core license Sticker. Customers will then be able to Identify licensed cards in future. Apollo Computer and all its Team members apologize for the inconvenience caused to resellers, customers, and friends by the events of the past few days. Our goal is to find solution for everybody. Please do not hesitate to contact us with questions or concerns. With sincere greetings from the whole Apollo-Team, Miri and Gunnar P.S. to V4 customers: No worries! Not only do you have the most advanced Apollo Core based cards, they are also licensed. They are not affected by this situation! Ostatnia aktualizacja: 23.07.2022 18:06:41 przez juen

External Drive (DF1-DF3) Replacing an external drive depends on the enclosure or cable being used. Amiga external drive enclosures usually include the circuitry to allow the Amiga to Identify the presence of the drive. In this case the Gotek with S0 jumper is usually a straight swap for the old floppy drive. If using a passive cable such as this Ebay item then be aware that this identification circuitry is missing, but for arcane reasons identification will typically happen to work as long as the Gotek has an image mounted when the Amiga boots. If you are having problems with your drive being identified, see Forcing Drive Identification below. High-Density Disks Amiga Kickstart versions 2.05 and later support high-density disks with 1760kB formatted capacity. This enhancement required a customised (and nowadays expensive!) HD drive modified to rotate at half speed and emit a special ID sequence to the Amiga when an HD disk is inserted. FlashFloppy supports this enhancement for 1760kB ADF images, but the high-density ID sequence must be explicitly enabled in FF.CFG. If using an Amiga external drive enclosure, please bear in mind that the enclosure's interface board usually emits a fixed double-density ID sequence which will make HD images unreadable. In this case you must disconnect the enclosure's ID circuitry on its interface PCB: Cut the PCB connection to external connector, pin 1. Connect a jumper wire between internal connector pin 34 and external connector, pin 1. Forcing Drive Identification Amiga hosts expect a drive ID sequence from external and Amiga-high-density drives on pin 34 of the floppy interface when the drive motor is disabled (pin 34 carries the Ready/RDY signal when the drive motor is enabled). In contrast, FlashFloppy's default interface mode (interface = shugart) permanently attaches RDY to pin 34, regardless of motor. This default behaviour usually works fine: Drive ID signalling is not a strict requirement for DF0 External drive enclosures often implement the drive-ID circuitry A mounted disk image asserts RDY which happens to match the Amiga ID sequence for a DD drive anyway However, there are a couple of cases where this default behaviour may not suffice: Using high-density disk images (1760kB formatted capacity) Using as an external drive with a passive interface cable, if FlashFloppy does not assert RDY during boot (eg. eject-at-power-on, no USB stick, or too slow to initialise) In these cases FlashFloppy can be forced to emit the drive ID on pin 34 at all times, replacing RDY, by adding interface = amiga to FF.CFG. When HD images are not being used, and when FlashFloppy is being used as DF0 or without problems as DF1-DF3, then it is best to use the default interface type (interface = shugart) as this gives more accurate behaviour on pin 34 in normal use while the drive motor is enabled. Exact emulation of pin 34 behaviour is not possible on unmodified Gotek hardware as the motor signal is not connected to Gotek's microcontroller. More accurate support, for modified or enhanced Gotek setups, may be implemented in future. https://github.com/keirf/FlashFloppy/wiki/Host-Platforms#commodore-amiga

Więcej szczegółów (tutaj na stronie): Can it use KVM and would that make it faster? KVM is a virtualisation facility so it does not help emulating PPC on a different CPU (such as x86_64 or ARM). It can only be used on a PPC host to run PPC code. Moreover, on PPC it ideally uses virtualisation (hypervisor or HV) support which is only found in server or newer CPUs. On PPC besides this HV mode KVM also has a so called PR mode which works on CPUs without hardware support but this can only run non-privileged user code natively and still has to emulate all privileged instructions so it's slower than HV KVM but depending on usage it should still be much faster than emulating all instructions. QEMU can use KVM on PPC host but since PPC Linux is now more focused on PPC64 servers it's possible that older CPUs and KVM PR needs some fixes and mostly only works for BookS CPUs so supporting PPC440 virtualisation would need some work. What else can be done to improve this? Probably a lot of things depending on time and expertise available (both of which may be limited if only one person is working on this). Apart from profiling and trying to Identify and eliminate bottlenecks (as already mentioned above) I think the interesting possibilities are: experimenting with KVM on PPC hardware, trying pass-through of physical devices to virtual machine (e.g. using a Radeon GPU for graphics) and support paravirtualisation (virtio drivers) on guest OSes that could help disk and network speed or using QEMU's virtio-gpu to support 3D acceleration. For work in progress ideas I've created an open project at Project Qmiga to have a place where interested developers could join and cooperate to make this happen.

Hence, as far as the legal issues are concerned, "Os 3.1.4" is "Amiga Os 4". Przyjrzyj się dokładnie ugodzie. Zawiera ona dwie definicje. Definicję Amiga OS 4 i osobną dla OS 3.1. Są to definicje ściśle rozgraniczone dlatego, że są to dwa osobne byty, co do których strony przyznają sobie zupełnie inne prawa. Nie można rozciągać definicji OS4 na 3.1, bo w takim wypadku ta druga nie byłaby w ogóle w tym dokumencie potrzebna. To, co sugeruje ten gość, czyli że OS 3.1.4 to tak naprawdę OS4, kupy się nie trzyma. Dodanie numerka .4 nic tu nie zmienia, to co wydali, to materialnie JEST OS3.1 z poprawkami, a nie zupełnie nowy system na jego bazie, jak OS4, i na takie płytkie zagranie się żaden sąd nie nabierze. A prawnik Amiga Inc wylicza takie właśnie tanie zagrywki i punktuje je bezlitośnie w najnowszym piśmie. Trzeba przyznać, że Hyperion mocno namotał w tej ugodzie i czasem może się wydawać, że był taki sprytny, ale czy to na pewno dobrze? Może się okazać, że nie bardzo, bo w takim wypadku cała ugoda nadaje się do unieważnienia, skoro każda ze stron miała co innego na myśli przy jej zawieraniu, a być może jedna ze stron celowo wprowadziła drugą w błąd niejasnymi sformułowaniami. Hyperion po raz kolejny sam się wkopuje przez własne zuchwalstwo. The two definitions thus Identify completely separate operating systems: (a) AmigaOS 4, the operating system developed by Hyperion, which at the time the Settlement Agreement was a PowerPC-based operating system, not one compatible for use with original Amiga hardware; and (b) AmigaOS 3.1, the operating system created by Commodore Business Machines, which runs on original Amiga hardware, and not on the PowerPC. Ostatnia aktualizacja: 11.01.2019 18:12:27 przez jubi

Pierwszy raz słyszę, że Commodore malowało monitory. Z internetu (fora i takie tam): 31st October 2016, 09:31 #3 damiraga damiraga is offline damiraga's Avatar Join Date Apr 2008 Country Bosnia-Herzegovina & USA Posts 192 Feedback 25 (100%) DI have a black CDTV monitor (C1084S-D2) which was actually repainted in black (on the outside only) with beige front and back labels. This is how it was purchased as the labels and the bar code sticker clearly Identify it as a CDTV monitor. I guess with Commodore being known for reusing parts, they had some beige cases which they repainted in black and sold with CDTVs until proper production run produced completely black models. Another one I had (which I sold some 8 years ago), was completely black (outside and inside) with the black labels. Both were D2 variants. I have never seen a dark grey model. " Re: The Black Monitor Ť Reply #5 on: May 04, 2018, 12:16:45 PM ť My black 1084S is the same way! It seems it was painted that way in the factory as it also has the barcode Identifying it as the "black" model. It came with the CDTV Pro set (keyboard, FDD, mouse) which I bought second-hand from the original owner. " A i jeszcze: link Ostatnia aktualizacja: 05.01.2019 16:49:35 przez stachu100

Jakby Twój nick był zarejestrowany to dostaniesz info: -NickServ- This nickname is registered. Please choose a different nickname, or Identify via /msg NickServ Identify <password>. /msg Nickserv help - pomocne informacje. Nikt nie powinien mieć problemu z rejestracją. Poza tym serwery freenode dają z automatu +R każdemu niezarejestrowanemu userowi, więc nie ma co strzelać focha, tylko trzeba te swoje nicki porejestrować.

OK, złapałem faceta na FB, w kwestii problemów o których pisał Pong: Out of 60 A1200 membranes sold so far, I have had reports of about 6 where there is a minor break (almost like a cut) across the track. I emailed everyone to say that all recipients who had not yet fitted the membrane needed to check if their membrane suffered from this - and if so, I would send a replacement. The factory has been made aware and I am working my way through all remaining membranes to Identify those with the issue so that the factory can replace them. Obviously, now I know about the issue, I am checking all membranes before sending them out. So - if he has seen a cut (basically he will soon know once they are fitted as a key will not work!) then he just needs to let me know so I can send replacements! Czyli zasadniczo problem już nas nie dotyczy, bo chłop sprawdza przed wysyłką. W kwestii ceny: dogadałem się, że jak weźmiemy 10 sztuk, to zrobi cenę 15 funtów zamiast 18 - zawsze coś, bo wysyłka do Polski 16,50 funta, więc podzielone przez 10 jesteśmy i tak trochę do przodu :) Co do membran A600 to tutaj się tylko jeden kolega zgłosił, więc zniżki nie wyszarpałem. Podejrzewam że w przypadku membran do A500/+ będzie tak samo. Ja od siebie jakbym je miał rozsyłać to mam kuriera DHL za 15 zetków. Generalnie całość powinna się zamknąć w 90-100zł sztuka, zależnie od ilości zamówionej przez każdego z was. Tak więc może zróbmy tak, że wpisujcie mi albo na priwa, albo tutaj w postach poniżej ile i jakich tych membranek (A1200, A 600 - uwaga! do A600 są dwa rodzaje, zielona i niebieska!, A500/+) i będziemy działać. Poniżej wrzucam linki do opisów, żeby każdy mógł przeczytać, czy dobrze zamawia :) A1200: link A600 zielona: link A600 niebieska: link A500/A500+: link Czy mogę prosić moderatora o dodanie w tytule wątku "Zbiórka"? Ostatnia aktualizacja: 31.03.2017 21:52:56 przez ijon

I znowu coś: Link do zaktualizowanego archiwum : link Zmiany: -Dodano najnowszą spolszczoną icon.library 46.4.448 -dodano najnowszy polski PFS3 All-in-one skompilowany gcc 6.x (eksperymentalne) -dodano spolszczenie najnowszego simplemaila -zmieniono THE.catalog, dopus.catalog, S:MCP.gurudat -uaktualniono MUI.catalog do najnowszej wersji -dodano nowe spolszczenie Identify.catalog oraz IdentifyTools.catalog Ostatnia aktualizacja: 08.02.2017 22:51:35 przez HanSolo

Proszę http://www.everymac.com/mac-identification/index-how-to-Identify-my-mac.html

Facts people, please lets try to only post facts. :-) Ok 1st FACT is that Apollo runs as 68040 now. This means software using 68040 features like e.g. MOVE16 can run fine now. This is an improvement. 2nd FACT : AMIGA OS can correctly Identify whether you have an 68040 with or without FPU. This means software asking the OS whether an FPU is there will work correctly. FACT no 3 : We have a full Motorola compatible FPU. The FPU is not enabled yet but this on the to do list. FACT 4) Yes our FPU provides more features, but this does not mean its incompatible. APOLLO core itself also provides more features, e.g. more registers, 64bit mode etc - But APOLLO is still full compatible.

Beta 13 - Mainboard SCSI controllers didn't initialize correctly (A3000/A4000T/CDTV) (b12) - "Do not force full display reset.." update made it worse, should be better now (b12) - I finally bothered to carefully re-examine AR3 freezer behavior, emulation updated, should now match real hardware, previously unsupported features like autofire work. - If copper DMA is switched off mid-instruction, allow instruction to finish. Fixes AR2 weird copper list detection code. - Added RDB mode HD geometry GUI support. (RDB mode geometry option = what IDE Identify Device and SCSI MODE SENSE Format Parameters/Rigid Disk Geometry returns). Very old controllers may require custom geometry. - Added HD/CF IDE harddrive GUI option. Currently only difference is in IDE Identify Device word 0 identifier. (Cause for infamous hdtoolbox "Unit is not a disk (Type 7)" error) - Added GUI IDE and SCSI version selection to hardfile panel. IDE has ATA-1, ATA-2+ (old default, returns ATA-6 to allow LBA48 support and more) and ATA-2+ Strict which drops ATA-1 feature that become optional in ATA-2, triggering A600/A1200/A4000 IDE driver bug that causes infamous "max transfer bug". (No, it isn't drive bug) SCSI has SCSI-1 and SCSI-2 options. Currently only real difference is INQUIRY version number, some old software (like original A590/A2091 install disk) require SCSI-1 version. - Added Archos ADD-500 emulation. - Added AdSCSI Advantage 2000 emulation. - Internal enforcer emulation hit can break to debugger, enable/disable with 'fen' debugger command. - SCSI Read Defect Data command: return empty defect header instead of Defect List Not Found error. (ADD-500 driver gets confused if Read Defect Data command does not return any data) - WD33C93 SCSI devices didn't support multiple units (b12) - Added hack that fixes max overscan scrolling in demo Seven Seas / Andromeda. (Demo has workaround for chipset bug that causes right edge to have a vertical gap if BPLCON1 is larger than zero. Hack is currently needed because glitch happens when hpos=0 and emulation is not designed to handle bitplane changes that cross virtual scanlines). Glitch was not emulated until few versions ago, demo worked only accidentally previously. - Added Windows 10 TP bug workaround, for some reason dialog window is visible before WM_INITDIALOG message (documentation specifically says it won't be visible until after WM_INITDIALOG) and also dialog is set as not visible. Fixes quickly appearing and disappering empty WinUAE GUI panel each time GUI is opened. AdSCSI Advantage 2000: - 5380 based fake DMA. - First 5380 based driver that uses chip's arbitrate bit instead of assuming AdSCSI is the only initiator. - 1.6 ROM added. (Anyone have later? At least 1.9 exists) - RDB parser is not fully compatible, does not load all filesystems (for example PFS3). Archos ADD-500: - Yet another 5380 based fake DMA SCSI controller. - v1.21 ROM added.

Czy zna ktoś sposób, jak w asemblerze zmienić napis na belce tytułowej Workbencha? Chodzi o to, aby dowolny napis był ciągle widoczny na belce tak, jak robi to MCP. W dokumentacji MCP jest napisane: "MCP tries to Identify the old WBTitleBar by searching for 'Amiga' at the beginning of the ScreenTitle. If this fails the function has no effect." Wynika z tego, że program szuka w pamięci starego napisu tytułowego i zmienia go. Pytanie, gdzie jest w pamięci struktura ekranu WB?

A może te błędy wynikają ze złej konfiguracji pliku NSDPatch.cfg? Taki plik znajduje się na dyskietce Emergency systemu OS3.9 w katalogu DEVS i jest kopiowany na dysk twardy w momencie instalacji systemu. # $Id: NSDPatch.cfg 1.35 2000/03/06 21:07:43 heinz Exp $ # $VER: NSDPatch.cfg 43.16 (6.3.2000) # # Demonstration patch configuration file for NSDPatch # =================================================== # # # Each device patch configuration must reside on a single line. # A patch that has been installed once cannot be changed. # The patching process works also for devices which generate a # new device base for each OpenDevice() call. It is not Unit # specific. For devices generating multiple bases per OpenDevice(), # existing opens won't be patched as they can't be located. # Once a patch is installed any Unit opened since then will be # patched. # # NOTE WELL: A device patch is not meant to replace an NSD upgrade # forever. It will emulate NSD device behaviour on top # of existing devices fairly well. It will not add any # major safety checks or automagically fix every problem # you might have with an old Exec device. It may not # implement every single NSD detail for various device # types. # # THERE IS ABSOLUTELY NO WARRANTY WHATSOEVER! STANDARD DISCLAIMER! # # How to install the patch on OS 3.5: # # 1. Update this configuration file as required and copy it # to "DEVS:NSDPatch.cfg". That's all. OS 3.5 does the rest. # # How to install the patch on OS 3.1: # # 1. Copy the configuration file and NSDPatch onto your boot # partition. You can choose the place arbitrarily, though DEVS: # and C: are recommended respectively. # # 2. If needed, rename the configuration file and change it as # needed for your setup. Check the option descriptions below. # BE CAREFUL WHEN CHOOSING PATCH OPTIONS! # # 3. Add a line like this one *immediately* after SetPatch to your # S:Startup-Sequence: # # <location>NSDPatch QUIET PCF <configfile> # # You only need to specify "PCF <configfile>" if you don't use # DEVS:NSDPatch.cfg # # 4. On every subsequent reboot, the NSDPatch will silently be # turned on according to the configuration. There is nothing # more you have to do except turning off the patch for any device # that gets updated to be NSD compliant. # # There are various options, parsed in dos.library/ReadArgs() style. # This file describes the options available with NSDPatch >= V43.16. # or OS 3.5. # # DEVICE The name of the device to patch (need not be resident) # If your device supports NSD already, it usually is # *NOT* wise to patch it! # You can check this with a tool like NSDQuery from the # original NSDPatch archives. # COMMANDS A comma separated list of the supported command # numbers. It is not necessary to specify the general # NSD commands like NSCMD_DEVICEQUERY. # When specifying commands, you can exclude some with # a subsequent negative specification as shown below # in the various patch lines. # Just use the "!" character to specify a command number # or range to be subsequently excluded again. # (Needs "DEVICE" option) # DEVICETYPE The numeric or symbolic NSD device type to set # (Needs "COMMANDS" option) # SKIPMOUNT/S After a trackdisk like device is patched, NSDPatch # automagically checks if any 64 bit partitions are mounted # but not yet activated. These partitions will then be # activated to support, e.g., the V43 FastFileSystem # which will activate only for big partitions # if the underlying device supports the NSD 64 bit # command set. # To suppress this feature, specify this option. # Normally, you should not use this option. # (Needs "DEVICETYPE" option) # IOERRNOCMD/S If the device to patch does not support IOERR_NOCMD # correctly, i.e., if it crashes on unknown commands, # specify this option. Only the commands specified # via the "COMMANDS" option will be accepted then. # All other requests will be safely returned with the # IOERR_NOCMD error. # (Needs "DEVICETYPE" option) # TD64/S If the device to be patched supports the 3rd party TD64 # command set, use this option. The NSD trackdisk # extensions will automatically be redirected then to # make use of that functionality for e.g. the V43 # FastFileSystem. Otherwise a simple HD_SCSICMD # fallback is implemented for trackdisk like devices. # This fallback is _very_ simple to emulate 64 bit # commands. Don't expect magic. (Needs "DEVICETYPE" # option) # ACTIVATE A DOS pattern to tell which DOS device names should # be activated to e.g. start up a filesystem on a # patched device. It is safe to specify already # active devices. Devices where the name is "hidden" # by a volume of the same name currently won't be # activated. You may want to specify the partition # names of partitions exceeding the 4GB barrier here # for a patched device with the V43 FastFileSystem # if you have used the SKIPMOUNT option when patching # the device. Don't specify a trailing ':' in the # pattern. # RDBUNIT/N If you have a trackdisk like boot device that # crashes on unknown commands instead of returning # IOERR_NOCMD, you will need this option, # "IOERRNOCMD", and "ACTIVATE". You can't boot from a # partition exceeding the 4GB barrier with an old # style device and the V43 FastFileSystem, and you # must not mark any partitions exceeding that barrier # as automountable if you have a device that does not # support IOERR_NOCMD. These partitions won't be # activated automatically by e.g. V43 FFS until the # patch is installed. To activate or mount these # partitions automatically after the patch is in # place, specify the device unit number to scan here # and the partition names with the "ACTIVATE" option. # The Rigid Disk Block (RDB) on the named unit will be # scanned and all named partitions will be mounted. # If you specify partitions that are already # mounted, an error will be returned. Actually, this # option is useful as a general "late mount" # functionality! # MOUNTANY/S This option is obsolete. Late mounting will always # look at all RDB entries on "RDBUNIT" matching the # "ACTIVATE" pattern, starting with NSDPatch 43.18. # VERSION/N If you know the exact version of a certain device to # REVISION/N be patched, specify these options. The patch line # will only be used if this version and revision # can be found. As NSDPatch will not skip configuration # lines for already patched devices, you can make a list # of certain patches for specific versions, followed by # a "generic" line for all other versions. # This is shown below for scsi.device. # Note the usefulness for these options with the ISNSD # and VERSIONISNSD options! # # Patches with version and revision info always take # precedence over a general patch line for the same # device if they apply. # SANA2MAGIC/S Some SANA2 devices don't take it very well if they # get passed a NULL buffer management pointer on OpenDevice() # This not only makes it hard for NSD to operate nicely, it # also confuses some of the popular SANA2 debugging tools. # If you have a device like this, you may want to try this # option. It should help by providing a dummy pointer if needed. # Note that you should add a patch line with an impossibly # high version/revision info using this option if you have # version lines requiring it and version lines *not* requiring # this option. # ISNSD/S Will recognize and not patch any device with at least # the given VERSION and, optionally, REVISION. # VERSIONISNSD/S Works like ISNSD for the exact VERSION.REVISION. # This is useful in case somebody put out a non NSD # device suddenly with a higher version number. Tss. # What an idea. # SINGLEPATCHONLY/S # NSDPatch will patch a device just once on the "first" call # to OpenDevice(). This option is still accepted, but OBSOLETE, # as this behaviour is NSDPatch default starting with NSDPatch # version 43.12. # # TRYMULTIPATCH/S # Normally, NSDPatch will check a device to patch on # the initial OpenDevice() call and patch it # appropriately. This behaviour is default starting # with NSDPatch 43.12. If you encounter a device that # changes its own device function addresses while it # is open, you should use this option. This is highly # unlikely, though, as this behaviour would be rather # inefficient and possibly crash prone. Note # that when using this option, you may encounter # infinite loops if other tools like debuggers # also patch into the device vectors. Before 43.12, # this option was the default setting but due to its # dangerous nature, SINGLEPATCHONLY is now the # default setting. # INTBEGINIO/S # Some devices may be used from within interrupts # to a certain extent. timer.device and audio.device # have functionality that may be used from interrupts. # Specify this option only if a device may be safely # called from within supervisor code. In supervisor # mode, NSDPatch functionality is then bypassed to # preserve system stability. Do not specify this option # if it is not needed as it will add some amount of # processing overhead. # # # MAPTODEVICE/K # MAPTOUNIT/K/N # By using this type, you can define mappings from one # device/unit combination to another. This is # useful if special tools check on the device # name for certain functionality and you really want # to use another device/unit. Examples can be found # below. It is usually unwise to map devices to # devices of a different type because the command # sets may well differ in a way that confuse non NSD # aware applications. Note that mapping trackdisk # units to other devices may be dangerous unless you # run any "noclick" hack before NSDPatch! # # # FIXSCSIUPDATE/S # The V40 scsi.device has a problem with the JAZ-drive # A CMD_UPDATE will start up the drive even if there is # nothing to update. For any trackdisk like device # with HD_SCSICMD, you # can specify this option to # fix a JAZ-drive. CMD_UPDATE will be replaced then # with a safe version, which only syncs up the # drive's caches if the drive is ready. # # # AVOIDFORBID/S # The AmigaOS kernel Exec single threads any device # opener with Forbid(), meaning that only the task # opening the device will run at that time. Some # devices rely on this, some modern devices don't. # Forbid() is bad, because opening device can take # some time, which means that other tasks are blocked # in a significant and possibly deadly way for time # critical applications. A better method to do single # threading is use of a semaphore, which # unfortunately can't be generally used due to # compatibility reasons. If you know that a device # can handle a semaphore, specify this option. The # Forbid() will then be automagically converted into # a semaphore call when the device is opened. # Note that if you have multiple patch lines under the # same device name with some of them using this option # and some of them not, you should add a "dummy" patch line # with this option using an impossibly high version and # revision number. See below for examples of this for the # SANA2MAGIC option, using 9999.9999 as version.revision. # At this point of time, it is not wise to use this option # for devices that can be expunged. # ONLY TOUCH THIS IF YOU KNOW WHAT YOU ARE DOING! YOU MAY # NOT GET WHAT YOU EXPECT! I MEAN IT! DON'T TRY TO BE SMART! # # # IDSTRING/K (Added 20-Feb-2000) # Some devices may patch into the system under the name # of other well established devices. Sometimes, it is impossible # to determine the difference with the version/revision # information. The advanced user can Identify devices by # their lib_IdString with this option. If you don't know # what I am talking about, you don't want to use this option. # Note: '#?' is the *only* acceptable pattern in the argument! # #------------------------------------------------------------------------- # # Default configuration lines for the V40 (OS 3.1) devices and their # OS 3.5 counterparts. # If you find any bugs or omissions, please report them. # With some work, all the correct versions could be added, # and this file could contain complete patch information for # different OS versions. Feedback on this is welcome. # # Add a comment '#' character to those lines where you already # use a NSD device. # # Notes: # # - audio.device is marked with IOERRNOCMD. It does not crash on # unknown commands, but it doesn't set IOERR_NOCMD correctly. # # - As a convenience measure for A4000T users, a line with # 2nd.scsi.device, equal to the scsi.device line, has been added. # # - mfm.device V38/V40 trashes a CPU register on OpenDevice() and # has a special private configuration command. The patch fixes # the former automagically (as for any device), and the patch # line reflects the latter. # # - scsi.device V40 and before V43.22 will not handle CMD_UPDATE well, # This is worked around by the FIXSCSIUPDATE option in the respective # lines. DEVICE audio.device DEVICETYPE NSDEVTYPE_AUDIO COMMANDS 1-14,32 IOERRNOCMD INTBEGINIO DEVICE cd.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,18-23,32-46 DEVICE clipboard.device DEVICETYPE NSDEVTYPE_CLIPBOARD COMMANDS 2-4,9-12 DEVICE console.device DEVICETYPE NSDEVTYPE_CONSOLE COMMANDS 1-3,9-12 DEVICE gameport.device DEVICETYPE NSDEVTYPE_GAMEPORT COMMANDS 1,5-13 DEVICE input.device DEVICETYPE NSDEVTYPE_INPUT COMMANDS 1,5-16 DEVICE keyboard.device DEVICETYPE NSDEVTYPE_KEYBOARD COMMANDS 1,5-13 DEVICE parallel.device DEVICETYPE NSDEVTYPE_PARALLEL COMMANDS 1-10 DEVICE printer.device DEVICETYPE NSDEVTYPE_PRINTER COMMANDS 1-12,!2,!4,!5 DEVICE ramdrive.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 2-5,9,11-15 DEVICE scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK VERSION 43 ISNSD FIXSCSIUPDATE DEVICE scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK VERSION 43 REVISION 22 ISNSD DEVICE scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 VERSION 40 REVISION 20 FIXSCSIUPDATE DEVICE scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28,!22 FIXSCSIUPDATE DEVICE 2nd.scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK VERSION 43 ISNSD FIXSCSIUPDATE DEVICE 2nd.scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK VERSION 43 REVISION 22 ISNSD DEVICE 2nd.scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 VERSION 40 REVISION 20 FIXSCSIUPDATE DEVICE 2nd.scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28,!22 FIXSCSIUPDATE DEVICE serial.device DEVICETYPE NSDEVTYPE_SERIAL VERSION 43 ISNSD DEVICE serial.device DEVICETYPE NSDEVTYPE_SERIAL COMMANDS 1-11,!4 DEVICE timer.device DEVICETYPE NSDEVTYPE_TIMER COMMANDS 9-11 INTBEGINIO DEVICE trackdisk.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 2-16,!8,$8002-$8005,$8009-$800b,$8010-$8011 DEVICE mfm.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-23,29 DEVICE a2065.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 2-3,8-11,14-26 SANA2MAGIC DEVICE a2060.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 2-3,8-11,17-26 SANA2MAGIC IOERRNOCMD DEVICE slip.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 2-3,9-26 #------------------------------------------------------------------------- # # A few configuration lines for known third party stuff. Please report # more device configurations if you can obtain them! # # It is unwise to use a configuration line without checking the version # of the device first! Not all these entries are necessarily tested. # # Entries for devices that are known to be troublesome are enabled as # default. # # Entries for specific known versions precede entries that should cover # all other versions. # # If you create new entries here, please report them to # <heinz@hwg.muc.de>. Thanks a lot. # # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # AmokNet DEVICE amoksana.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 1-5,8-9,16-26 VERSION 3 REVISION 189 SANA2MAGIC DEVICE amoksana.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 1-5,8-9,16-26 VERSION 3 REVISION 190 SANA2MAGIC DEVICE amoksana.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 1-5,8-9,16-26 SANA2MAGIC # VillageTronic Ariadne board. DEVICE ariadne.device DEVICETYPE NSDEVTYPE_SANA2 VERSION 1 REVISION 47 ISNSD #DEVICE ariadne.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 2-3,8-11,14-26 VERSION 1 REVISION 39 #DEVICE ariadne.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 2-3,8-11,14-26 # Interworks ICard DEVICE icard.device DEVICETYPE NSDEVTYPE_SANA2 VERSION 9999 REVISION 9999 SANA2MAGIC DEVICE icard.device DEVICETYPE NSDEVTYPE_SANA2 VERSION 1 REVISION 5 ISNSD DEVICE icard.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 2-3,8-11,14-26 VERSION 1 REVISION 4 SANA2MAGIC IOERRNOCMD DEVICE icard.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 2-3,8-11,14-26 SANA2MAGIC IOERRNOCMD # NE1000 for the GoldenGate board DEVICE gg_ne1000.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 2-3,8-11,14-26 VERSION 37 REVISION 7 SANA2MAGIC DEVICE gg_ne1000.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 2-3,8-11,14-26 SANA2MAGIC # NE2000 for the GoldenGate board DEVICE gg_ne2000.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 2-3,8-11,14-26 VERSION 37 REVISION 7 SANA2MAGIC DEVICE gg_ne2000.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 2-3,8-11,14-26 SANA2MAGIC # QuickNet board DEVICE QuickNetS2.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 2-3,8-11,17-26,$7ff0 VERSION 2 REVISION 3 SANA2MAGIC IOERRNOCMD DEVICE QuickNetS2.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 2-3,8-11,17-26,$7ff0 SANA2MAGIC IOERRNOCMD DEVICE QuickNet.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 2-3,8,17,20 SANA2MAGIC # Holger Kruse #DEVICE ppp.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 2-3,9-11,14-26 # A4066 #DEVICE a4066.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 2-3,9-11,14-26 VERSION 1 REVISION 9 # Hydra DEVICE hydra.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 2-3,8-11,14-27 VERSION 1 REVISION 44 SANA2MAGIC DEVICE hydra.device DEVICETYPE NSDEVTYPE_SANA2 COMMANDS 2-3,8-11,14-27 SANA2MAGIC # HWG version 40.9 DEVICE a2060.device DEVICETYPE NSDEVTYPE_SANA2 VERSION 9999 REVISION 9999 SANA2MAGIC DEVICE a2060.device DEVICETYPE NSDEVTYPE_SANA2 VERSION 40 REVISION 9 ISNSD # HWG/MBS version 3.x DEVICE a2065.device DEVICETYPE NSDEVTYPE_SANA2 VERSION 9999 REVISION 9999 SANA2MAGIC DEVICE a2065.device DEVICETYPE NSDEVTYPE_SANA2 VERSION 3 ISNSD # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # A few lines donated by Alessandro Zummo # MultiFace Card #DEVICE duart.device DEVICETYPE NSDEVTYPE_SERIAL COMMANDS 1-11,!4 #DEVICE pit.device DEVICETYPE NSDEVTYPE_PARALLEL COMMANDS 1-10 # GVP IOExtender or GForce 040 Combo #DEVICE gvppar.device DEVICETYPE NSDEVTYPE_PARALLEL COMMANDS 1-10 #DEVICE gvpser.device DEVICETYPE NSDEVTYPE_SERIAL COMMANDS 1-11,!4 # diskserial.device #DEVICE diskserial.device DEVICETYPE NSDEVTYPE_SERIAL COMMANDS 1-11,!4 # a2232.device #DEVICE a2232.device DEVICETYPE NSDEVTYPE_SERIAL COMMANDS 1-11,!4 # squirrel #DEVICE squirrelserial.device DEVICETYPE NSDEVTYPE_SERIAL COMMANDS 1-11,!4 VERSION 37 REVISION 565 # telser (Command set not checked!) #DEVICE telser.device DEVICETYPE NSDEVTYPE_SERIAL COMMANDS 1-11,!4 # VMC HyperCOM4-Z2 board # should work with other VMC-Devices (vmcisdn.device, hyperCOMxx.device) #DEVICE hyperCOM40.device DEVICETYPE NSDEVTYPE_SERIAL COMMANDS 1-11,!4 # Note: This device seems to violate NSD specs by using the $4xxx range. version 1.917 # It uses $4303-$4305,$43f0-$43f3,$4405 as it seems, so I don't list them. #DEVICE capi20.device DEVICETYPE NSDEVTYPE_UNKNOWN COMMANDS 1-3,5 # Version checked: 1.917 #DEVICE fossil.device DEVICETYPE NSDEVTYPE_SERIAL COMMANDS 1-3,5,8-9,11 # The type setting for these two devices seems somewhat questionable. # Any comments? # Versions checked: 3.13. #DEVICE ciwan.device DEVICETYPE NSDEVTYPE_SANA COMMANDS 2-3,9-11,18,23,25-26 #DEVICE iwan.device DEVICETYPE NSDEVTYPE_SANA COMMANDS 2-3,9-11,18,23,25-26 #DEVICE ariadnepar.device DEVICETYPE NSDEVTYPE_PARALLEL COMMANDS 1-3,5-12 #DEVICE ibmprint.device DEVICETYPE NSDEVTYPE_PARALLEL COMMANDS 1,3,5-10 #DEVICE ibmser.device DEVICETYPE NSDEVTYPE_SERIAL COMMANDS 1-3,5-10 #DEVICE serio.device DEVICETYPE NSDEVTYPE_SERIAL COMMANDS 1-10 # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # For omniscsi.device 1.9 as used in some Guru-ROM's # Yes, to patch omniscsi.device, you'll need the name gvpscsi.device! #DEVICE gvpscsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 2-5,9-15,20-23,28 # For HardFrame Controllers DEVICE HardFrame.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,23,28 # Oliver Kastl's atapi.device DEVICE atapi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 # Another recoverable ram disk. As it turns out, the author used incorrect arithmetic # when parsing the commands. So IOERRNOCMD is a *must* DEVICE statram.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 2-15,20-21 VERSION 37 REVISION 11 IOERRNOCMD # For Hardital Synthesis Controllers # Looks like this should work with syndisk.device 33.x DEVICE syndisk.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 2-5,9,11-15,28,$69,$6d,$70,$73 VERSION 33 # The following lines covering different Phase 5 devices were enhanced with help # from Frank Mariak # A few lines donated by Alessandro Zummo that were enhanced over time # Blizzard boards from Phase 5 DEVICE 1230scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 DEVICE 1230scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 TD64 VERSION 7 DEVICE 1233scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 DEVICE 1233scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 TD64 VERSION 7 DEVICE 1234scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 DEVICE 1234scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 TD64 VERSION 7 DEVICE 1260scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 DEVICE 1260scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 TD64 VERSION 7 DEVICE 2060scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 DEVICE 2060scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 TD64 VERSION 7 # Phase 5 board, donated by Willem Schaaij and enhanced over time DEVICE cybscsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 DEVICE cybscsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 TD64 VERSION 7 # Phase 5 PowerPC boards DEVICE cybppc.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 TD64 DEVICE blizzppc.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 TD64 # Another Phase 5 device. Due to the amount of private commands that are really "unknown" to me, # I decided to cut this down a little. It should be safer now. DEVICE z3scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 2-7,9-15,20-28 DEVICE z3scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 2-7,9-15,20-28 TD64 VERSION 7 # This should cover SCSI/IDE users with a DataFlyer card. DEVICE ExpSys.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-9,11-15,18,20-22,28-29 IOERRNOCMD # WarpEngine DEVICE warpdrive.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 VERSION 40 REVISION 66 # Oktagon 6.10 # Also seems to support 34-36,37-39 but I don't know if # the implementation is acceptable (cd.device!), so I don't list them DEVICE oktagon.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,18-22,28 VERSION 6 REVISION 10 # diskspare #DEVICE diskspare.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 2-15,18-22 VERSION 3 REVISION 0 # squirrel DEVICE squirrelscsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 VERSION 37 REVISION 1765 # Draco builtin hostadapter (Donated by Bernhard Möllemann) DEVICE dracoscsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-15,20-23,28 # hardfile.device by Chris Hames. Only 2-3,11 seem to do anything useful #DEVICE hardfile.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-11,13-15,18-21,$8001-$800b,$800d-$800f,$8012-$8015 #DEVICE cdromemu.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 2,12-14,$7ff2-$7ff3 # Most commands don't do anything but return. #DEVICE ibmide.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-21,$8001-$8015 # DKB WildFire DEVICE wildfirescsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 2-5,9,11-15,20-22,28 VERSION 1 REVISION 1 # CatWeasel multidisk.device, not even HD_SCSICMD support?! DEVICE multidisk.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-22,25-27,$8001-$8016,$8019-$801b VERSION 3 REVISION 42 # DKB FerretROM V1.28 DEVICE dkbscsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 2-5,9,11-15,20-22,28,$8002-$8005,$8009,$800b-$800f,$8014-$8016,$801c VERSION 1 REVISION 28 # Oliver Kastl's device for the Buddha Controller. DEVICE scsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-7,9-15,18-22,24-28 VERSION 100 REVISION 7 IDSTRING "#?Buddha_IDE#?" # cd.device by Georg Campana DEVICE cd.device DEVICETYPE NSDEVTYPE_TRACKDISK VERSION 3 IDSTRING "#?Campana#?" ISNSD # csascsi.device DEVICE csascsi.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 1-5,9-15,18-21,28 VERSION 39 REVISION 2 # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # AsimCDFS #DEVICE asimcdfs.device DEVICETYPE NSDEVTYPE_UNKNOWN COMMANDS 1-37 #------------------------------------------------------------------------- # # Some broken software checks the device name and assumes certain # capabilities. This prohibits the use of updated drivers because # the software would not use their features. # Via device mapping, you can map a certain device unit combination # to another. # # Fool CrossDOS into using TD_GETGEOMETRY for fake units #DEVICE mfm.device UNIT 1 MAPTODEVICE hwgatapi.device MAPTOUNIT 1 #DEVICE mfm.device UNIT 1 MAPTODEVICE scsi.device MAPTOUNIT 1 # Same thing for versions of FFS. # Note that mapping trackdisk units to other devices may be dangerous # unless you run any noclick hack before NSDPatch! #DEVICE trackdisk.device UNIT 1 MAPTODEVICE hwgatapi.device MAPTOUNIT 1 #DEVICE trackdisk.device UNIT 1 MAPTODEVICE scsi.device MAPTOUNIT 1 #------------------------------------------------------------------------- # # Demonstration lines for activation and late mount functionality. # If you want to late mount huge partitions, place the late mount lines # after the device patch line. Note that you must not specify a colon # for the DOS names. # # Activate a mounted DOS device entry named "HUGE" (without the colon!) #ACTIVATE HUGE # Late-Mount and activate a partition named "BIG" on scsi.device unit 4 #DEVICE scsi.device RDBUNIT 4 ACTIVATE BIG # Late-Mount all unmounted partitions on scsi.device unit 4 #DEVICE scsi.device RDBUNIT 4 ACTIVATE #? # Late-Mount all unmounted partitions except for UNIX and MAC on scsi.device unit 4 #DEVICE scsi.device RDBUNIT 4 ACTIVATE ~(UNIX|MAC) #------------------------------------------------------------------------- # Dummy lines for simple support of differing hardware. These are not really tested # and I have no idea what the true command capabilities are. DEVICE tekscsi2.device DEVICETYPE NSDEVTYPE_TRACKDISK COMMANDS 2-5,9-15,20-21,23,28 IOERRNOCMD #------------------------------------------------------------------------- ### EOT ### I na koniec ciekawostka. Problem z zaznaczaniem ikon i zawieszaniem systemu zniknął. Podpiąłem tylko drugi dysk z systemem 3.9. Ostatnia aktualizacja: 06.08.2014 12:25:03 przez glichtanski

Witam wszystkich. Od dłuższego już czasu jestem posiadaczem MacMini 1.33 ( late 2005 ) ( pazdziernik 2005 ) Model: M9686LL/B który był produkowany pół roku ( końcówka września- do końca lutego 2005. Znalazłem 2 portale które pokazują specyfikacje danego modelu ale z grubsza . http://www.everymac.com/ultimate-mac-lookup/?search_keywords=PowerMac10%2C2 http://www.powerbookmedic.com/Identify-mac-serial.php Wiem że jest jeszcze strona Apple - support jako 3 którą znam gdzie można sprawdzić swój model - aż tyle iiiiiii tylko tyle . Problem polega na tym że ja mam jakiś chyba nietypowy model o dodatkowych symbolach jeszcze pod spodem miniacza są to : A1126 i EMC 2079 gdzie w wyświetlanych na stronach informacji o danym modelu nie ma . Czy może wiecie gdzie mógłbym i jak mogę sprawdzić jeszcze swój model . Pozdrawiam serdecznie . :) Znalazłem jeszcze taki wpis na www.everymac.com : *M9686LL/B refers to the configuration of the Mac mini G4/1.25 introduced July 26, 2005. Unfortunately, as the G4/1.33 was not introduced formally, it never was assigned a separate order number. a po translate google wyszło tak : * M9686LL / B odnosi się do konfiguracji komputera Mac mini G4/1.25 wprowadzone 26 lipca 2005. Niestety, jak G4/1.33 nie została wprowadzona formalnie nigdy nie został przydzielony oddzielny numer zamówienia. To już wiem . Ale co z tymi drugimi numerami . Można coś z tym jeszcze zrobić ? Wpisuję w gógle ale jest du**a . ;) Ostatnia modyfikacja: 13.10.2011 13:04:49

Nie wiem czy dziala, ale moze pomoc przy zakupie. http://www.powerbookmedic.com/Identify-mac-serial.php

Jesli Twój skrypt nie radzi sobie ze zdjęciami panoramicznymi, to znaczy, że te zdjęcia nie są nikomu potrzebne Jak to nie radzi? Radzi i to bardzo dobrze... nadal nie rozumiesz paru spraw: sprawę formatu zdjęcia potrzebuję do definicji filetype'u. Wtedy inne formaty zdjęć zostają niejako odfiltrowane. W samym zaś skrypcie nie ma problemu rozpoznania i interpretacji rozdzielczości zdjęcia. Nie jeden Identify "wypluwa" informację n/t temat, w moim przypadku choćby stareńki Visage... Najważniejsze, że zmniejsza zdjęcia o 25%, bo wtedy pasuje to do "Twojego ekranu". Naprawdę... nieziemskie "warunki brzegowe". Rzekłbym wręcz "skrajne". Znowu muszę tłumaczyć? Podsyłam fotki rodzince i znajomy, oglądają na kompie. Jaki sens podsyłania większego rozmiarowo zdjęcia? Ograniczenia konta też robią swoje. Nie wiem jak inni, ale mam wrażenie jakbyś się po prostu czepiał...

Tylko zarzucasz komuś, że jego program do obsługi grafik np. nie nagrywa płyt ze zdjęciami, ale twój też nie nagrywa. Ty używasz do tego skryptu. Przecież on tez może użyć skryptu i połączyć jakieś programy. W czym twój skrypt byłby lepszy od czyjegoś na innym systemie? Nic nie zarzucam. Mój skrypt "lepszy", bo jest, istnieje, czeka sobie cichutko na wykorzystanie... całe skrypty to najczęściej 5-10 linijek... Pokazuje mi rozdzielczość, a z tą informacją mogę sobie sprawdzić w skrypcie czy rozdzielczość jest większa niż ileś tam. Identify pokazuje rozdzielczość ? Ciekawe... nie wiesz jak odczytuje tą rozdzielczość? Chyba, że po innym parametrze chcesz rozpoznawać czy zdjęcie jest HD? Najlepiej po rozdzielczości, ale nie wiem jak ją znależć e pliku... na razie mam identyfikację po ciągu EXIF, symbolu kamery i rozmiarze fotki...

Ale łączysz. Więc to nie jeden program robi, tylko kilka wywoływanych przez skrypt. W skrypcie wykorzystuję to co mi potrzebne... im bardziej specjalizowane narzędzie, i mniejsze, tym lepiej... skrypt rządzi się swoimi prawami... zresztą nie wiem co w tym złego dostrzegasz, lepsze "kobyły" z GUI od dosowych pchełek ? Amiga DOSowymi programami przecież stoi... 90% softu amigowego ma argumenty DOSa... aż się prosi by to wykorzystywać w skryptach... zresztą po cóż by innego one były? Można w ikonkach, jako tooltype'y ale to marnowanie potencjału ;) Mogę użyć np. programiku Identify. Nie rozróżni, myślę... działa chyba w oparciu o nagłówki, a nagłówek HD czy VGA cyfrowej fotografii taki sam... Ostatnia modyfikacja: 19.06.2011 00:38:53

Łączę dosłownie "pchełki".. mkisofs to 458kb, readcd to 155kb, jpegtool to 12kb, program do tworzenia glowikonki to 32kb... wszystko oczywiście z Aminetu, tj. darmowe. Ale łączysz. Więc to nie jeden program robi, tylko kilka wywoływanych przez skrypt. A jak tam pod linuxem z rozróżnianiem zdjęć HD od zwykłych? Mogę użyć np. programiku Identify. Na pewno jest też inne rozwiązanie, ale jako, że nieszczególnie zajmuje się obróbką zdjęć(tym bardziej masową) to nie siedzę w temacie ;) Pozdrawiam

Ja mojego poprawnie zidentyfikowałem na przykład tutaj. Albo tutaj.

Hym.. MPlayer dev-SVN-rUNKNOWN-2.95.3 (C) 2000-2006 MPlayer Team CPU: PowerPC 0 mplayer 1 -Identify 2 -vo 3 null 4 dane:Filmy/Tu_była_nazwa.wmv 106 audio & 227 video codecs Playing dane:Filmy/Tu_byla_nazwa.wmv. ASF file format detected. ID_AUDIO_ID=1 ID_VIDEO_ID=2 VIDEO: [WMV1] 320x240 24bpp 30.000 fps 0.0 kbps ( 0.0 kbyte/s) Clip info: name: ID_CLIP_INFO_NAME0=name ID_CLIP_INFO_VALUE0= author: aca ID_CLIP_INFO_NAME1=author ID_CLIP_INFO_VALUE1=aca copyright: ID_CLIP_INFO_NAME2=copyright ID_CLIP_INFO_VALUE2= comments: ID_CLIP_INFO_NAME3=comments ID_CLIP_INFO_VALUE3= ID_CLIP_INFO_N=4 ID_FILENAME=dane:Filmy/Tu_byla_nazwa.wmv ID_DEMUXER=asf ID_VIDEO_FORMAT=1VMW ID_VIDEO_BITRATE=0 ID_VIDEO_WIDTH=320 ID_VIDEO_HEIGHT=240 ID_VIDEO_FPS=30.000 ID_VIDEO_ASPECT=0.0000 ID_AUDIO_FORMAT=353 ID_AUDIO_BITRATE=0 ID_AUDIO_RATE=0 ID_AUDIO_NCH=0 ID_LENGTH=952.00 ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffwmv1] vfm: ffmpeg (FFmpeg M$ WMV1/WMV7) ========================================================================== ID_VIDEO_CODEC=ffwmv1 ========================================================================== Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 32000 Hz, 2 ch, s16be, 32.0 kbit/3.12% (ratio: 4000->128000) ID_AUDIO_BITRATE=32000 ID_AUDIO_RATE=32000 ID_AUDIO_NCH=2 Selected audio codec: [ffwmav2] afm: ffmpeg (DivX audio v2 (FFmpeg)) ========================================================================== AHI: Using 0x30002 AudioID. AHI: Using 7680 bytes per chunk and 240 Kb for buffer AO: [ahi] 32000Hz 2ch s16be (2 bytes per sample) ID_AUDIO_CODEC=ffwmav2 Starting playback... VDec: vo config request - 320 x 240 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is undefined - no prescaling applied. VO: [null] 320x240 => 320x240 Planar YV12

Oto log... Pegasos Boot Strap (c) 2002 bplan GmbH Running on CPU PVR:00083311 PLL setting : 00000003 Enable L1 ICache... Done. Setting ROM Defaults... Done. Configuring SDRAM... SDRAM Config Error : 80000000,0FD00008 10000000 Delaying...Done. RAMSIZE = 10000000 00000000 Reading W83194 : 78FFFFFFFFFFFF00 Done. Setting Front Side Bus to 100MHz... Done. Releasing IDE reset ... Done. Configuring Legacy Devices Initializing KBD... Done. PLL setting : 00000003 10000000 Done. FFFFFFFF BIOS: Stage 2 entered arg(FFFC0000,00000000,10000000) BIOS: MachineInfo at 0FFFFE68 BIOS: 0F6FFFE8 bytes added to mempool LoadFromRFS: starting LoadFromRFS: lib module 00 has abs load adr at 00C00000 CopyModule: start CopyModule: load address : 00C00000 CopyModule: copy module to ram...done ModuleCopy: expanding... done LoadFromRFS: 00000001 modules out of 00000001 loaded InitLib: start InitLib: call module as OF allocated g_e=0xFD00008 (len=19232) install_root: pkg=0xFD53B90 after init_environ e=0xFD00008 running nvramrc... Bus addresses: 253@2 I/O addresses: 7936@FE002100 Memory addresses: 64K@90010000 1.4G@90040000 Prefetchable memory addresses: install_ata_disk_driver: reg=0x1000 init_drive: reset controller 0x1000/0x100E init_drive: allow 4-bits for heads init_drive: select drive 0 init_drive: seccnt=0x1 sector=0x1 cyl_lo=0x0 cyl_hi=0x0 init_drive: error=0x1 status=0x50 status2=0x50 init_drive: Identify drive: atapi=0 install_ata_disk_driver: return no error (0) install_ata_disk_driver: reg=0x1000 init_drive: allow 4-bits for heads init_drive: select drive 1 init_drive: seccnt=0x0 sector=0x1 cyl_lo=0x0 cyl_hi=0x0 init_drive: error=0x0 status=0x0 status2=0x0 ATA-wait-ready: timeout: status=0x0 init_drive: failed install_ata_disk_driver: reg=0x1010 init_drive: reset controller 0x1010/0x101E init_drive: allow 4-bits for heads init_drive: select drive 0 init_drive: seccnt=0x1 sector=0x1 cyl_lo=0x14 cyl_hi=0xEB init_drive: error=0x1 status=0x0 status2=0x0 init_drive: Identify drive: atapi=1 atapi_cmd: cmdlen=12 atapi_cmd: inlen=8 len=65534 install_ata_disk_driver: return no error (0) install_ata_disk_driver: reg=0x1010 init_drive: allow 4-bits for heads init_drive: select drive 1 init_drive: seccnt=0x0 sector=0x0 cyl_lo=0xFE cyl_hi=0xFF init_drive: error=0x1 status=0x0 status2=0x0 ATA-wait-ready: timeout: status=0x0 init_drive: failed usb_ohci: paddr=0xFD06E9A plen=20 usb_ohci: phys=0x2005810.0x0.0xA0000000 size=0x0.0x1000 ret=no error usb_ohci: phys=0x2005810.0x0.0xA0000000 size=0x0.0x1000 usb_ohci: regs=0xA0000000 usb_ohci: pci_dma_alloc ret=0 usb_ohci: pci_dma_map_in ret=0 usb_ohci: dma=0xFD5F000 busdma=0xFD5F000 usb_ohci: hcca=0xFD5F000 hccadma=0xFD5F000 dma=0xFD5F100 busdma=0xFD5F100 usb_ohci: data-bufs: dma=0xFD60000 busdma=0xFD60000 usb_ohci: final: dma=0xFD60770 bufdma=0xFD60770

Z instrukcji jakiegoś chińskiego badziewia MP3 z hipermarketu: The player has a capacity of up to 100 files per folder. The first two letters of each filename must be numbered to Identify the position. Valid numbers are 01 to 99 and 00 for position 100. Amiga prawdopodobnie nie rozpoznaje tego ograniczenia. Doprawdy, powód do rulezowania niesamowity i okazja do tworzenia legend ludowych wspaniała. Ostatnia modyfikacja: 22.03.07 07:18

Pleas Identify the symbols on page: (i w tym miejscu jest losowy nr strony). Symbole klikam "na pałę", bo nie mam żadnej ściągi. Myślę, że dlatego nie działa zapis. Czy mam rację? A może ktoś ma książeczkę z tymi symbolami A może wypadałoby się zainteresować oryginałem, bo z formy tej wypowiedzi wnioskuję, że kolega nawet nie wie co to jest.

To prawda, sam ją zaczynałem kilka razy, jednakże ostatnia w miom przypadku nie należała do najtrudniejszych. Ponieważ nie działał mi zapis grałem rozgrywki od początku do końca, niektóre po 5-6 godzin, a i tak po przejściu ostatniej czułem ogromny niedosyt. A tak nawiasem - dlaczego nie działa zapis? Mam Settlersów na PC i też nie zapisuje rozgrywki. Zawsze sądziłem, że problem tkwi w błędnie wprowadzonych symbolach na pierwszej stronie po uruchomieniu gry? Pleas Identify the symbols on page: (i w tym miejscu jest losowy nr strony). Symbole klikam "na pałę", bo nie mam żadnej ściągi. Myślę, że dlatego nie działa zapis. Czy mam rację? A może ktoś ma książeczkę z tymi symbolami :?:

Zadalem sobie trud i przepisalem caly ostatni ekran :) --- TCP reno registered. ip-conntrack version 2.4 (2048 buckets, 16384 max) - 212 bytes per conntrack. TCP bic registered. Initializing IPsec netlink socket. NET: Registered protocol family 1. NET: Registered protocol family 17. NET: registered protocol family 15. NET: Registered protocol family 5. RAMDISK: Compressed image found at block 0. VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 232k init. EXT2-fs Warning: mounting unchecked fs, running e2fsck recomended. input: AT Translated set 2 keyboard as /class/input/input0. VFS: Can't find ext3 filesystem on dev hda1. VFS: Can't find ext2 filesystem on dev hda1. Unable to Identify CD-ROM format. HFS+-fs: unable to find HFS+ superblock. VFS: Can't find a HFS filesystem on dev hda1. AFFS: No valid root block on device hda1. input: ImPS/2 Generic Wheel Mouse as /class/input/input1. UDF-fs: No VRS found. mount: Mounting /dev/hda1 on /booty failed: invalid argument mount: /booty/mol-data: No such file or directory. mount: Could not setup loop device. Detecting PCI hardware... /linuxrc: 37: /usr/local/sbin/pcimodules: not found. /linuxrc: 47: /bin/bash: not found. Welcome to bash! exec: 53: /usr/local/bin/bash: not found. Kernel panic - not syncing: Attempted to kill init! Rebooting in 180 seconds... --- Tak sie zastanawiam, czy ja nie powinienem najpierw stworzyc jakiejs linuxowej partycji dla tego MOLKa? niektórzy pouruchamiali już MOLKa na Pegach1, na których podobno moga byc problemy, a ja mam Pega2 i stoje w miejscu :/

No i okazaîo sië űe korzysta z kilkunastu bibliotek - min. z mmu.library. Po wyrzuceniu tej biblioteki z Libs: jest ok, Scout dziaîa tak jak powinien i nie wiesza sië :D Dziëki! :)

Sprawdź z jakich innych bibliotek korzysta Identify.library. Przykładowo obecność mmu.library w LIBS:, jeśli cały pakiet MMU nie jest poprawnie zainstalowany, może powodować zawieszenia. Dopóki w UAE nie dorobią mmu.resource, żadna instalacja mmu.library nie będzie pod takim systemem poprawna.

Jest od identyfikacji sprzętu, korzysta z niej min. Scout (tzn. opcjonalnie)... :roll:

Z aminetu pociągnij jakieś inne wersje niż posiadasz,o ile się orientuję to chyba od packerów jest ta biblioteka ?! :mrgreen:

Orientuje się ktoś jaka wersja Identify.library działa pod WinUAE (o ile wogóle jakaś działa). U mnie poprostu każdy program korzystający z tej biblioteki wiesza się :cry: