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 > CSDb Entries > Release id #152591 : SD2IEC Kernal 1.0
2017-01-08 01:15
jcompton

Registered: Feb 2006
Posts: 17
Release id #152591 : SD2IEC Kernal 1.0

(Moving the discussion of wedge to a forum post)

If feasible, it would be nice to get the Big Three DOS wedge commands:

@ (command channel)
/ (load ,8)
% (load ,8,1)

The browser is a nice option, but the direct route is handy as well if both can be supported.
2017-01-08 07:40
Tom-Cat

Registered: Apr 2003
Posts: 13
Could the fast loader be adapted so it is used for general loading (also read byte, etc. and not just for the first file in the browser)?
2017-01-08 08:37
Claus_2015

Registered: Oct 2012
Posts: 22
I guess it should be easy to fit the wedge in, especially as the actually needed code for the commands should be available in the browser already. So only the parsing would need to be added.

I am not so sure about the general fast loading. Right now, the fastloader detects an sd2iec device during open and then switches to the fastload protocol by sending special m-w and m-e commands. In order to support general byte getting, one would need to maintain sd2iec flags for each opened file. If two files are opened on an sd2iec device, things would get complicated, because as far as I can oversee you cannot really switch between different files and continue loading in the middle of a file. Seems like for these cases, JiffyDOS is the way to go :-).

BTW just to clarify: the fast loading is not limited to the browser, it accelerates the BASIC load command, too.
2017-01-08 14:41
Claus_2015

Registered: Oct 2012
Posts: 22
Update: I checked back with Ingo Korb (the author of the sd2iec firmware) and he agrees that eload is not able to handle multiple files. The code on the sd2iec expects the transmission to be initialized with secondary address 0, effectively only allowing a single file to be opened at the same time.

So I do not think that I will extend the kernal to accelerate more than normal file loading, as this would require a change to a different loader.
2017-01-08 15:54
TheRyk

Registered: Mar 2009
Posts: 375
reasonably quick fast loader plus easy to handle file browser. quite nice to have!

of course, my old combo "5" (JiffyDos KERNAL on my EF3) "↑FB*" (File Browser) + Return somehow is fixed in my brain (and not much harder than "6" (your KERNAL) "Shift+Run/Stop") but with this new solution it ain't a problem anymore to launch file browser without resetting SD2IEC - no matter whether FB is on currently mounted image or not.

Suggestion: Implement F-Keys for stuff like LOAD, DIR, LIST, RUN
2017-01-08 18:46
Claus_2015

Registered: Oct 2012
Posts: 22
Just for completeness: Enthusi (obviously :-)) suggested to squeeze TurboTape in (which looks feasible). Is there anyone else who thinks that is a good idea? I am a bit in doubt, as an SD2IEC typically blocks the tape port, but it might make sense if people want to use one or the other without changing the kernal. Opinions?
2017-01-08 20:05
enthusi

Registered: May 2004
Posts: 635
Blocking the cassport for a device to transfer data through the IEC port is a bad idea anyway :-)
2017-01-09 16:01
jcompton

Registered: Feb 2006
Posts: 17
It's your project, but my feeling is if the premise is to be "a very useful kernel specifically for SD2IEC users", the fact that the vast majority of SD2IEC users have the tape port blocked means that any leftover space would be better used on optimizing outcomes for SD2IEC-specific use, and/or very general-purpose stuff like F-keys, rather than accounting for the narrower audience of people using external SD2IEC power, or using SD2IEC under emulation.
2017-01-10 16:37
Claus_2015

Registered: Oct 2012
Posts: 22
I originally wrote this kernal to make my life easier when creating/testing cartridges (where you need mass storage, but do not have the module slot free). I meanwhile feel the need for a memory monitor in these cases, so I will investigate if I can fit a simple one in. Holding Run/Stop while resetting would then skip module start and directly enter the monitor.
2017-01-10 17:32
Angel of Death

Registered: Apr 2008
Posts: 167
"fit a simple one in"
And a fast-loader and a file-browser.
Where did you find all that free space?
I made a Kernal once and without serial comm and tape functionality I only managed to squeeze SJ-load for the SD2IEC (no drive-code) and a few F-key commands in.
(anyway you'd publish the source, maybe? ;) )
2017-01-10 20:00
Claus_2015

Registered: Oct 2012
Posts: 22
:-) I decided on eload, because it is a pretty compact fastloader. The browser is the largest part with roughly 1.5 kb. Overall I was able to find 2565 bytes and I really used every available tiny segment (some are only 4 bytes) without wasting a single byte. When it is all done I am happy to share the source, although it is obviously a tad convoluted...
 
... 21 posts hidden. Click here to view all posts....
 
Previous - 1 | 2 | 3 | 4 - 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
Mason/Unicess
Sokrates
Menace/Spaceballs
hedning/G★P
Matt
Guests online: 79
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.7)
3 The Shores of Reflec..  (9.6)
4 Coma Light 13  (9.6)
5 Lunatico  (9.6)
6 Comaland 100%  (9.6)
7 Incoherent Nightmare  (9.5)
8 Wonderland XII  (9.5)
9 Comaland  (9.5)
10 Wonderland XIII  (9.5)
Top onefile Demos
1 Dawnfall V1.1  (9.5)
2 SidRok  (9.5)
3 Daah, Those Acid Pil..  (9.5)
4 Treu Love [reu]  (9.4)
5 Tunnel Vision  (9.3)
6 Dawnfall  (9.3)
7 One-Der  (9.2)
8 Hardware Accelerated..  (9.2)
9 Globe 2016 [reu]  (9.2)
10 Safe VSP  (9.1)
Top Groups
1 Booze Design  (9.4)
2 Oxyron  (9.4)
3 Censor Design  (9.3)
4 Crest  (9.3)
5 Camelot  (9.2)
Top Organizers
1 Burglar  (9.9)
2 Wotnau  (9.7)
3 Sixx  (9.7)
4 MWS  (9.7)
5 Frantic  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2017
Page generated in: 0.255 sec.