Can IntyBASIC be run in a "Cloud" environment?

[First Spear]

I spent way too much time thinking about this when I should have probably been doing other things..

 

I skimmed a few sites here and here and here and there, as well as re-reading DZ-Jay's input, and think that this could work.

 

1. Run on a free-tier Azure website, which gives a mini VM running IIS with 1gb of disk.
2. Put the Win32 versions of the jzIntv and IntyBASIC SDK bits in a directory of the web server.
3. Set up a source tree structure in the VM's space with a minimal layout for multiple files and versioning.
4. Create 1-2 page web app (simple name/pass authentication) that allows user to write IntyBASIC text with Xinha editor or something similar.
5. Add another page with 1-button compilation/linking/etc to build IntyBASIC code written.
6. Add button/dropdown/etc controls to select from a list of built ROMs. Selected ROM item is packaged into a floppy image and DOSBOX is launched along with parameters to use one jzIntv and the "ROM floppy". It might even be possible to keep the DOS environment running with just a "disk change" cycle to make re-running faster with a different floppy.

 

I could imagine writing code in one window and executing in another. The prospective IntyBASIC developer would have to know relatively little about IntyBASIC/AS1600/etc internals to get started.

 

 

Legwork cost - fairly high.

Dollar cost - $0.

 

 

I think that covers the OP's original intent - create something with IntyBASIC from home or work, centralized cloud-housed content, and a way to test/run his stuff without messing with local system configuration.

 

 

 

 

 

 

 

 

I had gotten the impression that the suggestion for DOSBOX was due to the fact it's been ported to run entirely in a browser, so that setup could be done once by someone knowledgeable, and then you could run that wherever you had access to a reasonably modern browser.

 

Sure, the way you put it sounds entirely unreasonable. But, given that DOSBOX has been used to great effect preserving other DOS-era games for average web users over at the Internet Archive, I don't think the suggestion was unreasonable at all, provided that someone knowledgeable sets up the DOSBOX to begin with, so that many others can come and use it. Of course, not everyone knows about the DOSBOX port, so there's that.

 

I do wonder, though, how you get files in and out of the "box." All of the DOS-era games on Internet Archive are self contained so far as I can see.

 

[freewheel]

The prospective IntyBASIC developer would have to know relatively little about IntyBASIC/AS1600/etc internals to get started.

 

 

You don't really need to know anything about IntyBASIC/as1600 internals to get started. You need to be able to a) open a command prompt, and b) type in a command with a few options - and the entire commands can be provided trivially for a default case (ie: test.bas test.rom or what have you). It's literally cut-and-paste compiling. With the SDK it should be even easier.

 

I literally dumped everything into a single folder and compiled and assembled within seconds, the first time I tried this. Maybe we're over-complicating things for people by suggesting they setting up PATH environment variables and worrying about project folders and explaining opening debugging sessions and whatnot. If you stick all the executables in one place, and save your source file to that same place, there isn't anything else you need to know. Save text file, run these 3 commands, boom your game appears in front of you. It's messy, but it works. And it's really only confusing once people start writing a few dozen games and you end up with a whole ton of files.

 

The far more complicated part is reading through the rather long IntyBASIC manual and figuring out just what the heck to put in your source file to begin with

[First Spear]

I think we are on the same page. Actually putting the IntyBASIC compiler inside a website as I thinly described would require putting everything inside a single directory, since you'd have no control where the "site" was physically stored in the cloud (rack to rack or zone to zone).

 

I guess you are right that someone would "only" have to know the command line, and as someone who has at least 2 open minimum at any given time I agree, but perhaps the folks that could be reached would be a larger audience that have no command line familiarity at all.

 

 

 

 

 

You don't really need to know anything about IntyBASIC/as1600 internals to get started. You need to be able to a) open a command prompt, and b) type in a command with a few options - and the entire commands can be provided trivially for a default case (ie: test.bas test.rom or what have you). It's literally cut-and-paste compiling. With the SDK it should be even easier.

 

I literally dumped everything into a single folder and compiled and assembled within seconds, the first time I tried this. Maybe we're over-complicating things for people by suggesting they setting up PATH environment variables and worrying about project folders and explaining opening debugging sessions and whatnot. If you stick all the executables in one place, and save your source file to that same place, there isn't anything else you need to know. Save text file, run these 3 commands, boom your game appears in front of you. It's messy, but it works. And it's really only confusing once people start writing a few dozen games and you end up with a whole ton of files.

 

The far more complicated part is reading through the rather long IntyBASIC manual and figuring out just what the heck to put in your source file to begin with