|Come for the quick hacks, stay for the epiphanies.
Re: Commodore disk image processor thingyby rje (Deacon)
|on Sep 04, 2014 at 21:17 UTC
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:
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!)