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



Post Your Message
Username: (Login)

Topic:
Message:
  


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

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

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

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

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

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

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

Mad
on 2017-09-01
07:59:44
 Re: Trackloader For The Masses, Not The Classes

great!!! ahem.. awesome!!!

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

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

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

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

siz
on 2017-08-08
13:24:44
 Re: Trackloader For The Masses, Not The Classes

SD1551 prototype by Jácint Juhász (nickname: IEC-ATA): https://www.youtube.com/watch?v=uAXmtxo7ufQ

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

siz
on 2017-07-17
08:37:36
 Re: Trackloader For The Masses, Not The Classes

Okay. I can live with that.

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

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

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

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

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

Lavina
on 2017-07-13
14:00:41
 Re: Trackloader For The Masses, Not The Classes

Christmas comes early this year

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

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

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

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