cx16: fix macptr() signature and use it in diskio.f_read() for big increase in load speed

This commit is contained in:
Irmen de Jong 2022-06-02 00:37:18 +02:00
parent 10b5fb5d72
commit c7eafd7c79
4 changed files with 39 additions and 3 deletions

View File

@ -363,7 +363,7 @@ romsub $fed5 = console_set_paging_message(uword msgptr @R0) clobbers(A,X,Y)
romsub $fecf = entropy_get() -> ubyte @A, ubyte @X, ubyte @Y
romsub $fecc = monitor() clobbers(A,X,Y)
romsub $ff44 = macptr() clobbers(A,X,Y)
romsub $ff44 = macptr(ubyte length @A, uword buffer @XY) clobbers(A) -> ubyte @Pc, uword @XY
romsub $ff47 = enter_basic(ubyte cold_or_warm @Pc) clobbers(A,X,Y)
romsub $ff4d = clock_set_date_time(uword yearmonth @R0, uword dayhours @R1, uword minsecs @R2, ubyte jiffies @R3) clobbers(A, X, Y)
romsub $ff50 = clock_get_date_time() clobbers(A, X, Y) -> uword @R0, uword @R1, uword @R2, ubyte @R3 ; result registers see clock_set_date_time()

View File

@ -239,6 +239,29 @@ close_end:
}
void c64.CHKIN(11) ; use #11 as input channel again
if sys.target==16 {
; commander X16 supports fast block-read via macptr() kernal call
uword size
while num_bytes {
size = 255
if num_bytes<size
size = num_bytes
size = cx16.macptr(lsb(size), bufferpointer)
if_cs
goto byte_read_loop ; macptr block read not supported, do fallback loop
list_blocks += size
bufferpointer += size
num_bytes -= size
if c64.READST() & $40 {
f_close() ; end of file, close it
break
}
}
return list_blocks ; number of bytes read
}
byte_read_loop:
%asm {{
lda bufferpointer
sta m_in_buffer+1

View File

@ -139,6 +139,8 @@ Provides several routines that deal with disk drive I/O, such as:
- load and save data from and to the disk
- delete and rename files on the disk
On the Commander X16 it tries to use that machine's fast kernal loading routines if possible.
string
------

View File

@ -3,8 +3,19 @@ TODO
For next release
^^^^^^^^^^^^^^^^
- cx16 diskio: use cx16 MACPTR() in f_read() to load stuff faster? (see its use in X16edit to fast load blocks)
note that it might fail on non sdcard files so have to make graceful degradation
- why is this code so much larger:
uword xx
for xx in 0 to size-1 {
gfx2.next_pixel(bitmapbuf[xx])
}
than this loop:
uword srcptr = bitmapbuf
repeat size {
gfx2.next_pixel(@(srcptr))
srcptr++
}
any difference between 6502 codegen and vm codegen?
- pipe operator: (targets other than 'Virtual'): allow non-unary function calls in the pipe that specify the other argument(s) in the calls. Already working for VM target.
- add McCarthy evaluation to shortcircuit and/or expressions. First do ifs by splitting them up? Then do expressions that compute a value?
- Inliner: also inline function call expressions, and remove it from the StatementOptimizer