| |
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? |
|
... 57 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting cadaverYou can test IDE64 in VICE. It works almost like "true drive emu" off, ie. CHRIN is fast, and IRQs get delayed only about a line, if at all.l Indeed, using my loader's KERNAL fallback with IDE64 didn't show any glitches with the border-opening test application last time i checked. Of course, same for 1581, but that's supported natively. :) |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Working 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. |
| |
soci
Registered: Sep 2003
Posts: 480 |
> 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
> It connects to the expansion port right?
> Does it have any fancy DMA injection methods, or can it map file data into
> DEXX/DFXX GEORAM style? Remember this is being compared to an instant bank of
> a cartridge.
No, it's not instant, does not do any DMA and it also does not directly map in
storage like rom, flash or ram cartridges.
Data is accessed using KERNAL calls and the operating system moves data around
or provides byte-by-byte access to files. If it's a CF card, hard disk, or some
sort of network drive it does not matter.
> Again this is something the 128 would make trivial, as I could just switch to
> bank 1,move the ZP elsewhere and then I can just keep the ZP and lower
> variables untouched. Switch back when you want to do loading, then return back
> to lower RAM being bank 1. Does IDE64 support 128 native?
The hardware kicks it into C64 mode before it even starts, so no.
> There are also the IDE64-specific block read/write calls, see
> http://www.ide64.org/guide.html
That's a bit old. For example if you handle directory paths like this that's
IDE64 specific. Instead paths should be written using the CMD syntax so that
there's some compatibility with CMD devices.
Up 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. |
| |
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 |
