2021-09-04, 07:02 PM
Hi guys, I'm sorry for this very late answer, I simply forgot to subscribe to this thread.
Regarding SD2IEC problem - I don't know where the problem is. The assembled D64 image uses original 1541 disk driver, which SD2IEC should be able to detect and emulate the speeder. I'm using Ultimate 1541-II myself and this works fine.
I should check if Jiffydos may be the issue here.
In any case, I think I will add a "DOS" disk driver for GEOS that uses only B-R/B-W commands and Kernal I/O functions.
The drawing speedup is noticeable: most of the savings (both memory and CPU cycles) comes from the benefit of having REP, but also due to STEP automatically adjusting the address of the next byte. GEOS draws on two screens at once, so once we have the starting point and STEP we save a lot on not adjusting two 16-bit pointers on zero page.
@abbruzze One thing that I noticed is that in Kernal64 code both display list program and port data are fetched from the same "mem" pointer. This "mem" is updated according to currentBank right after a write to control register $31. But it doesn't work this way on the real hardware because once I setup display list in one bank I can change banks: read and write from C64 side all over the whole BeamRacer memory without stopping DL.
Regarding SD2IEC problem - I don't know where the problem is. The assembled D64 image uses original 1541 disk driver, which SD2IEC should be able to detect and emulate the speeder. I'm using Ultimate 1541-II myself and this works fine.
I should check if Jiffydos may be the issue here.
In any case, I think I will add a "DOS" disk driver for GEOS that uses only B-R/B-W commands and Kernal I/O functions.
The drawing speedup is noticeable: most of the savings (both memory and CPU cycles) comes from the benefit of having REP, but also due to STEP automatically adjusting the address of the next byte. GEOS draws on two screens at once, so once we have the starting point and STEP we save a lot on not adjusting two 16-bit pointers on zero page.
@abbruzze One thing that I noticed is that in Kernal64 code both display list program and port data are fetched from the same "mem" pointer. This "mem" is updated according to currentBank right after a write to control register $31. But it doesn't work this way on the real hardware because once I setup display list in one bank I can change banks: read and write from C64 side all over the whole BeamRacer memory without stopping DL.