georgrottensteiner/c64studio

C64Studio is a .NET based IDE specializing in game development for the C64 in assembler and BASIC

c64studio's Issues

Moving watched addresses may result in OutOfRangeException

Moving watched addresses during debugging may result in OutOfRangeException

************** Ausnahmetext **************
System.ArgumentOutOfRangeException: Der Index muss sich innerhalb der Listenbegrenzung befinden.
Parametername: index
bei System.ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument argument, ExceptionResource resource)
bei System.Collections.Generic.List`1.Insert(Int32 index, T item)
bei C64Studio.DebugWatch.moveDownToolStripMenuItem_Click(Object sender, EventArgs e)
bei System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
bei System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
bei System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
bei System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
bei System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
bei System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
bei System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
bei System.Windows.Forms.Control.WndProc(Message& m)
bei System.Windows.Forms.ToolStrip.WndProc(Message& m)
bei System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Feature Request: Allow debugging in C128 VICE as well

It would be nice to debug in C128 VICE as well.

Add Breakpoint - not added to source window.

When clicking Add in the Debug Breakpoints window, the breakpoint is not added to the source window.

The source window is showing the addresses for the instructions. Even when the debugger is started, the breakpoint is not added to the window. However, it does get hit.

I'm looking into this, but don't yet have a pull request.

!basic directive only works with * = $0801

According to documentation it should be able to cope with other start addresses

This pseudo op adds a BASIC start line with a sys call to either the given jump address or the first statement after the pseudo op. If not provided otherwise the added BASIC line always has line number 10 and a 4 digit target address. This way the BASIC line will always require 12 bytes. If the jump address is 5 decimal digits the line will use 13 bytes.

Support Shift+Delete / Shift + Insert in the editor as 2nd default

Every editor I used in the last twenty years or more supported "Shift + Delete" to cut text into the clipboard and "Shift+Insert" to paste text from the clipboard. I figured this was a a de facto standard that has its roots in early terminal simulations, made it into the IBM Common User Access standard and is one of the two default key bindings (in addition to Ctrl+X / Ctrl+V) in Windows from the very beginning.
So it feels crippling to use the editor without these key bindings. I'm aware that I can redefine the key bindings but this way I lose the other default binding (Ctrl+X / Ctrl+V) which I use as well depending on the situation.
In a nutshell: would it be possible to support both default key bindings? Or at least let users define more than one key binding for a function?

win10 and a charset editor problem

seems the charset editor when selecting chars to edit has an issue when selecting which char to edit. When edited it doesn't to seem to show the edits as well. if you look at the attached jpeg you will see selecting the chars is just weird and that the screen to display is tiny

:( running 6.6 on window 10.

User interface text appears blurry on Windows 10

I ran the program under Windows 10, and the UI text appears blurry. This degrades the general UI experience. It would be great if you could fix that, and make the text crisp as one would expect from ordinary Windows applications.

C64 Studio on Linux using mono

So, i tried running mono to run it on linux (Peppermint 10/Ubuntu 18.04) I tried mono version 4.0.30319 yet i get an error
WARNING: The runtime version supported by this application is unavailable. Using default runtime: v4.0.30319
and
System.TypeInitializationException: The type initializer for 'FastColoredTextBoxNS.SyntaxHighlighter' threw an exception. ---> System.EntryPointNotFoundException: GetSystemInfo at (wrapper managed-to-native) FastColoredTextBoxNS.PlatformType.GetSystemInfo(FastColoredTextBoxNS.PlatformType/SYSTEM_INFO&) at FastColoredTextBoxNS.PlatformType.GetOperationSystemPlatform () [0x00047] in <0d9fcb1bad554078b5d9ad35a6a4ab2f>:0 at FastColoredTextBoxNS.SyntaxHighlighter..cctor () [0x00000] in <0d9fcb1bad554078b5d9ad35a6a4ab2f>:0 --- End of inner exception stack trace --- at FastColoredTextBoxNS.FastColoredTextBox..ctor () [0x00261] in <0d9fcb1bad554078b5d9ad35a6a4ab2f>:0 at (wrapper remoting-invoke-with-check) FastColoredTextBoxNS.FastColoredTextBox..ctor() at C64Studio.ReadOnlyFile.InitializeComponent () [0x0001b] in <d0837c83ae2c499e83966c738906d72b>:0 at C64Studio.ReadOnlyFile..ctor (C64Studio.StudioCore Core) [0x00014] in <d0837c83ae2c499e83966c738906d72b>:0 at C64Studio.OutputDisplay..ctor () [0x00000] in <d0837c83ae2c499e83966c738906d72b>:0 at (wrapper remoting-invoke-with-check) C64Studio.OutputDisplay..ctor() at C64Studio.MainForm..ctor (System.String[] args) [0x00000] in <d0837c83ae2c499e83966c738906d72b>:0 at (wrapper remoting-invoke-with-check) C64Studio.MainForm..ctor(string[]) at C64Studio.Program.Main (System.String[] args) [0x0000b] in <d0837c83ae2c499e83966c738906d72b>:0

UI request: keep current place in document when using "Replace All" in Find/Replace.

It would be handy if Find/Replace didn't jump you back the the start of your document when you hit Replace All.

SocketException when Debugging

I am using C64Studio 6.1 and when attempting to Debug, getting the following error:

RemoteDebugger.Connected Exception:System.Net.Sockets.SocketException:
  No connection could be made because the target machine actively refused it 127.0.0.1:6510
   at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)
   at C64Studio.VICERemoteDebugger.Connected(IAsyncResult iar)

The error appears in the Output panel before Vice window is shown.

I was wondering, if it would help to add a (configurable) wait and/or timeout before attempting to connect to the debug socket.

Delete Breakpoint Button - breakpoint not removed from source window

While in the Debugging Broken state, deleting a breakpoint from the Debug Breakpoints window does not remove it from the source window.

Latest versions of WinVICE don't seem to work in combination with C64 Studio

I can't get latest versions (GTk or SDL) to work. When I try to build an run I get an exit code 1. Tried several versions but all show give the same error.

64tass/tasm support

while im posting .... any chance you can support c64tass tasm syntax/pseudo commands please ... pretty please with cherries on top :D

wishful thinking

Watch entries cannot be deleted permanently

C64 Studion 6.9, while debugging assembly files.

Once entries have been added to the watch window, they cannot be deleted permanently. You can remove entries temporarily during a debug session, but changes aren't saved, when the session ends. Entries reappear when restarting the debug session or after saving and quitting out of C64 Studio and reopening the project.

I took a brief look at the source code of C64 Studio and it seems like watch entries are transferred from the project settings to the watch window, but changes in the watch window aren't transferred back to the project settings. This seems to be due to a missing
m_CurrentProject?.Settings.WatchEntries.Remove(Watch); in MainForm.RemoveWatchEntry().

Suggestion: Strip REMs from a BASIC program

Especially when writing BASIC programs for the VIC20, you probably want to save each and every tiny byte. REMs help finding your way through your code, but they eat up precious space. I suggest there should be an option that strips all REMs when building the .prg file.

Breakpoint disappeared

This was in Normal mode; I didn't try in Debugging Broken.

I clicked in the left hand edge to set a breakpoint on an instruction.

The breakpoint appeared in both the code window and the Breakpoints window.

I then deleted the line above the breakpoint. This was a comment. The breakpoint disappeared from both the source window and the Breakpoints Window. I was able to reset it by clicking in the left margin of the source window.

Implicit converting from sta (address),x to sta adress,x without warning

In https://www.retro-programming.de/programming/assembler/asm-grundlagen/debuggen/ there is a sample, where sta (address),y is used. As beginner, I tried to use the x register: sta (address),x and the sample was generated, but not working. With the debugger I found out, that the mnemonic was implicitly converted to sta address,x what should not be done. The studio should generate an error like "not implemented use of mnemonic" or something else or "not implemented use of mnemonic -> converted to xy" or something like this.

Pasting path to VICE

Minor Issue.

I pasted the path to VICE into the Form Wizard dialog, but the OK button did not become available (even after I removed the double quote characters).

I expected that the OK Button would become available when a valid path is entered in the text box.

Non initialized memory NOT being 0x00

If Adding something like this to the end of a program:

*=$1f00+2000

It looks like only the memory from the first term ($1f00 gets initlialized to 0x00) and the rest ( from $1f00 and forward) gets some kind of garble..

still have this weird issue

Uploaded the fixed version to the usual link: https://www.georg-rottensteiner.de/files/C64StudioRelease.zip

only just tried this and still having the same problem :(

errors with unused label !text and !binary

Edit: think i have then found an additional bug. see attached pic, left works with below the first set of !text remd out, the right shows if then under with *=$xxxx and then !text the error comes back.

Originally posted by @theenemy-thd in #39 (comment)

No email notifications on Pull requests

Hi,
I seem to receive no email notification when a new pull requests is created by someone. I've double checked my notification settings, and I think I should receive one.
Could there be something else in my profile settings interfering?

Best regards,
Georg Rottensteiner

Unexpected Error

I was working in a branch, based off commit 74823b7. This branch was my work on Issue #45, but you've completed that, so I'll remove this branch.

I do not think the changes I made (2 commits) in my branch caused this as I don't see anything in this stack trace that I touched. So I'll report it with the above disclosure.

I got a message box with the following in it:

System.ArgumentOutOfRangeException: InvalidArgument=Value of '2' is not valid for 'index'.
Parameter name: index
at System.Windows.Forms.ListViewItem.ListViewSubItemCollection.get_Item(Int32 index)
at C64Studio.DebugWatch.UpdateValue(String WatchVar, Boolean IndexedX, Boolean IndexedY, ByteBuffer Data) in C:\Users\mrj00\source\repos\C64Studio\C64Studio\Documents\DebugWatch.cs:line 161
at C64Studio.DebugWatch.watchReadFromMemoryToolStripMenuItem_Click(Object sender, EventArgs e) in C:\Users\mrj00\source\repos\C64Studio\C64Studio\Documents\DebugWatch.cs:line 324
at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ToolStrip.WndProc(Message& m)
at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at C64Studio.Program.Main(String[] args) in C:\Users\mrj00\source\repos\C64Studio\C64Studio\Program.cs:line 30

Keybindings for selecting colour to draw with

The new key bindings for the Custom Color, Multi Color 1 and Multi Color 2 are changing the colour index (selecting the next colour).

Would it be possible to add bindings to select Custom Color, Multi Color 1 and Multi Color 2 (ie: as if I clicked on their radio button) so I can draw with that colour?

Conditions not updated in Breakpoints window

Add an unconditional breakpoint.

Add a conditional breakpoint.

Click on the unconditional breakpoint. The address and other information updates, but the conditions do not.

New Feature: Vic 20 Support

Wondering if Vic 20 support in C64Studio could be a thing?

Memory options is likely to be the initial part to address (unexpanded, 3k, 8k+) but otherwise lots of similarities on a cut-down scale.

Also the built in debugger support would be cool (it currently falls back to the Vice monitor if point to xvic.exe)

Newly created consts don

!TRACE does not output address value, but acts as a breakpoint

!TRACE <Expression> is documented as "expression is evaluated ... as address and ... the value is written to the output window".

But nothing is printed in the output window of either C64 Studio or VICE terminal.
Instead, it act as an extra breakpoint.

Note: it is translated in the -moncommands file as break exec <trace location>

Debugging does not work with latest WinVICE version

Debugging does not work with WinVICE version 6.5 (64bit). It seems not to get a connection.

C64Studio version is 6.6 on Windows 10.

!scr is not used the same as in ACME

Hi Georg

I'm not sure, if this is an error or only "other behavior". In the same example (https://www.retro-programming.de/programming/assembler/asm-grundlagen/debuggen/) the directive !src is used (more or less at the end of the page).
With this, the code should not be interpreted as PETSCII like !text then with the ones from the CHAR-ROM.

What do you think about this?

If zone name is surrounded by quotes, quotes appear in the outliner too

Presumable the quotes should be removed as they are just indications of a space in a zone name?

System.NullReferenceException when opening preferences in 7.1

I get a System.NullReferenceException when opening the preferences in 7.1
I already tried to remove the settings.dat and let C64STudio create a new one but still the same.
Its happing on:

C64Studio/C64Studio/Dialogs/Settings.cs

Line 190 in aaf2d86

itemF.Text = GR.EnumHelper.GetDescription( Core.Settings.Functions[function].State );

No support for Ultimax cartridges

Currently, it's not possible to directly create a CRT for ultimax mode. Using cart8crt almost works, but "EXROM" isn't set, i.e. at offset 0x18, 0x00 should be 0x01.
Also the loading start address is wrong. At offset 0x4c, 0x80 (->0x8000) should be 0xe0 (->0xe000).

It should suffice to add a "ultimaxcrt" keyword which uses the following lines at the according locations:

      header.AppendU8( 1 );     // EXROM
      header.AppendU8( 0 );     // GAME
      ...
      chip.AppendU16NetworkOrder( 0xE000 ); // loading start address
      chip.AppendU16NetworkOrder( 0x2000 ); // rom size

operator precedence - modulus

The following line assembles in acme assembler.
!byte run/1000 % 10 + '0'
However, it produces this error in C64 Studio:

Cannot evaluate expression run/1000 % 10 +'0'

This is because the modulus operator is higher precedence than division. In most languages, division and modulus have the same precedence and are evaluated left to right. This allows the above expression to work.

Is this precedence (modulus before division) correct?

There's an easy work-around, of course:
!byte (run/1000) % 10 + '0'

BASIC label mode with free naming

Thanks for making a great tool!

It would be great if the labelling somehow was the original/reference file, thus making it possible to select any names to any lines. This would make big files more readable and also together with my other suggestion make the whole tool more usable for big BASIC programs.

GTK3VICE-3.6.1-win64 not working

I updated my GTK3VICE-3.5 to 3.6.1 and it seems its not working. Doesn't even bring up a VICE window or writes anything to the the vice log.
Is 3.6.1 already supported with 7.1?

Assembler Debugging not breaking with VICE 3.3

With default VICE tool parameters (using Setup Wizard):

Calling C:\path\VICE33\x64sc.exe with -truedrive +virtualdev -initbreak 0x2000 -remotemonitor 
    "C:\path\C64Studio70\Sample Projects\Sample Project 1\sample1.prg"

There is no stop in C64 Studio debugger. It just has the following session:

In fact, it looks like VICE does not even run the program.

However, when manually entering SYS 8192 in the VICE BASIC session,
debugging behaves as expected (for -initbreak and/or explicit breaks),

Expected: the program is executed in VICE automatically and is stopped in C64 Studio,
without having to type SYS 8192 in BASIC.

It might be an issue with the VICE "autostart" feature, even though in VICE Help,
it is supposed to work with different kinds media (disk, tape, etc) and both BASIC and ML.
Note: using the extra parameter -autostart had the same issue.

Newly created consts don't show up in auto completion

When a CONST ist created its not showing up in auto completion list

Once the project is build once, it's listed.

Is this a known or normal behavior?

C64Studio 7 on Linux using mono

I've tried to get C64Studio running on Ubuntu 20.04. There are some copy problems in C64Studio.csproj, but they are easily fixed ny adding
cp $(TargetDir)C64Studio.exe $(SolutionDir)C64StudioRelease/$(TargetFileName)
cp $(TargetDir).dll $(SolutionDir)C64StudioRelease
rm -f "$(SolutionDir)C64StudioRelease/BASIC Dialects/"
cp $(ProjectDir)BASIC?Dialects/* $(SolutionDir)C64StudioRelease/BASIC?Dialects

I can then build the program. However, when I run it I get

System.TypeInitializationException: The type initializer for 'GR.Image.DPIHandler' threw an exception. ---> System.EntryPointNotFoundException: GetDeviceCaps assembly: type: member:(null)
at (wrapper managed-to-native) GR.Image.DPIHandler.GetDeviceCaps(intptr,int)
at GR.Image.DPIHandler..cctor () [0x00029] in /home/johan/commodore/C64Studio/Common/Common/DPIHandler.cs:29
--- End of inner exception stack trace ---
at C64Studio.OutputDisplay..ctor () [0x0000d] in /home/johan/commodore/C64Studio/C64Studio/Documents/OutputDisplay.cs:13
at (wrapper remoting-invoke-with-check) C64Studio.OutputDisplay..ctor()
at C64Studio.MainForm..ctor (System.String[] args) [0x00000] in /home/johan/commodore/C64Studio/C64Studio/MainForm.cs:27
at (wrapper remoting-invoke-with-check) C64Studio.MainForm..ctor(string[])
at C64Studio.Program.Main (System.String[] args) [0x00023] in /home/johan/commodore/C64Studio/C64Studio/Program.cs:28

It seems to be some problem when calling gdi32.dll, which is mapped to libgdiplus.so.0 (see /etc/mono/config), and this library is installed. I don't know much about mono and can't get further, but it would be nice if it could be patched to work on Linux.

Rotate sprite loses some pixels in multi-colour mode

When I rotate a multi-colour sprites 90 degrees I am losing some pixels. Hires mode appears to work fine though.

Export to Assembly leaves the hex values in each line

Using Export to Assembly leaves the hex values for each line of assembler in the code. This means that the .asm file generated is invalid and has to be fixed up.

WeifenLuo.WinFormsUI.Docking.dll is out of date

The assembly WeifenLuo.WinFormsUI.Docking.dll included in the source files is 2.9.0.0.
Whereas the C64Studio.csproj references 3.0.4.0.

During build the following error occurs:

C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3245: Could not res
olve this reference. Could not locate the assembly "WeifenLuo.WinFormsUI.Docking, Version=3.0.4.0, Culture=neutral, Pub
licKeyToken=5cded1a1a0a7b481, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this refe
rence is required by your code, you may get compilation errors.
...
Considered "bin\Debug\WeifenLuo.WinFormsUI.Docking.dll", but its name "WeifenLuo.WinFormsUI.Docking, Version=
  2.9.0.0, Culture=neutral, PublicKeyToken=5cded1a1a0a7b481" didn't match.

Crash when selection "Empty space" option in Preferences>colours

I have found that if you click on the "Empty space" option after selecting multiple custom colours in other options, C64Studio will crash to desktop.

This does seem to be consistent and repeatable.

Breaking at start address doesn't seem to be working as expected

When I set DebugStartAddress to 0xF000 for an UltiMax project, the Vice monitor breaks at the first instruction, but for some reason C64Studio doesn't get control. I have to continue using "g" in the monitor, bu then the program just keeps on running. From there on, I can break and single step in C64Studio, but this way it's impossible to debug the start of the program from C64Studio.

The start parameters look OKish:
E:\emu\computer\c64\GTK3VICE-3.3-win32-r35872\x64sc.exe with -truedrive +virtualdev -initbreak 0xf000 -remotemonitor -moncommands "C:\Users\fade0ff\AppData\Local\Temp\tmpEE77.tmp" -cartcrt "E:\src\C64\Dead Test\Dead Test\dead_test_0xfade0ff.crt"

Suggestion: Turn off automatic switching of input modes in BASIC mode

When I am in BASIC mode, entering something like 10 PRINT" it goes into this special input mode like on a real C64/VIC20, but a lot of other editing functions are then not correctly usable. I always have to click the buttons on the upper side of the input window to reset editing mode. There should be key combinations to do this, or a mode which turns off switching input modes.

Search .word -> !word crashes

On windows 10, I tried to do a search and replace of ".word" into "!word" on a file and the IDE showed a C# Crash Report.
Also the editor was cleared

weird problem even if rem'd

I have a problem when adjusting text via the "*=$" command, it seems to then cause an issue here with the !binary command as it throws up an error and doesn't compile properly.

this is even if rem'd out.
delete after first rem'd out !text code and all ok... very strange

version 6.7 by the way

*edit = i can send files if needed

oh and thanks
Alex

No Keybindings for editors?

Could a future version get some keybindings for the editors, for example the sprite editor would benefit from bindings for:

Select colour (background, Multicolor 1. 2 and sprite color)
Go to next and previous sprite
Shift sprites up/down/left/right
Mirror and flip

Similar for charset, text screen and other editors?

Corrupted UI layout in C64Studio 7.0.1

After installing C64Studio 7.0.1, the UI layout is corrupted:

• No Solution Explorer
• No bottom panels (Issues, Log, etc)

Note: the old version 6.1 is still working fine, without such issues.

Workflow for doing multi-file BASIC build - reusable BASIC Libs

It would be nice if the tool supported Mulit-file BASIC build. Is this possible today?
If selected wisely (either as labelled listing without duplicate labels or with non-overlapping Start/Range-addresses per file), all files could be automatically added to one file before build. For example I'm writing a Chip8 Emulator as we speak. It will be alot of lines of BASIC. I've already created 13 different files to test different parts of the application.

If opcodes contains a forward reference to a zero page address, wrong opcode version is used

variable = $02 sta variable

assembles the sta as $85. But

sta variable variable = $02

assembles the sta as $8D.