Transparent D64->ZipCode upload would be great, so when uploading one could select a d64 and have it sent in ZipCoded format. (The reverse - converting ZipCoded to D64 after download wuld be great as well I presume)
I'm not sure how this would actually work out or why it's a good feature... C64 BBSs only? Look at file extension or something? Why do you not want to upload D64 files and why would you not want ZipCoded files on your system?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On pc, d64 is the normal format to represent c64 disk images. However you
cannot host them on the C64 itself as they are too big to store on a disk
(obvious).
So to c64 BBSes, full disk images are uploaded in Zipcode format.
Zipcode is useless on the PC and d64 is unmanageable on the C64.
I'm not sure how this would actually work out or why it's a good
feature... C64 BBSs only? Look at file extension or something? Why do you
not want to upload D64 files and why would you not want ZipCoded files on
your system?
Status: open Group: Next_Major_Release Created: Wed Jun 14, 2017 06:27 AM UTC by Pontus Berg Last Updated: Wed Jun 14, 2017 06:27 AM UTC Owner: nobody
Transparent D64->ZipCode upload would be great, so when uploading one
could select a d64 and have it sent in ZipCoded format. (The reverse -
converting ZipCoded to D64 after download wuld be great as well I presume)
Heh, I'm planning on doing the final 1.x release this month, so I'm looking into features for the next major version.
So I'm a bit confused as to why Zipcoded files would be useless on a PC... PCs should be able to use them with minimal overhead, and barring that, it should be trivial to convert to one or the other, but if the tools don't support it, I'm certainly not going to go fixing them all. :D
So the concept would be that when connected to a C64 BBS, any time an upload of a D64 or a download of a Zipcoded file (detected by extension?) would trigger an additional popup asking if you want to translate the format? Or do you imagine it as being a global setting and it doesn't bother you at transfer time?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Digging in a bit more, it seems like ZipCode is actually multiple files, so it would require the C64 BBS to support batch uploads... is that a reasonable assumption?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unless the emulators would start supporting transparent convert and depack
of ZipCode files, they are an extra hassle. You can't use them without
conversion and that is an annoying hassle. So "useless" is possibly not the
right term "stupidly annoying" would possibly be better ;-)
In all; ZipCode makes sense in a native c64 environment - d64 makes sense
in the pc/mac/linux world. The time they go back and forth is when they are
uploaded from a PC/mac/linux unit to a BSS and this is where the terminal
program is the tool.
And yes, ZipCode converts the disk to 4 or 5 files so it would need to be
some sort of batch upload logic in there as well.
Digging in a bit more, it seems like ZipCode is actually multiple files,
so it would require the C64 BBS to support batch uploads... is that a
reasonable assumption?
Status: open Group: Next_Major_Release Created: Wed Jun 14, 2017 06:27 AM UTC by Pontus Berg Last Updated: Thu Mar 05, 2020 04:18 PM UTC Owner: nobody
Transparent D64->ZipCode upload would be great, so when uploading one
could select a d64 and have it sent in ZipCoded format. (The reverse -
converting ZipCoded to D64 after download wuld be great as well I presume)
So batch logic for the upload is easy enough, but I suspect most C64 BBSs don't support batch uploads... I can't really think of an interface where it would be significantly better than an external utility. The sort of hacks I'm imagining now are like this...
For uploads, when you select a D64 upload, it prompts for Zipcode conversion and uploads the first Zipcode file instead, leaving the next three or four on disk, and they get deleted as they're uploaded(?) Or it leaves them on disk and prompts to delete after the last is uploaded or something.
For downloads, it looks to see if there's a "matching" set, prompts for a D64 filename, combines them and (optionally) deletes them.
It just feels really clunky to me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure how this would actually work out or why it's a good feature... C64 BBSs only? Look at file extension or something? Why do you not want to upload D64 files and why would you not want ZipCoded files on your system?
That was a late answer ;)
On pc, d64 is the normal format to represent c64 disk images. However you
cannot host them on the C64 itself as they are too big to store on a disk
(obvious).
So to c64 BBSes, full disk images are uploaded in Zipcode format.
Zipcode is useless on the PC and d64 is unmanageable on the C64.
On Thu, 5 Mar 2020, 05:49 Stephen James Hurd, deuce@users.sourceforge.net
wrote:
Related
Feature Requests: #6
Heh, I'm planning on doing the final 1.x release this month, so I'm looking into features for the next major version.
So I'm a bit confused as to why Zipcoded files would be useless on a PC... PCs should be able to use them with minimal overhead, and barring that, it should be trivial to convert to one or the other, but if the tools don't support it, I'm certainly not going to go fixing them all. :D
So the concept would be that when connected to a C64 BBS, any time an upload of a D64 or a download of a Zipcoded file (detected by extension?) would trigger an additional popup asking if you want to translate the format? Or do you imagine it as being a global setting and it doesn't bother you at transfer time?
Digging in a bit more, it seems like ZipCode is actually multiple files, so it would require the C64 BBS to support batch uploads... is that a reasonable assumption?
Stephen,
Unless the emulators would start supporting transparent convert and depack
of ZipCode files, they are an extra hassle. You can't use them without
conversion and that is an annoying hassle. So "useless" is possibly not the
right term "stupidly annoying" would possibly be better ;-)
In all; ZipCode makes sense in a native c64 environment - d64 makes sense
in the pc/mac/linux world. The time they go back and forth is when they are
uploaded from a PC/mac/linux unit to a BSS and this is where the terminal
program is the tool.
And yes, ZipCode converts the disk to 4 or 5 files so it would need to be
some sort of batch upload logic in there as well.
https://ist.uwaterloo.ca/~schepers/formats/ZIP_DISK.TXT
There is always the opportunity to include an external tool for the actual
conversion. I believe this one works:
https://sta.c64.org/starzipdoc.html
/Pontus "Bacchus" Berg
FairLight concil...
Den tors 5 mars 2020 kl 17:34 skrev Stephen James Hurd deuce@users.sourceforge.net:
Related
Feature Requests: #6
So batch logic for the upload is easy enough, but I suspect most C64 BBSs don't support batch uploads... I can't really think of an interface where it would be significantly better than an external utility. The sort of hacks I'm imagining now are like this...
For uploads, when you select a D64 upload, it prompts for Zipcode conversion and uploads the first Zipcode file instead, leaving the next three or four on disk, and they get deleted as they're uploaded(?) Or it leaves them on disk and prompts to delete after the last is uploaded or something.
For downloads, it looks to see if there's a "matching" set, prompts for a D64 filename, combines them and (optionally) deletes them.
It just feels really clunky to me.