14.07 20:28
[#152]
Re: PCMCIA GPU P-vision
@Phibrizzo, post #149
A sproboj jeszcze w ADoomie dodac parametry -rtg -directcgx.
W Amidze z p-Vision chwilowo siedzi Blizz1230 z FPU I MMU. Ale sprawdziłem te parametry na CSPPC 060/60MHz ZZ9000 i fpsy wzrosły z 5-6fps na 8-9fps. Granie już nie jest całkowicie masochistyczne.
ADoom ver 1.4.
15.07 11:57
[#157]
Re: PCMCIA GPU P-vision
@michal_zukowski, post #156
Z jednej strony taki Doom pod Arma na ZZ9000 to ciekawa sprawa, ale z drugiej strony zgadzam się - dobrze byłoby stworzyć jakiś pakiet w rodzaju WarpUP, oferujący zintegrowany system obsługi Armów pod AmigaOS. Wyposażony w multitasking i zarządzający zasobami. Trochę tych sprzętów* z jakimś Armem dla Amig powstało, i dobrze byłoby zunifikować to, bo bez tego będzie totalny miszmasz.
* mamy ZZ9000, Pistorm, Z3660, no i to śmieszne rozszerzenie RAM z dodatkowym Armem pod klapkę dla A500 - A514 czy jakoś tak się nazywa. Trochę tego już jest, a będzie pewnie więcej.
Ostatnia aktualizacja: 15.07.2026 11:57:33 przez wali7
* mamy ZZ9000, Pistorm, Z3660, no i to śmieszne rozszerzenie RAM z dodatkowym Armem pod klapkę dla A500 - A514 czy jakoś tak się nazywa. Trochę tego już jest, a będzie pewnie więcej.
Ostatnia aktualizacja: 15.07.2026 11:57:33 przez wali7
04.08 11:19
[#163]
Re: PCMCIA GPU P-vision
@wali7, post #157
Nie zunifikujesz. ZynQ ma słabiutkiego 32 bitowego Cortex A7, a PiStorm ma dużo mocniejsze 64bitowe Cortex A53 (pi3) lub A72 (pi4). Jakby ktoś coś zrobił na Agilex 5 SoC to mogłoby być nawet Cortex A76. W A314 z kolei jest RPi Zero (ARM11) albo znowuż Cortex A53 (rpi3, pizero2w). O ile coś można by było zrobić z tymi A53/A72 to jakoś nie wyobrażam sobie paczki scalającej A7 i ARM11 z w/w
Dodatkowo PiStorm leży na 68k bus. ZZ leży na Zorro II/III (co jest modyfikacją 68k local bus z dodatkami), A314 sieci głównie albo na ClockPort, albo na interfejsie DRAM rozszerzenia pod klapkę. Tego nie da się jakoś magicznie zunifikować wszystkiego skoro to różne generacje układów i na różnych interfejsach.
Dodatkowo PiStorm leży na 68k bus. ZZ leży na Zorro II/III (co jest modyfikacją 68k local bus z dodatkami), A314 sieci głównie albo na ClockPort, albo na interfejsie DRAM rozszerzenia pod klapkę. Tego nie da się jakoś magicznie zunifikować wszystkiego skoro to różne generacje układów i na różnych interfejsach.
24.08 12:29
[#164]
Re: PCMCIA GPU P-vision
@abcdef, post #163
Wszystko co napisałeś to doskonałe argumenty za stworzeniem takiego pakietu.
Chodzi właśnie o to, ze mimo iż mamy obecnie kilka projektów umożliwiających zamontowanie w Amidze 68k procesora z rodziny ARM, to różnorodność implementacji tego w hardware Amigi, oraz różnorodność samych ARMów uniemożliwia ich w miarę sensowne, zunifikowane oprogramowanie. Wspaniale to podsumowałeś.
Bo jeśli przykładowo ktoś stworzy dekoder mp3 pod ZZ9000, to nie zadziała on w A314, czy Z3660. A przecież każdy z tych Armów jest wystarczająco silny aby podołać temu zadaniu.
Mam na myśli niskopoziomowy pakiet, które rozpozna rodzaj hardware ARM w Ami, i za pomocą pakietu sterowników będzie w stanie zwrócić do systemu informacje o systemie ARM, zaalokować pamięć dostępną Armowi, wysłać binarkę do wykonania wraz z argumentami, a następnie zwrócić wyniki do AmigaOS. Dobrze by było, aby był w stanie zarządzać jakimś prymitywnym multitaskingiem wszystkich tych procesów pod Armem, lub przynajmniej zwrócić informację, że ARM jest zajęty i nie może podjąć zadania.
Dzięki temu, niezależnie od hardware ARM można by tworzyć oprogramowanie wykorzystujące te dużo szybsze od 68k procki. Bo nawet słabiutki ARM w ZynQ bije na głowę mocarny 68060.
Dokładnie tak by to mogło działać jak WarpOS dla PPC - można te same binarki PPC odpalić pod 603, czy 604 działających w architekturze UMA w kartach phase5, ale także na G3, albo G4 z własną pamięcią podpiętych przez PCI, a na natywnych systemach PPC w rodzaju MorphOS kończąc.
Chodzi właśnie o to, ze mimo iż mamy obecnie kilka projektów umożliwiających zamontowanie w Amidze 68k procesora z rodziny ARM, to różnorodność implementacji tego w hardware Amigi, oraz różnorodność samych ARMów uniemożliwia ich w miarę sensowne, zunifikowane oprogramowanie. Wspaniale to podsumowałeś.
Bo jeśli przykładowo ktoś stworzy dekoder mp3 pod ZZ9000, to nie zadziała on w A314, czy Z3660. A przecież każdy z tych Armów jest wystarczająco silny aby podołać temu zadaniu.
Mam na myśli niskopoziomowy pakiet, które rozpozna rodzaj hardware ARM w Ami, i za pomocą pakietu sterowników będzie w stanie zwrócić do systemu informacje o systemie ARM, zaalokować pamięć dostępną Armowi, wysłać binarkę do wykonania wraz z argumentami, a następnie zwrócić wyniki do AmigaOS. Dobrze by było, aby był w stanie zarządzać jakimś prymitywnym multitaskingiem wszystkich tych procesów pod Armem, lub przynajmniej zwrócić informację, że ARM jest zajęty i nie może podjąć zadania.
Dzięki temu, niezależnie od hardware ARM można by tworzyć oprogramowanie wykorzystujące te dużo szybsze od 68k procki. Bo nawet słabiutki ARM w ZynQ bije na głowę mocarny 68060.
Dokładnie tak by to mogło działać jak WarpOS dla PPC - można te same binarki PPC odpalić pod 603, czy 604 działających w architekturze UMA w kartach phase5, ale także na G3, albo G4 z własną pamięcią podpiętych przez PCI, a na natywnych systemach PPC w rodzaju MorphOS kończąc.