1,376 Odpowiedź przez Adam Klobukowski

(198 odpowiedzi, napisanych Sprzęt - 16/32bit)

Sikor napisał/a:

A widziałeś krótkie powyżej 4MB?

Mam 16MB. Używane były w Macach 68K i drukarkach. To był maks.

Idź do forum: Sprzęt - 16/32bit

1,377 Odpowiedź przez Adam Klobukowski

(17 odpowiedzi, napisanych Emulacja - 16/32bit)

Od zmiany emulatora na Aranym, ten jest można rzec 'dedykowany' dla FreeMiNTa, i działa bezproblemowo nawet na procesorach z architekturą little endian :D

Idź do forum: Emulacja - 16/32bit

1,378 Odpowiedź przez Adam Klobukowski

(17 odpowiedzi, napisanych Sprzęt - 16/32bit)

Cyprian napisał/a:

PIC jest na pokładzie (chyba dla RTC) ale FPGA również:

Nie chodziło mi że nie ma FPGA, tylko że ostatniu dołączył człowiek od PICa.

marekp napisał/a:

WD1772 FDC: The Floppy Disk Controller, including support for HD floppies.
Jak by to się dało "dokleić" do MISTa... Oj siadła by mi prawdziwa stacja.

A gdzie byś ją wpiął?

marekp napisał/a:

YM2149: The well known ST sound chip
Czy to może ten sam co w MIST? Ktoś może słuchał gier/muzyki z firebee? W MIST nie jest z tym najlepiej :-(

Nie wiem na 100%, ale zakładam że emulacja YM2149 pochodzi z projektu Suska. Nie wiem skąd jest w MiST.

Idź do forum: Sprzęt - 16/32bit

1,379 Odpowiedź przez Adam Klobukowski

(17 odpowiedzi, napisanych Sprzęt - 16/32bit)

Nie FPGA a PIC, to pewna różnica ;) PIC w FireBee nie wpływa bezpośrednio na kompatybilność - głównie zapewnia komunikację z urządzeniami zewnętrznymi.

Praca nad FPGA trwa cały czas, ale nie jest to łatwe.

Idź do forum: Sprzęt - 16/32bit

1,380 Odpowiedź przez Adam Klobukowski

(16 odpowiedzi, napisanych Emulacja - 16/32bit)

To pewnie problem wynikający z konwersji little/big endian ;)

Idź do forum: Emulacja - 16/32bit

1,381 Odpowiedź przez Adam Klobukowski

(6,333 odpowiedzi, napisanych Kolekcjonowanie)

Zdecydowanie nie ;)

Idź do forum: Kolekcjonowanie

1,382 Odpowiedź przez Adam Klobukowski

(188 odpowiedzi, napisanych Software, Gry - 16/32bit)

swinkamor12 napisał/a:
Adam Klobukowski napisał/a:

To przedstaw cokolwiek co demonstruje ten problem, bo my twierdzimy że go nie ma.

Proszę bardzo

http://dev-docs.atariforge.org/files/CO … V2_AES.pdf

Strona 164 przykładowy program dialog1.c jest wywoływanie funkcji z systemu,
skompiluj pod x86 żeby działało okienka niech się pokazują na emulowanym freemincie.
Skoro problemu nie ma to powinno to być proste.

Ale po co? AranyM z JITem robi to cały czas. Masz coś lepszego? Bo nadal nie ma problemu.

Idź do forum: Software, Gry - 16/32bit

1,383 Odpowiedź przez Adam Klobukowski

(188 odpowiedzi, napisanych Software, Gry - 16/32bit)

swinkamor12 napisał/a:
drac030 napisał/a:

Skoro jest taki idealny, to go sobie sam skompiluj, uruchom i poinformuj nas, w którym miejscu napotkałeś problem.

Nie zrozumiałeś. Ja twierdzę że się nie da bez dużego nakładu pracy.
Natomiast Adam Klobukowski że wymiana danych między x86 a x68k to nie problem.
Skoro nie problem to czekam aż weźmie i pokaże że to nie problem.

To przedstaw cokolwiek co demonstruje ten problem, bo my twierdzimy że go nie ma.

Idź do forum: Software, Gry - 16/32bit

1,384 Odpowiedź przez Adam Klobukowski

(198 odpowiedzi, napisanych Sprzęt - 16/32bit)

Takie nakładane adaptery są dosyć popularne. Mam taki na TT-Ramie do STE i w turbo do Amigi 600. W obu przypadkach działa i trzyma się bez problemów. Frak/Pak/Pupla to niezła kanapka, i jakoś się trzyma :)

Idź do forum: Sprzęt - 16/32bit

1,385 Odpowiedź przez Adam Klobukowski

(188 odpowiedzi, napisanych Software, Gry - 16/32bit)

swinkamor12 napisał/a:
Adam Klobukowski napisał/a:

Nie mam kompilatora dla ppc, ani całej reszty potrzebnych do tego narzędzi. Ty masz, juuż orezentowałeś kawałek kodu, w czym problem z resztą?

Pomysły typu dekompilacja standardowej funkcji z stdio to żart.
Nie wiem czego chcesz tam szukać. To po prostu działa.
Powerpc bez problemu sięga do danych 32 bit z adresu niepodzielnego przez 4.
Jeśli się to nie zgadza z twoimi wyobrażeniami o powerpc, cóż twój problem.
A skąd pomysł, że powerpc ma jakieś z tym problemy?

http://www.freescale.com/files/product/ … FPE32B.pdf
4.1.5: "(...)An attempt to access memory with an effective address alignment that is invalid for the instruction
causes the alignment interrupt handler to be invoked(...)"

swinkamor12 napisał/a:
Adam Klobukowski napisał/a:

Znam ten 'problem' wymiany danych z praktyki, przerabiałem go wielokrotnie, jak większość programistów.
Napisałem sporo kodu który musiał zmagać się z konwersją little/big endian i nie rozumiem twojego problemu. Więc wytłumacz mi na konkretnym przykładzie - na czym polega problem? Pokaż ten strasznie skomplikowany, trudny, powolny kod.

Proszę bardzo:
Napisz program w C pod x86 który otworzy okienko na emulowanym freemincie 68k,
po czym będzie coś tam rysował, okienko da się przesuwać będzie reagował na klawisze, mysz,
plus oczywiście będzie korzystał z jakiś kontrolek.

O tu powiedzmy na początek:

http://dev-docs.atariforge.org/files/CO … V2_AES.pdf

strona 84 program scroll.c

A potem powiedzmy coś z drzewkami

strona  125 object.c

Nie nic tu nie tłumaczysz. Pokaż mi swój kod, albo jakikolwiek kod, na którym możesz zademonstrować problem. Nie 'napisz se kod', bo ja już trochę kodu w życiu napisałem. Wskaż mi konkretny kawałek kodu gdzie ten 'problem' występuje i wytłumacz dlaczego tak jest.

Idź do forum: Software, Gry - 16/32bit

1,386 Odpowiedź przez Adam Klobukowski

(188 odpowiedzi, napisanych Software, Gry - 16/32bit)

swinkamor12 napisał/a:
Adam Klobukowski napisał/a:

Ważny jest kod skompilowany do asemblera.

To chyba żart. Jeśli masz z funkcją printf problem ściągnij źródła ze strony MOS team i sam skompiluj do asemblera.

Nie mam kompilatora dla ppc, ani całej reszty potrzebnych do tego narzędzi. Ty masz, juuż orezentowałeś kawałek kodu, w czym problem z resztą?

swinkamor12 napisał/a:

Skoro nie rozumiem, to mi wytłumacz.

Nie ma problemu. Napisz program pod x86 który otworzy okienko na emulowanym freemincie 68k,
po czym będzie coś tam rysował, okienko da się przesuwać będzie reagował na klawisze, mysz.
Po praktycznym zapoznaniu się z problemem wymiany danych z pewnością zmienisz zdanie o powerpc.

Znam ten 'problem' wymiany danych z praktyki, przerabiałem go wielokrotnie, jak większość programistów. Napisałem sporo kodu który musiał zmagać się z konwersją little/big endian i nie rozumiem twojego problemu. Więc wytłumacz mi na konkretnym przykładzie - na czym polega problem? Pokaż ten strasznie skomplikowany, trudny, powolny kod.

Idź do forum: Software, Gry - 16/32bit

1,387 Odpowiedź przez Adam Klobukowski

(16 odpowiedzi, napisanych Emulacja - 16/32bit)

Bez TOSa 3.0x to nie zadziała.

Idź do forum: Emulacja - 16/32bit

1,388 Odpowiedź przez Adam Klobukowski

(140 odpowiedzi, napisanych Bałagan)

Możesz pozwać za oszczerstwo.

Idź do forum: Bałagan

1,389 Odpowiedź przez Adam Klobukowski

(17 odpowiedzi, napisanych Sprzęt - 16/32bit)

Tak, ale na FireBee pójdzie na FireBee ;)

Idź do forum: Sprzęt - 16/32bit

1,390 Odpowiedź przez Adam Klobukowski

(140 odpowiedzi, napisanych Bałagan)

Nie chodzi o obrazę, ale o dyskryminację.

Idź do forum: Bałagan

1,391 Odpowiedź przez Adam Klobukowski

(17 odpowiedzi, napisanych Sprzęt - 16/32bit)

skrzyp napisał/a:
Adam Klobukowski napisał/a:

Gry z Atari ST w 95% nie pójdą na FireBee. Można za to na FireBee uruchomić Hatari które działa w wystarczającą prędkością :)

To bez sensu, po co więc kupować FireBee, skoro Hatari pójdzie na dowolnym innym komputerze?

Bo pójdzie sporo innego softu, ST to nie tylko gry.

Idź do forum: Sprzęt - 16/32bit

1,392 Odpowiedź przez Adam Klobukowski

(188 odpowiedzi, napisanych Software, Gry - 16/32bit)

swinkamor12 napisał/a:
Adam Klobukowski napisał/a:

Brak kodu funkcji fprintf.

Kod funkcji fprintf do ściągnięcia ze strony MOS team.

Ważny jest kod skompilowany do asemblera.

swinkamor12 napisał/a:

W kodzie który przesłałeś nie ma żadnego dostępu pod adres niepodzielny przez 4.

Jest tylko ty nie potrafisz znaleźć.
Mimo że masz w dumpie z kompilatora również linie z c.
Twoja wiedza o powerpc jest za mała.

To wskaż mi proszę, w której linii, w kodzie asemblerowym który pokazałeś, jest dostęp do adresu niepodzielnego przez 4.

swinkamor12 napisał/a:

No, nikt nie zrobił, poza autorami emulatorów takich jak WinUAE, Aranym, Hatarai i wielu innych. To o czym piszesz nie ma nic wspólnego z konwersją little/big endian, to po prostu generowanie stubów dla bibliotek.

Cały czas nie wiesz o czym piszesz. Coś  ci się wydaje ale tylko wydaje.
Spróbuj użyć w kodzie x86 bibliotek z obecnego freeminta 68k, to zrozumiesz o co chodzi.

Ale jak już pisałem większość "ekspertów" którym PowerPc nie pasuje, nigdy tego nie widziała i nie używała.

Skoro nie rozumiem, to mi wytłumacz. Na początku pisałeś że nie pasuje endianess, to Ci BartoszP pokazał że PowerPC w najnowszej Amidze ma takie samo endianess jak Intel. Więc skoro endianess moze być inne niż na 68K, i masz te same 'problemy' z endianess które miałbyś na Intelu, to na czym polega przewaga PowerPC?

Idź do forum: Software, Gry - 16/32bit

1,393 Odpowiedź przez Adam Klobukowski

(17 odpowiedzi, napisanych Sprzęt - 16/32bit)

Gry z Atari ST w 95% nie pójdą na FireBee. Można za to na FireBee uruchomić Hatari które działa w wystarczającą prędkością :)

Idź do forum: Sprzęt - 16/32bit

1,394 Odpowiedź przez Adam Klobukowski

(188 odpowiedzi, napisanych Software, Gry - 16/32bit)

swinkamor12 napisał/a:
Adam Klobukowski napisał/a:

Pokaż wygenerowany kod w asemblerze, łącznie z funkcją printf, to będziemy mogli o tym dyskutować.

A proszę bardzo kod w asemblerze, plus dump z kompilatora z dodatkowymi informacjami.

Brak kodu funkcji fprintf. W kodzie który przesłałeś nie ma żadnego dostępu pod adres niepodzielny przez 4.

swinkamor12 napisał/a:

Tobie do jakiegokolwiek kombinowania brakuje podstawowej wiedzy.

Wydaje ci się że obejdziesz problem konwersji danych be <-> le kombinowaniem z kodem emulatora.
Niestety tak ci się tylko wydaje. Byli już tacy co kombinowali tak jak ty i im też nie wyszło.
A na powerpc (i na innych be pewnie też tylko na razie nikt nie zrobił) sprawa jest bardzo prosta:
generuje się jeden nowy plik jedną linia w shellu i już można korzystać w programie pod powerpc,
z biblioteki 68k tak jakby była natywna w kodzie powerpc.

No, nikt nie zrobił, poza autorami emulatorów takich jak WinUAE, Aranym, Hatarai i wielu innych. To o czym piszesz nie ma nic wspólnego z konwersją little/big endian, to po prostu generowanie stubów dla bibliotek.

Idź do forum: Software, Gry - 16/32bit

1,395 Odpowiedź przez Adam Klobukowski

(140 odpowiedzi, napisanych Bałagan)

YERZMYEY/HOOY-PROGRAM napisał/a:

PS: Czyli nikt nie kojarzy, czy ta nasza VISA Electron będzie tam honorowana / będzie działała?
.

Nie powinno być problemu. Nie wiem na ile jedziesz, ale rozważ założenie konta w USD i zrobienie karty do niego rozliczanej bezpośrednio w USD, bo inaczej dużo stracisz na wielokrotnych przewalutowaniach. I nie zgadzaj się nigdy w bankomatach (oni to nazywają ATM) na to żeby ci bankomat przeliczał w lokalnej walucie, bo wtedy będziesz miał łańcuch przewalutowań, nawet jak zapłacisz kartą rozliczaną w USD.

No i na wniosku o wizę na pytanie czy jesteś terrorystą, odpowiedz że nie ;)

Idź do forum: Bałagan

1,396 Odpowiedź przez Adam Klobukowski

(188 odpowiedzi, napisanych Software, Gry - 16/32bit)

swinkamor12 napisał/a:
Adam Klobukowski napisał/a:

nadal porównujesz na jednym kod emulowany, a na drugim nartyny.

Zgadza się w obu przypadkach kod big endian.

To słabo sprawdziłeś. Na PowerPC, próba odczytania 32 bitowej wartości z adresu który nie jest podzielny przez 4 spowoduje błąd, na 680x0 możesz sobie czytac 32 bitowe wartości spod adresów podzielnych przez 2, a na 68020+ spod dowolnego adresu (tu musi być jednak wsparcie płyty głównej, i Amiga jest chyba w tym temacie ułomna)

Nie wiem skąd masz te informacje. Na moim G4 działa.

MOSRoot:test_da> type test.cpp

#include <stdio.h>

int main()
{

        int a[2]={0x01020304,0x05060708};
        char *p0=(char*)a;
        p0=p0+2;
        int *b=(int*)p0;
        fprintf(stdout,"%x\n",a);
        fprintf(stdout,"%x\n",p0);
        fprintf(stdout,"%x\n",b);
        int c=b[0];
        fprintf(stdout,"%x\n",c);
        return  0;
}

MOSRoot:test_da> gcc test.cpp -o test

MOSRoot:test_da> test

2d45e178

2d45e17a

2d45e17a

3040506

MOSRoot:Instalki/test_da>

W tym kodzie nie ma nic, co by wymuszało wygenerowanie przez kompilator odczytu słowa 32 bitowego spod adresu niepodzielnego przez 4.
Pokaż wygenerowany kod w asemblerze, łącznie z funkcją printf, to będziemy mogli o tym dyskutować.

swinkamor12 napisał/a:

Nie ma znaczenia jakie dane. Emulator przy odczycie konwertuje little-big endian wszystkie dane, bo tak się ich spodziewa aplikacja.
I nie ma znaczenia czy to będzie grafika, muzyka, tekst, czy cokolwiek innego.

Nie, tobie się wydaje że będzie działać zawsze. Niestety tylko tak ci się wydaje.
Jak będziesz ładować jako long i zmieniać kolejność bajtów przy ładowaniu,
gdy nie jest to potrzebne to stary kod nie będzie działać. 
Przy np danych graficznych dostaniesz sieczkę na ekranie.

W zaemulowanym środowisku nie ma to znaczenia. Emulowana aplikacja widzi wszystko w takim endianess w jakim się spodziewa i nie ma znaczenia jakie to dane, bo emulator nie ma szklanej kuli i nie potrafi powiedzieć czy $BAADCODE to początek sampla, element grafiki czy może kod.

swinkamor12 napisał/a:
Adam Klobukowski napisał/a:

Poczytaj trochę jak to działa, to przestaniesz rozpowiadać nieprawdę.

Myśmy już takich widzieli co to kombinowali tak jak ty.
Niestety okazało się że czasami działa ale nie zawsze.

Tobie do jakiegokolwiek kombinowania brakuje podstawowej wiedzy.

Idź do forum: Software, Gry - 16/32bit

1,397 Odpowiedź przez Adam Klobukowski

(188 odpowiedzi, napisanych Software, Gry - 16/32bit)

swinkamor12 napisał/a:
Adam Klobukowski napisał/a:

Nie porównujesz szybkość kodu emulowanego z natywnym na różnych platformach.

Zgadza się w obu przypadkach kod big endian.

Zmieniasz front, bo Ci BartoszP wtyknął? To nadal nie ma znaczenia, to są zupełnie inne procesory i nadal porównujesz na jednym kod emulowany, a na drugim nartyny.

swinkamor12 napisał/a:
Adam Klobukowski napisał/a:

No własnie nie zawsze, bo choćby na PowerPC masz problem z data aligment - odczyt danych spod adresu który pod 68K zadziała
bezproblemowo, na PowerPC wywróci aplikację.

Aż sprawdziłem te rewelacje. Masz złe informacje. Na PowerPC działa bez problemu.

To słabo sprawdziłeś. Na PowerPC, próba odczytania 32 bitowej wartości z adresu który nie jest podzielny przez 4 spowoduje błąd, na 680x0 możesz sobie czytac 32 bitowe wartości spod adresów podzielnych przez 2, a na 68020+ spod dowolnego adresu (tu musi być jednak wsparcie płyty głównej, i Amiga jest chyba w tym temacie ułomna)

swinkamor12 napisał/a:

Big/little endian nie powoduje żadnej komplikacji - poza ta którą ty tu wymyślasz. Little endian, big endian - nie ma żadnej różnicy pod względem łatwości emulacji.
Jak jesteś takim praktykiem, to pokaż proszę praktyczny przykład gdzie to sprawia problemy.

Dane tekstowe, dane graficzne.
Nie wiesz czy ładując 4 bajty spod danego adresu, powinieneś je zamienić czy nie.
Amigowe c2p na przykład.

A bez przeróbek na procesorze big endian będzie działać zawsze.

Nie ma znaczenia jakie dane. Emulator przy odczycie konwertuje little-big endian wszystkie dane, bo tak się ich spodziewa aplikacja. I nie ma znaczenia czy to będzie grafika, muzyka, tekst, czy cokolwiek innego.

Co więcej, pomijając emulatory, praktycznie każdy transfer danych przez internet jest robiony w big-endian (większość protokołów sieciowych przesyła bajty w kolejności big endian). I każda aplikacja na każdej platformie sobie z tym doskonale radzi i nie musi wiedzieć nic na temat danych które transferuje. Poczytaj trochę jak to działa, to przestaniesz rozpowiadać nieprawdę.

Idź do forum: Software, Gry - 16/32bit

1,398 Odpowiedź przez Adam Klobukowski

(140 odpowiedzi, napisanych Bałagan)

- a na mc royala mówią ćwierćfunciak z serem ;)

Idź do forum: Bałagan

1,399 Odpowiedź przez Adam Klobukowski

(188 odpowiedzi, napisanych Software, Gry - 16/32bit)

swinkamor12 napisał/a:
Adam Klobukowski napisał/a:

Takie że porównujesz samochód z drzewem.

Porównuje szybkość wykonywania kodu big endian z szybkością wykonywania kodem big endian czyli samochód z samochodem.

Nie porównujesz szybkość kodu emulowanego z natywnym na różnych platformach.

swinkamor12 napisał/a:

Nie w teorii, ale w praktyce. Widziałem kod emulatora, pisałem kod emulatora i uruchamiałem wiele emulatorów.

W teorii oczywiście. Niestety praktyka tu się rozmija z teorią.

Nie, wszystko to robiłem w praktyce.

swinkamor12 napisał/a:

Ludzie nie piszą idealnego kodu i mają różne dziwne pomysły.
Np przepisywanie stringów po 4 bajty żeby było szybciej.
Ładowanie danych graficznych do rejestrów procesora po 4 bajty.
itp itd.

A jak nie trzeba przerabiać danych to działa zawsze.

swinkamor12 napisał/a:

No własnie nie zawsze, bo choćby na PowerPC masz problem z data aligment - odczyt danych spod adresu który pod 68K zadziała
bezproblemowo, na PowerPC wywróci aplikację.

swinkamor12 napisał/a:

Dlatego powerpc jest takie fajne.

Big/little endian nie powoduje żadnej komplikacji - poza ta którą ty tu wymyślasz. Little endian, big endian - nie ma żadnej różnicy pod względem łatwości emulacji. Jak jesteś takim praktykiem, to pokaż proszę praktyczny przykład gdzie to sprawia problemy.

Idź do forum: Software, Gry - 16/32bit

1,400 Odpowiedź przez Adam Klobukowski

(188 odpowiedzi, napisanych Software, Gry - 16/32bit)

swinkamor12 napisał/a:
Adam Klobukowski napisał/a:

Czyli porównujesz emulowany na i7 do natywnego. Nie wiesz o czym mówisz.

Ale kogo to obchodzi czy emulowany czy nie?
Co to ma za znaczenie?
Liczy się tylko że natywny kod G4 big endian jest szybszy niż emulowany kod big endian na i7.

Takie że porównujesz samochód z drzewem.

swinkamor12 napisał/a:

Widziałeś na oczy kod źródłowy jakiegokolwiek emulatora? Ja widziałem kilku. Konwersja little-big endian jest trywialną operacją i  w aboslutnie znikomy sposób komplikuje sam emulator. Nie jest to żaden problem

Czyli widziałeś kod źródłowy jakiegoś emulatora i ci się wydaje Konwersja little-big endian jest trywialną operacją.

W teorii oczywiście. Jak rejestry są pod stałym adresem to pewnie tak.

Nie w teorii, ale w praktyce. Widziałem kod emulatora, pisałem kod emulatora i uruchamiałem wiele emulatorów. Nie wiem o jakich 'rejestrach' tutaj mówisz.

swinkamor12 napisał/a:

Ale w praktyce to tylko ci się wydaje. Jak masz bardziej skomplikowane struktury danych to już nie jest to takie proste.

Na procesorach big endian można te problemy po prostu pominąć.

Nie ma potrzeby by robić dodatkową zupełnie niepotrzebną pracę przy pisaniu kodu który będzie dane przerabiał, lub dostawał się do nich w inny sposób.

Dlatego powtórzę jeszcze raz, powerpc jest lepsze dla amigi i atari niż x86.

W praktyce, jest to zupełnie pomijalny problem. Nie ma żadnej niepotrzebnej pracy, bo to jest kilka linijek kodu.

Idź do forum: Software, Gry - 16/32bit