The program uses C128 mode as a "virtual cartridge" to hack C64, allowing keeping intact image data when swithcing back from C64 to C128 mode; but it does not work in VICE, apparently because the register which holds color map data is badly managed.
The linked program keeps intact the pointers to bimtap and colormap, and the whole bitmap memory, when switching back to C128, so it should be possible to rebuild the image; in VICE it works partially: some colors are lost. We concluded that there is some bug in how VICE manages register $DD00... but it's too complicated for me to understand what's actually wrong under the hood, all I know is that in retrodebugger, which uses VICE internally, shows right content of $DD00 in the interface, but internally it apparently remains stuck to an old value after $DD00 is updated.
Probably you can get more tech details asking on that thread rather than to me...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am not asking about tech details. I am asking how to reproduce this problem. What do i have to do to see it? You reported the problem, so you should be able to tell what the problem is - don't expect me to hunt for your problem, please.
(how does retrodebugger come into play here? it doesn't even emulate c128?)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Start VICE emulator for C128 (x128.exe on Windows)
Drag extractor.d64 over the emulator window
type load "binary",8,1 followed by ENTER (you can paste this command into VICE with ALT+INS)
type sys 4864 followed by ENTER : system will switch to hacked version of C64 mode
Drag captured-PW.d64 over emulator window; don't attach image from menu, else machine will be reset back to c128!
type load "captured!",8,1 (beware of "!") followed by ENTER
wait full loading (up to track 9)
type run followed by ENTER; the game will launch
go to the image you want to grab (splash screen of Captured)
perform a soft reset (ALT+F9 in VICE) to switch back to C128
type sys 5172 followed by ENTER
press spacebar until you see the desired image (only 4 images versions will be available)
press ENTER to save current image to disk
By the way, apparently there is no way to attach an image to C128 in C64 mode without resetting back to C128 and launching the image automatically after loading, using the menu: the only way is using drag&drop; in other words, there is no "just attach" button in the "attach disk file" panel.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By the way, apparently there is no way to attach an image to C128 in C64 mode without resetting back to C128 and launching the image automatically after loading, using the menu: the only way is using drag&drop; in other words, there is no "just attach" button in the "attach disk file" panel.
At this point i wonder what ancient VICE release you are using - because drag+drop will certainly reset+autostart in a recent one.
And you attach a disk without autostarting (or resetting) by clicking "attach/load" in the file chooser.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think "attach/load" written on a single button is very confusing: does the button attach an image or does it load in memory the first file in the image? They are two totally different things made by the same button depending on what appears on the screen.
I eventually discovered, just now, how it works:
1) menu --> attach --> select image: button attachs image;
2) menu --> attach --> select image --> single click on prg file: button attachs image, resets C64, which switches back to C128 mode, and loads file; program is not run;
3) menu --> attach --> select image --> double click on prg file: no button needed, everything in point 2 is performed. If program is run or not depends on an option set in another panel.
Which one of the 3 options is associated to drag&drop is set in settings... of Host, not of Drive
This means that this panel has two default "ok" buttons, i.e. the one which is automatically selected upon double clicking on something:
1) double click on image; what it should do: attach image ad exit. What it does: attach, reset, load, run (automatic press of autostart is visible)
2) double click on prg: attach, reset, load, run (automatic press of autostart is NOT visible)
This is completely confusing and misleading.
Vice 3.9.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It looks like the PLA and MMU may have the same side effect when it comes to using the past color ram selection setting before switching to C64 mode. I will make a test program first to verify on real hardware before I make the change.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well this was a very deep rabbit hole. I thought it was an MMU thing and made a tester, and when I finally pulled my C128 out of storage, the tester still didn't work. It turns out it was an issue with how the data port in x128 CPU worked. This code inserts itself into the C128 reboot process where it copies the colormap before the kernal fully resets. When a soft reset happens, the values of the data port are set to 0, and the "pport.data_read" wasn't updated to reflect the effect of the external pull up resistors so the color map was improperly selected until a write to $1 or $0 was performed which is much later in the C128 kernal reset process. So this code copied the wrong color map. I tested using the supplied d64 images and it works in r46031.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please tell exactly how to reproduce the problem - don't assume we can read italian :)
Hello? Please describe what to do with this program to reproduce the problem - whatever the problem is :)
The program uses C128 mode as a "virtual cartridge" to hack C64, allowing keeping intact image data when swithcing back from C64 to C128 mode; but it does not work in VICE, apparently because the register which holds color map data is badly managed.
Please heck this reddit thread for etails:
https://www.reddit.com/r/c64/comments/1i5qo1x/ripping_image_from_game_captured_where_is_color/
That wall of text doesn't really tell me how to reproduce the problem at all. Or even how it is related to the program linked in the OP
Please tell exactly, step by step:
and most importantly, make sure to use a recent VICE release :)
The linked program keeps intact the pointers to bimtap and colormap, and the whole bitmap memory, when switching back to C128, so it should be possible to rebuild the image; in VICE it works partially: some colors are lost. We concluded that there is some bug in how VICE manages register $DD00... but it's too complicated for me to understand what's actually wrong under the hood, all I know is that in retrodebugger, which uses VICE internally, shows right content of $DD00 in the interface, but internally it apparently remains stuck to an old value after $DD00 is updated.
Probably you can get more tech details asking on that thread rather than to me...
I am not asking about tech details. I am asking how to reproduce this problem. What do i have to do to see it? You reported the problem, so you should be able to tell what the problem is - don't expect me to hunt for your problem, please.
(how does retrodebugger come into play here? it doesn't even emulate c128?)
Added instructions to readme file.
By the way, apparently there is no way to attach an image to C128 in C64 mode without resetting back to C128 and launching the image automatically after loading, using the menu: the only way is using drag&drop; in other words, there is no "just attach" button in the "attach disk file" panel.
At this point i wonder what ancient VICE release you are using - because drag+drop will certainly reset+autostart in a recent one.
And you attach a disk without autostarting (or resetting) by clicking "attach/load" in the file chooser.
I think "attach/load" written on a single button is very confusing: does the button attach an image or does it load in memory the first file in the image? They are two totally different things made by the same button depending on what appears on the screen.
I eventually discovered, just now, how it works:
1) menu --> attach --> select image: button attachs image;
2) menu --> attach --> select image --> single click on prg file: button attachs image, resets C64, which switches back to C128 mode, and loads file; program is not run;
3) menu --> attach --> select image --> double click on prg file: no button needed, everything in point 2 is performed. If program is run or not depends on an option set in another panel.
Which one of the 3 options is associated to drag&drop is set in settings... of Host, not of Drive
This means that this panel has two default "ok" buttons, i.e. the one which is automatically selected upon double clicking on something:
1) double click on image; what it should do: attach image ad exit. What it does: attach, reset, load, run (automatic press of autostart is visible)
2) double click on prg: attach, reset, load, run (automatic press of autostart is NOT visible)
This is completely confusing and misleading.
Vice 3.9.
So, does it work?
are you serious?
Was that a hard question? Despite your confusion about the UI, you did not confirm that it does.
unsubscribed from thread.
Oh well, communication is hard, i guess.
I quickly tried and it seems still broken.
It looks like the PLA and MMU may have the same side effect when it comes to using the past color ram selection setting before switching to C64 mode. I will make a test program first to verify on real hardware before I make the change.
Well this was a very deep rabbit hole. I thought it was an MMU thing and made a tester, and when I finally pulled my C128 out of storage, the tester still didn't work. It turns out it was an issue with how the data port in x128 CPU worked. This code inserts itself into the C128 reboot process where it copies the colormap before the kernal fully resets. When a soft reset happens, the values of the data port are set to 0, and the "pport.data_read" wasn't updated to reflect the effect of the external pull up resistors so the color map was improperly selected until a write to $1 or $0 was performed which is much later in the C128 kernal reset process. So this code copied the wrong color map. I tested using the supplied d64 images and it works in r46031.