Taki projekcik aby zobaczyć jak szybko można ładować gry.

Kabelkiem łączymy port LPT z portem joysticka 2.

Transmisja danych jest po 4 bitach + taktowanie na sygnale "fire" na każdym zboczu pół bajta.
Najpierw wysylana jest suma kontrolna całego programu a potem dwa bajty długości.
(Obliczanie sumy można wyrzucić bo to spowalnia odbiór.)
Program na Atari ładuje się pod adress $100 czyli na stos - możecie sobie wygenerować inaczej.

W projekcie są 2 zestawy programów:
1. portal.exe  portalpt.com - tu odbywa się wysyłanie danych bez potwierdzenia, dlatego wyłącza się obraz na czas transmisji. Program wysyłający po wykryciu adresu INIT robi pół sekundy przerwy aby program mógł się wykonać - na ten czas są także załączane obraz i przerwania. W programie portal.exe zastosowałem opóźnienie polegające na wielokrotnym zapisie do portu 0x80 - jest to mniej wrażliwe na prędkość procesora. Tę wartość można podać jako drugi parametr po nazwie pliku xex.

2. Transmisja z potwierdzeniem - wymagany jest dodatkowy przewód od sygnału command sio 7 do pinu 15 na LPT.
Nazwy programów zaczynają się na H jak Handshake. To zrobiłem aby zobaczyć jaką maksymalną prędkość transmisji można uzyskać 13000 KB/s (bez przerwań i obrazu). Na dyskietce (portalpt.atr) jest kilka wersji loadera - po nazwie można się zorientować czego nie robi (OFF bez obrazu, NO_CSUM- nie liczy sumy SEI- wyłacza przerwania przed ładowaniem H170 - ten nic nie wyłącza jest obraz i przerwania). Program działał z razem z podłączonym SIO2SD.

Programy przetestowałem w Dosie i Linuxie (Ubuntu 11). Źródła dla obu systemów.

LPT - Atari Joy (schemat kabelka)
1 - 6
2 - 1
3 - 2
4 - 3
5 - 4
18- 8 (masa 0V)

Post's attachments

portALPT.zip 183.57 kb, liczba pobrań: 14 (od 2020-12-27) 

porta_testy.jpg 158.42 kb, nikt jeszcze nie pobierał tego pliku. 

Tylko zalogowani mogą pobierać załączniki.

2

Robiłem podobne rozwiązanie z '96 z wykorzystaniem LPT i Pascala... dużo frajdy z tego miałem. A powiedz, czy testowałeś może z przejściówkami USB<>LPT? Fajny projekcik :-)

https://systemembedded.eu/ ... https://www.youtube.com/watch?v=GwS7Es1x6mw
""Ja bardzo przepraszam, ale podejrzenia panów są całkowicie bezpodstawne. Ja niczym nie handluję. Ta pani przyszła do mnie w tym Pancake-u i w nim wychodzi.""
ABBUC Member #319. Preferowana forma kontaktu: email

3

Na portach joysticka podobnie, jak na porcie SIO są kondensatory ograniczające prędkość transmisji. Ich eliminacja pozwala uzyskać na SIO 126 kpbs. Ciekaw jestem na jaki transfer można by sobie pozwolić gdyby zrobić to samo na PIA. 13KBps to jest świetny wynik!

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

4

Nie używałem żadnych przejściówek.
Do kompletu wypróbowałem jeszcze jedną wersję programu - jeden z bitów portu zamieniłem na wyjście - a czwarty bit do nibbla pobrałem z "Fire" taktowanie było w jedną stronę od Atari do PC. Okazało się, że jest to najgorszy sposób gdyż port LPT nie nadążał z nadawaniem danych powodując błędy. Poprawiło się trochę gdy przestawiłem kolejność rozkazów aby opóźnić odczyt. Program trochę się rozrósł ledwo mieszcząc się na jednej stronie pamięci. (W kabelku zamieniłem 2 przewody)
w skrócie
  STA PortA  7 bit (taktowanie)
  LDA PortA  odczyt danych - to za szybko (pomiędzy te dwa rozkazy trzeba dać inne rozkazy)

To by było na tyle pozostaje zrobić wersję cało-bajtową.

*-----------------------*
Zamiast podsumowania mały offtopic z eksperymentów. Zrobiłem generator aby sprawdzić jaką częstotliwość da się wycisnąć z portu i wyniki są takie
Atari : 148,4 kHz
386sx: 220 kHz
amd800: 341 kHz
amd2000: 437 kHz
Mnożąc wynik razy dwa mamy ilość zapisów do portu w ciągu sekundy. Różnica między atari a PC jest taka, że dodając kilka rozkazów do pętli na Atari częstotliwość spada o kilka kHz a na PC-cie nieznacznie po przecinku. Nie wiem jak dokładnie działa zapis do portów LPT, ale gdzieś wyczytałem że działa z prędkością szyny ISA.
Program na wyglądał tak
...
   ldx #$00
   lda #$FF
x stx porta
   sta porta
   bvc x    lub jmp x

Ciekawostka pierwsza obojętnie czy bvc x czy jmp oba rozkazy (i programy) działają tak samo szybko, mimo że bvc jest o bajt krótsze.
Ciekawostka druga umieszczenie tego programu na stronie zerowej nie powoduje szybszego działania (chyba w TA czytałem że program na stronie zerowej działa szybciej jak widać nie.) (szybciej to działa zapis i odczyt z komórek pamięci na tej stronie - sprawdziłem to)

5

Prędkość działania w obu lokacjach (na zerowej i w dowolnym obszarze RAM) będzie taka sama, gdyż operujesz na argumentach jedno bajtowych (bvc x) a dostęp czy to do zerowej strony czy każdej innej zajmuje tyle samo czasu. Natomiast używając JMP X , program będzie o jeden bajt dłuższy jeśli program umieścisz poza stroną zerową. Fakt ten powinien mieć wpływ na prędkość dłuższą o 1 jeden odczyt... no chyba, że mamy tu klasyczny przykład pracy "na zakładkę" opisaną w książce pod autorstwem H. Kruszyński i K. Kulpa:  "Procesor 6502 i jego rodzina". :-)

Zastanawiam się co jest szybsze... nibble na fire czy przesyłanie danych w dwóch połówkach po 4 bity z synchronizacją/sygnalizacją  na 2-giej połówce PIA - tak robiłem to lata temu ale niestety nie mam żadnej dokumentacji i źródeł... no i można wtedy w dwóch kierunkach pchać dane :-)

PIA jest szybkie na tyle by obsłużyć zapis i odczyt w każdym cyklu dostępu procesora do rejstrów portu, problemem okazać się mogą pojemności na liniach danych od strony portów po czym pisał @mono.

Możesz też poprawić osiągi gasząc ekran na czas transmisji...

https://systemembedded.eu/ ... https://www.youtube.com/watch?v=GwS7Es1x6mw
""Ja bardzo przepraszam, ale podejrzenia panów są całkowicie bezpodstawne. Ja niczym nie handluję. Ta pani przyszła do mnie w tym Pancake-u i w nim wychodzi.""
ABBUC Member #319. Preferowana forma kontaktu: email