diff --git a/c64/aliases/,aliases_ram_lowmem.s b/c64/aliases/,aliases_ram_lowmem.s index e5e8e393..814aff63 100644 --- a/c64/aliases/,aliases_ram_lowmem.s +++ b/c64/aliases/,aliases_ram_lowmem.s @@ -141,7 +141,7 @@ .label CAS1 = $C0 // tape motor interlock .label STAL = $C1 // $C1-$C2 LOAD/SAVE start address .label MEMUSS = $C3 // $C3-$C4 temporary address for tape LOAD/SAVE - .label LSTX = $C5 // last keyy matrix position [!] our usage probably differs in details + .label LSTX = $C5 // last key matrix position [!] our usage probably differs in details .label NDX = $C6 // number of chars in keyboard buffer .label RVS = $C7 // flag, whether to print reversed characters .label INDX = $C8 // end of logical line (column, 0-79) @@ -150,7 +150,7 @@ .label BLNSW = $CC // cursor blink disable flag .label BLNCT = $CD // cursor blink countdown .label GDBLN = $CE // cursor saved character - .label BLNON = $CF // cursor visibilityy flag + .label BLNON = $CF // cursor visibility flag .label CRSW = $D0 // whether to input from screen or keyboard .label PNT = $D1 // $D1-$D2 pointer to the current screen line .label PNTR = $D3 // current screen X position diff --git a/c64/kernal/iec_fast/jiffydos_bittable.s b/c64/kernal/iec_fast/jiffydos_bittable.s index b8b32367..94e89a39 100644 --- a/c64/kernal/iec_fast/jiffydos_bittable.s +++ b/c64/kernal/iec_fast/jiffydos_bittable.s @@ -7,7 +7,7 @@ // Similar tables are probably used by nearly all the disk turbo loaders, // either on the C64 or drive side, soometimes generated in RAM on the fly; -// example disk turbo presented below has a veryy similar table - but the +// example disk turbo presented below has a very similar table - but the // values are in reversed order: // - https://www.pagetable.com/?p=568 diff --git a/c64/kernal/iec_fast/load_jiffydos.s b/c64/kernal/iec_fast/load_jiffydos.s index 126187c4..463a276a 100644 --- a/c64/kernal/iec_fast/load_jiffydos.s +++ b/c64/kernal/iec_fast/load_jiffydos.s @@ -11,7 +11,7 @@ // see description at https://sites.google.com/site/h2obsession/CBM/C128/JiffySoft128 // // For simplicity and some space savings, our routine does not check the RUN/STOP key at all; -// the protocol is fast enough (especiallyy with modern flash mediums) that probably nobody +// the protocol is fast enough (especially with modern flash mediums) that probably nobody // will want to terminate the loading. diff --git a/c64/kernal/iostack/load_save_common.s b/c64/kernal/iostack/load_save_common.s index af5e1ad8..8f43b96b 100644 --- a/c64/kernal/iostack/load_save_common.s +++ b/c64/kernal/iostack/load_save_common.s @@ -220,7 +220,7 @@ lvs_display_saving: lda (FNADDR), y jsr JCHROUT iny - bne !- // jump alwayys + bne !- // jump always !: rts diff --git a/doc/Protocol-JiffyDOS.md b/doc/Protocol-JiffyDOS.md index 95388eeb..f3773ad7 100644 --- a/doc/Protocol-JiffyDOS.md +++ b/doc/Protocol-JiffyDOS.md @@ -20,7 +20,7 @@ For legal reasons, no disassembling of the JiffyDOS ROMs was performed (only IEC When sending/receiving a byte, the JiffyDOS protocol timing is much more strict than the standard IEC. It is not enough to mask the interrupts - one has to make sure nothing will steal the CPU cycles. There are two ways to achieve this: - disable the screen completely for the duration of transmission; since VIC-II checks the bit in SCROLY register once per frame only, the code has to wait till the beginning of the next frame -- disable the sprites for the duration of transmission and synchronize with VIC-II RASTER/SCROLY registers to avoid badlines. Current implementation simply avoids transmission two lines before the badline; I suspect it can be reduced to one line, but it would need even more careful timing and would definitely mean inlining some subroutines - probably not worth the effort and increased code size, especially that 1541 JiffyDOS is not too fast sending bytes nevertheless +- disable the sprites for the duration of transmission and synchronize with VIC-II RASTER/SCROLY registers to avoid badlines. Current implementation simply avoids transmission two lines before the badline; I suspect it can be reduced to one line, but it would need even more careful timing and would definitely mean inlining some subroutines - probably not worth the effort and increased code size Timing details are omitted by purpose - they are already described in [2], besides most of the time it was determined by observing VICE IEC logs and (for example) adding NOPs when necessary. The protocool is not cycle-exact, so our implementation probably behaves slightly differently than the original one. @@ -53,7 +53,6 @@ Encoding the low nibble is done via lookup table, reverse engineered by observin Afterwards the controller either pulls the CLK quickly, or signals EOI by delaying this action. In our implementation the acceptable timing was adjusted by experimentation (pre-existing delay subroutine was used to reduce code size, also note that NTSC machines have slightly higher CPU frequency) - but it's important not to wait too long, 1541 JiffyDOS ROM can handle it, but SD2IEC implementation can not! - ## Receiving a byte Device ready to send a byte signals it by releasing CLK, bus controller performs the 'badline synchronization' (note: if screen blanking method was choosen, artificial delay has to be inserted, otherwise communication with 1541 fails; also note the slightly faster CPU frequency on NTSC machines!). Controller releases the DATA line to signal it is ready to accept bits.