Graphics and Map ripping from Atari ST games

All about ST/STE games

Moderators: simonsunnyboy, Mug UK, Doctor Bob Gordon, ICS, Moderator Team

Codetapper
Atariator
Atariator
Posts: 17
Joined: Fri Aug 05, 2011 8:13 am

Graphics and Map ripping from Atari ST games

Postby Codetapper » Fri Jul 26, 2013 4:50 am

Some of you may have heard about my graphics and map ripping software Maptapper which has been used to extract thousands of levels from hundreds of Amiga games. (These are all displayed on the Hall of Light site).

There has been interest from a few people for me to support Atari ST ripping natively and as a test, I have successfully managed to extract the tiles and then the first couple of levels from that piece of **** Tiertex game Dynasty Wars! Can any of the experts on here answer the following:

1. By looking at the Steem SSE source I have managed to load STS files, extract the 16 colour palette and depack the data. Once that was done, the search tools operate independently of the original file so no changes were needed. Are STS files the only ones that I need to worry about for ST users?

2. Is anybody on here interested in helping to test the ST ripping side of the program? (I'm mainly an Amiga user!)

3. Is there any equivalent site to HOL that would store maps or sprite sheets for ST games?

I hope to release an updated version this weekend with the preliminary ST support activated.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Graphics and Map ripping from Atari ST games

Postby AtariZoll » Fri Jul 26, 2013 6:48 am

1. Don't get exactly why you asking it. STS is just Steem's snapshot format, containing all RAM used. + other relevant. You can do same in Hatari, but format is certainly different. Or instead dealing with snapshot you can do RAM section dumps with Steem Debugger - if you don't know what is it, grab it immediately .

3. For instance: http://bringerp.free.fr/RE/
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

Codetapper
Atariator
Atariator
Posts: 17
Joined: Fri Aug 05, 2011 8:13 am

Re: Graphics and Map ripping from Atari ST games

Postby Codetapper » Fri Jul 26, 2013 8:08 am

1. It's more a question of "is Steem the main emulator people use?" On the Amiga, I only support WinUAE savestates as that is *the* emulator. Hence the question. How many people use Hatari? What's the most popular emulator and is any particular one much better than any other?

RAM section dumps are just uncompressed binary files aren't they? But they don't contain any palette information so they're less useful. Please correct me if I'm wrong about that.

3. Thanks for that, some impressive maps there! But is he only storing/uploading maps he's personally ripped?

User avatar
Marakatti
Atari God
Atari God
Posts: 1364
Joined: Sat Jun 18, 2005 9:58 am
Location: Finland
Contact:

Re: Graphics and Map ripping from Atari ST games

Postby Marakatti » Fri Jul 26, 2013 8:12 am

Atarimania can host the gamemaps. They will be linked to the game records for example this way --> http://www.atarimania.com/game-atari-st ... 10112.html

I could try to help you with the testing as long as it's quite simple to use, no programming skills or similar here ;)
-------------< Member of Atarimania >-----------
-< ST / STe / Falcon030 / TT030 archiver >-
-------------> www.atarimania.com <-------------

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Graphics and Map ripping from Atari ST games

Postby AtariZoll » Fri Jul 26, 2013 1:50 pm

Codetapper wrote:1. It's more a question of "is Steem the main emulator people use?" On the Amiga, I only support WinUAE savestates as that is *the* emulator. Hence the question. How many people use Hatari? What's the most popular emulator and is any particular one much better than any other?
RAM section dumps are just uncompressed binary files aren't they? But they don't contain any palette information so they're less useful. Please correct me if I'm wrong about that.
3. Thanks for that, some impressive maps there! But is he only storing/uploading maps he's personally ripped?


I think that Hatari is little less used, but it is still developed (Steem too, but not 'officially') . I don't think that there is some big diff. between 2.
You can dump color palette registers ( at $FF8240 ) too. And it may happen that all it is irrelevant, because every level has own palette, what is stored somewhere in RAM - likely rare case, though.
3. I think that yes.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
troed
Atari God
Atari God
Posts: 1450
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Graphics and Map ripping from Atari ST games

Postby troed » Fri Jul 26, 2013 2:19 pm

AtariZoll wrote:I think that Hatari is little less used, but it is still developed (Steem too, but not 'officially') . I don't think that there is some big diff. between 2.


Hatari is used on Windows, Mac and Linux. STeem is Windows only. (Also, Hatari runs both ST and STE, STeem only STE iirc - I'm a Mac user myself).

If I were to develop a completely new tool I'd definitely choose Hatari just because of the platform compatibility.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Graphics and Map ripping from Atari ST games

Postby AtariZoll » Fri Jul 26, 2013 6:48 pm

troed wrote:
AtariZoll wrote:Hatari is used on Windows, Mac and Linux. STeem is Windows only. (Also, Hatari runs both ST and STE, STeem only STE iirc - I'm a Mac user myself).
If I were to develop a completely new tool I'd definitely choose Hatari just because of the platform compatibility.


Not correct - Steem has Linux build too. And 'unofficial new devel.' has ST mode too - we have even forum section dedicated for ...
Some prefer platform compat, some better GUI :D
Don't plan to go in some 'which is better' discussion. Especially because we are already OT.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

Codetapper
Atariator
Atariator
Posts: 17
Joined: Fri Aug 05, 2011 8:13 am

Re: Graphics and Map ripping from Atari ST games

Postby Codetapper » Fri Jul 26, 2013 9:11 pm

I have had a quick look at the Hatari save format, and no disrespect to the authors, but it's a very poorly implemented save method if you ask me. Each chunk that is saved seems to have no length information so it's hard to locate the start of the real data. By dumping all the variables in a chunk of memory it makes it difficult/impossible to ever add further variables to that section of code as the length will change and therefore the save games will fail! Steem was not great either but at least had some length information in certain chunks.

WinUAE does it a much better way, like an IFF file with a series of chunks and lengths, and you can just read the chunks and process the ones you want and skip the others.

For now, I'm not sure how to implement Hatari support other than decompress the GZ file and have a 4Mb file to have to scan through for a 1Mb memory dump.

Does anybody know if there is a way to get to just the memory dump and what will happen with the savestates in future versions if any of the sections change in size?

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1996
Joined: Sun Jul 31, 2011 1:11 pm

Re: Graphics and Map ripping from Atari ST games

Postby Eero Tamminen » Fri Jul 26, 2013 9:54 pm

Codetapper wrote:what will happen with the savestates in future versions if any of the sections change in size?


Hatari memory dump is really just a dump of Hatari's internal structures' contents; it's not structured as a file, portable (between different byte orders or pointer sizes) nor intended to be read by anything else than the same Hatari binary. Contents and sizes of Hatari's internal structures change between Hatari versions.

Codetapper wrote:Does anybody know if there is a way to get to just the memory dump


Invoke Hatari debugger (with AltGr+Break) and use "savebin" command. Following would save first 4MB of RAM:

Code: Select all

savebin hatari-4mb.dump 0 0x400000


On Unix, if Hatari has been built with socket support, you can do this also through Hatari's control socket (see "man hconsole").

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Graphics and Map ripping from Atari ST games

Postby Dio » Sun Jul 28, 2013 10:41 pm

Basically, the problem is that unless there's a strict definition of exactly what the 'hidden state' in the ST is, then it's impossible to write a portable savestate file, and I'm not sure that we have that strictly nailed down for the ST yet (although the FPGA ST efforts may reveal it, if they've been doing exact logic comparison).

User avatar
christos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2456
Joined: Tue Apr 13, 2004 8:24 pm
Location: Greece
Contact:

Re: Graphics and Map ripping from Atari ST games

Postby christos » Sun Jul 28, 2013 10:45 pm

Dio wrote:Basically, the problem is that unless there's a strict definition of exactly what the 'hidden state' in the ST is, then it's impossible to write a portable savestate file, and I'm not sure that we have that strictly nailed down for the ST yet (although the FPGA ST efforts may reveal it, if they've been doing exact logic comparison).


Well D-bug have made savestates available on their hard disk patches on a real st so I guess it's possible. Maybe that format is worth investigating.

Codetapper
Atariator
Atariator
Posts: 17
Joined: Fri Aug 05, 2011 8:13 am

Re: Graphics and Map ripping from Atari ST games

Postby Codetapper » Sun Jul 28, 2013 10:55 pm

For now I will support the Steem savestates (as you can easily locate the palette information and the memory dump) but for Hatari all I am doing is decompressing the gzip stream and leave the user with a 4Mb file to trawl through for a 1Mb game. Not ideal at all (as it's impossible to find the palette, and the start of data), but at least you can scan through a dump.

If the Hatari guys implement a proper savestate at some point, I'll support that later. I really don't understand why the savestate can't consist of a header for each chunk of data saved and the length of each chunk as that would be all you need:

dc.l 'PAL ' ;Chunk name
dc.l 16*2 ;Length in bytes
ds.w ... palette ...

dc.l 'MEM ' ;Chunk name
dc.l $80000
ds.b ... memory dump ...

dc.l 'VARS' ;Chunk name
dc.l 32
ds.b ...

etc. You'd add 8 bytes to each block of data saved, and the file would still load into memory as it did before, and probably only cost a few kb of chunk names/lengths. And any new data stored can safely be added to the file as required. An old version of Hatari with a newer config would still import fine, as it would skip the chunks it doesn't know about. Is it so simple nobody has thought of it?

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Graphics and Map ripping from Atari ST games

Postby AtariZoll » Mon Jul 29, 2013 11:38 am

Dio wrote:Basically, the problem is that unless there's a strict definition of exactly what the 'hidden state' in the ST is, then it's impossible to write a portable savestate file, and I'm not sure that we have that strictly nailed down for the ST yet (although the FPGA ST efforts may reveal it, if they've been doing exact logic comparison).


I don't get why you talk about some 'hidden state' in case of ST. There is nothing hidden (except maybe wake-up states, which are not interesting at all in this case) . Everything can be read. All HW registers. Only that with MFP Timer data registers is little harder.
And since graphic modes are pretty simple, all this has really not much with this topic.
Making some standard snapshot format seems for me pretty useless - it is possible, but it will help nothing in this case. I could do conversion from emulator snapshots into my savestate snapshot or vs. - but no one suggested it so far. ( I did it in case of Sinclair Spectrum ).
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

Codetapper
Atariator
Atariator
Posts: 17
Joined: Fri Aug 05, 2011 8:13 am

Re: Graphics and Map ripping from Atari ST games

Postby Codetapper » Mon Jul 29, 2013 11:50 am

Most emulators have an ability to save the state and restore it later on a different machine, different version of the emulator etc. Why wouldn't you make a single savestate format that can correctly reload the state of the machine as it was saved?

Sites like C64Endings provide the savestate files so anyone can download and run the ending sequence, WinUAE savestates are passed around for various purposes. Why wouldn't Hatari want to do this?

Also why on earth would the savestate not even identify itself. If you decompress the gzip stream you get 1.7.6. or something like that. Why not a useful ID and version number:

ds.b "HATARI SAVESTATE 1.7.6"

or something? To quote Kramer on Seinfeld, it all seems a bit "amateur hour" I must say.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Graphics and Map ripping from Atari ST games

Postby AtariZoll » Mon Jul 29, 2013 12:22 pm

Codetapper wrote:Most emulators have an ability to save the state and restore it later on a different machine, different version of the emulator etc. Why wouldn't you make a single savestate format that can correctly reload the state of the machine as it was saved?
...


All it is on people wanting it. Ask emulator developers, and if they decide that enough people is interested they will improve savestates in that direction.
Now, doing something standard in Atari ST waters now ... don't know, other platforms have more cowork, I think. As this community is at moment, for me seems not likely to see some standard snapshot format. And honestly, I don't see that many people want to play some Steem snapshot at all cost on Hatari or real HW. Good thing is that real HW snapshots are OK for emulators - so conversion in one direction is solved :D
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
bullis1
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2301
Joined: Tue Dec 12, 2006 2:32 pm
Location: Canada
Contact:

Re: Graphics and Map ripping from Atari ST games

Postby bullis1 » Mon Jul 29, 2013 12:54 pm

Codetapper wrote:To quote Kramer on Seinfeld, it all seems a bit "amateur hour" I must say.

It is amateur though. It's an open source emulator IIRC, and the project isn't that old as far as complex emulators go. Nobody gets paid :wink:

I think it's fantastic that you are trying to add ST support to maptap. I'd say don't bother with Hatari snapshots; just go with the Steem ones. It's the more widely used emulator anyway. Hatari has alot of backing on these forums, but elsewhere Steem has the biggest userbase.
Member of the Atari Legend team

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 5161
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: Graphics and Map ripping from Atari ST games

Postby simonsunnyboy » Mon Jul 29, 2013 3:30 pm

bullis1 wrote:
Codetapper wrote:To quote Kramer on Seinfeld, it all seems a bit "amateur hour" I must say.

It is amateur though. It's an open source emulator IIRC, and the project isn't that old as far as complex emulators go. Nobody gets paid :wink:

I think it's fantastic that you are trying to add ST support to maptap. I'd say don't bother with Hatari snapshots; just go with the Steem ones. It's the more widely used emulator anyway. Hatari has alot of backing on these forums, but elsewhere Steem has the biggest userbase.


If you refer to Hatari than you should be corrected. Hatari surfaced in 2001 or 2002, and it is based on the 1999 vintage WinSTon v0.5 source although those parts are hard to recognize in the current version of Hatari.
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

User avatar
bullis1
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2301
Joined: Tue Dec 12, 2006 2:32 pm
Location: Canada
Contact:

Re: Graphics and Map ripping from Atari ST games

Postby bullis1 » Mon Jul 29, 2013 7:44 pm

I stand corrected Simon.

Still, Codetapper should just go with Steem snapshots, as it's the only functional option for his purposes. There are a number of recent cracks/fixes that do savestates on real hardware too, but once again there are no standards.
Member of the Atari Legend team

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 5161
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: Graphics and Map ripping from Atari ST games

Postby simonsunnyboy » Tue Jul 30, 2013 3:30 pm

Actually I think a common snapshot format similar to the .z80 files for the ZX Spectrum would be interesting and nice to have. Some emulators don't have proper disk write support but having common savestates could help in saving game positions. I also would fix it to 4MB but only snapshot which config is actually used.
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Hippy Dave
Atari Super Hero
Atari Super Hero
Posts: 515
Joined: Sat Jan 10, 2009 5:40 am

Re: Graphics and Map ripping from Atari ST games

Postby Hippy Dave » Tue Jul 30, 2013 7:51 pm

christos wrote:
Dio wrote:Basically, the problem is that unless there's a strict definition of exactly what the 'hidden state' in the ST is, then it's impossible to write a portable savestate file, and I'm not sure that we have that strictly nailed down for the ST yet (although the FPGA ST efforts may reveal it, if they've been doing exact logic comparison).


Well D-bug have made savestates available on their hard disk patches on a real st so I guess it's possible. Maybe that format is worth investigating.

If one can make a 'save state' on a stock Atari, then one has a good solution because this will work on emulators also.
An emulator should have the same limitations as the real hardware. Extra features, like debuggers, should have
compile time --enable-feature options to make the bloat optional.

User avatar
nativ
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4106
Joined: Mon Jul 30, 2007 10:26 am
Location: South West, UK

Re: Graphics and Map ripping from Atari ST games

Postby nativ » Tue Jul 30, 2013 9:02 pm

I have a piece of software from 1987? Revolver that snapshots the ST's Ram and 'flash' loads back via a RAM disk? I think a 2 min load is done in 10 secs

ULS is like this and so is PPera's System.

Can we just use MSA,ST and STX from the Atari's via this reload feature?
Atari STFM 512 / STe 4MB / Mega ST+DSP / Falcon 4MB 16Mhz 68882 - DVD/CDRW/ZIP/DAT - FDI / Jaguar / Lynx 1&2 / 7800 / 2600 / XE 130+SD Card // Sega Dreamcast / Mega2+CD2 // Apple G4

http://soundcloud.com/nativ ~ http://soundcloud.com/nativ-1 ~ http://soundcloud.com/knot_music
http://soundcloud.com/push-sounds ~ http://soundcloud.com/push-records

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Graphics and Map ripping from Atari ST games

Postby AtariZoll » Wed Jul 31, 2013 6:49 am

nativ wrote:I have a piece of software from 1987? Revolver that snapshots the ST's Ram and 'flash' loads back via a RAM disk? I think a 2 min load is done in 10 secs
ULS is like this and so is PPera's System.
Can we just use MSA,ST and STX from the Atari's via this reload feature?


I don't have experience with SW, devices (made in first place to break protections, I think), which makes snapshots on ST, but certainly they are based on saving machine state. There must be added extra code for keypress detection in games - we don't have non-maskable interrupt for instance on ST.

In theory, you could make some floppy image where would be startup code and loading, setting initial state of game + data what loads later. Actually, some cracks are exactly it. But it is much more complicated on ST than on some Sinclair Spectrum. No chance that some SW can do it .

Snapshot of Spectrum is very simple: only RAM and CPU registers . By ST we need: video, audio (PSG chip), MFP, IKBD chip, as abs. minimum.
Additionally, in many cases TOS version is necessary - snapshot may work only on exact same TOS v. - same # and language. (Because vectors pointing in ROM for instance).
So, some format should hold all it, + STE HW registers + ACIA , FDC ....
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
nativ
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4106
Joined: Mon Jul 30, 2007 10:26 am
Location: South West, UK

Re: Graphics and Map ripping from Atari ST games

Postby nativ » Wed Jul 31, 2013 10:28 am

Oh I forgot one! The Romantic Robot series, I am assuming the ST version did this too. On the Spectrum you could grab and save the memory at any point, and even PEEK and POKE.
Atari STFM 512 / STe 4MB / Mega ST+DSP / Falcon 4MB 16Mhz 68882 - DVD/CDRW/ZIP/DAT - FDI / Jaguar / Lynx 1&2 / 7800 / 2600 / XE 130+SD Card // Sega Dreamcast / Mega2+CD2 // Apple G4

http://soundcloud.com/nativ ~ http://soundcloud.com/nativ-1 ~ http://soundcloud.com/knot_music
http://soundcloud.com/push-sounds ~ http://soundcloud.com/push-records

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Graphics and Map ripping from Atari ST games

Postby Dio » Wed Jul 31, 2013 10:35 pm

AtariZoll wrote:I don't get why you talk about some 'hidden state' in case of ST. There is nothing hidden (except maybe wake-up states, which are not interesting at all in this case) . Everything can be read. All HW registers. Only that with MFP Timer data registers is little harder.

If you're considering stopping the clock at an arbitrary instruction boundary and saving the state for accurate later restore, that's clearly not the case. Just about every chip on the board has some hidden state. Just off the top of my head:
68000: prefetch register values, current phase step of the E clock
Display: the number of planes currently in the shifter staging registers, the current state of the H and V display enables
MFP: reset value of eachTDR; cycles to next decrement of the TDR
Sound: the time to next toggle of each YM2149 squarewave, the current phase step in the envelopes
Disk: the current track of the drive, the current rotation angle of the disk, the FDC state machine state (e.g. at what point is it in looking for an address mark?), the information currently in the DMA FIFOs
IKBD: the current IKBD queue (which may be part way through transferring e.g. a mouse packet)

Sure, the chances of these actually affecting the resulting savestate is not really very high, and you can eliminate some of them by putting restrictions as to when you allow savestates (e.g. don't allow floppy busy) but it's certainly possible that they are important. Emulators wanting to implement 100% accurate savestates need to handle all of these things, even if you might not necessarily see them as very important in a 'distribution' format.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Graphics and Map ripping from Atari ST games

Postby AtariZoll » Thu Aug 01, 2013 6:20 am

I said that all HW registers can be read. And it is what we need. CPU prefetch is really irrelevant here. We don't need total accurate state of machine, but possibility to restore normal work of some SW. So, supporting exact state of FDC and floppy drive is really not needed - we will not interrupt in middle of some floppy operation. Same may stay for IKBD. In case of MFP we need to read somehow timer data registers - what is only thing not possible to read directly - possible with little more time. Sound - same as for FDC. No need to save exact state of video/shifter.
Of course, in case of emulator there is possible to save everything, every small detail, and I don't know what all exactly popular emulators save.
In any case, just another proof that standard statesave format is not so easy - different emulators may save pretty different infos depending on emulation's way self.

By real machines is possible to save practically everything needed, in 99% cases just by saving HW registers, CPU registers and RAM. Possible problem is loosing of sync in case of MFP Timer B controlled video , for instance. Saving it and restarting in exact needed moment is almost impossible, so better is to use game's routine which starts it syncronised.
From practice: in most of cases no need to save STE extra Hscroll and scanline skip registers, because SW will update them at next Vbl.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.


Social Media

     

Return to “Games - General”

Who is online

Users browsing this forum: No registered users and 2 guests