Activity for elgonzo
-
elgonzo modified a comment on ticket #2065
cmd.exe works fine as far as i can tell. That's where i did all my testing before i did some checks in PS. PS also works fine unless you do a cls beforehand. I didn't notice it earlier, because i didn't do a cls while testing in PS. Only now when i was dealing with the puts replacement in the RestoreConsolePrompt function that i mentioned earlier i stumbled over the weird PS thing triggered by cls... UPDATE: "PS also works fine unless [...]" my arse!!! Piping works fine PS, like .\foo.exe | more,...
-
cmd.exe works fine as far as i can tell. That's where i did all my testing before i did some checks in PS. PS also works fine unless you do a cls beforehand. I didn't notice it earlier, because i didn't do a cls while testing in PS. Only now when i was dealing with the puts replacement in the RestoreConsolePrompt function that i mentioned earlier i stumbled over the weird PS thing triggered by cls... UPDATE: "PS also works fine unless [...]" my arse!!! Piping works fine PS, like .\foo.exe | more,...
-
cmd.exe works fine as far as i can tell. That's where i did all my testing before i did some checks in PS. PS also works fine unless you do a cls beforehand. I didn't notice it earlier, because i didn't do a cls while testing in PS. Only now when i was dealing with the puts replacement in the RestoreConsolePrompt function that i mentioned earlier i stumbled over the weird PS thing triggered by cls...
-
One more update re BackupAndRemoveConsolePrompt and RestoreConsolePrompt functions. I just noticed some strange issue triggered by the cls command in Powershell. Issuing a cls and then running my demo program (as shown in the gist), outputs correctly, with RestoreConsolePrompt placing the prompt and cursor at the right position correctly, as it is supposed to be. However doing cls before leads to PS now believing the input position to be the old cursor position before the cursor position has been...
-
One more update re BackupAndRemoveConsolePrompt and RestoreConsolePrompt functions. I just noticed some issue with triggered by the cls command in Powershell. Issuing a cls and then runnging my demo program (as shown in the gist), RestoreConsolePrompt places the prompt and cursor at the right position correctly. However doing cls before leads to PS now believing the input position to be the old cursor position before the cursor position has been changed by `RestoreConsolePrompt. Which means, now...
-
One more update re BackupAndRemoveConsolePrompt and RestoreConsolePrompt functions. I just noticed that for some (so far unknown) reason, despite RestoreConsolePrompt placing the prompt and cursor at the right position correctly, PS seems to track the input positions separately from the cursor position. Which means, typing (or recalling a command from the history) appears at the old unadjusted cursor position. Weird. I therefore would suggest to not use BackupAndRemoveConsolePrompt and RestoreConsolePromptas...
-
Here i am going to outline a solution to have working console output while also having working stdout/stderr redirects without needing "magic" CLI incantations such as -no-redirect-streams. Unfortunately, i am currently ill-equipped to get the tool-chain running for building VICE from source, hence why i also currently unable to submit my code suggestion as a diff or PR. And i don't know when i would be able to find enough time to get it all set up properly, so for the time being it's just me here...
-
I just noticed a mistake i made in the implementation of RestoreConsolePrompt. I used puts there to output a newline (can't manipulate the cursor position directly here, as the last output might be at the end/bottom of the console buffer, hence have to ensure a possibly needed shift of the lines in the console buffer). Which is fine if stdout is not redirected. But if stdout is redirected and stderr is not, RestoreConsolePrompt can't use puts, obviously. Need to replace it with a call to the WinApi...
-
I just noticed a mistake i made in the implementation of RestoreConsolePrompt. I used puts there to output a newline (can't manipulate the cursor position directly here, as the last output might be at the end/bottom of the console buffer, hence need to ensure a possible shift of the lines in the console buffer data). Which is fine if stdout is not redirected. But if stdout is redirected and stderr is not, RestoreConsolePrompt can't use puts, obviously. Need to replace it with a call to the WinApi...
-
Here i am going to outline a solution to have working console output while also having working stdout/stderr redirects without needing "magic" CLI incantations such as -no-redirect-streams. Unfortunately, i am currently ill-equipped to get the tool-chain running for building VICE from source, hence why i also currently unable to submit my code suggestion as a diff or PR. And i don't know when i would be able to find enough time to get it all set up properly, so for the time being it's just me here...
-
Here i am going to outline a solution to have working console output while also having working stdout/stderr redirects without needing "magic" CLI incantations such as -no-redirect-streams. Unfortunately, i am currently ill-equipped to get the tool-chain running for building VICE from source, hence why i also currently unable to submit my code suggestion as a diff or PR. And i don't know when i would be able to find enough time to get it all set up properly, so for the time being it's just me here...
-
Here i am going to outline a solution to have working console output while also having working stdout/stderr redirects without needing "magic" CLI incantations such as -no-redirect-streams. Unfortunately, i am currently ill-equipped to get the tool-chain running for building VICE from source, hence why i also currently unable to submit my code suggestion as a diff or PR. And i don't know when i would be able to find enough time to get it all set up properly, so for the time being it's just me here...
-
Here i am going to outline a solution to have working console output while also having working stdout/stderr redirects without needing "magic" CLI incantations such as -no-redirect-streams. Unfortunately, i am currently ill-equipped to get the tool-chain running for building VICE from source, hence why i also currently unable to submit my code suggestion as a diff or PR. And i don't know when i would be able to find enough time to get it all set up properly, so for the time being it's just me here...
-
Here i am going to outline a solution to have working console output while also having working stdout/stderr redirects without needing "magic" CLI incantations such as -no-redirect-streams. Unfortunately, i am currently ill-equipped to get the tool-chain running for building VICE from source, hence why i also currently unable to submit my code suggestion as a diff or PR. And i don't know when i would be able to find enough time to get it all set up properly, so for the time being it's just me here...
-
Here i am going to outline a solution to have working console output while also having working stdout/stderr redirects without needing "magic" CLI incantations such as -no-redirect-streams. Unfortunately, i am currently ill-equipped to get the tool-chain running for building VICE from source, hence why i also currently unable to submit my code suggestion as a diff or PR. And i don't know when i would be able to find enough time to get it all set up properly, so for the time being it's just me here...
-
Here i am going to outline a solution to have working console output while also having working stdout/stderr redirects without needing "magic" CLI incantations such as -no-redirect-streams. Unfortunately, i am currently ill-equipped to get the tool-chain running for building VICE from source, hence why i also currently unable to submit my code suggestion as a diff or PR. And i don't know when i would be able to find enough time to get it all set up properly, so for the time being it's just me here...
-
Here i am going to outline a solution to have working console output while also having working stdout/stderr redirects without needing "magic" CLI incantations such as -no-redirect-streams. Unfortunately, i am currently ill-equipped to get the tool-chain running for building VICE from source, hence why i also currently unable to submit my code suggestion as a diff or PR. And i don't know when i would be able to find enough time to get it all set up properly, so for the time being it's just me here...
-
Without being dispectful, but this is terrible. Because a user won't ever know about this unless they got lucky spotting compyx' comment in the vast abyss that of the internet. It's also astronomically unlikely that a user would even think about trying to look up/find such an option, because that's not how stdout/stderr redirection is supposed to work. It's supposed to just work. Lets not talk about the "wat?" moment that is the file used as redirection target being actually created but with some...
-
Without being dispectful, but this is terrible. Because a user won't ever know about this unless they got lucky spotting compyx' comment in the vast abyss that of the internet. It's also astronomically unlikely that a user would even think about trying to look up/find such an option, because that's not how stdout/stderr redirection is supposed to work. It's supposed to just work. Lets not talk about the wtf that is the file used as redirection target being actually created but with some random "lib_init()"...
-
Without being dispectful, but this is terrible. Because a user won't ever know about this unless they got lucky spotting compyx' comment in the vast abyss that of the internet. It's also astronomically unlikely that a user would even think about trying to look up/find such an option, because that's not how stdout/stderr redirection is supposed to work. It's supposed to just work. However, i understand why you guys implemented this option, because Windows console is frankly a bitch. Anyways, in a...
-
The help output is not on stderr, so trying to capture stderr won't help with the help ;-)
-
Impossible to redirect the help console output into a file
-
Oops... i guess you accidentally turned the description for the CPU operation fields from 0x01: load, 0x02: store, 0x04: exec into >=0x01: load, 0x02: store, 0x04: exec
-
I guess if an invalid value is sent which the emulator cannot make use of, an error response should be sent back with error code 0x81 ("An invalid parameter value was present "). For any value that has unsupported bits set, but is otherwise actionable, the response should -- and already does, iirc -- contain a field wth the cleaned-up value with any unsupported feature/function/flag bits reset to zero. This would then allow a client to relatively easily discover if a requested feature/function/flag...
-
Is it possible for you to share your code? Oops. I did not notice your request until now. If there is still interest, here are the relevant bits. And just to be clear, the issue did not reappear again so far, so this is purely a FYI comment, in case you are still curious about my code. The project is written in C#, with the code transmitting stuff to the binary monitor being: protected byte[]? CommandBodyBulkData { get; set; } = null; internal void SendCommandRequest() { System.Diagnostics.Debug.Assert(CommandRequestBodyLength...
-
Is it possible for you to share your code? Oops. I did not notice your request until now. If there is still interest, here are the relevant bits. And just to be clear, the issue did not reappear again so far, so this is purely a FYI comment, in case you are still curious about my code. The project is written in C#, with the code transmitting stuff to the binary monitor being: protected byte[]? CommandBodyBulkData { get; set; } = null; internal void SendCommandRequest() { System.Diagnostics.Debug.Assert(CommandRequestBodyLength...
-
Is it possible for you to share your code? Oops. I did not notice your request until now. If there is still interest, here are the relevant bits. And just to be clear, the issue did not reappear again so far, so this is purely a FYI comment, in case you are still curious about my code. The project is written in C#, with the code transmitting stuff to the binary monitor being: protected byte[]? CommandBodyBulkData { get; set; } = null; internal void SendCommandRequest() { System.Diagnostics.Debug.Assert(CommandRequestBodyLength...
-
Is it possible for you to share your code? Oops. I did not notice your request until now. If there is still interest, here are the relevant bits. And just to be clear, the issue did not reappear again so far, so this is purely a FYI comment, in case you are still curious about my code. The project is written in C#, with the code transmitting stuff to the binary monitor being: protected byte[]? CommandBodyBulkData { get; set; } = null; internal void SendCommandRequest() { System.Diagnostics.Debug.Assert(CommandRequestBodyLength...
-
Is it possible for you to share your code? Oops. I did not notice your request until now. If there is still interest, here are the relevant bits. And just to be clear, the issue did not reappear again so far, so this is purely a FYI comment, in case you are still curious about my code. The project is written in C#, with the code transmitting stuff to the binary monitor being: protected byte[]? CommandBodyBulkData { get; set; } = null; internal void SendCommandRequest() { System.Diagnostics.Debug.Assert(CommandRequestBodyLength...
-
Is it possible for you to share your code? Oops. I did not notice your request until now. If there is still interest, here are the relevant bits. And just to be clear, the issue did not reappear again so far, so this is purely a FYI comment, in case you are still curious about my code. The project is written in C#, with the code transmitting stuff to the binary monitor being: protected byte[]? CommandBodyBulkData { get; set; } = null; internal void SendCommandRequest() { System.Diagnostics.Debug.Assert(CommandRequestBodyLength...
-
Is it possible for you to share your code? Oops. I did not notice your request until now. If there is still interest, here are the relevant bits. And just to be clear, the issue did not reappear again so far, so this is purely a FYI comment, in case you are still curious about my code. The project is written in C#, with the code transmitting stuff to the binary monitor being: protected byte[]? CommandBodyBulkData { get; set; } = null; internal void SendCommandRequest() { System.Diagnostics.Debug.Assert(CommandRequestBodyLength...
-
Is it possible for you to share your code? Oops. I did not notice your request until now. If there is still interest, here are the relevant bits. And just to be clear, the issue did not reappear again so far, so this is purely a FYI comment, in case you are still curious about my code. The project is written in C#, with the code transmitting stuff to the binary monitor being: protected byte[]? CommandBodyBulkData { get; set; } = null; internal void SendCommandRequest() { System.Diagnostics.Debug.Assert(CommandRequestBodyLength...
-
I did test against the SDL version (using the same revision as the GTK version i used and mentioned in my report: SDL2VICE-3.6.1-beta.3-win64-r41682). At first, it was much better behaved, basically as you describe. The emulator window freezes, but it does not unduly load the CPU. The problem seemed to be limited to the GTK-based Windows version. I was doing a few repeated observations of the CPU loading of the GTK version vs. SDL version (i was running the GTK then the SDL version alternatively...
-
I did test against the SDL version (using the same revision as the GTK version i used and mentioned in my report: SDL2VICE-3.6.1-beta.3-win64-r41682). At first, it was much better behaved, basically as you describe. The emulator window freezes, but it does not unduly load the CPU. The problem seemed to be limited to the GTK-based Windows version. But after doing a few repeated observations of the CPU loading of the GTK version vs. SDL version (i was running the GTK then the SDL version alternatively...
-
The 1st command is sent fully and correctly, and a matching response is received successfully. I just don't send another command then, not even partially. I guess i need to wireshark the connection to see whether there is a stray byte being sent by my code after transmitting the command somehow, although that should not be the case (but then again, i have proven to not be able to comprehend simple code constructs, so who knows what my code is doing ;-) )
-
Ah, for crying out loud, i am a dumb idiot like no other. My apologies, of course the while loop exits if monitor_binary_data_available() is returning false. I was totally misinterpreting that (because i am apparently emperor of stupid), and from there it was all downhill for me and my (false) reasoning... I am so sorry for wasting your time (especially on the weekend). No idea, then, why the UI thread seems to freeze and the emulator hogging a CPU core after the 1st command has been sent and the...
-
Yes, i watched the fucking video. What the fuck should i look for? Where in he fucking video does it show anywhere what monitor_binary_get_command_line does, for fucks sake? :-)
-
I'm not sure it matters, but which machine are you trying to emulate? I am running x64sc. to make sure we are talking about the same thing: https://youtu.be/0sHfiqZXokM Look at the monitor_binary_get_command_line implementation. Once you have sent the 1st command to the binary monitor, the binary monitor will enter the while (monitor_binary_data_available()) loop in the monitor_binary_get_command_line function. After processing the command, the while loop will NOT be exited; except the command is...
-
I'm not sure it matters, but which machine are you trying to emulate? I am running x64sc. to make sure we are talking about the same thing: https://youtu.be/0sHfiqZXokM Look at the monitor_binary_get_command_line implementation. Once you have sent the 1st command to the binary monitor, the binary monitor will enter the while (monitor_binary_data_available()) loop in the monitor_binary_get_command_line function. After processing the command, the while loop will NOT be exited; except the command is...
-
I'm not sure it matters, but which machine are you trying to emulate? I am running x64sc. to make sure we are talking about the same thing: https://youtu.be/0sHfiqZXokM Look at the monitor_binary_get_command_line implementation. Once you have sent the 1st command to the binary monitor, the binary monitor will enter the while (monitor_binary_data_available()) in the monitor_binary_get_command_line function. After processing the command, the while loop will NOT be exited; except the command is causing...
-
This has the timeout you were mentioning: TIMEVAL time = {0, 250000}; No. It's definitely not the timeout i refer to. :-) Look at monitor_binary_data_available(): static int monitor_binary_data_available(void) { int available = 0; if (connected_socket != NULL) { available = vice_network_select_poll_one(connected_socket); } else if (listen_socket != NULL) { /* we have no connection yet, allow for connection */ if (vice_network_select_poll_one(listen_socket)) { connected_socket = vice_network_accept(listen_socket);...
-
This has the timeout you were mentioning: TIMEVAL time = {0, 250000}; No. It's definitely not the timeout i refer to. :-) Look at monitor_binary_data_available(): static int monitor_binary_data_available(void) { int available = 0; if (connected_socket != NULL) { available = vice_network_select_poll_one(connected_socket); } else if (listen_socket != NULL) { /* we have no connection yet, allow for connection */ if (vice_network_select_poll_one(listen_socket)) { connected_socket = vice_network_accept(listen_socket);...
-
This has the timeout you were mentioning: TIMEVAL time = {0, 250000}; No. It's definitely not the timeout i refer to. :-) Look at monitor_binary_data_available(): static int monitor_binary_data_available(void) { int available = 0; if (connected_socket != NULL) { available = vice_network_select_poll_one(connected_socket); } else if (listen_socket != NULL) { /* we have no connection yet, allow for connection */ if (vice_network_select_poll_one(listen_socket)) { connected_socket = vice_network_accept(listen_socket);...
-
This has the timeout you were mentioning: TIMEVAL time = {0, 250000}; No. It's definitely not the timeout i refer to. :-) Look at monitor_binary_data_available(): static int monitor_binary_data_available(void) { int available = 0; if (connected_socket != NULL) { available = vice_network_select_poll_one(connected_socket); } else if (listen_socket != NULL) { /* we have no connection yet, allow for connection */ if (vice_network_select_poll_one(listen_socket)) { connected_socket = vice_network_accept(listen_socket);...
-
I hope it's not misunderstood that the versioning is only present for breaking changes. Always good to know. I have to admit i was not fully aware of this yet until now. I have always tried to make them optional, so that the older, shorter variation of the command would still work, and the additional fields could be ignored by older versions of the server. That makes sense. And i noticed in the meantime that the emulator actually sends back a CPU operation field in the response with the unsupported...
-
This has the timeout you were mentioning: TIMEVAL time = {0, 250000}; No. It's definitely not the timeout i refer to. :-) Look at monitor_binary_data_available(): static int monitor_binary_data_available(void) { int available = 0; if (connected_socket != NULL) { available = vice_network_select_poll_one(connected_socket); } else if (listen_socket != NULL) { /* we have no connection yet, allow for connection */ if (vice_network_select_poll_one(listen_socket)) { connected_socket = vice_network_accept(listen_socket);...
-
This has the timeout you were mentioning: TIMEVAL time = {0, 250000}; No. It's definitely not the timeout i refer to. :-) Look at monitor_binary_data_available(): static int monitor_binary_data_available(void) { int available = 0; if (connected_socket != NULL) { available = vice_network_select_poll_one(connected_socket); } else if (listen_socket != NULL) { /* we have no connection yet, allow for connection */ if (vice_network_select_poll_one(listen_socket)) { connected_socket = vice_network_accept(listen_socket);...
-
This has the timeout you were mentioning: TIMEVAL time = {0, 250000}; No. It's definitely not the timeout i refer to. :-) Look at monitor_binary_data_available(): static int monitor_binary_data_available(void) { int available = 0; if (connected_socket != NULL) { available = vice_network_select_poll_one(connected_socket); } else if (listen_socket != NULL) { /* we have no connection yet, allow for connection */ if (vice_network_select_poll_one(listen_socket)) { connected_socket = vice_network_accept(listen_socket);...
-
This has the timeout you were mentioning: TIMEVAL time = {0, 250000}; No. It's definitely not the timeout i refer to. :-) Look at monitor_binary_data_available(): static int monitor_binary_data_available(void) { int available = 0; if (connected_socket != NULL) { available = vice_network_select_poll_one(connected_socket); } else if (listen_socket != NULL) { /* we have no connection yet, allow for connection */ if (vice_network_select_poll_one(listen_socket)) { connected_socket = vice_network_accept(listen_socket);...
-
This has the timeout you were mentioning: TIMEVAL time = {0, 250000}; No. It's definitely not the timeout i refer to. :-) Look at monitor_binary_data_available(): static int monitor_binary_data_available(void) { int available = 0; if (connected_socket != NULL) { available = vice_network_select_poll_one(connected_socket); } else if (listen_socket != NULL) { /* we have no connection yet, allow for connection */ if (vice_network_select_poll_one(listen_socket)) { connected_socket = vice_network_accept(listen_socket);...
-
This has the timeout you were mentioning: TIMEVAL time = {0, 250000}; No. It's definitely not. :-) Look at monitor_binary_data_available(): static int monitor_binary_data_available(void) { int available = 0; if (connected_socket != NULL) { available = vice_network_select_poll_one(connected_socket); } else if (listen_socket != NULL) { /* we have no connection yet, allow for connection */ if (vice_network_select_poll_one(listen_socket)) { connected_socket = vice_network_accept(listen_socket); } } return...
-
Some additional notes: It looks to me the monitor_binary_get_command_line is being executed on the GUI thread, as the emulator UI completely freezes up when the binary monitor is waiting for the next command to come, explaining at least partially why the desktop session feels so sluggish. I guess a solution to this problem could be two-pronged: Letting the binary monitor loop run in its own background thread. If the select function underlying monitor_binary_data_available cannot make use of the timeout...
-
Some additional notes: It looks to me the monitor_binary_get_command_line is being executed on the GUI thread, as the emulator UI completely freezes up when the binary monitor is waiting for the next command to come, explaining at least partially why the desktop session feels so sluggish. I guess a solution to this problem could be two-pronged: Delegate the binary monitor loop to its own background thread. If the select function underlying monitor_binary_data_available cannot make use of the timeout...
-
Binary monitor documentation: Boolean values
-
Binary monitor documentation: Undocumented response type 0x00
-
Binary monitor: Invalid CPU operation value in Checkpoint Set command can crash emulator
-
(I know that i can lower the priority of the Vice process in the Task Manager to ameliorate the issue. But it's a crude manual workaround i have to remember to apply evertime i start up the emulator, and which my fabulous brain forgets to do from time to time. Sigh...)
-
(I know that i can lower priority of the Vice process in the Task manager to ameliorate the issue. But it's a crude manual workaround i have to remember to apply evertime i start up the emulator, and which my fabulous brain forgets to do from time to time. Sigh...)
-
Binary monitor: Binary monitor waiting for next command hogs CPU
-
Binary monitor doc: Memory Get response docs could benefit from documenting special case of mem segment length being 65536
-
Yes, it's fixed (i tested with GTK3VICE-3.5-win64-r40824 now). My apologies for dropping the ball here. How time flies - i didn't realize it is/was so long ago i filed the report. Again, my apologies for not coming back earlier. :(
-
The invalid command was fixed in r40578. Ah, i first tested with r40000, and seeing the console window still popping up in r40584 made me falsely believe it would be the same there. I checked once more with r40584, and the output in the console window is indeed different . Not about unknown command anymore, but an error message about not being able to decode/unpack s!nafu.d64.
-
Oops, sorry, i forgot to mention which Vice version i am using. It's: GTK3VICE-3.5-win64-r40584 on Windows 7 Pro x64
-
Oops, sorry, i forgot to mention which Vice version i am using. It's: GTK3VICE-3.5-win64-r40500 on Windows 7 Pro x64
-
"Attach a disk image" dialog: A console window briefly opens when selecting a disk image with a name similar to that of a ZipCode file name
-
@Lawrence i think gpz' first comment was a response to my comment. (In which i stated that the expected line endings should be CR/LF instead of a single CR -- which of course was a wrong expectation, because PRINT# only emits a CR as a line ending.) Try r40500 or a newer version. I tested with r40500 and did not observe the issue anymore (whereas i could see the issue you reported with an older Vice version...)
-
Oh right, i forgot that it is the output as generated by PRINT#, which ends a line only with a CR. Yeah, it is indeed correct.
-
I can reproduce the issue with r40324, with the issue in some derivative form still existing in r40500. (I have tested with both the older GTK3VICE-3.5-win64-r40324 and with the rather current GTK3VICE-3.5-win64-r40500 on Windows 7 x64.) While it seems there has been an attempt to fix it sometime between r40324 and r40500, the fix is not correct (or incomplete), exhibiting still an issue with line endings. Iirc, line endings for printers require both a CR and a LF (0x0d, 0x0a). It seems, in older...
-
I tested again with GTK3VICE-3.5-win64-r40500 on Windows 7 x64. It works like a charm, i can confirm the issue has been fixed. Thanks so much! (Side note: I also did first a test with the old GTK3VICE-3.5-win64-r40324 again once more to ensure the issue is still reproducible in the same environment i was going to try r40500, so i have a rather high confidence in saying that the issue has been resolved successfully in r40490.)
-
Binary monitor: monitor_binary_get_command_line function can fail when an incoming command is split across two packets "just right"
-
Yeah, i had the suspicion it might be about no \r being sent by the remote monitor. Raw mode does work nicely (with putty's "Implict CR in every LF" setting enabled). By the way, only after some more testing and generally screwing around with putty and the remote monitor i noticed that when using incorrect connection settings in putty, Vice's remote monitor server can get into a non-working state from which it doesn't seem to be able to recover, necessitating a restart of the emulator. During all...
-
Yes. I spent some time and did some further experimentation and investigations. When communicating with the remote monitor server with a small program i quickly hacked together, i did see the monitor taking and excuting the monitor commands my little program transmkitted. So i kept playing around a bit more with the putty settings, and found that configuring putty to use passive telnet negotion mode helped. (I thought i tried this already when i did my initial tests and trials of different putty...
-
Binary monitor: Checkpoint set command with support for memspaces and banks
-
Oops, i just noticed i filed my report in the "feature request" section. Seems i am not able to relocate my report by myself. Dang, my sincere apologies. :-(
-
Small correction to my report above: The flickering i observed was in an older Vice version (WinVICE-2.4.20-x86-r29837) i also tested. There was no observable flickering in GTK3VICE-3.5-win64-r40324. My apologies if i happened to confuse somebody.
-
Remote monitor with putty telnet client: Connection established, but emulator doesn't do anything no matter what i type
-
Yeah, note that your path to 7z.exe contains a space character. Thus, you will have to surround it with double quotes ("c:\Program Files\7-zip\7z.exe"), otherwise cmd.exe will treat this as two separate arguments (delimited by the space character) c:\Program and Files\7-zip\7z.exe That problem/behavior is not about 7z.exe at all, just the bog-standard mode of operation of Windows' cmd.exe command line processor ;-)
-
Sorry for the radio silence last week. I was taking another look into one of the affected ZIP file. And i noticed that it had two problems. First, it had an additional byte after the compressed data. But this is likely unrelated to the error messages i encountered. The issue causing the misleading error messages were incorrect values in the "compressed size" fields (both in the data descriptor and in the central directory). The incorrect values were 4 bytes too large (thus including the 4 bytes of...
-
No need to quote from the specification/appnote. I already linked to this document in my post above, and i am aware of what is written in it :-) Are you trying to say that 7-Zip is having support for the ZIP data descriptor record? Btw, the signature for the data descriptor is present, so if 7-Zip is supposed to support ZIP data descriptor records, something else in the ZIP archive would be a contributing factor. Although, i don't know where 7-Zip would get the idea of reporting a "CRC error" even...
-
No need to quote from the specification/appnote. I already linked to this document in my post above, and i am aware of what is written in it :-) Are you trying to say that 7-Zip is having support for the ZIP data descriptor record? Btw, the signature for the data descriptor is present, so if 7-Zip is supposed to support ZIP data descriptor records, something else in the ZIP archive would be a contributing factor. Although, i don't know where 7-Zip would get the idea of reporting a "CRC error" even...
-
I am not quite sure why you are asking about Mac here in the 7-Zip forum. If you go to the official web site of the 7-Zip tool (https://www.7-zip.org/), you'll notice that only downloads for Windows are offered (aside from source code and p7zip for Unix-likes). Thus, if you really want to use 7-Zip (and not some other tool available for Mac), you are stuck with Windows. If you only want to create ZIP archives, you don't need 7-Zip specifically. There are many (GUI-based) tools out there -- i suspect...
-
I am not quite sure why you are asking about Mac here in the 7-Zip forum. If you go to the official web site of the 7-Zip tool (https://www.7-zip.org/), you'll notice that only downloads for Windows are offered (aside from source code and p7zip for Linux). Thus, if you really want to use 7-Zip (and not some other tool available for Mac), you are stuck with Windows. If you only want to create ZIP archives, you don't need 7-Zip specifically. There are many (GUI-based) tools out there -- i suspect on...
-
I am not quite sure why you are asking about Mac here in the 7-Zip forum. If you go to the official web site of the 7-Zip tool (https://www.7-zip.org/), you'll notice that only downloads for Windows are offered (aside from source code and p7zip for Linux). Thus, if you really want to use 7-Zip (and not some other tool available for Mac), you are stuck with Windows. If you only want to create ZIP archives, you don't need 7-Zip specifically. There are many (GUI-based) tools out there -- i suspect on...
-
I am not quite sure why you are asking about Mac here in the 7-Zip forum. If you go to the official web site of the 7-Zip tool (https://www.7-zip.org/), you'll notice that only downloads for Windows are offered (aside from source code), and p7zip for Linux. Thus, if you really want to use 7-Zip (and not some other tool available for Mac), you are stuck with Windows. If you only want to create ZIP archives, you don't need 7-Zip specifically. There are many (GUI-based) tools out there -- i suspect...
-
Use for /d in a batch file to enumerate directories instead of files (for more details, open a cmd window and type for /?). If you want to enumerate directories in a given base folder, do something like that: for /d %%i in (x:\PathToBaseFolder\*.*) do echo %%i (instead of echoing, you would then call 7-zip...)
-
Use for /d in a batch file to enumerate directories instead of files (for more details, open a cmd window and type for /?). If you want to enumerate directories in a given base folder, do something like that: for /d %% in (x:\PathToBaseFolder\*.*) do echo %%i (instead of echoing, you would then call 7-zip...)
-
Use for /d in a batch file to enumerate directories instead of files (for more details, open a cmd window and type for /?)
-
Use for /d in a batch file (for more details, open a cmd window and type for /?)
-
Today i was bitten in the arse by 7-zip giving misleading and outright wrong error messages due to its missing support for "Data Descriptor" fields in ZIP files ("Unexpected end of data", "CRC errors"). I am using 7-Zip 18.06 x64. My plea: Please include proper ZIP "Data Descriptor" support in 7-Zip. If for whatever reason this is not desired, at least make 7-Zip give meaningful responses when encountering ZIP files using "Data Descriptor" fields. Don't let 7-Zip give misleading/wrong error messages....
1