Sziasztok!

Nemes Marcus vagyok, negyedeves mikroelektronika szakos hallgato, a 
www.hix.com-on bongeszve talaltam Ratok.

Ketszeri Csaba irta:
: A problemam az, hogy van egy audio CD-m, ami eleg alaposan
: ossze lett karcolva, de sehol nem melyen, inkabb homalyos
: lett. A jobb lejatszok viszonylag turhetoen le is jatszak, a
: grabberek -ha lassan is- szednek le rola egesz turheto
: anyagot, de az meg pattog. Termeszetesen mas lemezek soha.

Tudtommal az audio CD-lejatszok a hibas reszt maguktol is tobbszor
olvassak, ill. ha nem jon ossze, akkor interpolalnak. A CDROM-lejatszo
termeszetesen nem interpolalhat, jol neznenk ki, ha ilyet tenne. Ettol
viszont pattog a wav. Vannak viszont olyan progik, amik a pattogast ki 
tudjak szurni.

######

FFT: szeretnek egy radix-2 decimation in time (DIT) FFT butterfly-t
programozni, az elmeletben azonban nem teljesen vilagos a twiddle factor
(W_N^nk) kiszamitasanak algoritmusa az egyes lepcsokben; azaz mit takar n
ill. k. Peldaval tarkitott elmeletet pl. a
http://www.soton.ac.uk/~xzhang/signal/part7/node2.html cimen lehet
talalni. 

Elore is koszonom,
marky a germanhonba szakadt neme[s|csek] - 

Sziasztok!

A #1105-os GURU-ban Borla feldobott egy labdat,
egy olyan progi irasaval kapcsolatban, ami
a HDD-n az eppen torolt fajlok helyet atirja
valami veletlen adattal, aztan aldja-vigye.
Az otlet nem rossz, a titkosito programok
tobbsegeben van is WIPE funkcio, ami ezt
valositja meg. DOS alat nem is gond megirni
hiszen leteznek az INT 25h es INT 26h
megszakitasok. WIN95 alatt viszont ezeket mar
nem lehet elerni. Azokat a progikat, amelyek ezzel
probalkoznak a Win elhajitja.
Az lenne a kerdesem, hogy van-e valakinek infoja
arrol, hogy helyette milyen rendszerhivasokat
lehet hasznalni a HDD szektorainak kozvetlen irasara
es olvasasara? Hol van ez dokumentalva?
Biztos van megoldas, kulonben a Defrag meg a NU
sem mukodne.

A valaszokat elore is koszonom.
Udvozlettel: Laci

--
Vagasi Laszlo

Sziasztok!

Lett egy kis idom, masfel het szunet utan itt a tema folytatasa:

Mint a multkor mar irtam, az OCR-hez altalanossagban 300 dpi
felbontasu fekete-feher (ugy ertem nem szurke) kep a legjobb. Ennek 
merete A4-es (irogeplap meretu) kep eseten 1.1 megabyte.

Sokan, amikor elkezdenek keppel foglalkozni, ugy hiszik, hogy a
legjobban kezelheto megoldas az, hogyha 1 pixel 1 byte-ban van
tarolva, hisz ilyenkor egy pointer kell csak a kepen valo
barangolashoz, ezt C-bol nagyon klasszul lehet kezelni. Nem szabad
viszont figyelmen kivul hagyni azt, hogy igy a kep mar kozel 9
megabyte lenne, amibol 8 teljesen feleslegesen foglalodik le,
raadasul a cache korlatozott merete miatt lassabban lehet kezelni
ezt a kepet (marmint az aktualis reszletet), mintha 1 bit lenne egy
pixel.

Kell tehat talani egy gyors modszert arra, hogy a kepet cimezhessuk 
valahogyan.

A kep tarolasrol meg annyit, hogy altolanosan alkalmazott rendszer
szerint a puffer legkisebb memoriacimen talalhato a kep bal felso
sarka, a byte-on belul a legnagyobb helyierteku bit (0x80) tarolja a 
bal szelso pixelt, a tobbi pixel sorra a kisebb helyierteku biteken 
van.

Az a helyzet, hogy ez a tarolasi mod sajnos nem a legszerencsesebb 
intel es hasonlo Little Endian processzoroknal, inkabb a motorola es 
tarsai Big Endian gepekhez illeszkedik.

(Nem tudom, mindenki tudja-e, mi ez az Endian-sag: az end=veg-bol
jon a szo, meg Swift (jol irom?) talata fel a Gulliver-ben, es
eredetileg arrol szolt, hogy melyik vegen erdemes feltorni a fott
tojast :)) A szamitogepben arrol szol, hogy a memoria elejere a gepi
szo kicsi vagy nagy helyierteku byte-ja kerul-e.)

Szoval LittleEndian gepeken azert szerencsetlen a pixelek ilyeten 
elrendezese, mert kenyelmetlenul lehet szavasan vagy duplaszavasan 
hozzaferni a kephez, mert a byte-hatarokon nem egymas melletti 
pixelek lesznek!

Memoriaban pixelek:
0. byte                          1. byte
0   1   2   3   4   5   6   7   |   8   9   a   b   c   d   e   f   

Regiszterben helyiertek:
AL                               AH
80  40  20  10  8   4   2   1   8000 4000 2000 1000 800 400 200 100

Jobb lenne, ha a bal szelso pixel az 1-es helyiertekre kerulne, a 
tobbi pixel pedig sorba a nagyobb helyiertekekre, de hat senki sem 
igy csinalja, es valamennyire alkalmazkodni kell a kulvilaghoz :(

Assembly-ben folytatom a dolgot, bar nehany #define-al C-be is 
atviheto amit irok, gcc eseten pl. a C optimalizacioja is 
megmarad az asm reszletek ellenere.

Szoval a legjobb megoldas talan egy pointert es egy bitmaszkot
alkalmazni: a pointer mutat az aktualis pixel byte-jara, a byte-os
maszk egyetlen 1-es erteku bitje pedig az aktualis pixelre.

Legyen pl. a pointer az EBX regiszterben, a maszk pedig az AL-ben. 
Ekkor az aktualis pixelrol igy donthetjuk el, hogy fekete-e:

    test  [ebx],al
    jnz   fekete    ; jump if not zero

(Ugyanez C-ben:  if (*pointer & maszk) {..fekete..} else {...} )

Az aktualis pixel felett es alatt levo pixelre konnyen at lehet igy 
is menni, egyszeruen a pointert kell csokkenteni illetve novelni a 
kep byte-ban mert szelessegevel. Trukkosebb az, hogy hogyan lehet a
bal illetve jobb szomszedjara menni:

jobbra lepes:
                ; al=80h        al=01h
    ror  al,1   ;    40h cy=0      80h cy=1      rotate right
    adc  ebx,0  ;        ebx+0         ebx+1     add with carry

balra lepes:
                ; al=80h        al=01h
    rol  al,1   ;    01h cy=1      02h cy=0      rotate left
    sbb  ebx,0  ;        ebx-1         ebx-0     subtract with borrow 

es kesz.
(Azok szamara, akik nem ismerik az asm-et: a rotalas elshifteli az 
adatot, es a kieso bitet beteszi egyreszt a carry-be, masreszt az 
adat tulso vegere. A subtract-nal a borrow ugyanaz fizikailag, mint a 
carry.)

Mara ennyi, a folytatasban a betu elsodleges szegmentalasarol, a 
korbejarasrol irok majd.

Akit erdekel a tema, annak egy hazi feladat: probald a kedvenc C
forditodhoz megirni a balra es jobbra lepes #define-jait vagy
inline-jait, es nezd is meg, milyen kodot general belole, mennyire
lehet optimalni. Az eredmenyt szerintem bekuldhetitek a listara, a 
tobbiek szamara is erdekes lehet.

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --

Szia,

beleneztem a cchecklistbox source-ban (winctrl3.cpp), es ott lehet latni,
hogy o lekezeli az ON_WM_LBUTTONDOWN uzenetet (sourceban meg is nezheted
hogy).
egyik modszer, hogy amelyik ablakban van atrakod az PreTranslateMessage
fn.-t es onnan te kezeled a klikket.

BOOL CDummyDlg::PreTranslateMessage(MSG* pMsg) 
{
if (pMsg->message == WM_LBUTTONDOWN) {
// ide rakhatod a te vizsgalatodat
}

return CDialog::PreTranslateMessage(pMsg);
}


Csaba

> =======================================================
> Felado :  [Hungary]
> Temakor: Checkboxos listbox klickelesi problema VC++ 5.0-ban ( 21 sor )
> Idopont: Thu Feb  5 22:00:18 EST 1998 CODER #14
> - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Sziasztok!

A kovetkezo problemaval allok szemben:

Van egy checkboxos listbox-om, amit a CCheckListBox-al csinaltam meg.
Jol mukodik is, de most kijott egy hiba:
Ha duplan klikkelek a SORRA, akkor minden tok jo, mert a dupla klikk
uzenet lekezeleset fel tudtam venni a Class Wizarddal. Itt bizonyos
feltetel eseten engedelyezem a kis pipa megjeleneset vagy eltuneset a
sor elejerol.
Viszont ha simplan klikkelek a sor_eleji_negyzetre akkor nem jon be a
dupla klikk uzenet (ertheto), viszont a kis pipa allapotot valt es en
nem tudom ellenorizni a dolgot. Osszekavarodnak az allapotok.

Szoval a baj az, hogy a sor eleji kis negyzet erzekeny a simpla
klikkre is es ezt nem tudom lekezelni.

Help please!

Koszi.
Pisti