[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