[Coco] New! Cassette to floppies

[Robert Gault]

There is a difference between SAVEM and CSAVEM. How many programs fit 
into 255 bytes or less, which is the length of a cassette block?

Rather than rely on memory, isn't anyone going to look at the Unravelled 
Basic code and read that for the CSAVE routine? I have looked at CSAVE 
(I can't find the CSAVEM branch point) and the CLOADM routines. I have 
yet to see any indication that an ml program can be saved in a block 
larger than 255 bytes.

I'll be happy to say I'm wrong if someone will tell me where the 
cassette code is in the Unravelled book that supports cassette blocks of 
larger than 255 bytes.

Arthur Flexser wrote:
> I believe Bob is correct about those peeks working fine with programs consisting
> of a single block.  You are incorrect that blocks cannot be longer than 255
> bytes;  an ML file can consist of a single block of any length, and does if it
> was saved using the SAVEM command rather than by an assembler.
> 
> Art
> 
> PS, as an unrelated face-saving fact, I am almost certain that somebody released
> a QBert clone for the CoCo that was called Cubix;  my error was in
> misremembering that that was the name of the original arcade game, and so
> misconstruing the inquiry as to whether anyone had ever ported Cubix to the
> CoCo.  Sorry 'bout that.
> 
> On Wed, 2 Nov 2005, Robert Gault wrote:
> 
> 
>>Bob, I think you should check the CLOAD and CLOADM code. The start 
>>address at $7E-$7F is a pointer to the load address as you say. But, 
>>each block read from the tape changes the $7E-$7F value. Any long 
>>program whether Basic or ml will use more than one tape block; they're 
>>255 bytes. This will happen with ml programs even if the program loads 
>>to contiguous memory. There is no cassette equivalent to disk single 
>>record format.
>>
>>The end address you have given is located within the cassette data 
>>buffer at $1DA-$2D9. That does not seem a good place to have a pointer. 
>>There is no mention of an end pointer (I can find) in the CLOAD code.
>>
>>Bob Devries wrote:
>>
>>>The START, END, and EXEC addresses of a binary file on tape are in fact 
>>>easy to fine, **PROVIDED** the file is contiguous, and not one of the 
>>>multi-block ones.
>>>
>>>START ADDRESS = PEEK(487) * 256 + PEEK(488)
>>>END ADDRESS = PEEK(126) * 256 + PEEK(127) -1
>>>EXEC ADDRESS = PEEK(157) * 256 + PEEK(158)
>>>
>>>If the file is of the multi-block format, you're on your own. :) You can 
>>>easily hear the difference by listening to the sound of the file being 
>>>played on the tape. If there's gaps in the data stream (except for the 
>>>short one after the name block, then it's a multiblock file).
>>>
>>>Many games had a pre-loader, which auto-executed, and loaded the rest of 
>>>the programme. These are more difficult to transfer to disk.
>>>-- 
>>>Regards, Bob Devries, Dalby, Queensland, Australia
>>>
>>>Isaiah 50:4 The sovereign Lord has given me
>>>the capacity to be his spokesman,
>>>so that I know how to help the weary.
>>>
>>>website: http://www.home.gil.com.au/~bdevasl
>>>my blog: http://bdevries.invigorated.org/
>>>
>>>
>>
>>-- 
>>Coco mailing list
>>Coco at maltedmedia.com
>>http://five.pairlist.net/mailman/listinfo/coco
>>
> 
> 
>