Post by jmpff3d on Dec 7, 2018 1:15:13 GMT
I was checking out the old Trinity game from Infocom. Gameplay felt -really- slow, and then I noticed the thing never activates 2 MHz mode. .......... That is a big WTF, a VDC "C-128 Only" game stuck to only 1 MHz ?? .. This had to be fixed. So yeah, I fixed it and uploaded "my version" to CSDb ( csdb.dk/release/?id=172209 ).
This game seems to be an autoboot/bootsector game which rides sequential serial load action from the 128's kernal. Some say only CP/M and few other softwares engaged in this kind of loading. I suppose commercial stuff rarely "went there" because it is a slow ride utilizing a sector interleave of "1", as noted in the following thread : c-128.freeforums.net/thread/130/c128-autoboot
... and here is how the fix was accomplished :
I am at a total loss as to why Infocom didn't set 2 MHz in the first place.
All they needed to do was dial-in the following THREE bytes, in the autoboot block/sector, right before they start fiddling with the MMU :
20 B3 77 JSR $77B3
That's it .. that's the bare minimum, nothing more to it.
Since the game "seems to work" with fast mode enabled, I classify this as gross negligence on infocom's part unless someone has a plausible theory (or bloody hardcore factoid) as to why they did not flip the 2MHz bit.
I spent some time checking if the game had any VIC-II (40 column) angles, it does not seem to have any. Sooo.. shouting at the top of my lungs to infocom 30+ yrs in downtime ----> What in blazes is the point of a 100%-VDC 80-column game if you're NOT going to enable fast mode !?
This game seems to be an autoboot/bootsector game which rides sequential serial load action from the 128's kernal. Some say only CP/M and few other softwares engaged in this kind of loading. I suppose commercial stuff rarely "went there" because it is a slow ride utilizing a sector interleave of "1", as noted in the following thread : c-128.freeforums.net/thread/130/c128-autoboot
... and here is how the fix was accomplished :
Autoboot sector at start of disk image:
* = 0000
0000 43 42 4D 'CBM' string
00 0C 00
02 00 00
0009 A5 D7 LDA $D7
000B C9 80 CMP #$80
000D F0 03 BEQ $0012
000F 20 5F FF JSR $FF5F
0012 20 7D FF JSR $FF7D ; jprimm .. jumps to primm routine and prints the bytes following this instruction until "00"
<text data here for PRIMM> ; 60 or so bytes of text for primm to print to VIC-II screen via screen editor codes
00 ; once "00" byte is seen by primm kernal routine, resume instructions from this point forward
0072 A5 A1 LDA $A1 ; load jiffyclock byte to set up brief delay via the IRQ-driven jiffyclock
0074 C5 A1 CMP $A1 ; compare byte in A register with zp memory location assigned to relevant jiffyclock byte
0076 F0 FC BEQ $0074 ; when the byte in A reg. and byte in memory location no longer match, move on
0078 20 B3 77 JSR $77B3 ; call the FAST MODE routine in kernal
007B A9 05 LDA #$05 ; configure mmu (see mmu bitswitch guide)
007D 8D 06 D5 STA $D506 ; mmu
0080 A9 4E LDA #$4E ; more mmu
0082 8D 00 FF STA $FF00 ; more mmu
0085 4C 00 0C JMP $0C00 ; exit
I am at a total loss as to why Infocom didn't set 2 MHz in the first place.
All they needed to do was dial-in the following THREE bytes, in the autoboot block/sector, right before they start fiddling with the MMU :
20 B3 77 JSR $77B3
That's it .. that's the bare minimum, nothing more to it.
Since the game "seems to work" with fast mode enabled, I classify this as gross negligence on infocom's part unless someone has a plausible theory (or bloody hardcore factoid) as to why they did not flip the 2MHz bit.
I spent some time checking if the game had any VIC-II (40 column) angles, it does not seem to have any. Sooo.. shouting at the top of my lungs to infocom 30+ yrs in downtime ----> What in blazes is the point of a 100%-VDC 80-column game if you're NOT going to enable fast mode !?
