Przejdź do treści forum
atari.area
Twoje polskie źródło informacji o Atari
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Aktualności ze świata Atari
Aktualizacja firmware A8PicoCart Nowe wydanie oprogramowania dla taniego kartridża A8PicoCart z obsługą kolejnych typów cartów.
THE 800XL osiągnął status Gold! Zakończono prace nad oprogramowaniem dla THE800XL. Retro Games Ltd rozpoczyna etap produkcji.
PiST 0.11.0 Środowisko programistyczne PiST dla Atari ST doczekało się nowej wersji 0.11.0.
bm800xl 0.5.9 Emulator bm800xl dla Raspberry Pi zyskał szybszy start, scanlines i pełne stany pamięci.
xasm 3.3.0 i wtyczka do VSCode Po czteroletniej przerwie powraca asembler skrośny xasm.
Opcje wyszukiwania (Strona 66 z 196)
Jakby co to warto pisać na bezpośrednio do Stevena: https://sourceforge.net/p/steemsse/forum/bugs/
@MQ czy udało Ci się rozwiązać ten problem?
może faktycznie rozbebeszyć to za mocne słowo, ale jednak trzeba coś tam odlutować o przylutować
MapRAM to fajny pomysł no ale raczej jako ciekawostka.
Mq napisał/a:Cyprian, pełna zgoda, też tak myślę o standardzie i wszystko co powyżej 64k to już jest rozszerzenie.
Natomiast w kwestii co jest najlepszym wariantem na dzień dzisiejszy, to ja bym powiedział, że jak już ktoś ma chęć rozszerzać pamięć, to najlepiej zrobić to od razu do 1MB, bo to jest na dziś taka ilość RAM-u, która zapewni, że pójdzie nam na pewno wszystko co powstało i powstaje na jakiekolwiek rozszerzone konfiguracje. Jak dziś robić rozszerzenie, to 1MB warto też ze względu na to, że obojętnie jak bardzo rozszerzamy pamięć, to roboty jest mniej-więcej tyle samo, a koszt samego RAM-u praktycznie pomijalny, bo też nie będzie różnicy za dużej w cenie czy kupujemy 64k czy kupujemy 1MB, bo te pamięci po prostu stanowią dziś taki sam złom, więc raczej liczy się jego waga i koszt przesyłki niż ilość pamięci w scalaku:-)
słusznie
jeśli chodzi MapRAM to co jest lepsze: rozbebeszyć kompa by mieć dodatkowe 2kB vs rozbebeszyć kompa i mieć dodatkowy 1MB
Jak dla mnie, właściciela 800XL i 65XE, wymagane 128kB oznacza właśnie niestandardową konfigurację.
Tak więc, nie widzę tu różnicy pomiędzy wariantami 128kB, 320kB, 576kB czy 1MB, gdyż każdy z nich oznacza że trzeba dokupić rozszerzenie pamięci. Na dzień dzisiejszy najlepszy wariant to pewnie U1MB, chociaż całkiem sporo osób ma 320kB.
Oczywiście zakładam że w kwestii 128kB, szczęśliwy właściciel będzie miał odmienne zdanie 130XE.
kolega niechcący się wysypał
są odpowiedzi:
https://dhs.nu/bbs-scene/index.php?request=20152
ultra napisał/a:of course you can use every tos which is working on a 1040ste. in my video i use 2.06 at the very beginning. i even tried out emutos.
no i cacy
ultra napisał/a:st the pcb does not fit into a st. it would be possible with some soldering skills and some extra logic for OE signals (st uses 4 roms instead of 2).
but i'm not planning to do a st version.
tu nie rozumiem do końca, bo moje 1040STfm miało dwie kości ROM
laoo/ng napisał/a:Się dopisałem.
Bycie STkowcem jest nawet ekscytujące ;)
w sumie to bycie Atarowcem jest ekscytujące :)
mkm napisał/a:"A z cartidge? On już jest w pamięci widzianej przez procka, nie trzeba nic kopiować, można uruchomić bezpośrednio!"
Z zastrzezeniem, że nie zrobisz już sobie self modifing code co jest czestą optymalizacja. A jeśli chcesz to musisz się skopiować do ram'u tak czy inaczej.
o to ciekawe, chodzi o to że jeden bank mam za małą wielkość? Jeśli tak to czy nie można rozwinąć kod do paru banków i przełączać w locie?
tutaj jest wideo pokazujące ultraTos w działaniu:
http://ultradev.ultrafex.de/diary.html
Jest to szybkie:
Works pretty well flashing a new Tos needs about 8 seconds. It's also possible to erase a Tos.
Jeśli dobrze rozumiem to oprócz TOS 1.62/1.06 wspiera również TOS 2.x oraz 1.0/1.2/1.4
Tos 1.x is also supported. I'm using RamTos to relocate the 1.x Tos to STE Tos Rom space.
Ciekawe czy da radę (w sumie powinien) z tym "Falcon TOS on STe":
https://dhs.nu/bbs-scene/index.php?request=18862
@lewis
pod linkiem który zapodałem jest:
Preordering
ultraTos development is almost done. Needs some more testing.
The price for a fully build up PCB is 37 euro + shipping. Maybe I can optimise the price a bit still need to search cheaper sources for the components.
a nie było to np. spowodowane brakiem kompatybilności tych programów z 68030?
np. różne wersje językowe albo EmuTOS
w którym momencie następuje reset? jak zapisujesz konkretny rejestr SoundDMA?
nówka projekt
Cena 37 euro + wysyłka
Cechy:
- 6 różnych wersji TOS
- Wgrywanie nowego TOSa bezpośrednio z pulpitu Atari
- Wybór domyślnego TOSu jumperami
- Zmiana TOS i uruchomienie bez wyłączania Atari
- Wsparcie TOS 1.x
- Łatwa bezkablowa instalacja
http://ultradev.ultrafex.de/ultraTos.html
https://dhs.nu/bbs-scene/index.php?request=20147
Jest taki dodatek do PAK68/3- PuSTE czyli płytka/bufor dla STE:
Jakby co to ja chętnie przygarnę sztukę.
Tutaj ktoś sobie PuSTE zmontował:
https://www.atari-forum.com/viewtopic.p ... 85#p412285
mam odpowiedz od Hatari że demo używa całej dostępnej pamięci i co powoduje że gryzie się z emulacją GEMDOS w Hatari.
Czyli trzeba pisać do Leonarda
zobacz czy tego mojego image działa czy nie.
Ok pisz do Leonarda, ja teraz piszę do Hatari bo z dysku Gemdos zarówno dla 2MB jak i 4MB RAM nie działa ok.
W sprawie image napiszę później, jak dasz znać czy działa czy nie u Cebie.
grzybson napisał/a:Odgrzebuję temat - działa komuś We Were At z driverem PPutnika?
Próbowałem na:
* STE z 4MB RAM, TOS 1.62DE ACSI2STM
* emulator Hatari
* darmowy obraz P.Putnika, ten z grami
* obraz z ICD Pro skonfigurowany według wytycznych Pinokia.
Kreszuje się tuż przed Mandelbrotem, na obrazku z dziewczyną z falującymi włosami, na białym tle. Wersja FDD w tym czasie doładowuje sobie dane.
Efekt jak w załączniku - screen z Hatari:
Sprawdziłem właśnie w wersji beta Steem SSE v4.1.0 R0 i Hatari 2.3.1.
Gdy uruchamiam demo z dysku wirtualnego (GEMDOS drive) to Hatari pokazuje ten sam błąd, w Steem jest ok.
Gdy uruchamiam z obrazu dysku AHDI to oba emulatory mają ten sam błąd.
W załączniku obraz dysku 256MB z AHDI.
Zgłoszę ten błąd do autorów Hatari/Steem.
zamiast odgórnych ograniczeń wolałbym więcej produkcji na fabrycznego malucha
no i git.
spróbuj inny sterownik dysków, np HDDriver, bo ten Putnika jest ok ale specyficzny
laoo/ng napisał/a:Doczytałem jeszcze teraz dokumentację i rzeczywiście przeczytałem, że TOS przydziela zawsze wszystko, a mshrink (alternatywna nazwa setblock) rezerwuje konkretny obszar, więc nie ma tam mowy o zwiększaniu pamięci bo i tak na starcie ma się maksa.
Mshrink zmniejsza wielkość przydzielonego bloku
Malloc/Mxalloc rezwerwują obszar pamięci
tebe napisał/a:https://www.youtube.com/watch?v=QJYVW-78NOI&ab_channel=RetroGralnia
ciekawe spojrzenie na scenę XE/XL osoby z nią nie związanej z kanału youtube #Retrogralnia, prowadzi też Muzeum we Wrocławiu "MUZEUM GRY I KOMPUTERY MINIONEJ ERY"
RetroGralnia jest ok, ale to nagranie niestety przykro się ogląda.
Czego spodziewa się puszczając produkcje 256 bajtowe? Bo chyba nie efektów z C-Drug czy Numen
Jest to bezpieczna wielkość z mojej głowy.
Z tego co pamiętam to u mnie HDDriver z pamięcią cache zajmował około 64kB. TOS zajmuje również nie więcej niż kilkadziesiąt KB. Dodałem 200kB na jakieś akcesoria i wyszło mi 3.7MB
@laoo/ng Czy demo będzie korzystać z systemu operacyjnego (np.doładowywać dane z dysku)? Jeśli nie, to cała pamięć jest Twoja.
Jeśli jednak tak, to zaznacz w pliku tekstowym że demo wymaga np. 3,7MB. Użytkownik będzie mógł dostosować swoje środowisko do wymagań dezaktywując NVDI, zmniejszając ilość cache HDDrivera, wyłączając akcesoria itp.
Swoją drogą, na dużym Atari, często używane są programy do zarządzania profilami (typu XBoot) uruchamiania komputera, np pod Demo, pod aplikacje itp.
Znalezione posty [ 1,626 do 1,650 z 4,877 ]