what should i write next?

reminisce about bbc micro & electron games like chuckie egg, repton, elite & exile

Related forum: adventures


User avatar
sydney
Posts: 1968
Joined: Wed May 18, 2005 9:09 am
Location: Newcastle upon Tyne

Re: what should i write next?

Postby sydney » Tue May 10, 2016 7:31 pm

fwibbler wrote:Much as I like Paradroid for the Archimedes, I still prefer Quazatron for the ZX Spectrum (I may have mentioned this before :roll: ). An updated and more colourful version of this would be nice.


Is the Archemedes version the same as the amiga/st versions which were vertical scrolling only? I much prefer the c64 version to the amiga version. I've never played Quazatron so may give it a go sometime to compare.

paulb
Posts: 764
Joined: Mon Jan 20, 2014 9:02 pm

Re: what should i write next?

Postby paulb » Tue May 10, 2016 7:43 pm

ThomasHarte wrote:The CPC has another trick up its sleeve though: linear scan lines. Through rerouting of the address lines. Being officially a 4Mhz system (albeit with contended memory, so the CPU sees some wait states if it accesses memory inopportunely), probably the pixel clock ends up being much the same as the BBC too? So pixels are the same physical size on screen?


You might have to explain this "linear scan lines" thing!

ThomasHarte wrote:
MatthewThompson wrote:There's White Magic by The 4th Dimension which whilst not a direct Gauntlet clone, comes pretty close and is clearly inspired by it.


Dunjunz is also unashamedly on the Gauntlet spectrum.


Once one gets past the superficial differences - yes, Gauntlet looks nice in the arcade, and I guess it sold quite a few Atari STs at the time - there's no need to feel that the Gauntlet genre wasn't tackled well enough by Dunjunz. Indeed, the gameplay of Dunjunz was arguably a lot more varied (and better) than the "chain gang" slog through uncountable monsters that Gauntlet offered.

paulb
Posts: 764
Joined: Mon Jan 20, 2014 9:02 pm

Re: what should i write next?

Postby paulb » Tue May 10, 2016 8:06 pm

fwibbler wrote:1942 (or 1943) would be nice too as we don't really have anything like that on the Beeb.


Where do you stand on Firetrack, then? Not even Peter Scott could face trying to out-do it, apparently. (See the Daxis section of the STH lost and found page.)

ThomasHarte
Posts: 327
Joined: Sat Dec 23, 2000 5:56 pm

Re: what should i write next?

Postby ThomasHarte » Tue May 10, 2016 8:30 pm

paulb wrote:You might have to explain this "linear scan lines" thing!

Just some crazy idea a few of the other micros apply that makes it a real hassle to plot text quickly*.

* ahem other than the ZX Spectrum's increment-H work of genius — within any 8-line aligned 8-line block, the byte on the line below is always 256 bytes forwards from where you are, so if you have a 16-bit address in HL then you can always increment or decrement L to go left or right and increment or decrement H to go up or down. Lines are linear but text is still fast to plot within character squares, and the correct addresses are still hit to get DRAM refresh from video output.

ThomasHarte
Posts: 327
Joined: Sat Dec 23, 2000 5:56 pm

Re: what should i write next?

Postby ThomasHarte » Wed May 11, 2016 1:36 pm

As to the original question, would sufficiently simple modern(-ish) mobile game suggestions be acceptable? I'm five years behind the times but Tiny Wings and Jet Pack Joyride would both probably adapt well, being primarily procedural or random, and would both be excellent 50Hz horizontal scrollers. Possibly the latter more than the former since it's a vertical and horizontal scroll with, in its mobile form, a bit of zoom, that'd be more likely to push you towards a hybrid pixel/vector display if you were porting to 8-bit targets.

User avatar
fwibbler
Posts: 180
Joined: Thu Jan 13, 2005 10:37 pm
Location: Essex
Contact:

Re: what should i write next?

Postby fwibbler » Wed May 11, 2016 3:02 pm

Where do I stand on Firetrack?

Hmmm, I know its a great from a technical standpoint, but give me the choice of playing Lightforce (Speccy), Powerstrike (Sega), Quark (Acorn 32bit), Tyrian (DOS), 1943 (Arcade) (thats all my favourite top/down scrolling shootemup games by the way) or Firetrack, then Firetrack would always be at the bottom of the list for me.

HTF
Posts: 1
Joined: Fri Apr 22, 2016 9:29 pm

Re: what should i write next?

Postby HTF » Sun May 15, 2016 10:06 pm

Hi, This is my first post although I've been following this forum for many many years now.

Here are my suggestions for what you could write next;

1. Tempest - The original arcade machine was 6502 based and the source code was only 8k in size. Perhaps you could do a Mode 1 version with 8 colours? or even a hi-res Mode 0 version with *some* colours. This would be a good opportunity for you to experiment with a vector scan type routine for the BBC. Could you even get the Beeb to execute as far as possible the original 6502 source code? The version that was released by Superior was OK, but not great, and Orlando's Demo version looked great but wasn't finished.

2. Citadel 2020 - Can we have a new version of Citadel with perhaps 256 or more screens? Why don't you include the map data on ROM (most emulators allow SWR and most of us that use proper Beebs can get a ROM blown pretty easily). Maybe forum members could help in designing the graphics, sounds and screens etc. a group effort.

3. Write a mega-game that requires all the Sideways ROM sockets and dual 80 track double-sided discs for the program code. Get somebody to produce a small piece of hardware that modified the 6845 so you could really push the BBC to it's limits. Rewrite your own OS ROM and remove the Basic ROM so you have complete control of the Beebs hardware.

User avatar
1024MAK
Posts: 6680
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: what should i write next?

Postby 1024MAK » Sun May 15, 2016 10:40 pm

Hello HTF and Welcome :D

If the game only reads from the sideways ROM area, EEPROMs and sideways RAM could also hold the data. The advantage with sideways RAM is that no ROM needs to be programmed (you can load data in from a disk or a SD card). The advantage of EEPROM is the Beeb can program it :D

You will have to explain what you mean about modifications for the 6845 CRT controller. It only does the timing, the cursor and the RAM address control. The way the data from the RAM is converted to what you see on screen is done by the video processor.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

ThomasHarte
Posts: 327
Joined: Sat Dec 23, 2000 5:56 pm

Re: what should i write next?

Postby ThomasHarte » Mon May 16, 2016 1:45 pm

Pulling the two threads together, a programmable option to shuffle the three lowest video address lines five lines to the left would have been quite helpful by opening up an optional 32-linear-bytes-per-line addressing mode. I suspect that the actual transposition of lines would actually be extraordinarily inconvenient to implement in hardware though?

If you're chucking extra hardware in, why not some sort of DMA thing that takes the 6502 off the bus? What state do its lines go if you assert RDY? Is that signal even available on an external port?

paulb
Posts: 764
Joined: Mon Jan 20, 2014 9:02 pm

Re: what should i write next?

Postby paulb » Mon May 16, 2016 2:15 pm

ThomasHarte wrote:Pulling the two threads together, a programmable option to shuffle the three lowest video address lines five lines to the left would have been quite helpful by opening up an optional 32-linear-bytes-per-line addressing mode. I suspect that the actual transposition of lines would actually be extraordinarily inconvenient to implement in hardware though?


I was thinking about this and surely the 256 byte jump from line to line would cause the screen memory to be spread over a huge address range. What did I miss?

ThomasHarte wrote:If you're chucking extra hardware in, why not some sort of DMA thing that takes the 6502 off the bus? What state do its lines go if you assert RDY? Is that signal even available on an external port?


I posted about this before, but the forum's stupid search function refuses to search for DMA and RDY because they are "common" terms (which I doubt), so I can't point you to the thread concerned. But RDY is exposed even via the cartridge connector and it should work, despite vague recycled claims that it doesn't which probably misrepresent the original caveat related to the NMOS version of the CPU (which merely indicates that it doesn't suspend the CPU until a read cycle occurs), but I haven't tested it myself. It's possible that some of the Atom debugging boards use RDY, though.

ThomasHarte
Posts: 327
Joined: Sat Dec 23, 2000 5:56 pm

Re: what should i write next?

Postby ThomasHarte » Mon May 16, 2016 2:52 pm

paulb wrote:
ThomasHarte wrote:Pulling the two threads together, a programmable option to shuffle the three lowest video address lines five lines to the left would have been quite helpful by opening up an optional 32-linear-bytes-per-line addressing mode. I suspect that the actual transposition of lines would actually be extraordinarily inconvenient to implement in hardware though?


I was thinking about this and surely the 256 byte jump from line to line would cause the screen memory to be spread over a huge address range. What did I miss?

That's why I was suggesting that (i) the shift be only five lines (honestly, I may have been thinking too much about the Electron here in preferring a 32-byte line; 64 is probably more BBC appropriate); and (ii) therefore that it be optional, so that 40 column, 80 column, arbitrary other column modes still work correctly. Which I think doesn't introduces leaps from line to line, at the cost of discarding most of the flexibility on line length?

User avatar
tricky
Posts: 1823
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: what should i write next?

Postby tricky » Mon May 16, 2016 5:57 pm

I would have been happy with the memory layed out as 256 bytes high, so one byte to the right would be one page. This would have meant wasting memory in modes 3 and 6, but would have made non 8 pixel high fonts easier, grid mode of the 6845 might have helped (if I haven't made it up). I also had some crazy ideas about arranging the for pixels of mode one into a2x2 square, but ig guess the memory wouldn't be fast enough.

User avatar
tricky
Posts: 1823
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: what should i write next?

Postby tricky » Mon May 16, 2016 7:59 pm

Well HTF, those are some ideas!

"1. Tempest -" I did play around with vector graphics BITD when I was going through my Lunar Lander fase, I might get back to it one day.

"2. Citadel 2020 -" Sorry, never played this, but I like the idea of a "... group effort".

"3. Write a mega-game ... small piece of hardware that modified the 6845 so you could really push the BBC to it's limits."
You may have overestimated my abilities just a little :shock:

"Rewrite your own OS ROM and remove the Basic ROM so you have complete control of the Beebs hardware."
My games generally use BASIC to script the loading from disk or whatever to allow people to "make it work" on their machine, the the game does one OS call *FX0 to check what kind of beeb it is on, then rudy takes control, only allowing the OS to pass on interrupts, as replacing the OS ROM would be a step too far! I drive everything else myself for predictability and speed, not that I have any complaints about OS1.2.

I'm currently having another go at tidying up my Phoenix game, but it is a bit slow going.
http://www.retrosoftware.co.uk/forum/viewtopic.php?f=19&t=909&hilit=phoenix

User avatar
kieranhj
Posts: 489
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: what should i write next?

Postby kieranhj » Mon May 16, 2016 9:43 pm

HTF wrote:1. Tempest - The original arcade machine was 6502 based and the source code was only 8k in size. Perhaps you could do a Mode 1 version with 8 colours? or even a hi-res Mode 0 version with *some* colours. This would be a good opportunity for you to experiment with a vector scan type routine for the BBC. Could you even get the Beeb to execute as far as possible the original 6502 source code? The version that was released by Superior was OK, but not great, and Orlando's Demo version looked great but wasn't finished.

Interesting idea, I'll have to track down the source. Main problem I'm guessing would be the limit on how many vectors a Beeb can rasterise in 20ms, not a lot is the likely answer. The original arcade machine being a vector display meant these were all a fixed cost I'm guessing (curious to look up the hardware now.)

Does anyone have a fast Bresenham line drawing routine lying around perchance? ;)

Always been interested in doing something for MODE 0 as it was a resolution not matched by any other home micros at the time. It wouldn't be possible to do multi-coloured lines though - you can only change the palette on a timed interrupt so the colours alter as you go down the screen.

User avatar
kieranhj
Posts: 489
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: what should i write next?

Postby kieranhj » Mon May 16, 2016 10:19 pm

kieranhj wrote:Interesting idea, I'll have to track down the source. Main problem I'm guessing would be the limit on how many vectors a Beeb can rasterise in 20ms, not a lot is the likely answer. The original arcade machine being a vector display meant these were all a fixed cost I'm guessing (curious to look up the hardware now.)

All the Tempest info you could need: http://ionpool.net/arcade/tempest_code_project/tempest_code_project.html

This looks decidedly non-trivial: the vector display is its own custom chip with a set of opcodes & registers, there's a poorly documented "mathbox" chip to assist with the 3D calculations and then Atari's custom POKEY chips that handle all the I/O. And the code is all wrapped up in the usual accoutrements of arcade cabinets so handling coin inputs, DIP switches etc.

Someone would have to have a very intimate knowledge of both the original Tempest & the Beeb to make this work. The disassembly effort on the aforementioned website makes my Thrust effort look decidedly easy..

User avatar
tricky
Posts: 1823
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: what should i write next?

Postby tricky » Mon May 16, 2016 10:41 pm

I haven't looked at that site yet, but writing the acrobat TV, RipCord and Sprint emulators for the beeb didn't really take that long; of course RipCord uses nearly the same code as acrobat TV.I did look at emulating a pokey, but It was more work than I wanted to do; each feature is fairly simple, but there are a lot of them.

EDIT: forgot to say, it was only quick because I had the mame driver source.

User avatar
Bagpuss
Posts: 17
Joined: Mon Apr 25, 2016 2:09 pm
Location: Cornwall

Re: what should i write next?

Postby Bagpuss » Tue May 17, 2016 8:59 am

+1 from me for a Tempest conversion.
Am a massive fan of the Atari vector stuff, and own several machines.
"A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams, Mostly Harmless.

paulb
Posts: 764
Joined: Mon Jan 20, 2014 9:02 pm

Re: what should i write next?

Postby paulb » Tue May 17, 2016 10:04 am

kieranhj wrote:All the Tempest info you could need: http://ionpool.net/arcade/tempest_code_project/tempest_code_project.html

This looks decidedly non-trivial: the vector display is its own custom chip with a set of opcodes & registers, there's a poorly documented "mathbox" chip to assist with the 3D calculations and then Atari's custom POKEY chips that handle all the I/O. And the code is all wrapped up in the usual accoutrements of arcade cabinets so handling coin inputs, DIP switches etc.


The hardware description suggests that the Mathbox really uses some AMD Am2900-series "bit-slice" ALU ICs. While looking around, I found this interesting implementation of the Am2901, and I wonder if MAME doesn't have some support for it.

Of course, this doesn't necessarily help with a port to the Beeb, but the architecture of the game tends to suggest that it might benefit from using a second processor, just as Elite apparently benefits from dividing the work between the CPUs.

kieranhj wrote:Someone would have to have a very intimate knowledge of both the original Tempest & the Beeb to make this work. The disassembly effort on the aforementioned website makes my Thrust effort look decidedly easy..


It would be a challenge for sure!

ThomasHarte
Posts: 327
Joined: Sat Dec 23, 2000 5:56 pm

Re: what should i write next?

Postby ThomasHarte » Tue May 17, 2016 1:34 pm

Standard comment upon any mention of Bresenham:
  • for "90–150 cycles" (i.e. I just Googled it) you can perform an 8x8 divide with remainder;
  • if you do that then you can use the Bresenham run-slice version.

i.e. if you need to draw a line that is a pixels across and b pixels down, a > b, then you need to draw b instances of a horizontal line that is either floor(a/b) or floor(a/b)+1 pixels long.

You get floor(a/b) from the divide and you have the remainder, a mod b, which is the error term (i.e. accumulate that per slice until it overflows, for that run draw at +1 length; seed your error term with half the modulus to get normal rounding).

The advantage then being that the decision step is peformed much less frequently and most of your pixel plots are parts of long runs. So you can save quite a bit if you're on a 1bpp or 2bpp graphics mode, where plotting a pixel is an involved read-modify-write process.

As the savings don't cut in until lines are sufficiently long and sufficiently flat, an ideal implementation would switch between classic Bresenham and run slice probably based on the major axis beyond a certain length and the minor then below a certain other length. Though with Tempest you've got a bunch of lines that don't change in length or position much so you could probably preassign and still do fairly well. Admittedly I'm imagining Tempest 2000 in which the camera bobs around quite a lot; I've not played it a lot but I think it's fairly static in the original? Which might even mean that all you're actually drawing for each frame is the enemies and player?

EDIT: has anybody ever put together a profiling sandbox? I'm imagining you chuck it a blob of 6502 code and a load location plus a list of tests; each test is a description of initial state plus a termination condition and a weighting; it runs through them all and gives you the weighted total cycle count. Turn it into a full unit tester if you want by adding a state test post termination, but then the scripting probably gets somewhat more complicated. But it would allow you more rapidly to get towards the optimal solution for leaf functionality like drawing a line.

User avatar
simonm
Posts: 164
Joined: Mon May 09, 2016 2:40 pm
Contact:

Re: what should i write next?

Postby simonm » Tue May 17, 2016 7:59 pm

Nice optimizations there.
mmm I enjoy the idea of a co-pro as a glorified 3d accelerator. load it up with local space model data once, update the camera rot trans matrix each frame, then have it send back transformed/view culled vert lists. Bit of double buffering and split mode, and who knows what type of 3d tricks could be had. Possibly.
3d math on an 8-bit integer cpu with 3 registers is rather involved mind.

User avatar
Arcadian
Posts: 2734
Joined: Fri Nov 24, 2000 12:16 pm
Contact:

Re: what should i write next?

Postby Arcadian » Tue May 17, 2016 8:12 pm

I remember a conversation a few years back with Guddler (Martin) who was looking at writing an authentic, Mode 0 conversion of Asteroids that utilised the 6502 co-pro ... from what I recall he definitely thought it was feasible, but no idea how much progress (if any) he made on it ...

Still, would be a very cool thing to see on the Beeb !
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk

Image
ABug Leicestershire (17-19 November 2017)

User avatar
tricky
Posts: 1823
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: what should i write next?

Postby tricky » Wed May 18, 2016 11:47 am

The extra resolution would be good, but I'm not sure about having horizontal lines twice as thick as vertical ones.

ThomasHarte
Posts: 327
Joined: Sat Dec 23, 2000 5:56 pm

Re: what should i write next?

Postby ThomasHarte » Wed May 18, 2016 3:25 pm

tricky wrote:The extra resolution would be good, but I'm not sure about having horizontal lines twice as thick as vertical ones.


Interlaced mode it is then*? You can wipe and draw the entire display in the retrace period, right?

* yes, I know, I've just written a full CRT emulation, I'm fully aware that interlacing doesn't actually change horizontal line size.

I back-of-napkinned it and figured that on a 1bpp platform without much space for code unrolling, a decision-every-pixel Bresenham implementation would probably look like:

Code: Select all

lda orMask      # 3
ora (scrAddr)      # 4
sta (scrAddr)      # 4
asl a         # 2
sta orMask      # 3
bcc +noAddrChange   # 2/3
; something, something, to subtract 8 from scrAddr, allowing for underflow
.noAddrChange
lda error      # 3
adc delta      # 3
bmi +storeDelta      # 2/3
; something, something, to decrement scrAddr, allowing for character square wrap
sbc #correctAmount   # 0/3
.storeDelta
sta delta      # 3

.. which is already 29 to 34 cycles per pixel, and I've ignored the actual hassle of addressing. Probably you could improve it a little, but bear with me.

If an 8x8 divide is at most 150 cycles and you assume that by run slicing you always spend less per pixel than by making a decision every pixel then, conservatively, I guess anything at least 10 pixels along the major axis — you spend the equivalent of the first five doing the divide, then you spend less than you would have done on the next five, giving you a saving versus 10 — and for which the minor axis is no greater than half the length of the minor (as otherwise you're almost back to making a decision per pixel anyway), the initial divide to facilitate run slicing probably pays off.

paulb
Posts: 764
Joined: Mon Jan 20, 2014 9:02 pm

Re: what should i write next?

Postby paulb » Tue Jun 07, 2016 1:07 pm

ThomasHarte wrote:
paulb wrote:
ThomasHarte wrote:Pulling the two threads together, a programmable option to shuffle the three lowest video address lines five lines to the left would have been quite helpful by opening up an optional 32-linear-bytes-per-line addressing mode. I suspect that the actual transposition of lines would actually be extraordinarily inconvenient to implement in hardware though?


I was thinking about this and surely the 256 byte jump from line to line would cause the screen memory to be spread over a huge address range. What did I miss?

That's why I was suggesting that (i) the shift be only five lines (honestly, I may have been thinking too much about the Electron here in preferring a 32-byte line; 64 is probably more BBC appropriate); and (ii) therefore that it be optional, so that 40 column, 80 column, arbitrary other column modes still work correctly. Which I think doesn't introduces leaps from line to line, at the cost of discarding most of the flexibility on line length?


OK, what I missed was that you'd have a column-oriented arrangement. Each 256-byte page holds a screen column (2 pixels in MODE 2, 4 pixels in MODEs 1 and 5, 8 pixels otherwise), and the low byte addresses a pixel row, with the high byte addressing columns.

I suppose the Electron didn't get this more sensible arrangement because the Beeb already defined the character-oriented screen layout and because compatibility with the Beeb was essential. A different question is why the Beeb did things that way in the first place.

User avatar
tricky
Posts: 1823
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: what should i write next?

Postby tricky » Tue Jun 07, 2016 4:56 pm

paulb wrote:... A different question is why the Beeb did things that way in the first place.

Because they didn't ask me 30 seconds after I got to the page on memory layout in the AUG :lol:
I believe that the 6845 has a "grid" mode, although I may have imagined this, where the "X" and "Y" wrap independently. This is how I would have set up the screen, so that vertically scrolling one line would start a MODE 2 screen at &3001 and &3000 would be in the bottom left and not the bottom right.

SarahWalker
Posts: 1038
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: what should i write next?

Postby SarahWalker » Tue Jun 07, 2016 5:08 pm

tricky wrote:
paulb wrote:... A different question is why the Beeb did things that way in the first place.

Because they didn't ask me 30 seconds after I got to the page on memory layout in the AUG :lol:
I believe that the 6845 has a "grid" mode, although I may have imagined this, where the "X" and "Y" wrap independently.

Nope, sadly not.

ThomasHarte
Posts: 327
Joined: Sat Dec 23, 2000 5:56 pm

Re: what should i write next?

Postby ThomasHarte » Fri Jun 10, 2016 12:56 pm

I think it's because, per the data sheet "[t]he CRTC provides memory addresses (MA0–MA13) to scan the refresh RAM. Row addresses (RA0–RA4) are also provided for use with character generator ROMs. In a graphics system, both the memory addresses and the row addresses would be used to scan the refresh RAM."

So in being designed to support two separate use cases — character buffer in RAM, character shapes in ROM; or just pixels, all in RAM — the CRTC hits the second case by making it strongly similar to the first.
Last edited by ThomasHarte on Fri Jun 10, 2016 2:11 pm, edited 1 time in total.

User avatar
tricky
Posts: 1823
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: what should i write next?

Postby tricky » Fri Jun 10, 2016 1:30 pm

I guess they could have added an external 8 bit adder, attached to the slow data bus to generate the Y, but that would have been more work and possibly tight on timing.

User avatar
Dethmunk
Posts: 167
Joined: Fri Jul 01, 2016 12:29 pm
Location: Guildford
Contact:

Re: what should i write next?

Postby Dethmunk » Tue Jul 05, 2016 12:32 pm

Your work is astounding Tricky. :shock:
I think if you're stuck for a game to make, if its an arcade port you're after how about a proper Gauntlet port!! :D or maybe Time Pilot (always loved that game).
As for other games how about a nice original game.... a graphic adventure game in the visual style of Legend of Zelda et al. :D
Image

User avatar
sydney
Posts: 1968
Joined: Wed May 18, 2005 9:09 am
Location: Newcastle upon Tyne

Re: what should i write next?

Postby sydney » Tue Jul 05, 2016 12:35 pm

Or maybe a nice fast mode 1 sprite plotting routine which can be easily called from basic and works on an electron!
:wink: :lol:


Return to “software: classic games”

Who is online

Users browsing this forum: No registered users and 6 guests