mirror of
https://github.com/cc65/cc65.git
synced 2024-12-29 13:31:59 +00:00
04cc463452
Please refer to https://github.com/cc65/cc65/pull/532 for background info.
I wrote in https://sourceforge.net/p/cc65/mailman/message/35873183/
===
cputs() wraps to the next line if the strings is too long to fit in the current line. I don't know if it's worth the effort to allow cpeeks() to continue reading from the next line. I'd like to discuss this aspect with the actual implementers.
===
This is still as unclear today as it was when I wrote the above. Therefore this change just doesn't add cpeeks() at all.
Since f8c6c58373 the Apple II CONIO implementation doesn't "need" revers() anymore - meaning that (nearly) every possible value can be placed in VRAM with a straight cputc() (without the need for a previous revers(1)).
The implementation of cpeekc() leverages that cputc() ability by always returning the value that can be fed into cputc() without a previous revers(1). Accordingly, cpeekrevers() always returns 0.
So after the sequence revers(1); cputc(x); a cpeekc() will return a value different from x! However, I don't see this behavior braking the cpeekc() contract. I see the cpeekc() contract being defined by the sequence textcolor(cpeekcolor()); revers(cpeekrevers()); cputc(cpeekc()); placing the very same value in VRAM that there was before. And that contract is fulfilled.
29 lines
727 B
ArmAsm
29 lines
727 B
ArmAsm
;
|
|
; 2020-07-12, Oliver Schmidt
|
|
;
|
|
; char cpeekc (void);
|
|
;
|
|
|
|
.export _cpeekc
|
|
|
|
.include "apple2.inc"
|
|
|
|
_cpeekc:
|
|
ldy CH
|
|
.ifdef __APPLE2ENH__
|
|
bit RD80VID ; In 80 column mode?
|
|
bpl peek ; No, just go ahead
|
|
tya
|
|
lsr ; Div by 2
|
|
tay
|
|
bcs peek ; Odd cols are in main memory
|
|
bit HISCR ; Assume SET80COL
|
|
.endif
|
|
peek: lda (BASL),Y ; Get character
|
|
.ifdef __APPLE2ENH__
|
|
bit LOWSCR ; Doesn't hurt in 40 column mode
|
|
.endif
|
|
eor #$80 ; Invert high bit
|
|
ldx #$00
|
|
rts
|