we need an IDE for intybasic

[vprette]

Just remembering longtime ago me working on intelliware to have a gui supporting jzintv.. I really think now it would speed up newbye developers like me to have an IDE for the intbasic (text editor + pixel editor for intycolor + a Test button that compile and assemble and run the rom in one click)..

 

this can be done in visualbasic... any people would be interested to work on that?

 

atarians have Bataribasic IDE, we need to fill the gap :-)

Edited November 17, 2014 by vprette

[+Gemintronic]

As another path around the problem maybe we could find people familiar with already existing flexible IDEs like Scintilla, Eclipse and Notepad++. Make a template for intybasic instead of a whole new program.

[freewheel]

Other than the bitmap editing, I'm not sure what an IDE brings to the table. Right now I just click save in my text editor (which already does syntax highlighting, bookmarking, and collapsible "functions" (at a user-definable level), up arrow in a terminal window and enter. I guess 2 mouse clicks and 2 keystrokes could be combined into a single button... if you haven't already written a compile/assemble/run script for your OS, I highly recommend doing so. We discussed this in another thread recently - I run mine probably 100 times per day when I'm busy.

 

Although an IDE could be very useful if it could handle bitmap edits not just for screens, but MOB/card data in a larger sense. It'd be fairly complicated to implement this because much of it depends on "state" data that could be located elsewhere within the code.

[intvnut]

You mean a dozen or two xterms spread across half a dozen virtual desktops isn't an IDE?

 

FWIW, I think you will see some better integration among certain parts of the existing toolchain soon.

 

 

As another path around the problem maybe we could find people familiar with already existing flexible IDEs like Scintilla, Eclipse and Notepad++. Make a template for intybasic instead of a whole new program.

 

Indeed, it might be interesting to embed jzIntv as a simulator in Eclipse. I don't know if jzIntv has all the right hooks, but the code is certainly there. I don't really know my way around Eclipse development, though.

 

Some work was put into allowing jzIntv to be built as a library; that may help. Also, I've largely kept SDL dependencies to a handful of files, so it should be possible to reimplement those to some other API (ie. native Windows, for example) without too much impact on the core. Tim Lindner once did that with MacOS 9. (Gives you an idea how long ago that was...) I don't know if that helps or hurts the possibility of integrating with an IDE like Eclipse. I'm just throwing that out there in case someone with expertise in that domain happens to be reading.

[+Gemintronic]

For many people an already configured IDE is requirement #1. I myself didn't touch batari BASIC until VisualbB came out. It's hard to understand for some C and asm programmers. The BASIC crowd grew up with IDEs just *there*

[freewheel]

The BASIC crowd grew up with IDEs just *there*

 

The VisualBASIC crowd, perhaps

 

My experience is the opposite of what you describe - I can't get very far with C or anything more complex without a suitable IDE. Just way too much code and way too much to keep tabs on. But IntyBASIC? It's so simple than an IDE would basically be a glorified text editor with a "compile and run" button. Which of course is essentially what I'm using.

 

It would be a whole different story if someone came up with an IDE that could scan the source code and populate a bitmap editor with the various graphical data - and kept it aligned with DEFINE statements, MODE, all that good stuff. And a music/sound tracker/editor that emulated the PSG and allowed realtime adjustment of timing and pitch, reflected back in the code. Someone much smarter than me of course. Right now I suspect we're all doing a lot of cut and paste between various components.

 

I personally am well into a ream of scrap paper with hand-written notes, diagrams, storyboards, hex calculations, ideas, etc. If these were Keith Robinson's notes, some guys here would be shelling out big bucks for them. Sadly I doubt these will ever be lusted after.

 

Anyway I have only one request to the community at large - build what you want, how you want, I'll mostly keep my snarky comments to myself. But please, for the love of god, do not let IntyBASIC, jzintv, or as1600 become Windows-only. Fortunately I know we're good on at least 2 of those.

[intvnut]

For many people an already configured IDE is requirement #1. I myself didn't touch batari BASIC until VisualbB came out. It's hard to understand for some C and asm programmers. The BASIC crowd grew up with IDEs just *there*

 

You call these IDEs?

 

 

Ok, fine. They have the editor and the runtime all built into one integrated whole.

 

But seriously, I didn't experience something like a modern IDE with BASIC until I encountered QBASIC in MS-DOS 5. I found the QBASIC IDE annoying. It was always "correcting" my spacing on things and was generally annoying.

 

You might also find this ironic, but my first experiences with C and Pascal were in Borland's various IDE products. With C, I started in the IDE space. It was only later that I figured out that vi + gcc + command line worked better for me.

[intvnut]

 

Anyway I have only one request to the community at large - build what you want, how you want, I'll mostly keep my snarky comments to myself. But please, for the love of god, do not let IntyBASIC, jzintv, or as1600 become Windows-only. Fortunately I know we're good on at least 2 of those.

 

I can assure you that neither jzIntv nor AS1600 will become Windows only. I guess those are the two you're referring to. I'm typing this from my main computer, a Linux box. My Windows box died over a week ago. It's still dead. I actually can't do Windows builds of jzIntv or AS1600 right now.

 

And earlier this weekend, I sent a perl script to nanochess. Apparently, it didn't happen to run on his Mac due to a missing module. Again... I don't think Windows-only is something you need to worry about even there.

[freewheel]

Ironically I'm debating setting up my development environment on my Windows laptop, for the long flight to Maui in a couple of weeks. I normally never "work" on vacation, not even during flights, but this stuff is just so goddamn much fun.

[+DZ-Jay]

 

The VisualBASIC crowd, perhaps

 

 

QBASIC had an IDE, and it's far from VisualBasic. I'm just saying. And even the old C=64 had the runtime integrated into the editor, though that's a bit of a stretch.

[freewheel]

 

QBASIC had an IDE, and it's far from VisualBasic. I'm just saying. And even the old C=64 had the runtime integrated into the editor, though that's a bit of a stretch.

 

QBASIC and VisualBASIC appeared the same year, so the reference in terms of the BASIC crowd "growing up" applies exactly the same. I'm just saying. Many of us home computer kids had been programming in BASIC for nearly 15 years by the time IDEs arrived.

 

If you consider the C64 to have the runtime integrated with the editor, I'd argue that so does Windows/Linux/OSX. Finish editing, and run a completely different command to run your program - exactly as I have today. The real difference is that we have a compile & assemble step, which is unusual in a C64 context, to say the least. However that can be trivially built into the equivalent of the C64's "RUN" command (a 3 line compile and execute step), so it's really not that different.

[+Gemintronic]

 

You might also find this ironic, but my first experiences with C and Pascal were in Borland's various IDE products. With C, I started in the IDE space. It was only later that I figured out that vi + gcc + command line worked better for me.

 

Not ironic. It's proper for beginners to focus on learning the language rather than cobbling together their preferred IDE. Thus starting with Borland C with its ready-to-run IDE and then going to something more customized is natural. Same logic applied to intybasic.

[vprette]

starting with text editor, compile button and background window to bas code (intycolor) is good for newbie like me, but most of all will be a start point to integrate/develop more tools that we simply have not available now (sprite editor, a music keyboard that you sing and translates in intybasic notes?)

Edited November 17, 2014 by vprette

[+DZ-Jay]

Like intvnut, I learned C and Pascal using Borland's Turbo C and Turbo Pascal. And also like intvnut, I quickly moved to using a text editor and the command line compiler.

 

There are two reasons why I would use an IDE: syntax highlighting and integrated debugger and inspector/monitor. Syntax highlighting is just something I like very much. I even created a TextMate (my text editor of choice) language file for CP1610 Assembly and for the P-Machinery Framework. As much as I admire and enjoy the vast array of features in jzIntv, I rather have an integrated debugger and inspector where I can trace the source code and view the status of watches, registers, and memory access in a more intuitive interface.

 

-dZ.

[+Gemintronic]

Here's a BASIC IDE that provides source. Maybe someone could fork that and make the needed changes in commands. Remove the visual form builder aspects for now.

 

http://lbbuilder.sourceforge.net/features.html

[intvnut]

Like intvnut, I learned C and Pascal using Borland's Turbo C and Turbo Pascal. And also like intvnut, I quickly moved to using a text editor and the command line compiler.

 

There are two reasons why I would use an IDE: syntax highlighting and integrated debugger and inspector/monitor. Syntax highlighting is just something I like very much. I even created a TextMate (my text editor of choice) language file for CP1610 Assembly and for the P-Machinery Framework. As much as I admire and enjoy the vast array of features in jzIntv, I rather have an integrated debugger and inspector where I can trace the source code and view the status of watches, registers, and memory access in a more intuitive interface.

 

-dZ.

 

BTW, there's a feature in jzIntv that allows it to display your source code alongside the disassembly, and to watch variables by name rather than address. You may know about it, but I don't know if others in the thread do.

 

When you assemble, add two flags to the AS1600 command line: -s symfile -j sourcemap. When you run jzIntv's debugger, add two flags to the jzIntv command line: --sym-file=symfile --src-map=sourcemap. Example:

.

$ as1600 -o game -l game.lst -s game.sym -j game.smap game.asm
$ jzintv -d --sym-file=game.sym --src-map=game.smap game

.

Then, in a wide terminal¹ (wider than 80 columns, I recommend at least 140 columns, but 160+ works best), jzIntv will display your assembly source code alongside the disassembly. Also, commands such as 'w' for watch will understand the symbol names from your program. ie. "wVAR" for the variable "VAR" instead of "w123' for location $123. Likewise for 'b' and 'f' to set breakpoints or running forward to a specific location. The command "/foo" will find and list all symbols beginning with the string "foo", in case you forget exactly what some label was named.

 

It isn't as pretty as a "watch window", but it is more integrated than it was in the past.

 

I think you'll hear more about this feature in the not-to-distant future.

 

---------------------------------------------

¹On Windows, you can make the terminal wider with "MODE CON". Alternately, the > command in jzIntv's debugger will issue a MODE CON command for you. >150 will try to make the console window 150 columns wide. On Linux and Mac, just drag the terminal window to a wider width.