451

(56 odpowiedzi, napisanych Software, Gry - 8bit)

Przecież i tak jest beeper ;) A tak w ogóle, jeśli idzie o emulator ZX Spectrum, kiedy wszystkie kanały dwóch Pokeyów będą wykorzystane na emulację AY-greka, wtedy zabraknie mi kanałów na beeper. Trzeba go będzie przenieść na GTIA, a to _może_ oznaczać pogorszenie jakości (bo GTIA ma 1 bit, a ZX ma jednak bity MIC i EAR, wprawdzie nie do końca 2, ale jednak z pomiarów wynika, że jest to więcej niż 1 - przyznaję wszakże, że nie wiem, czy cokolwiek tę możliwość wykorzystuje - w każdym razie zaemulowanie jej na Pokeyu nic nie kosztuje).

452

(56 odpowiedzi, napisanych Software, Gry - 8bit)

@lemiel, trafiłeś w sedno, to laptop, po odłączeniu zasilacza buczenie ustało. Wszystkie pliki mp3 w związku z tym wymieniłem na wersje niebuczące. Plus doszedł jeden nowy (refresh trzeba w przeglądarce wcisnąć po wejściu pod wyżej wspomniany adres, żeby przeładować plik index.html).

@pinokio i adam, no jasne, że te eksperymenty są tak ukierunkowane ;)

@cyprian: player jest na razie w fazie proof-of-concept i jako taki nie nadaje się do publikacji, zresztą eksperymenty jeszcze trwają i są widoki na pewne ulepszenia. Przygotowanie playera (nazwijmy to) produkcyjnego może trochę potrwać. Jak kto ciekaw, pewnie na Wapniaku będę mógł zademonstrować, że to nie jest ściema :D

Nowe pliki *.PSG chętnie przyjmę.

@wieczor: na jednym AY się raczej nie zmieści, ma 3 kanały z 12-bitową rozdzielczością.

453

(56 odpowiedzi, napisanych Software, Gry - 8bit)

Wyjmuję kotlet z zamrażarki.

Jak wiadomo, syntezą układu AY zajął się z sukcesem mono. Mnie natomiast przyszło do głowy pytanie, czy nie dałoby się wartości rejestrów AY (np. zawartych w plikach PSG) jakoś w miarę prosto przełożyć na wartości rejestrów może nie tyle Pokeya, ile dwóch Pokeyów. "W miarę prosto", to znaczy tak, żeby się to z zapasem zmieściło w player grający raz na ramkę.

Założenia są następujące:

1) kanały 1-2 i 3-4 w obu Pokeyach łączymy w pary uzyskując cztery 16-bitowe kanały syntezy.

2) mapujemy je następująco:

a) kanał A = Pokey 1, audf1-2
b) kanał B = Pokey 1, audf3-4 i Pokey 2, audf3-4
c) kanał C = Pokey 2, audf1-2

3) przełączamy wszystko na 1,773 MHz

4) gdy mikser AY-greka wskazuje, że w danym kanale należy generować czysty ton, generujemy takowy we wskazanym kanale, przeliczając wartości rejestrów AY->Pokey wg odpowiedniej tabelki

5) gdy mikser AY-greka wskazuje, że w danym kanale należy generować szum, pobieramy częstotliwość szumu, ładujemy ją wg tabelki do wskazanego kanału i w audc odpowiednim dla danej pary kanałów wybieramy szum $8x.

6) gdy mikser AY-greka wskazuje, że w danym kanale należy generować i czysty ton i szum, generujemy czysty ton, a do tego w młodszym bajcie audc dla danej pary wybieramy szum $8x i ustawiamy połowę głośności czystego tonu (dlaczego połowę? Bo już 2/3 głośności powoduje, że ten szum jest zbyt głośny w stosunku do reszty instrumentów).

7) obwiednie układu AY są nie do zaemulowania, ale instrumenty ich używające muszą się jakoś różnić, bo inaczej w niektórych utworach w ogóle nie słychać linii melodycznej. Przeto dzielmy je (obwiednie) na trzy grupy i przydzielamy im różne głośności: $0f, $0b i $07.

8) resztę olewamy.

Wynik tych eksperymentów jest tutaj:

http://drac030.krap.pl/ay/

Pliki nazywające się *_ay.mp3 są nagrywane na żywym AY-greku, konkretnie na Evie.

Pliki nazywające się *_pokey.mp3 to efekt działania playera napisanego wg powyżej wyszczególnionych założeń.

Rezultaty są oczywiście różne, tj. dobre, średnie i takie sobie.

PS. W torze nagrywania coś mi gdzieś buczy, nie umiem tego namierzyć ani wyeliminować, nawet nie wiem, czy źródłem jest Atari czy pecet używany do nagrywania. W każdym razie sample są zgrywane z żywego sprzętu :)

EDIT: buczenie zlikwidowane :)

454

(10,045 odpowiedzi, napisanych Bałagan)

Implikacja jest prosta: wykazujesz się mniej więcej takim samym zrozumieniem rzeczywistości i słowa pisanego, jak członkowie wymienionych organizacji.

Niezbyt skomplikowane, ale wiem, że nie byłbyś w stanie. Za proste :D

455

(10,045 odpowiedzi, napisanych Bałagan)

A wypatrujesz werbunku?

456

(10,045 odpowiedzi, napisanych Bałagan)

BartoszP napisał/a:

W układzie czwórkowym

Nie zastanawiałeś się nad członkostwem w PO? Albo przynajmniej najmij się do regionalnego oddziału GW. Nadajesz się.

457

(10,045 odpowiedzi, napisanych Bałagan)

2+2 to 4 czy 10? A może prawda leży pośrodku?

458

(318 odpowiedzi, napisanych Fabryka - 8bit)

@pasiu: TAP jest ładowany w całości do pamięci. Co do 128k, że pojadę klasykiem: czytałem dokumentację, ale mnie nie przekonała...

@tebe: pisz!

459

(318 odpowiedzi, napisanych Fabryka - 8bit)

Emulec ZX Spectrum, nowsza wersja:

http://drac030.krap.pl/pl-acc-pliki.php

Główne zmiany: 1) poprawiłem błąd w obsłudze przerwań Z80, 2) dodałem ładowanie programów w formacie TAP.

Opis tutaj: http://atariki.krap.pl/index.php/Let's_Emu!

460

(18 odpowiedzi, napisanych Programowanie - 8 bit)

Fajny pomysł :) Na filmie widać, jak to działa, nawet w razie braku źródła dałoby się odtworzyć.

461

(10 odpowiedzi, napisanych Programowanie - 8 bit)

To wygląda na adresy bloków dla procedury, która oblicza sumę kontrolną. Raczej są w notacji lo/hi, pewnie pod $FFD7 będzie $02.

462

(10 odpowiedzi, napisanych Programowanie - 8 bit)

@willy: też początkowo wyszedłem z tego założenia, i jest to jedyne rozwiązanie w sytuacji, kiedy istnieje ochrona pamięci, ale póki ona efektywnie nie istnieje i nie ma widoków na to, że zaistnieje kiedykolwiek w takiej postaci, może lepiej jest procedurę uprościć.

@pajero: to prawda, ale ten dokument http://www.westerndesigncenter.com/wdc/ ... 5c816s.pdf na stronie 32 mówi, że obszar wektorów zaczyna się na adresie $00FFE0. Przy czym dwa pierwsze wektory są zarezerwowane, więc pierwszy rzeczywisty istotnie znajduje się pod $00FFE4.

463

(10 odpowiedzi, napisanych Programowanie - 8 bit)

Patent nr 1 i zarazem propozycja do dyskusji, gdyż wpadłem na to dopiero parę dni temu (lepiej późno niż wcale).

Mianowicie istnieje pewien problem z szybkim łatwym i przyjemnym wykryciem, że aktywny w danej chwili OS zawiera procedury obsługi przerwań trybu natywnego. Gdyby natomiast taki sposób istniał, wtedy każdy program aplikacyjny mógłby w takowy tryb przełączyć CPU szybko, łatwo, przyjemnie, bez rzeźbienia i obawy, że nastąpi zwis.

Takich OS-ów może być milion, można napisać procedurę, która je oddzielnie rozpoznaje, ale żeby każdy ewentualnie nowy wymagał jej poprawienia, to kiepska perspektywa. Potrzebna jest uniwersalna i w miarę prosta metoda szybkiego sprawdzenia, czy ta możliwość istnieje. Kontrolowanie wszystkich wektorów po kolei na okoliczność, czy ich wartości mieszczą się się w zakresie $C000-$CFFF oraz $E400-$FFDF, mimo że może działać, dobre nie jest.

Zatem wymyśliłem coś takiego: ponieważ WDC definiuje obszar wektorów przerwań CPU jako $FFE0-$FFFF, zatem, gdyby bezpśrednio przedtem, tj. pod $FFDD-$FFDF, znajdowała się konkretna wartość magiczna, której odczytanie walidowałoby wektory trybu natywnego $FFE0-$FFEF, wtedy mielibyśmy uniwersalny i prosty sposób rozpoznania, czy w OS-ie istnieje wsparcie dla trybu natywnego. Wystarczyłoby odczytać 3 bajty ROM spod $FFDD, $FFDE, $FFDF, porównać z wzorcem, i z prawdopodobieństwem 1/16777216 zyskać pewność, że można się spokojnie przełączyć w tryb natywny bez dodatkowych zmartwień, albo że nie.

Jako wartość magiczną proponuję:

$00FFDD: $65
$00FFDE; $C8
$00FFDF: $16

464

(185 odpowiedzi, napisanych Sprzęt - 8bit)

@miker: jak to kto? Następny amigowiec :D

465

(318 odpowiedzi, napisanych Fabryka - 8bit)

Wykrywać to tam nie ma czego, może jedynie, ile jest pamięci. Postaram się jakąś procedurę detekcji rozmiaru RAM niedługo wkleić.

Pod SDX można skorzystać z info w COMTAB2:

COMTAB2+$00 - jeśli wartość ujemna (np. $FF), mamy 65C816. Jeśli na dodatek jest $FE, w ROM-ie są procedury obsługi przerwań trybu natywnego.

COMTAB2-$04 - liczba dodatkowych segmentów 64k pamięci RAM. Jeśli 0, wysokiego RAM-u nie ma.

COMTAB2-$05 - numer (najstarszy bajt adresu) pierwszego segmentu dodatkowego RAM-u. Jeśli brak, to $00. Jeśli jest, to na ogół $01.

Co do ładowania, nie ma specjalnego sposobu, np. emulec Spectrum ładuje kolejne bloki do pierwszych 64k, a potem relokuje je własnym relokatorem i przepisuje w miejsce docelowe.

Planowałem (i nadal planuję) umieszczenie w ROM-ie Rapidusa procedury ładującej, ale póki co jej tam nie ma.

466

(185 odpowiedzi, napisanych Sprzęt - 8bit)

Źle się wyraziłem, to jest pewnie ciekawy przypadek, tylko ja nie jestem psychiatrą.

467

(185 odpowiedzi, napisanych Sprzęt - 8bit)

xxl napisał/a:

wczesniej pisales ze traktuje ja zbyt doslownie, teraz ze doczytuje sie zeczy ktorych nie ma... zmiana zdania skorelowana jest ze zmiana cisinenia jak rozumiem ;-)

Traktujesz ją zbyt dosłownie i przez to doczytujesz się tam rzeczy, których nie ma. Jak coś ma etykietę SERIAL to musi to być naprawdę serial, antifa to antyfaszyści, bo tak się nazywają, a jak ktoś zrobi margarynę ze starego oleju silnikowego i napisze na opakowaniu MASŁO, też pewnie uwierzysz, że skład jest identyczny z prawdziwym masłem. Nazywa się to semantyzacja symboli i jest jednym z powszechnych błędów poznawczych.

mazi ma rację, dość tego oftopu, bo obiekt rozważań jest, jak zaznaczyłem powyżej, nudny.

468

(185 odpowiedzi, napisanych Sprzęt - 8bit)

Bo doczytujesz się treści, których tam nie ma. Przynajmniej w rzeczywistości, bo w "zeczywistości" może je widać.

469

(185 odpowiedzi, napisanych Sprzęt - 8bit)

Jesteś w te klocki tam samo beznadziejny jak w czytaniu doców Atari ze zrozumieniem. Ale to już, jak napisałem wyżej, nie moja sprawa.

470

(185 odpowiedzi, napisanych Sprzęt - 8bit)

Nie ochłonąłem, bo nie miałem z czego. Ktoś ci w końcu musiał powiedzieć o twoich staropanieńskich obsesjach, a do kogo z tym pójdziesz, to już twoja sprawa. W każdym razie schematyczność, powtarzalność i przewidywalność twoich zachowań na forum jest od bardzo dawna dość męcząca.

471

(185 odpowiedzi, napisanych Sprzęt - 8bit)

Wyraźnie powinna cię więc nią częstować raz dziennie, może pomoże.

472

(185 odpowiedzi, napisanych Sprzęt - 8bit)

Kwity mówią same za siebie, tylko że nie rozumiesz, co mówią. WSZYSCY to rozumieją, nawet Zientara gdzieś pisze o interfejsie szeregowo-równoległym, tylko jeden amigowiec nie jest w stanie od 10 lat tego pojąć i dpę zawraca... A co do gównokrucjat, jeszcze amnezji nie mam, non-stop masz jakiegoś wyimaginowanego wroga, którego próbujesz zwalczać: wrogiem PBI, wrogiem OS, wrogiem VBXE, wrogiem blitter VBXE, wrogiem 816, wrogiem akcelerator, wrogiem to, wrogiem tamto, jedynie słuszne to, jedynie słuszne tamto, Atari tak chciało, Atari by tak chciało, Atari tak nie chciało, ale MOGŁO CHCIEĆ, i tak w koło Macieju. To jest CHORE i tyle mam do powiedzenia.

473

(185 odpowiedzi, napisanych Sprzęt - 8bit)

Gadka jest o tym, że nie kumasz tematu, bo sformułowanie serial interface rozumiesz dosłownie i na tym opierasz obecną gównokrucjatę przeciwko PBI. Kup se 1200XL i daj se spokój, bo słuchać hadko.

474

(185 odpowiedzi, napisanych Sprzęt - 8bit)

Sformułowanie typu serial interface nie dotyczy warstwy sprzętowej tylko interfejsu I/O zaimplementowanego w OS-ie. A od czasów 1200XL OS się zmienił, bo pojawił się w nim kod obsługi PBI (w ramach tego tak zwanego interfejsu szeregowego, który tym samym szeregowy zaczął być tylko z nazwy). Czyli koncepcja się zmieniła. I ta wersja OS-u weszła do produkcji.

475

(318 odpowiedzi, napisanych Fabryka - 8bit)

mono napisał/a:

Żadne z tych rozszerzeń nie widzi pamięci Atari. Działa to w drugą stronę - Atari czasem widzi pamięć któregoś z tych rozszerzeń. Tak zachowuje się jeśli dobrze rozumiem Rapidus, Weronika, VBXE.

Akurat właśnie w przypadku Rapidusa jest odwrotnie: on widzi pamięć Atari (w tym VBXE, Weroniki et consortium), ale reszta towarzystwa nie widzi pamięci Rapidusa.