Jump to content
IGNORED

Atari v Commodore


stevelanc

Recommended Posts

I'm all for commodore but have to correct you :)

In every line where you use sprites VIC has to read pointer and sprite data...

So you lose 2 cycles for each sprite and 2 or 3 cycles because only instructions that perform write are possible in those last two or 3 cycles before sprite fetching begins...

So you end up losing 14+(2 or 3) cycles, roughly 15 * 200 lines = 3000 cycles...

It's not without cost :)

 

And as I know one line is 63 cycles long on PAL system ?

25 badlines = 25 * 21 (23 cpu cycles remaining per BL)..

175 normal lines = 175 * 63

112 blanked lines = 112 * 63

So we get 18606 cycles per frame..

 

But still easier to set up than ataris horizontal multiplexing of players, and with more colors and resolution...

Of course you're right.. That'll teach me to be thinking in NTSC land before writing that.. Don't notice I'd mixed PAL (63) with NTSC (65) there...

Oops.. :ponder:

 

And yes, I'm guilty of forgetting to take the multiplexed sprite cost into the frame when saying it's almost no cpu cost..

Oops ;)

Link to comment
Share on other sites

Here is timing for mode 5:

 

post-14652-1246216559_thumb.png

 

I = Instruction,M = Missile,P = Player,A = Address,R = Refresh

C = Character Data,G = Graphics Data,V = Virtual Read

 

In 'bad line' there is no free cycles in the visible part of line :(

Does it mean it is not possible to do player multiplexing ?

 

If that's the case, then only option would be bitmap mode... As Rybeg said we get more cycles, and more important.. there are no 'bad lines' ...

It looks like this:

 

post-14652-1246219018_thumb.png

 

Marked blue region is where second quad sized player would go...

If we would want to multiplex one player from first position on second (If I understood Atariksi correctly) there are 4 cycles available for that .....

Is it possible ?

I guess you need to change x coordinate of player ?

That is location D000-D003... as I know fastest way is STA $D000 for example ? That is 4 cycles....

What about changing player data ? That needs to be changed too....

 

Is it better if we use more players ?

 

Can someone explain that - horizontal player multiplexing and its limits....

Link to comment
Share on other sites

Something completely different ;)

 

What about trying to adapt "MOOD" to the A8?

It's a good candidate for either gr. 9, gr. 10 and gr. 11.

 

Okay Emkay, how about showing us something that's actually viable and can work instead of spouting repeated 'theoretical' ideas.. Really this whole thread comes down to 'in theory' the A8 is better, but we can't in practic prove it..

Your move sunshine.....

edit: I'm a bit tipsy and maybe regreting what i said..

Edited by andym00
Link to comment
Share on other sites

Something completely different ;)

 

What about trying to adapt "MOOD" to the A8?

It's a good candidate for either gr. 9, gr. 10 and gr. 11.

 

Okay Emkay, how about showing us something that's actually viable and can work instead of spouting repeated 'theoretical' ideas.. Really this whole thread comes down to 'in theory' the A8 is better, but we can't in practic prove it..

Your move sunshine.....

edit: I'm a bit tipsy and maybe regreting what i said..

 

My move? For what? Going back to the 70's and study programming on computers?

Sorry, in my real life I had nothing to do with development on computers, so I have no real experience with coding there.

My passion in coding on the A8 only reached something like this:

 

admirandus.png

 

Let it analyse a bit ;)

 

On the screen you see 3 different screenmodes side a side

You also see "Hires" coloured words

And the sounds are based on sawtooth waves. Done "before" 1990.

 

My writings are not to tell "hey the Atari is better than the C64" . We know the weak and power spots of both machines. On the C64 , all doable development on the hardware is done. And people now use the gotten experience to produce "real" software since decades.

 

On the A8... well... I'm not sure, but without real coding experience on my side, I have created many other software like this, back in the 80s (sadly, most is gone) ...

And, assuming that it was relatively easy for me to do this in my spare time, what could a real experienced coder have done, if he had seen "the light of richness" as they did on the C64?

Link to comment
Share on other sites

I can code it but here's a start for you. BASIC program for 23 colors/scanline with moving object-- use the joystick to move the object (this is slow but it's in BASIC):

 

10 PRINT "Atari BASIC program to show 23 colors/scanline in Graphics 15"

.

.

.

390 RETURN

RUN

Thanks for an example!

But do I have to type it in or is there a way to copy paste ? :)

 

You can copy/paste if you have uploader on PC -> Atari set up w/CR conversion.

You can then do: ENTER "C:" as one option if doing cassette simulation; that will read in a text file.

Link to comment
Share on other sites

btw. Why when C64 users shows real pictures, Atari users: only famous listing "23 colors per scanline" ;) or fake pictures. We strongly need gfx conventer to show Atari real power. Conventer with computer placed sprites, computer dli, computer rasters. G2f is nice but everything is manual, sometimes very unfriendly, very hard like rasters.

Sorry, but this still misses the point.

 

It is all well and good using a PC or MAC's power to analyze a picture and produce the most optimal implementation of this on the A8 but that same program doesn't know which areas are (or will be) software/hardware sprites in an actual port/conversion of the game and mostly, when this is taken into consideration, you'll find that the game engine required to support it all will impact greatly on the special display code produced by the gfx converter you describe.

 

Perhaps an engine such as this shows promise... Two Moons and One Sun?

 

I don't agree with you. :P

First: In some games like adventures, rpg, others static screens games (like Elvira - see at bottom) , this converter would be very useful. And also to show what atari can do in gfx. C64 user in 30 seconds can convert any picture. On Atari this takes days and will never be like from convert-program. Easy to write: "look Atari can 23 colors in scanline..." and show only listing or "But the tree is red, not brown, while on the A8 were more colours possible" and show fake image (with in fact RGB colors - not Atari colors and 1x1 pixels btw. For me always red tree is better then NOTHING :) ) - but really hard to prove this and show truly great image. Computers invents to relieve us from very complex work. On AtariGfx there is no more complicated things then correct placed sprites, priorites, rasters (look in g2f - this is paint tool or assembly code ?)

 

Second: Imagine this: there is engine which allows you to place sprites on screen - in realtime on 8bit Atari. And this engine is very fast because it is only add-on to zx spectrum emulator and this emulator takes the most cpu time.

Look here: http://tiny.pl/36v2 (original in polish, translated via google)

When you looked on pictures maybe you think - not good - but this engine has a big potential. I ask author, great Atari Coder ;) - Mono - about PC version, he answer: Can be done and without Atari cpu limits, on PC can be check every possible sprites, colors combination, and other resolutions like 2x1 pixel - and in effect more accurate conversion.

 

Third: G2Font is very good gfx program but i know much better like Grafx2 or Cosmigo Pro Motion. Of course in this programs you can't save files in Atari formats - but when we have a converter, then we can paint in any program, final picture convert to *.g2f file and retouch and correct minor conversion errors. Overall, much easier way to produce pictures to games, demos instead fake pictures or famous "23 colors listing". Much easier way to show C64 user why Atari is better in gfx. :D

 

------

- sorry for my poor english.

- i am Atari user since 1986 and never bought C64

- others C64 30 seconds conversion:

elvira.png

 

utopia.png

 

Interesting point, BUT there is nothing stopping the C64 remake of such classic adventure games as The Pawn and The Guild of Thieves on the C64 using trick screenmodes likes MCI IFLI HIFLI etc etc. In which case the graphics would look pretty much identical to the ST/Amiga graphics given you only need a few extra hues of a few colours for that 16 colour artwork :)

 

You may need to zoom in on those pictures to see if they are dithered as many C64 artwork is given restricted palette. I doubt they will look identical to ST/Amiga graphics once you stop dithering (which costs you resolution). IFLI/HIFLI within a game is much more restricted since you lose your sprite channels and distort part of the display as well and use up almost all CPU time.

Link to comment
Share on other sites

...

It does NOTHING of value, we all KNOW the A8 has a great palette and the C64 a limited one, so what?

...

I think this was also related to color depth not just palette. Having 16 colors and being able to show them all isn't that wonderful as having say 12 colors and being able to select them from 256. For general imagery, the probability that a scanline uses all 16 colors available to C64 is close to ZERO. But the probability that it uses 16 from 256 is high given shades most likely will show up (unless they are hand painted by C64 artists).

 

>This thread, like all the others where people (and I don't need to name names) attempt to belittle the C64 and it's excellent software library and rely ENTIRELY on shouting loudly, quoting random hardware performance values and NEVER SHOW anything (or in the case of SID bashing let me hear anything) that PROVES their random and ill founded opinions...

 

The thread has more to do with comparing hardware capability than belittling C64's software library. It does not rely ENTIRELY on shouting loudly nor random hardware performances. It's not based on ill founded opinions. You generalizing over the entire thread is your ill founded opinion. You're just slinging mud at something you haven't fully read/understood. You can't relate number of software titles available to hardware being superior.

 

And yet we still get games like Popeye when he remains PINK after eating his spinach despite the Atari having 255 more colours to choose from ;) The problem is realistically the Atari can't display more than 5 or so colours in a game with 50fps action and at a resolution of 160x200. The simple fact is for most games the C64 has an excellent selection of 16 colours to choose from. The only time you get an advantage is doing things like depth cueing or graduated skies like in say Elektraglide. On that kind of horizontal raster/Displaylist/Copperlist type effect the Atari does win because you can use the extra colours there, but in your average game say something like Bubble Bobble the Atari is backed into a corner as it just can't do any unique 16 colours everywhere on screen to replicate the look of the C64 version.

...

You also are restricted to 4*8 areas. Atari has a different approach so obviously porting from one to the other leads to some problems. It's easy to get 23 colors/scanline and Atari limit is definitely not 5 colors/scanline at 160*200. Earlier games were planned for 5 colors-- low memory useage or were easier to port using char-mode or linear graphics mode. And 23 colors/scanline can be done even in BASIC-- you don't need any DLIs or kernels which can actually get you more colors per scanline.

 

By the way, Popeye does change color after he eats spinach on my Atari (800XL NTSC).

 

>As I said BOTH machines were a compromise, Jay Miner fixed most of them in 1982/83 once the Amiga chipset prototypes were finished (although the sprite features were weak, a typical bugbear of Jay's work, at least he put in a really nice blitter solution) from the Atari A8.

 

But they are taller on both systems-- makes it easier to multiplex vertically.

 

Maybe so but they are very narrow AND a bit colourless as well as limited in number (8...same as the C64!) when older machines like the TI and Sord M5 had 32 sprites on screen anywhere, the Amiga sprite system is very weak, they put all their eggs into the 'blitter basket' as far as I can tell. Think of the sprites as a bonus not a feature of the Amiga...good for a mouse cursor ;)

 

(I am joking, it's a bit better than the Archimedes one single hardware sprite which IS the mouse cursor)

 

You know I agree horizontally both Atari and Amiga have lesser sprite coverage, but some games are planned to use the advantage of the taller sprites (like River Raid). Similarly, you can target the machines strengths like hardware scrolling and mixing modes which would end up costing you a lot more cycles when porting to C64. Just like when you take horizontally wider sprites and try to port on Atari/Amiga, it costs the latter machines more cycles of CPU time by replicating horizontally or substituting with software versions. Amiga can also replicate sprites horizontally using it's similar GRAFn registers.

Link to comment
Share on other sites

Something completely different ;)

 

What about trying to adapt "MOOD" to the A8?

It's a good candidate for either gr. 9, gr. 10 and gr. 11.

 

Okay Emkay, how about showing us something that's actually viable and can work instead of spouting repeated 'theoretical' ideas.. Really this whole thread comes down to 'in theory' the A8 is better, but we can't in practic prove it..

Your move sunshine.....

edit: I'm a bit tipsy and maybe regreting what i said..

 

Sorry, but you also made a mistake of generalizing over the whole thread without refuting the points presented in the thread; many points that are strengths of Atari did come with examples/postings of working state not just theory.

Link to comment
Share on other sites

Here is timing for mode 5:

 

post-14652-1246216559_thumb.png

 

I = Instruction,M = Missile,P = Player,A = Address,R = Refresh

C = Character Data,G = Graphics Data,V = Virtual Read

 

In 'bad line' there is no free cycles in the visible part of line :(

Does it mean it is not possible to do player multiplexing ?

 

If that's the case, then only option would be bitmap mode... As Rybeg said we get more cycles, and more important.. there are no 'bad lines' ...

It looks like this:

 

post-14652-1246219018_thumb.png

 

Marked blue region is where second quad sized player would go...

If we would want to multiplex one player from first position on second (If I understood Atariksi correctly) there are 4 cycles available for that .....

Is it possible ?

I guess you need to change x coordinate of player ?

That is location D000-D003... as I know fastest way is STA $D000 for example ? That is 4 cycles....

What about changing player data ? That needs to be changed too....

 

Is it better if we use more players ?

 

Can someone explain that - horizontal player multiplexing and its limits....

 

There are no bad lines in the linear addressed graphics modes. The text-based modes (which is like C64s) have a bad line every 8th line or 16th line but that varies with the text mode used. Some text modes only fetch 20 bytes instead of 40.

 

You need to multiplex only position (Xpos) if player is an incarnation (like Joust birds) and xpos is a byte so it's one STA or STX or STY. If it's different data, then you have to update GRAFn register and HPOS unless there's some symmetricity like my Curtains example which replicates 4 sprites horizontally but doesn't change the GRAFn registers-- just positioning them in different ways on right side verses left side. The limit of horizontal multiplexing is number of cycles available in a given graphics mode and scanline (some scanlines have 105 cycles available).

 

...

Link to comment
Share on other sites

The thread has more to do with comparing hardware capability than belittling C64's software library.

 

Well it did not start that way - the OP was asking about games comparisons, not some comparison of the hardware/custom chip's theoretical ability. It's the hobby horse of many posting to twist the thread into a byte by byte, register by register fight...

 

You're just slinging mud at something you haven't fully read/understood.

 

Oh please, that is not the case, I am fully aware of the hardware, I programmed it from 1981 onwards - hence my skepticism of the claimed performance vs the demonstrated performance!

 

You can't relate number of software titles available to hardware being superior.

 

No you can't but as several here can see no good in any games in the C64 library when patently MANY are superb games is an issue. Saying the A8 is better than the C64 because I can draw this picture is irrelevant. It's about the games (see OP) and nothing is being proven...

 

sTeVE

Link to comment
Share on other sites

You can copy/paste if you have uploader on PC -> Atari set up w/CR conversion.

You can then do: ENTER "C:" as one option if doing cassette simulation; that will read in a text file.

Whatever I try I get "ERROR- 130" ?

 

Im using Atari800Win plus, Mydos disk image, even tried to use H1 as hard drive, used "makeAtr.exe" tool to extract or insert files on and of disk image...

I can not save basic file, I can not load file from disk.... :(

What is the proper way to do it ? In small steps please... :)

Link to comment
Share on other sites

You know I agree horizontally both Atari and Amiga have lesser sprite coverage, but some games are planned to use the advantage of the taller sprites (like River Raid). Similarly, you can target the machines strengths like hardware scrolling and mixing modes which would end up costing you a lot more cycles when porting to C64. Just like when you take horizontally wider sprites and try to port on Atari/Amiga, it costs the latter machines more cycles of CPU time by replicating horizontally or substituting with software versions. Amiga can also replicate sprites horizontally using it's similar GRAFn registers.

 

But what about techniques such as VSP, which allow you to scroll the screen in a very flexible way ?

Bitmaps wrap around at 8k boundaries, Screens at 1K boundaries.. And it costs you at most 2 scanlines to do..

There's never any large copies, just updating new data at the edge of the screen as required..

I'm hesitant to suggest combining this with LineCrunch to achieve the same thing vertically, because it will cost you 25 scanlines to setup, but again that gives you vertical wrap around.. But it is easily doable and has been used many times in games.. The technique for them both combined is AGSP

But with these 2 techniques combined you have full XY scrolling with Colour Ram with only updating new data at the screen edges..

Link to comment
Share on other sites

Put it in a text file in directory pointed to by H1:

 

Then you should be able to ENTER "H6:filename"

 

And do not forget to to turn HDD emulation on: Atari -> Settings -> Enable H: patch ...

You will also need: http://raster.infos.cz/atari/forpc/dratex.htm

Found it! Thanks Jvas!

That was it, I set up H1 directory, but damn "Enable h: patch" was not turned on.... :)

Link to comment
Share on other sites

Do things right.

 

Of course you cannot put the screens straightway on A8, Stormlord or others... It´s the difference between port and conversions. The 23 colour in each line are right. To put this on screen, on the right, and real way, just do this, like me. Go to Google and find MAPS of the game. Then print all. And in that A4 paper, 1 paper for each screen do the changes with just a pen. The stormolord picture it´s only an example, but Pms under or overlays it would be the right way... G2F is great, but not the end.... I never sent you any screen of Last ninja, BUT I HAVE ALL THE SCREENS. If I give you examples of G2F Last Ninja Ninja screens, I will be probably, do the same as others. Understand G2F give us how to do all the screens. But not real!...

 

 

But not right. Last Ninja has 130 screens. I have all the shapes from Hi-resol. sprites of C64. I am now turning them to real A8 PM graphics. In my pictures, with G2F I can do all the artwork. But my idea goes much more further. If you do all the screens in G2F, you can put DLIs., PMs., but it's not the right way. I´m not a prograammer, I only want to do the screens, sprite shapes...

 

The real thing here it's that it´s possible to do. All is possible. Someone said yesterday (not yesterday, some days ago) that the only diference (in STORMLORD) is that it never be done.

 

My idea it´s real (I think).

Do all the screen changes using only DLIs. in G2F. Then in other program do all sprites shapes (Ninja, enemys, objects and shapes to put under or overlay (Gprior0)). A tree will always be the same tree. Just Pfs. If on that DLI line I need, I will put sprite shape, if I don't simply, just Pf.)

 

 

Now, I want to ask you: I do all the screens inG2F, DLIS. But if I do that, and use PMs. to under/overlay objects, leaving space free to Ninja and/or enemy sprites shape and movement, will I have the possibility ro use sprites in the game (example: in a line where I have PM2 and 3 used as under/overlay, can I use Ninja PM 0/1.).

 

 

Sorry, I am a little stuck... I think I don´t tell you in a way you understand. I know my idea... But it's dificult to explain. I will try to do all this dialog in a simple paper. Then I will

show you.

 

I know what to do do. I know what is or not is posible!...

The only thing it's that I'm not a programmer. I study and learn with you. With this, I learn how to do things (sprites,screens, others,...). For example, I cannot do a "Raster", gut, if I do a screen and want in some part of screen do a "Raster" I know now the "bad lines". So all my design work take thats in .

Link to comment
Share on other sites

The thread has more to do with comparing hardware capability than belittling C64's software library.

 

Well it did not start that way - the OP was asking about games comparisons, not some comparison of the hardware/custom chip's theoretical ability. It's the hobby horse of many posting to twist the thread into a byte by byte, register by register fight...

...

I think majority of people didn't exactly follow original posting, but it's too late to complain 256 pages later especially if OP isn't protesting. And if you go by original posting, only games that are superior on A8 would be posted so your comments regarding superior C64 is irrelevant to the topic as well.

 

>Oh please, that is not the case, I am fully aware of the hardware, I programmed it from 1981 onwards - hence my skepticism of the claimed performance vs the demonstrated performance!

 

It's not just claims in this thread. Plenty of proof as well. Proof is better than demonstration. With proof of method, you can apply it to whatever scenario you like.

 

You can't relate number of software titles available to hardware being superior.

 

>No you can't but as several here can see no good in any games in the C64 library when patently MANY are superb games is an issue. Saying the A8 is better than the C64 because I can draw this picture is irrelevant. It's about the games (see OP) and nothing is being proven...

 

Nobody is drawing the conclusion based on one picture. Many games were listed that are superior on A8 and that was happening side by side with the hardware discussion and nobody is stopping anyone from going with the topic.

Link to comment
Share on other sites

You know I agree horizontally both Atari and Amiga have lesser sprite coverage, but some games are planned to use the advantage of the taller sprites (like River Raid). Similarly, you can target the machines strengths like hardware scrolling and mixing modes which would end up costing you a lot more cycles when porting to C64. Just like when you take horizontally wider sprites and try to port on Atari/Amiga, it costs the latter machines more cycles of CPU time by replicating horizontally or substituting with software versions. Amiga can also replicate sprites horizontally using it's similar GRAFn registers.

 

But what about techniques such as VSP, which allow you to scroll the screen in a very flexible way ?

Bitmaps wrap around at 8k boundaries, Screens at 1K boundaries.. And it costs you at most 2 scanlines to do..

There's never any large copies, just updating new data at the edge of the screen as required..

I'm hesitant to suggest combining this with LineCrunch to achieve the same thing vertically, because it will cost you 25 scanlines to setup, but again that gives you vertical wrap around.. But it is easily doable and has been used many times in games.. The technique for them both combined is AGSP

But with these 2 techniques combined you have full XY scrolling with Colour Ram with only updating new data at the screen edges..

 

"Very flexible" so much so that it doesn't even work consistently on all machines. Unlike DLs which is a standard feature on all 8-bit computers since CTIA and scrolls per scanline and w/overscan or without. There's some stuff like shifting pixels in Graphics 9 that works on some machines, but at least say something that's consistent and doesn't garble the memory and risk computer software failure. And regardless, the point is things supported in hardware in a machine will always be better than doing them in software unless you have a lot of free CPU time compared to the other machine. Take collision detection as an example-- it definitely helps in games that need CPU power to do other things.

Link to comment
Share on other sites

aehm... it is nice to convert the sprite assets or shapes of LN but for the screens to do them in G2F might be dangerous if you don't know how the programmer will fill the screens with life hence means how the actual game & gfx engine will work? It is not good starting a lot of work without a lead programmer who is actually doing the coding?

Link to comment
Share on other sites

aehm... it is nice to convert the sprite assets or shapes of LN but for the screens to do them in G2F might be dangerous if you don't know how the programmer will fill the screens with life hence means how the actual game & gfx engine will work? It is not good starting a lot of work without a lead programmer who is actually doing the coding?

 

I'd say, it is better to have the screens around and to find what solution is the best solution for the gampeplay then.

Link to comment
Share on other sites

It's not just claims in this thread. Plenty of proof as well. Proof is better than demonstration. With proof of method, you can apply it to whatever scenario you like.

 

Then show me the proof, that's called a demonstration...

 

I see no proof, just show me and I will be sated, content to bow to the evidence rather than keep hearing the same implausible theory.

 

I've been an Atari 800 user and programmer for 29 years - I think I understand the PRACTICAL abilities of the hardware in a game scenario...

 

sTeVE

Edited by Jetboot Jack
Link to comment
Share on other sites

...So yes, there's a sprite left over for a cursor, and pretty much all of the cpu remaining as well..

I'm all for commodore but have to correct you :)

In every line where you use sprites VIC has to read pointer and sprite data...

So you lose 2 cycles for each sprite and 2 or 3 cycles because only instructions that perform write are possible in those last two or 3 cycles before sprite fetching begins...

So you end up losing 14+(2 or 3) cycles, roughly 15 * 200 lines = 3000 cycles...

It's not without cost :)

 

And as I know one line is 63 cycles long on PAL system ?

25 badlines = 25 * 21 (23 cpu cycles remaining per BL)..

175 normal lines = 175 * 63

112 blanked lines = 112 * 63

So we get 18606 cycles per frame..

 

But still easier to set up than ataris horizontal multiplexing of players, and with more colors and resolution...

 

As Rybags stated in post #6443, it's not just cycles you have to look at but uniformity of it and being able to sync up to particular cycles and I would say exactness of them. I can play back a digitized audio file knowing DMA is pretty much uniform in graphics modes (no bad lines). So what happens when you play audio with bad lines on C64? What's the worst case latency? And then of course those sprites and color RAM don't always use up same number of cycles so writing kernels would be a much more difficult task. Atari CPU clock syncs up with video color burst.

 

PAL/NTSC have same number of CPU cycles/scanline on Atari so one version of kernel will work on both machines. And you can use sprites in replicate mode w/screen off and get 105 cycles/scanline (27510/frame NTSC or 32760/frame PAL) for applications that need the time.

Link to comment
Share on other sites

It's not just claims in this thread. Plenty of proof as well. Proof is better than demonstration. With proof of method, you can apply it to whatever scenario you like.

 

Then show me the proof, that's called a demonstration...

 

I see no proof, just show me and I will be sated, content to bow to the evidence rather than keep hearing the same implausible theory.

 

I've been an Atari 800 user and programmer for 29 years - I think I understand the PRACTICAL abilities of the hardware in a game scenario...

 

sTeVE

 

Demonstration can also mean just an experiment to show it working in a particular case so I treat "PROOF" as a more solid case. Game scenarios vary with creativity of user-- if Atari was initial target machine for most software-- people would have optimized toward its hardware and it would be harder to port to other machines at the time. But if you want to port C64 games and find it hard it port some things, it doesn't mean C64 is better machine.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...