'Vorpal (later) analysis'
Author:Markus Benko (registered user: 16 posts )
Date: Mon, Dec 05th, 2011 @ 11:38 ( . )

Thanks for this detailed explanation of the format. Until IPFs become available and usable in emulators for these titles, this will help verifying track dumps and G64 files fore those titles.


REPLY: [With No Quote] --- [With Quoted Text]

'Vorpal (later) analysis'
Author:IFWSPS (guest: search)
Date: Tue, Dec 06th, 2011 @ 11:38 ( . )

You are welcome, and thanks for working on a new tool - once it is ready please consider posting about it at [link] as well :)


REPLY: [With No Quote] --- [With Quoted Text]

'Vorpal (later) analysis'
Author:The Doctor (guest: search)
Date: Thu, Mar 28th, 2013 @ 02:42 ( . )

On 12/06/2011 @ 11:38, IFWSPS wrote :
You are welcome, and thanks for working on a new tool - once it is ready please consider posting about it at [link] as well :)
:
--



Cool stuff. I used to hack back in the early days and got quite familiar with disk formats and controlling the drive directly. But you've obviously taken it further with the dissection of Vorpal. Amazed that people are still studying this platform.


REPLY: [With No Quote] --- [With Quoted Text]

'Vorpal (later) analysis'
Author:bluebirdpod (registered user: 28 posts )
Date: Tue, May 07th, 2013 @ 19:53 ( . )

not really, its amazing that peeps are still messing with Amstrad CPC64, and Apple2 stuff. Now the best selling 8-bit computer the Commodore 64, is still my favorite computer EVER. I miss all the glory. We had FUN. now its just work. LIVE FOREVER !! ! ! !!!!!


REPLY: [With No Quote] --- [With Quoted Text]

'Vorpal (later) analysis'
Author:SaxxonPike (registered user: 16 posts )
Date: Tue, May 28th, 2013 @ 20:47 ( . )

In the last two years I've practiced a lot with 6502 assembly, going so far as to implement barebones support in the Bizhawk emulator and code a few utilities for the C64 myself. I decided today I was going to look back at this project and pick at it once again.

I find it fascinating how fast this fast loader really is. It just blows through tracks like it's nothing. I didn't see that there was much to obscure the code because there isn't actually time in the transfer loop for it.

While extracting the files from Legend of Blacksilver using its own code, I found that the sectors it uses contain about $80 bytes worth of data. The file table is located at $FA04 in computer memory (which can be observed when the Kernal is disabled.) GCR is assembled by the drive using two tables that take up about a quarter of available RAM there. I'm still not sure how the sectors are laid out on the drive, but in this game it appears the directory is in a low track, I think it was track 2 on each disk. Interestingly enough, even using VICE 2.4 "x64sc", the directory didn't seem to load up the same every time. The game appears to use the integrity of the directory itself to determine if the rest of the disk is valid data. Sometimes the directory would be loaded in with the bits shifted once (left, IIRC). Once the directory loaded fine, the rest of the disk seemed to work OK, until a disk change. This is using the set of the "patched" G64 files. Hoxs64 doesn't actually exhibit this issue, and I can't figure out why.

Still crazy that it has the capability to load its largest files in a couple seconds.

With a bit of patience, I was able to extract all the game files and export them using monitor commands. It was a little tedious, but I'm going to be putting together something really special.


REPLY: [With No Quote] --- [With Quoted Text]


--- 0 Users Online --- 0 Recent Unique Posters

Q128=1670105856 - Threads: / 1670105856