On 18.06.2022 18:24, Piotr C wrote:
> On Saturday, June 18, 2022 at 1:07:23 AM UTC-7, Dawid Rutkowski wrote:
>> Mogą być, bo przecież ten napis się raczej nigdzie nie wyświetla.
>
> Kurde prawda! Nie wpadłbym, ale mogli przekodować napis aby w kodzie wyglądał
normalnie. Dzisiaj przedzwonie linie danych. Spróbuje też zdekodować dźwięk, chociaż
od ostatniego czasu gdy coś kodowałem w C minęło ładnych pare lat.

Mało prawdopodobne.
Kod to kod. a wsad to wsad. Bez sensu jest żeby upiększać wsad.
Mogą być pomieszane linie adresowe i/lub linie danych ale to się robi
żeby uprościć płytkę (sam tak robiłem), a nie żeby utrudnić kopiowanie.
Linii danych IMHO nie masz pomieszanych skoro widać napis. Może być
kolejność bitów zamieniona do dekodowania (MSB/LSB).
Linie adresowe raczej też nie są, aczkolwiek napis może się mieścić
akurat w bloku niezmieszanym.

--
Mirek.

do góry

Piotr C <k...@g...com> wrote:

> Wątpie czy ktoś coś poradzi ale nie mam innego pomysłu.

Pobawiłem się chwilę:

https://drive.google.com/file/d/1u-abfSvp7zs7VBmyQ4w
svffRkREyJcbZ/view

Baza do dalszych zabaw:

#v+
#include <stdio.h>
#include <assert.h>
#include <inttypes.h>

int main(void)
{
FILE *ifp, *ofp;
uint8_t value = 0x80;
uint8_t dir = 0;

ifp = fopen("VOICE_ROM_TMS27C010A.BIN", "rb");
ofp = fopen("output.raw", "wb");
assert(ifp);
assert(ofp);

for (;;)
{
const uint8_t ch = fgetc(ifp);
int i;

if (feof(ifp))
break;

for (i = 0; i < 8; ++i)
{
if (dir ^ !!(ch & (1 << i)))
{
if (value == 0xff)
dir ^= 1;
else
value++;
}
else
{
if (value == 0x00)
dir ^= 1;
else
value--;
}

fputc(value, ofp);
}
}

fclose(ofp);
fclose(ifp);

return 0;
}
#v-

I potem komenda:

sox -b 8 -c 1 -e unsigned-integer -r 22050 -t raw output.raw output.wav

Na pewno należałoby sparsować strukturę i resetować dekoder przy każdym
nowym komunikacie -- to powinno usunąć DC bias.

--
Gdybyś była owocem, to byłabyś najsłodszą truskawką. A gdybyś była
warzywem, to odwiedzałbym cię codziennie w szpitalu.

do góry

niedziela, 19 czerwca 2022 o 08:38:24 UTC+2 Arnold Ziffel napisał(a):
> Piotr C <k...@g...com> wrote:
>
> > Wątpie czy ktoś coś poradzi ale nie mam innego pomysłu.
> Pobawiłem się chwilę:

No ale słychać coś sensownego?
Są dwa zestawy językowe?

do góry

Jest Sun, 19 Jun 2022 02:37:06 -0700 (PDT), Dawid Rutkowski pisze:
> niedziela, 19 czerwca 2022 o 08:38:24 UTC+2 Arnold Ziffel napisał(a):
>> Piotr C <k...@g...com> wrote:
>> > Wątpie czy ktoś coś poradzi ale nie mam innego pomysłu.
>> Pobawiłem się chwilę:
> No ale słychać coś sensownego?

Słychać.
https://oc.lh2.pl/s/HeKko576yw4Fzgo

> Są dwa zestawy językowe?

Nie inaczej.

ATSD, bardzo fajne wykopalisko.

k.
--
Krzysztof Gajdemski | songo (at) debian.org.pl | KG4751-RIPE
Registered Linux User #133457 | BLUG Registered Member #0005
PGP key at: http://s.debian.org.pl/gpg/gpgkey * ID: D3259224
Szanuję was wszystkich, którzy pozostajecie w cieniu - Snerg

do góry

Dawid Rutkowski <d...@w...pl> wrote:

>> Pobawiłem się chwilę:
>
> No ale słychać coś sensownego?
> Są dwa zestawy językowe?

Słychać, zobacz link z mojego posta (albo z posta Krzysztofa niżej), to
link do pliku audio.

--
Przychodzi mrówka do krawca i mówi:
- Jest nitka?
- Jest!
- Cale dwa cm proszę!
- Zapakować???
- Nie! Powieszę się na miejscu!

do góry

Jest Sun, 19 Jun 2022 21:40:43 +0000 (UTC), Arnold Ziffel pisze:
> Dawid Rutkowski <d...@w...pl> wrote:
>
>>> Pobawiłem się chwilę:
>>
>> No ale słychać coś sensownego?
>> Są dwa zestawy językowe?
> Słychać, zobacz link z mojego posta (albo z posta Krzysztofa niżej), to
> link do pliku audio.

O kurczę. Faktycznie, wystawiłeś od razu audio. Byłem przekonany, że to
link do kodu i nawet nie zajrzałem. Niepotrzebne powielanie bytów
(bajtów?). :/

BTW, wydaje mi się, że docelowo próbki miały być odtwarzane wolniej. Tak
na ucho, to jakieś x 0,85 - 0,87% tego co wychodzi jako output.wav.

k.
--
Krzysztof Gajdemski | songo (at) debian.org.pl | KG4751-RIPE
Registered Linux User #133457 | BLUG Registered Member #0005
PGP key at: http://s.debian.org.pl/gpg/gpgkey * ID: D3259224
Szanuję was wszystkich, którzy pozostajecie w cieniu - Snerg

do góry

On Saturday, June 18, 2022 at 11:38:24 PM UTC-7, Arnold Ziffel wrote:
> Baza do dalszych zabaw:

Dzięki - Tobie i innym, fajna zabawa! Chyba wrócę do kodowania. Ulepszyłem trochę
program i:
- nie ma składowej stałej
- jest głośno, pełna dynamika

Co zmieniłem: generalnie Ty traktowałeś każdy oktet osobno, a myśle że lepiej
przesuwać bit po bicie i całkować z wagą: przykładowo: n=0.3 dla ostatniego bitu i
(1-n) dla poprzedniej wartości próbki. W zależności od współczynnika n, któryś
najstarszy bit [-x] przestanie mieć znaczenie (będzie zgubiony przez poziomy
kwantyzacji). Im 'n' większe, tym krótsza (bardziej stroma) odpowiedź impulsowa, im
mniejsze - tym dłużej 'wybrzmiewa' każdy bit. Myślę że w realizacji analogowej,
większe n to mniejsza pojemność kondensatora całkującego.
Teraz, przy stałym poziomie czyli ciągu 01010101... będzie oscylacja, więc uśredniam
dwie ostatnie scałkowane wartości.
http://mabanana.com/elcotel/wykres.png
Na wykresie to widać ładnie, jak przebieg ładowania kondensatora. Czerwone kropki to
bity na wejściu. Szare - po całkowaniu. Czerwone - po uśrednieniu. Dałem przykład z
ciągiem "1", potem ciąg "0", a potem naprzemienne.
**** Ulepszone nagranie: http://mabanana.com/elcotel/output.wav
Eksperymentalnie dobrałem n=0.2151. Przy 8-bitowym wyjściu ze znakiem (signed) filtr
powinien "pamiętać" do 20 ostatnich bitów, poprzednie będą "zgubione" przez
rozdzielczość wyjścia. Można n wyliczyć tak: n = 1- sqrt(1/127, ile_bitów).
Teraz: mimo że dynamika jest OK, to są szumy. Nie wiem jak to zrealizować lepiej.
Próbowałem uśredniać 3 próbki wyjściowe - ścina pasmo, szum jest "niżej" ale jest.
Nie wiem. Ta realizacja jest myśle bliska filtrowi RC 1-rzędu.

Program jest tutaj: http://192.168.0.200/elcotel/main.c - wrzucę jeszcze poniżej bo
te pliki będą skasowane.

Natomiast w kwestii kodowania mam szybkie pytanka:
- co robi #v+ ?
- fputc() - jest odpowiednik do zapisu int-a 16- lub 32 bit, lub całego obszaru
pamięci (wskaźnik)?

Programowałem w C chyba jedynie na studiach 20 lat temu, zawodowo nigdy. Wcześniej od
dzieciaka TurboPascal i Delphi już quasi-zawodowo. I chyba nadal lubię ten poziom
(kiedyś to się nazywało programowanie wysokopoziomowe, dzisiaj już raczej nie. Ale
skręca mnie jak widzę nowoczesne języki, jakieś dziedziczenia templejtów, nejmspejsy
itd itd. Taka chyba przypadłość jeśli się zaczynało w 1992 r.).

pozdrawiam

#include <stdio.h>
#include <assert.h>
#include <inttypes.h>


int main(void) {
FILE *ifp, *ofp;
uint8_t src_value; //odczytany bajt
float DSP_0 = 0; //aktualne wyjście integratora
float DSP_1 = 0; //popczednia wartość integratora (potrzebne
do uśredniania 2 próbek)
float n = 0.2151; // współczynnik filtra - znaczenie nowego
bitu
int8_t out_value; //wyjściowy bajt PCM (signed 8-bit)
int b=0; //bity, konwertowany do +/-1
int bitstream=0, bitstreammax=0; //aktualny i najdłuższy ciąg jednakowego bitu

ifp = fopen("VOICE_ROM_TMS27C010A.BIN", "rb");
ofp = fopen("output.raw", "wb");
assert(ifp);
assert(ofp);

do {
src_value = fgetc(ifp);
for (int i=0; i<8; i++) {
DSP_1=DSP_0;
b=(src_value&1)?1:(-1); //+1 dla 1, -1 dla 0
src_value>>=1;
DSP_0=DSP_0*(1-n)+n*b;
out_value=round((DSP_0/2+DSP_1/2)*127); //uśredniamy 2 próbki +
przeskalwanie +/-1 na +/-127 (signed int8)
if (i&1) fputc(out_value, ofp); //zapisujemy wyjście co
drugi bit
}
} while (!feof(ifp));

fclose(ofp);
fclose(ifp);

return 0;
}

do góry

Mała errata:
> po całkowaniu. Czerwone - po uśrednieniu.
oczywiście chodzi o zielony wykres.

> Program jest tutaj:
prawidłowo: http://mabanana.com/elcotel/main.c i są zachowane wcięcia

Dodam jeszcze że częstotliwość próbkowania wyszła 9690 Hz (zapis próbki PCM po co
drugim bicie wej.). Pod koniec wersji angielskiej jest sygnał zgłoszenia, który
powinien mieć 350&440Hz więc łatwo było to obliczyć.

P.

do góry