Jump to content
IGNORED

Li'l Bro ii - A better Unisonic Champion simulator for the Intellivision


decle

Recommended Posts

Happy New Year fellow VBLANK warriors.

As you might be aware 2018 is the 40th anniversary of the release of the Intellivision's little brother, the Unisonic Champion 2711. To celebrate I have tidied up Li'l Bro and added the four cartridges originally released by Unisonic:

 

 


Inside each game archive you will find three ROM images, suitable for JzIntv. These contain the Intellivision version of a single cartridge for use with and without the ECS and a musoCheat.rom containing just the in game ragtime music. In addtion, there is a JzIntv keyboard hack file, an overlay image, game instructions and box art:

 

 

Blackjack & Baccarat - Blackjack is the pack-in, just like the Intellivision

post-46336-0-16338500-1514799054.gif
lilBroBlackjackBaccarat.zip

 

 

PAC-02 Poker Games - 1978, no shifty eyed dealer yet
post-46336-0-84178900-1514799055.gif

lilBroPoker.zip

 

 

PAC-03 Family Fun - Mastermind clone and a variant of Backgammon
post-46336-0-89438800-1514799054.gif
lilBroFamilyFun.zip

 

 

PAC-04 Family Cards - Cards with no gambling

post-46336-0-12661300-1515690724.gif

lilBroFamilyCards.zip

 

 

PAC-05 Arithmetic Primer - Is there no system without Math Fun?

post-46336-0-20708200-1515690723.gif

lilBroArithmeticPrimer.zip

 

 

PAC-06 Bottom Gas - the first new game for the Unisonic Champion in 40 years is a port of Activision's Atari 2600 Dragster.

post-46336-0-25825000-1522993528.gif

bottomGas.zip

 

 

PAC-07 Hangman - a recreation of the unreleased game detailed in the General Instrument data sheet:

image.gif.8e6defb57ce5004b4d2f841a1be20703.gif

hangman.zip

 

 

PAC-08 Battleship - a recreation of the unreleased game detailed in the General Instrument data sheet:

battleship.gif.5d703f6040e3605f08fb1f57a72accae.gif

battleship.zip

 

 

Under the hood Li'l Bro is still a simulation of the Champion, rather than an emulation. However, the new version has been completely rewritten. This time rather than manually porting the games, as was done in 2016, the core of each Li'l Bro ii game is constructed automatically using static binary translation. A Perl script has been constructed that reads each Unisonic Champion cartridge image and generates the assembly source code of an equivalent Intellivision game. The simple, atomic instructions for doing things like writing to the screen on the Unisonic have been replaced with subroutine calls on the Intellivision. In practice, wrinkles such as indirect addressing make this a little more complicated than it might at first seem. The converted game source code has been integrated into a framework for Li'l Bro and assembled. The result is about three times larger and slightly slower than the original version of Li'l Bro. However, it does have the winning feature of not being mind-numbingly boring and time consuming to convert games.

Anyway, 'enjoy' playing the games of the Intellivision's little brother and remember to look back for some interesting updates. :)

As always, all feedback, good, bad and indifferent is most welcome.

Cheers

decle

 

Edited by decle
  • Like 9
Link to comment
Share on other sites

Nice work automating the conversion!

 

I'd still call these "ports". I understand parts have to be rewritten because of different graphics systems; and you pointed out problems with addressing. But I'm assuming the core gameplay is made up of the same instructions that have been ported after binary translation. People use the term "simulation" differently; to me simulation and emulation have become synonymous.

Edited by mr_me
  • Like 1
Link to comment
Share on other sites

Nice work automating the conversion!

 

I'd still call these "ports". I understand parts have to be rewritten because of different graphics systems; and you pointed out problems with addressing. But I'm assuming the core gameplay is made up of the same instructions that have been ported after binary translation. People use the term "simulation" differently; to me simulation and emulation have become synonymous.

 

In popular use, they're all misnomers, although they can be useful when used consistently with the same meaning. For instance, I understood precisely what decle meant by "simulation, not emulation," even though an English Professor would cringe at it.

Link to comment
Share on other sites

The way I keep those two words apart:

 

Simulation: A process or program that mimics another process, so on the outside it looks like it works the same way, though on the inside it could be very much different. As long as you play nice and not try to poke yourself through the "shell", your simulator will do what it advertises.

 

Emulation: A process or program that duplicates another process, to the smallest internal detail possible. Even if you poke into it, you will find that it behaves just like the original process, though sometimes you will find anomalies which is why emulator developers keep improving the programs and they use more and more computing power on the host machine in order to cover all bases.

 

In this case, I would definitely call it a simulator as the programs are recompiled. If you could run the exact original binaries, it would get closer to an emulator.

Link to comment
Share on other sites

  • 2 weeks later...

"backgammon" cool i didn't noticed this the first time.

i like this game, even when i'm a noob compared to my ex wife (a maghrib, a little berber, i mean a marrocain).

she plays 3 times faster and cheats whenever you are unattentive.

 

fortunately the machine can't cheat.

Link to comment
Share on other sites

  • 2 weeks later...

Hey guys,

I'm going to switch to updating the Li'l Bro programming thread because things are going to get a bit geeky from here on in :roll:

Having spent a little time now developing specifically for the Unisonic Champion, mainly in putting together the Bottom Gas port of Atari Dragster (see top of thread), I have been wondering whether General Instrument and Unisonic could have made some different decisions. Perhaps even ones that might have led to the Champion being a viable system, whilst still remaining the cheaper, little brother to the Intellivision. I thought that Li'l Bro, and specifically Bottom Gas, might provide an opportunity to explore this idea. It might also be possible to highlight some things regarding the nature of a system's identity, something I touched on in last year's the discusson of the IntellXpander.

Firstly, if you want to know more about why the Unisonic Champion is the Intellivision's little brother and why it is so rubbish you can find a brief(ish) summary in this post. Now, let's establish a baseline. Below is a simplified version of Li'l Bro, with no title screen or in game music, running the 1 / 2 player version of Bottom Gas. I've provided the ROM to run in JzIntv like the other versions of Li'l Bro. The Unisonic equivalent of this code is 2043 decles long.

post-46336-0-72357300-1516898439.gif
lilBroBottomGasBaseline.rom

As has already been highlighted, Li'l Bro does not properly represent the Unisonic's graphics, primarily because the character spacing is not correct:

post-46336-0-60147800-1515694770.png MAME / Unisonic

post-46336-0-11167000-1515691655.png JZIntv / Li'l Bro

This is interesting as I don't think the discrepancy is really noticeable without the two images side by side. The font and colour palette are strong enough drivers of the system's look to overcome this small inaccuracy.

Anyway, what could GI and Unisonic have done differently?

As Bottom Gas shows, it is possible to create a reasonable core action game mechanic, despite the CPU and memory limitations of the Gimini Mid-Range System design. So, lets start by tarting up the graphics a bit.

Clearly the left / right screen split is totally insane. So, let's sort out a more sensible screen mode. Initially this will replace the old one, but there is no reason that it could not be implemented in addition to the existing brain dead version.

Given the hypothesis that the font and palette are important to the system's identity, let's leave them alone, at least for the moment.

The existing screen mode uses 150 bytes of 8 bit BACKTAB RAM. If our new mode is 15x10 tiles it will use the same amount of memory and allow a single pane layout. This might seem like a rather small screen, however, it is only marginally smaller than the Intellivision appears on a PAL TV.

Because the standard font only uses 6 bits (64 characters), we could then use the top two bits of each BACKTAB entry to specify the foreground colour of the character. Finally, we could allow the selection of the background colour for the whole screen from one of the four standard hues by writing to the upper 2 bits of the sound register at $96.

So, what difference might these changes make to a Unisonic Dragster implementation (again there is a ROM below)?

post-46336-0-61845000-1516899431.gif

lilBroBottomGasUp1.rom

I think you will agree, it is quite a change. The first thing to note is that I don't believe the result feels like a Unisonic Champion game any more. It does not look like an Intellivision game to me either, just something "different". I think this is because of the shift away from the predominantly white on green palette, rather than the other changes in the video mode.

The resulting mode is definitely easier to program for, and supports a wider range of content more naturally. The main cost is the loss of resolution (for example the "press tap to stage" message no longer fits on the screen). We also lose the ability to draw the special double height card characters, as the background must now be a single colour.

Clearly, implementing these changes would have been exclusively within the remit of General Instrument. It is not obvious to me that a single pane GIC would have been any more difficult to implement than the split screen one. Therefore, I don't believe that the system would have cost significantly more or less to produce than the actual design.

The full set of changes to this version of Bottom Gas are:

  • Colours! - in addition to the obvious, the tacho changes colour at higher revs and the blown engine is highlighted with colour. Obviously the palette in use would mean that every game ends up looking a bit like the Italian flag ;)
  • Greater dragster movement - The split screen mode prevented the dragsters moving more than 4 characters from the left of the screen. This is because the rear wheels could not be shown at the correct vertical position on the right hand pane. This restriction is removed with the single pane mode.
  • Limited resolution - Most obviously seen in the tacho, which now only has 7 characters rather than 11. This makes playing the game slightly harder as the revs display is not as granular.
  • Simplified programming model - The single pane mode has saved enough space to allow the inclusion of the title marquee while still reducing the size of the Unisonic implementation to 1944 decles.

What do you think? Better, worse or just different?

I'm intending to look to upgrade the sound and controls next, stay tuned...

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

The thing is, looking through the Mattel contracts for the Intellivision, it's hard to imagine making a chip between the GIC and STIC in capability made an iota of sense, unless somehow Mattel had an exclusive lock on the STIC. The individual chips were not that costly.

 

In 1981, Mattel was paying $27.25 for the first 100K units, with the price declining to $23.50 once they crossed 300K units.

 

post-14113-0-95464600-1518501830_thumb.png

 

I can't find them right now, but I seem to recall the STIC itself was on the order of $2.50 in volume, with a similar price for the RA-3-9600.

 

This document, though, shows what development costs were like in 1978. Reading through this, it sounds like there was still a lot of risk around actually getting the STIC to work.

  • Like 3
Link to comment
Share on other sites

How much did the Unisonic cost, what was its immediate competition? I mean if it still would fall flat, worse than the Studio 2 in squares, it didn't need to be any better because only clueless grandmothers would buy it anyway.

 

According to this page, its target price was $150 with 4 built in games, and $20/cartridge. It was basically about half the price of the Intellivision across the board.

  • Like 1
Link to comment
Share on other sites

Simulation: A process or program that mimics another process, so on the outside it looks like it works the same way, though on the inside it could be very much different. As long as you play nice and not try to poke yourself through the "shell", your simulator will do what it advertises.

 

Emulation: A process or program that duplicates another process, to the smallest internal detail possible. Even if you poke into it, you will find that it behaves just like the original process, though sometimes you will find anomalies which is why emulator developers keep improving the programs and they use more and more computing power on the host machine in order to cover all bases.

 

 

When I hired into Texas Instruments, "emulator" referred to in-circuit emulation. Back when the term was first coined, it meant reimplementing the chip in discrete logic, so you could directly examine its internal state. Later, that morphed into using JTAG to control and examine the state of a special "emulator" version of a chip. Later still, it just referred to using JTAG to examine and control a production version of the chip, all in-circuit.

 

It also referred to using huge boxes such as Quickturn (now Palladium) or ZeBu for emulating silicon designs in FPGAs and/or specialized logic.

 

If you modeled hardware in software, it was a simulator, whether it was gate-level simulation or high-level simulation.

 

This Unisonic simulator falls under the umbrella of "static binary translation," really. It's neither emulation nor simulation. You're directly executing a translation of the original binary code to a new binary form. It doesn't matter that the instruction set is the same. (See HP's Dynamo for an example. It performed dynamic optimization, reading PA-RISC and writing PA-RISC, with optimization. But it started life as a dynamic binary translator, as I understand it.)

Edited by intvnut
Link to comment
Share on other sites

So the market at the end of 1977 would look something like this:

 

Bally Astrocade: $300 (launched in Oct 1977)

Atari VCS/2600: $200 (launched in Sep 1977)

Unisonic Champion 2711: $150, games $20 each (brand new)

RCA Studio II: ?? (launched in Jan 1977 at $150)

Fairchild Channel F: ?? (launched in Nov 1976 at $170)
A few systems not yet on the market:
APF MP-1000: $130 (launched in Dec 1978?)
1292 APVS family: $130-ish (launched in 1978? sometimes claimed to be ahead of the Channel F but I think that myth is debunked)
Odyssey^2: $199 (launched in Dec 1978)

That is only counting cartridge ROM based systems. Sure, the Unisonic is superior to the Studio II and at least is better at displaying text than the Channel F. I understand that the Atari VCS struggled in the beginning when all it had were rather simple games and it had a bunch of technical problems to solve, so perhaps there still was a little room on the market for a $150 system, before the class of 1978 arrived.

  • Like 1
Link to comment
Share on other sites

Apologies for the delay in an update, a bit of flu has slowed things down.

According to this page, its target price was $150 with 4 built in games, and $20/cartridge. It was basically about half the price of the Intellivision across the board.


Here is the article from Popular Mechanics referenced in the Unisonic FAQ that gives the Unisonic's pricing

So the market at the end of 1977 would look something like this:


It contains a brief review of the market and consoles of the time which confirms much of what Carlsson has noted.

In other news Gernot has uncovered a bug in the original Unisonic source of Arithmetic Primer (I know, given how brilliant it is and the number of people who must be sat glued to it all day it is surprising it went unnoticed this long ;)). Kudos for finding it Gernot!

The bug causes the game to randomly crash when setting up problems or one of the four multiple choice answers. It is caused by the not very random number generator and can be seen in at least the Easy / Addition only game. I am reasonably confident it is a bug in the Unisonic source, rather than the Li'l Bro conversion, as it can be replicated on MAME with the unichamp driver. The bug is relatively uncommon, something like 1 in 100 problems (perhaps 1 in 256?) will trigger it. Like the Intellivision the RNG in Arithmetic Primer chooses a rundom number and then throws it away if it is outside the desired range. Unfortunately under some circumstances the random number generator will fall into a sequence that will never result in a value between 0 and 9, and everything stops.

In investigating this bug I have also noticed a couple of other things about Arithmetic Primer:

  • The number of games is stored in an 8 bit value, and therefore, rolls over at 255, but does not crash. When it does so, it also resets your number of correct answers to 0 :mad:
  • The random number generator can be very not random. In both JzIntv / Li'l Bro and MAME / unichamp, if you sit and hold YES, answering each question with the first option, you very quickly get into a repeating cycle of 10 questions, only one of which you get the right answer for. This is very similar to the way in which World Championship Baseball consolidates on a relatively small number of actual games, as described here. Unfortunately in Arithmetic Primer this cycle does not stimulate the bug, so you have to enter different answers to get it to show:
    • 8 + 9 = (right answer)
    • 9 + 9 = (wrong answer)
    • 5 + 4 = (wrong answer)
    • 2 + 4 = (wrong answer)
    • 5 + 3 = (wrong answer)
    • 4 + 1 = (wrong answer)
    • 0 + 3 = (wrong answer)
    • 7 + 0 = (wrong answer)
    • 9 + 2 = (wrong answer)
    • 2 + 9 = (wrong answer)

All very interesting. Much more so than the game itself.

 

Hopefully some Unisonic Champion sound updates will be ready soon...

 

 

decle

Edited by decle
  • Like 1
Link to comment
Share on other sites

Thanks for the link. It means the APF MP-1000 was already out by then, a full year earlier than I had anticipated though $50 higher than in my prediction. I would think the Channel F would have dropped in price in a year and possibly the Studio II but since Popular Mechanics had obtained the RRP from manufacturers, I suppose the prices still stood although some retailers perhaps sold them for less. The price per game seems to be the same all over the line. The magazine doesn't seem to have done much of a comparison between the systems, which they thought offered the best value for money.

Link to comment
Share on other sites

In the world of technology, often it seems capacity is counted above release date. For instance, few people would consider the VIC-20 to be the big brother to the C64, and likewise the ZX-81 isn't referred to as the big brother to the ZX Spectrum. The same can go on about other brands, how are the Atari 2600, 5200 and 7800 related? The latter even runs 2600 games, whether it makes it a big or little brother (or sister?) of the 2600. In cases where both systems are equally mainstream and popular, I don't think people are thinking in such terms, e.g. if the NES is the big or little brother to the SNES or if they just come from the same family.

 

Also what is the Aquarius to the Intellivision - adopted stepchild?

Edited by carlsson
  • Like 1
Link to comment
Share on other sites

In other news Gernot has uncovered a bug in the original Unisonic source of Arithmetic Primer (I know, given how brilliant it is and the number of people who must be sat glued to it all day it is surprising it went unnoticed this long ;)). Kudos for finding it Gernot!

 

The bug causes the game to randomly crash when setting up problems or one of the four multiple choice answers. It is caused by the not very random number generator and can be seen in at least the Easy / Addition only game. I am reasonably confident it is a bug in the Unisonic source, rather than the Li'l Bro conversion, as it can be replicated on MAME with the unichamp driver. The bug is relatively uncommon, something like 1 in 100 problems (perhaps 1 in 256?) will trigger it. Like the Intellivision the RNG in Arithmetic Primer chooses a random number and then throws it away if it is outside the desired range. Unfortunately under some circumstances the random number generator will fall into a sequence that will never result in a value between 0 and 9, and everything stops.

 

It's good to know I'm not going insane. While chasing down the other issues, I did see Arithmetic Primer hang once while displaying possible answers to a problem. I went to go halt the game in the debugger, but was confounded by "any action button resets the machine." I couldn't reproduce it, though, but then I didn't try very hard as I was focused on the sound glitch.

 

As for the Intellivision's RNG and the limited number of WC Baseball games: Keep in mind in normal circumstances the RNG gains some environmental entropy as the game runs, so in normal circumstances, you have more entropy to work with than the 16-bit seed. In fact, your WC Baseball journey led me to tighten up jzIntv's emulation in a number of ways so that I didn't cause inadvertent emulation environment details to leak in and perturb the RNG. That's perhaps an important difference between the Intellivision's RNG and Unisonic's. (I haven't looked at Unisonic's.)

 

Intellivision's RNG is mathematically sound and produces a maximal period sequence. The fact it leads to a small-ish number of game outcomes in your WC Baseball exploration probably has more to do with the insensitivity of the game mechanics to some of the random numbers, and the fact that the only entropy source was the seed. The game mechanics have an "attractor" to certain outcomes.

 

Have you isolated the RNG in the Unisonic code?

Edited by intvnut
  • Like 1
Link to comment
Share on other sites

It's good to know I'm not going insane. While chasing down the other issues, I did see Arithmetic Primer hang once while displaying possible answers to a problem. I went to go halt the game in the debugger, but was confounded by "any action button resets the machine." I couldn't reproduce it, though, but then I didn't try very hard as I was focused on the sound glitch.

:)

 

As for the Intellivision's RNG and the limited number of WC Baseball games: Keep in mind in normal circumstances the RNG gains some environmental entropy as the game runs, so in normal circumstances, you have more entropy to work with than the 16-bit seed. In fact, your WC Baseball journey led me to tighten up jzIntv's emulation in a number of ways so that I didn't cause inadvertent emulation environment details to leak in and perturb the RNG. That's perhaps an important difference between the Intellivision's RNG and Unisonic's. (I haven't looked at Unisonic's.)

 

Intellivision's RNG is mathematically sound and produces a maximal period sequence. The fact it leads to a small-ish number of game outcomes in WC Baseball probably has more to do with the insensitivity of the game mechanics to some of the random numbers, and the fact that the only entropy source was the seed. The game mechanics have an "attractor" to certain outcomes.

Sorry, I did not explain myself well. I meant that, as you say, the dynamics of the game code further reduced the apparent randomness, and just like WCB arithmetic primer effectively has has attractors.

 

Have you isolated the RNG in the Unisonic code?

 

Naturally :)

 

L_13A7:
        MVI     G_00F5, R1                      ; load seed from $F4 / $F5
        SWAP    R1,     1                       ; 
        XOR     G_00F4, R1                      ; 
        MOVR    R1,     R0                      ; copy it
        SLL     R1,     2                       ; seed1 = seed << 4
        SLL     R1,     2                       ; 
        ADDR    R0,     R1                      ; seed1 += seed * 3
        ADDR    R0,     R1                      ; 
        ADDR    R0,     R1                      ; 
        MVO     R1,     G_00F4                  ; store seed1
        SWAP    R1,     1                       ; 
        MVO     R1,     G_00F5                  ; 
        ANDI    #$003F, R1                      ; seed1(MSB) %= 64
        CMPI    #$0033, R1                      ; 
        BGT     L_13A7                          ; if seed1(MSB) > 51, goto 13A7 (try again).  Looks suspiciously like choosing a card!

        MOVR    R4,     R7                      ; done

 

And at least one of the problematic calls is from:

 

L_10C6:
        JSR     R4,     L_13A7                  ; get the next random into R1

        MVI     G_00E8, R0                      ; check for easy or hard mode (I think)
        TSTR    R0                              ; 
        BNEQ    L_10D4                          ; if hard, skip 0-9 limit

        CMPI    #$0009, R1                      ; 
        BGT     L_10C6                          ; if random number > 9, goto 10c6 (try again)

 

Although the seed is 16bit, the problem is that if the LSB of the seed is 0 the MSB can cycle through a 32 value sequence each entry of which ends in $A or $E. These MSBs are used as the output of the RNG and clearly neither $A or $E is less than 10 :(

 

There is a source of entropy somewhere (presumably the timing of the player's input), but I have not bothered tracking it down.

Edited by decle
Link to comment
Share on other sites

Wow. That generator is horrible. All it does is compute 19N. That's all it's doing. It just multiplies by 19 every time, so the seed's "random" sequence is the lower 16 bytes of 19N.

 

Perhaps 19N was chosen randomly, out of all possible integers. :lol:

 

It reminds me a bit of this, from XKCD:

https://www.xkcd.com/221/

int getRandomNumber()
{
     return 4;  // Chosen by fair dice roll.
                // guaranteed to be random.
}

  • Like 2
Link to comment
Share on other sites

 

 

Perhaps 19N was chosen randomly, out of all possible integers. :lol:

 

It reminds me a bit of this, from XKCD:

https://www.xkcd.com/221/

int getRandomNumber()
{
     return 4;  // Chosen by fair dice roll.
                // guaranteed to be random.
}

 

That is a good xkcd. I've cited it many times. ;-)

 

 

I suspect, though, that 19 was picked mainly because it was prime, and produced better random numbers than 17N.

 

It's basically a really bad Linear-Congruential RNG.

  • Like 1
Link to comment
Share on other sites

Do the card games also have some sort of RNG and what does it look like? The same code, but used differently so its problems doesn't show as well?

 

Does this mean that young students who tried to practise their arithmetic skills on the Unisonic but got weird results, would flunk on school tests? A lost generation of mathematicians?

Link to comment
Share on other sites

  • 1 month later...

does that matter if how i draw a number?

it matters much more how i use it.

 

as well as a solution of whatever ingredients doesn't matters as much as what i select out of it.

 

i can use a sixteen sided dice and in the end the difference is if this green bottle is poisonous or if it's healthy? you will have to try and this is a "two sided dice".

ok i can make it less repetive or predictable (if i see the table), but none the less you can't predict if it's poisonous or not (because the table doesn't help you much then).

if i played a 100 times i can maybe predict with a high chance it won't be poisonous, but still i can be poisoned.

 

i guess simple mathematic games aren't a good example for this they are to easy seen through, especially when i work with a selection of answers, but in a role-playing you can't tell what happens, even if it's simple as 1,2,3. or do you count how many bottles you collected and how their relation was? "2 green, 3 red and 1 yellow, next must be a red one"? if you survived you concentrate on the next trap/challenge and you will know for this turn "never touch red bottles" i.e.. even if of three choices only one is left and i would know it must kill me i will be fooled and test it nonetheless only to find out it was dead awaiting me. but erm i'm a stupid gamer and i do had a cards counter as friend in school, i know that most was to predictable for him, but they are exotes.

he could track a one armed bandit by the way while we was talking and joking and could utter after a while things like "5 is followed most often by 8".

 

to speak in terms of my beloved "pioneer", does it matters if most pirates use this ship and this arms? no! i'm happy if i can burn their asses and get away alive.

neither a "cards counter" will have advantage of his talent, they prob. will burn his ass nonetheless, even when he could predict what exactly awaits him.

prob. one hit and your'e history, so what helps?

to be cautious.

i guess sometimes i like it to be "predictable", the fun starts if you use the players behave as seed, it will be more predictable in one sort, but exactly this will personalize it without that i have to care about how to achieve this.

 

the player btw., will think "how can this stupid game predict what i will do next?".

 

 

what's left is to flip a coin, either or not.

 

-----

 

VROOOAM! push the pedal down

Edited by Gernot
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

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