|
| |
AKA :
actual versions of my games on one disk.
Credits :
| Code | .... | Peiselulli of Performers, PriorArt, Tristar & Red Sector Inc., VICE Team |
| Music | .... | Ben Daglish |
| | | Linus of Arsenic, Camelot, Fossil, MultiStyle Labs, Oxyron, Performers, SHAPE |
| Graphics | .... | Veto of Oxyron, PriorArt, Tristar & Red Sector Inc. |
| Loader | .... | Mafiosino |
Download :
Look for downloads on external sites:
Pokefinder.org
Goof Info
Submitted by Peiselulli on 24 June 2020
| Add fixed version with the help from Krill. |
Goof Info
Submitted by Krill on 21 June 2020
It seems that a workaround is simply power-cycling the drive before RUN.
Otherwise, the following program would re-initialise the drive from software (without the lengthy memory check), see $eb22 at http://unusedino.de/ec64/technical/aay/c1541/ro41eaa0.htm .
The second open is to make sure that the buffer in question ($0600 in the drive) will not be used for opening the file to be loaded by the menu.
10 OPEN15,8,15
20 PRINT#15,"M-E";CHR$(34);CHR$(235)
30 CLOSE15
40 OPEN1,8,1,"#3"
Without fixing the loader itself, putting above code before the SYS statement in the menu BASIC starter (or using the assembler equivalent before installing the loader) might be an option. |
Goof Info
Submitted by Peiselulli on 21 June 2020
I took "track1f_acme.asm" from
Mafiosino Trackloader (19x)
And sorry, I'm not a loader expert, simply a user. But on my 1541-II (real) it works without any quirks, so I had no scruple to use it. Maybe somebody can fix this for future releases ? |
Goof Info
Submitted by Krill on 21 June 2020
| Oh and there does not seem to be any kind of error detection via checksum, but that's a bu...design decision not unheard of, for many loaders, even current ones. |
Goof Info
Submitted by Krill on 21 June 2020
Looked a bit into the loader problem, and it is most likely a loader bug regardless of running on a physical or virtual machine.
After installing the loader to drive RAM, the file to be loaded is opened via the normal OPEN command.
After opening the file, its starting track & sector position is known and the custom drive code is executed.
Now, it may happen that the OPEN procedure in the drive's DOS would allocate a buffer that happens to contain part of the previously installed custom code, in order to load the file's first block, thus overwriting part of the custom code with file data.
Which buffer is allocated depends a lot on various circumstances, the "history" of what the drive did between reset and load, which file is loaded, etc.
There seem to be some differences in the buffer allocation code between 1541 and 1541-II ROMs, so this would explain the (higher?) proneness to crashes on 1541-II compared to 1541.
Still, it's a loader bug not to ensure fixed block allocation for the OPEN procedure. |
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs (5)
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Support CSDb | |
|
 |  |
|
