| Posted By
bubis
on 2017-05-05
07:17:13
|  Trackloader For The Masses, Not The Classes
Coming soon! 
|
|
Posted By
Luca
on 2017-05-04
12:15:22
 | Re: Trackloader For The Masses Not The Classes
Oooh finally! Krill's trackloader is a cool one, but OMG enough playing with weird stuff like cygwin, I'd given it a try just to see how the magic happens and in the end it worked, but a friendly newcomer would become a sure shot for anybody, and maybe an easy manageable trackloader will be the skeleton where to build around a Crackers' Demo 6, am I wrong? 
|
|
Posted By
siz
on 2017-05-04
12:52:00
| Re: Trackloader For The Masses Not The Classes
Personally I don't like the idea of trackloaders. Nowadays as I'm getting older I don't want to use real floppy disks and we have very few alternatives for them:
- we have SD2IEC which supports some loaders (C64 ones but I managed to implement one of the IRq loader protocols on plus/4) but best usable for file based stuff
- we can use UK1541 (with some customization because the original one does not fit the plus/4 mechanically) which is a fair enough implementation for D64 images and supports most of the loaders (except the ones with custom DOS but I'v never seen one for plus/4) and cannot be used with a C16 and a C116 as it's connected to user port
- I'm not sure about 1541U2+ . Just received mine today so I I have to try if it's really usable with the plus/4. In theory it has standalone but you may never know.
|
|
Posted By
Csabo
on 2017-05-04
12:54:42
| Re: Trackloader For The Masses Not The Classes
I'm partially there with you, siz, as my main thing is always compatibility. However, it's good to have options though. Loaders in general is one of the things that should not be reinvented all the time, so easily reusable code is always welcome.
|
|
Posted By
bubis
on 2017-05-04
13:11:07
| Re: Trackloader For The Masses Not The Classes
@siz:
My intent is to provide you with a state-of-the-art trackloader that is easy to use.
The code is here: https://github.com/dotscha/bitfire
Create your own fork and add support for whatever hardware you want. Let me know when done, and we can include it in future releases if you wish.
|
|
Posted By
siz
on 2017-05-04
13:07:59
| Re: Trackloader For The Masses Not The Classes
Of course I understand why a demo coder wants a trackloader as slow loading times could kill the flow of the demo but still...
|
|
Posted By
bubis
on 2017-05-04
21:59:03
| Re: Trackloader For The Masses Not The Classes
You can download bitfire_plus4_20170505.zip here: https://github.com/dotscha/bitfire/releases/tag/2017.05.05
Bitfire+4 2017.05.05:
- Resident part: $200-$3ff
- Zero page: $04-$09
- 2bit ATN double clock receiver
- load raw, load+decomp, decomp routines
- Basic irq handler for music, frame counter, partial SID detection
- Win32 and Plus/4 binaries, ACME cross-assembler, include files and macros
- Simple code example and Win32 build script
|
|
Posted By
Luca
on 2017-05-05
02:54:13
| Re: Trackloader For The Masses Not The Classes
I'm gonna add it into the tool page once at home.
Absolutely stunning piece of code bubis! This big boss manages everything by yourself, and packs in level doynamite format too, making it the best choice for games and diskmags. It recognizes 16 different disksides too, and further non-trackloadable files can be further added due to the BAM .lz protection. I'll check how it works as soon as possibile...
|
|
Posted By
bubis
on 2017-05-05
03:13:14
| Re: Trackloader For The Masses Not The Classes
Remember, this is a loader by Bitbreaker/Oxyron. BSZ and myself just ported it to Plus/4. Also note that the initial version of this loader was mostly based on Krill's loader.
|
|
Posted By
gerliczer
on 2017-05-05
03:14:24
| Re: Trackloader For The Masses Not The Classes
Please don't take this as any kind of complaint, or trying to pick a fight or even depreciating your work, but why didn't you port Dreamload instead? It has built-in support in SD2IEC, so cheap and easy to use (on our machines, too) modern mass storage compatibility with IRQ-loader would've been solved instantly. I do understand that bitfire provides better performance and probably easier to use, but it has narrower compatibility, AFAIK.
|
|
Posted By
Luca
on 2017-05-05
04:05:13
| Re: Trackloader For The Masses Not The Classes
Guys, your neverending love for the SD2IEC et similia produced questions that would need further questions to answer to  Example: Mad, would you please tell us why Rocket Science does not work on SD2IEC, just to say one?
|
|
Posted By
bubis
on 2017-05-05
05:39:39
| Re: Trackloader For The Masses Not The Classes
I don't care about SD2IEC compability, because that's not part of the typical demo config. If that is slower than a 1541 I care even less. I care about compatibility, but that is 1541/1551 compability. I considered only two options: Bitfire or Spindle2.0. The reason why I picked Bitfire is that a port of Bitfire is probably faster on 1541 than a port of Spindle2.0. So, I care about 1541. Otherwise I would have picked Spindle2.0, because that would likely be much faster on 1551 than the other. It was very tempting to do a 1551-only loader port, so you are lucky that I care about compatibility at all and not just performance.
It can still happen that my next demo will be 1551-only.
Yes, you are complaining even if you are saying you are not. Why don't you rather create a fork of Bitfire+4 on GitHub and add support for SD2IEC? Put your time and effort where your mouth is!
|
|
Posted By
gerliczer
on 2017-05-05
06:11:27
| Re: Trackloader For The Masses Not The Classes
Thank you for answering my question. Requesting permission to hang myself.
|
|
Posted By
bubis
on 2017-05-05
18:51:55
| Re: Trackloader For The Masses Not The Asses
This will be remembered as a black day in scene histoday, a terrible day!
A state-of-the-are trackloader just landed on Plus4World and Gerliczer has suicidal thoughts because it doesn't have SD2IEC support!
You know it required a lot of effort to do this and reading comments like this is not rewarding and supporting at all. I will ignore them and rather focus on doing great stuff what real demosceners can appreciate.
|
|
Posted By
Luca
on 2017-05-05
06:40:02
| Re: Trackloader For The Masses Not The Classes
Oh no no please no drama ignition, more smileys are needed I'm happy to have now the chance of using Bitfire+4, and I would be even more happy if a Dreamload conversion would pop out from somewhere, or anything else treating SD2IEC compatibility.
Have to say I'm quite happy of the bubis' and BSZ's interest into this conversion, just because, as Csabo has pointed out, options are very welcome: now I can project farer than before my vision for any future release, or, example given, MMS now could release a graphics collection disk with IRQ trackloader playing a SID...or Terra Nova's tune!
Apropo, bubis. I know what you mean, but don't feel angry with anybody, nonetheless with gerliczer, who has shown interest in your release , all in all... ;) You know, the Plus/4 scene is much more relaxed than the C64, where ppl still "fight" into a crack scene for example, and there's a great variety of different users among democoders, barely fascinated, nostalgics, C16 classic games' players and so on :)
|
|
Posted By
Mad
on 2017-05-06
17:11:43
| Re: Trackloader For The Masses, Not The Classes
Just my 2 cents: I know that the porting of my games caused some trouble and perhaps this is the aftermath of it. That I had to add a SD2IEC Kernal loader was just no fun at all, since the games and demos also used the lower pages for code and it was really tricky to find the memory addresses which the Kernal Loader overwrites. Saying that, the main problem I faced with the Kernal loader was, that it caused some sei/cli commands which resulted in flickering of the loading screens, since I had to use irqs there.
To make it short, for me the main purpose of a track loader is not speed, it's the possibility to load in the background. Which is not fully given by the Kernal ones, they do restrict the on frame interrupt (and cause this sei/cli flickering) duration, too.
On C64 there is the Turbo Chameleon 64 which is somewhat "like" the SD2IEC but emulates a full floppy drive, too. So they don't have the problem anymore, a Chameleon seems to be pretty expensive sadly, too. (Don't know if the options siz mentioned also emulate a full floppy drive.)
Doing the Kernal stuff for all of my "products" was somehow the worst part of making them. I spend many hours figuring out what went wrong with the Kernal routines. And it was no fun at all, however I also learnt a little. Just remember making a product only for the SD2IEC would be also a no go, but perhaps possible. As said, using the Kernal routines is very bad from a programmers perspective, e.g. you have to wait several minutes for loading of a level on the 1541.. Or even the restriction for the interrupts to reside below $8000 and other ram/rom relations.
I just understand Bubis that he made some major effort to bring something nice to the plus/4 and got the response that he better should haven't done it, which is also somewhat embarassing and funny (no offence). As Luca said, the scene consists of different types of people, however from my perception the scene here is consisting of around 20 people (could be wrong) and telling some of them they should haven't done something if it's actually a plus for the options of any programmer on the plus/4 is not the best response Bubis could get for it.
Yes some people do have a SD2IEC and some people other hardware but that should not be a limiting factor on the options the other people have. I would be happy with a Trackloader which supports SD2IEC and 1551, too. However that doesn't seem to be in reach. So I stick to the currently "crappy" options for these devices (e.g. Kernal Loading).
However I wan't to do some stuff (e.g. displaying/animating something) while the demos or games are loading. So there is currently no other way else then using the current tackloaders anyway. Just anyone remember, that your hardware setup is not the only one!
And please don't take it to personal, as Luca said, the plus/4 scene isn't about fighting anything at all. That's not "CSDB like territory".
So be happy and enjoy this nice (here rainy) day!
ps: If I got some facts wrong, sorry. I just wanted to tell my view of the current loading systems on plus/4. And gerliczer I do also understand your point.
edit: Forgive me what I said about the CSDB, but sometimes there seem to be hard fights about a single "nop" or some missing credit there.. :)
|
|
Posted By
Csabo
on 2017-05-05
09:14:49
| Re: Trackloader For The Masses, Not The Classes
Hey, it's raining here also today.
But this release is pretty cool, and I'm confident that regardless of any comments, it's still appreciated by all.
Now, I'll just add one more thing, to address this part specifically: "Why don't you rather create a fork..." bubis, you massively overestimate us This is said in the nicest way possible, but Csabo = lamer, Luca = lamer, gerliczer = lamer. Seriously! We don't know the first thing about programming stuff for any drives. (Let alone using what you've released... I've been looking at it but damn... I'm a lamer, sorry.) Perhaps Mad or siz could do a fork - and what do you know, they have their own loaders
But yeah, bottom line: new trackloader, source released, this is a huge win for the scene. Kudos man!
|
|
Posted By
bubis
on 2017-05-05
09:33:47
| Re: Trackloader For The Masses, Not The Classes
I don't know drive coding either, that part was done by BSZ.
Just look into the example directory, the code and build script should make everything clear. This stuff is self contained, I even included the acme assembler (Bitfire compiles with that), so you don't need anything else installed to get it working.
If you want to dive deeper, read the readme files first and maybe download the whole source code.
Let me know if you have any questions!
|
|
Posted By
Murphy
on 2017-05-05
14:39:43
| Re: Trackloader For The Masses, Not The Classes
Guys, the fastest c64 loader now working on plus/4.
I have only one problem, no voting option on the Plus/4 world for this release. 10/10
|
|
Posted By
Gaia
on 2017-05-05
16:53:55
| Re: Trackloader For The Masses, Not The Classes
Slightly offtopic, but there is an extremely cool new drive emulator in the works by Zoltán Kollár, it is SD card based and will support disk turbos as well as it emulates a full 1541.
|
|
Posted By
Lavina
on 2017-05-06
07:13:06
 | Re: Trackloader For The Masses, Not The Classes
I have a lightpen. I demand every game and demo to be compatible with lightpen. I'm tired of hitting space between parts. Seriously, it's the 21st century. I want to click an icon with my lightpen on my TFT. Is that so much to ask for????
You can find the blueprint of the lightpen on our homepage. Please build one and use it.
P.S.: What's a fork???
P.S.2.: BSZ & Bubis - Great work, thanks so much!!! For those who don't realize what it means: more possible trackmos for the plus4. If that's not good news, then nothing in this bloody lightpenless century.
+++ EDIT +++; P.S.3.: I guess the scene is bigger than 20 dudes, it's like porn. More silent watchers than doers. ;-) Csabó? Any attendance stats available? :)
|
|
Posted By
bubis
on 2017-05-05
18:28:49
| Re: Trackloader For The Masses, Not The Classes
"A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project. Most commonly, forks are used to either propose changes to someone else's project or to use someone else's project as a starting point for your own idea."
Source: https://help.github.com/articles/fork-a-repo/
Bitfire+4 is on GitHub, the source code is freely available. It is actually a fork of the original Bitfire code base.
|
|
Posted By
Luca
on 2017-05-06
01:56:41
| Re: Trackloader For The Masses, Not The Classes
Lightpen's driven demo  Oooh smart idea indeed, that would really become a true absolute first original!
bubis: a tech question: mixing hidden trackloading stuff (.prg+.lz) and normal .prg files in the same BAM, should allow me to load the latter ones by blocks normally, but within an IRQ loader anyway, am I right?
|
|
Posted By
MMS
on 2017-05-06
03:17:31
 | Re: Trackloader For The Masses, Not The Classes
BSZ & Bubis - Thanks for the great release! And also a 10/10 from my side too.
You will see, if I can grow up to the expectations, or I just remain the smurf of coding
|
|
Posted By
bubis
on 2017-05-06
05:16:08
| Re: Trackloader For The Masses, Not The Classes
Hi Luca,
The Bitfire routines can only load files what you copy to the disk with the d64write -b option.
Other files, like high scores in a game - what you want to modify too - need to be treated separately.
(A hacky way may be to figure out the track/sector of Bitfire files and write them by blocks and read them by Bitfire routines. Let's get back to this if you really want to do something like this.)
|
|
Posted By
Luca
on 2017-05-06
12:34:42
| Re: Trackloader For The Masses, Not The Classes
- where to find "reset_drive.asm" and "request_disc.asm"?
- in the example, I saw the code rests in idle state when the screen is displayed, from rasterline $03 to rasterline $cc; didn't try by myself: how much maximum raster would steal the whole process of loading/depacking, as you experienced (in order to know how much I could spend for what's running on screen)?
|
|
Posted By
bubis
on 2017-05-06
14:10:22
| Re: Trackloader For The Masses, Not The Classes
Hi Luca,
Those .asm files are not part of the binary release, but they are included in the source packages what you can also download on the github release page: https://github.com/dotscha/bitfire/releases
The example code demonstrates that you can run your code in irq and load files in the remaining time in the main program. You can interrupt loading for any amount of time but it loads slower if you spend more time in interrupts. There is no simple answer to the how many rasterlines are needed for loading question. You have to experient with it.
|
|
Posted By
Degauss
on 2017-05-06
20:47:31
| Re: Trackloader For The Masses, Not The Classes
Didn't try this yet but: Kudos! Great work, guys!
|
|
Posted By
siz
on 2017-05-07
05:13:14
| Re: Trackloader For The Masses, Not The Classes
I've just tried out building and running the example of the loader. Seems to be fast but it's noticeably slower in NTSC mode (probably due to the forced double clock mode and less border lines).
I don't have a lot of free time but if you need help creating the single clock and/or the 1551 version probably I can help you.
In my loader I use a fully asynchron communication controlled by the computer so you can interrupt the transfer any time so your interrupts can be stable and it does not care if it's single or double clock. Of course it's a bit slower this way but the slow part is always reading the disk, not the transfer itself. For example with SD2IEC it's faster than the 8 bit 1551 due to no moving parts on an SD card.
|
|
Posted By
Luca
on 2017-05-07
05:47:35
| Re: Trackloader For The Masses, Not The Classes
siz: in the main.prg example, there's an IRQ doin' nothing from raterline $003 to $0cc, so maybe you have to change this values if you wanna try it on NTSC.
|
|
Posted By
bubis
on 2017-05-07
14:46:14
| Re: Trackloader For The Masses, Not The Classes
Degauss: Trying out means: download, unzip, run example/build.bat and run the resulting d64.
Siz:
1. Why don't you release that loader? Hey, that has SD2IEC suppot, make gerliczer happy, please! Can you show us how it performs? Like, can you do the same with your loader what you see in the example code?
2. The example code is only loading on the border, and you have less border lines on NTSC. Have you noticed NTSC compatibility?
3. Anyway, BSZ is basically done with the 1xClk receiver code. It is as fast as the C64 code. I will probably create a new release with that included in the coming weeks. 1551 support will require changes in the drive code too, so that will come later.
|
|
Posted By
siz
on 2017-05-07
18:49:07
| Re: Trackloader For The Masses, Not The Classes
I think you misunderstood me.
1. I know, I should. But I'm a lazy bastard and I always find some excuse what I want to do before releasing.
2. Yes, I noticed. And that's exactly what I wrote too: yes, it works in NTSC mode but due to less rasterlines it's noticeably slower. For me that was a bit surprising. First of all that it runs in NTSC and secondly that I can notice the difference. But kudos for the NTSC compatiblity.
3. I offered my help if you need it.
PS: I took the effort and put up a minimalist version to BitBucket. (because I host my private repositories there too). There is no such a fancy testprogram as in bitfire but that will come too. I've also added a readme and a minimalist make windows batch file.
PS2: BTW the link: https://bitbucket.org/siz/siziolibv3
|
|
Posted By
bubis
on 2017-05-08
10:50:47
| Re: Trackloader For The Masses, Not The Classes
This is serious stuff! Version 3, support for many hw and you only release it now?
I will take a closer look as soon as I have a bit more time.
|
|
Posted By
Luca
on 2017-05-08
11:09:18
| Re: Trackloader For The Masses, Not The Classes
siz: great stuff, variety of choices ftw!
|
|
Posted By
Lavina
on 2017-05-08
13:03:12
| Re: Trackloader For The Masses, Not The Classes
And you still have not seen everything.
|
|
Posted By
bubis
on 2017-07-13
06:05:33
| Re: Trackloader For The Masses, Not The Classes
Hi,
Here is the latest binary release for Bitfire+4, highlights:
Bitfire+4 2017.05.21:
- Resident part: $200-$3ff
- Zero page usage: $04-$0a
- 2bit ATN double clock receiver
- 2bit ATN single clock receiver
- Receiver swap routine: $400-$471
- load raw, load+decomp, decomp routines
- Basic irq handler for music with double clock protection
- Frame counter, partial SID detection
- Include files and useful macros for the most popular cross-assemblers
- Win32 packer and image writer tool, ACME cross-assembler
- Precompiled installers for Plus/4
- Simple code example and Win32 build script that uses the included assembler
Please see readme+4.txt for more details.
|
|
Posted By
siz
on 2017-05-22
04:45:21
| Re: Trackloader For The Masses, Not The Classes
Yes, I saw it last night. Great work!
A bug report: if drive #8 is 1541 and #9 is 1551 it will still say that there are 2 drives on bus and refuse to work. (accidentally my YaPE was set up like this). It would be nice if it ignored 1551's from the count. I started to create a patch but found no easy way (=doable in max. 5 rows of assembly) to do it so postponed it and rather report it as a bug than create a patch and pull request.
|
|
Posted By
Degauss
on 2017-05-22
05:47:40
| Re: Trackloader For The Masses, Not The Classes
dblclk receiver!? gotta take a look...
|
|
Posted By
bubis
on 2017-05-22
15:17:03
| Re: Trackloader For The Masses, Not The Classes
siz:
Thank you for pointing that out. It's a known bug, BSZ willl likely rewrite the whole drive detection logic as soon as the 1551 port is done.
Degauss:
The double clock receiver means that it is optimized for loading in double clock mode on the border. So, that is interrupt friendly, but slow on the screen where you have many single clock cycles.
The single clock receiver switches to single clock mode for block transfers, so that is equally fast on the screen/border but it basically does a
lda #2
php
sei
eor $ff13
sta $ff13
plp
when flipping the clock bit to protect the other bits of $ff13, so that delays interrupts a bit. There is a bitfire_plus4_sei label defined in the include files, so you can change that sei to nop, if you don't mess with $ff13 in your interrupt routines. This is the best I could come up with, I really hate this clock bit misery.
|
|
Posted By
Mad
on 2017-06-07
12:37:16
| Re: Trackloader For The Masses, Not The Classes
So, we finally decided to use Bitfire Plus/4 for our current game. The speed is a very good argument for it! It's really awesome. It seems that a 1551 port is planned, what is very good news.
However there is a problem. We have these people using the SD2IEC, and Bitfire loads tracks instead of files. If anyone has an idea how to load these files with an SD2IEC (perhaps with the kernal loader) any help would be most appreciated. (And we really needed the speed for this game)
btw: Bitifre is exceptional and easy to use! Thanks a lot for that!
|
|
Posted By
bubis
on 2017-06-07
17:20:12
| Re: Trackloader For The Masses, Not The Classes
Hi Mad,
This is good news!
We are making good progress with the 1551 port. The drive code and transfer is done, but we have to rewrite hw detection and the installer and there are other issues too. That will take a while.
Don't expect SD2IEC support any time soon or maybe ever. Please give SIZ's loader a try too.
|
|
Posted By
Mad
on 2017-06-07
17:27:39
| Re: Trackloader For The Masses, Not The Classes
Hi Bubis,
Siziolib sadly is much too slow. Perhaps I change to Krills Loader again, later on. We have some time now.. I'll see what can be done later on.
|
|
Posted By
bubis
on 2017-06-07
19:14:02
| Re: Trackloader For The Masses, Not The Classes
Krill's loader supports more disk drives for sure, but I don't think it supports SD2IEC.
|
|
Posted By
Mad
on 2017-06-07
19:37:31
| Re: Trackloader For The Masses, Not The Classes
I have implemented a Kernal Fallback for Krills Loader in the past.. It used just the Kernal Routines to load from SD2IEC.. However I think I stay with Bitfire..
|
|
Posted By
bubis
on 2017-06-15
12:13:11
| Re: Trackloader For The Masses, Not The Classes
Update:
We are kind of settled with the 1551 transfer routine. The fastest version worked at 1 byte / 19.5 cpu cycles but that was too complicated, so we decided to use another one that is half cycle slower. Drama!
Drive detection is also done in theory.
Now, I have to put the pieces together and create the next release, and first of all, test it properly!
BSZ will develop a block saving routine too what you can upload to drive memory using Bitfire routines. (You can't use kernal routines while Bitfire is installed in drive memory.)
|
|
Posted By
Mad
on 2017-06-15
12:03:29
| Re: Trackloader For The Masses, Not The Classes
Great news! Looking forward to test it here (yape/vice/plus4emu).. Perhaps this could get the standard for plus/4 loaders, that saving routine is marvelous..
|
|
Posted By
bubis
on 2017-08-08
06:41:15
| Re: Trackloader For The Masses, Not The Classes
Hi Guys,
I don't want to delay this even further, I want to show you some progress and move on, so I created a new release of Bitfire+4. It's actually a pre-release, I will explain why, but highlights first:
Bitfire+4 2017.07.12:
- Resident part: $200-$3ff
- Zero page usage: $04-$0a
- 1541 2bit ATM double/single clock receiver routines
- 1551 8bit protocol
- Optional 1541 receiver swap routine: $400-$471
- Precompiled installer for 1551 and 1541/1551 multi installer
- load raw, load+decomp, decomp routines
- Request disk and reset drive routines working with both 1541/1551 drives
- Basic irq handler for music, cpu clock protection, frame counter
- SID chip detection, missing SID detection and NAE detection
- Include files and useful macros for the most popular cross-assemblers
- Win32 packer and image writer tool, ACME cross-assembler
- Simple code example and Win32 build script that uses the included assembler
Please check readme+4.txt for more details.
So, why the pre-release, and why not a release? It's because the 1551 loader only works on the real machine or on Plus4Emu, and the installer for the 1551-only version sometimes has some strange behavior what we couldn't fix yet. The 1551 part worked just fine on Yape a few days ago, we are not really sure what caused this issue. I will create a proper release as soon as these problems are resolved.
You can download it here, your feedback is highly appreciated!
If you have both 1541/1551 drives and want to help in testing, please download test_plus4_1551.d64 and test_plus4_multi.d64.
|
|
Posted By
Luca
on 2017-07-13
11:19:03
| Re: Trackloader For The Masses, Not The Classes
Testing it right now on 1551, with several installer's attempts to start over and over: it's reliable, and it's incredibly INCREDIBLY fast!
|
|
Posted By
Lavina
on 2017-07-13
14:00:41
| Re: Trackloader For The Masses, Not The Classes
Christmas comes early this year
|
|
Posted By
bubis
on 2017-07-13
15:43:50
| Re: Trackloader For The Masses, Not The Classes
Update: Ok, so it seems the loader is working OK on real hardware. The Yape problem is a TIA emulation issue what will be fixed in the next Yape release, Gaia has confirmed it.
The reason why I remember Yape working in 1551 mode is that BSZ has changed the protocol and the earlier version really worked. Maybe it wasn't a few days ago, sorry guys, I am getting old, but at least I am not completly senile yet!
|
|
Posted By
Mad
on 2017-07-13
20:01:55
| Re: Trackloader For The Masses, Not The Classes
Bubis stay concentrated for many years to come, we need some more awesome demos for the plussy in the future. Good news, that it was not the loaders fault. Have to try it soonish, it's the first real fast option for 1541 and 1551 here, thanks for that!
|
|
Posted By
bubis
on 2017-07-15
04:06:54
| Re: Trackloader For The Masses, Not The Classes
Hi Guys,
Gaia has kindly created a quick Yape release (1.1.4) that fixes the TIA issue and a SID issue, so Bitfire should work on Yape with 1551 too including correct SID detection. We will try to fix the remaining bug in the installer over the weekend and then I will create a proper production ready release.
So, it's basically mission accomplished as far as the loader is concerned, but we will push it a bit further. BSZ will implement a save routine, so you will be able to persist game state, high scores, etc. with Bitfire too.
|
|
Posted By
Mad
on 2017-07-15
18:24:32
| Re: Trackloader For The Masses, Not The Classes
Incredible.. Now the current project works with 1541 and 1551.. And I thought this day would never happen! Big thanx to you guys!
|
|
Posted By
siz
on 2017-07-16
16:46:39
| Re: Trackloader For The Masses, Not The Classes
> including correct SID detection
I'm not sure about this one: my detection routine (which is included in my IOLibV3) works perfectly on real hardware but always detects 8580 on YaPE 1.1.4 independently of whatever SID type I choose in settings.
|
|
Posted By
bubis
on 2017-07-17
07:45:14
| Re: Trackloader For The Masses, Not The Classes
Siz, I think you are right about that. I don't have the latest Plus4Emu, but I have found a problem there too: it always detects a SID chip even when SID emulation is disabled.
Btw, hardware detection results are stored in link_chip_types = link_sid_type = link_drive_type = $03FF
bit 7: 1551 drive
bit 6: TED only, no SID
bit 5: NAE card
bit 4-1: unused
bit 0: new SID
BSZ has fixed the installer over the weekend, so, here is the official Bitfire+4 2017.07.17 release.
|
|
Posted By
Gaia
on 2017-07-17
08:02:32
| Re: Trackloader For The Masses, Not The Classes
@siz: YAPE does not emulate combined waveforms in 6581 mode properly (yet). It always emits 8580 type waves. Well, almost all SID cards are with 8580 anyway.
|
|
Posted By
siz
on 2017-07-17
08:37:36
| Re: Trackloader For The Masses, Not The Classes
Okay. I can live with that.
|
|
Posted By
Hypex
on 2017-08-08
10:42:29
| Re: Trackloader For The Masses, Not The Classes
Not trying to add insult to injury here but are any fastloaders in use compatible with the SD2I
EC? Or use the same transfer protocol? I do wonder if a fastloader can send testing code like JiffyDOS does in its strange way to the drive to determine what is present. I don't know how it supports different loaders if it doesn't fully emulate a 1541. Given they also say fast loaders are not supported. Seems like some kind of contradiction there.
So the list is JIFFYDOS, GEOS, FINAL CARTRIDGE III, EXOS, TURBODISK, EPYX FASTLOAD, SPEEDDISK AND DREAMLOAD FASTLOADERS.
Is Bitfire similar enough to these that it would work?
I'd like to have a Virtual1551. This would be plug in the cartridge port and act just like a 1551 except the disks would be stored on SD card. And because of the parallel port transfer of the 1551 it would totally crap over the 1541 fast loaders with an extra fast loader. It would also include a fast DMA mode where files would be loaded direct to host memory as fast as possible. Perhaps even as re-mapping internal RAM to host RAM like an expansion. Since it also includes 64KB. As well as a the ability to pick a cart to play. Hold down a key and a boot menu would come up. One can dream.
|
|
|
|
Posted By
Hypex
on 2017-08-10
10:42:31
| Re: Trackloader For The Masses, Not The Classes
Nice. It looks speed up. Is it 1541 killer 1551 fastloader?
|
|
Posted By
bubis
on 2017-08-30
12:21:14
| Re: Trackloader For The Masses, Not The Classes
Hypex: Those fastloaders are supported in the SD2IEC firmware, this is why they work, and not because SD2IED emulates the code they upload to the drive memory.
Bitfire is not supported (yet), but it is probably possible to add support for it too.
Some good news on our front: BSZ is done with the save routine (1541/1551), but it will take some time to test it and to create a proper release for it.
|
|
Posted By
Mad
on 2017-08-30
13:10:54
| Re: Trackloader For The Masses, Not The Classes
yeah!!! bubis you're my heroes.. I mean BSZ... .. Talked yesterday to Kichy about a save routine.. And it seems it will be finally there! Many thanks in advance!
|
|
Posted By
bubis
on 2017-09-01
06:17:20
| Re: Trackloader For The Masses, Not The Classes
It is already up on github and testing/save_test.asm demonstrates it's usage on both c64/plus4 if anyone is so curious.
I will try to do a binary release this weekend. I want to close this project finally and continue working on my trackmo!
|
|
Posted By
Luca
on 2017-09-01
06:33:09
| Re: Trackloader For The Masses, Not The Classes
Finishing projects, continuing trackmos...I'm listening to a series of wonderful words here
|
|
Posted By
bubis
on 2017-09-01
08:11:04
| Re: Trackloader For The Masses, Not The Classes
Don't be too excited yet! I am still porting my unreleased c64 effects, trying to improve them (like bitmap instead of zoom4, etc.). I haven't even started thinking on the demo concept or a release date yet. Short term goal is to finish porting this year. The prerequisite was a cutting edge loader of course, so porting Bitfire is kinda part of the demo project too. :)
|
|
Posted By
Mad
on 2017-09-01
07:59:44
| Re: Trackloader For The Masses, Not The Classes
great!!! ahem.. awesome!!!
|
|
Posted By
Hypex
on 2017-09-03
09:43:50
| Re: Trackloader For The Masses, Not The Classes
@bubis
Yes the SD2IEC has some fast loader detection code. After a brief read it looks like it checks for 1541 drive uploaded code so certainly possible to add support for Bitfire I think.
Perhaps I should add some encouragement that way. Having said that, is there a link for full source code? I downloaded the bitfire_plus4_20170712 archive but where are the main ASM routines? I can see include files and some support ASM but can't locate main ASM code .
|
|
Posted By
bubis
on 2017-09-04
11:45:21
| Re: Trackloader For The Masses, Not The Classes
That archive is a binary release. The source code is on GitHub:
http://github.com/dotscha/bitfire
Start with reading readme.txt and readme+4.txt.
I can't spend more time on BF, so please PM BSZ if you have questions.
|
|
Posted By
siz
on 2017-09-04
06:03:30
| Re: Trackloader For The Masses, Not The Classes
Yes, it's possible to add loader support for SD2IEC. For example for Bitfire you will have to add a separate plus/4 version as it has a different drivecode (SD2IEC download generates a checksum of the installed drive code and selects the appropriate protocol based on that). Sure, it's definitely doable.
But I would suggest to wait for a feature complete, stable version of Bitfire before doing that. And after releasing a new version of SD2IEC firmware you have to ensure that every user updates to that version.
|
|
Posted By
Hypex
on 2017-09-04
12:51:33
| Re: Trackloader For The Masses, Not The Classes
Thanks guys.
I was under the impression that Bitfire was stable. And being that it would upload 1541 drive code would be ready to go for support. At least on the C64 side of things.
I've been reading a bit about these speed loaders and they all seem to employ this common 2-bit routine with critical timing. I've come up with my own 3/3/2 routine for transfer of one byte with handshake timing, so to speak. In my head. In this one it uses the clock, data and attention lines to send 3 bits of data from drive to computer. Drive then waits for inverted result. When computer has data it sends inverted bits back to signal it's ready for next lot. Possibly one bit is all that is needed. It collects three bits again. Finally it gets the last two and signals back. A whole byte is stored. It only gets 2 bits on the last transfer because odd bits would be a pain to work with. The only problem would be abusing the attention line if it wouldn't interfere. And of course if the data can be synced like I describe.
|
|
Posted By
siz
on 2017-09-04
14:20:09
| Re: Trackloader For The Masses, Not The Classes
On the term 'stable' I meant that presumably it won't change in the near future.
|
|
Posted By
bubis
on 2017-09-05
00:21:58
| Re: Trackloader For The Masses, Not The Classes
Bitfire+4 2017.09.05:
- Loader resident part: $200-$3ff or smaller
- Loader zero page usage: $04-$0a
- 1541 2bit ATM double/single clock receiver routines for Plus/4
- 1551 8bit protocol
- Optional 1541 receiver swap routine for Plus/4: $400-$46c
- Precompiled installers for C64, Plus/4 1551 only and 1541/1551 multi
- load raw, load+decomp, decomp routines
- Request disc and reset drive routines for all supported hardwares
- Save routine for all supported hardwares, source and precompiled binaries
- Basic irq handler for music, cpu clock protection, frame counter
- SID/CIA chip detection, missing SID detection and NAE detection
- Include files and useful macros for the most popular cross-assemblers
- Win32 packer and image writer tool, ACME cross-assembler with documentation
- Simple code example and Win32 build scripts that use the included assembler
Please check readme+4.txt for more details.
You can download it here.
|
|
Posted By
Mad
on 2017-09-05
09:52:45
| Re: Trackloader For The Masses, Not The Classes
Saving for the win! I check that in the evening. So it seems the new plus/4 standard loader is complete now. Curious to what products that will lead in the future. (thanx from here!)
|
|
Posted By
bubis
on 2017-09-05
12:59:43
| Re: Trackloader For The Masses, Not The Classes
I hope that people will try it and conclude that trackmos are not difficult to do anymore.
I already know someone who had a kind of aversion of loaders and linking and now using Bitfire routinely.
BTW, here is a very interesting forum discussion regarding demo linking on CSDb:
http://csdb.dk/forums/?roomid=11&topicid=106406&showallposts=1
|
|
Posted By
MMS
on 2017-09-05
15:29:21
| Re: Trackloader For The Masses, Not The Classes
I think I will need a "Bitfire for Dummies"  ...
|
|
Posted By
bubis
on 2017-09-06
07:59:56
| Re: Trackloader For The Masses, Not The Classes
@MMS: Look into the example folder in the package, build it, that's a very basic example, so start there.
|
|
Posted By
Mad
on 2017-09-05
21:09:52
| Re: Trackloader For The Masses, Not The Classes
@Resource: I tested the save routine (with recompiling it to another memory location using the bat. extremely easy!!) and it works in 1551 and 1541 mode here (just yape, but it works). Nice idea to use a file on disc for a predefined track/sector location (thus also readable with bitfire again). Cool that all that is implemented now! Thanx from here! :)
|
|
Posted By
bubis
on 2017-09-26
08:50:40
| Re: Trackloader For The Masses, Not The Classes
@Mad: Thanks for checking it out!
For the education of others: The idea is that you save a file to disk in Bitfire format using d64write.exe's -b option. (These are the files what the loader can handle.) It prints out the starting track/sector of that file. You use that t/s in your code to overwrite the file on disk using this save routine.
(The nice thing about Bitfire files is that one block is one sector on the disk, so there are no t/s links at the beginning of the sectors. This is possible because d64write uses fixed interleaves on the whole disk, so the t/s links are deterministic and the loader pre-computes that instead of reading it from disk.)
Hi Guys,
Yet another release. We have found some hidden features unexpected issues with the save routine. Those are fixed now and I have added a bootdisk creator script to the package too. Enjoy!
Bitfire+4 2017.09.25:
- Loader resident part: $200-$3ff or smaller
- Loader zero page usage: $04-$0a
- 1541 2bit ATM double/single clock receiver routines for Plus/4
- 1551 8bit protocol
- Optional 1541 receiver swap routine for Plus/4: $400-$46c
- Precompiled installers for C64, Plus/4 1551 only and 1541/1551 multi
- load raw, load+decomp, decomp routines
- Request disc and reset drive routines for all supported hardwares
- Save routine for all supported hardwares, source and precompiled binaries
- Basic irq handler for music, cpu clock protection, frame counter
- SID/CIA chip detection, missing SID detection and NAE detection
- Include files and useful macros for the most popular cross-assemblers
- Win32 packer and image writer tool, ACME cross-assembler with documentation
- Simple code example and Win32 build scripts that use the included assembler
- Build script for bootdisk creation with optional dir art.
Please check readme+4.txt for more details.
You can download it here.
|
|
Posted By
Mad
on 2017-09-25
19:34:01
| Re: Trackloader For The Masses, Not The Classes
Cool! We did too have problems with the save routine. I had disabled it a few days ago. Now all is working correctly again and a main feature of our project now is doing like it should..
|
|
Posted By
bubis
on 2017-12-15
12:22:03
| Re: Trackloader For The Masses, Not The Classes
Hi,
New release! It's the same as the previous one plus some d64write improvements:
- It fixes a bug in d64write that printed wrong number of sectors information.
- Now you can save files of any size with the --boot option, when d64write runs out of sectors on track 18 (the directory track) it continues saving the file on normal tracks.
|
|
Posted By
Mad
on 2017-12-13
12:58:56
| Re: Trackloader For The Masses, Not The Classes
Wow cool! The first fix is really a must have for me. Getting the right block count of files and the complete disc is extremely useful. It was a little puzzling to see the block counts not changing after optimizing the routines. The second fix is also ace. Thanx!
|
|
Posted By
Luca
on 2017-12-13
13:04:23
| Re: Trackloader For The Masses, Not The Classes
The first fix comes just in time
|
|
Posted By
bubis
on 2017-12-14
08:59:57
| Re: Trackloader For The Masses, Not The Classes
Thanks for reporting it Mad!
|
|
Posted By
bubis
on 2018-08-28
03:57:28
| Re: Trackloader For The Masses, Not The Classes
Also falls into the "Trackloader For The Masses" category: Krill's new loader
https://csdb.dk/release/?id=167152&show=notes#notes
This has dramatically reduced resident size (~$280) and precompiled binaries for C64/Plus4 too!
|
|
Posted By
Mad
on 2018-08-28
07:50:49
| Re: Trackloader For The Masses, Not The Classes
Yes!!! Krills loader got a major update. He told me that there is no 1551 support currently done with it. If Krill takes the effort to implement the 1551 again, I think that would be a real nice option besides bitfire (and spindle?). Mostly because there is this Kernal fallback option, so no need to implement a custom routine for non fully compliant drive emulations like the SD2IEC and so on. Krill said this is actually the version 1.0 of his loader, as far as I remember. Cool to see it here, thanx bubis ( and of course Krill )!
|
|
Posted By
bubis
on 2018-08-28
08:29:38
| Re: Trackloader For The Masses, Not The Classes
I think 1551 also works with kernal fallback.
|
|
Posted By
siz
on 2018-08-28
17:19:28
| Re: Trackloader For The Masses, Not The Classes
The last version I've tested (a long time ago; before the official plus/4 version) the KERNAL fallback with a 1551 did not work.
|
|
Posted By
bubis
on 2018-10-01
05:37:04
| Re: Trackloader For The Masses, Not The Classes
Not major news, but a good news: I have tested Bitfire+4 with SD1541 (the first version, not V2) and it works properly!
|
|
Posted By
BSZ
on 2023-07-24
17:09:26
| Re: Trackloader For The Masses, Not The Classes
Ú, de rég is volt ez...
Az SD2IEC + VCPU topikban emlegettem, hogy az egész amiatt lett elkezdve, hogy a Bitfire-hez legyen reális lehetőség SD2IEC támogatást írni. A témában vannak fejlemények, erről hamarosan beszámolok. Elöljáróban annyit, hogy páran már láthatták működés közben! Illetve kedvcsinálónak egy kép:
"Ezt senki se próbálja ki otthon!"
Ápdét 2023.07.22.:
Itt ígértem egy hosszabb beszámolót, csak közben akadt egyéb feladat is. Készült pár mérés a töltési sebességekkel kapcsolatban, de az adatok előtt célszerű pontosítani, hogy mi is a cél valójában!
A feladat a topik címében emlegetett Bitfire töltő-rendszer SD2IEC-kel történő működőképessé tétele, de fontos kiemelni, hogy a BF alapvetően egy lemezes töltő. Tehát: az SD2IEC-es verziónak nem a leggyorsabb töltés a célja, hanem csak az, hogy hozza az 1541-es meghajtó sebességét. (Ha a töltőt használó program megfelelő sebességgel működik egy 1541-es meghajtóval is, akkor nincs ok arra, hogy ennél gyorsabban kelljen tölteni SD2IEC meghajtóról.)
Tehát a cél: hozni az 1541-es töltési sebességét, ahhoz képest bármi plusz az jó, de optimalizálni rá fölösleges. Azt már az elején megtippeltük, hogy csak a meghajtócsere önmagában gyorsítani fog (nem kell a lemez mechanikát kezelni, ami sok idő), emiatt lett még egy – legalább kipróbálandó – dolog: a ’41-es változat 2 bites adatátvitelt használ, de ennek van egy olyan hátránya, hogy csak egy eszköz lehet a soros buszra kapcsolva. Az SD2IEC-es verzióval érdemes megpróbálni az 1 bites adatátvitelt (hogy ne legyen ez a perifériaszám-limit), mert ha úgy is képes hozni az 1541 + 2 bites átvitel sebességét, akkor érdemes azt használni.
Maga a teszt annyit csinál, hogy a lemezen van 5 db. 32 KBYTE-os fájl, ezeket betölti sorban, és közben „megszámolja”, hogy a feladat hány képernyő-kirajzolás idejéig tart. A C64 / plus/4 képernyő-kirajzolási ideje nem pontosan egyforma, de az eltérés itt elhanyagolható, számolhatunk 50-nel másodpercenként. Azaz a kapott számot ha elosztom 50-nel, akkor megkapom, hogy hány másodperc alatt sikerült a 32 KBYTE adatot betölteni. (Itt a minél kisebb szám a gyorsabb.) Ha a 32-t elosztom az előbb kapott másodperc-számmal, akkor kijön az adatátviteli sebesség KB/Sec-ben. (Itt meg nyilván minél nagyobb a szám, annál gyorsabb.) A továbbiakban maradok a frame-számnál, aki a másik két mértékegységre kíváncsi, a fenti módon átszámolhatja.
No de jöjjenek az adatok! Készítettem még a múltkor két molinót, az első a C64-es verzió sebességeiről szól:
Az első két képrészlet az eredeti 1541-es töltésről szól, a számok a képernyőn hexadecimális értékek, az idők így rendre 303..333 képkiírásra jönnek ki. (A hagyományos lemeznél nem minden sávon található ugyanannyi szektor, illetve még ezer másik tényező befolyásolja a sebességet, ez a szórás emiatt teljesen rendben van.)
A második két képrészleten már az SD2IEC-es töltés látszik, annál is a két bites adatátvitel. És itt fontos megjegyezni, hogy ebben az esetben kizárólag a meghajtó változott, a számítógép oldalán futó kód teljesen megegyezik azzal, amit az 1541-es esetben használ! Itt az idők 164..167 képkiírásra jöttek ki, ez jó közelítéssel a duplája a ’41-es sebességnek. Lehet bizakodni, hogy az 1 bites átvitellel nem fog a felénél jobban visszaesni a sebesség…
A harmadik két képrészleten az 1 bites SD2IEC töltési idők látszanak: 250..252 képkiírásnyi idők lettek az eredmények, ez szépen hozza is a várakozásokat, az 1541-es 2 bites adatátvitelnél azért nem kevéssel gyorsabb, és nem zavarja a soros buszon levő több eszköz a töltést. Azaz: érdemes ezt a verziót használni a későbbiekben.
És akkor jöjjön a plus/4-es méréscsokor, ez egy kicsit komplexebb lesz, és van benne meglepetés:
Az első két képrészleten az 1541-es töltési idők látszanak, mindjárt két példányban. Ehhez is kell ide egy magyarázat: a kedvenc gépünk kétfajta órajellel működik, a képkiírás pozíciójától függően egyszeres vagy dupla órajellel. Az adatátvitelnél viszont a meghajtó sebességéhez kell a gépnek igazodni, ami az 1541 esetén „nem túl gyors”. A számítógépnek viszonylag sokat kell várakozni a meghajtóra, még az adatátvitel közben is! De ezeket a várakozási időket a dupla órajelhez kell beállítani, mivel a gép időnként azzal a sebességgel megy. Emiatt egyszeres órajel esetén „nem optimális” a várakozási idő. A gépet be lehet úgy konfigurálni, hogy csak egyszeres órajellel működjön végig, ilyenkor beállítható olyan várakozási idő (igen, még ekkor is gyorsabb a gép mint a ’41), ami az adatátvitel szempontjából megfelelő. Az idők közül az „#Sx” sorok ebben, az egyszeres órajeles üzemmódban mért időket mutatják: 301..332 képkiírási idők jönnek itt ki. (Ezek jó közelítéssel megegyeznek a C64-en mért értékekkel.) A „#Dx” sorok a dupla órajeles adatátviteli idők: 370..388 képkiírásnyi ideig tart egy-egy töltés. (A dupla órajeles módnak az az értelme, hogy az egyszeres órajelre kapcsolgatás rengeteg dolgot (időzítést, egyebet) felborít. Szinte mindig megéri a lassabb töltési sebesség mint kompromisszum, mint hogy az órajel-váltások által okozott mellékhatásokkal kelljen küzdenie a programozónak.)
A második két képrészleten ugyanez a teszt egy 1551-es meghajtóval fut. Itt a töltési idők 134..166 képkiírásra jönnek ki. Az 1551 CPU-ja dupla sebességen fut az 1541-éhez képest, így itt nincs szükség a gép egyszeres órajelére, ezért egyeznek meg a „#Sx” / „#Dx” értékek.
A harmadik két képrészleten a teszt SD2IEC meghajtóval + két bites átvitellel futott, de itt is érvényes az, ami a C64-nél fent: a gép oldali program megegyezik az 1541-es verzióval, csak a meghajtó változott! Az idők 165..167 képkiírás közöttiek egyszeres, 207..210 képkiírás közöttiek dupla órajeles átvitelnél. Az (erősen hunyorítva) dupla sebesség itt is látszik mindkét értéknél, az egy bites átvitelt mindenképpen érdemes megnézni. És itt jön egy kis meglepetés:
A negyedik két képrészleten az SD2IEC + 1 bites adatátvitel látszik, ahol 146..149 közötti képkiírási időt sikerült a programnak mérnie. Ez az érték nem hogy nem lassú, hanem egyenesen az 1551 8 bites sebességének a nagyságrendje! Ehhez azért muszáj fűzni szintén egy kis magyarázatot: a használt adatátviteli módszert egy 1541-gyel nem lehet megvalósítani ekkora sebességgel, annak a meghajtónak a CPU-ja lassú a feladathoz. Az SD2IEC esetén a meghajtó „odaér” a plus/4 adatátviteli protokolljára, ráadásul még dupla órajeles működés esetén is! (Az „#Sx” / „#Dx” számok között ezért nincs különbség, itt sincs szükség az egyszeres órajelre, mint ahogy az 1551 esetén sincs.)
A számok talán adnak némi támpontot a sebességeket illetően, de mint ahogy sok más teszt, ez sem teljes körű. A Bitfire tud „töltés közben kicsomagolni”, a fenti példák csak a „nyers”, egyszerű töltési sebességet mérik. A kicsomagolásos verzióhoz nem sikerült olyan mérési metódust kitalálni, ami úgy általánosságban mondana valamit, nem csak az adott fájl adott módon történő betöltésére. (A kicsomagolással egybekötött betöltés koncepciója az, hogy ameddig a meghajtó a következő blokkot keresi / olvassa, addig a gép úgyis csak vár a meghajtóra. Ezt a várakozási időt ki lehet használni a kitömörítésre, de ez persze csak akkor tud működni, ha a következő adag adat kicsomagoláshoz szükséges BYTE-ok már be vannak töltődve.)
Maga a módosított Bitfire loader még némi finomításra szorul, de remélem nem sokára kiadható formába kerül. Kérem várjon...
| Re: Trackloader For The Masses, Not The Classes
Man, how long ago this was.
As I mentioned in the topic of SD2IEC + VCPU, all this started to provide real possibility to code SD2IEC support for Bitfire. There are new developments which I soon will tell about. As a hint for you, some people saw it in operation. Also, to pique your interest, here is a picture:
"None should try this at home!"
Update 2023-07-22:
I promised a longer report here, but I had other things to do in the meantime. A few measurements have been made of the loading speeds, but before the data, it is useful to clarify what the 'target'!
The task is to make the Bitfire loader system (mentioned in the title of this topic) work with SD2IECs, but it is important to point out that the BF is basically a disk-loader. So: the SD2IEC version does not aim to be the fastest, but only to reach the speed of the 1541 drive. (If the program using the loader works with a 1541 drive at a reasonable speed, there is no reason to load faster from an SD2IEC drive.)
So the goal is to reach the loading speed of the 1541, anything extra is good, but optimizing for it is unnecessary. We guessed from the beginning that just changing the drive alone would speed things up (no need to deal with the disk mechanics, which takes a lot of time), so we added one more thing - at least to test: the '41 version uses 2-bit data transfer, but this has the disadvantage that only one device can be connected to the serial bus. With the SD2IEC version, it is worth trying 1-bit data transfer (so that this is not the peripheral number limit), because if it can still achieve the speed of 1541 + 2-bit transfer, it is worth using it.
What the test itself does is that it loads 5 files of 32 KBYTE from the disk in sequence, and "counts" how many frames (screen-drawing times) the task takes. The C64 / plus/4 frame times are not exactly the same, but the difference here is negligible, we calculate at 50 per second. That is, if I divide the resulting number by 50, I get the number of seconds it took to load the 32 KBYTE data. (Smaller number is the faster.) If I divide 32 by the number of seconds I just got, I get the data transfer rate in KB/sec. (Obviously, higher number is the faster.) I will use the frame numbers, but if you want to know the other two units, you can convert them as above.
But let's get to the data! I made two more molinos the other day, the first one is about the speed of the C64 version:
The first two pieces are the original 1541 load, the numbers on the screen are hexadecimal, so the times come out to 303..333 frames. (With conventional disk, there are not the same number of sectors on each track, and there are thousands of other factors affecting the speed, so this scatter is perfectly fine.)
In the second two pieces you can see the SD2IEC loading with the two-bit data transfer. And here it is important to note that in this case only the drive has changed, the code running on the computer side is exactly the same as the one used in the 1541 case! Here the times came out to 164..167 frames, which is roughly double the speed in '41. Let's hope that with the 1 bit transmission the speed will not drop more than half...
In the third two pieces you can see the 1-bit SD2IEC load times: 250..252 frames, which is pretty much as expected, a bit faster than the 1541 2-bit data transfer, and not disturbed by the multiple devices on the serial bus. In other words: it is worth using this version in the future.
And then we come to the plus/4 measurement, this one will be a bit more complex, and there are surprises in it:
The first two pieces show the loading times of 1541, in two versions. Here's an explanation: our favourite machine works with two types of clock, single or double clock, depending on the 'printing' position on the screen. When transferring data, however, the machine has to adapt to the speed of the drive, which is "not very fast" for the 1541. The computer has to wait a relatively long time for the drive, even during data transfer! But these waiting times must be set to the double clock speed, as the machine will sometimes run at that speed. For this reason, the waiting time is "sub-optimal" for a single clock running speed. The machine can be configured to run at a single clock all the way through, in which case you can set a latency (yes, even then the machine is faster than the '41) that is full optimal for data transfer. Of the times, the "#Sx" lines here show the times measured in single clock mode: 301..332 frames come out here. (These are roughly the same as the values measured on the C64.) The "#Dx" lines are the double clock data transfer times: 370..388 frames per load. (The point of double clocking is that switching to single clocking messes up a lot of things (timing, etc). It's almost always worth the slower load speed as a trade-off rather than having to deal with the side-effects of clock changes for the programmer.)
The second two pieces show the same test running on a 1551 drive. Here the load times come out to 134..166 frames. The CPU of the 1551 is running at double the speed of the 1541, so there is no need to single clock in computer-side, hence the "#Sx" / "#Dx" values are same.
In the third two pieces the test was run with SD2IEC drive + two-bit transfer, but here too what applies to the C64 above: the machine-side program is the same as in the 1541 version, only the drive has changed! Times are between 165..167 frames for single clock transmission and between 207..210 frames for double clock transmission. The (heavily about) double speed is also visible here for both values, the one bit transmission is definitely worth looking at. And here comes a little surprise:
The fourth two pieces show the SD2IEC + 1 bit data transfer, where the program was able to measure between 146..149 frames. This value is not only not slow, it is the order of magnitude of the 8-bit speed of 1551! A little explanation is also necessary for this: the data transfer method used cannot be achieved with a 1541 at this speed, the CPU of that drive is slow for this task. In the case of SD2IEC, the drive "reaches" the data transfer protocol of plus/4, even in double clock operation! (The numbers "#Sx" / "#Dx" therefore make no difference, and the single clock mode is not needed here, as it is not needed for 1551.)
The numbers may give some indication of speeds, but like many tests, it's not comprehensive. Bitfire can "decompress while loading", but the above examples only measure the simple "raw" loading speed. For the decompress version, it was not possible to come up with a measurement method that would tell you something in general, not just how speed of load that file in a particular way. (The concept of an decompressed load is that as long as the drive is looking for/reading the next block, the machine is waiting for the drive anyway. This waiting time can be used for decompressing, but of course this can only work if the BYTEs needed to decompress the next batch of data are already loaded.)
The modified Bitfire loader itself still needs some refinement, but I hope to have it in a releasable form soon. Please wait...
(Partly machine translation, correct me if something is wrong! )
|
|
Posted By
Murphy
on 2023-07-23
03:39:37
| Re: Trackloader For The Masses, Not The Classes
Wow! This sounds truly revolutionary. But then you'd have to upgrade the SD2IEC firmware.
Can I do that easily? Will this cause any compatibility problems?
|
|
Posted By
BSZ
on 2023-07-23
07:32:18
| Re: Trackloader For The Masses, Not The Classes
@Murphy: Updating the firmware is simple (if the device was manufactured properly): just copy the new firmware to the root directory of an SD card, insert the card into the drive and press RESET. The drive will find the new firmware and perform the replacement.
No compatibility issues have been reported so far, but testing is always a good idea!
|
|
Posted By
Murphy
on 2023-07-24
06:00:10
| Re: Trackloader For The Masses, Not The Classes
Great! I'll update my SD2IEC as soon as it comes out.
How much extra disk space do I need if I make a new build from my older stuff?
|
|
Posted By
BSZ
on 2023-07-24
15:48:26
| Re: Trackloader For The Masses, Not The Classes
@Murphy: The 'installer' is currently ~12 blocks longer than the previous version, that's how much extra space is needed. But it currently includes the over-complicated, over-designed and oversized device selector, shown above. Instead, I think it will be worth making a much simpler one in the future. (Which will take up slightly less space.)
|
|
Posted By
siz
on 2023-07-25
04:11:46
| Re: Trackloader For The Masses, Not The Classes
@BSz: in my loader I use the last accessed drive (content of $ae) or if it's value is not in the 8-30 range then fallback to #8.
|
|
Posted By
BSZ
on 2023-07-25
12:44:24
| Re: Trackloader For The Masses, Not The Classes
@Siz: This is also a good solution, but there are problems with it. For example, the user loads the boot file from unit 9, then execute DIRECTORY command from unit 8, then RUN the loaded boot file. The above solution is then confused. Of course we can say that the user should not do this! This problem can be worked around with an autostart boot file, but many people don't like that. Fine by me, but it is true that on plus/4, LOAD "*",8,1 is more difficult than SHIFT+RUN/STOP.
One of the fixes is related to this: programmers typically pack the boot file. (Quite rightly!) BF's own compressor is suitable for this purpose: bitnax (BF own packer) can create a self-extracting file. But at runtime, the unpacking code overwrites - not very elegantly - a significant part of the ZP (incl. $AE). Therefore, I have added to the sfx code to preserve this memory content. But... The programmer may use another packer for this purpose, which may have the same problem.
The original C64 version solved this very simply: because of the 2-bit transmission, only one device can be on the bus. If more devices were found during the scan, the user was asked to fix the problem. If only one device is present, it should be used. But with plus/4, the complications have started: for example, a 1551 does not cause any problem in 1541 with 2 bit transfer. The full chaos starts with SD2IEC: there is no problem with multiple devices on the serial bus.
The current program does is check and count the devices on startup. If you find only one device and it is supported, use it. In all other cases, the drive selector UI is launched. The last used drive will be selected, the user just has to confirm it.
This drive selector code has become quite complicated, may want to make a simpler one in the future. I have tried to make it in a way that is easy to replace, whether or not I succeeded, I will find out when I try.
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
