| |
oziphantom
Registered: Oct 2014
Posts: 478 |
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....
|
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Claus_2015: thanks for the hint, eload is .. interesting :) Practically you setup loading first with the stock routines, then upload the short "drivecode" and resume with a fast protocol.
It's a 2bit timed protocol, so you can't have sprites and IRQs will be delayed while it waits for badline clearance, but screen can be on, so would be OK for typical games. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
This will be for a release. The game is "Cart only" basically. However there are people who have what I call "Welded devices" attached to their machines, and they are welded in. Since the game is Gmod2, it won't work on anything but hardware or VICE. For the Mini one can just make it a Ocean 512K cart and pop up a screen that says "take snapshot now to save". So that is those bases covered(Hardware + Emulator + Mini) This however still leaves the welded and the people who can't afford a cart edition in the lurch. To which I take that sd2iec are somewhat ubiquitous these days particularly with the more casual user, 1541uII is for the hardcore user. But I feel that
1541IIu+ hundreds (probably has reach over a 1000 though)
sd2iec thousands
and then most 1541II users probably started with a sd2iec and then realized it didn't give them enough of what they want and then upgraded. So with this I might be able to make a "good enough" experience that uses the SD2IEC. If it was to be done on a 1541 physical disk you have the following cases..
Bit of game...
Please insert Disk 3 Side A
...seek
...load
Please insert Disk 2 Side B
...seek
...load
Bit more game...
Please insert Disk 1 Side A
If the game gets a 128 native version, then what would give me an extra "80K" over a C64 version, and given a 1571 doubled sided disk it would drop the disk flipping down to half, and I could load with burst.. but lots of work very little gain.
SD2IEC I can put all the files in a flat directory so I can just grab any file I want at any point, with a fast loader it shouldn't take too long, to fetch a bitmap portrait here, some dialog text there, battle animation here, level script there etc It will still pause and stutter a bit, but might be "livable"
If not the "can't afford a cart" people will be in the lurch and I could use the REU capabilities of the 1541UII and TC to make up for the lack of cart. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
Quoting cadaverClaus_2015: thanks for the hint, eload is .. interesting :) Practically you setup loading first with the stock routines, then upload the short "drivecode" and resume with a fast protocol.
It's a 2bit timed protocol, so you can't have sprites and IRQs will be delayed while it waits for badline clearance, but screen can be on, so would be OK for typical games.
Typical games have sprites on the screen though. If I have sprites I could probably turn them off while loading, but I feel my game is unique in this aspect.
However eload does look interesting thanks for the link. |
| |
Knight Rider
Registered: Mar 2005
Posts: 114 |
Please remember that the Sam's Journey fastloader is only supported by sd2iec v1.0.0. Some SD2IECs have an other firmware and can't be upgraded. Example SDRIVE1564 that has sd2iec v0.10.3 and cannot be upgraded. |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
oziphantom: You can do a Y-range check and use the timed protocol only while outside the sprite area. Slower, but at least doesn't crash or force you to hide sprites. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting oziphantomand I could load with burst.. but lots of work very little gain. When it comes to burst, indeed. I've recently added it to my loader, and it's not faster at all than a well-optimised bit-banging protocol.
But where do you get all the content to fill 5-6 disk sides? How much space do you reckon would everything take when well-compressed? |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Knight RiderPlease remember that the Sam's Journey fastloader is only supported by sd2iec v1.0.0. Some SD2IECs have an other firmware and can't be upgraded. Example SDRIVE1564 that has sd2iec v0.10.3 and cannot be upgraded. Really, those crappy non-upgradeable devices should go die in a fire. There's a limit to catering to emulators. Explicit SD2IEC support is already questionable, with it not being a drive replacement but a mass storage device. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
Quoting KrillQuoting oziphantomand I could load with burst.. but lots of work very little gain. When it comes to burst, indeed. I've recently added it to my loader, and it's not faster at all than a well-optimised bit-banging protocol.
But where do you get all the content to fill 5-6 disk sides? How much space do you reckon would everything take when well-compressed?
I think Burst while not faster than 2bit in a tight coupled loop,if I'm pulling in a byte around other things, such as irqs, sprites, game logic, having 8 bits being transferred without a CPU having to be involved will make it a lot easier. As I can't miss the byte, and it will wait for me without needing to be sent again.
However does your code use Burst + 2Bit bang, because that would get you faster again right, as the Burst byte won't occupy CPU time while you transfer the 2bits and hence be almost for "free"?
the 512K cart will already be compressed. It will have some code uncompressed to do the initial boot etc, but all the data will be compressed. |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
One note after a shot at implementing eload: doing the setup for file load using IEC protocol will be murder for your interrupts, if you use Kernal (and it takes several frames.) However, as the device is known at this point, you could take a happycase approach, and implement your own simplified IEC send byte routine that can coexist with your interrupts. Also has the advantage that you can clobber whatever memory you like. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting cadaverOne note after a shot at implementing eload: doing the setup for file load using IEC protocol will be murder for your interrupts, if you use Kernal (and it takes several frames.) However, as the device is known at this point, you could take a happycase approach, and implement your own simplified IEC send byte routine that can coexist with your interrupts. Also has the advantage that you can clobber whatever memory you like. I did some research into that for Thundax's yet-to-be-released game which premiered at X 2018. He required an IRQ loader as well as an IRQ saver, both not resident in the drive, so also uploading the code using KERNAL had to be IRQ-friendly. I don't have the code here at the moment, and it needs some clean-up, but i'll post the gist of it soonish. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
