| |
oziphantom
Registered: Oct 2014
Posts: 490 |
SD2IEC fastloader
Does anybody know of a system that fast loads, or a disassembly of a fast loader that SD2IEC supports? |
|
... 60 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Krillnot sure if this helps, but this is an example of what i did Quoting cadaverWorking eload-based game fastloader here: https://github.com/cadaver/c64gameframework Nice to see that my suggestion helped. :) |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Quoting cadaverWorking eload-based game fastloader here: https://github.com/cadaver/c64gameframework
It's tangled quite deep with the rest of the framework (in loader.s), so may not be very usable outside of it.
Very helpful, thank you. |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Quoting soci> Its hard to say until the game is done. Or even started, I'm just at the
> planing and early test stage. I guess an IDE64 with CF is going to be "as" fast
> but as just KERNAL and not fastloader, will it be fast enough?
Depends. Some benchmarks:
https://singularcrew.hu/idedos/perf.php
That is pretty fast ;)
Quoting sociUp to date information is in the user's guide. Section 13 describes KERNAL
calls and memory use:
https://singularcrew.hu/idedos/beta/IDE64_users_guide_beta.pdf
The operating system was written so that it only "trashes" memory locations
which would be trashed the same way on a stock machine as well when accessing a
serial device. The addresses are listed so there's no need to guess what to
back up.
the quality Soci levels of documentation I see.. no if only Tass would let you "pin" addresses and let the rest flow around them ;) |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
I've come up with a better way to support the 1541IIU/EF3/TC the way you support the mini is by making a Ocean 512K cart as they are binary compatible. You just rip out the EEPROM saving and tell them to "press menu and take a snapshot now". While the aforementioned devices do have freezers, on hardware it is "risky". However saving is user instantiated in an end of the level menu, to which if it takes longer to save/load "meh", so it can just use a "save disk", be it a physical disk or an emulated one, using pure KERNAL routines. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
for TC64 and 1541U (and EF of course) just make a regular EF cartridge (WITH saving to flash - remember to use the EAPI however). Both let you save the updated cartridge. regular "freezing" on the other hand will NOT work with an ocean cartridge on either device. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Slight update to the SD2IEC fastloader code I wrote, now there's a generic IEC send reimplementation without any long IRQ pauses. Can also be used outside SD2IEC for fastloader uploading.
There is a short IRQ disable, but it's only to prevent SD2IEC enabling JiffyDOS mode on the last bit of ATN bytes.
Initially I thought SD2IEC is more lax regarding EOI, but it turns out to be the same. The bit send timing itself must be slower on the C64 side when communicating with a real drive.
https://github.com/cadaver/c64gameframework/commit/3397dbc24d01.. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting KrillOkay, didn't get around cleaning it up yet and not sure if this helps, but this is an example of what i did:
; scratch "TEMP"
lda #FLOPPYMW - scratch
ldx #<scratch
ldy #>scratch
jsr $ffbd; SETNAM
lda #$6f; secondary address: command/error channel
sta $b9
lda #$20; LISTEN
jsr sendslow
jsr $f3e6; send secondary address and filename
lda #$3f; UNLISTEN
jsr sendslow
jsr $ee03; clear ATN
[...]
sendslow ora $ba
sta $95
lda $dd00
and #%11001111
ora #%00001000
sta $dd00
- bit $dd00
bpl -
sei
jmp $ed5a; send byte
Meanwhile, it turned out that i forgot the EOI delay (http://unusedino.de/ec64/technical/aay/c64/romeeb3.htm), and it's quite crucial. So "sendslow" becomes:sendslow ora $ba
sta $95
lda $dd00
and #%11001111
ora #%00001000
sta $dd00
- bit $dd00
bpl -
ldx #$b8
- dex
bne -
sei
jmp $ed5a; send byteDFLTO ($9a) for LISTEN and DFLTN ($99) for TALK also don't appear to be set, which i do in a clean version in another codebase: CLEAR_DATA_OUT_CLEAR_CLK_OUT_ASSERT_ATN
: SET_FLAGS_N_DATA_V_CLK
bpl :-
ldx #$b8; delay
: dex ; of
bne :- ; ~1 ms
lda FA
sta DFLTO
ora #SA_LISTEN
sta BSOUR
sei
jsr NOEOI; send byte
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
