Commodore disk image processor thingy

[rje]

Dear Perlmonks,

I wrote a Perl library, and I think it's pretty cool, but I'm also asking your opinions about it - is it worth putting on CPAN, for instance.

It is a pure-Perl library for handing Commodore disk images. For those needing a refresher, these are digital images of diskettes and hard disks used by Commodore computers in the late 1970s thru the 1980s.

It's hosted inside my network, behind my modem's firewall, by my Raspberry Pi running a cheapo web server I wrote (also in Perl) specifically for the purpose of serving and manipulating Commodore disk images.

My library handles D64, D71, D81, D67, D80, D82, and X64 image types. Each format is a little package (about 8k) with data specific to that image. I made them packages, although I could have just used parametric data. These packages are essentially parametric data anyhow, and provide context to a generic engine that knows how Commodore disk images work.

The library is 140k (includes good POD documentation, which is rare for me) split among about 20 files.

First, is it worth posting to CPAN. It's awfully specialized. Maybe it would be better just to post it as a tarball on a website (or github?).

Second, it's been nearly 10 years since I've uploaded to CPAN, and I am intimidated by the process. Yes, I've read the rules, but I'm concerned about uploading 20 related files in one batch. Anyone have any advice beyond what PAUSE has to say?

Thanks for listening.

[ww]

Upload? Emphaticly, yes!

Recently ran a fairly wide search for readable (bootable) OCC (Osborne 1) floppies, either SD or DD. That convinced me that there are many "antique 'puter buffs" out there. Some of them might even be induced to look into Perl with a headstart like that.

And, BTW, got a set that's supposedly good... and a (+/-) month later, still have not had the opportunity to test that.

[DrHyde]

We've already got 6502 and Z80 emulators on the CPAN, so uploading stuff for dealing with obsolete computers won't exactly be new. And rather than asking "why should I upload this to the CPAN", rather ask "why shouldn't I"? And if you can't think of any good reasons, go ahead. So what if only a tiny number of people find it useful. Only a tiny number find the 6502 and Z80 emulators useful too. Finally, only 20 files? Have you looked at distributions like Moose, or Number::Phone? A bunch of related files in a tarball is normal.

[AppleFritter]

By all means, go ahead and upload this! It sounds like a great module to have on CPAN. I don't see any upside to posting it elsewhere instead: CPAN is all about discoverability and ease of installation, and putting them on a random website, github or so wouldn't help with either. When was the last time that you, when needing a certain Perl module, turned to Google rather than (meta)CPAN?

And 20 files shouldn't be a problem at all, either, so long as you upload them all in one bundle (DiskImage::Commodore or so, and no, I'm not recommending that specific name).

Go for it! I'm sure your contribution will be greatly appreciated by fellow enthusiasts.

[rje]

Okay, thank you all for your support. This is really refreshing and exciting, so I'm going to do it!

That means you guys can help me one more time :)

There's another Perl guy I've talked to about these modules (Paweł Król) who has written a library (D64::Disk::*) that uses Per Oloffson's C library. We batted around NAMESPACES a bit, and agreed on a package namespace for my stuff. BUT due to your helpfulness so far, I think a wise move would be to ask your opinions as well.

The package structure we like is:

Commodore::Disk:: * (7 common packages go here)
Commodore::Disk::Format:: * (8 format-specific packages go here)

The "common" packages have code that can read and write any Commodore disk image headers, directories, the BAM, handle entire images, extract sprites, and so on.

The "format-specific" packages each contain parametric data that describes the disk topology of a particular image, with two exceptions. The first exception is a package supporting the "X64" format, which by definition may itself encapsulate any valid Commodore disk image. The other exception is a package which manages CUSTOM disk images.

The "Commodore" namespace could grow, for example to support tape drive emulation, a driver to communicate with the C64's RS-232 port or the user port, and so on. I'm pretty sure Commodore doesn't have generic hardware, hence justifying the namespace.

Similarly, the "Commodore::Disk" namespace could grow, for example if somebody writes a package that interfaces with the Raspberry Pi kernal hack that does Commodore disk I/O via its GPIO pins. Yes, I'm thinking about it.

Anyhow, I've babbled on too long, and by now I've bored you with the obvious: the package structure. Anyone have some good constructive criticism for me?

Thank you all again. I appreciate the feedback (and of course I've really liked the positive feedback!)

[ww]

"Commodore::Disk::Format:: * (8 format-specific packages go here)"

Perhaps trivially better?       s/Format:: */Formats:: */

"Format", in the singular, in US-ian English is ambiguous: it can refer to a particular schema for organizing a data-holder (floppy, HD, RAM-disk, thumb-drive, etc) but it can (and often does) refer to the act of "formatting" a disk. The added "s" would reduce the ambiguouity (I think), and more closely suggest your intent to provide "format-specific packages".

[frozenwithjoy]

I've also been timid about submitting to CPAN. I received good feedback (and a confidence boost) by first posting the synopsis/description/etc. of modules to PrePAN.

[rje]

I'm a chicken when it comes to pushing content to CPAN. I am intimidated, not so much by the process, but by wanting to only push the absolute best code I can. And I'm not convinced this is that.

So it's going to take thought and some careful tweaking.

On the other hand it was trivially easy to post the code to my GIT repo. After all, THAT is a glorified workspace.

https://github.com/bobbyjim/CMD-images