Classic99 Web Repository?

[Tursi]

This little suggestion from Retroclouds kind of caught my eye:

 

2) If going the web way, some kind of repository feature could be added where code can be exchanged or loaded

from the internet and then pumped directly into classic99.

 

I thought this was a pretty neat idea, though not so much thinking about tying it to the translator, but rather, an online repository where new code could be downloaded directly into Classic99 with a click.

 

Sort of a TI-99 app store.

 

I thought I'd break it out and see if that would be something people would support with software? I'm not thinking of getting into the nightmare of making anything that deals with money, so free apps only. But the idea would be a click built into the Classic99 menu that loads up the app store webpage (or you can load it directly), and when you click on an app, it loads it directly into the emulator.

 

In thinking about the mechanics of this - it's not that hard for the most part. I know how to do the interface. My web design skills are very HTML 1.0, but that's enough to get started till someone with more talent and ambition comes along. Certainly I'd have no problem if other emulators wanted to use it too.

 

For file format, we need something pretty generic and standardized.. to that end I am thinking RPK, which means I could not do it till I implement RPK support in Classic99. (Not too bad a deal though). I'd also want to add the memory types that Classic99 supports but MESS does not (although shipping everything as a cartridge image, even if it loads, isn't a big deal - I can release my TI BASIC tool and we can just as easily do one for XB). I'd also have to improve the cartridge interface so it's easier to load/save/create carts (maybe embed the TI BASIC/XB tools in the emu itself).

 

The idea would be to have a custom protocol handler to invoke the emulator. While I'd like to say "classic99://", it would probably be better to be more generic for everyone, and use "ti99emu://". Click the link, Classic99 launches and downloads the RPK, installs it and starts it. (Might be cool to have a thumbs-up button for liking the app, too).

 

This is all pretty straightforward, and might be a cool way to both reach people who are not in the community (I get lots of downloads from random people!), as well as provide a way for those people to get access to the new software being created.

 

So my question is, if we build it, will you come (and contribute your own software, new or old)?

[ti99iuc]

GREAT IDEA !!!!!! :DDDDDD

[Opry99er]

All my current software is at your disposal.... It's only 2 games and a couple tools, but please feel free to distribute them! "Lemonade Stand" and "Honeycomb Rapture" (Calimari Carl to follow soon) on the game side, and you're welcome to include my music tool as well, if you'd like. It's not much, but it works. This is cool!!!

 

Love to see this blossom.

[matthew180]

I must be an idiot. I've never heard of RPK (which does not mean much), and 20 minutes on Google turned up nothing that seems to fit the idea of a "generic and standardized" format. Lots of guns. Lots of DVD and CD ripping. Does anyone have a link to a resource that gives details on the format being talked about in this context?

[Opry99er]

RPK is the cart format used my MESS. It's basically a zipfile containing all the cartridge info and headers.

 

Of course there's probably alot more to it than that.... But that's essentially the premise.

Edited February 14, 2011 by Opry99er

[sometimes99er]

Sounds very nice. Would/should this work from different sites or just one main app store ?

 

How about use of simple File Type Association (.rpk) ?

 

Edited February 14, 2011 by sometimes99er

[Tursi]

Sounds very nice. Would/should this work from different sites or just one main app store ? How about use of simple File Type Association (.rpk) ?

 

File type association changes it from an integrated experience to downloading a file and launching it. Nothing wrong with that, and what most people are used to, but for the people I am thinking of, eliminating that one extra step would be a nice thing to do. In addition, I can put verification of the file into Classic99 before it's even saved to the disk (although I doubt I would put in much in the first pass), which is also a nice thing to have control over.

 

The link I'd embed in Classic99 would go only to my app store, but unless coded to reject such requests, I see no reason why the ti99emu:// handler would not work for anyone's site? It would be nice to have final apps centralized. But putting such a link on your own site would be good for betas or such things you didn't want the whole userbase to see by default.

 

Would I also need to include DSK support in the archive? Let me specify - in order to keep the experience to the end user as simple as possible, cartridge boot would be mandatory. It seems to me in that case, since we support 128k ROM and 640k GROM in a cartridge, that needing disk files probably won't come around (and I'll help people convert their software if needed!) But are there cases I'm not thinking of where disk file downloads would also be needed?

Edited February 15, 2011 by Tursi

[+OLD CS1]

DSK support would be great, if only for simplicity. It is quite a chore to extract a DSK into one of the Classic99 DSK folders using TI99Dir, even more so when frequently switching between disks. Possible, but not a easy as just opening a DSK file, whether contained within an RPK or stand-alone.

[marc.hull]

I for one think the more the merrier. Things like multiple sites tend to sort themselves out in the long run.

 

I do agree with Mike in that there are far tooooooooooo many formats and they tend to generate confusion. Since I have the suspicion that C99 will soon support .dsk floppy images in V9T9 format (correct me if I am wrong...) I would vote for that. Since TIDIR is so easy to use and supports the CF7 and variants the TIFILES format is a thing of the past and PC99 and it's odd format is used only by those who have and use PC99 which I imagine is far fewer than the C99 users.

 

I would recommend that those who do create these repositories do NOT allow open uploading to them. Otherwise you are going to end up with the same mess that WHT is in.

 

Additionally it would be the polite thing to do to contact the authors of the programs (if possible) to ensure that they have no objections to making their works available on your respective sites.

[Opry99er]

Good ideas, Marc. I agree that the PC99 format is (for the most part) obsolete. .DSK images cannot be transferred directly to a TI via XMODEM, therefore I think it's important that we continue to support the TIFILES format. For the purposes of this app-store, though, I believe that a uniform format (non TIFILES) is most certainly required... If Classic99 starts supporting .dsk format, I'm all in favor of that.

 

I really would like to learn more about what you guys are planning here... Are we talking about making everything a "C99-cart"? Not a technical cartridge with cart header and all, but a C99 specific "pseudo-cart"? That's an interesting idea. =) Would allow XB games to look like a cartridge on Classic99--- when in reality would simply be a LOADer that shows up in the cartridge select screen.

 

I'm silently listening from now on. =) Great discussion, guys.

[ti99iuc]

I for one think the more the merrier. Things like multiple sites tend to sort themselves out in the long run.

 

I Agree Too.

 

ote name='marc.hull' date='Tue Feb 15, 2011 5:10 PM' timestamp='1297786202' post='2210620']

I do agree with Mike in that there are far tooooooooooo many formats and they tend to generate confusion. Since I have the suspicion that C99 will soon support .dsk floppy images in V9T9 format (correct me if I am wrong...) I would vote for that. Since TIDIR is so easy to use and supports the CF7 and variants the TIFILES format is a thing of the past and PC99 and it's odd format is used only by those who have and use PC99 which I imagine is far fewer than the C99 users.

 

Yes, i agree in this too... i decide to use a C99 format only for my database software, and jpg and pdf for other database (manuals, magazines, advertisements ecc.)

 

I would recommend that those who do create these repositories do NOT allow open uploading to them. Otherwise you are going to end up with the same mess that WHT is in.

 

About this i agree too ... i can add people to upload material but must follow some policies to upload and no all people will can... also the scanning quality of the paper stuff is a BIG prerogrative on my idea of database.

 

Additionally it would be the polite thing to do to contact the authors of the programs (if possible) to ensure that they have no objections to making their works available on your respective sites.

 

about this is agood thing... but not always is possible to contact the authors and some time the authors do not answer, so i thinked to write on my site that who do not want his material online on my site can contact me and i will delete the material, think you it can be good ?

 

however i like a lot the idea to create a direct link to a database with classic99...

 

I OFFER my database link if TURSI want. I already programming a similar "market style" graphic interface (Android "Market" i'm not an "i-phonian"... i just like Apple Computer !).

[Tursi]

Since TIDIR is so easy to use and supports the CF7 and variants the TIFILES format is a thing of the past and PC99 and it's odd format is used only by those who have and use PC99 which I imagine is far fewer than the C99 users.

 

The TIFILES format will never be a thing of the past for me. I still hate disk images and am only going to support them by popular demand. I see no reason my "TI" (Classic99) with 1TB of disk at its disposal should be restricted to 10 character filenames, 127 files in a folder, or 90-360k per file. Using TIFILES files has always been how I've used my TI, since I've always interoperated with other machines.

 

But I have accepted that I am in the minority and will support everyone else too.

 

However, the V9T9 Files-In-A-Directory format needs to be taken out and shot. Enough with storing the "real" filename inside the file with obtuse renaming of the real file. I still can't correlate some files TI99Dir writes with the real filename, it's not using the rules that V9T9's documentation describes. Which makes it yet another format, unless someone can explain what I'm missing.

 

I would recommend that those who do create these repositories do NOT allow open uploading to them. Otherwise you are going to end up with the same mess that WHT is in.

 

Additionally it would be the polite thing to do to contact the authors of the programs (if possible) to ensure that they have no objections to making their works available on your respective sites.

 

While I do have some concern about order, I'll allow authors to submit their software (otherwise nothing will be on mine )... I'll probably keep an eye on it, I'll most likely need to test everything anyway so there'd be a short auth process. I will be asking that authors only upload their own work, my respository won't be for old commercial works (that would violate my license from TI, except for TI's own stuff.)

 

The reason I don't want my download system to be DSK based is not due to my dislike, however, but simply because there is no way for an inexperienced TI user to start a disk based program (except for XB autoload). I suppose, however, we could require that as a standard (and maybe require a fixed filename for E/A#5 which Classic99 can then autoload too). I'll consider this, I guess it's not much harder than cart to implement. One of my goals here is to support the casual user who doesn't know how to operate the machine.

 

I really would like to learn more about what you guys are planning here... Are we talking about making everything a "C99-cart"? Not a technical cartridge with cart header and all, but a C99 specific "pseudo-cart"? That's an interesting idea. =) Would allow XB games to look like a cartridge on Classic99--- when in reality would simply be a LOADer that shows up in the cartridge select screen.

 

This is more or less what I was considering -- although any Classic99 cartridge (pseudo or otherwise) could technically be built for the real machine. Look at the TI BASIC program loader that we built! Also, when doing my E/A Complete GROM, I coded a GROM DSR (based on CS1) that loaded program image files from GROM. I didn't end up using it, but it worked nicely, showing that you could port disk access to a cartridge loader with a couple of simple tweaks. (It had to be GROM because you can't put a ROM-based DSR into a cartridge, let alone a GROM-only cart ).

 

That said, I think you guys are convincing me to allow DSK images as well as RPK carts, so long as an identification and standard boot is enforced. Classic99 does make it easy for me to hack startups.

 

Last night instead of sleeping I was thinking about this, and rather than a web page, I was considering an integrated experience. That way my Linux adapter should be able to browse it on a real TI. That would be in lieu of the URL handler. Maybe. Not sure if I want to add the cartridge emulation hardware.

 

I haven't decided when I can start any of this yet anyway.

 

I OFFER my database link if TURSI want. I already programming a similar "market style" graphic interface

 

I like the idea of using existing web pages, of which there are a few fantastic ones, but they don't address the loading/format requirements in all cases. But what if I also included webpage links to direct people to these sites? Then everyone can browse and the more adventurous could dig deeper and learn to use it.

[Opry99er]

Awesome... this is a very cool idea. =)

[+retroclouds]

Nice. I'd really like to see support for .rpk images in classic99.

 

When I originally brought up the idea for this web stuff, I had in mind to have a virtual "DSKW" device in classic99 that is bound to some website (configurable using classic99 options or init file).

I changed the idea somewhat in regards to Matthews' translator software

 

Image doing a "OLD DSKW.XBGAME" and it'll load a file hosted by a webserver, doing save would store it there for the next to download.

 

I could imagine something like that could be possible using windows features and the WEBDAV protocol (WEBDAV)

Ofcourse that would bring up some questions regarding access permissions, etc.

 

Person A saves the program, person B old's it, changes a few lines and saves it again.

That would mess up persons A program (*)

Would be cool while working with multiple persons on the same program.

 

Ofcourse the appstore approach is very nice and I'd like to support it

 

(*) EDIT: Coming to think of it. Perhaps some kind of revisions could be handled on the webserver.

Edited February 18, 2011 by retroclouds

[Tursi]

Hmmm... I like the DSKW idea a lot too.... it would cost little to do.

 

Appreciate all the ideas and thoughts everyone. I'll let that percolate a bit and see what boils over.

[+OLD CS1]

Or something like FTP: on the Amiga. I suspect the "." parameter separator is etched in stone at some non-DSR level. I mean, could something like

 

OLD FTP:ftp.site.com/BASICPROG

 

be made to work? Or, something in Classic99.ini like

 

[DSK5]
Type=4     /* FTP */
Path=ftp.server.com/pub/ti-99/

 

Then DSK5 could be used to access the FTP site.

 

I dunno. Just thinking; if you are going to include WEBDAV functionality why not go ahead and include FTP functionality, since I know there are a bazillion ftp libraries out there. But, then there are also several CURL-like libraries which would allow for full URLs, like http:// https:// ftp:// etc.

 

Another thought is on-the-fly reconfiguration of Classic99 instead of having to reload the .ini. DSKx could then be configured while the program is running. I suspect that is a bit more difficult to implement.

[Tursi]

I try to keep the third party libraries in Classic99 to a minimum. They are a royal pain to support.

 

And yes, I know I need to add a configuration dialog. That's been on the list for 10 years. Classic99 doesn't have anything in the code that prevents it from changing config on the fly, it just hasn't been done in favor of features I actually needed. With 10 disk folders of unlimited size that can be manipulated in real time by Windows explorer, I don't need to real-time reconfigure the disk system. All you people who standardized on restrictive images instead are the only reason I've bumped that priority up.

 

It would be cute to allow FTP/HTTP, but that's a very different goal than what I'm talking about here, which is an interface for people who don't know how to use the machine that lets them get access to the new software people are producing.

 

Both may be achievable with minimal effort (probably not FTP, I'm about done supporting FTP servers after my years with SCWebCam, but the HTTP engine will need to be in there anyway!). This is some time out though.

[+OLD CS1]

All you people who standardized on restrictive images instead are the only reason I've bumped that priority up.

 

What do you mean, "you people"? I am one of those people who want .DSK support, but for me it is just so I can use the myriad DSK files out there, now. Saves having to extract it into a folder. You know, the fewer the steps the better, eh?

 

Look, it would be best if you just started coding all the features we want, lest we lock you in a basement. We demand features, buddy buwahahahahahaha!

 

In all seriousness, I know I speak for gobs of Classic99 users when I say, we appreciate all of your hard work.

 

/buttkiss-mode Carry on, folks.