Messages

Serial pins could also be repurposed as MIDI ports (rs232 port @38400bps IIRC) so it could be a big plus. I, personnaly would want to develop music/midi-oriented tools for vectrex32 if that kind of extensibility existed.

Ok, so it is an high level only language for now? I remember starting developing things on Arduino and after few weeks begin to be interested into the assembly which was accessible with some commands (the same for C with the _asm_ directive). The programs written with some low level routines were so much faster.
My point is that providing high level language for this project is paramount and you made the right choice since it allows new developpers to get ahold of the system quickly and allow them to prototype faster since the learning curve is small. But don't forget that eventually they'd become seasoned developers and ambitious project would greatly benefit of faster routines. So making low level instructions accessible can be a big plus for V32SC.

As always it's only my two cents and you know better this hardware than me

If I were you I let it as some accessible serial pins (a small yet standard connector would be cool otherwise bare pins would be ok). Why do you ask me? For a simple reason: today you can have a serial to wifi interface for less that $3. The same for BT! So by going the serial route you're staying generic enough to let (hardware) developers to build on it! Hell! a game could be designed for linked multiplayer from the serial port but would work the same with a link cable or with a wifi as it would just reads RX and TX ports!

[TL;DR:]

You're perfectly right, I get your point. But be sure that someone will find a way to access the DRM mechanism over BASIC. It's just a matter of time. See all the consoles that have been developped with milion$ in R&D (PSP, Playstations, Xbox...) and still be cracked at the end and you'll know V32SC's DRM will suffer the same fate. This is true the target is way smaller than the one for modern consoles so it have less chance of being cracked, but as soon as someone sees it as an intellectual/interesting enough challenge s-he'll go for it and defeat it.

TL;DR: never underestimate the power of PEEK/POKE

Another solution could be to put a passthru connector on the V32SC in order to let developers hookup their cartridge on it. They will act as a sort of memory extension and could be developed on the cheap. The disadvantage would be a lot of extensions proturing from the Veccy (it always could be worse though ^^). But one can 3D print a stylish enclosuring resembling a floppy drive which will house the V32SC and a passthru connector for cartridges. This would make for a very stylish Vectrex accessory! These cartridges will just be memory extensions and could also use custom (totally optional) chips (aka SuperFX which sent calculations directly to datalines of the SNES cartridge connector without the SNES seeing the difference with a regular cartridge).

[*will*]

I'd say you should do nothing about it, and let it up to the developer. Hell, reverse engineering is fun so there can be challenges to be made (crackmes) between developers (of homebrew DRM) and crackers, like in the (old) computing scene!

The benefits of don't embedding native DRM into V32SC will be double:

• Not more work for you; you can concentrate on more productive things
• If the developers choose to bring DRM to their games, their will be different versions of it across their games/developers. So if when a protection is cracked they just have to make another version of it. If it was the SMartcard's DRM which would be cracked, all the software which depends on it will be cracked at once

Don't forget that your project is at first a debugging tool, so it *will* be turn against it to crack its own DRM if it happen to have one. You can chose to put in place schemes like execution rings (ring0, ring3...) to try to mitigate it but again this would means more work into a project that needs development and your attention on many other details which are more close to the original goal of it (making faster games on a legacy machine).

I will quote Benj Edwards in his 'Why History Needs Software Piracy' essay:

"If you see strict DRM and copy protection that threatens the preservation of history, fight it: copy the work, keep it safe, and eventually share it so it never disappears. [...] no one living 500 years from now will judge your infringing deeds harshly when they can load up an ancient program and see it for themselves."

So if you want your work to disappear from history please use DRM. I won't come this way with you, furthermore on a system which has seen its initial games' catalog going public domain by the company selling the console. I want my kids/ future generations to play your game and enjoy your work. I don't want them to look at some blurry jpegs or old captured footage of it.

Developers should trust their customers. Piracy will always exist, DRM is not a solution; trust is.