COMMODORE PLUS/4 WORLD
  Home  Search  Games  Tapes  Covers  Cheats  Maps  Software  New Stuff 
 Hall Of Fame  HVTC  Game Endings  Features  Solutions  Remakes  Publications  Magazines  Effects  Top List 
 Members  Groups  Plus/4 Encyclopedia  Hardware  Tools  Options  Forum 
Login
Forum Help



Post Your Message
Username: (Login)

Topic:
Message:
  


Previous Messages
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

Degauss
on 2017-05-22
05:47:40
 Re: Trackloader For The Masses, Not The Classes

dblclk receiver!? gotta take a look...

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

bubis
on 2017-05-22
02:39:09
 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

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

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

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

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-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

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

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

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

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

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
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

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

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

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

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

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

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

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

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

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

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

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

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
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

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

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

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

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-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

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
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

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

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

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

bubis
on 2017-05-05
07:17:13
 Trackloader For The Masses, Not The Classes

Coming soon!


Copyright © Plus/4 World Team, 2001-2017