Page 13 of 16

Re: CBM prg Studio

Posted: Sun Mar 26, 2017 2:10 am
by ajordison
Thanks for spotting the broken link. :wink:

Re: CBM prg Studio

Posted: Mon Mar 27, 2017 10:05 am
by tonyrocks
thanks for the update! Love this Studio!

Re: CBM prg Studio

Posted: Sun Apr 09, 2017 9:13 am
by Kakemoms
Hi

I have problems with getting a basic program and assembly program to build together (in current version). Is it a bug or am I doing something wrong? Both "Determine build order from source files" or "Use specified build order" only results in launching the basic program. There is no assembly building going on since I have a couple of errors in the code (and they do not show up in the error list).
If I select "Use specified build order", then try to build, then go into "Project properties again" I get a message saying "Programs in the project cannot have the same start address or line number". The specified build order is then shown as empty.

My assembly program starts at $2000 while the basic program ends much sooner than that. My guess is that the interpreter sees that as overlapping since the basic area spans all of the $1200-$8000 memory?

How can I get around this?

Edit: Even putting the assembled program at $A000 results in the same problem; only the basic program will be included in the resulting prg.file.

Re: CBM prg Studio

Posted: Sun Apr 16, 2017 8:28 am
by ajordison
Hi,
Sorry for the late reply, I've had a broken router which has only just got fixed. As for your problem, a couple of other users have reported problems with building mixed projects and it's my top priority to get fixed.

Arthur.

Re: CBM prg Studio

Posted: Sun Sep 17, 2017 3:00 pm
by ajordison
Well it's long overdue but version 3.11.0 of CBM prg Studio has been released!

The complete list of bug fixes and new features is on my website.

Thanks again for your continued support of this project!

Re: CBM prg Studio

Posted: Thu Jan 04, 2018 12:24 pm
by LoadError
I've just discovered about this app and I won't be going back now that I am using It. Thanks!

EDIT: unfortunately I've just stumbled upon a problem. Up until yesterday, all was fine. Today I did some minor edits to the BASIC code (in the BAS file).
Now every time I try to renumber this file I get an exception: "index out of matrix bounds" (translated from Italian).
The renumber does not take place, and I get the chance to abort or to continue.
If I build the BAS to PRG and open the PRG in CommodoreEditor, it renumbers just fine.

EDIT: problem found by the developer, will be fixed in the forthcoming release, thanks mate!

Re: CBM prg Studio

Posted: Sat Jan 13, 2018 11:00 am
by ajordison
Beat those post-Christmas blues with a new version of CBM prg Studio! Head over to http://www.ajordison.co.uk for details.

Thanks again for your support with this project!

Re: CBM prg Studio

Posted: Mon Jan 15, 2018 10:53 am
by tonyrocks
As always, thanks again for your hard work! I enjoy every new release!

Re: CBM prg Studio

Posted: Thu Jan 18, 2018 11:05 am
by LoadError
Good. I've upgraded, and the bug I wrote you about seems solved indeed. Thank you.

Re: CBM prg Studio

Posted: Sun Mar 04, 2018 5:20 am
by Xerra_
This program is one of the best things I've ever used. I loved tinkering with it in the days when I still used a Windows system at home. I wish it wasn't written in VB.Net so the author could maybe do a Mac port.

Re: CBM prg Studio

Posted: Sat Apr 14, 2018 12:12 am
by Kakemoms
Looks like I found a tiny bug in the "Generate SYS() call".

It gives a SYS call that starts at $1201, even if you have chosen Vic 20 without expansion, in which Basic starts at $1000.

Correct should be that it starts at $1001.

Edit:
Another bug with instruction CMP:

CMP $0000,X does not assemble but gives an error.
CMP $1000,X on the other hand assembles ok.

Both bugs are for version 3.1 of CBM prg Studio.

Re: CBM prg Studio

Posted: Sat Apr 14, 2018 4:32 am
by ajordison
Are you sure it was in version 3.1? CBM prg Studio is at version 3.12.0 at the moment. I'll check the bugs you mentioned though.

Re: CBM prg Studio

Posted: Sat Apr 14, 2018 2:00 pm
by Kakemoms
ajordison wrote:Are you sure it was in version 3.1? CBM prg Studio is at version 3.12.0 at the moment. I'll check the bugs you mentioned though.
Oh sorry, its version 3.12.

Re: CBM prg Studio

Posted: Sun Apr 15, 2018 5:15 am
by ajordison
Does your source code have a start address in it (like *=$1000)? CBM prg studio will look for a start address in the source before it tries to form an address from the machine type.

Also, this program assembles fine on my version:

00001 0000 *=$1000
00002 1000
00003 1000 D5 00 CMP $0000,X ;DOES NOT ASSEMBLE BUT GIVES AN ERROR.
00004 1002 DD 00 10 CMP $1000,X ;ON THE OTHER HAND ASSEMBLES OK.
00005 1005

Have you turned the zero page optimisation off? Even if you have you will only get a warning, not an error. Can you post the error here?

Re: CBM prg Studio

Posted: Sun Apr 15, 2018 9:56 am
by Mike
ajordison wrote:

Code: Select all

00003 1000 D5 00 CMP $0000,X ;DOES NOT ASSEMBLE BUT GIVES AN ERROR.
IMO, when a programmer writes "CMP $00xx,X" - or any other similar instruction with the high byte of the operand explicitly set to zero - in cold blood, without any involved symbols, that instruction should be assembled with *absolute* address mode, and not zero page. It ought not matter, whether "zero page optimization" is enabled or not. With numeric addresses in hex, ZP mode should only be enabled for two-digit hex operands.

As you know, on the NMOS 6502, ZP indexed operands wrap after $00FF, whereas ABS indexed operands do not. They have different semantics! So, when the programmer wrote "<mnemonic> $00xx,X" or "<mnemonic> $00xx,Y", he most probably meant it this way, and this leads to very difficult to find "bugs" (which actually are caused by a design fault in the assembler for this case here), when other parts of the code actually rely on the non-wraparound behaviour of ABS,X/ABS,Y, but don't find their data there if they then use "<mnemonic> $01xx" to retrieve it (quite apart from those unsuspecting ZP addresses being 'shot' by the unintended wraparound).

Just my 2 cents.