Hive multi-cart - It's alive!

[RAGINxxXxxCAJUN]

What's the latest on the progress on the cart?

[chart45]

im in for one great work

[doomguy]

How will this cart compare to the LTO Flash?

[abrondino]

Please alert me when this becomes available. I would like to purchase it.

[bikeguychicago]

How will this cart compare to the LTO Flash?

 

You won't be able to play any LTO/Elektronite ROMs (should they become available) on it, for one...

[+DZ-Jay]

You won't be able to play any LTO/Elektronite ROMs (should they become available) on it, for one...

Any future ones, perhaps. I don't see why Christmas Carol wouldn't play on it.

[GroovyBee]

I've played Rocketeer, Mars Minis, Mystery Castle, Apple Snaffle, Terra 5, KillBotz!, Hover Bovver and Next Street on it, as well as a whole bunch of legacy games and protos and I didn't encounter any problems. Last time I checked, DZ-Jay's Carol worked fine on it too . Although I haven't had time to test nanochess's Space Raid or Princess Quest games on it, but I see no reason why they wouldn't work.

[Rev]

Serious question, and maybe I should direct this to Willy/Joe/Elektronite/Lto. But are their (your) game Roms going have code or something like DRM that may limit them being playable in emulation and/or other multicarts? I honestly dont remember the final say from the LtoFlash thread. Im not trying to start any arguements. In the long run, i dont care, since i would always buy individual carts anyhow.

 

Thanks.

[GroovyBee]

There will be no DRM on my multi-cart. If I put out out game ROMs they'll be completely free of charge. I'm not the least bit interested in gouging collectors for a digital copy.

[+intvsteve]

Games that use JLP-specific features - or IntelliCart- or CC3-specific features for that matter, will expect those features to be present in order to work, unless they take measures to work around their absence.

 

The use of any hardware-specific feature, like extra RAM at certain locations, bank switching, accelerated instruction features, what have you, will be game-specific. Modern CPUs even do this sort of thing, with all kinds of new instruction sets that applications my choose to use - which necessarily restricts the set of processors on which they'll run. So games designed to run on JLP boards will require those features. AFAIK Carol didn't require those features, and could probably have been put on carts of any Intellivision era.

 

The DRM features of LTO Flash! are entirely opt-in so it's up to the entity owning the rights to the ROM to decide what to do.

 

If a new board design comes along that has features not on LTO Flash!, then there will be a compatibility problem for programs using such features.

 

To this point, all the special features like RAM, bank switching, flash storage, et. al. have been documented for all to use. If competing feature sets occur, my personal hope would be that firmware updates would allow for emulation of such features through some form of cooperation, even if it's just in the form of decent documentation.

Edited August 28, 2014 by intvsteve

[+DZ-Jay]

Games that use JLP-specific features - or IntelliCart- or CC3-specific features for that matter, will expect those features to be present in order to work, unless they take measures to work around their absence.

 

The use of any hardware-specific feature, like extra RAM at certain locations, bank switching, accelerated instruction features, what have you, will be game-specific. Modern CPUs even do this sort of thing, with all kinds of new instruction sets that applications my choose to use - which necessarily restricts the set of processors on which they'll run. So games designed to run on JLP boards will require those features. AFAIK Carol didn't require those features, and could probably have been put on carts of any Intellivision era.

 

The DRM features of LTO Flash! are entirely opt-in so it's up to the entity owning the rights to the ROM to decide what to do.

 

If a new board design comes along that has features not on LTO Flash!, then there will be a compatibility problem for programs using such features.

 

To this point, all the special features like RAM, bank switching, flash storage, et. al. have been documented for all to use. If competing feature sets occur, my personal hope would be that firmware updates would allow for emulation of such features through some form of cooperation, even if it's just in the form of decent documentation.

 

That is not necessarily accurate. Christmas Carol, for example, uses JLP-specific features to save the state of "saving Christmas" in order to unlock the "Boss Level" in the practice menu; however, it fails gracefully on non-JLP hardware like the CC3 and works as normal. It just won't save that state.

 

Likewise with extended RAM: JLP models its memory map after other common implementations, such as the Intellicart and the CC3.

 

True, if games are designed to be used with the LTO-Flash only, then they won't work anywhere else. However, none exist so far so we shall see what the future brings. One would hope that game programmers would like to reach the widest audience.

 

-dZ.

[Rev]

Thanks for clearing up Steve. So its up to each individual game maker.

[+intvsteve]

 

That is not necessarily accurate. Christmas Carol, for example, uses JLP-specific features to save the state of "saving Christmas" in order to unlock the "Boss Level" in the practice menu; however, it fails gracefully on non-JLP hardware like the CC3 and works as normal. It just won't save that state.

 

Likewise with extended RAM: JLP models its memory map after other common implementations, such as the Intellicart and the CC3.

 

True, if games are designed to be used with the LTO-Flash only, then they won't work anywhere else. However, none exist so far so we shall see what the future brings. One would hope that game programmers would like to reach the widest audience.

 

-dZ.

What isn't necessarily accurate? I said this:

 

"Games that use JLP-specific features - or IntelliCart- or CC3-specific features for that matter, will expect those features to be present in order to work, unless they take measures to work around their absence." [emphasis added]

 

So, Carol uses JLP features (OK, I didn't know that, so there's the inaccuracy). But, you then explain exactly what I said, which is that a game (Carol) could use special features, but work around their absence and fail gracefully. Not all games will do that. Does the ROM you distribute use JLP features?

 

As to RAM, to this point, each new generation of hardware has attempted to remain backward compatible, though I admit not being fully versed on all the stuff out there. So, CC3 maintained IntelliCart compatibility, and JLP expands on both of those, I think. That was crucial to the people involved in the design and implementation. As intvnut has elaborated, LTO Flash! does as well. I.e. programs using IntelliCart, CC3, or JLP features will work. I don't immediately recall all the nuances of various bank switching modes-there may be situations where you can't use multiple bank switching modes at the same time or some such.. I also think the RAM on LTO Flash! is all 16-bit. Joe will need to speak to that.

 

I'm still pretty early on in my Intellivision programming career, and haven't written any code exploiting the features of the more advanced capabilities of these boards.

 

Personally, I appreciate designs that fail gracefully when hardware features are not present, but it's not always realistic, or possible, to achieve. Writing a JLP game but testing it on a CC3 requires a design that fails gracefully. LTO Flash! lightens that burden.

Edited August 28, 2014 by intvsteve

[mylok]

I look forward to this and the LTO flash cart. I am unfortunate enough to not have a cuttle cart and don't feel like paying $400 to $500 for one on eBay.

 

I will buy two of these as well as two LTO's when released.

 

Keep up the good work it is much appreciated.

Edited August 28, 2014 by mylok

[+DZ-Jay]

What isn't necessarily accurate? I said this:

 

Your comment seem to imply that games taking advantage of LTO Flash! features would not work anywhere else. Especially since you were alluding to my earlier comment using Carol as an example of an LTO-feature-enabled ROM that works everywhere. I apologise if I misunderstood your comment.

 

You added this at the end:

The DRM features of LTO Flash! are entirely opt-in so it's up to the entity owning the rights t the ROM to decide what to do.

 

Additionally, I want it to be clear that the LTO Flash! features--all of them--are opt-in as well. So a ROM that plays on the LTO Flash! can still play in other platforms, unless someone chose not to.

 

My point is that, yours and other's comments seem to suggest that the LTO Flash! is "backwards compatible" to play older stuff and that newer stuff will only work there. That's only if programmers (or rights holders, in the case of DRM) choose to make games and distribute them only on LTO Flash! However, as I mentioned before, I would imagine programmers would like to cast as big a net as possible with their distribution. They have so far.

 

We haven't seen home-brews being ECS-specific (to take advantage of additional RAM and sound voices), Intellivoice specific (to take advantage of synthesized voice), or even CC3-specific (yes, it does have additional RAM on-board); and everybody in this business has strived very hard to make sure the games play in every single console and emulator imaginable. It is not clear right now that the future will be different.

 

As for Carol, there are various versions of the ROM out there, some with JLP features, some without. The code is such that it fails gracefully by using the save feature if its there and skipping it if not. It also has a build configuration option to conditionally include or exclude the code from the ROM.

 

The first ROM releases do not include it. I didn't see a reason for it since it wouldn't work anywhere else, so I build the ROM excluding the save feature. Some later special builds include it, since JLP save support was built into newer versions of jzIntv.

 

-dZ.

Edited August 28, 2014 by DZ-Jay

[+DZ-Jay]

Personally, I appreciate designs that fail gracefully when hardware features are not present, but it's not always realistic, or possible, to achieve. Writing a JLP game but testing it on a CC3 requires a design that fails gracefully. LTO Flash! lightens that burden.

 

There's also a special widget that Joe created that allows you to test JLP features in the CC3. Sure LTO Flash! would not require that, but it hasn't been impossible so far. Moreover, the jzIntv emulator/debugger supports it as well.

 

intvsteve, I think we are in agreement over the overarching point that LTO Flash! brings new exciting features that can enhance games, and that it is up to the programmer to decide, when taking advantage of them, if the game should constrain itself to require them.

 

Then again, so will the Bee3.

Edited August 28, 2014 by DZ-Jay

[+intvsteve]

 

My point is that, yours and other's comments seem to suggest that the LTO Flash! is "backwards compatible" to play older stuff and that newer stuff will only work there.

 

I don't see how anything I've said suggests this, but whatever. Next:

 

That's only if programmers (or rights holders, in the case of DRM) choose to make games and distribute them only on LTO Flash!

 

 

That's precisely what I've said from the beginning, and emphasized again in an early response. So I'll restate it again:

 

If you use features specific to certain hardware, then you've bought into it UNLESS YOU TAKE MEASURES TO ACCOUNT FOR THAT HARDWARE'S ABSENCE.

 

Extra features on hardware from the very beginning of the console have always been opt-in. Pedantically speaking, sound and controller usages are opt-in in software, though the hardware may have some problems if those features don't exist. The only absolutely necessary things are the CPU and a means for it to find code to execute. You don't even need RAM, though that would make for somewhat limited programs. How programs cope with the absence of hardware features is specific to that program. E.g. Mattel could have just let Intellivoice games crash if no Intellivoice was present. They chose not to - they failed gracefully. But then we have some games that just don't work e.g. w/ the ECS, either because you can't future-proof, or because you choose not to fail gracefully - depends on when the software was written.

 

As the pool of Intellivision developers hopefully grows (I'm looking at you, IntyBasic!), ideally higher level tools and frameworks will make it easier to choose whether or not to use advanced features, perhaps even in the form of basic template applications that start off with code that assumes certain feature sets, with skeleton failure mode code ready to fill in. You mention Joe's 'widget' for feature detection. I'd bet that Joe will expand such tools that presently flag hardware-specific features to also report LTO Flash! usages as well. He has a vested interest in this. With such utilities as a core, more can follow.

 

With each new generation of "cartridge hardware" new features are also by default opt-in. The challenge with such designs is to avoid incompatibility with existing software and other hardware peripherals that map into known addresses. I suppose over time, adding new features may become more challenging if more and more little slivers of the memory map are 'reserved'. This is where tools really help out.

 

So I'll close with another thought experiment, because they are fun. There are features on LTO Flash! that simply are not available on all other devices. That's part of the excitement for new hardware. Rather than a clone of CC3, Joe wanted to push forward. For example, you'll be able to use the serial port from Intellivision code. If you use that serial port to communicate with the host PC, then you'll have to be running on hardware that supports this, and even likely require software on your host computer to be running, too. At this time, I know of only one platform with such a feature for use from CP1610 code, though maybe there's an obscure or undocumented feature of the IntelliCart or CC3. If a future hardware product chooses to support a serial port, it would likely, out of deference to backward compatibility, support the LTO Flash! API to it. And then it could extend it, or offer an even better I/O mechanism. That's up to that new design. It wouldn't be required at all, and it could in fact completely ignore all other features from other designs.

 

Any program that does use the serial port, for example, will limit itself to hardware with such capability. If it's essential to gameplay, i.e. you've written something that requires your program to use a serial port, it also implies that your console is attached to a computer and has software running there to be the other end of the I/O pipe. The author of such software makes a conscious decision limiting where that program runs. If the goal is to have some kind of connectedness, that's why you chose the platform you did. Maybe such an application just disables certain features when not on the specified hardware. E.g. in a multiplayer adventure game would make sense to do this. When running in 'disconnected mode' when no serial port can be found, or no host computer is connected, it would disable 'networked multiplayer mode' or whatever. An analogy would be games that require the Kinect or a Wii Fit board. In the case of Kinect, it's become ubiquitous and isn't a big deal. Not so much for the Wii Fit.

 

In summary, I think we're saying the same things, but not always hearing them. Maybe because my posts turn into tl;dr

[+DZ-Jay]

I don't see how anything I've said suggests this, but whatever.

 

I was objecting to the following comment from one of your previous posts, along with others with similar context:

 

So games designed to run on JLP boards will require those features.

 

I know what you are trying to say, that games designed to take advantage of JLP-only or LTO Flash!-only features will require those respective platforms to run, and that choosing those features is optional. However, the above comment doesn't say this.

 

In summary, I think we're saying the same things, but not always hearing them. Maybe because my posts turn into tl;dr

 

I don't think we're saying the same things, since one of my salient points is that compatibility across platforms may be more desirable for most games and thus it is important for everyone to understand that most future games will work on LTO Flash! as well as GroovyBee's and CC3, except when explicitly made not to by programmer or publisher choice. Granted, this choice could be in order to support a very desirable feature.

 

I do believe that we agree in many of the other points, so there's that.

 

Cheers!

-dZ.

Edited August 28, 2014 by DZ-Jay

[+intvsteve]

I should really remember that old joke about the word 'assume'. I assume that people will infer that when I say "So games designed to run on JLP boards will require those features." in sentence N, and said "..., unless they take measures to work around their absence." N-M sentences earlier, in the same post, that it would still be implied.

 

EDIT: N > M, M and N are both positive numbers.

Edited August 28, 2014 by intvsteve

[GroovyBee]

There are features on LTO Flash! that simply are not available on all other devices.

My Bee2/Bee3 also have features that JLP cannot support. My games are already using the RAM, flash and accelerated hardware features available in the BeeX BIOS.

 

If you use that serial port to communicate with the host PC, then you'll have to be running on hardware that supports this, and even likely require software on your host computer to be running, too. At this time, I know of only one platform with such a feature for use from CP1610 code, though maybe there's an obscure or undocumented feature of the IntelliCart or CC3.

In my opinion, serial ports are of limited use for multi-player games. The likelihood of collectors being close enough together to hook up two machines is pretty minimal. Even if they hook their machines up using TCP/IP via a PC host, it will still require a coordinated effort to find somebody else to play against. Never mind the developer adapting the game play for an indeterminate amount of network lag. That pretty much relegates such features in games to having novelty value and only being played at shows and events.

 

The serial port would have uses for getting data on/off the machine but a microSD card can be used for that too .

[Rev]

Intv multicarts.......FIGHT!

 

 

Sounds like a new fighting game. Sweet.

[+intvsteve]

I see the greatest value of the serial port being the development cycle for testing on hardware. I.e. build-deploy-test when you've got a console tethered to your PC and a tuner card. I've used my Intellicart for that kind of thing mainly because I didn't like fumbling w/ the SD card on my CC3 and diddling with the menu editor. Didn't have my CC3 set up for serial access and didn't need to in my case.

 

The build-deploy-test case is likely a big reason the CC3 kept the serial port, and probably why LTO Flash! has it, too. (intvnut will have to answer that.) But Joe likes to think big, so he augmented what could be done with it. He probably has all kinds of ideas.

 

You could even instrument "debug" builds of code and have a host-side monitor app for spying in case there are pesky hardware bugs that don't arise in emulators. Not being an experienced Intellivision programmer, maybe such a scenario is unrealistic, but I know around my day job the embedded systems guys do lots of debugging of their systems through the serial port.

 

Things like games or other apps making use of the serial port, I agree, will always have an extremely limited pool of interested parties, and would be software toys more than anything. But then, there are lots of creative people around here to come up with lots of new ideas.

[GroovyBee]

I see the greatest value of the serial port being the development cycle for testing on hardware. I.e. build-deploy-test when you've got a console tethered to your PC and a tuner card. I've used my Intellicart for that kind of thing mainly because I didn't like fumbling w/ the SD card on my CC3 and diddling with the menu editor. Didn't have my CC3 set up for serial access and didn't need to in my case.

I always used to copy my games to the CC3's microSD card (I say "used to" because the Bee3s need all the action they can get at the moment). Once you've created a new entry with the CC3 menu editor once, you only need to replace the *.rom in the microSD card's GAMES directory every time you update it.

 

You could even instrument "debug" builds of code and have a host-side monitor app for spying in case there are pesky hardware bugs that don't arise in emulators. Not being an experienced Intellivision programmer, maybe such a scenario is unrealistic, but I know around my day job the embedded systems guys do lots of debugging of their systems through the serial port.

I have a logic analyser that handles any kind of hardware debugging that I need to do. It means that the routines always run at full speed and they don't have to poll for hardware to TX anything (unless that is what the hardware is supposed to be doing ). Having the right test equipment makes strange hardware quirks and issues much easier to find. I gave up struggling with serial port debugging many moons ago.

[+intvsteve]

I just dislike the process of: build program, remove SD card, put in adapter, put in PC, browse to SD card folder (if OS can't remember where it was), copy file, say yes, I want to replace the darn thing!, remove SD card, remove from adapter, put in CC3 (or whatever ), lather rinse repeat. I'm too fatfingered for those tiny cards. My personal development style is highly iterative, so the physical process is a chore. A full-sized SD card removes two of those steps, and making a build script running on the command line to copy it to the SD assuming it's inserted does cut it down a little further, but you get my drift.

 

I prefer: Build program, click "Download". Hence using the Intellicart for my decrepit little projects.

 

What can I say, I'm a lazy guy, and too cheap to buy another SD card reader. (My wife's laptop, also used by the kids a lot, is the only thing we have w/ a reader, and it's a high-demand device.)

 

It's great you've got a logic analyzer. I'd say a large part of the pool of current and potential Intellivision developers are likely not experienced with, trained to use, or able to justify the expense of one, though you could probably get an old used one pretty cheaply.

 

I think we can all agree that if we can provide easy-to-use tools, and the experienced can offer guidance to the learners, the community will flourish.

 

Hopefully, we all will adequately document the features we support/implement on hardware and, where possible, attempt some sort of compatibility where possible / reasonable. To this point, the shipping products have, AFAIK, done this. How people writing programs choose to use those features, and cope with them being present (or not), is up to them once products go 'into the wild'.

[GroovyBee]

I just dislike the process of: build program, remove SD card, put in adapter, put in PC, browse to SD card folder (if OS can't remember where it was), copy file, say yes, I want to replace the darn thing!, remove SD card, remove from adapter, put in CC3 (or whatever ), lather rinse repeat. I'm too fatfingered for those tiny cards. My personal development style is highly iterative, so the physical process is a chore. A full-sized SD card removes two of those steps, and making a build script running on the command line to copy it to the SD assuming it's inserted does cut it down a little further, but you get my drift.

 

I prefer: Build program, click "Download". Hence using the Intellicart for my decrepit little projects.

I prefer "build program" and it copies the new ROM to the microSD card directly, no messing about with the GUI . All I have to do then is eject the card and try it out on the Inty. Its all down to personal development style at the end of the day because there is no right or wrong way to develop games.

 

What can I say, I'm a lazy guy, and too cheap to buy another SD card reader. (My wife's laptop, also used by the kids a lot, is the only thing we have w/ a reader, and it's a high-demand device.)

A collector for Inty can't afford $5-$10 for a new reader .

 

It's great you've got a logic analyzer. I'd say a large part of the pool of current and potential Intellivision developers are likely not experienced with, trained to use, or able to justify the expense of one, though you could probably get an old used one pretty cheaply.

99% of Inty developers will never need such a tool.