Ian Collier wrote: > Does the Amstrad DSK format not cover this? (I don't actually > know anything about it, except that it is more complicated than > a straight dump of all the tracks on the disk.)
I've not found any official docs for it but I've flicked through the comments in some ASM code that reads them, and it does seem to cover things like unformatted tracks, but I didn't see anything for non-512 byte sectors. I'll have a more thorough look for the format sometime. I'm not really up enough on snazzy disk protection methods to understand what's needed as I never bothered with them myself, so I'll have to have a play with some real disk. Can anyone recommend any demos or games that have use fairly non-standard disk formats? > Actually I think I just typed in what came into my head - I'm sure some of > the flag calculations must be horribly inefficient. Then again, there is > no easy way to generate them unless you want to rely on the host > cpu having similar flags which you can just copy. I think there's at least one emulator that gets quite a speed boost from doing just that. Unfortunately most ASM Z80 emulators can't cope with the paged SAM memory layout without having to copy up to 32K around when the paging ports are written to (which would probably be too slow if it was frequent, even copying as QWORDs!). They do direct memory accesses on a fixed 64K address range, which bypasses common (but slower) memory read and write routines. I was wondering whether the your current core would benefit from having the register pairs in little endian order so HL can be accessed without shifting and ORing the two 8-bit parts, so I might give that a try at some time - it can conditionally be compiled as big endian for the platforms that need it. I might experiment to see if anything else can be trimmed down, but I think the video generation eats so much (especially when large portions of the screen change frequently) that it's not worth spending too much time on it! Si
