|
|
Post by spannernick on Aug 23, 2020 9:34:56 GMT
yeah..  |
|
|
|
Post by gurce on Aug 23, 2020 12:57:46 GMT
Got some thoughts back from people on the inside, so thought I'd share my take on the thoughts conveyed, in my own words, so I don't lock anybody into an official position
I feel that there's a willingness on their part to engage with the community via the github repo, so it seems like forking is ok. So if you've implemented an idea that you want to put on their radar, it might be worth doing a pull request, they could mull it over, given their own time constraints, how thoroughly tested it is, how feasible they feel it is, etc, they might consider including it in a future firmware update.
I sensed some degree of concern in relation to bricked devices and the impact it has on their business, with more people claiming their warranties due to inadvertently bricking their devices due to fake updates. I can sympathise there. While I personally can comfortably put on my modder's hat and tinker with internals, I do so with the acceptance of the risks involved and that I'm voiding warranty.
My sense of the modder guys in the64community forum, I reckon you're a bright, friendly, helpful bunch of people, well-intentioned in wanting to create some fun mods for the community. My only worry is that occasionally, I feel like some modding incarnations may have been promoted to the wider community (e.g. on fb forum) with a sense of "This is fun, this is fine, don't worry, there won't be any problems or side-effects", and some fairly innocent naive people jumped into that world without fully being aware of the potential risks, not even realising they were engaging in a mod.
They may not have even been promoted by the modders, but by new folk that used the mods, thought they were wonderful, posted in the wider community messages like "Hey, try this, it is awesome, works great on my machine, no problems at all, no worries!".
Personally, I feel like any modding tool (whether it be one that permanently modifies the firmware, or one that resides solely on the usb stick) should coming with some initial precautionary warnings: "Hey, this is a mod, we tried to make it as safe as possible, but hey, there's always a risk things could go wrong and you could void your warranty. If things do go wrong as a result of this, don't take those issues to Retro Games, talk them over with us here in the community forum and we'll try get things sorted for you".
Anyways, my goal wasn't to poopoo your efforts here, I think you've all done a wonderful job in achieving all of this, and I enjoyed witnessing the collaborative way you've all gone about it, sharing your smarts with each other and evolving what was possible, further and further.
My only hope was to just to be open to the feedback coming from the other direction, and mull over how both eco-systems can flourish without impacting each other adversely
As for the 4-player joystick idea, I got a surprising amount of detailed feedback on this, on what points of the VICE-code I should be consider digging into, I really appreciated that. Alas, my time is still pretty limited to dig into these things (even writing this post took a lot of time and thought  ). Anyways, I'll enjoy digging into it when the next pocket of spare time comes around
|
|
|
|
Post by gurce on Aug 23, 2020 23:37:16 GMT
One thing I'll share from the response verbatim are the thoughts and ideas relating to how to go about making a 4-player mod, as others here might also find them useful and might have more windows than me to give them some thought
|
|
|
|
Post by jj0 on Aug 24, 2020 8:22:12 GMT
Got some thoughts back from people on the inside, so thought I'd share my take on the thoughts conveyed, in my own words, so I don't lock anybody into an official position
I feel that there's a willingness on their part to engage with the community via the github repo, so it seems like forking is ok. So if you've implemented an idea that you want to put on their radar, it might be worth doing a pull request, they could mull it over, given their own time constraints, how thoroughly tested it is, how feasible they feel it is, etc, they might consider including it in a future firmware update.
I sensed some degree of concern in relation to bricked devices and the impact it has on their business, with more people claiming their warranties due to inadvertently bricking their devices due to fake updates. I can sympathise there. While I personally can comfortably put on my modder's hat and tinker with internals, I do so with the acceptance of the risks involved and that I'm voiding warranty.
My sense of the modder guys in the64community forum, I reckon you're a bright, friendly, helpful bunch of people, well-intentioned in wanting to create some fun mods for the community. My only worry is that occasionally, I feel like some modding incarnations may have been promoted to the wider community (e.g. on fb forum) with a sense of "This is fun, this is fine, don't worry, there won't be any problems or side-effects", and some fairly innocent naive people jumped into that world without fully being aware of the potential risks, not even realising they were engaging in a mod.
They may not have even been promoted by the modders, but by new folk that used the mods, thought they were wonderful, posted in the wider community messages like "Hey, try this, it is awesome, works great on my machine, no problems at all, no worries!".
Personally, I feel like any modding tool (whether it be one that permanently modifies the firmware, or one that resides solely on the usb stick) should coming with some initial precautionary warnings: "Hey, this is a mod, we tried to make it as safe as possible, but hey, there's always a risk things could go wrong and you could void your warranty. If things do go wrong as a result of this, don't take those issues to Retro Games, talk them over with us here in the community forum and we'll try get things sorted for you".
Anyways, my goal wasn't to poopoo your efforts here, I think you've all done a wonderful job in achieving all of this, and I enjoyed witnessing the collaborative way you've all gone about it, sharing your smarts with each other and evolving what was possible, further and further.
My only hope was to just to be open to the feedback coming from the other direction, and mull over how both eco-systems can flourish without impacting each other adversely
As for the 4-player joystick idea, I got a surprising amount of detailed feedback on this, on what points of the VICE-code I should be consider digging into, I really appreciated that. Alas, my time is still pretty limited to dig into these things (even writing this post took a lot of time and thought ). Anyways, I'll enjoy digging into it when the next pocket of spare time comes around Cool that you got that extensive reply. How did you contact them? I've tried to contact RGL with questions on getting the kernel source via their contact webpage and support email address, but have never received a reply. Which is a bit disappointing. I agree there should be a 'Use at your own risk' warning to any mods and a 'Make a backup' as well (which is facilitated by e.g. XWM and the Carousel tool) and a 'If you break it go to the forum and not to RGL' but essentially the device is almost unbrickable due to the FEL mode. I feel the moderators of some of the Facebook groups are overcautious - especially with regards to PCU which doesn't change anything on the actual device. |
|
|
|
Post by gurce on Aug 24, 2020 13:31:26 GMT
Cool that you got that extensive reply. How did you contact them? I've tried to contact RGL with questions on getting the kernel source via their contact webpage and support email address, but have never received a reply. Which is a bit disappointing. I agree there should be a 'Use at your own risk' warning to any mods and a 'Make a backup' as well (which is facilitated by e.g. XWM and the Carousel tool) and a 'If you break it go to the forum and not to RGL' but essentially the device is almost unbrickable due to the FEL mode. I feel the moderators of some of the Facebook groups are overcautious - especially with regards to PCU which doesn't change anything on the actual device. I gave them a ping via their facebook messaging thingie. As for why they opened up more than usual, I can only speculate. I'm also used to getting minimal responses via facebook, I never took it badly, I just always assumed they get so many queries and messages, it's probably too much of a distraction to respond to everyone in the detail they'd like. So, I'll consider myself lucky, this time around
Yeah, I understand how you feel regarding the over-cautious stance in the facebook group to modding. I recall the emotions on the topic got very hot after there were a few people posting their 'help! my mini/maxi doesn't work anymore!' messages there. Most admins went in for the "See, I told you so, naughty naughty" approach. For me, as I've done a bit of modding myself, I wouldn't be one to assertively wave the naughty-naughty stick about at others for doing so So I mainly stayed quiet through that period, as I sensed emotions were running high on the topic. Felt maybe it'd be easier to converse on it in a more objective manner when emotions had settled. I kinda feel like that is slowly happening now, in small increments. I see people now and then posting their mods there, not getting too much grief over it, admins might have a little warning grumble, but it doesn't get too heated like it did before And maybe on the whole, I feel what they did was ok-ish, for those innocent/naive folks that jumped into modding without realising what they were diving into, they gave those people a bit of a scare, added a sense of caution to others before dipping their toe in those waters. So while it was a bit heavy-handed, there was some good intent there. |
|
|
|
Post by gurce on Aug 24, 2020 14:04:44 GMT
Ok, tried something different tonight. Thought I'd try downloading the clean vice 2.4 source (not sure which exact version of vice 2.4 they used, so just got the latest I could find).
I slogged away with trying to get it to build for mac osx with SDL-menus.
Finally got something semi-working there.
I seem to have to run it in this odd fashion, with lots of arguments:
src/x64 -kernal data/C64/kernal -basic data/C64/basic -chargen data/C64/chargen -symkeymap data/C64/sdl_sym.vkm -keymap 0
It starts up, I can press F12 to see the sdl-menu, nice.
But in c64-mode, I can't type anything on the C64's screen yet. I'm guessing I've screwed up the keymap arguments.
My reasoning/thought behind tonight's approach was that perhaps I could try developing my mods locally on the mac, run them there, iterate a bit quicker in getting an idea of what might or might not work.
Once I settle on something that ought to work, I can try patch the redquark vice source in the same manner and see if I have the same luck there
Anyways, past my bedtime, will dabble into it further another day |
|
|
|
Post by spannernick on Aug 24, 2020 22:20:13 GMT
Its the keyboard, its mapped differently, try using the keymap file from the firmware with vice, I was going to do try that Vice 2.4 and compile it but was trying to compile red quark(Carousel) but have a problem with Freetype2 at the moment and it will not compile.
|
|
|
|
Post by spannernick on Aug 25, 2020 10:48:59 GMT
If RGL are more open with the community and share the source files to do with THEC64 then people will be more interested in the devices, that a good thing, that why SNES Mini, MD Mini and PS Classic are more popular. It gets more people involved in the devices if they are modded, I would of not got the MD Mini or PS Classic if they were not modded, everything is modded nowadays, even Mobile Phones are with CFW, that why we have XDA Developers... As I see it, if you are willing to mod your THEC64 and are fiddling with its firmware then you are will to fix the device yourself if it goes wrong and can't expect RGL to fix it for you, thats not fair, if you think like that then you should not be modding THEC64 in the first place. If you are modding THEC64 then you should look up first how it fix it, if something goes wrong, I did. At the beginning I didn't know a lot about Linux, alot I got from THEC64 Community here, without it alot of the stuff to do with THEC64 would not be possible.. Thank you to all for making this a great community.. |
|
|
|
Post by gurce on Aug 25, 2020 12:19:49 GMT
Ok, I had another dabble tonight on my mac-osx vice build.
Finally got the keyboard input working, by running it with:
src/x64 -directory data/C64
This seems to default to the " sdl_sym.vkm" keymap file. I suppose I should try swap this for whatever thec64's vkm file is, but running out of steam tonight
Anyways, I tried to make a mechanism that would listen to CTRL+left-arrow key to switch the joysticks. Here was my attempt:
Seemed to trigger fine on mac-osx, but when I built it into the c64emu.rgl file, it didn't seem to register on the system 
If only I could see some printf output on the hardware, that'd help me debug this better
Think I used to be able to see such output via the uart-mod, but the serial output there seems all corrupted these days (maybe the serial connection got loose, my baby daughter tugged on the serial cord too hard perhaps ).
Anyways... |
|
|
|
Post by gurce on Aug 25, 2020 13:40:58 GMT
Ah ok, got it fixed now. I had all my key-checking logic fine, I just forgot to call my keyswap routine within it, oops
Ok, latest branch contents here does the trick, CTRL + Left-arrow now swaps the joystick (replacing the previous restore key):
re-compiled .rgl file available here:
Some remaining gotchyas: - I still suspect that the extra-buttons on thec64 joystick aren't being swapped (probably isn't a big deal for many games, but probably will be for some) - On my wishlist would be to have a banner message overlaid on the screen informing the user that the joystick has been swapped (don't have the smarts to do that presently, but maybe one day)
Anyways, this is proving to be a nice warm-up for my next goal after this, to try get 4-player joystick support working... Fingers crossed on that, I think that'd be a lot of fun... I just need to make some friends to invite over to try it  |
|
|
|
Post by jj0 on Aug 25, 2020 17:53:37 GMT
Nice!
In the meantime I received a reply from RGL...
My questions were:
- I've read on your website that I can request the kernel/uboot source code via a GBP 5 money transfer. However as I don't live in the UK this is somewhat laborious/expensive, is it possible to use a bank transfer to an IBAN account or to use PayPal instead? If so, can you provide your IBAN number or PayPal adress?
- Do I have to pay GBP 5 per device type (Mini, Maxi) source?
- There is some source code for the Mini available requested and then published by the 'ModMyClassic' team. However this does not seem to contain the actual working uboot NAND driver (uboot does not compile, errors out on the NAND driver) nor kernel NAND driver. For both NAND drivers it would appear that they are different from the version used for the acutal uboot and nand.ko as the NAND Chip ID length used in the sources is 44 bytes whereas the NAND Chip ID length in nand.ko is 48 bytes. If I do request the source(s) fro the Mini and Maxi will this contain the correct source for the uboot NAND driver and the kernel nand driver?
- Would it be possible to publish the uboot and kernel source in the RGL github?
And the reply was:
Thank you for contacting us, as per the instructions on our site, if you can -
'send a money order or cheque for 5 GBP made out to Retro Games Ltd and send it to : GPL Compliance Division, Retro Games Ltd. West Wing Studios, Unit 166, The Mall, Luton, England. LU1 2TL'
A disc will be sent out to you by return.
Thanks for your support
Disappointingly unhelpful...
|
|
|
|
Post by spannernick on Aug 25, 2020 20:27:49 GMT
Nice! In the meantime I received a reply from RGL... My questions were: - I've read on your website that I can request the kernel/uboot source code via a GBP 5 money transfer. However as I don't live in the UK this is somewhat laborious/expensive, is it possible to use a bank transfer to an IBAN account or to use PayPal instead? If so, can you provide your IBAN number or PayPal adress?
- Do I have to pay GBP 5 per device type (Mini, Maxi) source?
- There is some source code for the Mini available requested and then published by the 'ModMyClassic' team. However this does not seem to contain the actual working uboot NAND driver (uboot does not compile, errors out on the NAND driver) nor kernel NAND driver. For both NAND drivers it would appear that they are different from the version used for the acutal uboot and nand.ko as the NAND Chip ID length used in the sources is 44 bytes whereas the NAND Chip ID length in nand.ko is 48 bytes. If I do request the source(s) fro the Mini and Maxi will this contain the correct source for the uboot NAND driver and the kernel nand driver?
- Would it be possible to publish the uboot and kernel source in the RGL github?
And the reply was: Thank you for contacting us, as per the instructions on our site, if you can -
'send a money order or cheque for 5 GBP made out to Retro Games Ltd and send it to : GPL Compliance Division, Retro Games Ltd. West Wing Studios, Unit 166, The Mall, Luton, England. LU1 2TL'
A disc will be sent out to you by return.
Thanks for your supportDisappointingly unhelpful... Ah well it was worth a try.. |
|
|
|
Post by gurce on Aug 26, 2020 4:21:27 GMT
Jj, sorry you didn't have any luck. Ah well, hope we can make do with the little luck that comes our way then. Maybe over time, we might have another little window of luck. Let's see :-)
|
|
|
|
Post by gurce on Aug 27, 2020 12:34:24 GMT
Tonight, was digging for a location in the code where I could potentially inject a banner message about the joystick being swapped.
Wasn't sure if there was anything pre-existing like that, there probably is and I just can't hunt it down as yet.
But anyway, tonight, I tried looking for any brute-force way I could over-write the screen contents.
I settled for injecting code inside "raster-modes.h" - raster_modes_draw_line_cached(). For my first attempt, I just tried over-writing every 2nd raster line to be the colour red, just as a minimalist attempt.
Whenever I get another stab at it, I'll aim to improve on this and overlay some kind of dummy string instead...
|
|
|
|
Post by gurce on Aug 28, 2020 13:07:47 GMT
Tonight, I tried to study what I thought might be an example of drawing strings over the screen, inside the sdl-ui menus.
Some points of interest were: - "arch/sdl/uimenu.c" - sdl_ui_print(text, x, y) : draws the string at desired x,y coord
- "arch/sdl/uimenu.c" - sdl_ui_putchar(c, x, y) : draws the individual chars within the string
- menufont.font gets used within sdl_ui_putchar() to draw the char with the desired c64 font
menufont.font gets set within "arch/sdl/x64_ui.c" - c64ui_init() to be:
sdl_ui_set_menu_font(mem_chargen_rom + 0x800, 8, 8);
The 0x800 offset chooses the 2nd characterset (BIG+SMALL chars), rather than the BIG+GRAPHIC chars.
Still mulling over how this will help me. I recall you guys might have been considering enabling the sdl-menu system at some stage.
As that might be something further down the track, I'm thinking I'll make do with my brute-force screen drawing idea rather than relying on sdl.
I tried pushing across some ideas from sdl_ui_print() into my current injection point within raster_modes_draw_line_cached(), but it isn't working out so well.
Turns out this function only triggers when some region of the screen has its content modified (e.g., by typing in text on that line).
I'm out of steam for tonight, but for next foray, I'll look for another/better home to inject this string-drawing stuff and we'll see how that goes...
|
|
|
|
Post by gurce on Aug 29, 2020 13:02:46 GMT
Ok, made some more progress tonight.
Found a new point to inject my drawing ontop of screen contents, within "maincpu.c" - maincpu_mainloop() function. It's still probably not an ideal location as it gets called too often and will slow things down, but i'll look into a better home later.
I spent some time wrestling with where to find the top-left pixel of the 320x200 area within the draw-buffer, but finally settled for this horrid-looking recipe:
width = vicii.raster.geometry->screen_size.width
+ vicii.raster.geometry->extra_offscreen_border_left
+ vicii.raster.geometry->extra_offscreen_border_right;
BYTE* gfx_ptr = vicii.raster.canvas->draw_buffer->draw_buffer
+ vicii.raster.geometry->gfx_position.y * width
+ vicii.raster.geometry->gfx_position.x + vicii.raster.geometry->extra_offscreen_border_left;
For my first test, I drew a single red line at the top, that worked, so I was happy:
Then I thought I'd try drawing a string instead (to trigger upon pressing CTRL+left-arrow), but oddly, it didn't show up again I then noticed if I started typing characters within its vicinity, the screen would update with my desired content.
Aah ok, the penny dropped. Even with this new injection point, it still only wants to redraw the bare-minimum. So I looked for a repaint mechanism, and found one in "raster.c" - raster_force_repaint(). Neato, that did the trick
Ok, got the beginnings of a text-overlay system now at-least. Still needs more refinements, but I'm content with getting this far tonight |
|
|
|
Post by gurce on Aug 29, 2020 13:32:54 GMT
Oh and some side-thoughts came to mind, that once this brute-force text drawing mechanism is more stable, maybe it we could get the sdl menu system working by routing its draw mechanism to this brute-force method too (hence without needing any sdl-drawing assistance). Anyway, an adventure for another time... :-)
|
|
|
|
Post by spannernick on Aug 29, 2020 13:55:23 GMT
Looking nice.. Maybe put it at the top left and maybe get it to say "JOY PORT 1" when it changes it to port 1 and "JOY PORT 2" when it changes back to port 2.. |
|
|
|
Post by jj0 on Aug 30, 2020 7:45:10 GMT
Looking nice.. Maybe put it at the top left and maybe get it to say "JOY PORT 1" when it changes it to port 1 and "JOY PORT 2" when it changes back to port 2.. Yes, looks cool . Though the text should be something like "GURCE CHANGED YOUR JOYSTICK TO PORT <X>" I think... |
|
|
|
Post by spannernick on Aug 30, 2020 11:51:23 GMT
Oh and some side-thoughts came to mind, that once this brute-force text drawing mechanism is more stable, maybe it we could get the sdl menu system working by routing its draw mechanism to this brute-force method too (hence without needing any sdl-drawing assistance). Anyway, an adventure for another time... :-) Yes that could be 2 keys combo too like CTRL+F1 cause theirs no F12 on a C64 keyboard.. |
|
|
|
Post by gurce on Aug 30, 2020 13:41:00 GMT
Mixed results tonight, a little frustrating
For my attempted tweak via my macbook's vice-source, had some success with displaying the message with this approach...
I no longer rely on some injection point. I just call my debug_msg(x,y,string) function whenever it's needed. It will: - Pause the emulator
- Draw the message on the canvas
- Force the canvas to be repainted
- Pause for 1 second
- Un-pause the emulator
- Force the canvas to be repainted (and in doing so, removing the message)
I then tried grafting the same change into the rgl vice, building it, and trying the new .rgl file on the hardware.
Frustratingly, I just see the64's title/intro thingie fade in and out, and then it just freezes and doesn't get into the carousel.
I tried running it on my c64mini with the uart hack. Luckily, tonight it seemed to show the comms output without corruption. So I was hoping to run 'the64' manually from the terminal and hopefully see some error message explaining why it was failing to jump into the carousel.
But frustratingly, there is no error message that appears The 'the64' simply terminates without giving a reason and leaves me back at the prompt
I kinda wonder if 'the64' is assessing the c64emu.rgl in some way, very early on in proceedings, and if it's not happy with it, it simply backs out?
I also suspect it's probably a mistake on my part, perhaps making an assumption that some mechanism I used which was available on the macbook's vice isn't available in rgl's vice. Just frustrating that I don't get any error msg to provide any hints on this...
Fwiw, I pushed the attempt into the repo:
Also uploaded the .rgl I built of this effort here, in-case anyone knows of any ways to extract more clues on the failure:
Another approach I can try to debug this is to incrementally comment out bits of my recent commit and try it out on the hardware, to see if I can track which bit it is choking on... It'll be a bit tedious, so I'll save that attempt for another night...
|
|
|
|
Post by gurce on Aug 31, 2020 13:43:32 GMT
Had another stab at it tonight, empty-handed once more, but edging closer, maybe...
I had an idea to copy across the strace tool (from the ubuntu-qemu environment), putting it on the usb stick and running it on the hardware with:
strace the64
I compared the output of my failing c64emu.rgl versus a working one. I saw the failing case definitely dies after attempting to open my .rgl file immediately after the splash screen fades out, but alas, it didn't reveal any clues on 'why' it failed.
I then thought it might be interesting to try copy gdb across to the usb-stick and try break on the opening of the .rgl file, to see if the backtrace had any clues. By the time I prepped up my usb-stick to try this though, the uart-hack's serial connection started getting choppy and corrupted again, argh
So gave up on that idea, and just went down the path of manually commenting out parts of my recent commit, to see if it was a particular aspect of it that was the problem.
That was tedious to do, but I seem to have tracked down the culprit, my use of the ui_pause_emulation() function was causing the64 process to die.
So I commented this out. Fortunately, I don't think I need it anyway, as my 1-second pause within my debug_msg() function is blocking anyway.
I tried that on the hardware, the64 accepted my .rgl file fine this time. When I tried the CTRL-LeftArrow shortcut within a game, I witnessed a 1 second pause, but unfortunately, no text overlayed on-top of the game
Perhaps there's something unique about the way drawing is done on thec64 that my code isn't aware of...
I feel like I'll need to either get gdb running on the hardware, or get the c64emu.rgl emulator running within xwm and debug it there...
Anyways, calling it a night |
|
|
|
Post by gurce on Aug 31, 2020 14:29:55 GMT
But wait, one last puff of steam left in me. I was scouring through rgl source looking for reasons why the text didn't display, and think I found out why.
Inside redquark's "src/viceport/video.c", I saw this comment:
// This is called repeatedly to render dirty rectangles
// XXX This is disable for reduqark, by link wrapping the follwing functions:
// XXX void raster_canvas_handle_end_of_frame( void *raster )
// XXX void video_canvas_refresh_all ( void *canvas )
// XXX See src/ui/Makefile for
// XXX -Wl,-wrap=raster_canvas_handle_end_of_frame -Wl,-wrap=video_canvas_refresh_all
// XXX
// XXX Nop __wrap_* function are at the end of this file.
// XXX
// XXX Note, video_canvas_refresh_all(), and hence videp_canvas_refresh is called when
// XXX setting the palette, the actual call being within:
// XXX vice/src/video/video-canvas.c:video_canvas_palette_set()
// XXX but this only happens once.
The concept of link-wrapping is new to me, so I read more about it here: drewdevault.com/2016/07/19/Using-Wl-wrap-for-mocking-in-C.html Ah ok, I get it now, he has replaced those two functions with these empty wrappers he added to the bottom of the file: void __wrap_raster_canvas_handle_end_of_frame( void *raster ) { };
void __wrap_video_canvas_refresh_all ( void *canvas ) { };Aah, I had made use of this video_canvas_refresh_all() function within my debug_msg() function, so this would explain why I don't see any text now... So the question then becomes, does the64's vice give me any alternative way to refresh the screen contents? I'll look into that tomorrow. |
|
|
|
Post by gurce on Sept 1, 2020 13:10:28 GMT
Finally hit paydirt tonight
It was still hard-fought, with a lot of failed attempts preceding it, which I'll document here too briefly:
- To try fix my screen-repaint woes, I tried making a copy of the video_canvas_refresh_all() function, and called that un-wrapped version instead. That didn't work.
- I started to worry if the canvas draw-buffer format was different on the64 compared to normal VICE, so I tried adding some debug-output directly to basic screen memory (my show_str() function, a poor man's printf ) to show some hex values of the pixel data, and this comforted me that I indeed was drawing to a valid canvas:
- I recall JJ, Nick and others were talking over building the64/carousel source recently, so I hunted down those threads and had a read, browsed through the source inside THE64-C64OSS, looking for clues there.
- ...and yeah, I found hints in there that its concept of repainting relied on redraw events being sent
- This reminded me of a function I had browsed through before "src/viceport/vsync.c" - vsync_do_vsync().
- Inside it, there were some comments relating to sending notifications of FRAME_DONE and waiting for START_NEXT_FRAME.
- So I tried using a call to vsync_do_vsync() to act as my 'repaint'.
- Oh my, it *almost* worked. Upon pressing my shortcut key, the message appeared!
 - The only problem was, it wouldn't disappear after a second, the system just froze up!
- So then I wondered whether it was due to a step within the function relating to waiting for START_NEXT_FRAME.
- So to avoid that, I then tried using solely a step within that function that was responsible for the FRAME_DONE notification:
vsyncarch_presync(); // does a notify FRAME_DONE
...and hey presto! It worked! Felt so happy that I took a video to preserve my trophy moment!
I've pushed the latest tweak into the 'joyswap' branch:
I've also uploaded a new .rgl file here:
Whew... I can sleep a little more peacefully tonight... But gee, that sure was a tonne of effort just to get a small piece of text on the screen! Hehehe
|
|
|
|
Post by jj0 on Sept 1, 2020 16:36:33 GMT
Great stuff! Perseverance wins the day. 👏
|
|
|
|
Post by spannernick on Sept 3, 2020 12:03:23 GMT
Nice one, I will adding it to PCU today.. |
|
|
|
Post by gurce on Sept 3, 2020 12:50:35 GMT
Cheers man. Hope it doesn't make too much extra work for you to update it each time like this.
If so, maybe we can delay the releases until the next major cool tweak gets introduced.
I'm hoping the joyswap+msg mod might pave the way for other ppl to try add in mods of their own too.
E.g. if you wanted to try do something similar as a shortcut key to swap sid chips? Maybe that could work in a similar way too?
Or I was thinking I could try add another shortcut key to act as the freeze button for a freeze cartridge?
I dunno for sure, but I'm guessing adding shortcuts like this and dropping a quick message for the user won't be as painful the next time around :-)
|
|
|
|
Post by wini on Sept 3, 2020 17:11:28 GMT
great job!! I am always impressed, what you get out of the The C64!!
Thank you very much for your work!
|
|
|
|
Post by spannernick on Sept 5, 2020 9:24:29 GMT
Cheers man. Hope it doesn't make too much extra work for you to update it each time like this. If so, maybe we can delay the releases until the next major cool tweak gets introduced. I'm hoping the joyswap+msg mod might pave the way for other ppl to try add in mods of their own too. E.g. if you wanted to try do something similar as a shortcut key to swap sid chips? Maybe that could work in a similar way too? Or I was thinking I could try add another shortcut key to act as the freeze button for a freeze cartridge? I dunno for sure, but I'm guessing adding shortcuts like this and dropping a quick message for the user won't be as painful the next time around :-) Its no problem, it takes about a couple of minutes to add, thanks for making it.. |
|
|
|
Post by gurce on Sept 6, 2020 13:17:26 GMT
Just could squeeze in an hour to quickly attempt some extra shortcuts.
I'm not completely happy with the performance yet, but I'm aiming for:
- CTRL-F = press freeze button (for cartridges like action-replay) - CTRL-S CTRL-R = soft-reset - CTRL-H = hard-reset
There's some issues with the debug messaging to sort out, and I was kinda hoping that the hard-reset would bring the system back to the cartridge menu, which it isn't presently, so I'll need to look into that.
I've dropped my attempt so far here:
Don't think it's worth sharing in pcu just as yet, perhaps give it time for the kinks to be sorted out.
But if anyone wants an early peek at it, a preliminary rgl file is here:
|
|
). Anyways, I'll enjoy digging into it when the next pocket of spare time comes around 
Feb 5, 2024 14:16:57 GMT