[Coco] Crunch?

Stephen H. Fischer SFischer1 at Mindspring.com
Thu Jun 4 11:08:15 EDT 2009


Hi,

>  I think it is seeing the data in track 0
> sector 1 and deciding that it must be an OS-9 disk

I think this is what is happening.

I sure wish I had some way on this Vista computer to look at the first
sector in HEX and ASCII at the same time.

And I could find my OS-9 manual quickly.

Here are the first few lines, lines are folded:

#               LIST_ON                                 : REM CHANGE TO
COMMENT LINE IF NOT WANTED
#               XREF_ON                                 : REM CHANGE TO
COMMENT LINE IF NOT WANTED
#               CONSTANT UBN~VERSION$      = "1.060202 RC0"
#               CONSTANT UBN_TITLE$        = "Urbane XUBN~VERSION$  - Tandy
Color Computer 3 Disk Extended Color Basic Preprocessor."
'               Original Left Hello A. Nani Mouse Inx.

#               CONSTANT IN_FILE$          = "UBN_IN.TXT"

Comparing the display in Wordpad I immediately realized that a tab character
might be in the first line as the column with ":REM" does not match the
second line. In Wordpad, they do.

There is a line of code for tabs":


                IF IN_LINE_CH   = ASC_TAB GOTO SUBSTUTE_SPACE_FOR_TAB

So Urbane is not bothered by the tab.

SHF




----- Original Message ----- 
From: "Darren A" <mechacoco at gmail.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Wednesday, June 03, 2009 3:35 PM
Subject: Re: [Coco] Crunch?


> On 6/3/09, Willard Goosey wrote:
>> On Tue, Jun 02, 2009 at 07:52:35PM -0400, Paul Fitch wrote:
>>> I don't think you have anything to fix either, since its not broken.  Of
>>> course, I always assumed that a .DSK or .OS9 image was an actual virtual
>>> COPY of a real disk in all respects.
>>
>> Some of the tools that take will take files and build a .dsk with them
>> only make the file as large as it has to be to store the files and the
>> directory.
>>
>> So a DECB .dsk will have at least the first 17 tracks, but an OS-9
>> .dsk might only be N*256 bytes long, possibly not even to an even
>> number of tracks.
>>
>
>
> The problem is definitely with VCC.  If you pad out the Urbane.dsk
> file to exactly 161,280 bytes (630 sectors) VCC will still not be able
> to access it properly.  I think it is seeing the data in track 0
> sector 1 and deciding that it must be an OS-9 disk (even though it
> isn't). It then uses that information to setup an incorrect disk
> geometry.
>
> Darren




More information about the Coco mailing list