Topic: Miscellaneous topics, mainly floppy disk support

Trying to clean-up a little.

Moved to here everything not covered by the other topics or
posts simply not to discussed there. Nothing removed, of course.

/WoS

Re: Miscellaneous topics, mainly floppy disk support

wolfgang wrote:

darrin, funny is I also thought something like a v20 extension would be more appropriate when I did add the menu wink

LOL.

Quick question, did you get the email I sent you yesterday about sharing the information about this core on another website?  I think it would be of interest to others.

Cheers.

Re: Miscellaneous topics, mainly floppy disk support

Personally I don't mind sharing info, but I would prefer a link back to this thread.
/MikeJ

4 (edited by darrin 2014-01-26 16:04:32)

Re: Miscellaneous topics, mainly floppy disk support

Absolutely Mike.  More advertising = more sales (hopefully) and more developers/users.

I'll wait for an OK from Wolfgang first as he might get more questions from new subscribers as a result.  smile

PS.  Mike, did you get the PM I sent you about a second board and updating my current one?

Re: Miscellaneous topics, mainly floppy disk support

I don't think so - what did you use, email or the contact form?

Re: Miscellaneous topics, mainly floppy disk support

The EMAIL button on this forum below your name.  Unfortunately it doesn't say which address it sends it too.

Re: Miscellaneous topics, mainly floppy disk support

Sorry... you're not the first to think that v20 extensions were for the VIC-20.  These are for the v20 terminal emulation.

Re: Miscellaneous topics, mainly floppy disk support

No prob Jim.  Like I said, comedy isn't my strong point.  big_smile

Re: Miscellaneous topics, mainly floppy disk support

darrin wrote:

Quick question, did you get the email I sent you yesterday...

After a second look: yes I got it, just missed it between the update messages from the forum which ends up on the same account, sorry... sad

/WoS

Re: Miscellaneous topics, mainly floppy disk support

Thanks Wolfgang.  I'll make a post and link back here.  Meanwhile, thanks again.  I'm really looking forward to playing with this core.

The first computer I used was a PET 4016 at school and then I ran home and asked for a computer of my own.  I got a VIC-20, cassette drive and a second hand black & white TV.  Ah, the fun of playing Blue Meanies...

Re: Miscellaneous topics, mainly floppy disk support

d64 files might work ok for the VIC-20 core, but they won't provide much use for a C64 core.  I confirmed with Mike that he is planning on making flux a standard function of the disk controller emulation for the various cores.  This gives us 100% compatibility for all disk formats for all cores. 

Where is Mike's 6522 core?  I would like to see if you he added the known bugs in the 6522 that some floppy protections actually use.

12 (edited by WoS 2014-02-03 23:04:00)

Re: Miscellaneous topics, mainly floppy disk support

Hmmm, I am using VICE and other emulators for C64, and I still use a "real" C64 and a C128D with a SD2IEC.
All games and CP/M programs I have (and more than I am ever able to play or use) are in d64 format and most of them work nicely - at least for ordinary users like me... wink

Frankly, I am not aware of any other such commonly and widely used format like the d64 for the C64 and C128 (which you can easily find on all this web pages around).


But of course in future a lot of things are possible, and no doubt that Mike can do that. I also agree that it would be nice to have such a setup.


I can only speak about what I am going to do:

Fact is, actually the framework is still Amiga-specific and only handles ADF files. So the next step is to support a generic block-based setup for FD and HD content. Mike currently works on that and we had some aligment on the setup.

Up to now I had to set up my own (simplified) read-only framework to do some testing (I think it works really nicely) so a  generic block-based handler is an important next step.

Such a generic setup allows me to finalise my generic 1541 drive on Replay, which will support reading and writing d64 files, as all the other well known implementations I found do. By the way, I finished today a stand-alone 1541 FPGA setup with on-the-fly write support for d64 as well (not yet embedded in Replay, just tested in simulations).


This 1541 drive can be used independently of VIC-20 - for a C64, C16 or whatever other commodore computer one might implement in future and of course where d64 files are available.  If more than this is needed, time (and user requests) will show. If there is someone keen to add further formats/features in parallel is of course always welcome big_smile



The m6522 is included in the VIC core source tree as it was in Mikes original distribution, didn't put them yet on the generic lib section (as I have not tested it in a generic fashion).

/WoS

13 (edited by JimDrew 2014-02-04 00:45:31)

Re: Miscellaneous topics, mainly floppy disk support

It's extremely rare for people to use d64 format for emulators like WinVICE, CCS64, and Hoax64.  Most everyone uses g64 images so that copy protected (non-cracked) games and utilities will load.  g64 won't work for many types of programs though.  The SD card solutions are not that popular, at least in the U.S. because they are too difficult to manage.  This is why Gideon's device is so popular - it supports g64 files, but it has some bugs still - like emulating both VIA timers (something that several custom disk loading routines require to function).  I am writing a cycle exact 1541 emulator for the SuperCard Pro board.  You will be able to use flux images (or g64 files) to read/write disks just like a real drive.  This is the goal that Mike and I chatted about for ALL of the cores with ALL disk formats.  If you build support for flux for one, they all work.

Re: Miscellaneous topics, mainly floppy disk support

Years ago I had a 'working' on-chip 1541 emulator that I tested both with FPGA64 and a real C64. At that point it utilised a soft-core NIOS to read an image from SD card on the Altera DE1.

Anyway, my point is that if you want to support D64 files on a system that was designed to read g64 files, then it's generally a simple matter to re-construct the G64 data on-the-fly as the D64 image is being read. In fact, this is what I did (at least at some point) in my implementation, using the information gleaned from the MESS driver on the G64 format.

I'm also wondering if you could go one step further, and implement a flux-level emulation, that was in turn capable of constructing the flux data for a G64 image, and the G64 data for a D64 image!?! That way everyone is happy!?!

Food for thought...

Re: Miscellaneous topics, mainly floppy disk support

This is what Mike and I have been discussing.  We have the ability to make exact flux level images, and these are being used in other programs already (like HxC).  The image files are the same format no matter what type of disk was imaged, so the mechanism for feeding the data can be the same for all cores.

16

Re: Miscellaneous topics, mainly floppy disk support

Handling G64 is less easy in HW than D64 and will require specific ARM FW to handle. Thus I went for D64 for now.
No question, a "target-independent" floppy format would be a much nice generic approach and would require only once some ARM FW extensions valid for all cores.

/WoS

17

Re: Miscellaneous topics, mainly floppy disk support

JimDrew wrote:

d64 files might work ok for the VIC-20 core, but they won't provide much use for a C64 core.

I want to put my priority on file formats which are commonly used and fixing the core in general. I am not (yet) focus on the (maybe) technically best format to use (which is another valid approach, but simply not mine as I see it less practical to start with). So I also won't spend time yet in discussing if format "XYZ" is better than "ABC" as long as so many other things are to finalise.

I am a friend of facts and not opinions, so I did some statistics on TOSEC and other available catalogues to get some numbers to compare (like the size of DAT packages in TOSEC and so on) about relevant formats people prepared and can easily find on the web and use on the cores.

The "hitlist" is for the VIC-20 is:
CRT followed by PRG followed by D64

The "hitlist" for C64 is:
D64 followed by T64 followed by PRG

In terms of availability of files people can use,  g64 is far off on this lists , flux formats are rarely mentioned. So if the framework can support D64/ADF for floppy media and CRT/PRG/BIN for "binary" media, it supports already the biggest junk of available files people can grab and use with the cores, which is just fine as a starting point. Just for completeness of the core itself, I am adding a tape streamer block and proper tape format as well (and it is an important step towards support of T64).

Everything else is still a nice to have for me, especially as there is still some serious work to do on the framework and of course on the core itself (bugfixing).    By the way: on amiga side, I got out that the ADF files have the highest rank.

/WoS

18 (edited by JimDrew 2014-02-10 20:16:37)

Re: Miscellaneous topics, mainly floppy disk support

You are looking only at cracks.  Let's face it, no company released unprotected software.  Cracks often times are buggy and slow compared to an original disk.  This is why at very least g64 images are preferred.

Also, since the FPGA Arcade system is an emulator (not a simulator), it makes sense to have hardware-level support just like the real hardware was.  smile

Re: Miscellaneous topics, mainly floppy disk support

jimdrew, quite the contrary on the c64 actually. crackings crews often fixed bugs in games and added fastloaders.
i am totally with you wolfie, d64 is what people use.
on the amiga dms is very common as well. that would be a nice bonus to have.

Re: Miscellaneous topics, mainly floppy disk support

(dms might not be common in emu collections on websites, but in peoples real amiga archives, dms is by far the most common way to store trackloaded disks).

21

Re: Miscellaneous topics, mainly floppy disk support

JimDrew wrote:

You are looking only at cracks.  <..>
Also, since the FPGA Arcade system is an emulator (not a simulator)

Topic 1:
There are motivated peoples behind this preservation communities. You say they are only collecting cracks? Your opinion, not mine. And it is not the topic here.

--> There are tons of demos, games and magazines without copy protection. I have a lot of them myself as original disks. Plenty of stuff to start with and try out the implementations for the Replay board. It's "food for the masses".

And I already set up my own small test programs on the PC using a cross compiler and generating d64 files I can load to check out and test functions of the vic-core. This is because there are also tons of tools to create such formats directly.

And the existing 1541 on the Replay will definitely help as starting point for a C64 development as well - and one doesn't need to start from scratch here.

--> I really showed my interest on this flux file and asked for examples, up to now I have not got any. Anther reason to stick on my actual approach on the 1541 to support first what is really out there and easy to catch.

If I can get any useful (and concrete!) link as alternative to tosec, gamebase & co (with real information and plenty of alternate file content like such flux files I can use for development) --> welcome. wink

Topic 2:

For me an emulator is something like VICE, MESS etc. when HW is modeled on software basis. Even if Replay is also an (HW-)emulator, I like the slogan "no emulation, no compromise". And it is a nice statement of the final goal and to have some way of differentiating the approaches.

As I said, many of these media formats are made in a way to easily work for this SW-emulators, not considering "direct" handling in HW. This makes it hard to directly support them without using yet another embedded CPU on FPGA or a uC beside the FPGA (which I don't really like as it adds another FW development part to the core). So I also took what can be done the easy way first.

By the way: do you notice you are the only one complaining what is NOT available, and I am sure you didn't even try out yet what IS already available? There are so many things to get done, what is your problem with just taking one step before the other?


spotUP wrote:

jimdrew, quite the contrary on the c64 actually. crackings crews often fixed bugs in games and added fastloaders.
i am totally with you wolfie, d64 is what people use.
on the amiga dms is very common as well. that would be a nice bonus to have.

Amiga is a different story, I agree. And I am not involved in this scene.

But in principle it is the same: start with one to have a starting point to work on. Then improve step by step. I'd prefer to have an Amiga with ADF I can already try out than discussing an Amiga supporting the perfect format which will definitely take much more time to get it.

I never said that D64 its the end of the story. So I don't see JimDrew's point. Of course his proposal is probably the best way for a final solution, but it is for me simply not the most urgent topics to work on.

/WoS

Re: Miscellaneous topics, mainly floppy disk support

spotUP wrote:

jimdrew, quite the contrary on the c64 actually. crackings crews often fixed bugs in games and added fastloaders.
i am totally with you wolfie, d64 is what people use.
on the amiga dms is very common as well. that would be a nice bonus to have.

I disagree.  Look at what I did for the C64/128.  I made programs that duplicated as well as removed protection checks in *thousands* of programs, but you still need the disk structure intact.  A d64 image is just sectors in sequential order.  In order to have games stored in this format, they have to be cracked into loadable files, no longer in their original format.  I was a "cracking crew", so I know exactly what is required to do this and what happens to the compatibility when you add fastloaders to systems already having one, and/or other other speed enhancement hardware, REU, carts, etc.  Cracked programs lose compatibility of the original disk, and almost always occupy more disk space requiring compression (those colorful flickering lines during decompression) to get it to fit.  This takes away from the original experience.

The purpose of an emulation is to emulate a system exactly.   Anything else is a simulator, which is fine if that is what your goal is.  I know Mike's goal is for 100% compatibility, which is why FPGA Arcade will be *the* system to have.

Re: Miscellaneous topics, mainly floppy disk support

wolfgang wrote:

--> I really showed my interest on this flux file and asked for examples, up to now I have not got any.

I gave you a link to the developer area on my website.  It contains the structure of the flux format file.  I can give you some image files to experiment with as well.


wolfgang wrote:

I never said that D64 its the end of the story. So I don't see JimDrew's point. Of course his proposal is probably the best way for a final solution, but it is for me simply not the most urgent topics to work on.

Having D64 support is nice.  It works well for WinVICE and other emulators, but even those have G64 and P00 (psuedo-flux).  I was under the impression from your statements that D64 is all you intended to support.


wolfgang wrote:

If I can get any useful (and concrete!) link as alternative to tosec, gamebase & co (with real information and plenty of alternate file content like such flux files I can use for development) --> welcome.

The reality is that anything in a file format that you don't own is illegal, at least in North America and Australia.  I am not sure about the copyright laws in Europe.  Copyrights last the life of the author plus 75 years.  So, posting a file of a crack or even original flux image is a felony crime in the U.S.  So, you don't see the sites that hold these images published anywhere because of it.  The DMCA in the U.S. allows for someone to make a backup copy of any software that is no longer in production as long as the copy protection mechanism is not circumvented (cracked).  A flux copy of course makes an identical copy.  However, the copyright does not change.  You are still not allowed to give away or sell any copies.  You can only have them for backup and personal use.  This is a fact that needs to be heavily stressed with FPGA Arcade, because it could be a legal issue otherwise.

Re: Miscellaneous topics, mainly floppy disk support

there are plenty of sites that hosts games with permission from the authors... let's not go into this boring discussion shall we?...

Re: Miscellaneous topics, mainly floppy disk support

In my opinion (others may disagree) supporting a new low level format is a good idea, but after the more commonly used formats are in place. Wolfgang is waiting for me to fix the file interface, which I am working on now.

"I never said that D64 its the end of the story. So I don't see JimDrew's point. Of course his proposal is probably the best way for a final solution, but it is for me simply not the most urgent topics to work on."

Absolutely.

I really like the elegance of streaming low level flux data directly into the FPGA, shaped so it is at the same rate as the rotating oxide - this is as close to the real thing as we can get chaps!

Anyhow, back to work on ADF support...
/MikeJ