| |
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....
|
| |
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 |
| |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
