Szia!
Ez engem is érdekelne.
pjg nekem megvan az egész ha érdekel.

Köszi, szerintem ez a könyv meg is van nekem otthon.

Lehet, hogy kicsit félreérthető voltam. Nem az MBR és a bott szektor adatainak az értelmezése okoz gondot, hanem arra keresek módszert, hogy mi alapján azonosíthatók ezek a szektorok. Ugyanis mindkettőben csak a szektor végén lévő 55AA szignatúra az egyetlen, ami ilyen jellegű dolgokra definiált, viszont ez nem különbözteti meg őket. Azaz ha látok egy ilyen szignatúrát, akkor csak abban lehetek biztos, hogy vagy MBR-t, vagy partícionálatlan kártya esetén a boot szektort olvastam be.

A másik dilemmám, hogy a boot szektorban nincs semmilyen azonosító, ami alapján ki lehetne jelenteni, hogy az egy FAT boot szektor, illetve, hogy melyik verziójú FAT. A Microsoft FAT32-es leírása (ami kitér a korábbi, 16 és 12 bites verziókra is) is csak annyit ír, hogy kizárólag a filerendszerben lévő clusterek száma alapján lehet eldönteni, hogy az 12, 16 vagy 32 bites FAT-e éppen.

A fentiekhez kapcsolódó további dilemma, hogy racionálisan gondolkodva egyáltalán fel kell-e készülnöm mindenféle konfigurációra, pl. a partícionálatlan kártyán lévő filerendszerre, vagy például a FAT12 használatára. Gyakorlati szempontok alapján megfogalmazott véleményetek érdekelne ezzel kapcsolatban.

Jó olvasni, hogy másoknak is megvan a könyvem...

Gyakorlati szempontok alapján vannak olyan mezők, amiknek stimmelniük kell, különben invalid az adott célra a mező. Pl. a boot sector esetén ilyen a médiatípus mező (itt tipikusan 0xf8 szokott lenni HDD-ken), ilyen a partíció első blokkjának az abszolút címe a diszken (ennek egyeznie kell, különben pl. semmilyen m$ oprendszer nem hajlandó bootolni onnan).
A partíciós táblánál meg ilyen mező a partíció típusa, ill. az, hogy a partíció blokkjai (kezdő és befejező blokkja) a device méretéből nem lóghatnak ki.

De amúgy én azt olvastam ki az (éppen az imént átküldött) doksiból első olvasásra, hogy az MBR nélküli, naked partíció az nem szabványos.

Ha jól emlékszem az volt a lényeg, hogy az MBR alsó felén a partíció tábla kiértékelő program van, az értelmezi a legfelső területen, az 55AA előtt levő 4 bejegyzést. A boot szektor is ilyen felépítésű, de a benne levő program boot adatokat kezeli. Ja, egy 80x86 -tal egyszerű.
Emlékeim szerint a partíció típuskódja megmondja a DOS partíció típusát (< 32M avagy >32M), a boot rekordban van egy Media descriptor kód, amiből meg lehet állapítani, hogy floppy (FAT12) vagy Hard disk (FAT16) a meghajtó. Ezenkívül ott van a System ID mezőben:


Az MBR -ben nincs ilyen szöveg...

Amit csatoltam, abban ott látom a FAT tipusához az azonosítókat. Azok nem azok? (MBR 04h címtől)

Nálam is ott ül a könyvespolcon ezen könyved.

Igen, ha van MBR, akkor az ott felsorolt partíciók típusaiból elvileg lehet következtetni. Egyre inkább hajlok arra, hogy az MBR nélküli flashdiszkeket el fogom utasítani.

Kicsit azért furának tartom, hogy anno a FAT kitalálásakor semmiféle azonosítót, szignatúrát nem tettek bele a boot szektorba, és csak közvetett úton (ahogy _vl_ is írta: bizonyos mezőkben lévő értékek hihetősége, konzisztenciája alapján) lehet többé-kevésbé megbizonyosodni arról, hogy tényleg egy FAT boot szektorral áll szemben az ember. Ugyanilyen meglepő számomra, hogy a FAT verziója is csak közvetett információkból található ki. A német szövegben a boot szektor 36H pozíciójában kezdődő "FAT name" mezőről is annyit mond az MS, hogy az csak egy tájékoztató mező, igazából nem jelent semmit, ráadásul nem is kötelező, a 26H pozíción lévő szignatúra jelzi, ha az utána következő 3 mező ki van töltve.

Azért nem voltak haszontalanok az infók, amiket adtatok, megpróbálok összeállítani egy folyamatot erre a döntési mechanizmusra.

Miért is lett volna azonosító egy 360k -s foppy boot szektorában?
El sem tudtuk képzelni azt, hogy más is lesz. Egyszerűen nem volt még kitalálva sem a FAT16, sem a többiek...

Valahol a fórumban már felmerült egyszer egy hasonló eset, most meg fogom magam ismételni. Van egy konkrét célod amit szeretnél megvalósítani, miért bajlódsz olyasmivel amit mások már rég (és jól) megoldottak? A 18as széria már támogatja a Microchip MMC/SD fájlkezelő könyvtárát, FAT32 sem gond neki, használhatsz alkönyvtárakat, hosszú fájlneveket, létrehozhatsz állományokat vagy mappákat egyszerű függvényhívásokkal, sőt még keresési funkciók is vannak.
Rengeteg tapasztalatot és tudást szerezhetsz ha magad írod (pláne assembly ben) de nem lesz a legcélravezetőbb...

Az ötlet felmerülésekor még egy nyers memóriakártyában gondolkodtam, mondván összeállítom a "szalagtartalmat" valami PC-n futó progival, aztán mehet ki az SD-re dd-vel. Ráadásul a feladat megvalósításához - úgy gondolom - nagyon hasznos lenne minél hardverközelibb módon közelíteni, mert az impulzusok generálásakor elég kis időzítéseket kell pontosan betartani, főleg a "turbó"-s állományok visszajátszásakor. Később gondolkodtam el rajta, hogy nem biztos, hogy baj lenne ha fileokból dolgoznék.

Egyébként nem igazán kedvelem a C-s megoldásokat, több okból sem. Az egyik, hogy ami ingyenes, az hol itt, hol ott nyavalyás, ami meg jól használható, az meg közel sem ingyenes. Egy másik ok a méret és a sebesség kérdése. A neten kotorászva egyébként láttam FAT-os libeket és hasonlókat, de azért a valamelyiknél látott tizen- vagy huszon k-s helyfoglalása kicsit el is rémített a használatától, illetve arról győzött meg engem, hogy akkora tudásra nekem nincs szükségem, amit ezek nyújtanak.

Mellesleg ahol most állok, abban még azért akkora munkabefektetésem sincs, gyakorlatilag az elmúlt hétvége szabad időit használtam fel rá. Talán csütörtökön munka után tettem fel a nyomógombot, a LED-eket, meg egy 20MHz-es kvarcot és lógattam rá egy LCD modult egy üres 28 pin demo board-ra. Péntek este meg az SD foglalatot és az illesztőit építettem rá egy lukacsos paneldarabra, és ezt is vezetékekkel lógattam rá a vezérlésre. Azaz a hardver ekkor állt rendelkezésre, ezután kezdtem úgy az MPLAB X-ben, hogy "new source file" Az előtte való egy-két héten azért üres időimben elég sokat olvasgattam a szakirodalmat az SD kártyákról.

Mellesleg még morfondírozok azon, hogy floppy drive-ot is lehetne emulálni a C64 felé egy hasonló hardverrel. Ott azért kicsit bonyolultabb a dolog, mert a trükkösebb dolgok a floppyba letöltöttek programrészleteket, amiket ott futtattak, és azokkal kommunikálva töltötték be a dolgokat a lemezről. De ez már egy processzoremuláció lenne, ilyet biztos nem csinál az ember PIC-kel. Ezen még gondolkozom egy kicsit

Linuxot használsz?


Szerintem ilyet a normál c64 nem csinált, csak különféle turbo programok. Nekem volt ilyen 1541-em, csak ott permanensen át volt írva a 1541 programja, ill. a c64-ben is más volt a ROM helyén, így tudta 20 sec alatt végigolvasni az egész lemezt.

A helyfoglalást illetően ezt a könyvárat lehet konfigurálni, ha nincs szükség az írásra vagy a keresésre egy szimbólum törlésével deaktiválódik az egész kód. Időzítést könnyen meglehet oldani puffereléssel s az adatok továbbításával megszakításon keresztül. Ők is hardwareközelben oldották meg hiszen ay egész lényegében az SPI modult használja, csak te ezt alapállapotban nem látod. Plusz a könyvtár rétegelve van: a felső a fájlrendszer az alsó az SPI kezelése, nyugodtan ki lehet cserélni vagy módosítani ha valamelyik nem a célnak megfelelő.
Nem igazán kerestem más könyvtárakat neten, de a ez a Microchiptől ingyenes és nagyon is jól használjató. És le merem fogadni, hogy egy optimális fordító sokkalta gyorsabb és kompaktabb kódot fog generálni mint amit Te vagy én valaha meg fogunk tudni írni assembly ben. A fordítás alatti optimalizálás egész kis tudomány, én csak belekóstoltam s hihetetlen komplex.
Csak bátorítani tudlak a használatára.
(Jelenleg egy zene lejátszón dolgozom, olvas kártyáról, adatokat továbbít a codec nek, kezeli a színes grafikus képernyőt(320x240) a szintén Mchipes GOL könyvtárral, kezeli az érintőfelületet és még így sem csúsznak el az időzítések. Képes lejátszani 48kHz 32 bites sztereó WAV okat és az már 3Mbit/s.. Igaz ez egy PIC32)

Te már találkoztál olyan SD-vel, amin nem volt MBR? Sima formatáláskor nem keletkezik, csak ha rendszer lemeznek formatálod?

Hogy mit meg nem lehet oldani mikrokontrollerekkel: nemrég láttam egy elég elvetemült projektet, egy ARM emulátort ami egy 25 MHz-es AVR en futott. 32 MB RAM lett hozzácsapva, a teljesítménye egy 6-7 kHz es ARM processzorral ért fel. SD kártyáról olvasta az adatokat, 6 óra alatt felállt róla az X!

Talán segít az alábbi pár link:
( épp tegnap gondoltam én is erre, hogy jó lenne C64 -hez ilyesmi )

http://jderogee.tripod.com/project1541.htm


_vl_ : hmm speeddos régi szép idők..

Hogy láttam-e ilyet, azt nem tudom, mert korábban sosem vizsgálgattam őket. Most viszont igen, és az Ubuntu disk utilityjéből simán meg lehet formázni őket MBR-esen és csupaszon is (sőt, még más partícionálások szerint is). A csupaszra formázott is ugyanúgy használható, legalábbis Linux alatt. Az biztos, hogy többfelé partícionált SD-vel már találkoztam, pedig az sem mindennapos felhasználás. A vmware esxi installer ha flash-re installáltatja az ember, akkor 3 vagy 4 partíciót hoz létre és oda pakolgatja a cuccait. Ráadásul a flash bootolható is lesz.

Azt ki fogom próbálni, hogy a csupaszt bedugom a fiam Win 7-es gépébe, hogy ott hogy néz ki.

Idézet:
„Linuxot használsz?”

Igen, már több mint 3 éve laptopot használok a saját cuccaimhoz, és azon Ubuntu van. Korábban MPLAB-ot VirtualBox-os XP-n futtattam, mostanában inkább a javas MPLAB-X megy a linuxon.

Idézet:
„?mert a trükkösebb dolgok a floppyba letöltöttek programrészleteket, amiket ott futtattak, és azokkal kommunikálva töltötték be a dolgokat a lemezről.?

Szerintem ilyet a normál c64 nem csinált, csak különféle turbo programok.”

Igen, pont arra utaltam. Volt pár turbóbetöltő, amit elindítva a betöltő a saját, gyors kommunikációjához tartozó rutinokat átküldte a floppyba és azok ott futottak. És láttam anno olyan, egész lemezes játékot is, ami hasonlóan turbózott. Nomost egy játékba lehet, hogy más kommunikáció van beépítve, mint egy általános turbóbetöltőbe, így nem biztos, hogy olyan egyszerű ilyesmit emulálni PIC-kel. De a normál lemezkezelést egészen biztosan meg lehet csinálni, meg esetleg valami általános turbós adatátvitelt is.

Megnéztem, a Win7 is kezeli rendesen a partícionálatlan SD-re létrehozott FAT-ot.

Jópofa cucc, majdnem pont ilyenen gondolkodtam én is Bár nekem eszembe jutott, hogy akár a fileok is tárolhatók lennének a FAT filerendszerben, és akár sokkal nagyobb méretű floppyk is behazudhatók lennének. Fene tudja, csak ötletelek még a dolgon...

Egyébként itt is írja: "Because the circuit is based on a PIC microcontroller and not a fancy FPGA or 65xx processor it will never act 100% the same as an 1541. This is the main reason why fastloaders will not work as on a real 1541. " - ez pontosan az, amire utaltam korábban.

Sziasztok!
Akadt egy kis problémám a c30 fordítóval.

void init_xlcd(void)
{
OpenXLCD(FOUR_BIT & TWO_LINE & SEG1_50_SEG51_100 & COM1_COM16);
while(BusyXLCD());
WriteCmdXLCD(DON & CURSOR_ON & BLINK_OFF);
while(BusyXLCD())


char mesg1[] = {'H','A','R','D','W','A','R','E','\0'};
putrsXLCD(mesg1)


}

Ebböl a linker az putrsXLCD(mesg1)
sort nem fogadja el. Az xlcd.h -ból az összes többi
utasítás jó neki.
Mi lehet a hiba?

Üdv kszabi

Nem a pontosvesszőt hiányolja?

Két pontosvessző is hiányzik, s ha ezek után sem jó, akkor meg kell nézni, hogy MIT ÍR KI, mi a megnevezett hibaok.

Üdvözlet! Ez a Hex nincs meg valakinek átalakítva, hogy 50voltig tudna mérni? Ott van alul, letölthető, de 30v-nál megáll a kijelzés. Köszönöm. http://electronics-diy.com/digital-volt-meter-with-pic16f676.php

Sziasztok!
Bővíteném a Watt féle USB HID demot 18F2550 -re C18 -ban. Lefordul szépen. Létrehozok benne egy csomó string descriptort const ROM struct{ ... } sorokkal, ahogy a demoban az eszköz neve van definiálva. Minden állomány lefordul, de a linker nem tudja összeállítani a kódot.


Miért panaszkodik egy RAM terület túl nagy méretére, amikor csak const ROM ... sorokat tettem a kódba? Ha ezeket a sorokat kiveszem, a linkelés sikeres.

Ha assembly állományként hozom létre a stringeket, hogyan érhetem el, hogy ne a kód elejére, hanem egy általam megadott címterületre kerüljenek?
Köszönöm

Írd már be, hogy pontosan mit definiáltál, amit az idata-ba akar rakni...

Sziasztok!
dsPIC33FJ16GS402 típusú vezérlőhöz keresek szimulátort. Valaki tudna mondani ilyet? Az Ohson Software termékei között nem találtam ilyet, sajnos a Proteus sem támogatja, több ilyen programot pedig nem ismerek, google sem tudott sok okosat mondani.

Előre is köszi a segítséget

MpLab Sim, de ez is csak beta...

A fenti sorból hozam létre 18 darabot különböző szöveggel, természetesen egyedi azonosítókkal és a méretnél (sizeof()) mindig a saját azonosítót adva meg, a méret minden esetben jól megadva. Megpróbáltam így és a köv formában is:


Ha csak néhány sort (2 - 3 sort) fordítok be, akkor rendben megtörténik a linkelés is..

Üdv, Pic pwm komparrátort szeretnék építeni, hogyan tehetem meg? szóval bemegy a szinusz és a másik oldalt meg a pwm jön ki, 16 - 32 bites érdekelne.