rdos skrev:Genombrott!

*applåd* det brukar inte vara så enkelt att få igång saker på ny "arkitektur"... en PC är inte alltid en PC.

nitro2k01 skrev:För framtida referens, GRUB4DOS is the kitt! (sic)
http://gna.org/projects/grub4dos/
Det är en version av GRUB som kan laddas på ett antal sätt: Från DOS, från XP's boot.ini, från GRUB ( ) och med kexec. Till och med från Vista mha bcdedit, om man får tro manualen.

Låter imponerande.

nitro2k01 skrev:G4D kan göra allt som vanliga GRUB kan, plus en del intressanta saker som mig veterligen vanliga GRUB inte kan göra:
* Den kan läsa filer frän NTFS, OOB. (Det kanske GRUB2 också kan iofs)

Även om detta skulle funkat med just min GRUB, så skulle det inte hjälpt så mycket. RDOS kan inte läsa NTFS, och kan därmed inte heller starta de applikationer som byggs under Windows. Om de inte läggs med i binärfilen, vilket är ganska onödigt.

nitro2k01 skrev:* Den kan emulera diskar i RAM, både disketter och IDE-diskar, förutsatt att OS'et accessar disken i realläge. Detta funkar uppenbart för DOS men jag har även lyckats köra Windows 98 från en preparerad disk image. Går även att göra från disk, men då readonly. Om OS'et accessar disken i realläge som sagt.

Vilket RDOS inte gör. Det skulle varit extremt ineffektivt. RDOS kör i protected mode, och kör "realläge" kod i virtual 86 läge.

nitro2k01 skrev:* Den kan ladda Windows XP natively, alltså inte genom klassikern "chainloader +1" utan genom att faktiskt ladda in Windows-kärnan till en lämplig plats i minnet, preparera registren på det sätt som kärnan förväntar sig och hoppa till entry point. Vanliga GRUB kanske också kan göra detta, bara att man inte brukar göra så... Jag vet inte.

OK, jag är impad.

Klarar den av att ladda RDOS utan ett mellansteg (grubload.bin) oxå? Det är nämligen så att för att kunna starta RDOS direkt så duger det inte att sätta upp "flat-mode" och hoppa till en entrypoint. RDOS initialiseras i 16-bitars protected mode, inte i flat mode.

nallen skrev:

rdos skrev:Genombrott!

*applåd* det brukar inte vara så enkelt att få igång saker på ny "arkitektur"... en PC är inte alltid en PC.

Jag trodde knappt själv på att det skulle fungera, även om dokumentationen påstod att det var standard PS/2 mus och tangentbord. Dessutom hade jag inte lyckats lösa APIC-konfigurationen på min stationära, utan den hängde sig fortfarande så fort avbrottssystemet sattes på. Nu har jag satt in default-värden för APICen på min bärbara (vilka stämmer med de som fanns från början), så då kanske man kan få igång även den stationära.

Det som fortfarande är osäkert är specarna på nätverkschipen. Det är Atheros som tillverkat dom, och deras hemsida är väldigt torftig utan specar. Verkar inte heller finnas specar på nätet. Jag skickade iaf en "inlindad" frågeställning till dem om att få tillgång till specarna. Detta har jag lyckats med förr. Annars får jag nog använda Linux-drivrutinen som mall, vilket inte alls är lika bra.

Nu löste du ju problemet här, men med tanke på ev. framtida liknande äventyr. Hade det inte kunnat räcka att göra en extra partition med FAT och där du installerar rdos? Då kunde du från windows kopiera över allt nödvändigt till rdos-partitionen, även om du inte kan läsa från andra hållet. Nackdelen är förstås att du måste boota om varje gång du behöver någon ytterligare fil, eller behöver använda något win-program, men det borde väl vara en fungerande, om än något mera omständig, lösning?

På sikt kanske det vore värt att lära rdos läsa NTFS? Det kan säkert finnas många kommersiella applikationer där man kan vilja ha både OSen parallellt. jag vet inte om MS har släpp tnågon dokumentation av NTFS, men linuxfolket har ju uppenbarligen knäckt det i alla fall, och där är ju källkoden öppen.

Kvasir skrev:Nu löste du ju problemet här, men med tanke på ev. framtida liknande äventyr. Hade det inte kunnat räcka att göra en extra partition med FAT och där du installerar rdos? Då kunde du från windows kopiera över allt nödvändigt till rdos-partitionen, även om du inte kan läsa från andra hållet.

Det skulle funkat med en NTFS-boot partition + en nyare GRUB, kompletterad´med en FAT-partition. Då kunde jag lagt Windows och Windows-program på NTFS, och utvecklingsverktygen + allt som RDOS behöver på FAT32. Problemet är förstås att jag då behövt ett verktyg för att minska NTFS-partitionen efter eMachines installation (de använder hela disken). Annars finns ingen plats för FAT32 partition.

Kvasir skrev:På sikt kanske det vore värt att lära rdos läsa NTFS? Det kan säkert finnas många kommersiella applikationer där man kan vilja ha både OSen parallellt. jag vet inte om MS har släpp tnågon dokumentation av NTFS, men linuxfolket har ju uppenbarligen knäckt det i alla fall, och där är ju källkoden öppen.

Vet inte hellerr hur det är med detta heller egentligen. Jag tror att dokumentationen numera finns tillgänglig, men det är ganska omständigt att skriva nya filsystemsdrivrutiner till RDOS. De skrivs ju i assembler.

rdos skrev: Problemet är förstås att jag då behövt ett verktyg för att minska NTFS-partitionen efter eMachines installation (de använder hela disken). Annars finns ingen plats för FAT32 partition.

Naturligtvis, men det finns gratisprogram som gör det.
Den här har jag kört, och såvitt jag minns körs den från windows och behöver inte brännas på någon bootbar skiva.
http://www.partition-tool.com/personal.htm

Kvasir skrev:Vet inte hellerr hur det är med detta heller egentligen. Jag tror att dokumentationen numera finns tillgänglig, men det är ganska omständigt att skriva nya filsystemsdrivrutiner till RDOS. De skrivs ju i assembler.

Måste du skriva allt i assembler då? C/C++ kommer ju åt allt på lågnivå, och det går ju att komplettera med små assemblersnuttar om något måste optimeras bättre än kompilatorn gör det. Men visst, det är säkert en massa jobb ändå med att läsa NTFS. Jag tänkte mest att det kan vara en kommersiell fördel.

Kvasir skrev:Måste du skriva allt i assembler då? C/C++ kommer ju åt allt på lågnivå, och det går ju att komplettera med små assemblersnuttar om något måste optimeras bättre än kompilatorn gör det. Men visst, det är säkert en massa jobb ändå med att läsa NTFS. Jag tänkte mest att det kan vara en kommersiell fördel.

Det finns ingen C/C++ kompilator som klarar av minnesmodellen i RDOS kärna. Den som är närmast (men som fortfarande behöver anpassas) är Open Watcom. Den supportar 48-bit segmented minnesmodell (som vissa versioner av OS/2 oxå använde). Fast OS/2 använde då kodsegment med 32-bitars attribut. RDOS använder mestadels 16-bitars kodsegment med 48-bitars pekare.

Att anpassa Open Watcom till att även kunna kompilera kod för RDOS kärna är dock ett möjligt framtida projekt. Som säkert kommer före att göra NTFS.

OK. Nu är jag dåligt insatt i hur detta fungerar i praktiken nuförtiden. Det är väl 25-30 år sedan jag intresserade mig minnesmodeller, och hur den tidens principer och visioner har utvecklats idag har jag dålig koll på. Jag funderar dock på hur många referenser man behöver göra som inte är lokala inom segment, och om man skulle kunna skriva egna rutiner i assembler för sådana accesser och hopp? Vilket segment som avses för lokal addressering är väl implicit genom något segmentregister, om jag minns rätt. Ditt problem skulle då vara att du behöver 16-bits lokal adressering, inte 32-bits. Det får mig då att tänka på DJGPP, en C++-kompilatro som utvecklades för att utveckla program till MS-DOS, och såvitt jag förstår använder just 16-bitsadressering.

http://www.delorie.com/djgpp/

För att skydda olika drivrutiner och datasegment ifrån varandra så jobbar RDOS internt med ett kodsegment per drivrutin, och oftast oxå med ett datasegment per drivrutin. Nästan alla kodsegment är 16-bitars, eftersom inga drivrutiner är större än 64kb. Den som kommer närmast är själva kärnan som är kring 50kb idag. Men för att kunna stödja alla typer av applikationsprogram så är alla pekare 48 bitar (16 bitar selektor + 32 bitars offset). De pekare som kommer ifrån typiska applikation skrivna med "flat" är då ett konstant selektor + en 32 bitars offset. 16 bitars protected mode applikationer använder selektor + 16 bitars offset. De kan använda samma funktioner genom att öka offset-delen till 32-bitar (den höga delen fylls med nollor). För DOS-program finns funktioner som skapar en selektor ifrån ett segment, så att de kan använda 16-bitars protected-mode versionen av anropen. På assemblernivå så är detta inte svårt att hantera, men de flesta C-kompilatorer klarar inte ut detta. Dessutom så består anropen av en speciell ogiltig op-kod + ett register-interface. Detta klarar Open Watcom elegant av att hantera genom att man kan definiera vilka register som kan kopplas till speciella parametrar i ett anrop.

Vänta nu, menar du att går att ställa in Open Watcom så den gör vad du behöver? Eller var det bara en del av det som gick att ordna?

Sedan har förstås både Open Watcom och GCC öppen källkod, så det borde gå att hacka om det själv, men det kanske inte är så enkelt att det är några lokala ändringar på några få ställen bara?


Jag gillar idén med separata segment för varje drivrutin, ur säkerhetsaspekt. Det låter imponerande också med en kärna på bara 50 kB i dagens läge. Å andra sidan är det kanske snarare mera imponerande hur andra lyckas göra så stora kärnor. Fast Linuxkärnan går kanske att får ner i storlek ganska bra om man strippar den på "onödiga" finesser.

Kvasir skrev:Vänta nu, menar du att går att ställa in Open Watcom så den gör vad du behöver? Eller var det bara en del av det som gick att ordna?

Det behövs nog en hel del ändringar i kompilator och miljö för att klara det, men jag tror att om jag skulle få lust med detta så kommer jag att få lägga in det i "trunk" oxå. Chapin, som håller i Open Watcom, kontaktade mig redan för över fem år sedan då kompilatorn skulle gå över i Open Source, men just då avvaktade jag med att göra något. Det var för ett år sedan som jag åter besökte projektet och ville få lägga in applikationsdelen. Då fick jag en egen "branch", som nu är fullt integrerad i "trunk". Jag har oxå numera skrivrättigheter till "trunk", det hade jag inte från början.

Kvasir skrev:Sedan har förstås både Open Watcom och GCC öppen källkod, så det borde gå att hacka om det själv, men det kanske inte är så enkelt att det är några lokala ändringar på några få ställen bara?

Nej, knappast. Det är hundratalet ställen jag varit inne på bara för att få till själva skapandet av exekverbara filer + debugger. Gör man det i en egen version av t.ex. GCC så är det en omöjlighet att hålla sig uppdaterad. Koden divergerar ganska snabbt så att man blir avskärd ifrån möjligheten att hålla sig aktuell med vad som händer. Det överlägset bästa sättet är att lägga in koden i själva projektet. Då blir den lätt att underhålla, och de som gör saker gör dem även för ens eget projekt.

Att få in ett mindre känt system i GCC är väldigt svårt. Jag höll på i månader bara med att få med några få patchar till binutils. Vet inte om de finns med idag eller inte. Jag gav upp.

Kvasir skrev:Jag gillar idén med separata segment för varje drivrutin, ur säkerhetsaspekt. Det låter imponerande också med en kärna på bara 50 kB i dagens läge. Å andra sidan är det kanske snarare mera imponerande hur andra lyckas göra så stora kärnor. Fast Linuxkärnan går kanske att får ner i storlek ganska bra om man strippar den på "onödiga" finesser.

Det behövs nog strax under 1 MB för att få till något som är användbart dock. Fast då får man USB, ethernet. grafik, standard tangentbord, mus, FTP-server och en DOS-liknande kommandotolk. Plus en miljö för att köra Open Watcom program.

rdos: Finns såsen grubload.bin (eller load.exe för den delen) att tillgå någonstans? Jag kan iofs diassemblera, men kod med kommenterarer och etikettnamn vore inte fel

rdos skrev:Det behövs nog strax under 1 MB för att få till något som är användbart dock. Fast då får man USB, ethernet. grafik, standard tangentbord, mus, FTP-server och en DOS-liknande kommandotolk. Plus en miljö för att köra Open Watcom program.

Hmmmm... Jag vet inte hur väl det stämmer, men jag har hört något om att man kan utnyttja L2-cachen som RAM. Jag vet inga detaljer, som huruvida den kan utnyttjas fullt ut som minne (inkl page tables etc) men om det går så kanske det går att använda RDOS utan externt RAM på en processor med någorlunda stor cache?

nitro2k01 skrev:rdos: Finns såsen grubload.bin (eller load.exe för den delen) att tillgå någonstans? Jag kan iofs diassemblera, men kod med kommenterarer och etikettnamn vore inte fel

Länk: http://rdos.net/vc/viewvc.cgi/trunk/ker ... iew=markup