23 July 2024, 15:40 | #21 |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,604
|
There are also examples where it doesn't seem to work but in fact it is something else...
Not all games will load and start with: LOAD"*",8,1 ... because the required file is not always in the first place on the disk, which can give the wrong impression that the game is not working. Here are some examples: forbidden_forest[cosmi_1983](later) ... LOAD"*",8,1 (works because FF is the 1st file on the disk) forbidden_forest[cosmi_1983](earlier)(!) ... LOAD"FF",8,1 (works because is not the 1st file on the disk) top_gun[ocean_1986](pal) ... load"*",8,1 (works because LOADER is the 1st file on the disk) top_gun[thunder_mtn_1987](pal)(!) ... LOAD"LOADER",8,1 (works because is not the 1st file on the disk) repton[sirius_1983](!) ... LOAD"SIRIUS",8,1 and RUN (works because is not the 1st file on the disk) platos_cave[krell_1983] ... load"MENU",8,1 and RUN so sometimes it is necessary to look into the directory structure to find an explanation if it doesn't work! (Fortunately, it is not necessary to type in the emulator, but to look in the directory structure and click on one of the files.) Last edited by amilo3438; 23 July 2024 at 16:44. |
23 July 2024, 17:30 | #22 | |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,604
|
Quote:
andy_capp[mirrorsoft_1987)(pal) ... no need to disable wobble or other! vixen[martech_1988](pal)(paraprotect_v2) ... no need to reduce speed now! and probably some others too! PS. I haven't found anything so far that requires disabling decelaration! Almost everything that has been tested today simply works! EDIT: Found it: "falcon_patrol[advantage_1983]" ... now need decelaration to be disabled to work! (I guess now it's like vice(sc) which doesn't emulate it anyway.) PS. It doesn't work on Micro64 emulator too if mechanic emulation is enabled! EDIT: No need to disable deceleration if selected drive is 1541-C in denise! Last edited by amilo3438; 28 July 2024 at 17:05. |
|
23 July 2024, 21:32 | #23 | |
Registered User
Join Date: Sep 2003
Location: germany
Age: 45
Posts: 486
|
Quote:
Correctly, an old G64 should no longer run. For the user, this is confusing and not understandable why some still work, and he gets the impression that it is a bug. |
|
24 July 2024, 18:49 | #24 |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,604
|
15) championship_lode_runner[br0derbund_1984](!) ... when the fire button is pressed on the title screen, it won't go into the game, it goes back to the title screen!? (works in hoxs64, micro64 and vice but not in denise!?)
EDIT: It works in denise if disk is unprotected! Last edited by amilo3438; 24 July 2024 at 18:57. |
24 July 2024, 19:36 | #25 | |
Registered User
Join Date: Sep 2003
Location: germany
Age: 45
Posts: 486
|
Quote:
|
|
24 July 2024, 20:08 | #26 |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,604
|
16) turrican_s1[rainbow_arts_1990](pal) ... Works only in denise and hoxs64!!! (weak bits/illegal GCR on many sectors) (vice and micro64 fail to load it)
Note: But the other side of the disc needs a new conversion from nib to work! PS. Maybe you should check it on a real c64 & ultimate-II+ to see how accurate it is! (i.e. can it be trusted when testing) EDIT: Some info from c64preservation.com... It's Rainbow Arts earlier protection that is used on the original release of Turrican, and was also used on other Rainbow Arts, Magic Bytes, and Time Warp disks released 1987-88. (all PAL) It contains an aggressive sync length check on track 36 that, if the correct length isn't found, formats the disk and resets the C64. On Turrican it is on track 37 and locks instead of formatting the disk. PS. So, many disks in existence that use this protection don't work in any emu, but... if they are re-converted from nib, using the latest nibconv with the -r option, there is a good chance that they will work. Some examples: katakis/denaris and great giana sisters which worked only after the conversion, but there are still also those (albeit in the minority) that did not work even then. Also, re-converted version of "16) turrican_s1[rainbow_arts_1990](pal)" will load in vice(sc) emu, but locks on track 37! (while works in denise and hoxs64) Last edited by amilo3438; 25 July 2024 at 21:44. |
26 July 2024, 22:24 | #27 |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,604
|
17) jump_jet[anirog_1984] ... Another one that needs 1541 drive to work!
18) wild_west[ariolasoft_1985] ... same Is there any reason why 1541-II is set default in the emu!? Is there something special that works on the 1541-II and not the 1541 drive!? PS. Yes, I remember something was broken on 1541 kernal that was fixed in 1541-II! (maybe that's why 1541-II is default, but compatibility seems lower) Last edited by amilo3438; 26 July 2024 at 22:55. |
27 July 2024, 17:36 | #28 | |||||
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,604
|
I found an interesting topic on Lemon64 forum (from 2011) which deals with the ways of archiving C64 discs.
There seem to be two ways to do this: 1) With the use of Nibtools and 1541 disk drives. 2) Kyroflux from the PC drive. The first archiving method is the one used by C64PP (i.e. C64PreservationProject) Another way is the one used by SPS (i.e. Software Preservation Society). You can find out more about it on the Lemon64 forum: https://www.lemon64.com/forum/viewtopic.php?t=39740 Some quotes... 1) Nibtools Quote:
Quote:
So I guess, around that time, they introduced their own new Extended G64 SPS file format, firstly introduced into VICE 2.4a SPS! PS. Two disk images with a new file format can be find on their site: https://kryoflux.com/?page=download (find on the bottom: G64 Images) What is interesting is that nibtools/nibscan.exe (using last version) can recognize this new format and reports it as: "Extended SPS G64 detected"! (so any emu can recognize this also) What is also interesting is, when you re-convert a .nbz file into .g64 by nibtools/nibconv.exe (using last version) it doesn't convert it into this new extended format, or I don't see in option how to do that. So, after converting with nibtools, a g64 file stays in an old (not extended) format! (or this is not necessary for existing nib/nzb files) Quote:
Does a NIB file contain more raw information than a G64 file? Quote:
Is Kyroflux better than NIBtools? Quote:
EDIT: Yes, more info about here... KryoFlux: enhanced G64 generation & new VICE patch --> https://www.lemon64.com/forum/viewtopic.php?p=517763 Last edited by amilo3438; 27 July 2024 at 22:41. |
|||||
27 July 2024, 18:45 | #29 | |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,604
|
Quote:
(Apart from the two g64 files offered on the kyroflux pages, there is actually nothing else available in a new extended g64 format!) Last edited by amilo3438; 27 July 2024 at 18:52. |
|
27 July 2024, 23:28 | #30 | ||
Registered User
Join Date: Sep 2003
Location: germany
Age: 45
Posts: 486
|
Quote:
Quote:
--------------------- The NIB files don't show flux changes (what is really on disc) and are not sufficient for preservation. only IPF, P64 have these kind of informations. the NIB files contain GCR encoded data (=from disc controller decoded raw data) |
||
28 July 2024, 02:47 | #31 | |
Registered User
Join Date: Aug 2006
Location: Augusta, Georgia, USA
Posts: 559
|
Quote:
1) Tracks used to be limited to 7928 bytes, which while never in the specification, was a limitation in VICE. This is removed now since a long time ago. 2) Tracks are now shortened/truncated to a length that matches closely to the density of the track (also you can override this with -C). In the past, you could have (for example) a much longer track than could fit on a physical disk track. Because VICE now adjusts it's bitrate to the length of the track (maybe that's the best way they could think to improve it) these "old" G64's may not work properly. 3) It will automatically render G64's with fat tracks properly. VICE used to ignore half tracks and just present existing data from the previous track, and it longer does this. As mentioned, you can re-convert to the new "format", even just using the existing G64 and convert in-place. Still, there are limitations using a 1541 to read sync-lengths, so they will never be perfect. Protections that expect an accurate sync length may fail unless you adjust the image. As far as I know, the only thing that SPS added was a extra block of data in the header that describes some internal information used by DTC to write the image to disk. VICE ignores it. |
|
28 July 2024, 14:22 | #32 |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,604
|
@r.cade
Thanks for the detailed feedback! Now we learned something new, which is that we have 3 versions of G64 files: 1) old g64 format ... generated with older versions of nibconv 2) new g64 format ... generated with newer versions of nibconv 3) extended sps format ... generated by sps team tool However, I would have some additional questions, so if it wouldn't be a problem to answer at least some... What remains unknown is since when was that change introduced for the nibconv new g64 format!? In fact, I'm currently testing some 2015 dated files so I'm not sure if it's the old format or the new format! (i.e. would it be necessary to convert them, although most of the ones tested so far did not have any problems) I'm also wondering, is there a way for say a user or an emulator to tell the difference between the old and the new format!? (except maybe by the date of creation or testing whether it works on an old or a new version of vice) Browsing the c64pp database, I come across files that are marked green (ie verified), so I wonder does this mean that such files have been tested/verified that they work on the original 1541 disk drive after writing to the diskette, and can we consider such files valid enough for the verification of emulator testing!? (e.g. in the case that it does not work on the emulator and it is checked that it works on the 1541 disk) What I notice that is missing in the database is the information about whether any of those verified files still needed to be "additionally processed" before it was written to the disk!? (or for some reason it is left to the user to experiment on his own) Is there any information about which files these are, and that they have been successfully converted to a diskette, that the emulators are still not able to run them!? (this would be of interest when checking the accuracy of the emulator) Last question... Can nibwrite and nibconv be considered similar in function, except that the first one writes to a diskette and the second one creates a g64 file!? (i.e. if a successful write to the diskette was created, then with the same procedure we get a successful g64 file ... and vice versa) Thanks in advance for the answers! Last edited by amilo3438; 28 July 2024 at 14:59. |
28 July 2024, 14:59 | #33 | |||||
Registered User
Join Date: Aug 2006
Location: Augusta, Georgia, USA
Posts: 559
|
Quote:
Quote:
Quote:
Quote:
Quote:
|
|||||
28 July 2024, 15:13 | #34 |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,604
|
Thanks for the quick reply!
This further clarified whether the g64 format could be suitable for reliable emulator testing. After testing quite a few files and comparing them on different emulators, it can be concluded that it depends on the particular emulator. On, for example, hoxs64, the tested falcon works without problems, while on others, denise and micro64, it is necessary to turn off deceleration emulation or mechanical emulation in order to work. EDIT: No case anymore as it works on denise with deceleration enabled if disk drive is 1541-C! (same drive as in Hoxs64) Start trekking ii (from other source) also works on hoxs64, but for the same on denise and micro64 it is necessary to turn on deceleration or mechanical emulation for it to work. So it either works or it doesn't... the only thing that remains is the comparison that if something doesn't work on the denise (emu which I'm testing) but works on others, determine the reason why it's like that. Although it remains incomprehensible why it sometimes works when the RPM is changed on say 305, while on another emulator eg hoxs64 it has no effect at all. (it's like hoxs64 is somehow adapting to the file it's reading) EDIT: So I wondered again why falcon works in hoxs64 and found the reason... hoxs64 uses 1541-C drive! falcon_patrol[advantage_1983] ... in denise no need to turn off deceleration emulation if selected drive is 1541-C!!! @PiCiJi - After this knowledge I'm not sure if Emulate Motor Deceleration (hack) is needed anymore!? @r.cade - I wonder if it depends on the version of the disk drive from which a nib file was created! (ie does it have any effect) ----------------- 19) vampires_empire[digitek_19xx](weak) ... c64pp database says "protection fails in emulation", but it works in all 4 tested emus! (denise, vice(sc), hoxs64, micro64) (Note: To load use: LOAD":*",8,1) Last edited by amilo3438; 29 July 2024 at 10:13. |
28 July 2024, 21:45 | #35 | ||
Registered User
Join Date: Sep 2003
Location: germany
Age: 45
Posts: 486
|
@r.cade thanks for infos
Quote:
Quote:
|
||
28 July 2024, 22:28 | #36 |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,604
|
No, the entire test time it was enabled! It was only necessary to turn it off for one game (Edit: falcon), but since that game works even if it is enabled but with 1541-C drive, then nothing left for which it would need to be disabled.
So, everthing that work, work with the enabled motor deceleration! And for other that doesn't work, disabled motor deceleration didn't help. ( and some of might work after re-converting it with nibconv tool ... what will test after ) So far I found very low % of those that doesn't work in comparison to those that work. EDIT: Also, in some cases where denise needs RPM to set higher in order to work, other emus like hoxs64 might sometimes load it (but mostly will not load it if a g64 needs higher RPM) and this is the only difference! So far a very few games needed RPM to be set higher than normal 300 RPM! PS. After changes mentioned in post#20, denise works now very similar to other emus! (and I use it with emulated motor deceleration enabled all the time) EDIT2: No need to change anything, specially option to disable emulated motor deceleration! No, needs to be removed because it's a hack and not a real disabled deceleration emulation! I found it useful in situations when you need to change RPM in order some g64 to work... just leave on default 300RPM and only disable deceleration and it might work! (usually if something works in vice and not in denise, this is what you need to do ... just disable deceleration) Example: I re-converted "out_run_s1[us_gold_1988](pal)(!)" from nbz to g64 and it work without to change RPM in denise if emulated deceleration is disabled... otherwise it would need to change RPM to 298 setting! Also, if re-converted with option -C297, it will work on denise with 300 RPM + deceleration enabled! (but will still not work on hoxs... not sure why! Edit: Seems 1541-C drive don't like it, same in denise if 1541-C!) Also it will work in vice but not in denise if emulated deceleration is disabled! (so it's not the same as vice, it's a hack and needs to be removed or done right!) New: Tested same in micro64 with mechanical emu. enabled =work, and with disabled = not work ... but in vice that doesn't emulate deceleration it works! (I'am confused!) ------ Some nuances between emulators that can affect whether something works or not... Denise ... use 1541-II disk drive (by default) + emulate motor deceleration! (with option to disable it Edit: False, curently it's a hack (post #23) that needs to be removed or done right or maybe not needed at all !) ... PAL & NTSC support! Vice ... use 1541-II disk drive (by default) and only is one that does not emulate motor deceleration! ... PAL & NTSC support! Micro64 ... use 1541 disk drive (by default) and you have option to enable disk mechanic emulation! (not sure what is default) ... PAL only! Hoxs64 ... use 1541-C disk drive (by default) and it seems to support motor deceleration without option to disable it! ... PAL only! Last edited by amilo3438; 29 July 2024 at 17:21. |
29 July 2024, 16:56 | #37 |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,604
|
20) rolling_thunder[tengen_1989](pal)(cyan2) ... Works in vice and micro64! (fails in denise and hoxs64) EDIT: Works in denise if disk wobble disabled!
21) chessmaster_2100_s1[software_toolworks_1988](multi_density)(!) ... Stops at track 16! (Note: Patched version works!) - Quote from the C64pp database about: "Protection: looks for 4 GCR bytes written at non-standard density in tail gap of track 16 sector 20. EOR'd together must = $79." - If the g64 is correct, ie if not all necessary data is missing, this could be a challenge! Last edited by amilo3438; 29 July 2024 at 18:09. |
29 July 2024, 21:25 | #38 |
Registered User
Join Date: Sep 2003
Location: germany
Age: 45
Posts: 486
|
@amilo3438
The difficulty here is that you can't tell how far the G64 deviates from the standard behavior to conclude how if emulator bug exists. I'll wait here until you're done (final report or so) or don't feel like it anymore. To decide whether something can be changed in the timing or possibly in the options for the mechanics emulation: Wobble, Motor Aceleration, Deceleration, Stepper Seek Time. The actual G64 emulation is certainly almost identical in the mentioned emus. edit: exception could be Micro64. changelog gives some hints Last edited by PiCiJi; 29 July 2024 at 21:31. |
29 July 2024, 21:41 | #39 | |
Registered User
Join Date: Sep 2003
Location: germany
Age: 45
Posts: 486
|
Quote:
Last edited by PiCiJi; 29 July 2024 at 21:51. |
|
30 July 2024, 13:17 | #40 | |||
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,604
|
Quote:
Quote:
PS. So for the same reason I don't report what didn't want to run in denise and any of the other emulators, but only comparisons with others. (focusing primarily on Denise) But not everything is so simple! We learned something from all this, and that is that there are situations when we suspect that the g64 is faulty, but it just needs some specificity in the settings, eg a different version of the disk drive, or in the start command (":*" instead of "*" ), or it needs to be started by entering the file name because it is not at the beginning of the disk, or TV standard (PAL or NTSC), that could have an effect on making it work. Quote:
In fact, the focus now seems to be on finding something that would work on one of the other emulators and not on denise! (to make collection of examples) Perhaps the focus should be shifted to those more tricky protections, such as v-max, vorpal, bitrate changes on the same track, track-to-track synchronization etc.!? (but I'm not sure how reliable the collection I'm testing is in that regard) Any idea if Denise is having trouble with any of the more complex protections? (of course, for such testing it is necessary to have a reliable disk image whose has been determined to be correct) PS. Actually, the beginning of the idea for this test started when I read on another forum that some of the g64 don't work on emulators... so I said let's check how accurate Denise is in disk emulation. However, in the meantime I realized that g64 is not the same as ipf for the amiga, so it cannot be determined with certainty whether or not something should work on the emulator. So, if it works then good, if not, you are not sure what the problem is, in the g64 or the emulator itself. (in case you can't get the g64 to work with any changes to the emu settings or with creating a new one) Yes, I could confirm that, except in some rare situations where there is a deviation... like f.e need to change the RPM in Denise, while some other emulators do not notice the difference of +-2 RPM (or sometimes more) on disk rotation! Last edited by amilo3438; 30 July 2024 at 14:47. |
|||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Blitter line mode problems | deimos | Coders. General | 23 | 10 October 2019 10:10 |
Celtic "Meeting Demo", Timing problems in Cycle Exact Mode | StingRay | support.WinUAE | 5 | 26 January 2018 15:15 |
Mani Pulite sprite problems (A500 mode) | andreas | support.WinUAE | 17 | 22 January 2015 14:41 |
Super72 mode problems | mark_k | support.WinUAE | 8 | 16 March 2014 11:16 |
Problems with Detect Idle CPU mode | bdoe | support.WinUAE | 6 | 27 September 2002 13:44 |
|
|