ProCaster/Yamada Firmwaren kehitys (koodi painoitteinen viestiketju)

kun laite oli ollut kaukosäätimestä katkaistuna, ja avasin sen, niin kansiopolku näytti minulle I/II (kaikki nuo merkit yhden merkin sisässä = merkki 138). Nyt kun katkaisin virrat ja käynnistin uudelleen, niin kansiopolku on tyhjä (ei merkkejä). Näin kuitenkin tuon "uuuuuuuuuuuuuu" jo kertaalleen aiemmin, en vain tiedä oliko se tämä levy, vai jokin muu

EDIT: Vaihdoin levyä, ja nyt tulevat merkit ovat satunnaisia. Kun aeimmin näin nuo uuuuuuuuuuuu merkit, niin laite oli tehdasasetuksilla, nyt on suomi asetukset kaikkialla missä mahdollista. Muuta ei minusta tässä välissä ole muuttunut.

 

Tässä uudessa firmwaressa toimii kuitenkin kaikki muut tiedostoselaimen erikoisfontit, mitkä ei APEX-YAMA-firmwaressa toimineet. Tosin B7-versiossa oli modattu ARM-osa

 

Jos hakemistonimeä ei saa pelittämään niin voidaanko se poistaa kokonaan ruudulta. Ei ainakaan häiritse silloin.

 

selaimen fontit Y6600 8032 bank1

(1)
ROM:68DF 7F 07 mov R7, #7
ROM:68E1 02 05 83 ljmp OSD_TextFont

(2)
ROM:C58E 7F 07 mov R7, #7
ROM:C590 12 05 83 lcall OSD_TextFont

 

FILE BROWSER by MaBreaker: "Current directory and Folder icon is viewed top of file list (if it is not root) by DIR_Disp_DirLine function"

ROM:67AA DIR_Disp_DirLine:
joka sisällä on edellä mainituista se ensimmäinen

 

Paras päivitys mik löytyny mun Yamada 6600 8MB:n, kaks elokuvaa
mitä yritin kattoo aamulla ei toiminu kunnolla. Toisessa
äänisynkka pielessä ja toisessa ääni pätki pahasti. Mut ku päivitin
tähän:
http://personal.inet.fi/koti/temi/tiedostot/Y6600_Peekton_Risc_b1.zip
Alko pelittään loistavasti. Aikaisemmin oli Temin v15 mik seki tosi
hyvä b7 ei oikeen pelittäny. Kiitos varsinki temi ja RistoE.

 

Moikka!

Onko tämä Zapata nyt uusin versio. Ja mikä on toi srt-bugi? Ajastus?
http://zapata07.pt.to/
http://www.speedsurf.to/zapata07/6600_PeektonRISC_srtfix.rar

 

Kyllä pitäisi olla. Edit. srt-ajastusbugin vuoksi soitin ei osaa erotella millisekunteja
esim
00:02:53,994 --> 00:02:56,990
Eli firmware ei osaa huomioida xx:xx:xx,900 pilkun jälkeisiä numeroita
990 millisekuntia on jo melkein yksi sekunti ja sen alkaa jo huomata tekstityksessä.

Tämä on siis hyvin yleinen bugi Mediatekin piirillä varustetuissa soittimissa. Voisin arvioida ,että noin 90%.ssa alkuperäisissä firmwareissa on tämä bugi

-------------------------------------------------------------¨

RistoE:lle

alkuperäisessä V5 firmwaressa ROM:68E1 ljump ROM_583
Na v15 firmwaressa ljump ROM_F7F0
eli lopussa lisätty koodia

 

1) Nuo tiedostopolun oudot merkit saattaisivat tulla siitä että jostain edellisestä kirjoitus operaatiosta on jäänyt päälle väärä tila. Tällöin esimerkiksi tuo "u" voisikin olla kirjain 251 eikä 1.

2) Toisaalta pitäisi tarkistaa odottaako Peektonin ARM koodi että tiedostoselaimen merkistö olisikin 128 merkkinen. Apexissahan näin oli ja ilmeisesti tässä peektonissakin.

3) Kun palaan tiedoston katselusta, niin näyttää pitkän rivin uuuuuuuuuuuuuu, mutta kun käyn levyn alakansiossa ja palaan takaisin, niin näyttää vain yhden u:n. Kansio jonka nimen pituus on kuusi merkkiä, näkyy kahdeksalla u-kirjaimella. Nimeenhän ilmeisesti lisättäisiin alkuun ja loppuun \ merkit.

Minua nuo satunnaiset merkit eivät häiritse juurikaan, mutta pitää katsoa noita ajatuksella, aina kun niitä tulee putkelle.

 

Ei näytä myöskään olevan merkitystä jos vaihtaa ljmp lcall samaksi kuin alkuperäisessä v5 firmwaressa. Samat u-kirjaimet näkyy näytössä

 

Kun laite käynnistetään ja tiedostopolku on "u", niin tuossa oikein on merkkien määrä. Kun toistosta palataan tiedostoselaimeen, ja näytössä on "uuuuuuuuuuuuu", niin tuntuisi että silloin on kadotettu oikea tiedostopolun merkkien määrä sekä luetaan väärää muistialuetta (jossa on pelkkää 00 00 00 00 00 00 ...). Kun sitten käydään alihakemistossa ja palataan päähakemistoon, niin koodi osaa taas laskea polussa olevien merkkien määrän, mutta lukee väärää muistialuetta?

Mutta jos uskoo ylläolevaan, niin sitten pitää ihmetellä miten tiedostonimet menevät oikein. Pitäisi löytää kuvaus siitä miten noita tiedostonimiä ja polkuja luetaan muistiin, ja onko se 8032 koodissa vai ARM koodissa. Ilmeisesti luku on ARM koodilla ja näyttö 8032 koodilla?

 

Pitää vielä kokeilla alkuperäistä Yamada 6600 v5 8032 osaa ja peektonin risc osaa ->onko sama bugi?

Edit. Testitulokset: Ei näyttänyt yhtään kirjainta (Ei edes U:ta)

 

dokumentissa CP125x Conversion in FileBrowser: WriteFileName2List rutiinista, joka on ARM koodissa, löytyy osat WriteDirName ja WriteFileName.

Pitää myöhemmin tutkia miten WriteDirName osuudet eroavat NAv15 koodissa ja Peektonissa. Ilmeisesti WriteFileName osuuksien pitäisi olla yhtenevät. Jos vain WriteDirName osuudessa on eroa, niin sitten pitäisi yrittää korvata Peektonin vastaava osuus NAv15 koodilla.

Peekton ARM:
ROM:00020BFA ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
ROM:00020BFA
ROM:00020BFA
ROM:00020BFA WriteFileName_to_List ; CODE XREF: sub_20D04+144p
ROM:00020BFA
ROM:00020BFA arg_14 = 0x14
ROM:00020BFA arg_18 = 0x18
ROM:00020BFA arg_1C = 0x1C
ROM:00020BFA arg_20 = 0x20
ROM:00020BFA
ROM:00020BFA PUSH {R0-R2,R4-R7,LR}
ROM:00020BFC MOV R0, #0x20 ; ' '
ROM:00020BFE LDRB R7, [R0,R1]
ROM:00020C00 ADD R1, #0x21 ; '!'
ROM:00020C02 SUB SP, SP, #0x10
ROM:00020C04 STR R1, [SP,#-0x10+arg_14]
ROM:00020C06 CMP R2, #0
ROM:00020C08 BNE loc_20C0E
ROM:00020C0A MOV R6, #1
ROM:00020C0C B loc_20C10
.
.
.
ROM:00020C94 WriteDirName ; CODE XREF: WriteFileName_to_List+CAj
ROM:00020C94 LDR R0, [SP,#-0x10+arg_18]
ROM:00020C96 LDR R1, [SP,#-0x10+arg_14]
ROM:00020C98 ADD R0, R0, R6
ROM:00020C9A ADD R1, R0, R1
ROM:00020C9C SUB R1, #0x10
ROM:00020C9E LDRB R1, [R1,#0xF]
ROM:00020CA0 LDR R2, [SP,#-0x10+arg_20]
ROM:00020CA2 LSL R0, R0, #0x18
ROM:00020CA4 STRB R1, [R2,R4]
ROM:00020CA6 ADD R4, #1
ROM:00020CA8 LSR R0, R0, #0x18
ROM:00020CAA LSL R4, R4, #0x18
ROM:00020CAC LSR R4, R4, #0x18
ROM:00020CAE STR R0, [SP,#-0x10+arg_18]
ROM:00020CB0
ROM:00020CB0 loc_20CB0 ; CODE XREF: WriteFileName_to_List+72j
ROM:00020CB0 LDR R0, [SP,#-0x10+arg_18]
ROM:00020CB2 CMP R0, R5
ROM:00020CB4 BCS loc_20CE0
ROM:00020CB6 ADD R0, R6, #0
ROM:00020CB8 LDR R1, [SP,#-0x10+arg_1C]
ROM:00020CBA BL loc_21CF8
ROM:00020CBE MOV R1, #0x32 ; '2'
ROM:00020CC0 SUB R0, R1, R0
ROM:00020CC2 CMP R0, R4
ROM:00020CC4 BGT WriteDirName
ROM:00020CC6 B loc_20CE0

 

my-yamada foorumilla zapata07 kysyy voisiko tehdä orginal 8032+pk_arm firmwaren, jotta hän voisi testata tulevatko jotkin pienet jumit 8032 koodin muutoksista. Temi, onko sinulla tue eilinen testiversiosi vielä tallessa. Se on minusta juuri mitä zapata07 haluaisi testata.

Toinen juttu että ltsouk sanoo ettei näe u-merkkejä, hänellä on käytössä koodisivu 1253.

 

Original Yamada 6600 v5 8032 + Peekton 6002 RISC
http://personal.inet.fi/koti/temi/tiedostot/Y6600_v5_peek_arm.zip

Edit. corrected link

Se johtuu siitä että ltsouk:in fonteissa on 1:n kohdalla on tyhjä kohta
NA v15 firmwaren 1-5 paikalla on fontteja. u-kirjain on ensimmäisenä
siellä, mikä näkyy tiedostoselaimessa.
http://personal.inet.fi/koti/temi/kuvat/font.jpg
Fontcreatorilla tehdyissä fonteissa 1-5 paikalla on vain tyhjää

Ideahan tuossa on se, että loppupään fontteja, kun ei saada näkyviin muuten niin ne näytetäänkin alussa
(joskus kokeiltiin muttaa ARM-osasta 7E->FF:ksi, mutta tiedostoselain ei kuitenkaan kyennyt näyttämään loppupään fontteja

Tämä bugi vaikuttaa minusta,että ARM ja 8032-osan yhteys on jostain koti poikki, kuten esim. tuon dokumentin tapauksessa ei toiminut tekstitys, vaan se piti korjata 8032 bank1-osassa
http://f1.grp.yahoofs.com/v1/0M7CQ3...ents/How to use MTK Risc in BBK firmwares.rtf

Pitää minunkin vielä testata tuo DivX test cd2, kunhan ensin polttelen sen levylle

 

kirjoittelin illalla my-yamada sivustolle sinun muistiinpanojesi pohjalta ohjeet kuinka vaihtaa NAv15 versioon toinen risc. Nyt on mielenkiintoista nähdä millaisia kokemuksia ihmisiltä tulee.

 

Nyt toistaa minun United 4067M soitin Packed bitsream leffat kunnolla ja tukee lähes kaikkia tekstitysmuotoja, mutta yllätys yllätys! unitedissa toimii kansiopolku oikein
(kävi hyvä tuuri kun ei tarvinnut koskea 8032 osaan)
DTS Downmix toimii myös

 

mitä arm versiota käytät? peekton 6002?
jos käytät, niin ehkä NAv15 8032 koodista jäi sittenkin jokin osoite muuttamatta? Tosin kävin koodia itsekin läpi jokunen päivä sitten enkä löytänyt muita osoitteita joita muuttaa.

EDIT. tutkin tuon sivultasi löytyvän united v5 version ja sen arm osoitteet toisaan täsmääväät. Aika mahtava hiene yhteensattuma! Tästä pitäisi osata päätellä jotain tuon tiedostopolun ongelmasta. Tietäisi vain mitä...

 

peekton 6002v2 risc-osaa joka on laitettu minun sivulta löytyvään 4067M v5 firmwareen

 

Bank 3 koodi:
ROM:C553 90 F8 E0 mov DPTR, #0xF8E0
ROM:C556 E4 clr A
ROM:C557 F0 movx @DPTR, A ---------: 0xF8E0 saa arvon 0
ROM:C558 A3 inc DPTR
ROM:C559 74 38 mov A, #0x38 ; '8'
ROM:C55B F0 movx @DPTR, A ---------: 0xF8E1 saa arvon 38
ROM:C55C A3 inc DPTR
ROM:C55D EF mov A, R7
ROM:C55E F0 movx @DPTR, A ---------: 0xF8E2 saa arvon R7
ROM:C55F A3 inc DPTR
ROM:C560 ED mov A, R5
ROM:C561 F0 movx @DPTR, A ---------: 0xF8E3 saa arvon R5
ROM:C562 30 1C 0D jnb RAM_23.4, ROM_C572
tässä olevaa viittausta jaettuun muistiin pitää tutkia. Casmir666 ohje sanoo että tällainen osoite olisi olemassa, ja että arm koodin puolelta "ARM_Unk7" käyttää tätä osoitetta, mutta tuossakin ohjeessa on tällä kohtaa kysymysmerkkejä ja että "function ARM_Unk7 seems different on Yakumo and HB". Varmaankin ongelman lähde on tässä. Taidan verrata alkuperäisen firmwaren bank 3 koodia tähän pätkään.