Jump to content

Recommended Posts

The market you are trying to build is very small from the outgo - splitting the market isn't a decision I'd recommend, not to mention the need to support two different platforms. So if you're going to do both a standalone and an add-on, it'd be silly to make them incompatible with each other.

 

If it were me, I'd also try to make them both run on the same PCB. The cost of manufacturing two separate casings alone is crazy, but to design and debug two separate PCBs in isolation is a lot of work for a small team. If you can reduce that workload, you have a better chance of reaching the goal.

 

From a developer's standpoint, you're releasing videos of software running on a machine and you're still trying to decide the CPU configuration. ;) If you want to support other developers, I'd recommend you make sure that the design of the system is solid. You are going to need to describe the machine (in detail) to other people if you want strong support for it. That starts with a strong design and follows up with strong documentation.

 

My advice would be to take a step backwards, and start with the question "what do I want to do with this hardware?" Get your design on paper and then build that design.

 

It's very easy today to add advanced features that we only dreamt of 30 years ago, which makes it too easy to get stuck in feature creep and never get done. Stay strong! ;)

 

But that's all just armchair advice, discard at will. ;)

Actually this is all pretty good advice. Indeed having two incompatible or partially compatible platforms isn’t my goal.

Rev A board used for videos was never intended to be a complete board. It was created to validate our video solution, and for that purpose it works well.

And to be clear, the question I am being asked is to decide on a Z80+Z80 versus 68000+Z80 architecture. I see pros and cons on both, but 68000+Z80 configuration makes the SGM2 a little more complicated. It is always possible, but then we starting getting to the point where the CV isn’t really necessary anymore.

From development point of view, the 68000 has a lot of development tools available out there, but Zilog offers some unique stuff for their Z80s, like a interface for debugging from a PC and a C compiler.

 

 

Sent from my iPhone using Tapatalk

I was just talking to the hardware team. They asked me about including the 68000. We discussed some of the pros and cons. The pros are fairly obvious, the cons are mostly related to the SGM2. As you know, SGM2 and OMNi share the same architecture. If we go 68000, things start to get complicated with the SGM2. I don't want two platforms, I want a single platform that I can feed. So my question is, and I don't think I ever asked that before, how important is the SGM2 for you? Do you favor the SGM2 more, the OMNI more, or just don't care (meaning you are fine with either)?

One idea the hardware team floated was to make the SGM2 only partially compatible with OMNi (Z80 mode), while the OMNI adds a 68000 mode. Not sure if I like that either. Or we can just keep things as they are, Z80 only. Please feel free to comment. Decisions must be made ASAP.

I'm on board for the SGM2 only but I might be in the minority. Maybe setup a poll?

I have a very straightforward opinion as a enthusiast of hardware design and software game creation, if adding a 68000 will cause the add on not to happen, the I am ok with the add on not happening.

 

The reason I say this, is that the 68000 opens up all kind of programming possibilities seeing as how the X68000, Sega Genesis, Amiga, Arcade Games and other machines used it. If the developer tool chain can allow for home-brew programmers of those consoles to make games for the Omni, then the trade-off in my opinion is well worth it.

 

Honestly I am also very keen to see how developers can be creative and use both processors at once, I can only imagine it can be interesting.

 

I would prefer not to connect new hardware to my old aging Colecovision if possible that hardware is so unstable being so old in my opinion.

 

The big win for me about the add on was that it was going to come out significantly before the stand alone console, so we can use it and devs can get familiar with the SDK toolkits.

Edited by imstarryeyed

I have a very straightforward opinion as a enthusiast of hardware design and software game creation, if adding a 68000 will cause the add on not to happen, the I am ok with the add on not happening.

 

The reason I say this, is that the 68000 opens up all kind of programming possibilities seeing as how the X68000, Sega Genesis, Amiga, Arcade Games and other machines used it. If the developer tool chain can allow for home-brew programmers of those consoles to make games for the Omni, then the trade-off in my opinion is well worth it.

 

Honestly I am also very keen to see how developers can be creative and use both processors at once, I can only imagine it can be interesting.

 

I would prefer not to connect new hardware to my old aging Colecovision if possible that hardware is so unstable being so old in my opinion.

 

The big win for me about the add on was that it was going to come out significantly before the stand alone console, so we can use it and devs can get familiar with the SDK toolkits.

Something I may have mentioned on passing. Being Omni and SGM2 the same platform mostly, the point with the SGM2 coming out first was not related to any technical difficulty with the console, but rather the fact that the investment to get arcade ports done is considerably lower than original games. And considering the money involved in getting the hardware out, that may be a necessity. Arcade ports are a must for us CV fans, but other communities may not care as much. So getting the platform out as a CV module made sense from that perspective. Once the hardware was out, I could then invest the necessary money on original stuff. The second reason being that I can’t openly promote the console with unlicensed games. Again not a big deal with a CV module. Those are still issues, and supposing we skip the module and go with the console first, it would have to be a sort of limited release, let’s say an AtariAge edition, with little fanfare, until original games get done and we can openly advertise the whole thing. So that is something else I must take into account. On the other hand, OMNI isn’t exactly intended as something for the ColecoVision community only, so I can see how having a 68000 could increase the appeal.

 

 

Sent from my iPhone using Tapatalk

Ok. I would keep SGM2 for ColecoVision users want to play quality arcade games since Coleco released module 1, Atari 2600 emulator as well.

 

But I would drop Omni since it's a new system with its own cartridges. Only few people would be interested with it.

The key point here is probably the 68000, if it is worth the trouble or not. Advantage is compatibility with some more advanced arcades, some 16-bit computers, and the fact that a lot of developers may be familiar with it. Disadvantage is that it makes the system a dual boot system, thus more complicated to implement a SGM2, and the fact that (believe or not) the 68k is actually slower than the Z80 we are using, at least in theory.

If you make a system with 2 Z80's, isn't that a dual boot system too?

 

I think a system with a 68000 and a Z80 sounds like a Sega Genesis copy, while a dual Z80 machine would be a unique system.

 

Clive Sinclair made 3 successful computers based on the Z80 ( the ZX80, the ZX81, and the Spectrum) , but he got into trouble when he tried to make a 68000 based machine (the QL). I think this was partly because he kept the 8bit data bus, which slowed down the 68000 quite a bit.

 

How wide is the data bus on the SGM2? How do you address more than 64k of Ram with the new Z80?

You have been missing team meetings. OMNI isn't backward compatible with ColecoVision. :P

 

EDIT: so yeah, no cartridge adaptor is possible, unless we put the whole ColecoVision inside the cartridge adaptor. Problem with being CV compatible is that we would need to go the FPGA route to get digital video, and I don't want to go FPGA.

Can't you put the ColecoVision in the cartridge adaptor, like it's done with the Super Game Boy? (j/k) :P

  • Like 1
Clive Sinclair made 3 successful computers based on the Z80 ( the ZX80, the ZX81, and the Spectrum) , but he got into trouble when he tried to make a 68000 based machine (the QL). I think this was partly because he kept the 8bit data bus, which slowed down the 68000 quite a bit.

 

Bear in mind that the QL didn't use a proper 68000 - it used a 68008, which was the version of the 68000 that only supported an 8-bit data bus and reduced address bus. There's a reason why virtually no other microcomputers used it (hint: Sinclair did everything on the cheap).

 

That said, nothing wrong with a 68000 / Z80 combo. It was very common in arcade hardware at the time (in various permutations) and would give the SGM2 some serious muscle. However, I can see where multiple Z80s could get very close to that in terms of processing power.

I think if Opcode can implement the sound and graphics libraries in very friendly way to developers who make homebrew games for the other Z80 & 68000 consoles I can imagine there will be a chance that devs might be interested in expanding their user base. I think any new games made for the console will be a big win.

 

In my imagination the libraries would be similar to those consoles that allow for straightforward porting of their games, but with the bonus of some added features that are available on the Omni that allow those ports to be enhanced for the Omni.

 

I do not know how feasible this is, but it would be interesting if possible.

Edited by imstarryeyed

I'm not a hardware designer so take my comments with a grain of salt. From everything you have described and provided info, I think the one thing you should follow is the KISS principle: Keep It Simple... Sir. ;).

 

- getting a new system off the ground is already complicated enough

- making development harder for similar return is usually a Nono, devs need to want to use your system. Make it easy for them to develop, not harder. Introduce a second different CPU and you might gain easier access to some games but lose devs while you are at it

- you already stated your original specs could produce 16bit quality games so...

- you are targeting a reasonable amount of consoles sold to be self-sustainable but not to attract big money devs with long development cycles. Ie most devs who will use your system will have very fixed budgets with possibly no use for complicted development, so 68000 could be n issue, especially in dual mode (i would predict few will use it)

 

Good luck with whatever decision you come up with, the system has potential.

Edited by Loafer

After seeing what the TurboGrafix-16 (aka PC Engine) could do with a good video chip and an 8-bit processor, I'm wondering what the fuss is. Dual Z80 chips should be good for almost all 80's arcade games. Even 68000 games like Marble Madness had decent 8-bit ports, it seems like it comes down to the skill of the programmer and the VDP.

  • Like 3

Not sure but according to https://en.wikipedia.org/wiki/Zilog_eZ80 a 50MHz eZ80 version is roughly equivalent to a 150MHz Z80 ... I think that is plenty of power and would make a 68K quite unneeded aside the ease of porting for some of the 68K based arcades.

As you said CV users may care about arcade ports as such SGM2 users may care too, OMNI users may want some original titles so for those the 68K may matter little and maybe a faster Z80 is all that's needed.

 

I understand you want to maintain the '80s feeling but that can be done with an "optional" reduced clock if needs be.

  • Like 1

Not sure but according to https://en.wikipedia.org/wiki/Zilog_eZ80 a 50MHz eZ80 version is roughly equivalent to a 150MHz Z80 ... I think that is plenty of power and would make a 68K quite unneeded aside the ease of porting for some of the 68K based arcades.

As you said CV users may care about arcade ports as such SGM2 users may care too, OMNI users may want some original titles so for those the 68K may matter little and maybe a faster Z80 is all that's needed.

 

I understand you want to maintain the '80s feeling but that can be done with an "optional" reduced clock if needs be.

 

 

After seeing what the TurboGrafix-16 (aka PC Engine) could do with a good video chip and an 8-bit processor, I'm wondering what the fuss is. Dual Z80 chips should be good for almost all 80's arcade games. Even 68000 games like Marble Madness had decent 8-bit ports, it seems like it comes down to the skill of the programmer and the VDP.

 

While it is true that any CPU can do any game, it is always way easier to do ports using the same CPU, since we don't have the luxury of having access to the original source code.

 

I'm not a hardware designer so take my comments with a grain of salt. From everything you have described and provided info, I think the one thing you should follow is the KISS principle: Keep It Simple... Sir. ;).

 

- getting a new system off the ground is already complicated enough

- making development harder for similar return is usually a Nono, devs need to want to use your system. Make it easy for them to develop, not harder. Introduce a second different CPU and you might gain easier access to some games but lose devs while you are at it

- you already stated your original specs could produce 16bit quality games so...

- you are targeting a reasonable amount of consoles sold to be self-sustainable but not to attract big money devs with long development cycles. Ie most devs who will use your system will have very fixed budgets with possibly no use for complicted development, so 68000 could be n issue, especially in dual mode (i would predict few will use it)

 

Good luck with whatever decision you come up with, the system has potential.

 

I think if Opcode can implement the sound and graphics libraries in very friendly way to developers who make homebrew games for the other Z80 & 68000 consoles I can imagine there will be a chance that devs might be interested in expanding their user base. I think any new games made for the console will be a big win.

 

In my imagination the libraries would be similar to those consoles that allow for straightforward porting of their games, but with the bonus of some added features that are available on the Omni that allow those ports to be enhanced for the Omni.

 

I do not know how feasible this is, but it would be interesting if possible.

 

 

Bear in mind that the QL didn't use a proper 68000 - it used a 68008, which was the version of the 68000 that only supported an 8-bit data bus and reduced address bus. There's a reason why virtually no other microcomputers used it (hint: Sinclair did everything on the cheap).

 

That said, nothing wrong with a 68000 / Z80 combo. It was very common in arcade hardware at the time (in various permutations) and would give the SGM2 some serious muscle. However, I can see where multiple Z80s could get very close to that in terms of processing power.

 

If you make a system with 2 Z80's, isn't that a dual boot system too?

 

I think a system with a 68000 and a Z80 sounds like a Sega Genesis copy, while a dual Z80 machine would be a unique system.

 

Clive Sinclair made 3 successful computers based on the Z80 ( the ZX80, the ZX81, and the Spectrum) , but he got into trouble when he tried to make a 68000 based machine (the QL). I think this was partly because he kept the 8bit data bus, which slowed down the 68000 quite a bit.

 

How wide is the data bus on the SGM2? How do you address more than 64k of Ram with the new Z80?

 

2 Z80s isn't a dual boot system in the sense that it will always be a Z80 being the master CPU. When we have 68000+Z80 we may want to be able to select which CPU we use. So the system may be able to boot as a Z80 machine, or may boot as a 68000+Z80 machine.

 

Data bus is 8-bit if Z80 and 16-bit if 68000. Addressing is 24-bit no matter the CPU, so up to 16MB.

 

 

Thanks for all the comments. That surely helps me to get an idea of what you guys expect.

 

I understand that for the average user the CPU may not matter. And the point here isn't performance, we can get the same level from different CPUs. My concern is what would be the best option to attract developers (from a personal POV, I would go with Z80 only, but others may think differently). I also want to stay focused on the Atari era group, so it must be something that makes sense for them. While any developer from any group is very welcome, the focus for OMNI is Atari era. Since 6502 isn't an option, I thought 68000 would be a friendlier option. While Z80 was very popular in the arcades, it wasn't as popular for home devices in the US for some reason.

 

For the sake of performance comparison:

 

DHRYSTONES/SEC:

A 68000 at 12MHz - about 1100

Z80 at 4MHz - about 150

Extrapolating --->

Z80 at 12MHz - about 450

eZ80 at 12MHz - about 1300

 

MIPS:

68000 at 12MHz - about 2MIPS

Z80 at 4MHz - about 0.5MIPS

Extrapolating -->

Z80 at 12MHz - about 1.5MIPS

eZ80 at 12MHz - about 4.5MIPS

 

For comparison sake:

PC Engine - 3.3MIPS

Genesis - 1.9MIPS

SNES - 1.8MIPS

What about putting a 80286 instead of a Z80 ?

 

I think it should be quiet easy to port Z80 code to 286.

 

the Z80 is backward compatible with the 8080 . the 80x86 family is somewhat based on the 8080 .

 

back in time you were able to find kind of "translator" that can directly transform 8080 code to run on 8086 without any modification (after the translation process).

 

and i think you can find 286 up to 25 Mhz .

 

Speaking about translation from Z80 to 286 , years ago a guy ported a set of MSX games (including Konami's KnightMare) to PC 286. He did not rewrite code for zero he started from the MSX rom directly. and it was not emulation.

The architecture of a console can only go so far in attracting developers. It really comes down to the developer tools, especially for homebrew programmers who can only code in their free time.

 

If I were in your shoes, what I would do is study Game Maker. I've never used it myself, but seeing some of the rather impressive games that were made with it on YouTube, it seems to be full-featured which explains its general popularity. Perhaps you can learn from that in some fashion for your own Omni dev tools.

 

One thing's for sure: Releasing a bare-bone Z80 or even 68000 compiler with minimal documentation is a sure-fire way to see the Omni fade into oblivion. Homebrew coders in 2019 demand actual tools: Graphic editors, sound editors, accurate emulators, debuggers with source code breakpoints, and everything has to run in Windows (or maybe other operating systems if there's a significant demand for it). And of course there needs to be source code examples to help beginners understand how to do such things as animating on-screen objects, coding a platformer (i.e. gravity and collision detection with platforms), implementing smooth scrolling, coding a space shooter, etc. etc. etc.. And the worst part is that you need to have ALL those things in place to attract new developers, otherwise they'll just do a quick demo to get a feel for the dev tools, and they'll dump it in favor of more advanced tools on other gaming media (such as Game Maker, ironically).

 

Just look at how few homebrew coders there are right now for the ColecoVision. The few that we have are relatively prolific, but they are certainly not legion. I don't know how much you've discussed this with your Omni hardware team, but I can't imagine someone creating all those advanced dev tools alone.

  • Like 5

If it's going to have a development environment in a higher level language it really doesn't matter, to new game developers, what the cpu is. So then the 68000 might let you port a few more old games, if people care about those. If you can get a better development environment for 68000 than that might be the way to go.

I understand that for the average user the CPU may not matter. And the point here isn't performance, we can get the same level from different CPUs. My concern is what would be the best option to attract developers (from a personal POV, I would go with Z80 only, but others may think differently). I also want to stay focused on the Atari era group, so it must be something that makes sense for them. While any developer from any group is very welcome, the focus for OMNI is Atari era. Since 6502 isn't an option, I thought 68000 would be a friendlier option. While Z80 was very popular in the arcades, it wasn't as popular for home devices in the US for some reason.

The architecture of a console can only go so far in attracting developers. It really comes down to the developer tools, especially for homebrew programmers who can only code in their free time.

 

If I were in your shoes, what I would do is study Game Maker. I've never used it myself, but seeing some of the rather impressive games that were made with it on YouTube, it seems to be full-featured which explains its general popularity. Perhaps you can learn from that in some fashion for your own Omni dev tools.

 

One thing's for sure: Releasing a bare-bone Z80 or even 68000 compiler with minimal documentation is a sure-fire way to see the Omni fade into oblivion. Homebrew coders in 2019 demand actual tools: Graphic editors, sound editors, accurate emulators, debuggers with source code breakpoints, and everything has to run in Windows (or maybe other operating systems if there's a significant demand for it). And of course there needs to be source code examples to help beginners understand how to do such things as animating on-screen objects, coding a platformer (i.e. gravity and collision detection with platforms), implementing smooth scrolling, coding a space shooter, etc. etc. etc.. And the worst part is that you need to have ALL those things in place to attract new developers, otherwise they'll just do a quick demo to get a feel for the dev tools, and they'll dump it in favor of more advanced tools on other gaming media (such as Game Maker, ironically).

Pretty much this. You're just not going to get *any* modern independent game developers to work on your new system with only a few hundred or few thousand potential customers, unless you make it amazingly easy for them to port to your console. That means actual Unity or Game Maker support ... not look-alikes, the real things so that they can easily port existing code.

 

Modern day developers don't care about the CPU ... it's got to be a high-level language, or no interest. Standard C would barely count. C++ or C#, with full source level debugging.

 

The reality is ... you're too small an operation to be able to provide that level of support.

 

 

Homebrew developers are only going to be marginally less demanding. They're still going to want a high-level language, but standard C might be OK, as long as there is good debugging and a large pre-written library.

 

 

The amount of folks that are going to be willing to write in assembly-language, either eZ80 or 68000, is not much more than a handful ... and they have plenty of other real 80s & 90s consoles, that shipped millions of units, and have strong existing fan-bases, that they can code for.

 

 

Using the eZ80 gives you the luxury of being able to leverage Zilog's existing C development environment, and its source-level debugger.

 

Adding a totally-different development environment for a 68000 CPU is just going to put people off.

 

If you *really* wanted to add in a 16-bit CPU to make C coding easier, then I'd recommend, as I did before, going with Zilog's Z16/ZNEO, which has the added advantage of using the same Zilog development environment and debugger as the eZ80 ... so no developer confusion, just faster execution on the 16-bit side.

 

The ZNEO's 80s-era Z8000-descended instruction set would make converting existing 68000 assembly language code a pretty trivial task, if you're actually thinking of just ripping-off code from old arcade games.

 

 

Having said all of that ... the choice is really up to you. This is your passion-project, so just put in whatever hardware you feel makes sense for your own development.

Edited by elmer

There is no doubt that our original ColecoVision console is dying.

There could be another need for a new console like the Phoenix VGS.
And we know that Eduardo dream about a console with his own format.

If you want to support the ColecoVision people, you should definitely focus on developing a console still based on ColecoVision.
It can still be a new system based on the 68000 + Z80 environment as you like, but it should, like the Phoenix VGS, be familiar with ColecoVision in the form of a single cartridge port for original ColecoVision games.

The console must have the necessary graphics and contemporary sound chips.

I imagine a standalone console with built-in ColecoVision + SGM1 in a 68000 + Z80 environment.

There should only be one pcb mounted and one single cartridge port that can handle both ColecoVision and 68000 based games.
You can call it the Opcode Super Game System (SGS).

The new 68000 + Z80 based games should be in the same cartridge shell, with a new SGC2 or SGC3.

I can see a problem in not being true to the original games and there should still be a market for ColecoVision games.
CV + SGM1 have limits, same has 68000 just don't make games that aren't bigger than they really are or can be.

And yes I agree, arcade ports is a must for our ColecoVision fans.

And I think there is a basis for both options in a single console.

 

I think CV+SGM should still be supported together with your SGC1 which I also will support like the Phoenix VGS. :)

Based on my own opinion and sorry my english.

  • Like 1

There is no doubt that our original ColecoVision console is dying.

There could be another need for a new console like the Phoenix VGS.

And we know that Eduardo dream about a console with his own format.

If you want to support the ColecoVision people, you should definitely focus on developing a console still based on ColecoVision.

It can still be a new system based on the 68000 + Z80 environment as you like, but it should, like the Phoenix VGS, be familiar with ColecoVision in the form of a single cartridge port for original ColecoVision games.

The console must have the necessary graphics and contemporary sound chips.

I imagine a standalone console with built-in ColecoVision + SGM1 in a 68000 + Z80 environment.

There should only be one pcb mounted and one single cartridge port that can handle both ColecoVision and 68000 based games.

You can call it the Opcode Super Game System (SGS).

The new 68000 + Z80 based games should be in the same cartridge shell, with a new SGC2 or SGC3.

I can see a problem in not being true to the original games and there should still be a market for ColecoVision games.

CV + SGM1 have limits, same has 68000 just don't make games that aren't bigger than they really are or can be.

And yes I agree, arcade ports is a must for our ColecoVision fans.

And I think there is a basis for both options in a single console.

 

I think CV+SGM should still be supported together with your SGC1 which I also will support like the Phoenix VGS. :)

Based on my own opinion and sorry my english.

 

You're totally right here:

 

If homebrewers start making games for SGM2/OMNI or even Phoenix, they would probably drop Colecovision.

Edited by Serguei2

Pretty much this. You're just not going to get *any* modern independent game developers to work on your new system with only a few hundred or few thousand potential customers, unless you make it amazingly easy for them to port to your console. That means actual Unity or Game Maker support ... not look-alikes, the real things so that they can easily port existing code.

 

Modern day developers don't care about the CPU ... it's got to be a high-level language, or no interest. Standard C would barely count. C++ or C#, with full source level debugging.

 

The reality is ... you're too small an operation to be able to provide that level of support.

 

 

Homebrew developers are only going to be marginally less demanding. They're still going to want a high-level language, but standard C might be OK, as long as there is good debugging and a large pre-written library.

 

 

The amount of folks that are going to be willing to write in assembly-language, either eZ80 or 68000, is not much more than a handful ... and they have plenty of other real 80s & 90s consoles, that shipped millions of units, and have strong existing fan-bases, that they can code for.

 

 

Using the eZ80 gives you the luxury of being able to leverage Zilog's existing C development environment, and its source-level debugger.

 

Adding a totally-different development environment for a 68000 CPU is just going to put people off.

 

If you *really* wanted to add in a 16-bit CPU to make C coding easier, then I'd recommend, as I did before, going with Zilog's Z16/ZNEO, which has the added advantage of using the same Zilog development environment and debugger as the eZ80 ... so no developer confusion, just faster execution on the 16-bit side.

 

The ZNEO's 80s-era Z8000-descended instruction set would make converting existing 68000 assembly language code a pretty trivial task, if you're actually thinking of just ripping-off code from old arcade games.

 

 

Having said all of that ... the choice is really up to you. This is your passion-project, so just put in whatever hardware you feel makes sense for your own development.

This is great info. Thank you for sharing. I see something here that really caught my attention that I wasn’t aware of. Investigating further.

 

Some news I think are worth sharing.

- We are now at 300 people in our SGM2 Early Adopter list.

- And we are having some promising talk about licensing. Stay tuned.

 

 

 

Sent from my iPhone using Tapatalk

  • Like 1

UPDATE:

 

- with 300 people in the waiting list for the SGM2, development proceeds as planned

 

- we are replacing one Z80 cpu with a 16-bit cpu. That will make our architecture more versatile

 

Thanks again for all the comments and suggestions. They were really helpful. :)

 

 

Sent from my iPhone using Tapatalk

  • Like 6

I signed up via the link in the email from a couple days ago (pretty much right after it was sent out). Filled out the survey info to be an early adopter. Does that mean I'm signed on as an early adopter? I didn't get any confirmation email or other indication aside from a message thanking me for filling the survey. Just want to be sure I'm in! Really excited about this project!

Edited by Hastor

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...