Hello, Guest the thread was viewed3.5k times and contains 20 replies

last post from mega65 at the

JiffyDOS

    Should be doable. But how much increase in loading speed it will give is uncertain thanks to the speed the system already has (i am thinking about diminishing returns here).

    Another problem is that JiffyDOS is licensed per machine basis - and will add to the total cost in the end.

    This is more or less guesswork - and i think Gardners is able to shed some light on this.

    In principle, the MEGA65 will be able to run any C64 or C65 ROM. So if you own JiffyDOS ROMs, they should work. However, this will not make any difference to the internal drive, except to disable it, since you would need a C65-version of JiffyDOS to have it not clobber the routines that talk to the internal drive.

    We do have plans to make a better C65 ROM with much faster speeds on the internal drive, and that would be backward compatible with existing C65s. It seems it should be possible to increase the internal drive speed from ~1KB/sec to 10 - 30KB/sec.

    Just curious: If you connect a 1571 to a C65, does it run at 1541 speed or does it use its burst mode? In the latter case, Jiffydos would add a lot less than it would in the first case and you could simply get yourself a 1571 in order to be able to read diskettes at good performance.

    The loading speed of the MEGA65 from a D81-Image is blazing fast: if you read a file that span the whole disk just using kernel routines, it will take about 15 seconds.

    Only cause for using Jiffy would be "legacy" hardware like a 1541, mostly for "migrating software". For 3.5" floppies would will most probably use the internal drive, SD-card readers like the Atmega based ones are rather pointless, because the MEGA65 is also planned to have SD card support.

    Imho, a good solution would be either a community-patched kernel or a program that patches the kernel during runtime. I'd also suggest to go for an open source reimplementation of the JiffyDOS serial line protocol, because of the copyright.

    Also note, that the internal floppy would not benefit from any *DOS floppy speeder, as it is not connected via a bus (serial or other), but running as a different configuration of the C65 CPU. I also remember reading a statement of one of the engineers of the C65 that the floppy is rather slow due to that design and that there's not much room for improvement.

    C65's internal drive is slow because (AFAIK) the software solution: it transfers byte by byte switching memory configuration modes on C65 (between DOS and KERNAL "environments"). Indeed, it's still faster than an 1541 would be, but far more slower what the internal drive would allow. So by only a software solution improvement can be "fantastic" (but needless to say, it's kinda fast enough even this way when running at ~48MHz, but it's another story). And anyway, if someone is brave, they can access the internal drive directly on hardware level, it's not on IEC or any other bus, but registers in the I/O area, like VIC, SID, or other devices (but not in VIC-II I/O mode, only in VIC-III, or well VIC-IV too in case of M65).

    ROM in M65 is not special in any way (in contrast of a real machine, where ROM is well ROM ... and having always the same content), from the viewpoint of M65 it's the "same" as being RAM, but with initialized content, and possibly write protection then to really behave as being a ROM. And ROMs are loaded from the SD-Card anyway. AFAIK, you can (or will be able to?) select ROMs in a user-friendly way with some key presses during the "boot process" from some pre-defined configurations or such.

    I think the use of a 1541 or 1571 with a Mega65 would be a lot broader than just "migrating software". Modifying C64 software with C65 functionality accessible from C64 mode will be the most economical way to get some software library that uses the Mega65. Adding some features is not much work for the community and can be done with a limited size community. However, eliminating all 1541 dependencies from such software would be a lot of work. Therefore I think it is safe to expect many people will not go that route and simply connect a 1541 or 1571, problem solved, use the built-in floppy for software with no floppy assumptions.

    Therefore I would expect that 5.25 floppy drives will be part of a common use-case with the Mega65 and this declaring them as "legacy" would not be justified. Therefore the desire for people to use fastload solutions like JiffyDOS looks justified to me and considering community activity around JiffyDOS I wouldn't be surprised if a Mega65 version would be developed.

    Nobody knows wether the C65 supports the burst mode of the 1571?

    The C65 ROMs are largely based on the C128 ROM, so I believe it should support burst mode when in C65 mode, but I can't immediately confirm that.

    Regarding accelerating the byte-by-byte routines in the ROM, I looked at making it pass a pointer to the sector buffer and/or copy ~30 bytes at a time in the little transfer area it uses at the top of the 2KB colour RAM. I got part way through, and ran out of time. The nice thing is that this fix would be totally compatible, and also would work on a real C65, to give about 5x - 10x speed up for LOADing, from ~1KB to more like 10KB/sec. On a MEGA65 it would go from about 16KB/sec to around 100KB/sec, which is currently the limit of the SD card interface (although I plan to improve the SD linear read speed to ~1MB/sec).

    I think the rest of the questions have been answered by others?

    Paul.

    But the work of migrating software to a non-1541 kind of drive has already been taken care of. Look for software modified to run on the sd2iec or the 1581.

    Also if I take a look around at demoparties, I didn't see anyone using a disk drive any more. 1541-ultimate or Chameleon are used with disk images. Even for the the C128 with burst mode there is a patched version of the sd2iec for that.

    “Nobody knows wether the C65 supports the burst mode of the 1571?”

    Sure we do. Take a look at: https://github.com/MEGA65/c65-…ster/c65manualupdated.txt

    The chapters starting at lines 13586 and 13657 state the burst load exists, but burst save doesn't.

    Nevertheless, I can see the desire for wanting JiffyDOS or something alike. (I'm asking for parallel cable support in the Chameleon constantly, to get SpeedDOS/DolphinDOS running.) But this should be something that can be taken care of as a community effort after the release. Something like a github-repo containing different flavours of the firmware, as there are a lot of ways the kernal can go, as the mass of patched C64 kernals shows...

    @Chris3: well I wouldn't call that "flash" since the target is after all RAM from the pointview of M65, just for C64/C65 it's "ROM". But never mind, it's just the notions. As far as I know (Paul can answer this much better for sure ...) it's planned to have different configurations, and allow the user to press keys 0-9 (or such) during the boot to select some pre-defined one ... or so .... As for the M65 itself, you can even use all memory (including the area what would be "ROM" for C65 and/or C64) as normal RAM, if you need such amount of RAM for an M65 software project for example ...

    :: @LGB added on 28 Jun ’17 · 17:40

    The other reason, I would not call this 'flash', as ROM is always loaded at every "boot" of the machine, since it has no "real" ROM from the technical point ...

    Yes, the hypervisor on the MEGA65 already lets you have 10 different ROMs, and pick which to load by holding 0 through 9 down on poweron. This loads MEGA65X.ROM from the SD card instead of MEGA65.ROM.

    You can also just make a program that loads in a ROM from a disk image, asks the hypervisor to disable write-protect on the ROM area, copies it back in, asks for write-protect to be restored, and then jumps to the reset vector.

    Paul.

    I've been thinking a bit about the reasons why and when I am using real floppy disks. I like my 1541U2 and for sure devices like this are an essential component of modern use of Commodore computers. I have a dedicated desk for my C64. If I take it to the living I usually leave the physical floppy drives upstairs. 1541U2 is often fine for such purposes.

    As you might have imagined, I am using a 1571. My good old 1541-II still works fine, but the 1571 is a nice upgrade. There is Jiffydos inside, but my C64 has the original ROM. I can use JiffyDOS on my C64 with the custom kernal feature of the 1541U2, but I often limit myself to the Final Cartridge III fastloader, it is faster than JiffyDOS. So the JiffyDOS in my 1571 is largely unused, except for one crucial feature: Autodetection of single and double sided disks. If you no longer need to switch the drive into double sided mode to read a double sided disk, double sided disks suddenly become much more usefull, and suddenly the 1571 is a real improvement over the 1541.

    I often use real floppies in the following situations:
    * Software on floppies, I have hundreds of them and regularily use them
    * Allthough I agree a lot of software has been fixed for modern storage media, there is also a lot of software that hasn't. Even modern demo's like Comaland assume a 1541, don't run from device 9 and even don't tolerate any other device than device 8 on the bus. While the 1541U2 is 100% compatible, you need to reconfigure it (turn off second drive, turn off IEC device, turn off printer, switch it to device 8), it is much more convenient to use the real floppy drive: Switch on, pull cable from 1541U2, run demo.
    * The 1541U2 is a 1541 simulator, so single sided only. Double sided work therefore always on real floppies.
    * Demonstration purposes. Many people are too young to have known 5.25 floppies. If you demonstrate your C64 to someone, it works a lot better if you can show a real floppy drive with real floppies. You show what computing really was in the 80's.

    Not everything here translates to a Mega65, but I'm convinced that if I will have one, I'm going to connect a real floppy drive. With burst mode supported, even if just for load, it looks like the 1571 is a good match for the Mega65 and without an urgent need for JiffyDOS.

    When I look at my C128 and JiffyDOS, I see that fast serial feature of C128 is enough for speed, only one drive JD really needs - it is 1541. C65 and M65 features fast serial too, only C64 has problem. I don't understand why is 1541 so popular...SSDD 170K with turtle speed. Ok, for C64 mode of C128, C65 and M65 is JD good shell extension for Basic 2.
    Really it's old Basic version, but when I read posts about JiffyDOS, it looks like C128 fate - C64 mode limited it by hardware and native software. I don't want that M65 will be used for C64 mode only... I know that you all will be angry, but look forward and see M65 mode with all enhancements and understand that C64 is not king anymore. It's my own opinion, so kill me if you want.
    Miro

    “only one drive JD really needs - it is 1541.”

    Agree, but JD's auto detection of double sided floppies really makes the 1571 a lot more usefull in combination with the C64.

    “I don't understand why is 1541 so popular...”

    The 1541 is so popular because it was so popular in 80's. It was so popular in the 80's because of economical reasons: Joe Average could own a computer with a real floppy drive. Single sided floppy's were no major space limitation for a lot of C64 software and therefore flipping disks to access the backside was acceptable. The speed limitations were annoying but could be easily circumvented by fastloaders.

    It fact, I believe the 1541 was a major contribution to the C64's vast and rich software catalogue. Games on floppy disks could be significantly more complex than games on tapes, this gave the C64 an advantage over many of its competitors.

    “I don't want that M65 will be used for C64 mode only... I know that you all will be angry, but look forward and see M65 mode with all enhancements and understand that C64 is not king anymore.”

    Well, the advantage of the C65 has over the C128, is that hardware wise, all functionality is available in C64 mode. When the C128 switches to C64 mode, it basically is a C64, very few C128 functions can be accessed from the C64 more. Therefore C64 games could not be enhanced with C128 features, you had to do a full rewrite for C128 mode. With the C65 this is not the case: You can for example use all functionality of the VIC-III in C64 mode.

    Of course, software written for C65 mode would be the perfect world, but rewriting software for C65 mode needs significant resources and the question is if the community will have enough of those resources. Enhanced C64 software needs much less resources from the community and could already make the Mega65 a success from a software library point of view.

    I completely agree with you Daniel. The line between C64 and C65 mode is really a case of which version BASIC you see when you load the program. After that, it is completely irrelevant. Given the lack of C65-mode software library and bugs in various versions of the C65-mode ROM, I suspect that the default will be for MEGA65 software starting in C64 mode. But also agree that it would be nice to see some software that starts in C65 mode, or at least that takes good advantage of the VIC-III/IV features etc.

    Btw, what's about emulation of an 1541 (? or other drive(s) ?) in FPGA on M65 (optionally, with keeping external IEC drive possibility as well, of course)? After all, 1541 Ultimate is also an FPGA, and if I remember correctly the HDL source is GPL in fact. Though I don't know if there is enough spare space in Artix-7 for this too ...