Zaxon, ale ty masz chyba wersję ze "patchowanym" ROM-em (dodatkowy EPROM z MyIDE OS-em w środku komputera). Ja mówiłem o wersji która się odpala z carta. Ona przepisuje ROM->RAM po czym dokonuje modyfikacji OS-ROM przepisanego do RAM. W tym wypadku dużo programów (np. wszystkie spakowane np. Cruncher-em 5.0 lub Code3 Cruncherem) nie ma szans odpalić. Przykłady można by mnożyć ale nie to jest moim celem.

Ja rozumiem iż MyIDE spokojnie wystarczy do odpalania gierek i nawet większości dem. Dla każdego według potrzeb. A że 90% użytkowników ATARI takie coś wystarcza to takie rozwiązanie jak MyIDE jest w stanie zapewnić to czego od interface oczekują... czyli szybkiedo załadowania gry/dema/programu. No i wszystko mają pod maską :) Nie trzeba angażować SIO2PC lub szukać dyskietek/kaset :)

[joke mode ON] Ale Bitter Reality i Overmind Ci nie działają :P[/joke mode OFF]

W przypadku wersji MaxFlash + MyIDE to byłaby paranoja. Nie można użyć RAM pod OS-ROM. Można chyba twierdzić iż 90% obecnych produkcji wykorzystuje te obszary pamięci. Co do zgodności z wersją z MyIDE OS-ROM. To chyba nie ma większego problemu. Jeżeli program nie ma własnego loadera i nie korzysta z własnych procedur transmisji (np. Overmind, Bitter Reality). To chyba wszystko powinno chodzić (chyba że coś wykorzystuje bezpośrednie skoki w OS-ROM).

pozdrawiam
Seban

Hej!

Z tego co pamiętam to chyba są dwie wersje. Jedna to elektronika (pakowana do środka komputera) + zmieniony OS-ROM. Druga to kombinacja cartridge MAX-Flash + Elektronika MyIDE zamknięta w jednej obudowie od carta. No i należy wspomnieć iż słowo "elektronika" to dużo powiedziane :) Jeden bufor i parę bramek :)

Co do wersji cartridge to myślę że skoro ma w środku FLASH to spokojnie może się z niego uruchomić jakiś software :) Może być tam również specjalnie spreparowana wersje MyDOS na potrzeby MyIDE.

Być może się mylę bo nigdy się tym interface jakoś nie interesowałem bardziej, więc większość tego co tu napisał to moje domysły.

pozdrawiam
Seban

@pirx: U mnie foobar pokazuje info o stream-ie pasku na dole, poniżej screen:

Skręcenie przewodów nie zapewnia żadnego zabezpieczenia przed przesłuchem, powiedziałbym iż nawet odwrotnie :) Dla takiego rodzaju kabla należy zastosować transmisję różnicową. W jednym kablu nadajemy normalny sygnał w drugim sygnał odwrócony w fazie o 180 stopni. W odbiorniku te sygnały zostają odjęte od siebie przez co zakłócenia które dostały się do kabla znoszą się w wyniku odjęcia sygnału normalnego i odwróconego w fazie o 180.

Samo zastosowanie takiego kabla nic nie da. Warstwa fizyczna (sprzętowa) musi być do takiego medium transmisyjnego dostosowana :) Właśnie warstwa fizyczna RS485 jest zrealizowana na zasadzie transmisji różnicowej.

http://pl.wikipedia.org/wiki/EIA-485

Tego nie wiedziałem :) zawsze unikałem "Illegal Opcodes" :) chyba że musiałem debugować jakiś super zabezpieczony kod przed debugowaniem :) ale nie pamiętam aby ktoś używał SBX :) Zresztą nazewnictwo "nielegalnych" mnemoników w tamtych zamierzchłych  czasach było raczej mocno różnorodne a do tego słabo udokumentowane :( No cóż człowiek uczy się przez całe życie :)

Coś mi się kiedyś wydawało iż nie wszystkie "illegal opcodes" działają identycznie na 6510 i 6502? Jestem w błędzie?

No i użycie SBX eliminuje wszystkich posiadaczy 65816 oraz 6502C.

pozdrawiam
Seban

bo to chyba "6510 undocumented OPCODE" ;)  http://www.zimmers.net/anonftp/pub/cbm/ ... data/64doc

The 'SBX' ($CB) may seem to be very complex operation, even though it
is a combination of the subtraction of accumulator and parameter, as
in the 'CMP' instruction, and the command 'DEX'. As a result, both A
and X are connected to ALU but only the subtraction takes place. Since
the comparison logic was used, the result of subtraction should be
normally ignored, but the 'DEX' now happily stores to X the value of
(A & X) - Immediate.  That is why this instruction does not have any
decimal mode, and it does not affect the V flag. Also Carry flag will
be ignored in the subtraction but set according to the result.

a ten link jest niezły: (chodzi mi o katalog w którym się znajduje ;] )

http://ftp.pigwa.net/stuff/collections/ ... PUdocs.txt

:D

Zaxon: mam go na tapecie, niebawem info. Z paskami problem mam - nie mogę podobnych namierzyć, na wolumenie nie mają nic pasującego :(
Miker: odezwę się niebawem, sprawa w toku :)

jest jeszcze jedno wyjście...

4) poprosić twórcę np. MagoTrans aby dodał pewną funkcjonalność do swojego programu :) W momencie kiedy w rekordzie danych wykryty zostanie segment INIT albo chociaż sekwencja bajtów ($e2,$02,$e3,$02) lub ($e0,02,$e3,$02) program musiał by generować dłuższą przerwę między rekordami w generowanym WAV-ie :)

pozdrawiam
Seban

Hej!

Jeszcze jedno... ponieważ Robbo w tej niespakowanej wersji miało ponad 44KB i wczytywanie tego z kasety to prawdziwa męka przygotowałem wersję spakowaną Exomizer-em, do pobrania tutaj. Plik ma około 15KB.

pozdrawiam
Seban

no właśnie nie ciszy :) Trzeba nadawać logiczną "1" czyli coś koło 5278Hz :D W dodatku trzeba by tak wcelować aby żadnego "pyknięcia" nie było :D Zajęcie karkołomne chyba raczej :D

Kurcze ja kiedyś napisałem kilka takich programów kopiujących, nawet dodawały loader ale ni cholery nie mogę znaleźć tego... mam jedynie szczątki źródeł "Cassette Protect Copy" który kiedyś napisałem dla Sikora... on też dodawał przerwy odpowiednie ale binarki znaleźć nie mogę a źródła się nie kompilują bo brakuje mi jakiejś mojej biblioteki której oczywiście na dyskietce nie ma :(

Panowie... zapewniam was że pliki nagrane w standardzie wymagają dłuższych przerw między rekordami w przypadku długo wykonujących się segmentów INIT. To była i jest norma, nie ma mowy o uszkodzonym sterowaniu silnikiem czy ręcznym robieniu pause. Swego czasu było sporo programów kopiujących dysk-taśma które o tym wiedziały i same robiły odpowiednie przerwy. Trzy posty wyżej zapodałem wam WAV-a zgranego z ATARI przy pomocy takiego kopiera (DT_COPY). Wersja z dłuższą przerwą po drugim rekordzie działa bezbłędnie. Loader "!" zatrzymuje silnik przed uruchomieniem segmentu INIT jednak jak już to pisałem powyżej bezwładność silnika magnetofonu nie pozwala na tak szybkie zatrzymanie się taśmy. Właśnie dlatego w przypadku zapisu programu przez LIST i wczytywaniu przez ENTER, system operacyjny dawał długie przerwy między rekordami aby magnetofon zdążył się zatrzymać po każdym wczytanym bloku.

W przypadku tego nieszczęsnego ROBBO tekst widoczny w czołówce po drugim rekordzie jest wypisywany "ultra szybką" procedurą "put char" z ROM-u Atari i trwa to całe wieki, dlatego po drugim rekordzie ładowanie się sypie (za krótka przerwa między 2 a 3 blokiem danych). Taka uroda zapisu na taśmie ;) Już chyba po prostu o tym zapomnieliście :)

Co do uszkodzenia występującego w przypadku KSO2000, które opisuje kolega Lt_Bri to osobiście się nie takim nigdy nie spotkałem ale jest ono bardzo prawdopodobne jeżeli ktoś dał za słaby tranzystor sterujący silnikiem na płytce KSO. Jeżeli tranzystor został uszkodzony i dostawał przebicia złącza C-E, wtedy działo by się tak jak napisał Lt_bri - silnik był cały czas włączony.

pozdrawiam
Seban

sprawdzę Ci jutro i dam znać.

UPDATE #1: Sprawdziłem twój plik WAV-e, problem jest dokładnie taki o jakim mówiłem, po drugim bloku loader uruchamia segment INIT niestety przerwa między rekordami jest za krótka i w momencie gdy już pokaże się czołówka "cracked by Mr.Bacardi" jest już pozamiatane bo taśma jest już w połowie kolejnego rekordu.

Wyjścia są dwa:

1) przygotować wav-a z odpowiednią przerwą
2) należy wywalić tą czołówkę (do niczego nie jest potrzebna)

Jak znajdę chwilę czasu przygotuję Ci nowego wav-a i wersję z wywaloną czołówką bez segmentów INIT.

UPDATE #2: Tutaj masz OGG-a z przerwą po drugim rekordzie, zgrałem z prawdziwego Atari przy pomocy prymitywnego interface skleconego na szybko (dwa rezystory i dwa kondensatory). Powinno działać, daj znać jak poszedł test. Plik do pobrania tutaj. Rozmiar ~11MB.

pozdrawiam
Seban