leuat / trse Goto Github PK

The Abs( number ) function currently only works for Bytes. Can it be extended to also work for integers if passed in and the number?

Give warnings/errors when using integers with methods that don't support integer values...

Using this code:

program MyProgram;
var  
	myNumber: integer;
   
begin
	myNumber := 1000;
end.

The assembler code generated is correct:

	; Assigning single variable : myNumber
	ldy #0
	; Integer constant assigning
	ldy #3
	lda #232
	
	sta myNumber
	sty myNumber+1

Now change the assignment to a negative: myNumber := -1000;

The assembler code is:

	; Assigning single variable : myNumber
	ldy #0
	lda #-744
	sta myNumber
	sty myNumber+1

When File->New File->Image/Charset/Sprite is opened as "C64 Sprite Editor" the program crashes with this output:

QMetaObject::connectSlotsByName: No matching signal for on_btnExportAsm_clicked()
QMetaObject::connectSlotsByName: No matching signal for on_lstImages_clicked(QModelIndex)
QMetaObject::connectSlotsByName: No matching signal for on_sliderX_actionTriggered(int)
QMetaObject::connectSlotsByName: No matching signal for on_btnPanLeft_clicked()
QMetaObject::connectSlotsByName: No matching signal for on_btnPanUp_clicked()
QMetaObject::connectSlotsByName: No matching signal for on_leExtraDataSize_textChanged(QString)
QMetaObject::connectSlotsByName: No matching signal for on_checkBox_clicked()

This is also true for "C64 Sprite Editor (deprecated type)" "C64 Multicolor Charmap", "C64 Regular Charmap" and "VIC20 Multicolor bitmap".

Tested with the 0.06.5 release from http://www.lemonspawn.com/turbo-rascal-syntax-error-expected-but-begin/downloads/ on Fedora 30 and with a manualy compiled version from github on Ubuntu 18.04.

BR,
Benjamin

Nice to have feature request:

While playing around, it would be useful to sometimes modify the ASM files and build and run them in the emulator. For example, while debugging or if I want to get some assembler code copied out into an ASM(" "); statement in TRSE later.

How easy is it to add a special build and run step that just works on the ASM file and ignores the original RAS?

FIxed

This empty program produces a larger ASM file because it is including routines for MoveTo and PrintDecimal even though these command do not exist outside of the comments:

program MyProgram;
var  
   index: byte; 
begin
	/*
	MoveTo(0,0,$04);
	PrintDecimal(result, 0); 
	*/
end.

Can comments be excluded completely from the compilation so that the resultant program does not contain unnecessary code?

Andy : please add this file when you have time! I'll just use a random .rtf in the meantime

Draw a character in the large zoomed window to the left. The Charset panel to the right does not show what you have drawn. However, if click in empty space (for example, the window background) the charset will refresh and show the changes. Also keys WASD will refresh the charset.

Choosing an uneven "Start Y" like 1, 3, 5... causes problems when drawing in the top row. It always draws two tiles: one in the top row, and one in the row above the top row (which shouldn't exist).

When I compile a RAS file it generates an ASM file. If I use Ctrl+R to run while the ASM file is in focus in the editor TRSE will crash without an error and close.

• IDE implementation : 90%
• M68K dispatcher : 10%
• M68K methods : 0%

I have a request for a small enhancement in the code editor:
Follow previous line indent after pressing Enter

The following declaration:

var
  arr : array[8] of byte = (1,2);

Generates the following assembly code, note that it has not filled out six extra zero's and the line ends with a comma:

arr dc.b 1, 2,

Would be preferable to reserve the amount of memory needed for the array if the user supplies too few values in the declaration, or to throw an error, to avoid unwanted bugs.

Hi,

When using the C64 Sprite editor and going to File->Save As the program crashes.
Here is the backtrace:
1 QString::append(QChar) 0x7ffff70126c0
2 QTextStream::operator<<(char) 0x7ffff71cbcb3
3 QDebug::maybeSpace qdebug.h 125 0x52ec8a
4 QDebug::operator<< qdebug.h 155 0x52ec8a
5 LImageIO::Save limageio.cpp 46 0x52ec8a
6 FormImageEditor::Save formimageeditor.cpp 352 0x48f486
7 TRSEDocument::SaveCurrent trsedocument.h 62 0x44cf63
8 MainWindow::SaveAs mainwindow.cpp 453 0x44cf63
9 MainWindow::qt_static_metacall moc_mainwindow.cpp 345 0x5fd0e1
10 MainWindow::qt_metacall moc_mainwindow.cpp 411 0x5fd923
11 QMetaObject::activate(QObject *, int, int, void * *) 0x7ffff716866c
12 QAction::triggered(bool) 0x7ffff7a91456
13 QAction::activate(QAction::ActionEvent) 0x7ffff7a93b12
14 ?? 0x7ffff7c18e42
15 ?? 0x7ffff7c2057e
16 QMenu::mouseReleaseEvent(QMouseEvent *) 0x7ffff7c215a2
17 QWidget::event(QEvent *) 0x7ffff7ad9fce
18 QMenu::event(QEvent *) 0x7ffff7c23b9b
19 QApplicationPrivate::notify_helper(QObject *, QEvent *) 0x7ffff7a97ad6
20 QApplication::notify(QObject *, QEvent *) 0x7ffff7aa11a3
...

BR,
Benjamin

When using copy and paste in the charset editor in 2x2 character mode, one of the chars is ignored:

Create a new project.
Now try to create a RAS source file. Nothing is created and no editor is opened.

To get around this, it seems I can open the newly create project from the file menu, I can then create a RAS source file

Check out QStandardPaths::AppLocalDataLocation

Can some debugging support be added as an option when running in VICE?

Having observed another C64 dev tool, it calls VICE with the following command line:

-moncommands "C:\path\file.dup" "C:\path\file.prg"
The dup file is in the following format:

;labels
al $0810 .start
al $087B .gameLoop
;breakpoints
break $0AE2

Would require a way to set breakpoints in the editor - would be ideal if when you set a breakpoint in the RAS file and built the ASM version, that is showed the breakpoint there also.

The VICE monitor is pretty handy when you want to understand what memory or registers look like at a certain point, potentially deep within the course of running the game/demo.

If you select a smaller screen width and, for example, a "Start X" value of 2, the first two columns are "wrapped", so placing tiles in the first two columns also places tiles in the last two and vice versa.

Have sent you the full description by email.

in the isOverlapping command, the last line is to assign the value in A into a variable called result.

The ASM that TRSE generates is correct:

sta result

However, in VICE, the resultant code is:

sta $4e ; 4e is one of the zero page pointers.

New feature request:

TRSE currently implements a FOR loop like the following C loop:

FOR i := 0 to 5 DO < -- > for(int i = 0; i < 5; i++)

The TRSE behaviour of the FOR loop is to count 0,1,2,3 and ending at 4. The traditional Pascal behaviour of a FOR loop would return 0, 1, 2, 3, 4 and 5 before ending.

Add a new command called FORI - FOR Inclusive that uses the traditional Pascal Behaviour.

This will prevent existing code from breaking and offer the developer a choice based on their preference.

Hi,
i use archlinux and i3 window manager and for some reason the TRSE crashes on project open. Is it possible the run the stuff from CLI?

need streamnlining, such as parameter explanations

When viewing help page for CopyImageColorData no information is shown. There is a CopyImageColorData.rtf file with content that should be displayed.

The FOR DO loop with STEP is not working correctly.

program MyProgram;
var  
   index: byte; 
begin
	moveto(0,0,$04);
	
	for index := 1 to 10  do
	begin
		screenmemory[index] := 1;
	end;
	loop();
end.

The above code should start at 1 (it does) and end at 10 (it ends at 9). There are 9 A's printed on the screen.

program MyProgram;
var  
   index: byte; 
begin
	moveto(0,0,$04);
	
	for index := 1 to 10 step 2 do
	begin
		screenmemory[index] := 1;
	end;
	loop();
end.

The above appears to 'miss' the 10 (as step 2 is 1, 3, 5, 7, 9, 11 ...) and displays many more A's on screen. It is testing for index == 10 rather than index > 10 to stop the loop.

	lda #10
	cmp index
	bne for6334

Assembler output from the above code.

program MyProgram;
var  
   index: byte; 
begin
	moveto(0,0,$04);
	
	for index := 2 to 10 step 2 do
	begin
		screenmemory[index] := 1;
	end;
	loop();
end.

The above hits the 10, but same issue as the first example, there are only 4 A's on screen.

Hi,

When using the C64 Sprite Editor on a resolution of 1366x768 (16:9) the bottom of the screen can't be seen (missing bottom check boxes) nor can it be resized to fit the screen.
p.s. Using Gnome3 DE on Fedora 30.

BR,
Benjamin

Image editor document %(¤/&%ups up with high-resolution scaling

The following code with an integer condition always returning true:

program MyProgram;
var  
   v1: byte; 
   v2: integer;
begin

	v1 := 2;
	v2 := 2;
	
	moveto(20,12,$04);
	
// this works
	if v1 = 2 then screenmemory[0] := 0;

// this returns true no matter what value v2 is:
	if v2 = 1 then screenmemory[1] := 1;
	if v2 = 2 then screenmemory[2] := 2;
	if v2 = 3 then screenmemory[3] := 3;
	if v2 = 4 then screenmemory[4] := 4;

	loop();

end.

The assembler code:

	; Binary clause INTEGER: EQUALS
binaryclauseintegerlbl128703
	lda #1
	jmp binaryclauseintegerfinished31322
binaryclauseintegerlbl223811
	lda #2
binaryclauseintegerfinished31322
	cmp #1
	beq ConditionalTrueBlock25667
	jmp elsedoneblock17035
ConditionalTrueBlock25667
	; Assigning single variable : screenmemory
	lda #4
	ldy #4
	sta (screenmemory),y
elsedoneblock17035

Example:

Type Abs( in the text editor.

Place the cursor at the start of Abs, or between the A and B or B and S and pressing the F1 key brings up the correct help topic.

Place the cursor at the end of S and before the ( and press F1 brings up an empty help topic.

Documenting Atan2. I can see param 1 and 2 are x1 and x2, param 3 and 4 are y1 and y2.

Byte
First, there is an issue that all parameters appear to be bytes, If either the X or Y parameters passed to Atan2 are integers, it only passes the low byte value.

atan2_x1    .byte 0
atan2_x2    .byte 0
atan2_y1    .byte 0
atan2_y2    .byte 0

For common usage the X parameters are likely to come from sprite positions which is too small for a byte. Is it possible to extend this function to support integers, or should I add a note that the x and y pos should be scaled by half to both fit into a byte under these conditions?

Return values
Second, to confirm, if I define angle as a byte, the results are returned as a byte value scaled between 0 and 255 to represent angles 0 through 360?

	; Assigning single variable : angle
	; Call atan2
	; integer assignment NodeVar
	ldy xpos1+1 ; Next one ; optimized, look out for bugs
	lda xpos1
	sta atan2_x1
	; integer assignment NodeVar
	ldy xpos2+1 ; Next one ; optimized, look out for bugs
	lda xpos2
	sta atan2_x2
	lda ypos1
	sta atan2_y1
	lda ypos2
	sta atan2_y2
	jsr atan2_call
	
	sta angle

With the TRSE code below, adjusting the x and y values result in the following:

x1  y1  x2  y2  result
----------------------
100 100 200 100  0  - position 2 is to the right of position 1
100 100 100 200  63 - position 2 is below position 1
100 100 0   100  127 - position 2 is to the left of position 1
100 100 100 0    192 - position 2 is above position 1

Angle value of 255 is the maximum returned before it returns to 0.

However, if I define angle to be an integer, I get very different results:

x1  y1  x2  y2  result
----------------------
100 100 200 100  256 - position 2 is to the right of position 1
100 100 100 200  63 - position 2 is below position 1
100 100 0   100  1407 - position 2 is to the left of position 1
100 100 100 0    704 - position 2 is above position 1

When angle is an integer, it is loading it with the A and Y registers in the asm produced:

	; integer assignment NodeVar
	ldy angle+1 ; Next one ; optimized, look out for bugs
	lda angle

Should byte values only be used for the returning angle, or is there a bug and integers are supported?

Here is the test TRSE program:

program MyProgram;
var  
   x1, x2 : integer; 
   y1, y2, angle  : byte; 
   
begin

	ClearScreen(32, ^$0400);
	
	x1 := 100;  y1 := 100;
	x2 := 200;  y2 := 100;

	angle := Atan2(x1, x2, y1, y2);

	MoveTo(0,0,$04);
	PrintDecimal(angle, 6);

	Loop(); 
	
end.

During some testing, I found that the assembler in TRSE crashes the program when a reference is missing. In this case screenmemory is not defined. Think might be related to that duplicate label crash where you mentioned it was run in another thread. Might be a thread safe issue.

Here is some example code that crashes on my Windows set up:

 processor 6502

	ORG $801
	.byte    $0E, $08, $0A, $00, $9E, $20, $28
	.byte   $32,$30,$36,$34
	.byte    $29, $00, $00, $00

	ORG $810

MyProgram
	jmp block41
index	dc.b	
TL	dc.b 0, 1, 2, 3, 
TR	dc.b 3, 5, 6, 7, 
BL	dc.b 8, 9, 10, 11, 
BR	dc.b 12, 13, 14, 15, 
 ; Temp vars section
 ; Temp vars section ends
block41

	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	; Tile tl,tr,bl,br, tileno, screen_width
	ldx #$3
	lda TL,x
	sta screenmemory
	jmp * ; loop like (?/%
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop
	nop

EndSymbol

When I introduce screenmemory = $0400 it no longer crashes.

http://ffd2.com/fridge/math/fastmult?fbclid=IwAR0B6ITmPVsXHZ-AQGKPtstebDdWDRdIyIm_pHzLtYk34sg7-2fP281SMmk

Be able to correctly drag / resize window

Would be handy to have a zoom in option on the memory maps so can read the smaller sections.

There are some actions that should update either the drawing window or the preview, but they only update after additional actions (like pressing a key)

Some examples:

• In the charset editor, copy and paste of chars won't update the charset display. It updates when pressing the return key afterwards.
• Actions in the drawing window generally don't update the respective character in the charset display. The sprite editor does that correctly, but the charset editor doesn't.
• The "Levels" tab of the level editor. The level thumbnails don't update correctly and the whole section is completely empty the first time I click on it, as if there were no levels. And in reverse, the drawing window doesn't update when I select a different level.

There might be more, but I haven't checked every possible action.

Consider:

program MyProgram;
var  
	myNumber: byte;
   
begin

	ClearScreen(32, ^$0400);
	
	myNumber := -1;

	MoveTo(0,0,$04);
	PrintDecimal(myNumber, 6);
	screenmemory := screenmemory + 40;
	PrintDecimal( Abs( myNumber ), 6);

	Loop();
	
end.

The output is:

255
002

Should the Abs value returned be 001 ?

First of all, thank you for this software! It's surprisingly powerful, considering it's still in an early stage. It's more convenient than coding in assembly, but it still gives you full control over the hardware and avoids bloat. Well done!

I have a couple of usability suggestions for the drawing tools like sprite editor, level editor etc.:

• When I resize the window, the graphics display is stretched. I would prefer it if the aspect ratio was kept, so I don't get a wrong impression of the proportions while drawing.
• For similar reasons, it would be great if there were (optional) fixed zoom levels (x2, x3, x4 etc.) independent from the window size, to avoid uneven pixels due to scaling.
• An option to swap colors ("Multicolor 1 <-> Foreground" etc.) could be extremely useful. Especially in the early stages of game development there's often a lot of experimentation with colors.
• Being able to change the order of the sprites (without countless of copy&paste actions) would be great.
• Maybe in future the level editor could support different tile sizes, so that it's not limited to 2x2, but can also use 1x1 or 3x3 characters per tile?

Extend the help system to include descriptions for constants.

Create the RTF files.

Investigate if can extend to reserved words and a new Platform category for help on the language and platform specific documentation.

Negative values for STEP currently do not generate the correct code:

program MyProgram;
var  
   index: byte; 
begin
	moveto(0,0,$04);
	
	for index := 10 to 2 step -1 do
	begin
		screenmemory[index] := 1;
	end;
	loop();
end.

This generates the following which is almost correct (stopping after 3):

for6334

	; Assigning single variable : screenmemory
	lda #1
	ldy index
	sta (screenmemory),y

	dec index
	lda #2
	cmp index
	bne for6334
forLoopDone19169

However, set the STEP to -2 and the same assembler code is generated:

program MyProgram;
var  
   index: byte; 
begin
	moveto(0,0,$04);
	
	for index := 10 to 2 step -2 do
	begin
		screenmemory[index] := 1;
	end;
	loop();
end.

for6334

	; Assigning single variable : screenmemory
	lda #1
	ldy index
	sta (screenmemory),y

	dec index
	lda #2
	cmp index
	bne for6334
forLoopDone19169

dec index instead of a SBC #2

The assembler is having a problem with:

sbc #$c

When observing in VICE, can see it has been created as:

sbc #$14

(Have sent you a more detailed email with the example code)

There are three constants called VIC_DATA_LOC - Vic20, C64 and C128.

The help section only brings back one instance.

Also some others such as SCREEN_CHAR_LOC.

Can a fix be created to load the correct value for the build target; VIC20, C64, C128 ?

This is in connection to something I am trying to do elsewhere, and is probably occurring in several places for PureNumeric parameters.

nop(4+10);

the 4+10 part causes the assembler to crash and shut down TRSE (tested on Windows).

This is a low priority, but wanted to mention in case useful further down the line.