CBM prg Studio

[Shaun_B]

Click on my name and you will see it in my profile

Regards,

Shaun.

[ajordison]

I'm hoping to release version 3.1.0 of CBM prg Studio at the end of next week (I was supposed to release it at the end of last week but you know how it is...) and I thought I'd test the water by releasing a beta version today.

Here's what's new:
Code Snippets (a throwback to c64prggen!)
Improved VICE debugger support
New tutorial for mixing BASIC and machine code (thanks Shaun!)
Support for the Plus/4 in the screen code builder tool
Improved multicolour mode support for VIC20 projects (though technically a bug fix, not a new feature )
The usual raft of bug fixes.

Any feedback (especially bugs) you can give before the end of next week will be greatly appreciated. Please note that this is a test version, so don't let it loose on your prized source code!

Cheers,
Arthur.

[ajordison]

Here's a small update which fixes:
* a small 'incbin' problem which ignored some parameters if there was a comment on the same line.
* changing the sprite preview background colour changes the colour in the main design window.

Still on track for release on Friday 18th, barring any major bugs (cue major bugs!). There are two problems remaining that I know of:
* possible bug with starting programs in the VICE debugger, though I can't confirm it yet.
* The overall performance is poor with large projects. Adding new files is painfully slow so I'm going to spend a couple of days investigating that.

Once again, any problems you find in the mean time (nothing too major!) are appreciated.

Arthur.

[jrubin]

looks nice! wish there was a linux version

[ajordison]

Late as usual but version 3.1.0 of CBM prg Studio has been released. There's something for everyone in this version, including:

* BASIC Code Snippets.
* Improved VICE debugger support.
* Support for the Plus/4 in the screen code builder tool.
* BASIC 8 support for C128 projects.
* Improved multicolour screen designer support for VIC20 projects.

And of course not forgetting a ton of general bug-fixes.

As usual, many thanks to the testers, bug reporters and donators who helped with this release!

[MarcWalters]

I've been trying out Prg Studio. It's a nice program.

Requests:
1) Assembly editor: Code folding.
It would be nice to un/fold code for the following:
- At label at cursor
- All labels
- All Parent labels
- All Child Labels
- All labels except the one at cursor

2) Assembly editor: Multiple statements per line - separated by colon

3) 1) BASIC editor: Code folding.
It would be nice to un/fold code at a label. Maybe a directive that contains a description.

10 REM The next line will be a heading

Code: Select all

block - Display "Hello World"
20 PRINT "HELLO WORLD"
block_end
30 END

When folded, shows:

Code: Select all

10 REM The next line will be a heading
...block - Display "Hello World"
30 END

4) Assembly Compile
Basically a build without output to either memory or disk - useful for quick test to ensure no silly errors.

5) Build with external call
Calls a user-defined execution after a build, eg to VICE with parameter of the object file.

One bug was found:
In the text editor (assembly), if there is a tab between a label and instruction and that entire space is selected then TAB pressed, the tab is inserted before the label, which is unwanted behaviour.

STEP 1:

Code: Select all

LOOP                lda #00

STEP 2:

Code: Select all

LOOP[SELECTED]lda #00

STEP 3:

Code: Select all

<TAB>

Result:

Code: Select all

                 LOOP                lda #00

[satpro]

I've been trying out Prg Studio. It's a nice program.

Requests:

2) Assembly editor: Multiple statements per line - separated by colon

Nah, not that. Assembly programming is one statement per line. Always. Only. Use that left-over space for your comments.

[MarcWalters]

I've been trying out Prg Studio. It's a nice program.

Requests:

2) Assembly editor: Multiple statements per line - separated by colon

Nah, not that. Assembly programming is one statement per line. Always. Only. Use that left-over space for your comments.

I'm aware of the arguments for and against multiple instructions per line.
However, I've always used this feature of Brad Templeton's (look him up on Wikipedia!) PAL Assembler and have found it to bring practical benefits.

I believe logically relative instructions that act as a single unit benefit from such a grouping - as long as the group acts as a unit and the program does not jump into it.

For example, a Word move is a homogeneous block of code which should be able to sit on a single line. Actually, you will often find this does in other assemblers (eg GEOS) - as a macro instruction!

On a 25-line C64 display it is important to use as much screen real-estate as possible. If the entire "idea" of a code routine can be shown on a single screen, rather than just 25 instructions of that idea, then that assists both understanding AND readability.

Code: Select all

InitScrn lda <$0400 : sta $FB : lda >$0400 : sta $FC : rts

The question arises: Why is this any different from using multiple statements per line for BASIC?

Code: Select all

100 POKE 251,0 : POKE 252,4 : RETURN

versus

Code: Select all

100 POKE 251, 0
110 POKE 252, 4
120 RETURN

And what about mixed datatype records? With some whitespace padding they can be arranged in a very readable tabular form.

Code: Select all

Message_1 text "Hello World"
byte 0
word Default_Msg
byt 0,0,0
Message_2 text "Goodbye World"
byte 1
word Bye_Msg
byt 2,0,0

versus

Code: Select all

Message_1 text "Hello World"   : byte 0 : word Default_Msg : byt 0,0,0
Message_2 text "Goodbye World" : byte 1 : word Bye_Msg     : byt 2,0,0

And, finally, the following image shows what I think is a valid use. Note the arrangement of code.


Multiple statements per line can be valid. I rest my case.

[satpro]

Well, okay.

1) BASIC uses multiple statements per line because of the significant overhead present in each line, in addition to a slight speed advantage. So PAL did it that way because it was available as intrinsic to BASIC. Because of this "feature" you could make room for more source (but no speed advantage). Big advantage in cramming BASIC lines, although much less readable.

Cross-assembly (CPS) doesn't have the same space issue, and there is no speed advantage, so there is no need to cram source code. In my mind, this is a call for larger source codes, complete with comments, spaces, entire segregated sections, and mega-multiple include files. And more comments. In other words, each "grouping", as you call them, gets its own space. For data we can just use the comma to group things. For code, an empty line delineates the "space" between fragments.

To say that a multi-byte accumulator load or store is a group worthy of segregation is pushing the definition a bit. The 65816 does it in one shot. So what would you recommend after the colon on that line? Somebody would find something to put there.

The point is, it always leads to spaghetti code. For you, for me, for Arthur -- for everybody. We want to go in the other direction.

2) Now that you've introduced the colon as a statement separator in a cross-assembly program, could you recommend a new label marker? Most assemblers use the colon as a temp label, or even to symbolize a label AS a label. From the compiler's standpoint, a multi-instruction source line is now full of labels.

Can't rest yet, Marc. We need you back up on the stand...

[dudz]

i have to agree with that... multiple mnemonics in one line are terrible, and the only reason for the existance of that crap is that someone abused the basic editor for entering assembly code. yuck!