8bitfiles.net/archives

home *** CD-ROM | disk | FTP | other *** search

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / CAT7-940127B.SFX / 02cat7 next >

Wrap

Text File | 1990-02-12 | 33.5 KB | 892 lines

Baudville called Blazing Paddles that used this technique. ------------ Category 7, Topic 12 Message 43 Fri Dec 18, 1992 E.RAFANAN at 22:54 EST Yes, but (I'm assuming you're talking about the VIC screens) doesn't that really limit you to 4 colors in an 4x8 block - which really means when you're swapping color maps, you can only get up to 16 different colors in each 4x8 block? I'm just guessing, so let me know if I'm wrong. ------------ Category 7, Topic 12 Message 44 Sat Dec 19, 1992 CMD-DOUG at 04:02 EST Yes, I was only speaking of overall colors available. To do what you are saying would require a video interrupt for every bit, which I don't think is possible. An interrupt for each line IS possible, though, so using multicolor mode with color map swapping and raster line interrupts could yield a palatte of 240 with up to 128 different colors per cell. Only half of what you were looking for, but a far improvement over what you can get using static screen modes. ------------ Category 7, Topic 12 Message 45 Mon Dec 21, 1992 R.KNOP1 [Rob Knop] at 10:39 EST It is possible to get a raster IRQ interrupt at the end of each scan line on the VIC 40 column screen. (If I am not mistaken, this is how FLI works.) Is it possible to get an IRQ at the end of each VDC scanline? Since the VDC is able to do as small as 8x2 color blocks, (8 vertically if I remember correctly), you could get 320x200 resolution with each "pixel"'s color controlled independently. (Though I don't think there is enough memory even in a 64K VDC machine to hold the bitmap and all the color maps necessary for the 240 color mode. I think it's close, though.) -Rob ------------ Category 7, Topic 12 Message 46 Mon Dec 21, 1992 CBM-ED [e.g.bell] at 14:15 EST I don't think you can do that kind of raster work with the VDC Rob. The VDC doesn't generate any interrupts at all. The only thing it does do as far as I know is signal when it is moving the electron beam back to the top of the screen. But if it did, how could there be enough room in a 64K 128 for a 240 scheme and not in a 64K VDC? Not being sarcastic... I don't understand the logic either way, but especially not the latter. ------------ Category 7, Topic 12 Message 47 Mon Dec 21, 1992 CMD-DOUG at 21:10 EST According to a conversation I had with Loren Lovhaug many moons ago (back when IPAINT was being developed), it WAS possible to make changes at the end of each scan line. I don't know what kind of trick was used to do this, but perhaps someone could get in touch with Rick Kane to find out. ------------ Category 7, Topic 12 Message 48 Mon Dec 21, 1992 C128.JBEE at 21:26 EST I get an upcoming issue of TC-128/64 ;) Actually, there are a lot of tricks you can play with the VDC, including raster bars. Anyone seen the J.Litz demo? Actually, I experimented with this years ago, just isn't feasible in my opinion because you get the "flashies". Before I got bogged down in work I was experimenting with "dot" addressable color by narrowing the characters to one pixel x 2. The default screens on the A. for a lot of the early games was 320x200. You can store the information for a 320x200x8 (bitplanes) for a full color GIF. The problem is just displaying it. By using smaller characters and interlace it is possible to display a decent looking picture. I think a grayscaled 640x800 picture will look a lot better than a 320x200 "chunky" color GIF picture anyday. ------------ Category 7, Topic 12 Message 49 Tue Dec 22, 1992 R.KNOP1 [Rob Knop] at 01:33 EST Ed- Well, there is room for a 240 color screen if you limit yourself to using 8x8 color blocks. What I was thinking was 8x2 color blocks, 8 pixels vertically (the VDC does have such a mode, doesn't it? or is it 2 pix vertically?). Then, every scan line, switch your color map using some sort of fancy VDC IRQ technique that is probably not possible, and you can set the color of each horizontal pair of pixels independently of every other pair. (No more of this being limited to 2 or 4 or whatever colors in one 8x8 block.) This gives you an effective resolution of 320x200 independently addressable and colorable pixels on the screen. Now, the memory required for this scheme is 16K for the bitmap (assuming 640x200 bitmap), and 640x200/(2*8)=8K for each color map. To independently address the color of every pair of pixels, you need 8 separate color maps, which means 64K of color map memory alone. If you do go back to the limit of 8x8 color map blocks, then it is certainly possible, because you only need 16K or something like that for color maps. I was being ambitious. This is all talk so far, isn't it? :) JBEE: Re: 640x800 Greyscale looking better than "chunky" 320x200 color, it really depends on the image you are looking. If the colors vary slowly, and you have enough of them, sometimes looking at a 320x200 full color screen you wouldn't believe that the resolution is as low as it is. (For example, I once saw "Wing Commanader" on a 386 and was impressed that the quality of graphics were what the were on the 320x200 (or similar) screen.) On other pictures, it does look quite chunky and giving up the color for the higher resolution gains you a lot. Then, also, if the 640x800 isn't true greyscale, but rather 1 bitplane black and white graphics which have been dithered, you don't really have 640x800 resolution. And, some pictures dither far better than others. (Actually, it may just be that some pictures have been dithered better than others :) -Rob ------------ Category 7, Topic 12 Message 50 Tue Dec 22, 1992 C128.JBEE at 02:04 EST I should have said dithered B&W 640x800 :) ------------ Category 7, Topic 12 Message 51 Tue Dec 22, 1992 R.PATERNOST2 [Ray] at 20:43 EST In the FWIW department, I have GeoGIF, and it does an adequate job of displaying _some_ GIF pictures nicely. (I think it's the interlaced ones that it chokes on.) However, I'd be happy to get a GIF viewer that scrolls the picture like Paintview II from RUN magazine does: Scroll the picture with the mouse. ------------ Category 7, Topic 12 Message 52 Tue Dec 22, 1992 C128.JBEE at 22:43 EST Sounds interesting! ------------ Category 7, Topic 12 Message 53 Sun Jan 03, 1993 M.KIRBY2 at 10:03 EST My complaint about 128/64 GIF viewers is not about color or resolution, though of course there is always room for improvement. The problem is that most IFs are too big for the screen. I have a viewer for 64 mode that lets you load in different chunks of the picture but this is a long slow process and the farther you get from the top right corner the longer it takes. What I'd like to see, and I brought this up on Q-Link once, is a viewer that will load in the entire picture and then let you scroll around it. Perhaps it could use an REU if the files is to big to fit into memory at once. ------------ Category 7, Topic 12 Message 54 Sun Jan 03, 1993 C128.JBEE at 17:55 EST Maybe the best solution is to convert it to a native mode format like Basic 8 or Geos and then scroll around the picture. Best thing would be a ram device like a REU or Ramlink. I believe the delay when scrolling is from having to decode the color tables on the fly. ------------ Category 7, Topic 12 Message 55 Sat Jan 09, 1993 R.PATERNOST2 [Ray] at 15:14 EST I would be happy to see a program like "geo-GIF" that decodes the color as well. Of course, something that would convert GIFs to I-Paint format would certainly be as welcome! ------------ Category 7, Topic 12 Message 56 Sat Jan 09, 1993 R.KNOP1 [Rob Knop] at 20:33 EST Does anybody know where I can get ahold of the I-Paint format? I've looked in the libraries here, and didn't find it. If it's there, could somebody give me a file #? If not, where else could I find it? I do know where I can get the GIF format... depending on the I-Paint format, this should be a rather doable project, I would think. -Rob ------------ Category 7, Topic 12 Message 57 Sun Jan 10, 1993 C128.JBEE at 00:14 EST I uploaded a text file into Library #5 within the last two weeks or so ;) ------------ Category 7, Topic 12 Message 58 Sun Jan 10, 1993 R.KNOP1 [Rob Knop] at 13:38 EST JBEE- Got it, I'll take a look at it momentarily. Thanks, -Rob ------------ Category 7, Topic 12 Message 59 Thu Jan 14, 1993 R.KNOP1 [Rob Knop] at 00:19 EST JBEE - The format file is just what I need. Also just got the GIF format, and will put some thought to writing a converter :) One other thing I need: the table of actually what color each of the 256 different combinations of color value gives. ideally, the table would give 8- bit R,G, and B value for each color, since that's what's tabulated in theGIF's :) I'll poke through the library to see if there is such a beast there. -Rob ------------ Category 7, Topic 12 Message 60 Thu Jan 14, 1993 B.VRIELING1 at 19:52 EST Rob, A note on converting the colour within GIF's to the C128 colour format: Converting between two different 'resolutions' of RGB colour is not difficult (ie. finding the 128 colour closest to the one in the GIF). One can think of the different amounts of colour as directions in three space. Suppose we label the RGB colours for a point in the GIF R1, G1, and B1 (they will each have a specific value taken from the GIF). Now, take all 16 of the C128's colours for the 80 column screen (look up their RBG component values in the PRG) and compute (for all of them): (R1-R)^2 + (G1-G)^2 + (B1-B)^2 ...where R, G, and B are the component values for the C128 colour. After you compute this for ALL 16 colours, you will have 16 corresponding values. The SMALLEST one is the C128 colour CLOSEST to the original one in the GIF. Mathematically, the above is a distance equation, and we're computing the distance between the GIF colour, and all the C128 colours. The three axes are the three different colours. The smallest distance is the value that is the closest in actual colour. (Mathematicians will comment that you should ROOT the above equation, but squaring is a linear transformation, so the smallest answer to the above would yield the same colour as the smallest from a set of rooted values.) Gee, this math/cs major has its uses, eh? ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu Fido: Bruce Vrieling @ 1:229/15 ------------ Category 7, Topic 12 Message 61 Thu Jan 14, 1993 C128.JBEE at 23:14 EST Almost makes me want to go make to school for a degree ;) ------------ Category 7, Topic 12 Message 62 Fri Jan 15, 1993 R.KNOP1 [Rob Knop] at 00:55 EST Bruce- Right, I've actually done stuff very much like that before. Basically all you're doing is least squares fitting :) I've even poked through some code that converts 24-bit color images to the Amiga HAM format, which uses basically the algorightm that you describe, although it's a little more complicated because the HAM format is sorta screwey. What I need to be able to do that, though, are the R, G, and B values for the 240 (or 256 or whatever) colors that can be displayed by I-Paint. Ideally, I'd like 8-bit values for R, G, and B, since 8-bit values are what you will see in GIF's. (And, of course, since that means there are 24 million different colors, the I-Paint images won't be able to keep the full fidelity of the original GIF.) Of course, there is also dithering to get better color... and that's something I know next to zilch about. I should try to find a good computer graphics book that says something about dithering. -Rob ------------ Category 7, Topic 12 Message 63 Sat Jan 16, 1993 B.VRIELING1 at 19:51 EST Rob, Hmmm. I'm with you on that one, as I know nothing about dithering either. If you do come across some useful info, could you send me email as to where I could locate it? It would be appreciated. :) ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu Fido: Bruce Vrieling @ 1:229/15 ------------ Category 7, Topic 12 Message 64 Tue Jun 15, 1993 M.KIRBY2 at 22:25 EDT I've been recieving lots of UU encoded GIFs lately but can't decode them. I delete everything before "Begin" and after "end" but I always get a file error. I encpoded a GIF I alredy had to compare and asside from capatalizing the "begin" and "end" it seemed the same. I'm using the UUXFER program, are there other's that might do a better job? ------------ Category 7, Topic 12 Message 65 Wed Jun 16, 1993 C128.JBEE at 02:01 EDT If you are trying to receive UU files through GEnie mail it will not work as far as I know. You would have to use xmodem to transfer the UU files. ------------ Category 7, Topic 12 Message 66 Wed Jun 16, 1993 R.KNOP1 [Rob Knop] at 09:35 EDT UUencoded files should work just fine through GEnie mail. I think GEnie doesn't like it when you do it :), but there should be no technical problem with it. UUencode was originally developed so people could send binary files through media (e.g. email) which only let you send ascii files (i.e. the whole point is that you don't need to use something like xmodem because you probably don't have it available :) ), and it is a fairly robust file transfer method. In my experience, Fuzzy Fox's uuxfer is pretty robust program. You do want to remove everything before the begin and everything after the end... sometimes people will break a uuencoded file into multiple chunkgs (i.e. multiple email messages) which need to be concatenated back together before the uudecode will work. My guess as to what your problem is is some sort of ASCII/PETSCII translation... this is because you mention the difference between the file you started with and the file uuxfer produced when _encoding_ is the begin and end in capitals. Are you using ASCII-PETSCII translation when downloading? If so, try turning it off, or downloading the file as Binary... to quote from the docs by Fuzzy Fox: First of all, I should think that anyone who does Telecomm work on C64's knows the problem of encoding with ASCII and PETASCII. UUXFER will ALWAYS ALWAYS ALWAYS encode its files in ASCII, and *NOT* in PETASCII! This means that when you upload the file, you must specify either ASCII or BINARY file transfer, or at least specify that you are turning translation OFF. I hope this is clear. When decoding files with UUXFER, the program should cope properly if you accidentally leave translation turned on, but I won't swear to that. It will properly handle end-of-line encodings of all kinds. Good luck. -Rob ------------ Category 7, Topic 12 Message 67 Thu Jun 17, 1993 HOWIE-CBM at 05:03 EDT Rob, Nope! UUxfer will only work properly when the file that it is going to UUdecode is in ascii, *NOT* petascii. This really should not be a problem for a 64 nor 128 user. Most all Terminal program with buffers, most all wordprocessors, and text editors offer the translation option of petascii <=> ascii. Therefore, if a UUdecoded file inadvertantly was translated into petascii, it can easilly be changed back into its UUdecodable form. Howie ------------ Category 7, Topic 12 Message 68 Fri Jun 18, 1993 R.KNOP1 [Rob Knop] at 22:27 EDT Howie- in that case, I expect that's what the problem is- the uuencoded file ended up in PETSCII. For 128 owners, ZED is probably the quickest and easiest way to convert between ASCII and PETSCII . -Rob ------------ Category 7, Topic 12 Message 69 Sat Jun 19, 1993 C128.JBEE at 03:00 EDT I would be interested in knowing how program files and picture files transfer in GEnie mail. I always thought the e-mail editor stripped none printing characters that could be part of a picture or program file. ------------ Category 7, Topic 12 Message 70 Sat Jun 19, 1993 CBM-ED [e.g.bell] at 09:27 EDT John: JB> I would be interested in knowing how program files and JB> picture files transfer in GEnie mail. I always thought the JB> e-mail editor stripped none printing characters that could JB> be part of a picture or program file. The editor does strip those characters, but UUENCODE translates binary files into files of all printing characters using who-knows-what kind of algorithm. End result is a file that can be transferred through a mail editor, all of which strip non-printing codes (or execute them somehow). I believe UUENCODE was developed for Internet, tho I'm not sure about that. ------------ Category 7, Topic 12 Message 71 Thu Jun 24, 1993 M.KIRBY2 at 23:33 EDT Thanks. Since I was using a commie program I just assumed it would use Petscii. I converted the files to ASCII and they decoded just fine. Thanks again. ------------ Category 7, Topic 12 Message 72 Sun Jun 27, 1993 HOWIE-CBM at 17:23 EDT You're welcome! :) Howie ------------ ************ Topic 13 Mon Nov 25, 1991 D.MCALEER1 [Micro-Bytes] (Forwarded) Sub: Howsabout an ASCII Art Converter? Hi all :) I'm curious if there is an ASCII art design program for the 64 or 128, or if there's a program that will convert a normal picture to ASCII art. Anyone? 2 message(s) total. ************ ------------ Category 7, Topic 13 Message 1 Tue Nov 26, 1991 C128.JBEE [* Sysop *] (Forwarded) There are Doodle to ASCII converters. There should be some uploaded about 3 years ago. If you can not find them e-mail me and I will upload the PD ones I have. There are also ASCII picture designers for the C-128 and C-64. Most convert PSA clipart to ASCII screens. ------------ Category 7, Topic 13 Message 2 Wed Nov 27, 1991 D.MCALEER1 [Micro-Bytes] (Forwarded) Thanks, JBEE. :) I'll do a quickie library check. \/\/\/ Paul /\/\/\ ------------ ************ Topic 14 Sun Feb 23, 1992 G.HOYLE (Forwarded) Sub: BASIC 8 CONVERTERS 2 message(s) total. ************ ------------ Category 7, Topic 14 Message 1 Sun Feb 23, 1992 G.HOYLE (Forwarded) Does anyone know of any converter for Basic 8 graphics files? I know nothing about Basic 8. ------------ Category 7, Topic 14 Message 2 Sun Feb 23, 1992 M.DULSKI1 [Mark @WIZARD] (Forwarded) Just left you a reply in CAT 11 TOP 1 about this. ;) ------------ ************ Topic 15 Fri Dec 18, 1992 E.RAFANAN at 23:39 EST Sub: Graphic Formats Would like info on various Graphic Formats. 7 message(s) total. ************ ------------ Category 7, Topic 15 Message 1 Fri Dec 18, 1992 E.RAFANAN at 23:41 EST Does anyone know where I can get info on the various graphic formats? I'm looking to make a viewer/converter. I know - there's PLENTY of those, but I like to know how things work. Thanks for any info! Eric ------------ Category 7, Topic 15 Message 2 Fri Dec 18, 1992 C128.JBEE at 23:47 EST Name the formats you want info on so we can point you in the right direction. :) ------------ Category 7, Topic 15 Message 3 Sun Dec 20, 1992 E.RAFANAN at 23:57 EST Well let's see.... How about starting out with the basics... Art Studio and Advanced Art Studio - I already know this format. (About the only ones I know! <grin>) Koalas Doodles Compressed Koalas and Doodles - what is the compression method used in these? RLE? Thanks! Eric Actually that's about all formats I really want to know about. Thanks again! ------------ Category 7, Topic 15 Message 4 Mon Dec 21, 1992 CBM-ED [e.g.bell] at 01:28 EST Eric: First GG and JJ files do use an RLE method to compress. Basically, whenever a number of the same bytes is encountered, a 254 is written to the file, followed by the number of bytes to follow, followed by the byte itself. I believe an actual file chr 254 is just preceded by a chr$(254). Doodle files are straight hi-res bit map format that you should be able to BLOAD to 8192 in the C128 and view w/a Graphic 1 command. Koalas are similar to doodle but include the information for a color map, a border color, and multi-color bit-map info as I recall. I worked with them in the distant past and don't really remember too well where everything is moved to, but the files are stored together and separated by the viewer into the components, the color stuff poked to the required area. PrintShop graphics are little blocks of hi-res information you could just poke into memory to view with the right code. There are 2 sizes, you would have to read them in to get the size. I think, in terms of 8 bit bytes, you have something like 7 x 7 or 13 x 7 for the 3 block. RLE files are created using information to tell the computer how many bits are on then how many are off in each raster line. There is a very good explanation in an old Transactor. There is also an extensive description of GIF files in a text file somewhere in the libraries. I"m at work right now and thus no time to do the search for you, but the info is out there if you do a search on GIF, I bet. ------------ Category 7, Topic 15 Message 5 Tue Dec 22, 1992 E.RAFANAN at 00:25 EST Thanks for the info!!! The compression for the Koalas and Doodles looks pretty straightforward. Viewing the Doodles looks pretty easy too. Are Koalas' info stored in the order you specified - color map, border color, and multi-color data? If not, you wouldn't happen to know the correct order? If I know that much, I'm pretty sure I can get it on the screen. Thanks also for the extra info on the Print Shop, RLE, and GIF formats. Like I said in my first post though, I just wanted to play around, so I don't want to tackle too much right now. BTW - I'm writing this in C. Just to 'C' if I can! (Sorry, couldn't resist!!!) - Eric ------------ Category 7, Topic 15 Message 6 Tue Dec 22, 1992 C128.JBEE at 02:05 EST geoPaint format is in Lib#35 and the topic about it is in Lib#1. ------------ Category 7, Topic 15 Message 7 Tue Dec 22, 1992 CBM-ED [e.g.bell] at 07:24 EST I don't remember the order of the Koala data, but I *think* it is data at 24576, border color is the byte at 34576, color map starts after that somewhere.... I would recommend if you know ML that you download something that displays it and disassemble it. The actual display routines are not very big... probably less than 50 or 100 bytes total to flip the appropriate bits, etc. and move the necessary data into the correct RAM. I did all of this many years ago in Bell Term for Doodle, Koala, compressed and uncompressed, Printshop, and RLE. ------------ ************ Topic 16 Sun Jan 10, 1993 E.BENDER (Forwarded) Sub: I Paint printer driver is there one for the Panasonic KXP 1124i? I have tried to find a driver that works but so far no luck. Can anybody help me? 1 message(s) total. ************ ------------ Category 7, Topic 16 Message 1 Sun Jan 10, 1993 HOWIE-CBM (Forwarded) The 1124i? Doesn't it have an Epson LQ emulation? If so, then any IPaint Epson LQ driver ought to do nicely. Howie ------------ ************ Topic 17 Mon Jan 18, 1993 R.PATERNOST2 [Ray] at 22:01 EST Sub: Viewers for Geos Info on displaying graphics screens from other software packages under Geos. 2 message(s) total. ************ ------------ Category 7, Topic 17 Message 1 Mon Jan 18, 1993 R.PATERNOST2 [Ray] at 22:03 EST Are there any PD viewers for Geos that will display hires b+w/multicolor screens from Doodle!, MicroIllustrator, and the like? Also are there any convert utilities that will convert pics from the above mentioned software to/from GeoPaint format? If so, where are they? ------------ Category 7, Topic 17 Message 2 Mon Jan 18, 1993 C128.JBEE at 23:27 EST I believe the files that would convert from Doodle and other hires formats are: #7845 Graphicview #7720 Scrap It! and some other utility from Joe Buckley that I can't remember the name :? ------------ ************ Topic 18 Thu Feb 25, 1993 G.HOYLE (Forwarded) Sub: WHAT IS BASIC 8? How do I get it? What do I need to have to use it? What good is it? 1 message(s) total. ************ ------------ Category 7, Topic 18 Message 1 Thu Feb 25, 1993 CBM-MARK (Forwarded) This topic will be moved to category #7 shortly. Why? Well Basic 8 is a graphic programming language and category #7 is the "Sight & Sound" Category. Guess that answers your question on what Basic 8 is :) What do you need to use Basic 8? Three things basically, a C128, 80 column monitor and a disk drive as a minimum. As for what good is it, it's about the easiest way there is for you to program graphic screens on the C128's 80 column screen. If you can program in BASIC you will have no problem using BASIC 8 since it's an extention of BASIC. Briwall and Software Support should both carry BASIC 8. I don't know about Tenex as I couldn't find it listed in the last catalog I have. Mark ------------ ************ Topic 19 Sun Mar 21, 1993 T.RUTTER2 [Troy Rutter] at 13:03 EST Sub: Ultra SIDplayer - Discussion This topic is for ideas, comments, questions about the new SIDplayer called Ultra SIDplayer. It is currently in alpha testing so any comments can help shape the future of the program. 17 message(s) total. ************ ------------ Category 7, Topic 19 Message 1 Sun Mar 21, 1993 T.RUTTER2 [Troy Rutter] at 13:03 EST Hi, my name is Troy Rutter (DATASID, QDJ Troy/Data on Qlink) and I thought Id sign on and finally start this topic for discussion about Ultra SIDplayer v1.0 that will be coming out shortly. Basically this SID player goes where no SID player has dared go before. Do you hate downloading your SIDs in the slr,msw,pil,wpl formats-- then have to dissolve them-- then have to boot up the SID player only to discover you forgot to dissolve one? ARGH! Well, don't despair-- Ultra SIDplayer is here! Ultra SIDplayer takes your archived SIDs and plays back the music, stereo, words (and later the pictures!) without having to dissolve them! So all you need to do is load up the player then select your SIDs and there ya go! Currently I have all file formats working to some extent. I must admit i need to look at the older versions of the .msw files more closely. Picture displays for wpl and pil are not available yet. A beta version will be coming shortly... please let me know what additional features you would like to see (no MIDI, please!). -Troy ------------ Category 7, Topic 19 Message 2 Mon Mar 22, 1993 C128.JBEE at 05:33 EST Hi Troy :) If you are the author of Ultra SID Player maybe you should contact me by e-mail about it. I have the exclusive rights to the Sid book by Compute, maybe we could work together on something. ------------ Category 7, Topic 19 Message 3 Mon Mar 22, 1993 T.RUTTER2 [Troy Rutter] at 09:00 EST Jbee, My source code for the SID player is built around the code that Mark Dickenson released into the public domain when he started his Stereoplayer. The filename of the source is called stereo.mod. Since it uses stereo, Mark had to completely re-write Craig's code. Which means I'm not quite sure what your exclusive rights pertain. When I release the SID player, since I am using Mark's PD source, I could not, in all conscience, attempt to sell the final product. I don't know the legalities involved here. Specificially, if a PD source code is used can the finished program be sold. Or is it just my conscience telling me I won't. I dunno Jbee.. clarify what you meant in email or something. Im a little confused. ;D ------------ Category 7, Topic 19 Message 4 Mon Mar 22, 1993 CBM-ED [e.g.bell] at 09:07 EST Is the pd source for ML code or BASIC? I am interested in the PD stuff regardless of how the other stuff works out. ------------ Category 7, Topic 19 Message 5 Mon Mar 22, 1993 R.KNOP1 [Rob Knop] at 09:25 EST If it is truly PD, then it is completely legal for you to do anything with it. You could even turn around and sell the code yourself unmodified. Thus, it would certainly be legal. As to conscience: how much in the way of modification did you do to the code yourself? If you've made any significant changes and enhancements, you probaly have a "moral" right to laim the code as your own. A lot of people use public domain code segments, code segments they've licenced, algorithms worked out by others, etc. in their code, and the code is still very much theirs (IMHO). For instance, if you are writing a database program, but implement your sort according to a bubble sort algorithm that you read in a book (or even with a legally used code fragment from that book), you can still claim rights to your program, even though you didn't reinvent the wheel :) -Rob (IMHO, of course :) ------------ Category 7, Topic 19 Message 6 Mon Mar 22, 1993 T.RUTTER2 [Troy Rutter] at 16:41 EST What I have done is this: Mark Dickenson, gracious as his is, released his stereo source (for only playing the music) into the public domain in 1988. In the documentation he says it is intended to be used to install in games, programs, whatever. Which is what I am doing. I have built an entire player around his interrupt routine that will take a SID archive (.msw for instance), interpret it, then play the left side, the right side, show the words, and will probably later display the pic. So as far as the code for the program itself, it is mine. The actual SID routine is Mark's. (Does that make ANY sense at all?) Anyway, I'm still in the early stages.. getting the music,stereo and words to play.. Heck, I havent evn added the directory routine yet. :DD As for Ed's post... the code that Mark provided is strictly machine language... and strictly for the 64. As is evident in the Book/Disk combo JBee has rights too... the 128 routine is slightly different. However.... in the back of the book accompanying the Enhanced SID Player, it gives tips for adding the code to your own programs.. the only limitation being that due credit is given for the source. And, if possible, the file called sid.obj128 remain titled in that way. ------------ Category 7, Topic 19 Message 7 Mon Mar 22, 1993 CBM-ED [e.g.bell] at 20:57 EST Ok, given what you have just posted, could you upload the player code to our libs... if it is for th C64 that is not a prolem. I'm sure I can adapt it, and I am more than willing to credit the author, keep the name, etc. I just don't want to re-invent the wheel, and this seems to be exactly what I need. I'm not interested in making a competing product.... just a player for SIDS that can be used within my program. Would you upload the code? Thanks! ------------ Category 7, Topic 19 Message 8 Tue Mar 23, 1993 HOWIE-CBM at 00:39 EST Rob, I thought bubble sorts were superceeded by several newer and faster ones. As for code ownership I fully agree with what you have expressed. I do not see how there can be any question but that Troy can do as he sees fit with his code, even tho portions may contain others algorythms. New code always relies on prior existing code. Else how would we ever progress? Howie ------------ Category 7, Topic 19 Message 9 Tue Mar 23, 1993 C128.JBEE at 01:30 EST Actually all I wanted to know about and ask was if I could include it on the back of the SID disk (with the book) and if you would want to write some articles for TC128/64 on the how the SID player works and how to make good sounding SIDs vs. just copying sheet music. I just didn't want to turn the topic into a commercial which is why the reply was a bit "terse" :D ------------ Category 7, Topic 19 Message 10 Wed Mar 24, 1993 T.RUTTER2 [Troy Rutter] at 20:34 EST Ok, heres the scoop... I have the SDA of the stereo code Mark uploaded to Qlink.. no problem. NOW... On Qlink.. not once, not twice.. but THREE times under different uploaders is a file called sid.obj.128 now... supposably Craig released this into the Public Domain shortly after the ENHANCED SIDplayer book/disk came out with the 128 code. I don't want to be fingered for uploading proprietary (??) software... but it is on Qlink and they are VERY careful about PD stuff. Whatcha think JBEE, is it safe? ------------ Category 7, Topic 19 Message 11 Wed Mar 24, 1993 CBM-ED [e.g.bell] at 23:15 EST And judging by the filename, sid.OBJ.128, is this source code... I am not picky as to which machine I get it for.... 128 or 64 is ok. I believe I can work with either because when it comes right down to it, there is not that much different wrt the SID stuff ------------ Category 7, Topic 19 Message 12 Thu Mar 25, 1993 C128.JBEE at 12:09 EST >software... but it is on Qlink and they are VERY careful about PD stuff. I will try to connect with Craig this week and ask him :) ------------ Category 7, Topic 19 Message 13 Fri Mar 26, 1993 B.VRIELING1 at 19:07 EST Howie, (Perhaps this is in the wrong thread (Sidplayer, not sorts) but good info is likely always welcome so...)