|
Post by spiff on Sept 3, 2006 7:54:43 GMT -5
I just joined the PETSCII-forums, although I have spent a lot of time browsing arround in here earlier . I bought a PAL DTV (v2) in april and immediately modded it with keyboard, IEC etc.: symlink.dk/nostalgia/dtv/I also did some experiments with a color-fix: symlink.dk/nostalgia/dtv/colorfix/Now, let me go ahead with a question I have been wondering about for some time: When I boot my DTV to BASIC-mode (with CTRL) and do a directory listing, I get about 44 entries (the 30 games and some of the easter egg stuff). I am aware that this directory does not list all the files on the flash, but I assume the reason for even having the list is that it would be possible to load the games and programs from BASIC mode. However, only 15 of the files can actually be loaded from this mode. Is this due to the bug in the kernel loader (i.e. will this be resolved if I patch the kernal with tlr's kernalpatcher)? Thanks in advance
|
|
|
Post by tlr on Sept 3, 2006 12:26:20 GMT -5
Welcome! Very nice measurements on the colors! I especially like the chroma measurements. Now, let me go ahead with a question I have been wondering about for some time: When I boot my DTV to BASIC-mode (with CTRL) and do a directory listing, I get about 44 entries (the 30 games and some of the easter egg stuff). I am aware that this directory does not list all the files on the flash, but I assume the reason for even having the list is that it would be possible to load the games and programs from BASIC mode. However, only 15 of the files can actually be loaded from this mode. Is this due to the bug in the kernel loader (i.e. will this be resolved if I patch the kernal with tlr's kernalpatcher)? The kernalpatcher only fixes the reported end address from kernal load routine, it will not make any files load that didn't load earlier. Note that "$" is just a file in the flash. There is nothing that guarantees that a name listed in "$" even exists in the flash. To see the actual files in the flash you can use dirscan.
|
|
|
Post by spiff on Sept 3, 2006 13:58:57 GMT -5
Thanks. And thank you for the reply. Yes, I think the scope pictures help to get some hard facts about how important the different parts are. Perhaps I got a little too carried away with the desciption of how the composite signal is encoded. At some point I may move this information into a separate article, so this one just explains that there is little need for the chroma-fix. Yes, I am aware of that. I have also sucsessfully modified the $-file, first by adding a second entry for zaxxon, which was already loadable from BASIC, and secondly by adding bubble bobble (encoded with your dtvpack and placed at $1E0000). But I really cannot understand why the files are listed in the $-file if they cannot be loaded from BASIC. Is the $-file used for anything else? Wouldn't it be nice if all the games would load correctly from BASIC? I know the menu works fine, but having the listing in BASIC work too is nice, even if it is just faked (i.e. the $-file). I guess it would be possible to modify the programs that are on the DTV with the appropriate BASIC-loader, so they can be started in this way, right? (although it may be too much work for something that dosn't really make much of a difference). So the fixes in the kernel loader code only updates the end address? When is this needed? Yup, played with that as well. Is it correct that the SYS address is listed as 0 for all the games in the original PAL DTV (v2) flash? Is this SYS address used by anything in the original flash? or is it just used in the new menu system?
|
|
|
Post by tlr on Sept 3, 2006 14:19:13 GMT -5
But I really cannot understand why the files are listed in the $-file if they cannot be loaded from BASIC. Is the $-file used for anything else? Wouldn't it be nice if all the games would load correctly from BASIC? I know the menu works fine, but having the listing in BASIC work too is nice, even if it is just faked (i.e. the $-file). I guess it would be possible to modify the programs that are on the DTV with the appropriate BASIC-loader, so they can be started in this way, right? (although it may be too much work for something that dosn't really make much of a difference). Most of the games are not packaged as basic programs, rather complete unpacked memory dumps. This makes sense for the DTV as the file system is already packed, and this will make loading-/start-times faster. I guess they could have slapped a sys-line on most of them, but it was hardly a design criteria. So the fixes in the kernel loader code only updates the end address? When is this needed? When loading a program from flash that requires $ae/$af and/or $2d/$2e to be correct. This is especially true for basic programs, but also many (older) crunchers require this. Yup, played with that as well. Is it correct that the SYS address is listed as 0 for all the games in the original PAL DTV (v2) flash? Is this SYS address used by anything in the original flash? or is it just used in the new menu system? This is not used in the original flash. It is used by Roland in his menu. I thought it was clever so I adopted it for dirscan. If anybody else makes a menu they should use the same for compatibility.
|
|
|
Post by spiff on Sept 3, 2006 15:59:11 GMT -5
Most of the games are not packaged as basic programs, rather complete unpacked memory dumps. This makes sense for the DTV as the file system is already packed, and this will make loading-/start-times faster. Agreed. I guess this would also be possible to do with other games that one wants to add to the DTV. With the 2MB flash (compared to 180kB floppies), I would totally agree that a decruncher is not needed, and the faster startup is more important. Again, I think you are right. But also, adding such a SYS-line should be fairly easy. Perhaps at some time I will give it a try. I just think that being able to easily run these programs from BASIC is nice - for instance if the menu is not available. And starting with the games that are currently on the DTV means there are no other parts that need to be fixed (such as the device number in the multi-part games). OK, so when loading other games (e.g. from IEC), which have not been modified to run on the DTV, the new kernal will give me a better chance of success, correct? Excellent, then I think I finally comprehend why your documentation (about the dtv kernal) describes these bytes as unused, and running dirscan on the unmodded DTV unit did not show anything. Thanks for the replies. I guess a kernal upgrade is in place then. BTW: I assume the fixes to the kernal will still work with the other bits and pieces in the flash (i.e. loading INTRO). Provided, of course, that the shift key thing is not reversed, which would require a keyboard to be connected in order for this to happen.
|
|
|
Post by tlr on Sept 3, 2006 16:21:39 GMT -5
Again, I think you are right. But also, adding such a SYS-line should be fairly easy. Perhaps at some time I will give it a try. I just think that being able to easily run these programs from BASIC is nice - for instance if the menu is not available. And starting with the games that are currently on the DTV means there are no other parts that need to be fixed (such as the device number in the multi-part games). Nice, but probably not worth the effort. Adding the sys addresses to the directory is useful though. OK, so when loading other games (e.g. from IEC), which have not been modified to run on the DTV, the new kernal will give me a better chance of success, correct? The end address bug only affects loading from flash. BTW: I assume the fixes to the kernal will still work with the other bits and pieces in the flash (i.e. loading INTRO). Provided, of course, that the shift key thing is not reversed, which would require a keyboard to be connected in order for this to happen. Loading intro works exactly the same. I haven't played all the games to the end to see if they work the same, but I assume that they will. Besides nobody reported any problems with it, yet. Patching the kernal will also give the much needed option of running custom code in flash at $1f8000 with a fail safe fallback.
|
|
|
Post by spiff on Sept 4, 2006 9:09:45 GMT -5
Nice, but probably not worth the effort. Adding the sys addresses to the directory is useful though. Well, I really don't have time to do it now, anyway. But I might still do it at some point, just because it will allow me to get to know a little more about how the files are loaded on the C64 or DTV, and how this interacts with the kernal. It's all a learning experience. Ahh, yes, I should have guessed (I did look through the kernal disassembly and saw the comments). But thanks for pointing it out anyways. Well, I don't think I will be playing through all the games either. I just wanted to make sure that if I reflash a DTV and otherwise put it back together as a unit without any keyboard/IEC/whatever connections, it will still work. ;D Yes, I can se that coming in handy. So I think it is just a matter of when I get the time to upgrade my kernal now. Thanks for the insight.
|
|
zee
Junior Member
Posts: 75
|
Post by zee on Sept 11, 2006 13:23:30 GMT -5
Just started modding another PAL DTV V2 and tested out spiff's lumafix. I captured these images using s-video connected to my DV camcorder which was hooked to the PC over firewire. See how the presence of the capacitor C10 has almost no effect to the quality of the s-video signal (check the large pictures in the zip to see more clearly). This is how the menu from Summer Games now looks (still not too good). And here are the unpacked BMP screenshots for closer inspection. oms.wmhost.com/dtv/dtv2pal_svideo_lumafix.zip
|
|
|
Post by Roland on Sept 11, 2006 14:33:52 GMT -5
well, the reason for the summer-games image is a VERY BAD selection of the 16 out of 256 colors.
a small patch in the kernal which sets the 16 default values would help a lot!
|
|
zee
Junior Member
Posts: 75
|
Post by zee on Sept 11, 2006 16:33:27 GMT -5
Ok, I replaced the default palette in kernal with this one: 00 0F 35 BC 67 E9 84 1E 27 14 39 05 09 EE 89 0C Then tested it with kernalpatcher from RAM but the colors didn't change... --------------- Ah, found what kept the palette from changing. Seems it doesn't get reloaded when the kernal is tested from RAM. On the left are the original colors after spliff's lumafix and on the right are the new colors from the good old Pepto's palette. And the large pictures as usual... oms.wmhost.com/dtv/dtv2pal_palettefix.zip
|
|
zee
Junior Member
Posts: 75
|
Post by zee on Sept 12, 2006 16:01:41 GMT -5
And also those familiar bootpictures for comparison... As before, on the left images taken with spliff's lumafix and on the right after changing the kernal palette.
|
|
|
Post by tlr on Sept 12, 2006 16:12:30 GMT -5
Ok, I replaced the default palette in kernal with this one: 00 0F 35 BC 67 E9 84 1E 27 14 39 05 09 EE 89 0C Then tested it with kernalpatcher from RAM but the colors didn't change... Hmm, this doesn't sound right. I'm pretty sure it works. Load the kernal patcher 0.8. Load your kernal into the patcher. Test kernal in ram. Works? Nice colors BTW. Have you tested them with the known color cycles? Roland also did a modded palette. Have you compared?
|
|
|
Post by David Murray on Sept 12, 2006 16:29:41 GMT -5
And also those familiar bootpictures for comparison... That is weird. Is this how the Mammoth toys logo usually looks? It looks like a 16-color image done in the C64 multi-color mode. Here is an example of a Mammoth Logo from the Hummer without any kind of video fix. galaxy22.dyndns.org/dtv/hummer/game/mammoth_logo_640.jpgI don't have a luma-fixed version handy at the moment.
|
|
zee
Junior Member
Posts: 75
|
Post by zee on Sept 12, 2006 17:16:01 GMT -5
Hmm, this doesn't sound right. I'm pretty sure it works. Load the kernal patcher 0.8. Load your kernal into the patcher. Test kernal in ram. Works? Nice colors BTW. Have you tested them with the known color cycles? Roland also did a modded palette. Have you compared? I used kernalpatcher 0.8 to test. Only after I manually called the screen init routine (SYS64029) the colors changed. And I've propably missed Roland's palette... Uh, that looks quite terrible. To me it looks like they just used the default palette to create the logos. Anywho, here's few more comparison shots: On top the original PAL DTV, Spiff's fix in the middle and at the bottom with additional kernal palette fix. And...
|
|
|
Post by spiff on Sept 13, 2006 10:54:00 GMT -5
zee, what a nice comparison. I particularly like the last images of the C64 boot screen.
How did you come up with the palette values for the kernal fix?
Since it appears you have a framegrabber that can represent the colors fairly well, I guess grabbing the colors of the C64 and then comparing to the possible colors (e.g. from TLR's palette utility) and finding the closest match would make the most true colors. Is this how you did it?
Unfortunately I don't have a good frame grabber card, so for now I am stuck with taking pictures of the TV screen, which gives a lot of problems with varying light levels etc.
|
|