How to get a disk based image?

Ecernosoft · December 23, 2022

So, I'm in sort of a pickle. I'm going to need more than 16K for my game, and I don't want to deal with bank-switching. My plan is to code it for the 8bit, release the 8bit version, then port it to the 5200.

So, I want a 32K disk image. How can I do that?

In fact, I might even sacrifice loadless gameplay for more content/better graphics (Loading backgound graphics straight into the $3C00-$3FFF area instead, and having each zone's level data (3K max) load into the $3000-$3BFF area. (Or I might just not even need to do it before the $4000 region and load it in the $B000-$BFFF area, leaving all code in the $4000-$AFFF area.) although I may need the OS to do that, and I'm trying to stay away from the OS as much as possible, as this is what DMA looks like for me:

; That's a lot!!!

So, any ideas on how to get a disk based image? (And how fast is the Atari disk drive anyway?)

Thanks!

Thelen · December 23, 2022

If you're using Altirra you can mount a folder as a disk like here:

The following directory will be a .atr to be loaded with Altirra:

The autorun.sys file is the compiled code from Mads assembler (which is being put there and renamed by a .bat file). Dos will automaticly run 'autorun.sys'.

The raw files are the datafiles to be loaded later by the game.

Here is the code snippet which can be used as base, I made/adapt it to load data to the VBXE card directly from disk. Sorry, it's messy, no time to clean it...

;***********************************************************
;copy data from disk to VBXE memmory
;***********************************************************
;takes:

;a=128+..start in which bank?
;x=128+..last bank to fill
;ztmp1 = low byte pointer filename
;ztmp2 = high byte pointer filename


load_diskdata_to_VBXE_bank
               stx     tmp2    ;=last bank to fill (128+x)
               sta	TMP1	;save the starting bank



; *****************************
; First, close and open IOCB2
; *****************************
LOTRCK  LDX #$20      ;for IOCB2
        LDA #12       ;close command
        STA ICCOM,X   ; into ICCOM
        JSR CIOV      ;do the CLOSE

        LDX #$20      ;IOCB2 again



        LDA #3        ;open file
        STA ICCOM,X   ; is the command

      

        LDA ztmp1             ;low byte of start of the filename <<<<<<<<<<<<<<<<<-------------------------
        STA ICBAL,X   
        LDA ztmp2             ;high byte of start of the filename <<<<<<<<<<<<<<<<<<<---------------------------
        STA ICBAH,X


               LDA #4        ;INPUT
               STA ICAX1,X   ; open for INPUT

	lda	#0
	sta	icax2,x

        LDA #0
        STA ICBLH,X   ;high byte length
        LDA #20
        STA ICBLL,X   ;>low byte length
        JSR CIOV      ;do the OPEN






load_next_bank

        lda     tmp1
        vbsta   VBXE_MA_BSEL



; *****************************
; load 1K data 
; *****************************
        LDX #$20      ;by using IOCB2
        LDA #7        ;get character
        STA ICCOM,X   ; command

;Data is directly stored in the VBXE threw the MEMAC at $9000-9FFFF
        LDA #$00  ;start-address WHERE the data will be stored low Byte
        STA ICBAL,X   ; low byte
        LDA #$90  ;start-address WHERE the data will be stored High Byte
        STA ICBAH,X   ; high byte

;
        LDA #$00        ;length of data to read low byte<<<<<<<<<<<<<<<<<<<<<<<<<<------------------------
        STA ICBLL,X   ; low byte
        LDA #$10     ;>length of data to read high byte <<<<<<<<<<<<<<<<<<<<------------------------------
        STA ICBLH,X   ; high byte
        JSR CIOV      ;put out the line

        ldy     tmp1
        CPy     tmp2    ;Is y thesame as the last bank to load?
        beq     end_disk_bank_loading
        iny
        sty     tmp1
        jmp     load_next_bank



end_disk_bank_loading
        rts

Filename to point to example:

;Filenames of BITMAP data to load to VBXE in sub 'Initial_game_setup
;the filename of the file must be in Capitals!!!!!!!!!!!!!!!!!!!
tile_filename
        DTA	C'D1:TILES.RAW'		;tiles bmpdata level 1 NAME
    	DTA	$9B            ;atascii end of line (return) character

It took me almost a day to get proper disk loading to work, maybe this can save some time for you. Where a marked with a <<<<<<--------- you can put your own pointer and by the next the filelength you want load.

Edited December 23, 2022 by Thelen

+CharlieChaplin · December 23, 2022

Standard sizes for A8 (boot) disk images are 90k, 130k, 180k, 360k, 720k, etc.

If you only need 32k or less, better create a COM/XEX file (so-called executable file).

xxl · December 23, 2022

From what you write, it is not possible to create such a disk image in a standard way. you have at least 2 obstacles: 1. file system (32KB image can't be handled by DOS2 without modifications (disk directory is beyond the 32KB range), you can try SpartaDOS but filesystem support will be troublesome here).
2. operating system - you write that you do not want to work with it - DOS requires an enabled Operating System.

I would solve it this way:
created a standard disk image, recorded the necessary files on it and based communication on xBIOS which allows you to refer to files by names or sector numbers - if we cut the disk image to 32KB, it will still work (we will not need directory sectors). This method also has the advantage of being faster - it is used by the Prince of Persia game for Atari.
transferring the game prepared in this way to the 5200 should not be a problem anymore - just replace the I/O procedure in xB with reading from CAR (trivial). What's more - I would record the parts of the memory that you will be loading in the binary file format (where the loading location and the length of the file are defined) to shorten the program even more - the effect would be as follows:
data loading:

lda > sector file 1
ldy < sector file 1
jsr xBIOS_READ_SECTOR ; set (we cut off disk directory)
jsr xBIOS_LOAD_BINARY_FILE ; load

and that's it 🙂

+DjayBee · December 23, 2022

If 32634 bytes (32k-128-6) is enough, you can create a boot disk directly from your code.

The boot header is six bytes:

$00

1 byte - number of sectors to boot (max. $FF)

2 bytes - load address

2 bytes - run address

After booting, the OS jumps to the beginning of your code (load address + 6).

If this returns via RTS, it will jump to "run address".

There is no need to interact with the OS in any way.

Edited December 23, 2022 by DjayBee

Zolaerla · December 23, 2022

Since nobody's answered your last question, expect disk loading to be 1-1.5KB per second with the built-in OS, or up to ~10KB per second with the HISIO patch and an SIO2PC or equivalent connection while on a simple loading screen (too complex will cause framing issues at full speed).

If it's going to fit in a XEX, that's the method I recommend (32KB as suggested above). If you don't have a tool to make your own, and you're not using an assembler that creates them, the file format is described here: https://www.atarimax.com/jindroush.atari.org/afmtexe.html

If you are planning on booting directly from the disk like a lot of software did that has nothing to do with DOS, and you want to avoid the blue screen with the booping while loading, I suggest making a tiny boot sector that will put something up on the screen (or just black it out and silence the boops to load a stage 1 loader with a title screen, then load the full game in). The latter is what I tend to do with a 1 sector "make the screen black and make the sounds go away" boot sector to then load a title screen which then loads the actual game. This can all be done with binary data accessing specific sectors on the disk to load. A little bit of work to set up, but not too bad.

dmsc · December 24, 2022

Hi!

4 hours ago, Ecernosoft said:

So, I'm in sort of a pickle. I'm going to need more than 16K for my game, and I don't want to deal with bank-switching. My plan is to code it for the 8bit, release the 8bit version, then port it to the 5200.

So, I want a 32K disk image. How can I do that?

You don't want a 32k disk image, as there are no actual "physical" 32k disks. You should use standard disk sizes, 90k (720 sectors of 128 bytes) is the most common, and compatible with any Atari 8-bit disk drive.

After you decide the disk size, you decide how the data is organized in the disk:

- Raw data, in sectors: you have to read data from specific sectors using SIO calls.

- DOS disk, the data is organized by a DOS, using a standard format. Here, you read files (normally by name), of arbitrary size.

Then, if you decide on the second, you have multiple DOS to select from 🙂

Have Fun!

Ecernosoft · December 24, 2022

3 hours ago, dmsc said:

Hi!

You don't want a 32k disk image, as there are no actual "physical" 32k disks. You should use standard disk sizes, 90k (720 sectors of 128 bytes) is the most common, and compatible with any Atari 8-bit disk drive.

After you decide the disk size, you decide how the data is organized in the disk:

- Raw data, in sectors: you have to read data from specific sectors using SIO calls.

- DOS disk, the data is organized by a DOS, using a standard format. Here, you read files (normally by name), of arbitrary size.

Then, if you decide on the second, you have multiple DOS to select from 🙂

Have Fun!

so it's not that easy.......... what a shame.......

How about bank-switched cartridges to load into memory instead? (Ex. A 32K cartridge format)

+DjayBee · December 24, 2022

7 hours ago, Ecernosoft said:

so it's not that easy.......... what a shame.......

Do you use MADS as assembler?

If so, I can supply a code snippet which assembles directly into a valid and complete ATR disk image.

xxl · December 24, 2022

2 hours ago, DjayBee said:

If so, I can supply a code snippet which assembles directly into a valid and complete ATR disk image.

Great idea. Could you please post an example on the forum?

Ecernosoft · December 24, 2022

16 hours ago, DjayBee said:

Do you use MADS as assembler?

If so, I can supply a code snippet which assembles directly into a valid and complete ATR disk image.

I use DASM. (Reminder: I am using 8bitworkshop here. It's a very useful website for people like me who don't want to bother with CLI.)

But still post it! I convert incompatible programs to DASM whenever I need to.

If you could convert it to DASM for me though, that would be AWESOME, thanks!

Edited December 24, 2022 by Ecernosoft

Ecernosoft · December 24, 2022

13 hours ago, xxl said:

Great idea. Could you please post an example on the forum?

Yes!
Please do.

Despite me not using MADS, I can try and convert it to DASM. (It's my preferred assembler even when I don't use 8bitworkshop. )

Ecernosoft · December 24, 2022

On 12/23/2022 at 2:29 PM, DjayBee said:

If 32634 bytes (32k-128-6) is enough, you can create a boot disk directly from your code.

The boot header is six bytes:

$00

1 byte - number of sectors to boot (max. $FF)

2 bytes - load address

2 bytes - run address

After booting, the OS jumps to the beginning of your code (load address + 6).

If this returns via RTS, it will jump to "run address".

There is no need to interact with the OS in any way.

Oh, I probably won't need the full 32K.........

But I might.

Where do I put this header?

Edit: If I were creating a 48K game for an 800xl, would this still work?

Also, why the -128?

Edit 2: Wait..... it works....??? (I'm starting the code at $4000. It will go from $4000-$BFFF.)

Edit 3: What extention would this be? (It works on MAME, but MAME works with everything I throw at it no matter the extention. ALTIRRA is my preferred emulator due to accuracy and it does care about the extentions. Please let me know when you have time @DjayBee!

Edited December 24, 2022 by Ecernosoft

Zolaerla · December 24, 2022

1 hour ago, Ecernosoft said:

Oh, I probably won't need the full 32K.........

But I might.

Where do I put this header?

Edit: If I were creating a 48K game for an 800xl, would this still work?

Also, why the -128?

Edit 2: Wait..... it works....??? (I'm starting the code at $4000. It will go from $4000-$BFFF.)

Edit 3: What extention would this be? (It works on MAME, but MAME works with everything I throw at it no matter the extention. ALTIRRA is my preferred emulator due to accuracy and it does care about the extentions. Please let me know when you have time @DjayBee!

He's talking about a boot disk. You would create a .ATR file (which has a 16-byte header first) and have the very first 6 bytes of data be that header. I believe as raw binary on a disk, you can use the .XFD format. The -128 is because you can only tell the Atari OS up to 255 sectors to load (the -6 is for the 6 byte header). If you want more than that number of bytes, you'd have to use loading routines to get the additional sectors.

Here's what loading a number of sectors from the Atari OS looks like (you have to know where you want to load it (LoadAddress, 16-bit), the start sector (StartSector, 16-bit), and the number of sectors @ 128 bytes each (NumSector, 8-bit):

  ; Set load address
  LDA <LoadAddress
  STA DBUF
  LDA >LoadAddress
  STA DBUF + 1

  ; Set start sector
  LDA #<StartSector
  STA DAUX
  LDA #>StartSector
  STA DAUX

  ; Use A for number of sectors
  LDA #NumSector

LoadDiskData:
  ; Preserve A
  PHA

  ; Load a sector and wait for it to finish
:
  JSR DSKINV
  BMI :-

  ; Move up the address to load the next sector
  CLC
  LDA DBUF
  ADC #128
  BCC :+
  INC DBUF+1
:

  ; Increment the sector to load
  INC DAUX
  BNE :+
  INC DAUX+1
:

  ; Repeat if there are any sectors remaining
  PLA
  SEC
  SBC #1
  BNE LoadDiskData

Further note, because someone's probably going to comment: I do not set device or the SIO command in this as those are not necessary when booting. This is from my boot disk code. However, they would also have to get set if used in general code instead of when booting.

Edited December 24, 2022 by Zolaerla
fixed typos, because of course I missed 'em before posting. =/

Ecernosoft · December 25, 2022

4 hours ago, Zolaerla said:
He's talking about a boot disk. You would create a .ATR file (which has a 16-byte header first) and have the very first 6 bytes of data be that header. I believe as raw binary on a disk, you can use the .XFD format. The -128 is because you can only tell the Atari OS up to 255 sectors to load (the -6 is for the 6 byte header). If you want more than that number of bytes, you'd have to use loading routines to get the additional sectors.

Here's what loading a number of sectors from the Atari OS looks like (you have to know where you want to load it (LoadAddress, 16-bit), the start sector (StartSector, 16-bit), and the number of sectors @ 128 bytes each (NumSector, 8-bit):
  ; Set load address
  LDA <LoadAddress
  STA DBUF
  LDA >LoadAddress
  STA DBUF + 1

  ; Set start sector
  LDA #<StartSector
  STA DAUX
  LDA #>StartSector
  STA DAUX

  ; Use A for number of sectors
  LDA #NumSector

LoadDiskData:
  ; Preserve A
  PHA

  ; Load a sector and wait for it to finish
:
  JSR DSKINV
  BMI :-

  ; Move up the address to load the next sector
  CLC
  LDA DBUF
  ADC #128
  BCC :+
  INC DBUF+1
:

  ; Increment the sector to load
  INC DAUX
  BNE :+
  INC DAUX+1
:

  ; Repeat if there are any sectors remaining
  PLA
  SEC
  SBC #1
  BNE LoadDiskData
Further note, because someone's probably going to comment: I do not set device or the SIO command in this as those are not necessary when booting. This is from my boot disk code. However, they would also have to get set if used in general code instead of when booting.

Question:

What do I put for the 16 byte header? What does each byte do, and what values do what things?

Thanks!

Zolaerla · December 25, 2022

ATR Header is:
0: Signature: $96
1: Signature: $02
2: Low 8-bits of size in paragraphs*
3: Middle 8-bits of size in paragraphs*
4: Low # of bytes per sector
5: High # of bytes per sector
6: High 8-bits of size in paragraphs
7: 9 0s

* The size of an ATR is in 16-byte groups called paragraphs as a 24-bit value. So for 32KB, you would divide 32,768 by 16 for 2,048, which is $000800.

You want to use 128 bytes per sector, so for our theoretical 32KB ATR file, your header would be:

$96, $02, $00, $08, $80, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00

When accessing sectors, the sectors are 1-based, so the very beginning of the disk is sector 1.

Also, realize that most ATR generators pad out a 128-byte sector SD disk to the standard Atari size of 720 sectors or 92,160 bytes instead of what we're using above. This might be a better target size to use since it would translate to a real disk easier, if that matters to you at all.

Edited December 25, 2022 by Zolaerla

Ecernosoft · December 25, 2022

3 hours ago, Zolaerla said:

ATR Header is:
0: Signature: $96
1: Signature: $02
2: Low 8-bits of size in paragraphs*
3: Middle 8-bits of size in paragraphs*
4: Low # of bytes per sector
5: High # of bytes per sector
6: High 8-bits of size in paragraphs
7: 9 0s

* The size of an ATR is in 16-byte groups called paragraphs as a 24-bit value. So for 32KB, you would divide 32768 by 16 for 2048, which is $000800.

You want to use 128 bytes per sector, so for our theoretical 32KB ATR file, your header would be:

$96, $02, $00, $08, $80, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00

So, where would I put this?
I'm guessing at the first ORG right? (The start of the code)

(In this case, the start of my code is $4000.)

Zolaerla · December 25, 2022

Just now, Ecernosoft said:

So, where would I put this?
I'm guessing at the first ORG right? (The start of the code)

(In this case, the start of my code is $4000.)

I don't know your assembler, but for CA65 which is what I use, I would create the binary directly (assuming Game.bin), and then just have a tiny ASM file that gets assembled to the final .ATR file like:

.ORG $1000 ; This doesn't matter at all
.BYTE $96, $02, $00, $08, $80, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00
.INCBIN "Game.bin"

When I make my own disks, I wrote a PHP script that puts every binary file at exact sectors, since I'm working with complex multi-disk stuff and want to know where everything is. If your game gets much more complex, there is this sort of utility available if you are aiming for binary (self-executing). The disk format is a bit different if you want to be DOS-compatible, and that is more complex than some simple assembly since you need a file table and each file has indexing added to it and the like. I think DIR2ATR is the name of a popular tool for that.

Ecernosoft · December 25, 2022

4 hours ago, Zolaerla said:
I don't know your assembler, but for CA65 which is what I use, I would create the binary directly (assuming Game.bin), and then just have a tiny ASM file that gets assembled to the final .ATR file like:
.ORG $1000 ; This doesn't matter at all
.BYTE $96, $02, $00, $08, $80, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00
.INCBIN "Game.bin"
When I make my own disks, I wrote a PHP script that puts every binary file at exact sectors, since I'm working with complex multi-disk stuff and want to know where everything is. If your game gets much more complex, there is this sort of utility available if you are aiming for binary (self-executing). The disk format is a bit different if you want to be DOS-compatible, and that is more complex than some simple assembly since you need a file table and each file has indexing added to it and the like. I think DIR2ATR is the name of a popular tool for that.

So it doesn't matter where I put it? (Ex. I can put mine at $4000?)

Again, I'm using DASM here. And since I'm going to make a 5200 port, I'm going to need bytes free (Just a few, like ~64) to do the 5200 joystick to 2600 joystick (Note: 2600 and 8bit machines feature the same joystick. Comeon Atari, use those paddle inputs for buttons like the 7800 did!)

P.S. Yes, that code would work for my assembler.

Edited December 25, 2022 by Ecernosoft

Zolaerla · December 25, 2022

10 minutes ago, Ecernosoft said:

So it doesn't matter where I put it? (Ex. I can put mine at $4000?)

As long as you include the 6-byte boot header DjayBee mentioned with your binary data. To repeat what he said, assuming you're doing 32,634 bytes (the max allowed in a boot sector), you'll start your binary with:
.BYTE $00 ; Unused OS flags
.BYTE $FF ; The number of sectors to boot. 255 gives you up to 32,364 bytes, but it's going to take a long time to load!
.ADDR $3FFA ; The address to load everything at. $3FFA is $4000 - 6, so the 6-byte header will still be there, but not interfere with where it loads
.ADDR $4000 ; Where execution begins, assuming you want to start running at $4000
[* your binary goes here *]

It vaguely matters where you put it, since you don't want to override the OS data, stack, or overlap with ROM which won't work correctly. $0700 to $BFFF are available with just the Atari OS installed and no cartridge/BASIC/DOS included. I've seen some things say $0600 is the minimum, but I just use $0700 since I think the later OS versions use a bit more RAM.

Edited December 25, 2022 by Zolaerla
Changed a - to a . so it doesn't look like a subtraction

Ecernosoft · December 25, 2022

3 hours ago, Zolaerla said:

As long as you include the 6-byte boot header DjayBee mentioned with your binary data. To repeat what he said, assuming you're doing 32,634 bytes (the max allowed in a boot sector), you'll start your binary with:
.BYTE $00 ; Unused OS flags
.BYTE $FF ; The number of sectors to boot - 255 gives you up to 32,364 bytes, but it's going to take a long time to load!
.ADDR $3FFA ; The address to load everything at. $3FFA is $4000 - 6, so the 6-byte header will still be there, but not interfere with where it loads
.ADDR $4000 ; Where execution begins, assuming you want to start running at $4000
[* your binary goes here *]

It vaguely matters where you put it, since you don't want to override the OS data, stack, or overlap with ROM which won't work correctly. $0700 to $BFFF are available with just the Atari OS installed and no cartridge/BASIC/DOS included. I've seen some things say $0600 is the minimum, but I just use $0700 since I think the later OS versions use a bit more RAM.

Thanks!

(Odd, when I run it in Altirra, having the header at $3FFA and code starting at $4000, it doesn't work. Of course, I did change the extention to a .atr file since my assembler defaults to .bin files.)

I'm sorry that I'm asking a ton, it's the first time I've done anything like this. Also, Merry christmas!

Edited December 25, 2022 by Ecernosoft

Zolaerla · December 25, 2022

1 hour ago, Ecernosoft said:

Thanks!

(Odd, when I run it in Altirra, having the header at $3FFA and code starting at $4000, it doesn't work. Of course, I did change the extention to a .atr file since my assembler defaults to .bin files.)

I'm sorry that I'm asking a ton, it's the first time I've done anything like this. Also, Merry christmas!

Hmm... can you link the .atr and your game's binary? I can take a look at what's going on. Kinda hard to tell what's up otherwise. It might just need to be 0-padded to the full size or something. If you don't want it to be "out" yet, I can see if I can make a simple one in DASM, since it looks pretty similar looking at its docs.

Zolaerla · December 25, 2022

6 hours ago, Ecernosoft said:

Thanks!

(Odd, when I run it in Altirra, having the header at $3FFA and code starting at $4000, it doesn't work. Of course, I did change the extention to a .atr file since my assembler defaults to .bin files.)

I'm sorry that I'm asking a ton, it's the first time I've done anything like this. Also, Merry christmas!

Wow, DASM is an aggravating assembler if you don't know it. Requiring spaces for its directives drove me batty.

In any case, here is a tiny .asm file to create a .ATR with an up to 32KB .bin file that pads it as needed. This is done by fudging it being a binary moved $10 (16) bytes before the OS header. Tested in the latest DASM (v2.20.14.1):

	.PROCESSOR 6502
	.ORG $3FEA

	; ATR Header (sets a 32KB file)
	.BYTE $96, $02, $00, $08, $80, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00

	; OS Boot Header
	.BYTE $00
	.BYTE $FF
	.WORD $3FFA
	.WORD $4000

	.INCBIN "Game.bin"
	IF * < $BFFA
	  .DS $BFFA - *
	ENDIF

The command line I used to create it was:
dasm SimpleDisk.asm -f3 -v5 -oDisk.atr

It created an ATR disk that loads just fine in Altirra.

Edited December 25, 2022 by Zolaerla

+DjayBee · December 25, 2022

12 hours ago, Zolaerla said:

Also, realize that most ATR generators pad out a 128-byte sector SD disk to the standard Atari size of 720 sectors or 92,160 bytes instead of what we're using above. This might be a better target size to use since it would translate to a real disk easier, if that matters to you at all.

Please always do this.

There is software which hickups massively with non-standard sized or truncated ATRs.

Ecernosoft · December 25, 2022

11 hours ago, Zolaerla said:
Wow, DASM is an aggravating assembler if you don't know it. Requiring spaces for its directives drove me batty.

In any case, here is a tiny .asm file to create a .ATR with an up to 32KB .bin file that pads it as needed. This is done by fudging it being a binary moved $10 (16) bytes before the OS header. Tested in the latest DASM (v2.20.14.1):
	.PROCESSOR 6502
	.ORG $3FEA

	; ATR Header (sets a 32KB file)
	.BYTE $96, $02, $00, $08, $80, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00

	; OS Boot Header
	.BYTE $00
	.BYTE $FF
	.WORD $3FFA
	.WORD $4000

	.INCBIN "Game.bin"
	IF * < $BFFA
	  .DS $BFFA - *
	ENDIF
The command line I used to create it was:
dasm SimpleDisk.asm -f3 -v5 -oDisk.atr

It created an ATR disk that loads just fine in Altirra.

THANK. YOU.

P.S. Merry christmas!

How to get a disk based image?

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members