Trying to improve x49gp
|
10-09-2018, 03:13 PM
Post: #61
|
|||
|
|||
RE: Trying to improve x49gp
(10-05-2018 11:26 AM)3298 Wrote: I think the best way to support a NewRPL-adapted UI in x49gp would be to add variants of the existing "hp49g+" and "hp50g" models which use the same base image and the same bootcode as the existing ones, but with modified copies of the label definitions. That would actually be pretty easy: some light modifications to the existing model checks, and altered copies of the "static const x49gp_ui_key_t x49gp_ui_keys[]" and "static const x49gp_ui_key_t x50g_ui_keys[]" arrays (the difference between these is just a little bit of color - on the 49g+, the left-shift and right-shift keys have white labels, on the 50g they are black).I just did what I described in the quoted post. It seems that apart from moving STO|> and RCL from K to M, almost all modifications compared to a regular 50g are erased key labels. The remaining modifications are three additional labels above rightshift, leftshift, and alpha which explain which physical keys the simulator binds them to. You'll see some differences between the newRPL simulator and the new keyboard layouts for x49gp. These are: - The keybind hints above rightshift, leftshift, and alpha are not present. They don't match x49gp's keybinds anyway. - I assumed erasing OFF was done because it doesn't make much sense in the simulator, but x49gp supports being turned off, and the firmware surely does as well, so I kept that label. - The newRPL wiki says that the P key acts as a main menu key, so instead of erasing the SYMB label I replaced it with a MAIN label. - x49gp's label placement code centers labels for the rightshift or leftshift planes above the key if the other one is absent. I could enforce the right/left-aligned placement by using "" as label instead of NULL (like I had to do for the main labels on G, H, I, J, K, L, because the absence of a main label apparently makes x49gp assume it's dealing with a cursor key, which causes the letter label to be omitted as well), but I don't think that's necessary. - Because the K and M keys get different font sizes in x49gp, the STO|> label looks different. I had to condense it too, otherwise it would have collided with the M. There was an ancient bug in x49gp's keyboard layout handling, which caused only one of the two previously existing layouts to ever be used. The differences between the two were minimal, which explains why nobody noticed it. I spotted it in the code when I wondered how to hook up the new layouts properly - the significant differences of these to the old ones would have exposed it, because the bug kind of defeats the purpose of this patch. I'm tempted to file the peculiar behavior concerning keys without a main label under the "bug" category as well, but I didn't bother fixing that because it was so easy to work around (empty label instead of no label at all). You can get the newRPL layouts to appear by modifying the calculator type in the config file (look for a line starting with "type=" without the quotes; and make sure that x49gp is not running, otherwise exiting it will overwrite your changes). In addition to the old types "hp49g+" and "hp50g" there are "hp49g+/newrpl" and "hp50g/newrpl". Apart from the labels these types behave identically to the corresponding type without "/newrpl" suffix. As usual, my commit message: Code: Add newRPL keyboard layouts via new calculator types "hp49gp/newrpl" and "hp50g/newrpl" |
|||
10-10-2018, 02:25 PM
Post: #62
|
|||
|
|||
RE: Trying to improve x49gp
(10-09-2018 03:13 PM)3298 Wrote: Claudio: patches 34 and 35 didn't make it into your repository yet. While this one doesn't depend on those, the missing files incident convinced me that I need to do a better job at checking for desyncs between us. Also, you can probably delete qemu/qemu-0.9.0.tar.gz, because as of patch 26 (which removed the broken option to build with the older QEMU version) it's no longer used. Done, patches 34,35 and 36, as well as removal of that old file are committed to the repo. I also made a couple of changes to complement your own about the deleted labels that shouldn't have been deleted: * I changed the word "MAIN" on P with "MENU", I think it's clearer. * Added PREV.M, DEL, ABS, ARG, PRG, NUM.SLV, TIME, CONVERT, BASE, LIB, CMPLX, ARITH and ENTRY missing labels, as those keys are implemented. * I also added CUT, COPY and PASTE, as well as BEG, END, and UPDIR to the cursors. Doesn't look too great but they are all important shortcuts to remember. So go ahead, pull and rebuild. |
|||
10-10-2018, 09:21 PM
Post: #63
|
|||
|
|||
RE: Trying to improve x49gp
Perhaps the "END PASTE" could be shifted right by a pixel or three, but yes, they don't look great. At least they're there, and don't look like the 49G. Still, that's merely my opinion, to be taken with a very large container of Himalayan Pink salt. Nice work on the rework, by the way.
Would it be worthwhile adding the newrpl image to the collection, or does that change too often to be useful? I've managed to chuck everything into the one .x49gp directory, and I select between all three by feeding x49gp with a config parameter: x49gp ~/.x49gp/config-{50,49+,newrpl} etc. It was "fun" building the individual versions though, amazingly I even found a "HP-49" for my 49+ so the BIOS version comes up "correctly" though as mentioned earlier, even this can be taken with 64.79 mg of salt. (Post 305) Regards, BrickViking HP-50g |Casio fx-9750G+ |Casio fx-9750GII (SH4a) |
|||
10-10-2018, 09:50 PM
Post: #64
|
|||
|
|||
RE: Trying to improve x49gp
(10-10-2018 02:25 PM)Claudio L. Wrote: Done, patches 34,35 and 36, as well as removal of that old file are committed to the repo.Thanks! That was quick. Looks like our faithful customer brickviking is already happy. (10-10-2018 02:25 PM)Claudio L. Wrote: I also made a couple of changes to complement your own about the deleted labels that shouldn't have been deleted:See, that's the benefit of having the main newRPL developer in the loop - x49gp gets more up-to-date keyboard labels than newRPL's own simulator! (Just teasing you ... but the simulator should probably get those labels too, eventually. A cropped x49gp screenshot would do in a pinch.) The cursor key labels do indeed look a bit weird due to their collision with the edges of the inset area between the cursor keys, but maybe we could move the texts around. Especially the texts above the left and right keys get uncomfortably close to the up key. They could be shoved away by adding spaces (kind of hacky, but it works) at the right end of the left key's text and at the left end of the right key's text, and perhaps a letter could be dropped... BEG and END are already as short as they can be without making them too hard to understand, COPY could maybe lose the O (pretty much everybody understands CPY), but PASTE ? Would PSTE be understandable enough? I'm not sure. I tried changing the texts to Code: "BEG CPY " Code: " END PASTE" DEL is on the list of the labels you said were added back, but I can't find it ...? I'm assuming it should be in its old position as left-shift label of backspace, but that is still NULL. And finally, what about the CANCEL label below ON? Should that be restored as well, or does interrupting a program work different enough on newRPL that it's better to leave it out? (You can probably tell I never got around to testing newRPL myself.) |
|||
10-11-2018, 02:43 AM
Post: #65
|
|||
|
|||
RE: Trying to improve x49gp
(10-10-2018 09:50 PM)3298 Wrote: See, that's the benefit of having the main newRPL developer in the loop - x49gp gets more up-to-date keyboard labels than newRPL's own simulator! (Just teasing you ... but the simulator should probably get those labels too, eventually. A cropped x49gp screenshot would do in a pinch.) My bad, and I did it on purpose. I understood from you previous posts that if one string was NULL the next one wasn't going to be displayed, so I changed to "" all NULLs to the left of any nonempty label. (10-10-2018 09:50 PM)3298 Wrote: DEL is on the list of the labels you said were added back, but I can't find it ...? I'm assuming it should be in its old position as left-shift label of backspace, but that is still NULL.I added it, not sure where but I did... Yes it's supposed to go in the usual place (10-10-2018 09:50 PM)3298 Wrote: And finally, what about the CANCEL label below ON? Should that be restored as well, or does interrupting a program work different enough on newRPL that it's better to leave it out? (You can probably tell I never got around to testing newRPL myself.) Nope, we can leave Cancel out. In newRPL you need to do On-A-C to stop a program, and it will ask for confirmation. I always got annoyed when my programs got interrupted accidentally, so I made it more involved "by design". By the way, it's about time you try newRPL, either on-calc, on a PC with x49gp, PC with newRPL Desktop, or now on Android. I don't think you have any valid excuse not to. |
|||
11-12-2021, 12:08 PM
Post: #66
|
|||
|
|||
RE: Trying to improve x49gp
Hi all. I know this is a rather old thread, but I can't find a better place to post this.
I'm trying to compile x49gp under Linux Mint 20.2 x64 but to no avail. I followed each and every instruction on several git repositories (official and forks) but the thing still throws errors and refuses to compile. Even the svn repositories had to be renamed because the ones stated in the instructions do not work apparently due to SVN URL convention changes. The repos I have tried so far: svn co https://svn.code.sf.net/p/x49gp/code x49gp svn co https://github.com/chwdt/x49gp.git x49gp git clone https://github.com/chwdt/x49gp.git git clone https://github.com/datajerk/x49gp.git and the installed libraries and dep packages: sudo apt-get install libgtk2.0-dev Any help would be appreciated. (btw, it would be so useful to have this as a binary package somewhere) Thanks in advance. |
|||
11-12-2021, 09:39 PM
Post: #67
|
|||
|
|||
RE: Trying to improve x49gp
(11-12-2021 12:08 PM)Helix751 Wrote: Hi all. I know this is a rather old thread, but I can't find a better place to post this. Try my repo: https://github.com/claudiobsd/x49gp it has many fixes by 3298 (see above in this thread), so it's a bit ahead of Chris's repo, since he never pulled those changes. If you give more specifics on the errors we can help you better. |
|||
11-13-2021, 12:12 AM
Post: #68
|
|||
|
|||
RE: Trying to improve x49gp
As Claudio said, his branch is more up-to-date than the ones you listed.
Regarding the errors, I haven't needed to recompile x49gp in ages because I didn't make changes, and nobody else did either ... but prompted by your request, I did so just now, and indeed there are some errors. All of them are just warnings promoted to errors by the -Werror flag, so the quick fix would be to get rid of that, or at least put in exemptions for the warnings that do occur. Those I saw are: - A whole bunch of array-bounds in qemu/qemu-git/tcg/x86_64/tcg-target.c. Those may or may not be valid, I'm not familiar enough with QEMU's guts to tell. That said, x49gp uses an ancient stripped-down version of QEMU, so a bit of breakage every now and then stemming from compiler updates is annoying but kind of expected. - A pair of stringop-overflow in block-vvfat.c (which is also from QEMU, despite not being in that subdirectory). Same commentary applies. - A pair of deprecated-declarations in /usr/include/gtk-2.0/gtk/gtktoolitem.h (yes, that's a system header; it's used in a number of x49gp source files) because the latest version of GTK2 declares some types as deprecated and then goes on to use them in function declarations. Silly GTK2, that will never work with -Werror - I can call that a GTK2 bug, right? The last one can only be worked around (and that most likely has to be done in all GTK2 applications compiling with -Werror now, not just x49gp). The first two should be investigated and eventually fixed properly. Nevertheless, here's a quick fix via exemptions from -Werror. The warnings will still show up, but at least it will finish compiling. Code: diff --git a/Makefile b/Makefile Code: patch -p1 -i <filename-you-saved-it-to> --- As for distributing binaries: I can only speak for myself (other people could build it and distribute the results themselves, after all), but I've refrained from providing binaries so far for a number of reasons: - I can provide a package for Arch Linux relatively easily, but that opens the door to people asking for Debian/Ubuntu, Fedora, BSD, MacOS, etc. packages which range from much harder to impossible with what I have. Not providing any is at least consistent. - x49gp is derived from a modified ancient QEMU which is licensed under GPL, which means x49gp has to be GPL-licensed (or compatible) as well. It's not quite there, unfortunately. The most important part of GPL compliance is providing the source of course, which is trivial if the source is the only form it's distributed in ... but we should be declaring explicitly which license x49gp uses (which isn't as easy as it sounds, because not all contributors can be contacted anymore to ask whether they are okay with a particular license), and we shouldn't be bundling source-less calculator firmware with it. Aside from enforcing compliance with the GPL requirement for providing sources on request, avoiding binary distribution somewhat mitigates these legal headaches by helping keep a low profile. - Speaking about bundling firmware, while some of my changes published in this thread (and subsequently committed into Claudio's repository) were aimed at eliminating the firmware from x49gp to insulate against license issues, there's still the bootcode left. At least those changes moving the firmware choice from the build process to a first-launch setup was a step in the right direction, because that means a user could just pick the newRPL firmware and get a usable emulator without HP firmware other than bootcode. Still, by bundling the bootcode (and firmware in the repository - mostly for convenience now, after those changes) HP could pound on its copyright on that data. Our only defense would be that strictly speaking they should have been aware of x49gp for a long time via HP employee Tim Wessman's past contributions, and still have not objected, thereby silently permitting us to keep distributing them. Keeping a low profile helps there too. |
|||
11-15-2021, 10:46 PM
Post: #69
|
|||
|
|||
RE: Trying to improve x49gp
(11-12-2021 09:39 PM)Claudio L. Wrote: Try my repo: Thanks for replying. Running Linux Mint 20.2 (Ubunto 20.04). I downloaded your repo sources with: Code: ~$ git clone https://github.com/claudiobsd/x49gp and tried compiling (plain 'make'), but here's the output and errors shown: Code: ( cd qemu/qemu-git; \ |
|||
11-15-2021, 10:54 PM
Post: #70
|
|||
|
|||
RE: Trying to improve x49gp
(11-13-2021 12:12 AM)3298 Wrote: As Claudio said, his branch is more up-to-date than the ones you listed. I DEFINITELY LOVE YOU (grin) It actually worked. Thanks a million! This post should be pinned, as it's a working solution for newer Linux installations. Thanks again. Now enjoying both my physical HP50G and my newest Linux one. Cheers. |
|||
11-17-2021, 08:27 PM
Post: #71
|
|||
|
|||
RE: Trying to improve x49gp
After getting the program successfuly compiled and running, I wonder if the prgm actually has an icon resource?
'make install' does install it in the appropriate binaries folder and the prgm appears in the menu as well, but with a blank icon, the same one that appears in the task bar when running the instance.. Thanks and regards. |
|||
11-17-2021, 09:17 PM
Post: #72
|
|||
|
|||
RE: Trying to improve x49gp
You're not missing anything, there is no icon.
Feel free to contribute one, though, if you feel like you're up to that kind of challenge. |
|||
11-17-2021, 09:22 PM
Post: #73
|
|||
|
|||
RE: Trying to improve x49gp
(11-13-2021 12:12 AM)3298 Wrote: - I can provide a package for Arch Linux relatively easily, but that opens the door to people asking for Debian/Ubuntu, Fedora, BSD, MacOS, etc. packages which range from much harder to impossible with what I have. Not providing any is at least consistent. I think there's no doubt the license of x49gp cannot be anything other than GPL because of being a derivative work of QEMU. All contributors knew this when they worked on the project, so I don't see why you would need to contact them one by one. Everybody knows that contributing to a GPL project means their contribution will be released under the GPL. Source code is available in multiple places, all you'd need to do is perhaps add a URL to any of the github repos to comply with the GPL. I don't think the license requires you to include the sources in the distribution, but for you to make the source code available, which is a different thing. Pointing to a github repository should suffice (I think, I'm not a lawyer). Otherwise all Linux packages would have to be distributed with full sources. Instead, the package tells you where the sources that were used for the build are located, and you are on your own after that. (11-13-2021 12:12 AM)3298 Wrote: - Speaking about bundling firmware, while some of my changes published in this thread (and subsequently committed into Claudio's repository) were aimed at eliminating the firmware from x49gp to insulate against license issues, there's still the bootcode left. At least those changes moving the firmware choice from the build process to a first-launch setup was a step in the right direction, because that means a user could just pick the newRPL firmware and get a usable emulator without HP firmware other than bootcode. Still, by bundling the bootcode (and firmware in the repository - mostly for convenience now, after those changes) HP could pound on its copyright on that data. Our only defense would be that strictly speaking they should have been aware of x49gp for a long time via HP employee Tim Wessman's past contributions, and still have not objected, thereby silently permitting us to keep distributing them. Keeping a low profile helps there too. As far as the binaries... they should be removed from the repository. Then perhaps create a script that would download the formal HP ROM zip files from hpcalc.org, extract the actual rom files and cleanup. That leaves only the boot code... that should be moved away to some obscure repository. Maybe not obscure, perhaps a .zip file uploaded to hpcalc.org with the boot code for all supported calcs, then the user can go and download it by hand (or a script provided that does it during install). I believe hpcalc.org has authorization to host binary files copyrighted by HP, so no issue there. |
|||
11-17-2021, 09:52 PM
Post: #74
|
|||
|
|||
RE: Trying to improve x49gp
@Claudio I've created a pull request for you on github with some gcc flags I have to set to successfully compile x49gp. It also adds DESTDIR in the Makefile because I make a (Slackware) package and this makes it easier.
Concerning packaging, the script I made (for personal use) is visible @ SlackBuild. Even if you're not familiar with Slackware it should be straightforward to understand and might be of interest because I do pull the ROM (2.15) and documentation from HPCalc and newRPL rom from sourceforge in the package to have a self-sufficient batteries-included package. "My" emulators: x50ng & more |
|||
11-17-2021, 11:02 PM
Post: #75
|
|||
|
|||
RE: Trying to improve x49gp
(11-17-2021 09:52 PM)gwh Wrote: It also adds DESTDIR in the Makefile because I make a (Slackware) package and this makes it easier.Uhh, so where's the problem this is supposed to solve that isn't already solved by overriding INSTALL_PREFIX (see the Arch PKGBUILD I attached to an earlier post in this thread)? In short, I run make all with INSTALL_PREFIX set to where it's supposed to be installed eventually (so the handful of directory references compiled into the binary are correct), then make install with INSTALL_PREFIX set to the equivalent directory inside the one that gets compressed into a package by the packaging utility. That's the kind of process I've seen in packaging other software, and therefore the process I designed the INSTALL_PREFIX variable for when I implemented the install target. |
|||
11-17-2021, 11:47 PM
Post: #76
|
|||
|
|||
RE: Trying to improve x49gp
(11-17-2021 09:22 PM)Claudio L. Wrote: I think there's no doubt the license of x49gp cannot be anything other than GPL because of being a derivative work of QEMU.I'm not a lawyer either, but as far as I remember one of the big changes between GPL v2 and v3 was adding many other licenses to a list of those GPL considers "compatible" (which some projects even cited as a reason to stay v2-only instead of v2-or-newer). As far as I can tell, the existence of this list gives us some wiggle room to choose a one of them for those parts that aren't directly QEMU pieces. In that light contacting the contributors who constitute "us" for clarification may or may not be needed, but doing so would definitely be the safe option. (11-17-2021 09:22 PM)Claudio L. Wrote: Source code is available in multiple places, all you'd need to do is perhaps add a URL to any of the github repos to comply with the GPL. I don't think the license requires you to include the sources in the distribution, but for you to make the source code available, which is a different thing. Pointing to a github repository should suffice (I think, I'm not a lawyer). Otherwise all Linux packages would have to be distributed with full sources. Instead, the package tells you where the sources that were used for the build are located, and you are on your own after that.Oh, I know that. But I also know what people do with binary packages, and that distressingly often omits the linking to source part. Look no further than x49gp itself, particularly the list of forks on GitHub ... last time I checked (anonymously of course; my stance on their terms and conditions hasn't changed for the better since Microsoft took over), the twenty or so newest commits were from a particularly dumb user who forked your repository, then started removing all the files over many commits (one by one at first, then in batches), then added a binary package and a fresh readme, and changed both of these many times in quick succession. Aside from the disgusting misuse of git as a version control system, this idiot didn't deign to tell others what sources the binaries were produced from. Sure, the commit history kind of retained the source files, but which revision(s?) were the binaries produced from, and were there custom patches? Nobody knows. If x49gp already has such an example in its current state, I don't even want to imagine what nonsense people would do if binary packages were pre-made. Given the average human stupidity, it probably won't get better down that path, only worse. (11-17-2021 09:22 PM)Claudio L. Wrote: As far as the binaries... they should be removed from the repository. Then perhaps create a script that would download the formal HP ROM zip files from hpcalc.org, extract the actual rom files and cleanup.Hey, quarantining HP firmware and bootcode to hpcalc.org and pulling it in during build or installation is a pretty great idea. Eric Rechlin indeed has HP authorization to host the firmware, though I'm not sure if that covers the bootcode too. He currently doesn't offer that for download at least (apart from a copy of x49gp, but that doesn't count). |
|||
11-18-2021, 05:40 AM
Post: #77
|
|||
|
|||
RE: Trying to improve x49gp
(11-17-2021 11:02 PM)3298 Wrote:(11-17-2021 09:52 PM)gwh Wrote: It also adds DESTDIR in the Makefile because I make a (Slackware) package and this makes it easier.Uhh, so where's the problem this is supposed to solve that isn't already solved by overriding INSTALL_PREFIX (see the Arch PKGBUILD I attached to an earlier post in this thread)? Not a problem per se. I missed your PKGBUILD posted earlier. In my opinion (and really I'm just splitting hair and rationalizing), what I came to understand packaging sources is that INSTALL_PREFIX defines where is the target filesystem the files should be installed. DESTDIR is a temporary prefix added only during the make install phase. It's not used anywhere else, whereas I've seen software where INSTALL_PREFIX (or more precisely PREFIX) was significant during compilation and overriding it during make install broke something. Nothing wrong in this case with your approach but it could cause problems with different software and the convention I internalized regarding Makefiles is more along the lines of Code:
Code:
"My" emulators: x50ng & more |
|||
11-18-2021, 06:41 PM
Post: #78
|
|||
|
|||
RE: Trying to improve x49gp
(11-17-2021 11:47 PM)3298 Wrote: I'm not a lawyer either, but as far as I remember one of the big changes between GPL v2 and v3 was adding many other licenses to a list of those GPL considers "compatible" (which some projects even cited as a reason to stay v2-only instead of v2-or-newer). As far as I can tell, the existence of this list gives us some wiggle room to choose a one of them for those parts that aren't directly QEMU pieces. In that light contacting the contributors who constitute "us" for clarification may or may not be needed, but doing so would definitely be the safe option.Mmmm... I understood it in a completely different way. The way I understood it is that a license being "compatible" means that source code under that license can be included in a GPL project. GPL being the main license covering the entire project, swallowing the other license. Anyone modifying the code that's under the other license as part of the GPL project would still have to release the changes in compliance with the GPL license, even if those files were originally BSD licensed for example that doesn't require that. In other words, the GPL attaches on top of the other license and imposes its restrictions. The other way around doesn't work: any work derived from any GPL'd source becomes GPL'd. You can't derive work from a GPL'd project and place it under a different license, even if it's compatible, the new work becomes GPL. (11-17-2021 11:47 PM)3298 Wrote: Oh, I know that. But I also know what people do with binary packages, and that distressingly often omits the linking to source part. Look no further than x49gp itself, particularly the list of forks on GitHub ... last time I checked (anonymously of course; my stance on their terms and conditions hasn't changed for the better since Microsoft took over), the twenty or so newest commits were from a particularly dumb user who forked your repository, then started removing all the files over many commits (one by one at first, then in batches), then added a binary package and a fresh readme, and changed both of these many times in quick succession.Hahaha! and I had to go and look for myself... I think that guy just wants to build his resume, so he forked some 400 projects, adds hundreds of bogus commits like the ones you saw, then he can put in his resume something like "more than 3500 commits contributed to over 400 open source projects". (11-17-2021 11:47 PM)3298 Wrote: ... I think we can submit it to Eric's and see if he approves it. I'd say all binaries are probably OK on his website at this point, since they are long discontinued products. |
|||
11-18-2021, 07:16 PM
Post: #79
|
|||
|
|||
RE: Trying to improve x49gp
(11-18-2021 06:41 PM)Claudio L. Wrote: I think we can submit it to Eric's and see if he approves it. I'd say all binaries are probably OK on his website at this point, since they are long discontinued products. Yeah, I'll approve it. I was planning to do an update in the next week or so anyway. How did you get the binary in the first place? Extracted it from a calculator? And yes, HP sent me a lot of this stuff specifically to add to my site in the first place. I'm sure this is in the spirit of what they already provided. |
|||
11-18-2021, 08:23 PM
Post: #80
|
|||
|
|||
RE: Trying to improve x49gp
(11-17-2021 11:02 PM)3298 Wrote:(11-17-2021 09:52 PM)gwh Wrote: It also adds DESTDIR in the Makefile because I make a (Slackware) package and this makes it easier.Uhh, so where's the problem this is supposed to solve that isn't already solved by overriding INSTALL_PREFIX (see the Arch PKGBUILD I attached to an earlier post in this thread)? The point is that DESTDIR is not where the files would eventually end up when installing the package. It points to a temporary staging directory used to construct a binary package from the "installed" files without actually installing them in the live system for real. Combined with the fakeroot command, it allows for building binary packages in an environment that appears to have root privileges without the builder actually having root privileges. See DESTDIR: Support for Staged Installs for DESTDIR's use in GNU coding standards. — Ian Abbott |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 3 Guest(s)