| |
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....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
at this point just use pi1541 :) |
| |
hedning
Registered: Mar 2009
Posts: 4732 |
Quote: at this point just use pi1541 :)
+1
The pi1541 is a lot better, cheaper and more accurate than anything you could do to boost the sd2iec. We should not adapt stuff to the sd2iec. |
| |
Mr.Ammo
Account closed
Registered: Oct 2002
Posts: 228 |
Quoting oziphantom[...] I assumed [...]
Do not to assume.
Listen to Krill. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Don't see harm in adapting stuff as long as it does detection properly and continues to run on proper drives.
Have to take care when testing, for example I just found out that SD2IEC doesn't give a shit whether you send the EOI signal for filenames or commands, as long as you Unlisten afterward. A real 1541 does :) |
| |
hedning
Registered: Mar 2009
Posts: 4732 |
Quote: Don't see harm in adapting stuff as long as it does detection properly and continues to run on proper drives.
Have to take care when testing, for example I just found out that SD2IEC doesn't give a shit whether you send the EOI signal for filenames or commands, as long as you Unlisten afterward. A real 1541 does :)
That is the way to go if you want to support it, of course. But sd2iec-only adaptations would be devastating and sad. |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
well the trick is an sd2iec "might" just be able to pull it off good enough to not be a massive pain. Where a physical disk won't be able to. However a 1581 might be able to, it will still be a lot slower but its disk capacity is high enough. A 1581 on a 128 is probably in the realms of livable. However supporting a 1581 on a 128 is probably worse than supporting a sd2iec ;) |
| |
soci
Registered: Sep 2003
Posts: 480 |
Would it be difficult to have a KERNAL fallback without nuking the vector tables? Making the loader serial bus specific does not help when trying to run stuff from an IDE64. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Eload easily needs the most code due to the init needed for each file. That or any sector buffer could go over the OS-sensitive areas.
It's kind of a lot work to support everything, but when you don't leave anything up to 3rd party later fixes, the initial user reception should be better.
(if your game is huge, I can understand not having 1541 drivecode, and the extra work for disk swap screens) |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
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? 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.
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? |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
You 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.
There are also the IDE64-specific block read/write calls, see http://www.ide64.org/guide.html |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
