Rozumiem też, że nie robiłeś w niej żadnych zmian. Asemblujesz madsem?
EDIT: u mnie działa zgodnie z oczekiwaniami, właśnie sprawdziłem na paru konfiguracjach (w tym na emulcu).
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
7th Annual Atari Homebrew Awards Oczywiście nie zabrakło polskich akcentów.
Wyniki FujiCup 2024 Sprawdź, czy były niespodzianki!
Mad Pascal 1.7.2 Optymalizacje, poprawki błędów oraz nowe funkcjonalności.
Tydzień na oddanie głosu w FUJICUP! Głosowanie potrwa tylko do 22 lutego 2025...
TURGEN 9.3.1 Najnowsza wersja oprogramowania TURGEN wprowadza kilka istotnych ulepszeń.
atari.area forum » Posty przez drac030
Rozumiem też, że nie robiłeś w niej żadnych zmian. Asemblujesz madsem?
EDIT: u mnie działa zgodnie z oczekiwaniami, właśnie sprawdziłem na paru konfiguracjach (w tym na emulcu).
A skąd waćpan owo "sparta_detect" wziąłeś? Z Atariki?
Coś udało się sklecić.
Jest dobrze! Reditus startuje i działa, a C-Drug działa z muzyką. Uwagi w skrzynce pocztowej :)
ten sam ram musi być widoczny w banku 0 oraz banku 1 procesora i tu jest właśnie ten problem.
Tak ściśle rzecz biorąc, wystarczyłoby zmirrorować stronę zerową. Może to coś ułatwia?
Przyczyną jest - przypuszczam, bo kodu nie oglądałem, jeno śmieci w pamięci - adresowanie z przekroczeniem granicy 64k. Np. zapis adresów $00-$02 w ten sposób:
ldx #$fd
loop:
lda costam-$fd,x
sta $ff03,x
inx
bne loop
Przy X=$FD, rozkaz STA $FF03,X robi zapis pod $010000 zamiast pod $000000 - nawet w trybie emulacji. I im dłużej o tym myślę, tym bardziej mi to wygląda na błąd w procesorze - w trybie emulacji "tradycyjne" rozkazy nie powinny móc przekroczyć granicy 64k ze względu na zgodność wstecz, a tymczasem przekraczają.
Rozwiązaniem mogłoby być ograniczenie w trybie emulacji dostępności RAM-u powyżej pierwszych 64k (w tym trybie jego użyteczność i tak jest dyskusyjna); np. w ten sposób, żeby było tam "widać" to samo, co w pierwszych 64k. I to jest pewno owo "postawienie na głowie zarządzania pamięcią" w karcie :)
Może da się spaczować. A może autor się znajdzie i poprawi?
Ok, podlinkowałem post w Atariki, żeby go było łatwiej znaleźć :)
Antic z natury rzeczy czyta z chipu. A CPU czyta z fastu, ale zapisuje do fastu _oraz_ do chipu. Zatem włączenie fastu w danym obszarze nie powinno robić Anticowi różnicy.
Nie mogę też odpalić Reditusa, który na 100% (jak praktycznie wszystko poza marginalnymi wyjątkami) działa na 65c816, a nie działa nawet w "trybie" $FF0080,$EF. Demo akurat ładuję z SIDE2 i ze sterownikiem side2.sys, lecz nie wydaje mi się by wyższe MemLo miało tu znaczenie, bo po przepaleniu w tych samych warunkach wspomnianego dema z 6502c program działa. Draco?? - Odpal to na swojej karcie z IDE+.
Reditus zamienia się w Exitus. :) Pewnie znowu podobna sprawa (dodatkowa pamięć).
Draco, możesz mi podlinkować opis Simiusa do posta z paczem do IDE+ - PCB rev. C???
Ke? Chyba nie, bo nie wiem, o co chodzi :P
Nie, nie. "Fast", który Pinokio włącza, jest to fast do odczytu. Zapisy spokojnie idą pod spód i docierają do Antica.
org $d301
lda #$ff
sta $d301
rts
W ten sposób ładujesz do $d301 wartość $a9 (czy może $d3). Hint: w obszarze rejestrów I/O nie umieszczamy kodu.
Daj tak (składnia MAC/65)
*=gdziekolwiek
init lda #$ff
sta $d301
rts
*= $02e2
.word init
A dalej własny program. Powinno zadziałać. BTW. dobrze byłoby jeszcze przestawić ramtop i zrobić gr.0, żeby przenieść pamięć obrazu, o ile jej używasz.
Sprawdziłem C-Drug na komputerze, gdzie jest 65C816 i dodatkowa pamięć, ale nie ma turbo. Dźwięk też skaszaniony - czyli psuje go obecność dodatkowego RAM-u. A raczej: 24-bitowa szyna adresowa, bo nawet gdyby nie było tam RAM-u, efekt byłby ten sam; ważne jest, że adresowanie się nie "zawija" do początku pamięci.
EDIT: co do "synchronizacji", nie ma różnicy, SI ciągle daje multiplier 0.997. W przypadku 65C816 taktowanego 1,77 MHz jest to czasami 0.997 a czasami 1. Zatem nawet jeśli jakaś różnica jest, jest minimalna.
Draco wygrzebałem właśnie z zakamarków swojej poczty zdjęcie z SI jakie kiedyś zrobiłeś jeszcze zanim dostałeś ode mnie kartę. Tam też jest multiplier 0.997.
Czyli są to raczej błędy pomiaru. Ergo nie ma o czym mówić.
Dla porządku sprawdzę jeszcze jaki jest efekt synchronizacji 16 i 1,77 MHz.
EDIT: co do C-Drug, niektóre programy (np. MyDOS) przestają działać prawidłowo w obecności dodatkowej pamięci powyżej 64k (bo, o ile dobrze pamiętam, np. lda $FFFF,X gdy X>0 wypada w dodatkowym RAM-ie zamiast na początku tradycyjnego). Może to ta przyczyna?
65c816:
Clock Speed: 1.769MHz
Clock multipliter: 0.997
No właśnie, przyjmując, że to nie jest błąd pomiaru,... sam sobie zadawałem ostatnio takie pytanie: jeśli włączymy pamięć Atari dla całych tradycyjnych 64k i wyłączymy "szybkie operacje wewnętrzne", mimo tego procesor nadal będzie taktowany zegarem 16 MHz, prawda? A 16 MHz nie da się podzielić przez wartość całkowitą tak, żeby uzyskać 1,773446 MHz. Zatem nawet w takim "kompatybilnym" trybie będą niewielkie straty (0,3 % jeśli wziąć pomiar SI za dobrą monetę) wynikające z konieczności synchronizacji zegarów. Mylę się?
Racja, pomyliło mi się z włączeniem. $FF zamiast $FD.
A gdzie w Atariki jest napisane coś, co mogłoby zostać tak zrozumiane? Skąd wziąłeś "3"?
Powinno być lda #$fd sta $d301.
Co do Atariki: http://www.atari.org.pl/forum/viewtopic … 49#p170049
Ja wcale nie jestem pewien, czy to była ta przyczyna, bo pod disasemblerem wszystko wyglądało zdrowo. W każdym razie mads nie powinien akceptować składni w rodzaju <etykieta i >etykieta (włączając w to #<etykieta i #>etykieta), jeśli "etykieta" jest adresem zdefiniowanym wewnątrz blk reloc albo blk empty.
I przyłączam się do sugestii mono, że .ds następujące od razu po blk reloc nie powinno generować podwójnych nagłówków, tylko wytworzyć pusty blok o odpowiedniej wielkości (i z zadanym w blk reloc atrybutem).
ten ENV, to za co w zasadzie odpowiada?
Dowiesz się, kiedy zobaczysz error 183 ;P
Nawiązałem kontakt z autorem, udostępnił mi źródłówkę i pozwolił zrobić fork. Można się zatem spodziewać "oficjalnej" wersji w rozsądnym czasie.
@ajcek: jak się poznajduje i pousuwa błędy, można będzie pomyśleć o dalszym rozwoju. Ale to nie nastąpi szybko :)
EDIT: wywala się copy/paste. Powalczę z tym kiedyś. Chwilowo w załączniku wersja z normalniejszym przypisaniem niektórych klawiszy (np. ctrl-g zamiast inverse-g).
Nic już dziś nie robię. Wesołych Świąt!
Jest coś takiego: http://singularcrew.hu/vi65/
Autor zrobił wersję dla Atari, ale do niczego się ona nie nadaje, bo jest zasemblowana pod adres $0800. Korzystając z chwili świętego spokoju zeźródłowałem wersję dla GR.0 i przerobiłem ją pod SDX. Dodałem mu też na początku ładowanie pliku wskazanego w linii komend:
vi65 [path>fname.ext]
Efekt w załączniku. Na oko działa, ale czy się gdzieś nie wysypuje, to jest jeszcze do stwierdzenia.
PS. Plikowi "zip" po ściągnięciu trzeba zmienić nazwę na "vi65.com".
w odpowiednim momencie zanim os stwierdzi że carta niema
Dobry zabobon z rana lepszy niż śmietana. Proponuję jeszcze robić to przy pełni księżyca spluwając przez lewe ramię. :D
O ile mowa o flaszerze SDX, on wyświetla "waiting" i czeka na kart przy wyłączonych przerwaniach. Zatem ani OS ani żadne "odpowiednie momenty" nie mają tu nic do rzeczy, można kart włożyć po godzinie i efekt będzie taki sam, jak przy włożonym po sekundzie.
Poza tym, gdyby przerwania były włączone, OS-owi "stwierdzenie, że karta nie ma" zajmuje 1/50 sekundy. Konia z rzędem temu, kto w tym czasie zdąży zrobić cokolwiek, o włożeniu kartridża w gniazdo nie wspominając.
tu candle, goscinnie od draca (nie mam pc)
jesli podstawowy ram atari jest uszkodzony - nic nie bedzie dzialac prawidlowo
wlacznie z zapisywyaniem/wczytywanie ustawien przez ultimate
ergo - wymien podstawowy ram
Głupio spytam - co takiego konkretnie powiązanego z IDE+ wykorzystuje IPLD?
Wykorzystuje - a w zasadzie wywołuje - loader binarny zaszyty w ROM-ie IDE+ :)
Czy któryś zakon ma w regule zakaz korzystania z internetu oprócz forów?
atari.area forum » Posty przez drac030
Wygenerowano w 0.126 sekund, wykonano 14 zapytań