Hej!

Z wielką chęcią przygarnę.

czy w pełni sprawny tego jeszcze go końca nie można na 100% powiedzieć, aby mieć 100% pewności uruchom test GTIA z SysInfo: http://drac030.krap.pl/pl-si-pliki.php

więcej info o możliwych wadach GTIA, tutaj: http://atariki.krap.pl/index.php/GTIA

wątek chyba dobry, s system już widziałem bo wcześniej Voy wklejał w tym wątku informację o nim... ale nie miałem jeszcze czasu się temu przyjrzeć, bo czeka jeszcze trochę sprzętów od uicr0Bee-ego w kolejce.

Posty Voy-a w których wrzucił informację o "Injektor" i jeszcze innych systemach:

http://www.atari.org.pl/forum/viewtopic … 60#p263060

http://www.atari.org.pl/forum/viewtopic … 67#p263067

Z ciekawości jak się już uporam z bieżącą kolejką to rozrysuję schemat tego "Injektora", wygląda na odmienne rozwiązanie od tych które do tej pory widziałem.

EDIT#1:
Zastanawia mnie natomiast jedna sprawa, na screen-shocie ze strony opisującej Injektora-a...

Widać jakiś program pod którym podpisał się "Michal Galinski", ktoś zna ten software? Wygląda na jakiś program kopiujący, ale nigdy wcześniej go nie widziałem. W dodatku wgląda jakby to był zwykły program kopiujący dysk <--> kaseta obsługujący jedynie "standard".

EDIT#2:
Nie za wiele rozumiem po hiszpańsku, jednak z instrukcji wynika, że używając programu Michała Galińskiego podczas konwersji standard ---> turbo, zapisu w turbo dokonuje się wybierając jako urządzenie wyjściowe stację dysków. Nie wiem jak ów program działa, ale można zgadywać że w systemie pewnie jest instalowany handler "D:" obsługujący zapis w turbo.
W sumie instrukcja mówi o zupełnie innym programie niż ten kopier Michała Galinskiego który widać na screen-shotach. W sumie to nie wiem dlaczego na screenach jest ten kopier.

EDIT#3:

Z tego co rozumiem z wątku na forum dotyczącym inż. wstecznej "Injektora", kaseta z programem kopiującym nie była czytelna, udało się odzyskać tylko jakiś program do konwersji w BASIC-u. Właściwy kopier/konwerter przepadł. Plików WAV o których mowa wątku już chyba nie ma nigdzie w sieci. Niby w późniejszych postach ludzie piszą że udało im się pobrać WAV i nagrywając go na kasetę kilka razy nawet udało im wczytać ten soft, jednak żadne linki które są załączone w postach już nie działają, a wayback-machine nie archiwizowało tych niszowych rzeczy :D

Ślepota nie boli, Voy zapodał link do bloga, gdzie jest spora część softu dla tego systemu: https://dogdarka8.blogspot.com/search/label/COPIADORES. Niestety nadal nie mogę namierzyć tego kopiera od "Michal Galinski".

EDIT#4:

Wszystko wskazuje na to że ten "Injektor" to turbo oparte o klasyczną modulacje FSK z tym że dekoder FSK montowany dodatkowo do magnetofonu jest w stanie dekodować o wiele większe bit-rate, jeżeli dobrze patrzę w źródła to chyba domyślną prędkością transmisji jest około 4000 bps, do tego przerwy IRG zostały skrócone. Co prawda to bardzo wstępna analiza, ale wychodzi na to że to taki "odpowiednik" Turbo 2600 ... tyle że teoretycznie szybszy i software-owo o wiele mniej skomplikowany (kod loadera jak i programu kopiującego). Nie wiem które rozwiązanie było pierwsze, w kodzie źródłowym Injektor-a widnieje data 05.09.88... nie pamiętam kiedy było opublikowane Trubo 2600. Ja o nim po raz pierwszy usłyszałem w audycji radiowej Radiokomputer.

Hej!

Wysłałem e-mail (via forum) z informacjami jakich potrzebują aby wysłać paczkę.

Wiem że pytanie może się wydawać dziwne, ale jakiego zasilacza używasz? oryginalnego czy jakiegoś nowoczesnego impulsowego?

Pytam bo na obrazku "composite" widać takie jakby poziome równomierne pasy/zmiany jasności... wygląda trochę jakby Ci się robiła jakaś wredna pętla masy (tzw. ground loop), ale to może być kwestia grabbera lub peceta do którego masz podłączony grabber.

100% racji ;) Mój przykład był zbyt mało skomplikowany, nie uwzględniłem tego że faktycznie offsety do poszczególnych pól struktury można określić już na etapie kompilacji.

A już z czystej ciekawości, jak CC65 poradzi sobie jeżeli to będzie tablica wskaźników zawierająca adresy np. stringów?

#include <stdio.h>

#define _countof(array)    (sizeof(array) / sizeof(array[0]))

void main(void)
{
    char *msg[]={"ala ma kota", "atari rulez!", "undercover error?", "super bulgot 3000"};

    for(uint8_t i=0; i < _countof(msg); i++)
    {
        printf("%s\n",msg[i]);
    }
}

ps) wiem że mogę sam sprawdzić, jednak Ty masz to wszystko zapewne w głowie i znasz odpowiedź bez sprawdzania czegokolwiek ;)

Da się oczywiście i w ten sposób, ale stos jest po prostu za mały aby dało się nieco bardziej skomplikowane rzeczy w ten sposób zrealizować, nie wiem jak jest dokładnie w CC65 (trzeba by podpytać np. Fox-a) ale wydaje mi się że stos jest emulowany (przynajmniej gdy wybierzemy "większy model pamięci/adresowania"). Niestety narzut kodu przy realizacji w tego w ten sposób jest dość spory i mam wrażenie że wydajność kodu generowanego przez kompilator drastycznie spada.

Kiedyś liczyłem na to że KickC ma szansę stać się całkiem fajnym kompilatorem, ale prawdę mówiąc przestałem śledzić zmiany i postępy w projekcie, bo miał on fazę kompletnego zastoju.

Z MadPascalem mam ten problem że to Pascal, to był co prawda jeden z pierwszych języków (po BASIC, ASM, etc.) których się uczyłem, ale gdy tylko przesiadłem się na C, to pisanie w Pascalu jakoś przestało być, hmmm... no nazwijmy to "atrakcyjne". Doceniam oczywiście starania TeBe i ogrom pracy który włożył w MadPascala, ogromny szacun za to! Ale sam Pascal jakoś mnie odrzuca, być może mam jakieś bezsensowne uprzedzenia i pewnie gdybym posiedział i przystosował się ponownie to by to jakoś poszło, ale ja po prostu robię za małe rzeczy aby wytaczać taką armatę jak MadPascal to moich prostych/prymitywnych projekcików... jestem jeszcze z tego pokolenia dla którego pisanie w pure ASM to czysta radocha :)

Ponieważ się "nie znam" to się wypowiem ;) Wydaja mi się że w przypadku 65xx i C problemem stają się również operacje które wymagają użycia dużej ilości wskaźników, przykładowo:

ctx->iocb.len = 256;

będą również kłopotliwe do prostej/optymalnej realizacji za pomocą "zasobów" które są dostępne w 65xx.

Do kompletu jakieś nie ma mowy o ramkach stosu, etc. Trzeba tak naprawdę emulować "duży" stos, jeżeli chcemy mieć możliwość operowania na większych strukturach danych, czy lokalnych zmiennych znajdujących się na stosie.

Te narzędzia jeszcze do nie tak dawna nie były darmowe... rzuciłem na nie okiem w momencie kiedy WDC udostępniło je, ale nie byłem zachwycony tym co wypluwał ten kompilator. Do tego instrukcja i sam kompilator i linker wydawały mi się strasznie toporne i chwilę mi zajęło zanim poprawnie udało się skompilować cokolwiek :)

Zresztą nie oszukujmy się... 6502 nie jest przyjaznym procesorem jeżeli chodzi o kompilatory, w większości przypadków tam gdzie ktoś wkłada 65xx pisanie w C mija się z celem, bo kod wygenerowany przez kompilator przy małym projekcie jest tak duży że tracimy połowę zasobów tylko dlatego że "kompilator".

Widziałem kiedyś też to co generuje komercyjny kompilator IAR-a, mimo że firma ma długą tradycję w pisaniu kompilatorów i ich kompilator robił co mógł, to kod nie był również zachwycający, niestety jak pisałem już wcześniej same ograniczenia architektury powodują że nie da się wygenerować sensownego kodu przy bardziej złożonych "konstrukcjach językowych". Może w przypadku 65816 jest lepiej, ale tutaj nie mogę się wypowiedzieć bo nie zajmowałem się analizą kodu wygenerowanego dla 65816 przez jakikolwiek kompilator.

Mam parę sztuk jakichś złomków przeznaczonych właśnie na takie akcje jako dawców, także puki będzie w kartonie z "dawcami" odpowiednia część, to będę doprowadzał te sprzęty do jak najlepszego stanu. Pudło z "dawcami" i tak stało lata i się kurzyło, chociaż teraz na coś się przyda... a i ja będę mógł zyskać trochę wolnego miejsca :D