1,401 Odpowiedź przez Adam Klobukowski

(140 odpowiedzi, napisanych Bałagan)

Bo w Polsce karty pojawiły się dopiero po 1990, a masową popularność zdobyły po 2000. Dlatego można u nas od razu postawić na nowoczesną infrastrukturę i nowoczesne usługi. W krajach 'zachodnich' jest pod tym względem zacofanie, bo nie są chętni do ponoszenia kosztów wymiany starych urządzeń na nowe, szczególnie dopóki stare jeszcze działają. Dlatego w Polsce usługi bankowe stoją na jednym z najwyższych poziomów na świecie.

Idź do forum: Bałagan

1,402 Odpowiedź przez Adam Klobukowski

(24 odpowiedzi, napisanych Programowanie - 16/32bit)

Pytanie było o kompilatory dla Atari, nie dla PC.

Idź do forum: Programowanie - 16/32bit

1,403 Odpowiedź przez Adam Klobukowski

(24 odpowiedzi, napisanych Programowanie - 16/32bit)

Tylko że GCC na ST jest nieużywalne, a na Falconie i TT dopiero ma sens jak masz TT Ram.

AHCC jest specjalnie przygotowane do pisania oprogramowania na Atari i jest ciągle wspierane prze autora. To że iny ma 16 bitów to nie problem, bo jest jeszcze long int.

Idź do forum: Programowanie - 16/32bit

1,404 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,405 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,406 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,407 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,408 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,409 Odpowiedź przez Adam Klobukowski

(6,411 odpowiedzi, napisanych Kolekcjonowanie)

Zdecydowanie nie ;)

Idź do forum: Kolekcjonowanie

1,410 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,411 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,412 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,413 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,414 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,415 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,416 Odpowiedź przez Adam Klobukowski

(140 odpowiedzi, napisanych Bałagan)

Możesz pozwać za oszczerstwo.

Idź do forum: Bałagan

1,417 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,418 Odpowiedź przez Adam Klobukowski

(140 odpowiedzi, napisanych Bałagan)

Nie chodzi o obrazę, ale o dyskryminację.

Idź do forum: Bałagan

1,419 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,420 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,421 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,422 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,423 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,424 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,425 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