Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums


Forums > C64 Coding > SD2IEC fastloader
2019-02-19 15:51
oziphantom

Registered: Oct 2014
Posts: 274
SD2IEC fastloader

Does anybody know of a system that fast loads, or a disassembly of a fast loader that SD2IEC supports?
 
... 56 posts hidden. Click here to view all posts....
 
2019-02-27 11:02
cadaver

Registered: Feb 2002
Posts: 1106
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
2019-02-27 12:20
Krill

Registered: Apr 2002
Posts: 1159
Quoting cadaver
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.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. :)
2019-02-27 21:27
cadaver

Registered: Feb 2002
Posts: 1106
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.
2019-02-28 00:50
soci

Registered: Sep 2003
Posts: 424
> 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.
2019-02-28 05:22
Krill

Registered: Apr 2002
Posts: 1159
Quoting Krill
not sure if this helps, but this is an example of what i did
Quoting cadaver
Working eload-based game fastloader here: https://github.com/cadaver/c64gameframework
Nice to see that my suggestion helped. :)
2019-02-28 05:33
oziphantom

Registered: Oct 2014
Posts: 274
Quoting cadaver
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.


Very helpful, thank you.
2019-02-28 06:02
oziphantom

Registered: Oct 2014
Posts: 274
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 soci
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.

the quality Soci levels of documentation I see.. no if only Tass would let you "pin" addresses and let the rest flow around them ;)
2019-02-28 06:06
oziphantom

Registered: Oct 2014
Posts: 274
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.
2019-02-28 10:52
Groepaz

Registered: Dec 2001
Posts: 9090
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.
2019-03-02 14:51
cadaver

Registered: Feb 2002
Posts: 1106
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..
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
bugjam
Alakran_64
razorback/G★P
WVL/Xenon
Dymo/G★P
Snabel
Sentinel/Excess
kms
hedning/G★P
redcrab/G★P
AJOT
Guests online: 43
Top Demos
1 Uncensored  (9.7)
2 Unboxed  (9.7)
3 Edge of Disgrace  (9.7)
4 Coma Light 13  (9.6)
5 Comaland 100%  (9.6)
6 Lunatico  (9.6)
7 The Shores of Reflec..  (9.6)
8 X Marks the Spot  (9.5)
9 Old Men in Used Cars  (9.5)
10 C=Bit 18  (9.5)
Top onefile Demos
1 Bad Boy  (9.7)
2 Smile to the Sky  (9.6)
3 Daah, Those Acid Pil..  (9.5)
4 Dawnfall V1.1  (9.4)
5 FMX Music Demo  (9.4)
6 Rewind  (9.4)
7 Crystal Gazer  (9.4)
8 Official X2018 Report  (9.4)
9 Arok 20 Invitation  (9.4)
10 Pandemoniac Part 2 o..  (9.4)
Top Groups
1 PriorArt  (9.7)
2 Oxyron  (9.5)
3 Booze Design  (9.4)
4 Censor Design  (9.3)
5 Performers  (9.3)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Horizon  (9.8)
3 The Mind Slayer  (9.8)
4 The Shadow  (9.7)
5 Stormbringer  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2019
Page generated in: 0.066 sec.