1

jesli w drugim POKEY nie uzywana jest czesc odpowiedzialna za transmisje to nie daloby sie zrobic tak, zeby dugi SEROUT nie wysylal bitow startu i stopu?

mozna by wtedy zrobic cos takiego:

https://soundcloud.com/protodome/4000ad

http://atari.pl/hsc/ad.php?i=1.

2

O ile wiem i właśnie przeczytałem, dokumentacja nic nie wspomina o możliwości wyłączania w POKEYu bitów start/stop.

3 Ostatnio edytowany przez mono (2022-02-14 02:43:59)

A czemu chcesz to wyłączać? Dostaniesz falę o wypełnieniu 1/10 do 9/10. Przy wystarczająco wysokiej częstotliwości to nawet nie usłyszysz nośnej.

Edit: Ustawiając 1.77MHz jako główny zegar i 10 w generatorze potrzeba wysłać bajt co 110 cykli (16,1kHz nośna). To nie lepiej użyć 7-bitowego PWM-a bo i tak generator masz zajęty (chyba że taktowanie transmisji miałbyś z zewnątrz to masz 5-ty kanał w POKEY-u o rozdzielczości 3-bit)?
Można by próbować też traktować to jako strumień bitów i traktować bit startu i stopu jako bity danych, tyle że czasem byłyby one błędne. Może w ogóle nie będzie to mieć znaczenia np przy 4 w generatorze czyli nośnej 44,3kHz (bajt co 50 cykli)?

Edit 2: Ale możesz taktować z zewnątrz i dostać 5-ty kanał w POKEY-u wrzucając z zewnątrz dowolny strumień bitów nie martwiąc się w ogóle ramkami i bitami start/stop. Ale czemu wtedy nie wprowadzić tego na linię audio zamiast kombinować z datain?

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

4

20% szumu w sygnale nie nazwalbym niczym.

http://atari.pl/hsc/ad.php?i=1.

5 Ostatnio edytowany przez mono (2022-02-14 13:37:24)

Ale poza zakresem słyszalności :) Więc niech se szumi.

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

6

no nie wiem, masz 10 bajtow 10*8  80 bitow, do tego 2x1x10 bitow start/stop = 20 bitow

razem 100 bitow w czym 20 to smieci

jak poza zakresem slyszalnosci? zamiast pierdziec przez beeper pierdzim przez transmisje pokeya. jest jeszcze gorzej bo masz 2 bity smieci jeden po drugim

http://atari.pl/hsc/ad.php?i=1.

7 Ostatnio edytowany przez mono (2022-02-14 16:43:01)

Nie 10*8 tylko 10*10. Traktujesz bity startu i stopu jak bity danych, ale takich które MOGĄ BYĆ przekłamane bo nie masz na nie wpływu.
Załóżmy że generujesz poziom stały więc masz strumień:
0101010101 0101010101 0101010101
czyli wysyłasz $55 $55 $55 - gdzie tu masz jakiś pisk i jakieś błędy?
Może inny schemat np:
0111111111 0111111111 0111111111
czyli wysyłasz $FF $FF $FF - tu też widzisz jakieś błędy?
No dobrze - jak chcesz wygenerować:
0001110011 1100001010 0000111110
to wysyłasz $9C $A1 $F8 ale strumień bitów generowany jest tak:
0001110011 0100001011 0000111111
wtedy dostaniesz w drugim bajcie 2 błędne bity a w trzecim bajcie 1. Przy częstotliwości 44.3kHz to nawet nie wskoczy w próg słyszalności.

Edit: Poza tym jak masz dwa błędy w bajcie (w miejscu bitu startu powinna być 1 a w miejscu bitu stopu 0), to nie wiem czy to w ogóle będzie miało znaczenie. Znaczenie myślę będą miały kumulowane pojedyncze błędy w bajcie. Ale te może dałoby się skompensować celowymi przekłamaniami w bitach danych? Tak sobie fantazjuję.

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

8

nawet nie trzeba sprawdzac... octocode generuje sobie "sample" powiedzmy ze robi strumien 256 bitow - w tym strumieniu ustawia np. 5 bitow

a Ty mi mowisz ze ustawienie w tym strumieniu CYKLICZNIE ?50? bitow nie bedzie mialo znaczenia...

http://atari.pl/hsc/ad.php?i=1.

9

Z jaką częstotliwością ten strumień jest renderowany?

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