Blocks to kilobytes

[MIRKOSOFT]

Hi!

I have problem to transfer number of blocks to rounded kilobytes in assembler.

Here is code:

Code Select Expand


calculate blocks to kilobytes:

jsr bank // set bank to #15
lda blks // LO - blocks
ldx blks+1 // HI - blocks
sta 101
stx 100
ldx 144
sec
jsr $af0f // number of blocks to FAC1
jsr $8c38 // move FAC1 to FAC2
lda #$00 // value_
ldx #$01 // _256
sta 101
stx 100
ldx 144
sec
jsr $af0f // to FAC1
jsr $af21 // FAC1 × FAC2 - result in FAC1
jsr $8c38 // FAC1 to FAC2
lda #$00 // value_
ldx #$04 // _1024
sta 101
stx 100
ldx 144
sec
jsr $af0f // to FAC1
jsr $8b4c // FAC2 ÷ FAC1 - result in FAC1
jsr $af0c // FAC1 to #22/#23 or Acc.HI/Yreg.LO
ldy 22
lda 23
sty kib // save result
sta kib+1 // to memory
rts

always is result zero.

Can anybody help me?

Thank you everybody!

Miro

[Hydrophilic]

The problem is your call to $af0f.  You need to load .X with the value 144, but you are loading with address 144!!

So change every instance of

Code Select Expand

ldx 144
to

Code Select Expand

ldx #144

Problem solved!  BTW, a block normally contains 254 bytes of data, not 256.  Of course it is easy to divide by 256 in assembly, but since you are using floating-point anyway, it couldn't hurt to use 254.

Have fun!

[BigDumbDinosaur]

BTW, a block normally contains 254 bytes of data, not 256.  Of course it is easy to divide by 256 in assembly, but since you are using floating-point anyway, it couldn't hurt to use 254.

The two track and sector bytes that point to the next block allocated to the file effectively count as part of the file, as without them, the file would be unreadable after the first sector.  So converting blocks to KB is technically correct.  He would multiply blocks used -1 by 256, which can be readily performed with a bunch of arithmetic shifts.  Read the number of bytes in the last block and adding that to the blocks-to-bytes conversion should produce what he wants.

[Hydrophilic]

I must disagree.  Even though a block contains 256 bytes, only 254 of them store file data.  The other 2 bytes store meta data (track and sector pointers).

Use 256 if you want "size on disk" but use 254 if you want "data size".  I guess it really depends on what Mirkosoft wants to accomplish.  I'll let him decide, but thought it was important to distinguish between the two forms of measurement.

[BigDumbDinosaur]

I must disagree.  Even though a block contains 256 bytes, only 254 of them store file data.  The other 2 bytes store meta data (track and sector pointers).

Use 256 if you want "size on disk" but use 254 if you want "data size".  I guess it really depends on what Mirkosoft wants to accomplish.  I'll let him decide, but thought it was important to distinguish between the two forms of measurement.

In UNIX or Linux, a flat file consists of lines of ASCII text, with each line terminated by <LF> ($0A).  Although the user will normally never see the line terminators they are counted in the file size displayed in a directory listing.  ls -l on a file doesn't display the character count, only the bytes consumed by the file as a whole.  As the forward pointers in a CBM random block file (PRG, SEQ, USR) are part of a file and are essential to the file's usability, they are part of the aggregate file size, the "size on disk," which is what a directory listing should display.