Copy Link
Add to Bookmark
Report

Info-Atari16 Digest Vol. 90 Issue 161

eZine's profile picture
Published in 
Info Atari16 Digest
 · 26 Apr 2019

  

=========================================================================

INFO-ATARI16 Digest Tue, 6 Feb 90 Volume 90 : Issue 161

Today's Topics:
16 meg partition limit
Abaq: where is it?
Error in TOS file browser? (2 msgs)
Hard Disk Cleaning Supplies
Non-profit needs 8bit software!
Of Mega2s and Other Things ST :-)
PC-DITTO II
Weirdness with High Density drives and the ST
----------------------------------------------------------------------

Date: 5 Feb 90 19:17:11 GMT
From: portal!atari!apratt@apple.com (Allan Pratt)
Subject: 16 meg partition limit
Message-ID: <2020@atari.UUCP>

brazil@pawl.rpi.edu (Timothy E. Onders) writes:
>In article <20465@watdragon.waterloo.edu> swklassen@tiger.waterloo.edu (Steven
W. Klassen) writes:
>>mentioned the 16 meg limit, however, the utilities which came
>>with it allowed me to make larger partitions.

>Those would be HDX 3.0. HDX 3.0 allows partitions up to 1 GBy (that's
>1024 MB in case you didn't know.), It also allows more partitions per
>physical drive.

Right. Actually it's 3.01; the driver that came with 3.0 had a bug,
though the formatter (HDX) is the same.

>>unreliable for long term use?

Certainly not.

>The only problem, however, is that many disk utility programs ...
>don't know how to handle the larger partitions.

Also right. Here's the bottom line: when you have a partition larger
than 16MB, the driver creates the partition with 1KB sectors (or more!)
rather than 512-byte sectors, which is the old value. Cluster size is
still two sectors, whatever size that is. The disk itself is formatted
with 512-byte sectors, and Rwabs does blocking and deblocking, turning
requests for "one logical sector" into as many physical sectors as
necessary.

The reason for the large-sector implementation is that all GEMDOSes can
handle any (power-of-two) sector size, but not all can handle a cluster
size other than two.

The drawback is that some (most) utilities assume that one sector is
always 512 bytes. They could have used the Getbpb() call and used the
sector size returned from that, but the original TOS documentation all
but guaranteed 512 bytes forever. These programs will crash, or worse,
will fail quietly because they read "one sector" into a buffer which is
only 512 bytes long; the Rwabs transfers 1K, clobbering whatever came
after the buffer in memory. Also, their notion of how big a sector is
(e.g. number of directory entry slots in a directory sector) will be
wrong.

As an additional complication, if you use the "raw mode" (also called
"physical device") bit in the first arg to Rwabs, you get physical
sectors, which are still 512 bytes. That number is not obtainable as a
variable anywhere, so it'll probably stay at 512.

The hardest-hit class of programs is the "add cache sectors" or other
disk-caching kind, because it needs to know how big a buffer to
allocate. The answer to that question is impossible to compute, so
it's available from the hard-disk driver. (It's impossible to compute
because it involves a user-preference value which can be patched into
the driver: with removable media you could pop the cartridge and put in
one with larger logical sectors, so the user tells the driver a
minimum for the "maximum sector-size" value to use.)

CACHExxx.PRG from Atari, of course, interrogates the driver and uses
that number correctly.

I'm not publishing the way to interrogate the driver here because I
would not get it right. The straight scoop is avaiable to developers
in the HDX 3.0 Release Notes document.

The moral is, utilities should always use Getbpb to find out how big
sectors are, how many sectors per cluster, etc., and base all your
other calculations and "constants" on the answers. If you're adding
GEMDOS buffers or other permanent objects, get the release notes and do
it right.

============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt

------------------------------

Date: 6 Feb 90 05:27:28 GMT
From:
cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!watserv1!watmath!watmsg!mwnewman@tu
t.cis.ohio-state.edu (mike newman)
Subject: Abaq: where is it?
Message-ID: <34005@watmath.waterloo.edu>

Does anyone know the current status of the abaq machine? If anyone knows
if it is available, or where I could get some technical specifications, could
you please email me?

thanks.

Apologies if this has already been mentioned: I haven't noticed it.


disclaimer: Why yes, thank you! I'll have two please.
disclaimer: Why yes, thank you! I'll have two please.

mike newman mwnewman@watmsg.uwaterloo.edu
"Thy Sine Function Shalt Never Be Greater Than One." --MatheMatics

------------------------------

Date: Mon, 5 Feb 90 22:19:12 EST
From: "Hiscocks, Peter" <FCTY7284%RYERSON.bitnet@ugw.utcs.utoronto.ca>
Subject: Error in TOS file browser?
Message-ID: <90Feb5.224924est.58370@ugw.utcs.utoronto.ca>

When I double click on certain types of files to browse through them, I find
that paging forward (using the space bar) works fine. However, using the
return key, by holding it down to cause the file to scroll, eventually
causes an 11 bomb crash.
This seems not to be a problem on vanilla text files, but is a problem on
text files with long lengths, possibly related to the carriage return
character not being in the usual place.
This same 'bug' (if it is such) shows up when using ABZMON, and scrolling
through a memory or file dump.
Has anyone else noticed this? Is it known to occur under certain circumstances?

Incidentally, I highly recommend ABZMON as a debugging device. It comes with
source code and is PD. I can send it to one of the archives if the concensus
is that it would be useful.
Peter

------------------------------

Date: Mon, 5 Feb 90 22:19:12 EST
From: "Hiscocks, Peter" <FCTY7284%RYERSON.bitnet@ugw.utcs.utoronto.ca>
Subject: Error in TOS file browser?
Message-ID: <90Feb5.224924est.58370@ugw.utcs.utoronto.ca>

When I double click on certain types of files to browse through them, I find
that paging forward (using the space bar) works fine. However, using the
return key, by holding it down to cause the file to scroll, eventually
causes an 11 bomb crash.
This seems not to be a problem on vanilla text files, but is a problem on
text files with long lengths, possibly related to the carriage return
character not being in the usual place.
This same 'bug' (if it is such) shows up when using ABZMON, and scrolling
through a memory or file dump.
Has anyone else noticed this? Is it known to occur under certain circumstances?

Incidentally, I highly recommend ABZMON as a debugging device. It comes with
source code and is PD. I can send it to one of the archives if the concensus
is that it would be useful.
Peter

------------------------------

Date: 6 Feb 90 06:05:15 GMT
From:
zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!w
atserv1!bmaraldo@tut.cis.ohio-state.edu (Commander Brett Maraldo)
Subject: Hard Disk Cleaning Supplies
Message-ID: <974@watserv1.waterloo.edu>

I was wondering if there was a program that would help to
clean up my hard disk; that is, somethig that would organize all the
fragmented files and what-not and place all the unused space in a
large continuous section on the drive. You know what I mean, don't
you? :-)

Brett L Maraldo

ps. It's late... very late.


--
-------- Unit 36 Research ---------
"Alien Technology Today"
bmaraldo@watserv1.UWaterloo.ca
?uunet!clyde!utai?!watserv1!bmaraldo

------------------------------

Date: 6 Feb 90 06:13:43 GMT
From: portal!portal!cup.portal.com!Justin_Randall_Padawer@apple.com
Subject: Non-profit needs 8bit software!
Message-ID: <26633@cup.portal.com>

We recently received 2 Atari 800XL and 1 1200XL computers with disk
drives and a printer. Of course we are very grateful. But in order
to use the computers with the kids we work with we need software. At
this point, we'll take anything...beggars aren't choosers. Unfortunately
we aren't budgeted for buying software, but I'm **very** interested in
exposing these kids to computers; I think they'll love them. Our agency
treats chemically dependent teenagers in Appalachian East Tennessee.
(Need educational, recreational, productivity software; disk or cartridge.)
--Randy Padawer, program counselor, DRI Adolescent Center, 412 Citico Street
Knoxville, TN 37921 Telephone (615) 524-5757
My Internet/Usenet: Justin_Randall_Padawer@cup.portal.com

------------------------------

Date: 6 Feb 90 04:48:32 GMT
From: cunixc!cunixd.cc.columbia.edu!ia4@columbia.edu (Imran Anwar)
Subject: Of Mega2s and Other Things ST :-)
Message-ID: <2816@cunixc.cc.columbia.edu>

Keywords: Mega2, discontinued, Atari

I got a Mega4 at Manny's music inNYC after it too was out of stock at J&R.
I called Atari and (as usual?) after a lot of efforts and a "stinker" of a
fax message to the Director marketing there found agentleman named Don there
who went out of his way to help....

From the few people I spoke to in my efforts to get the info I was told that
the Mega2 was not being discontinued....whereas all the stores in NYC were
saying it is being discontinued reportedly based on the comments of the guy
who sells Ataris to them.....so who do we believe?

Funny thing is that when finally I did get the list of Atari dealers in NY
from Atari the ONLY ones who carried them were J&R and two smaller
stores...all else said they were not carrying the STs anymore :-(

I don't know if any of this has helped (except to confuse the issues even
further :-)

Imran Anwar

PS I got the Mega4...I'd say to all Mega2 hopefuls...get the Mega4 ...it is
better in my opinion to spend the extra few (hundred :-)? ) bucks now than
later :-) I also got the mono monitor...its great too.

[Of course all standard (and non standard :-) ) disclaimers apply ]

PPS Someone recently asked on the net what Atari's marketing strategy is.
In my opinion the official one would be to prevent sales by any means
possible (but there are always these troublemakers in the staff who actually
respond to customers ;-) ....Atari should fire 'em all :-) ).

That is the strategy or maybe they are waiting to make me a Job offer when
I am done with my MBA studies :-)
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
Not likely considering the time I spend with my ST :-)

------------------------------

Date: 6 Feb 90 05:55:51 GMT
From: portal!portal!cup.portal.com!buggs@apple.com (William Edward JuneJr)
Subject: PC-DITTO II
Message-ID: <26629@cup.portal.com>

Can compiler packages be used on these MSDOG emulators?
I was wonderin' 'bout Turbo C or the Zortech one.

Why not do a '386 'DMA box'? That way you COULD run UNIX & X Windows, no?

What can you REALLY do with the current products that are out?


Ed <wasn't there talk of an '386SX based emulator?> June

------------------------------

Date: 5 Feb 90 20:38:48 GMT
From: rochester!rit!ultb!drp9500@PT.CS.CMU.EDU (D.R. Paradis)
Subject: Weirdness with High Density drives and the ST
Message-ID: <2112@ultb.isc.rit.edu>

I have this problem with the 5 1/4" drive I have hooked up to
mine....(also with the 3 1/2")

It appears that if the ST accesses the disk at all that the boot
sector gets either rewritten or corrupted in some way that the IBM (PC
Ditto) can't read.

I correect this by using DC Format and re writing an IBM boot sector
to the disk and it reads fine. (I have to do this more on the 3 1/2"
than the 5 1/4")

Sure is a pain in the ass fix but it works for now.....

Bob

------------------------------

End of INFO-ATARI16 Digest V90 Issue #161
*****************************************

← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos App from Google Play
install Neperos as PWA

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT