Message board for the users of flat assembler.
> OS Construction > LBA32
as in AS400, LBA32 is a way to read and write meory devices with a single adress space.
see code below for more explanations:
!LBA32 is not LBA28 or LBA48!
;LBAread should use a 32 bits LBA32 adress to access all the memory present on the machine. ; ;the size of one block will be 256 bytes. ;a single sector from a drive will contain 2 LBA32 sectors ;a single 4K page will contain 16 LBA32 sectors ;a single RM segment will contain 256 LBA32 sectors ; ; the size of 256 bytes for LBA32 sector will simplify some way of adressing; ; as each secotr will be coverable by a single 8 bit offset ; and will let the use of more smaller drive fragments to hold files and data structures. ; with this design, the LBA adress space will cover up to 1TB of memory. ; ;the ram is located at LBA0 ;the first drive is located at the first empty megabyte boundary after the ram ;the seocnd drive follows the frist, as previouslly ;etc for all memory devices found on the system ; ;LBAread: dd f.LBAread,.fptr,LBA ;.fptr: dd segment:offset,size ; ; ;#the next step would be to provide a better way. ;# for example, lba2fptr and fptr2lba ;# a simple converter that will do great file managment. ;# one to read from ram ;# one to read from lba ;LBAmap: ; LBAvalue field size ; 0 RAM 256M ; +ramsize 1st drive 1.44M ; +drive size 2nd drive 40G ; etc... LBAread: .call=0 .fptr=4 .LBA=8 push eax ebx ecx edx edi esi ;save all registers push es ;segment for fptr accesses pop es pop esi edi edx ecx ebx eax ret
it is just this for a moment, an idea, but will soon exist.
|30 Oct 2010, 14:11||
Can you make it bigger? This is a severe restriction. Just one 2TB drive will kill the whole idea.
Perhaps you can consider 4kB sector size. This would match the CPU paging granularity. But would still limit you to 16TB. Okay for now, but in just a few years time may become a big problem with restricted addressing.
|30 Oct 2010, 14:24||
LBA32 for 32 bits CPU, and then, 32 bits systems.
in few years, 64 bits adressing will be the mainstream.
on 64 bits CPUs, it will be LBA64.
my cpu is 256 MB of ram (4G limit?)
my HDD is 40 GB ( LBA28 limit?)
then, it is suitable for old machines, where we are aware of the lmits (that will never grow).
it is not a problem for 2TB drives because i haven't one. just support what still exists.
|30 Oct 2010, 14:51||
What's wrong with variable size addressing?
|31 Oct 2010, 02:17||
LBA28 can go up to 128 GB (unless sector size is not 512 bytes, if can happen at all.)
|31 Oct 2010, 06:03||
i still know that.
then, today is a new day, last night, i've found THE solution:
all these 5 functions share the same parameter structure.
.fptr: ;handle to memory zone (seg:off,size) .offset: ;offset in the device (in lba, chs, bytes, ...) .path: ;device access reference (drive n°, path, memory zone,...) .size: ;size of the device or geometry (bytes, sectors,...)
then, it will be possible to do converters relativelly easy.
for example, Vdisk will be a function to write to a disk, but the disk wil be a file. access will be in sector size (512 bytes), geometry will be the size of the file in sectors, and path will be the name of the file.
the fifth function will be ram
it will read and write to ram, as if it was a drive.
operations to read and to write will be separated.
lba32 will use a map to localise the device that can be any of the 3 others items.
the first 4GB of lba32 will be covered with ram function.
the first 1.44MB just after 4GB mark will be a floppy drive image file, the first 1MB boundary after, it will be the disk function, for the secondary drive etc...
LBA32 will be many more complicated than the 4 other functions, it will have a map with each element pointing to a translator item, and then, one of the 4 items.
lba32 can reference a lba32 item too, but it have many chances to lead to strong bug if we access lba32map recursivelly.
that's all for the moment.
|31 Oct 2010, 12:38||
finally, i have a working layout about all these file/drive functions.
for the moment, only DOSfile, Vdisk and Disk exists.
Vdisk is a Disk that uses DOSfile to store the content. the reference to a Vdisk is not a bios number, but the pointer to path string.
an application that uses both in order to do transparent drive managment should set fields accordingly to the selected device.
i have tested to read to a disk image file, on usb and on hdd, it is ok.
able to write anywhere in the file, using a very cool LBA adress.
it needs DOSread and DOSwrite functions in order to read of write amount of memory referenced by fptr..
it also needs the file size, then, Vdiskid is provided to return the disk image size.
;use of a dos file as a hard drive vdisk: .call=0 .fptr=4 .lba=8 .path=12 .size=16 .read: push eax push dword[esi+.lba] shl dword[esi+.lba],9 mov eax,[esi+.fptr] mov eax,[eax+fptr.size] mov [esi+.size],eax call DOSread shr dword[esi+.size],9 pop dword[esi+.lba] pop eax ret .write: push eax push dword[esi+.lba] shl dword[esi+.lba],9 mov eax,[esi+.fptr] mov eax,[eax+fptr.size] mov [esi+.size],eax call DOSwrite shr dword[esi+.size],9 pop dword[esi+.lba] pop eax ret
the drive list popup covers 5 bios drives, and 3 virtual drives.
drives: Node .drv0,.drv1,.drv2,.drv3,.drv4,.drv5,.drv6,.drv7 .drv0: Diskid 0 .drv1: Diskid 80h .drv2: Diskid 81h .drv3: Diskid 82h .drv4: Diskid 83h .drv5: Vdiskid fd0 .drv6: Vdiskid usb0 .drv7: Vdiskid hd0 fd0: dd 0:@f,128 @@: db 'e:/fd0.bin',0 usb0: dd 0:@f,128 @@: db 'e:/usb0.bin',0 hd0: dd 0:@f,128 @@: db 'c:/fool/hd0.bin',0
and now, i can select a drive transparently in order to write sectors to it.
i've just tryed to create a floppy image file using bootwriter, and boot from it under bochs,
[FIXED] built an image with a working bootsector.
could not load font bitmap
it will do nothing.
now the image file is correctlly built, and boots from bochs...
the next step will be to test FOOL FILE SYSTEM on an image file instead of a disk. and be able to boot the image under bochs, to confirm a little the real drive capability.
|31 Oct 2010, 23:49||
one more idea to add to this project:
lba32 as a main file system.
each file system implemented on the general structure
filesystem: .call=0 ;fat32,ext2,etc... .fptr=4 ;location in ram .lba=8 ;disk or virtual disk, or file .path=12 ;asked or returned path .size=16 ; size or geometry or whatever structure needed to quantify the current item
then, just a root table that will contain consecutive zones in LBA32 for local use.
lba32list: .size=0 .list=4 .. dd @f-$-4 dd realmoderam ;1MB dd extendedram ;up to 4GB dd floppy ;floppy image, or direct to hardware item dd hdd0 ;direct to disk dd FAT12 ;file sytem on floppy dd FAT32 ;file system on harddisk dd EXT2 ; file system on harddisk ;etc... @@:
of course, every machine will have it's own map.
then, to find the file we want, it would be interresting to use paths or any other way to reference any item in the list.
lba32fs: dd LBA32,.fptr,?,.path,? ;all fields in ? are returned by the function .fptr dd ?:?,? ;segmented pointer in ram .path db "root/floppy1/lba=0" ; to access the boot sector from first floppy in the lba32 list.
and if the device doesn't exist, no problem, it just returns a null item.
now, i return to my journey
|09 Nov 2010, 19:29||
< Last Thread | Next Thread >
Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.