Discussion:
What did an original Apple II sell for?
(too old to reply)
I am Rob
2017-09-06 03:39:33 UTC
Permalink
Raw Message
Just posting this for a comparison.

http://www.ebay.com/itm/Commodore-65-Computer-The-Holy-Grail-of-Commodore-Collecting/222630201237?_trkparms=aid%3D777003%26algo%3DDISCL.MBE%26ao%3D1%26asc%3D43628%26meid%3Df42100649261499fb51d654c9cf23091%26pid%3D100013%26rk%3D5%26rkt%3D12%26mehot%3Dpp%26sd%3D222322359951&_trksid=p2047675.c100013.m1986
I am Rob
2017-09-09 03:40:50 UTC
Permalink
Raw Message
Post by I am Rob
Just posting this for a comparison.
http://www.ebay.com/itm/Commodore-65-Computer-The-Holy-Grail-of-Commodore-Collecting/222630201237?_trkparms=aid%3D777003%26algo%3DDISCL.MBE%26ao%3D1%26asc%3D43628%26meid%3Df42100649261499fb51d654c9cf23091%26pid%3D100013%26rk%3D5%26rkt%3D12%26mehot%3Dpp%26sd%3D222322359951&_trksid=p2047675.c100013.m1986
Final price: $18,350.00
barrym95838
2017-09-10 15:53:59 UTC
Permalink
Raw Message
Post by I am Rob
Post by I am Rob
Just posting this for a comparison.
http://www.ebay.com/itm/Commodore-65-Computer-The-Holy-Grail-of-Commodore-Collecting/222630201237?_trkparms=aid%3D777003%26algo%3DDISCL.MBE%26ao%3D1%26asc%3D43628%26meid%3Df42100649261499fb51d654c9cf23091%26pid%3D100013%26rk%3D5%26rkt%3D12%26mehot%3Dpp%26sd%3D222322359951&_trksid=p2047675.c100013.m1986
Final price: $18,350.00
http://oldcomputers.net/appleii.html

A new 4K Apple ][ sold for $1298 in 1977, which inflates to about $5,243
in 2017. I think that 4K would feel a bit constrictive even back then,
and 16K was probably a more popular choice at $1698 ($6858), at least
until the Disk ][ was introduced.

Mike B.

Mike B.
cb meeks
2017-09-13 13:44:12 UTC
Permalink
Raw Message
Post by barrym95838
Post by I am Rob
Post by I am Rob
Just posting this for a comparison.
http://www.ebay.com/itm/Commodore-65-Computer-The-Holy-Grail-of-Commodore-Collecting/222630201237?_trkparms=aid%3D777003%26algo%3DDISCL.MBE%26ao%3D1%26asc%3D43628%26meid%3Df42100649261499fb51d654c9cf23091%26pid%3D100013%26rk%3D5%26rkt%3D12%26mehot%3Dpp%26sd%3D222322359951&_trksid=p2047675.c100013.m1986
Final price: $18,350.00
http://oldcomputers.net/appleii.html
A new 4K Apple ][ sold for $1298 in 1977, which inflates to about $5,243
in 2017. I think that 4K would feel a bit constrictive even back then,
and 16K was probably a more popular choice at $1698 ($6858), at least
until the Disk ][ was introduced.
Mike B.
Mike B.
Sure, 4K would have been restrictive. But, you have to remember that in 1977 people actually didn't know what to do with a computer and there wasn't exactly a lot of software. I would guess that most people brought their 4K Apple II home and said "Now what?".

It was a chick-n-egg problem. People needed more RAM for better software but they needed better software to justify more RAM. :-)

That why it took a few years actually before computer started selling VERY well.
Ralf Kiefer
2017-09-13 23:06:01 UTC
Permalink
Raw Message
Post by cb meeks
Sure, 4K would have been restrictive. But, you have to remember that in
1977 people actually didn't know what to do with a computer and there
wasn't exactly a lot of software. I would guess that most people brought
their 4K Apple II home and said "Now what?".
At that time I started my "career" in school in front of a PET with 8kB
of RAM and the tape recorder. After some months we felt this
restriction. We just "played" with our own BASIC programs.

- Ralf
Chris Tobar
2017-09-14 04:37:02 UTC
Permalink
Raw Message
This is slightly off topic, but what Ralf said about using a PET with a tape recorder made me curious - was it hard to get cassette tapes to work for saving and loading data back then?

When I bought my Apple II+ a few months ago, I briefly tried to save programs to a tape before I found some blank floppy disks. It drove me nuts! It was so finicky, I kept getting error messages and had to keep adjusting the volume. I only got it to work once or twice. Are Apple II computers just more picky, or was this a common problem with early computers?

- Chris
barrym95838
2017-09-14 05:28:26 UTC
Permalink
Raw Message
Post by Chris Tobar
This is slightly off topic, but what Ralf said about using a PET with a tape recorder made me curious - was it hard to get cassette tapes to work for saving and loading data back then?
When I bought my Apple II+ a few months ago, I briefly tried to save programs to a tape before I found some blank floppy disks. It drove me nuts! It was so finicky, I kept getting error messages and had to keep adjusting the volume. I only got it to work once or twice. Are Apple II computers just more picky, or was this a common problem with early computers?
- Chris
I used tapes for storage in the early 1980s on the Apple ][, C=64, and TRS-80. In my personal experience, I would grade them at "B", "C", and "D" respectively, for overall performance and reliability. As soon as I could afford the Disk ][, I was completely done with Apple cassettes ... the difference was night and day.

Mike B.
Your Name
2017-09-14 06:36:19 UTC
Permalink
Raw Message
Post by barrym95838
Post by Chris Tobar
This is slightly off topic, but what Ralf said about using a PET with a
tape recorder made me curious - was it hard to get cassette tapes to
work for saving and loading data back then?
When I bought my Apple II+ a few months ago, I briefly tried to save
programs to a tape before I found some blank floppy disks. It drove me
nuts! It was so finicky, I kept getting error messages and had to keep
adjusting the volume. I only got it to work once or twice. Are Apple II
computers just more picky, or was this a common problem with early
computers?>> - Chris
I used tapes for storage in the early 1980s on the Apple ][, C=64, and
TRS-80. In my personal experience, I would grade them at "B", "C", and
"D" respectively, for overall performance and reliability. As soon as
I could afford the Disk ][, I was completely done with Apple cassettes
... the difference was night and day.
I can't recall ever having many issues with the tapes on our VIC20 and
C64 computers ... other than being horribly slow of course. Things did
speed up a bit when "turbo loaders" started appearing. We did
eventually get a disk drive for the C64 though and the tape drive was
"put out to pasture" (the games still on tape were transferred to disk
using one of those "freeze" cartridges that were a fad at one time).
Richard Thiebaud
2017-09-14 12:10:34 UTC
Permalink
Raw Message
Post by barrym95838
Post by Chris Tobar
This is slightly off topic, but what Ralf said about using a PET with a tape recorder made me curious - was it hard to get cassette tapes to work for saving and loading data back then?
When I bought my Apple II+ a few months ago, I briefly tried to save programs to a tape before I found some blank floppy disks. It drove me nuts! It was so finicky, I kept getting error messages and had to keep adjusting the volume. I only got it to work once or twice. Are Apple II computers just more picky, or was this a common problem with early computers?
- Chris
I used tapes for storage in the early 1980s on the Apple ][, C=64, and TRS-80. In my personal experience, I would grade them at "B", "C", and "D" respectively, for overall performance and reliability. As soon as I could afford the Disk ][, I was completely done with Apple cassettes ... the difference was night and day.
Mike B.
I used tapes with my TRS-80 and they worked well. My brother used tapes
with his Apple II and they were finicky.
Jorge
2017-09-14 16:01:18 UTC
Permalink
Raw Message
Post by Richard Thiebaud
I used tapes with my TRS-80 and they worked well. My brother used tapes
with his Apple II and they were finicky.
That was my experience too, trash-80's tapes worked better, were more reliable, it was less picky than the Apple II.
Michael J. Mahon
2017-09-14 07:20:31 UTC
Permalink
Raw Message
Post by Chris Tobar
This is slightly off topic, but what Ralf said about using a PET with a
tape recorder made me curious - was it hard to get cassette tapes to work
for saving and loading data back then?
When I bought my Apple II+ a few months ago, I briefly tried to save
programs to a tape before I found some blank floppy disks. It drove me
nuts! It was so finicky, I kept getting error messages and had to keep
adjusting the volume. I only got it to work once or twice. Are Apple II
computers just more picky, or was this a common problem with early computers?
- Chris
My experience is that cassette storage is quite easy and reliable on the
Apple II.

The key is using a "simple" cassette recorder, without tone conttols.
Simple recorders about 6"x12"x2" were very common in the eighties, before
the Walkman form factor.

Typically, a mid- to two-thirds-volume setting was about right.

It was necessary to pay attention to head alignment (azimuth) if cassettes
were interchanged between decks, but problems were pretty rare. This is not
an issue if only one deck is used.

Proper tape handling technique was important.

I generally used C60s, marching down the tape as I saved subsequent
revisions of a program, and as I wrote new programs. The tape counter was
religiously zeroed at the start of each cassette, and the counter was
written down on an ascending log of the tape's contents.

To record, write down the tape counter, press PLAY-RECORD and press ENTER
for the save command. Listen for the end of the data, wait a couple of
seconds, and press STOP on the recorder.

To read, position the tape to the logged number, press PLAY, and when you
hear the "preface" tone, press ENTER for the load command. When the data
ends, wait a couple of seconds and press STOP.

To simplify the cuing and avoid the use of headphones, I soldered a 220 Ohm
resistor across the speaker cut-out switch on the "line out" jack of the
deck. That caused all playback and monitor audio to be audible through the
deck's speaker at low volume--perfect for cueing.

I very seldom encountered a data recording error (maybe twice in over ten
*hours* of data), but, since I recorded all revisions of my code/data, it
was not difficult to recover using the previous version.

Something that may help (I tried it as a verification strategy) is to write
a short assembler program that simply "echoes" the cassette input to the
Apple speaker. Varying the playback volume while such a loop is running
provides instant feedback on whether the cassette input port is "hearing"
the data. The level should be somewhat higher that the lowest level that is
reproduced correctly.

Of course, disks are much faster and more convenient, but reliability and
usability were excellent if an appropriate deck and use protocol were used.
The Apple cassette interface is very robust.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Daniel Bethe
2017-09-15 05:33:39 UTC
Permalink
Raw Message
I'm glad to see another cassette player dropout, and amen to the holy gospel of the floppy drive. My first computer in third grade was an Atari 800xl and it came with a cassette drive and two tapes. My mom and I never ever got a tape to work. We tried and just didn't get it! We quickly traded that in for a 5.25" drive ;)
I am Rob
2017-09-15 21:30:16 UTC
Permalink
Raw Message
Post by I am Rob
Post by I am Rob
Just posting this for a comparison.
http://www.ebay.com/itm/Commodore-65-Computer-The-Holy-Grail-of-Commodore-Collecting/222630201237?_trkparms=aid%3D777003%26algo%3DDISCL.MBE%26ao%3D1%26asc%3D43628%26meid%3Df42100649261499fb51d654c9cf23091%26pid%3D100013%26rk%3D5%26rkt%3D12%26mehot%3Dpp%26sd%3D222322359951&_trksid=p2047675.c100013.m1986
Final price: $18,350.00
How do I rename the topic of this thread to "WHO GIVES A SHIT?"
Jorge
2017-09-15 21:55:54 UTC
Permalink
Raw Message
Post by I am Rob
How do I rename the topic of this thread to "WHO GIVES A SHIT?"
LOL. They have hijacked your thread!
--
Jorge
Jorge
2017-09-14 13:56:42 UTC
Permalink
Raw Message
A floppy rotates @300 rpm, a track has 16 sectors, a sector 256 bytes, a byte 8 bits => a bit is read roughly every 1/(300/60)/16/256/8 -> 6µs

On the tape a one takes 1000µs and a zero 500µs, so loading a bit takes 750µs on average.

600 dollars (1978 dollars!) bought you a 125x boost in speed, and that alone was a good thing.

But the cassette driver could run much faster today because we don't use cassettes any more. I think 100..200 µs per bit could be made to work error free nowadays, that's 3..7 times faster. That's something ADTPro could use... Oliver? David? The Schmidts? Do you hear me? :-)

I once peeked with the scope at the signal coming out of the 741 of the cassette input, it had a rise time of 20 to 30 ms. And it takes quite longer to react in one direction that in the other (from low to high IIRC). That's something to keep in mind.

A problem of the cassette output of the Apple II is R19 (12k), all the Apple IIs I have had have that R shorted with a wire with test clips to make it compatible with the audio line input of the Macs. Works wonderfully! BTW this is also something the ADTPro user guide should mention because a Mac can't sense properly the Apple II microphone-level signal and that totally ruins ADTPro audio transfers for Mac users.
--
Jorge.
Jorge
2017-09-14 14:00:01 UTC
Permalink
Raw Message
Typo: 20 to 30 µs not ms
Ralf Kiefer
2017-09-14 15:03:04 UTC
Permalink
Raw Message
Post by Jorge
byte 8 bits => a bit is read roughly every 1/(300/60)/16/256/8 -> 6µs
Don't forget the gaps! A single track (DD, MFM) covers 6500Byte =
52.000bits.
-> one bit is represented in ˜4usec.
Post by Jorge
On the tape a one takes 1000µs and a zero 500µs, so loading a bit takes
750µs on average.
See Kansas City standard. But Apple used their own standard.
https://en.wikipedia.org/wiki/Kansas_City_standard

My Eltec Eurocom 1 uses the 6850 @300Baud to generate the raw data
stream for the tape recorder. But there is a coding in the files with
overhead. My Eurocom 1 doesn't store raw binaries but Motorola S-Records

- Ralf
Jorge
2017-09-14 15:15:52 UTC
Permalink
Raw Message
Post by Ralf Kiefer
Post by Jorge
byte 8 bits => a bit is read roughly every 1/(300/60)/16/256/8 -> 6µs
Don't forget the gaps! A single track (DD, MFM) covers 6500Byte =
52.000bits.
-> one bit is represented in ˜4usec.
But that's raw/unformatted, my figure takes the encoding/protocol into account :-)
Post by Ralf Kiefer
Post by Jorge
On the tape a one takes 1000µs and a zero 500µs, so loading a bit takes
750µs on average.
See Kansas City standard. But Apple used their own standard.
https://en.wikipedia.org/wiki/Kansas_City_standard
stream for the tape recorder. But there is a coding in the files with
overhead. My Eurocom 1 doesn't store raw binaries but Motorola S-Records
So that's even worse yet! Apple's baud rate is 1333 (1/750e-6).

Cheers,
--
Jorge.
David Schmidt
2017-09-14 15:11:15 UTC
Permalink
Raw Message
Post by Jorge
[...]
But the cassette driver could run much faster today because we don't use cassettes any more. I think 100..200 µs per bit could be made to work error free nowadays, that's 3..7 times faster. That's something ADTPro could use... Oliver? David? The Schmidts? Do you hear me? :-)
Also see: https://github.com/datajerk/c2t
Post by Jorge
[...]
A problem of the cassette output of the Apple II is R19 (12k), all the Apple IIs I have had have that R shorted with a wire with test clips to make it compatible with the audio line input of the Macs. Works wonderfully! BTW this is also something the ADTPro user guide should mention because a Mac can't sense properly the Apple II microphone-level signal and that totally ruins ADTPro audio transfers for Mac users.
Normally, Mac users do the mic boost as suggested on the ADTPro website:
http://adtpro.com/connectionsaudio.html#Boosting

Are you saying you bridge the resistor and it essentially boosts the
output at the Apple II end?
Jorge
2017-09-14 15:27:03 UTC
Permalink
Raw Message
Post by David Schmidt
Are you saying you bridge the resistor and it essentially boosts the
output at the Apple II end?
Yes.

I totally missed the paragraph "On the OSX operating system, you will find the microphone boost by opening the Audio-MIDI configuration tool, selecting the setting for line-in, and then moving the volume sliders all the way to the right" :-)

But, hey, if you short r19 you don't need to do that AND... you can pass programs between Apple IIs via the cassette ports, something you can't do if you don't (for the same reason).
--
Jorge.
Jorge
2017-09-14 15:53:50 UTC
Permalink
Raw Message
Post by David Schmidt
Also see: https://github.com/datajerk/c2t
https://github.com/datajerk/c2t/raw/master/article/article.pdf

That's cool !!! I love it! 8000..9600 baud !

Today's browsers can also receive audio... so ADTPro style bi-directional audio comms are possible between a II and a web page (more so with R19 shorted), thus ADTPro could be made as a web page. I'm very good at javascript, if you need the audio .js I'll happily write it for you!
--
Jorge.
Jorge
2017-09-14 16:29:25 UTC
Permalink
Raw Message
Post by Jorge
I once peeked with the scope at the signal coming out of the 741 of the cassette input, it had a rise time of 20 to 30 ms. And it takes quite longer to react in one direction that in the other (from low to high IIRC). That's something to keep in mind.
A picture is worth a thousand words: https://imgur.com/a/K2IeH

The yellow trace is H14 (74251) pin 4, the blue trace is the 741 pin 2 (cassette input). R19 is shorted and there's a jack to jack cable feeding the cassette output into the cassette input.
--
Jorge
Jorge
2017-09-14 16:55:13 UTC
Permalink
Raw Message
Post by Jorge
Post by Jorge
I once peeked with the scope at the signal coming out of the 741 of the cassette input, it had a rise time of 20 to 30 ms. And it takes quite longer to react in one direction that in the other (from low to high IIRC). That's something to keep in mind.
A picture is worth a thousand words: https://imgur.com/a/K2IeH
The yellow trace is H14 (74251) pin 4, the blue trace is the 741 pin 2 (cassette input). R19 is shorted and there's a jack to jack cable feeding the cassette output into the cassette input.
What is interesting there is that the same 82µs pulse, depending on its polarity, can result in either a 65µs or an 85µs pulse at $c060 (the yellow trace). It can happen to be shortened or elongated.
--
Jorge.
Michael J. Mahon
2017-09-14 21:03:22 UTC
Permalink
Raw Message
Post by Jorge
byte 8 bits => a bit is read roughly every 1/(300/60)/16/256/8 -> 6µs
On the tape a one takes 1000µs and a zero 500µs, so loading a bit takes 750µs on average.
600 dollars (1978 dollars!) bought you a 125x boost in speed, and that
alone was a good thing.
Consider, though, the actual effect on "user speed".

When I was developing Applesoft code (not unusual for 1980 ;-), I would
rewind the cassette deck to the start of the last-SAVEd version and LOAD
it. This would typically take a minute or less.

Then I would edit and test the program for a session lasting an hour or
two, then I would SAVE the new version after the old one--another minute.

If, during the session, I made a big change (a new fork), I might SAVE one
or two times within a sesssion.

In any case, the few minutes spent LOADing and SAVEing was a minuscule part
of my time at the computer.

My first exposure to a disk-based Apple was actually just a two-month
rental, to developed a piece of software. I certainly enjoyed the
convenience and speed of developing with a disk drive, but I had no problem
returning to my native cassette environment when the project was completed.


The disk environment was much more convenient when working with multiple
projects or pieces of code/data. Within a year I had managed to convert a
couple of SA400s to Apple-compatible drives, and secured a clone Disk ][
Controller card, and I was in the DOS game. ;-)

I've never been tempted by nostalgia to return to my cassette-based
existence, but I'm proof that there was no intrinsic reliability issue with
Apple cassettes, and it was one of the fastest cassette interfaces around.
It was quite practical.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Michael J. Mahon
2017-09-14 21:12:56 UTC
Permalink
Raw Message
Post by Michael J. Mahon
Post by Jorge
byte 8 bits => a bit is read roughly every 1/(300/60)/16/256/8 -> 6µs
On the tape a one takes 1000µs and a zero 500µs, so loading a bit takes 750µs on average.
600 dollars (1978 dollars!) bought you a 125x boost in speed, and that
alone was a good thing.
Consider, though, the actual effect on "user speed".
When I was developing Applesoft code (not unusual for 1980 ;-), I would
rewind the cassette deck to the start of the last-SAVEd version and LOAD
it. This would typically take a minute or less.
Then I would edit and test the program for a session lasting an hour or
two, then I would SAVE the new version after the old one--another minute.
If, during the session, I made a big change (a new fork), I might SAVE one
or two times within a sesssion.
In any case, the few minutes spent LOADing and SAVEing was a minuscule part
of my time at the computer.
My first exposure to a disk-based Apple was actually just a two-month
rental, to developed a piece of software. I certainly enjoyed the
convenience and speed of developing with a disk drive, but I had no problem
returning to my native cassette environment when the project was completed.
The disk environment was much more convenient when working with multiple
projects or pieces of code/data. Within a year I had managed to convert a
couple of SA400s to Apple-compatible drives, and secured a clone Disk ][
Controller card, and I was in the DOS game. ;-)
I've never been tempted by nostalgia to return to my cassette-based
existence, but I'm proof that there was no intrinsic reliability issue with
Apple cassettes, and it was one of the fastest cassette interfaces around.
It was quite practical.
BTW, last year I was poking around in the past and found my old cassettes.
I'm happy to report that they are as readable as ever, even though they
have outlasted the Panasonic deck that wrote them (so I had to create a
mapping from the original deck's tape counter to the new deck's counter)
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Jorge
2017-09-14 21:18:49 UTC
Permalink
Raw Message
Post by Michael J. Mahon
BTW, last year I was poking around in the past and found my old cassettes.
I'm happy to report that they are as readable as ever, even though they
have outlasted the Panasonic deck that wrote them (so I had to create a
mapping from the original deck's tape counter to the new deck's counter)
The silly rubber belts! That happened to mine too...

BTW, Antoine, I have some cassettes that I believe are NOT in your collection yet :-)
--
Jorge.
Anthony Ortiz
2017-09-14 21:29:46 UTC
Permalink
Raw Message
Jesus Xmas... you guys are too hardcore!
James Davis
2017-09-15 18:23:29 UTC
Permalink
Raw Message
Post by Jorge
A problem of the cassette output of the Apple II is R19 (12k), all the Apple IIs I have had have that R shorted with a wire with test clips to make it compatible with the audio line input of the Macs. Works wonderfully! BTW this is also something the ADTPro user guide should mention because a Mac can't sense properly the Apple II microphone-level signal and that totally ruins ADTPro audio transfers for Mac users.
There is no R19 in the schematic for the enhanced IIe in my TRM. Are you talking about R18 or R6, maybe?
Jorge
2017-09-15 21:52:49 UTC
Permalink
Raw Message
Post by James Davis
Post by Jorge
A problem of the cassette output of the Apple II is R19 (12k), all the Apple IIs I have had have that R shorted with a wire with test clips to make it compatible with the audio line input of the Macs. Works wonderfully! BTW this is also something the ADTPro user guide should mention because a Mac can't sense properly the Apple II microphone-level signal and that totally ruins ADTPro audio transfers for Mac users.
There is no R19 in the schematic for the enhanced IIe in my TRM. Are you talking about R18 or R6, maybe?
Is this the schematic?

http://www.applelogic.org/files/IIESCHEMATIC.pdf

If so, it would be R6... BUT I would not short it in the IIe because it's not coming off a cheap LS TTL but from a CMOS ASIC. Better safe than sorry: I'd put a 200 or 300Ω resistor in parallel with R6 NOT a short.
--
Jorge.
James Davis
2017-09-16 06:14:12 UTC
Permalink
Raw Message
Post by Jorge
Post by James Davis
Post by Jorge
A problem of the cassette output of the Apple II is R19 (12k), all the Apple IIs I have had have that R shorted with a wire with test clips to make it compatible with the audio line input of the Macs. Works wonderfully! BTW this is also something the ADTPro user guide should mention because a Mac can't sense properly the Apple II microphone-level signal and that totally ruins ADTPro audio transfers for Mac users.
There is no R19 in the schematic for the enhanced IIe in my TRM. Are you talking about R18 or R6, maybe?
Is this the schematic?
http://www.applelogic.org/files/IIESCHEMATIC.pdf
If so, it would be R6... BUT I would not short it in the IIe because it's not coming off a cheap LS TTL but from a CMOS ASIC. Better safe than sorry: I'd put a 200 or 300Ω resistor in parallel with R6 NOT a short.
--
Jorge.
Yes, Jorge, if not the same, very similar. I thought it might be R6. Later, it occurred to me to check the Apple II/II+ TRM schematics, and I found R19 there. It does correspond to R6. Good to know not to short it out completely. I think M.J.M. has written about this in the past also.

James Davis
Jorge
2017-09-16 10:27:30 UTC
Permalink
Raw Message
Post by James Davis
Post by Jorge
Post by James Davis
Post by Jorge
A problem of the cassette output of the Apple II is R19 (12k), all the Apple IIs I have had have that R shorted with a wire with test clips to make it compatible with the audio line input of the Macs. Works wonderfully! BTW this is also something the ADTPro user guide should mention because a Mac can't sense properly the Apple II microphone-level signal and that totally ruins ADTPro audio transfers for Mac users.
There is no R19 in the schematic for the enhanced IIe in my TRM. Are you talking about R18 or R6, maybe?
Is this the schematic?
http://www.applelogic.org/files/IIESCHEMATIC.pdf
If so, it would be R6... BUT I would not short it in the IIe because it's not coming off a cheap LS TTL but from a CMOS ASIC. Better safe than sorry: I'd put a 200 or 300Ω resistor in parallel with R6 NOT a short.
--
Jorge.
Yes, Jorge, if not the same, very similar. I thought it might be R6. Later, it occurred to me to check the Apple II/II+ TRM schematics, and I found R19 there. It does correspond to R6. Good to know not to short it out completely. I think M.J.M. has written about this in the past also.
200Ω should give you 1/3 of 5v: 1.6 volts, 300Ω 1/4: 1.25 volts peak to peak. The reason why it's ok to short the TTL output is because a TTL can barely drive its output to +5v and in any case it does so very weakly, unlike (I believe) that CMOS of the IIe.

With that mod in place you can try SAVE on one and LOAD in another and it should work.
--
Jorge.
Jorge
2017-09-14 17:42:43 UTC
Permalink
Raw Message
This is truly totally amazing: http://asciiexpress.net/diskserver/
Antoine Vignau
2017-09-14 18:52:50 UTC
Permalink
Raw Message
Jorge,
your calculation for the number of bytes for a sector is wrong. We save nibbles not bytes, so 342 nibbles to handle 256 sectors. At the speed of 300RPM, it is roughly 4us per bit.

I let you perform the calculation of the number of data we can have per track...

Antoine
Jorge
2017-09-14 19:21:43 UTC
Permalink
Raw Message
Post by Antoine Vignau
Jorge,
your calculation for the number of bytes for a sector is wrong. We save nibbles not bytes, so 342 nibbles to handle 256 sectors. At the speed of 300RPM, it is roughly 4us per bit.
To use a serial port analogy, you're talking bauds I'm talking bps. But you knew that already...
Michael 'AppleWin Debugger Dev'
2017-09-14 23:56:25 UTC
Permalink
Raw Message
Post by Antoine Vignau
Jorge,
your calculation for the number of bytes for a sector is wrong. We save nibbles not bytes, so 342 nibbles to handle 256 sectors. At the speed of 300RPM, it is roughly 4us per bit.
Indeed. Beneath Apple DOS, Figure 3.3 states it takes 4 μs (microseconds) to read 1 bit off the disk.
Post by Antoine Vignau
I let you perform the calculation of the number of data we can have per track...
I already did that last year :-)

https://retrocomputing.stackexchange.com/questions/503/absolute-maximum-number-of-nibbles-on-an-apple-ii-floppy-disk-track
Post by Antoine Vignau
The maximum is 8309 ($2075) nibbles for track 0.
Antoine Vignau
2017-09-15 01:59:15 UTC
Permalink
Raw Message
Jorge,
please tell me which cassettes you have. If you cannot digitize them, I can.
I'll pay shipping both ways,
Antoine

nb. "bytes" was missing between "256" and "sectors" in my previous message.
Jorge
2017-09-15 11:39:03 UTC
Permalink
Raw Message
Post by Antoine Vignau
Jorge,
please tell me which cassettes you have. If you cannot digitize them, I can.
https://imgur.com/a/Pzfck

Some come with manuals/booklets. Applesoft with the blue manual. I know there's twelve more but I could not find them at this moment.

If there's any one you don't have, which I doubt (*), I'll take pictures and digitize the audio and booklet.

(*) WOW, the cassette collection you've got @ brutaldeluxe is huge !!! Fantastic! But some of them without the audio, why?

BTW what's disk-o-tape? That sounds very interesting!
--
Jorge.
Jorge
2017-09-15 08:40:49 UTC
Permalink
Raw Message
Sorry guys but just as 1200 baud is 872.7 bps, the disk II bps is 6µs/bit not 4 :-)

Have a nice day!
--
Jorge.
Michael 'AppleWin Debugger Dev'
2017-09-15 17:21:52 UTC
Permalink
Raw Message
Post by Jorge
Sorry guys but just as 1200 baud is 872.7 bps, the disk II bps is 6µs/bit not 4 :-)
Your numbers are STILL off.

_How_ the nibbles are encoded effect the answer. Let's actually do the math.

First, recall that:

* The physical hardware takes 4 µs (microseconds) to read a bit.
* To read a full "disk nibble" -- which I'll hijack the normal "nibble" convention -- takes 4us * 8 bits / disk nibble = 32 µs/nibble.


# 4&4 Encoding

With 4&4 encoding it takes 512 nibbles to encode 256 bytes. That is, it takes a minimum of 32 µs + 32µs = 64 µs to read a full byte.

The total time to read 256 bytes/sector is:
= 512 nibbles/sector * 32 µs/nibble
= 16,384 µs / sector.

This gives us an _average_ time per bit of:
= 16,384 µs/sector / (256 bytes/sector * 8 bits/byte)
= 16,384 / 2,048
= 8 µs/bit.


# 6&2 Encoding

With 6&2 encoding it takes 342 disk nibbles to encode 256 bytes.

The total time to read 256bytes/sector is:
= 342 nibbles/sector * 32 µs/nibble
= 10,944 µs/sector

This gives us an _average_ time per bit of:
= 10,944 µs/sector / (256 bytes/sector * 8bits/byte)
= 10,944 / 2,048
= 5.34375 µs/bit

Now I didn't account for the Address field, nor Data Field -- namely the prologue and epilogue.

Address Field = D5 AA 96 v0 v1 t0 t1 s0 s1 c0 c1 DE AA EB + 8 sync nibbles
Where v# = volume, t# = track, s# = sector
= 14 nibbles * 32 µs/nibble + 8 * 40 µs/nibble
= 448 µs + 320 µs
= 768 µs

Data Field = D5 AA 96 [...342...] c0 DE AA EB
= 3 + 342 + 4
= 384 nibbles

Total time to read a sector:
= 768 µs + 384 nibbles * 32 µs/nibble
= 768 + 11,1,36
= 13,056 µs

This gives us an average time per bit of:
= 13,056 µs/sector / (256 bytes/sector * 8bits/byte)
= 6.375 µs/bit


Note: Both DOS 3.x and ProDOS waste space by doing dumb shit like using two nibbles for Volume, Track, and Sector EACH when only two nibbles are required for both the Track and Sector.


# 18 Sector

If instead we have "big sectors" such as Roland's RWTS18 which has 6 sectors of 768 bytes/track. This is equivalent to 18*256 = 4,608 bytes/track -- hence the name 18.

Total time to read a sector:
= 1,024 nibbles * 32 µs/nibble
= 32,768 µs

Average time per
= 32,768 µs / (768 bytes * 8 bits/byte)
= 5.33 µs/bit


# 19 Sector

Jon Brooks has mentioned you can use more then 64 "disk nibbles" -- all the way up to 81 nibbles reliably.

See:
* https://groups.google.com/forum/#!topic/comp.sys.apple2/6oyxBR4LpgA
Post by Jorge
Total is 6211 nib = 49,688 trk bits
Minimum time to read a sector:
= 6,211 nibbles * * 32 µs/nibble
= 198,752 µs

This gives us an _average_ time per bit of:
= 198,752 µs / (19 sectors*256 bytes/sector * 8 bits/byte)
= 198,7752 / 38,912
= 5.107 ... µs

Where are you getting 6µs/bit again ??
James Davis
2017-09-15 18:14:36 UTC
Permalink
Raw Message
Post by Michael 'AppleWin Debugger Dev'
* The physical hardware takes 4 µs (microseconds) to read a bit.
* To read a full "disk nibble" -- which I'll hijack the normal "nibble" convention -- takes 4us * 8 bits / disk nibble = 32 µs/nibble.
I don't get that!? Isn't a nibble 4 bits? 4*4=16, right?

Stopped reading at your first math mistake.
Michael 'AppleWin Debugger Dev'
2017-09-16 01:47:55 UTC
Permalink
Raw Message
Post by James Davis
Post by Michael 'AppleWin Debugger Dev'
* To read a full "disk nibble" -- which I'll hijack the normal "nibble" convention -- takes 4us * 8 bits / disk nibble = 32 µs/nibble.
I don't get that!? Isn't a nibble 4 bits? 4*4=16, right?
Yes, normally, nibble means 4 bits but we are talking about _disk nibbles_ here as I pointed out. The hardware could initially only read alternating bits reliably so the restriction was that every other bit was set to 1. So even though you were reading/write a byte it wasn't the _full_ byte -- only a full valid nibble of data. The name is unfortunate but regrettable.

Over the years Woz relaxed the rules for the disc controller to allow two consecutive zeroes.
Post by James Davis
Stopped reading at your first math mistake.
/Oblg. Chronicles of Riddick: "You made three mistakes."

Your first mistake was _assuming_ I coined a new term.

Your second mistake was being ignorant of history.

You DO realize that _Woz_ himself, the inventor of the Disk II controller, called them nibbles back in 1979, right?

COREQUS.S
https://htmlpreview.github.io/?https://github.com/Michaelangel007/apple2_dos33/blob/master/dos33.html#COREQUS

017 ***************************
018 * *
019 * MAR 18, 1979 *
020 * WOZ *
021 * *
022 ***************************

053 * NIBLIZING TABLE 'NIBL' *
054 * (64 BYTES) MAPS 6-BIT *
055 * NIBLS INTO VALID 7-BIT *
056 * NIBLS. THIS TABLE *
057 * MUST NOT CROSS A PAGE *
058 * BOUNDARY. *

Also, why did Roland Gustafsson the creator of RWTS18 call them "disk nibbles"?


; Valid disk nibbles
;
NIBBLES HEX 96979A9B9D9E9FA6
HEX A7ABACADAEAFB2B3
HEX B4B5B6B7B9BABBBC
HEX BDBEBFCBCDCECFD3
HEX D6D7D9DADBDCDDDE
HEX DFE5E6E7E9EAEBEC
HEX EDEEEFF2F3F4F5F6
HEX F7F9FAFBFCFDFEFF

Your third mistake was pretending to know more then you think you do.

Next time spend more time reading "Beneath Apple DOS" before flaming someone and pretending to understand a topic such as the Disk Controller.
James Davis
2017-09-16 07:05:10 UTC
Permalink
Raw Message
Post by Michael 'AppleWin Debugger Dev'
Post by James Davis
Post by Michael 'AppleWin Debugger Dev'
* To read a full "disk nibble" -- which I'll hijack the normal "nibble" convention -- takes 4us * 8 bits / disk nibble = 32 µs/nibble.
I don't get that!? Isn't a nibble 4 bits? 4*4=16, right?
Yes, normally, nibble means 4 bits but we are talking about _disk nibbles_ here as I pointed out. The hardware could initially only read alternating bits reliably so the restriction was that every other bit was set to 1. So even though you were reading/write a byte it wasn't the _full_ byte -- only a full valid nibble of data. The name is unfortunate but regrettable.
Over the years Woz relaxed the rules for the disc controller to allow two consecutive zeroes.
Post by James Davis
Stopped reading at your first math mistake.
/Oblg. Chronicles of Riddick: "You made three mistakes."
Your first mistake was _assuming_ I coined a new term.
Your second mistake was being ignorant of history.
You DO realize that _Woz_ himself, the inventor of the Disk II controller, called them nibbles back in 1979, right?
COREQUS.S
https://htmlpreview.github.io/?https://github.com/Michaelangel007/apple2_dos33/blob/master/dos33.html#COREQUS
017 ***************************
018 * *
019 * MAR 18, 1979 *
020 * WOZ *
021 * *
022 ***************************
053 * NIBLIZING TABLE 'NIBL' *
054 * (64 BYTES) MAPS 6-BIT *
055 * NIBLS INTO VALID 7-BIT *
056 * NIBLS. THIS TABLE *
057 * MUST NOT CROSS A PAGE *
058 * BOUNDARY. *
Also, why did Roland Gustafsson the creator of RWTS18 call them "disk nibbles"?
http://youtu.be/ScFrXoD99hw
; Valid disk nibbles
;
NIBBLES HEX 96979A9B9D9E9FA6
HEX A7ABACADAEAFB2B3
HEX B4B5B6B7B9BABBBC
HEX BDBEBFCBCDCECFD3
HEX D6D7D9DADBDCDDDE
HEX DFE5E6E7E9EAEBEC
HEX EDEEEFF2F3F4F5F6
HEX F7F9FAFBFCFDFEFF
Your third mistake was pretending to know more then you think you do.
Next time spend more time reading "Beneath Apple DOS" before flaming someone and pretending to understand a topic such as the Disk Controller.
Hi Michael,

I was not trying to FLAME you. I truly did not understand what your meant by saying, "To read a full "disk nibble" -- which I'll hijack the normal "nibble" convention ...." I did not remember that one bit on a diskette is really two, and that a "nibl" is really 8-binary digits, or a "byte" on a diskette. I stopped reading because I knew I would not understand the rest of your post until I understood what you meant by, "To read a full "disk nibble" -- which I'll hijack the normal "nibble" convention -- takes 4us * 8 bits / disk nibble = 32 µs/nibble." Now that you have made it clear, I shall continue reading your post.

I think, though, based on what your said, that Wozniak's disk "nibl" is different than a "nibble" in more than just spelling. A "nibl" is really: "one 'byte' on magnetic media representing one 'nibble' of serialized data" (input or output to or from an electronic device for interpretation or storage, respectively).

James Davis

P.S. I do not understand why everyone reads so much more into simple questions than what they ask. Why they get so offended and defensive. My wife does it every time I ask her something and then she's angry about it when I try to explain that my question did not mean what she thought, that it was just a simple question. When I do it, my neighbor always says, "Your not listening!" several times, until I understand what he is saying.
Anthony Ortiz
2017-09-16 13:12:03 UTC
Permalink
Raw Message
"P.S. I do not understand why everyone reads so much more into simple questions than what they ask. Why they get so offended and defensive."

As an unbiased observer I must say that when you replied and said "I stopped reading after your first mistake" I thought 'wow, those are fighting words', and started lamenting that our nice and cozy apple ii forum was about to go down in flames... and I'm definitely not the type of person to read something else into something. Had you said 'I couldn't understand the rest of your post' then that would have had a completely different meaning.
Michael 'AppleWin Debugger Dev'
2017-09-16 18:01:43 UTC
Permalink
Raw Message
Post by James Davis
Hi Michael,
I was not trying to FLAME you. I truly did not understand what your meant by saying, "To read a full "disk nibble" -- which I'll hijack the normal "nibble" convention ...."
Fair enough.

We both made mistakes.

Your mistake was saying:

"Stopped reading at your first math mistake. "

When it would have been far better to say:

"I don't understand why you are "hijacking" nibble. Is this a standard term or one you invented?"


My mistake was assuming that everyone knew what a (disk) "nibble" was. The term "nibble" W.R.T. Apple 2 Disk Drives has been pretty consistent and common knowledge for the past ~40 years.

I probably should have said:

-- which I'll hijack the normal "nibble" convention to use the de facto Apple 2 lingo --


I don't keep track of who is new and who isn't but I'll try to take a little more time to explain definitions in depth to prevent misunderstandings in the future.
Post by James Davis
I did not remember that one bit on a diskette is really two, and that a "nibl" is really 8-binary digits, or a "byte" on a diskette. I stopped reading because I knew I would not understand the rest of your post until I understood what you meant by, "To read a full "disk nibble" -- which I'll hijack the normal "nibble" convention -- takes 4us * 8 bits / disk nibble = 32 µs/nibble."
That was the problem -- you didn't understand, so you assumed I made a "math mistake" instead of asking a clarifying question.
Post by James Davis
Now that you have made it clear, I shall continue reading your post.
Hopefully I didn't make any actual math mistakes. :-)
Post by James Davis
I think, though, based on what your said, that Wozniak's disk "nibl" is different than a "nibble" in more than just spelling.
Interesting theory and there may be some truth to it but I believe Woz was just abbreviating "nibble."

Why?

Remember, this is from an era where assemblers restricted symbols names down to 8 characters -- for two reasons:

1) memory was _extremely_ limited -- the common case was that symbols were < 8 chars so that is the standard picked, and

2) string comparison was one of the performance (*) bottlenecks. Since string hashing on the 6502 was more expensive then just doing a raw string compare, limiting strings to 8 characters made "some" sense.

(*) A perfect example of just how bad a naive string compare performs to hashing is my project:
https://github.com/Michaelangel007/perl_crap_reference


With this restriction everybody abbreviated the fuck out of (symbol) names so they would fit.

i.e.

We see the routine is named:

PRENIB16 <-- less than 8 characters

And not the "proper" 'NIBL' name:

PRENIBL16 <-- 9 characters


Likewise we see abbreviations such as:

RDADR16 <-- "ReadAddr16"


Now one bit of evidence towards your theory is this snippet:

001 SBTL '16-SECTOR PRENIBLIZE'
002 ****************************
003 * *
004 * PRENIBLIZE SUBR *
005 * (16-SECTOR FORMAT) *
006 * *
007 ****************************

But if we keep reading down again we have more evidence that Woz was just abbreviating "nbble" whenever he needed to:

035 PRENIB1 DEY
049 PRENIB2 LDA NBUF2,X

Why didn't Woz call these PRENIBL1, and PRENIBL2, respectively ?
Was Woz just being lazy and thus abbreviating:
* "Nibble" as "NIBL" and
* "Pre-nibbilizing" as "Preniblize"?
Did Woz _intentionally_ coinning a new homonym? "Niblze"
Was Woz just a bad speller?

I don't have know. The Etymology of Woz's "NIBL" is definitely an interesting story!

I could probably count on one hand all the people in the world who would be interested in THAT answer. :-/

Other authors definitely noticed the abbreviation.

Beneath Apple DOS (B.A.D), Figure 3.17, calls this the: PRENIBBLE routine

They also use the correct spelling:

"... This is done by the 'prenibble' routine at $B800. ... Figure 3.18 shows the before and after of prenibbilizing. ..."

I do notice that the B.A.D authors use the term (with quote):

"disk" byte

as much as possible -- possibly to minimize confusion.


I understand where Woz was coming from. A disk nibble, originally, only had 4 valid bits, even though 8 bits were read.

It is too bad he didn't coin a new word.

Or if he did, maybe everybody assumed he just abbreviated it.

But here we are ~40 years later discussing it. :-)
Post by James Davis
A "nibl" is really: "one 'byte' on magnetic media representing one 'nibble' of serialized data" (input or output to or from an electronic device for interpretation or storage, respectively).
Yes, in the _context_ of the Apple 2 Disk.

Hence why I mentioned:

"The name is unfortunate but regrettable."

And use the term:

"disk" nibble

to try to minimize confusion.
Post by James Davis
James Davis
P.S. I do not understand why everyone reads so much more into simple questions than what they ask.
James, it was your tone in your second comment. "I stopped reading after your math mistake."

Instead of acknowledging that you were COMPLETELY outside your depth of field and didn't understand -- you assumed that I didn't know what I was talking about.

How we say it is just as important as what we say.

i.e. That classic "Form vs Function" debate.

ANYWAYS, it is all good. The confusion is cleared up, and we can go back to pontificating and de-railing other threads. :-)
James Davis
2017-09-16 18:35:11 UTC
Permalink
Raw Message
Post by Anthony Ortiz
"P.S. I do not understand why everyone reads so much more into simple questions than what they ask. Why they get so offended and defensive."
As an unbiased observer I must say that when you replied and said "I stopped reading after your first mistake" I thought 'wow, those are fighting words', and started lamenting that our nice and cozy apple ii forum was about to go down in flames... and I'm definitely not the type of person to read something else into something. Had you said 'I couldn't understand the rest of your post' then that would have had a completely different meaning.
Post by James Davis
Hi Michael,
I was not trying to FLAME you. I truly did not understand what your meant by saying, "To read a full "disk nibble" -- which I'll hijack the normal "nibble" convention ...."
Fair enough.
We both made mistakes.
"Stopped reading at your first math mistake. "
"I don't understand why you are "hijacking" nibble. Is this a standard term or one you invented?"
My mistake was assuming that everyone knew what a (disk) "nibble" was. The term "nibble" W.R.T. Apple 2 Disk Drives has been pretty consistent and common knowledge for the past ~40 years.
-- which I'll hijack the normal "nibble" convention to use the de facto Apple 2 lingo --
I don't keep track of who is new and who isn't but I'll try to take a little more time to explain definitions in depth to prevent misunderstandings in the future.
Post by James Davis
I did not remember that one bit on a diskette is really two, and that a "nibl" is really 8-binary digits, or a "byte" on a diskette. I stopped reading because I knew I would not understand the rest of your post until I understood what you meant by, "To read a full "disk nibble" -- which I'll hijack the normal "nibble" convention -- takes 4us * 8 bits / disk nibble = 32 µs/nibble."
That was the problem -- you didn't understand, so you assumed I made a "math mistake" instead of asking a clarifying question.
Post by James Davis
Now that you have made it clear, I shall continue reading your post.
Hopefully I didn't make any actual math mistakes. :-)
Post by James Davis
I think, though, based on what your said, that Wozniak's disk "nibl" is different than a "nibble" in more than just spelling.
Interesting theory and there may be some truth to it but I believe Woz was just abbreviating "nibble."
Why?
1) memory was _extremely_ limited -- the common case was that symbols were < 8 chars so that is the standard picked, and
2) string comparison was one of the performance (*) bottlenecks. Since string hashing on the 6502 was more expensive then just doing a raw string compare, limiting strings to 8 characters made "some" sense.
https://github.com/Michaelangel007/perl_crap_reference
With this restriction everybody abbreviated the fuck out of (symbol) names so they would fit.
i.e.
PRENIB16 <-- less than 8 characters
PRENIBL16 <-- 9 characters
RDADR16 <-- "ReadAddr16"
001 SBTL '16-SECTOR PRENIBLIZE'
002 ****************************
003 * *
004 * PRENIBLIZE SUBR *
005 * (16-SECTOR FORMAT) *
006 * *
007 ****************************
035 PRENIB1 DEY
049 PRENIB2 LDA NBUF2,X
Why didn't Woz call these PRENIBL1, and PRENIBL2, respectively ?
* "Nibble" as "NIBL" and
* "Pre-nibbilizing" as "Preniblize"?
Did Woz _intentionally_ coinning a new homonym? "Niblze"
Was Woz just a bad speller?
I don't have know. The Etymology of Woz's "NIBL" is definitely an interesting story!
I could probably count on one hand all the people in the world who would be interested in THAT answer. :-/
Other authors definitely noticed the abbreviation.
Beneath Apple DOS (B.A.D), Figure 3.17, calls this the: PRENIBBLE routine
"... This is done by the 'prenibble' routine at $B800. ... Figure 3.18 shows the before and after of prenibbilizing. ..."
"disk" byte
as much as possible -- possibly to minimize confusion.
I understand where Woz was coming from. A disk nibble, originally, only had 4 valid bits, even though 8 bits were read.
It is too bad he didn't coin a new word.
Or if he did, maybe everybody assumed he just abbreviated it.
But here we are ~40 years later discussing it. :-)
Post by James Davis
A "nibl" is really: "one 'byte' on magnetic media representing one 'nibble' of serialized data" (input or output to or from an electronic device for interpretation or storage, respectively).
Yes, in the _context_ of the Apple 2 Disk.
"The name is unfortunate but regrettable."
"disk" nibble
to try to minimize confusion.
Post by James Davis
James Davis
P.S. I do not understand why everyone reads so much more into simple questions than what they ask.
James, it was your tone in your second comment. "I stopped reading after your math mistake."
Instead of acknowledging that you were COMPLETELY outside your depth of field and didn't understand -- you assumed that I didn't know what I was talking about.
How we say it is just as important as what we say.
i.e. That classic "Form vs Function" debate.
ANYWAYS, it is all good. The confusion is cleared up, and we can go back to pontificating and de-railing other threads. :-)
Sorry Guys,

I have "foot in mouth disease" a lot.

James Davis
James Davis
2017-09-16 18:47:27 UTC
Permalink
Raw Message
Michael,

I think I read somewhere once that Woz intentionally used "Nibl" instead of "Nibble" to distinguish the difference. But, we should just as Woz.

So, Steve Wozniak, if you are reading this thread, what was your purpose in using "Nibl" instead of "Nibble"--to abbreviate or to distinguish a difference?

James Davis
Michael J. Mahon
2017-09-16 19:46:51 UTC
Permalink
Raw Message
Post by James Davis
Michael,
I think I read somewhere once that Woz intentionally used "Nibl" instead
of "Nibble" to distinguish the difference. But, we should just as Woz.
So, Steve Wozniak, if you are reading this thread, what was your purpose
in using "Nibl" instead of "Nibble"--to abbreviate or to distinguish a difference?
James Davis
You are making a mountain out of a molehill.

All that's going on (or, actually, went on a long time ago) is that the
slang term "nibble" was used for two different things. This is not unusual,
particularly when the use contexts are distinct.

Using "nibble" for half of a byte was actually deprecated by IBM, the
promulgators of the 8-bit "byte" (itself a neologism). The alternative
spelling "nybble" was suggested to clarify the relation to "byte", but
never caught on.

Woz abbreviated mercilessly, just as everyone did when identifier lengths
were limited. (BTW, identifier lengths were limited in the beginning
because computers were organized around the concept of "words", which
typically held six to eight 6-bit characters--micros just followed the
crowd. Check out FORTRAN.)
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
James Davis
2017-09-16 20:02:22 UTC
Permalink
Raw Message
Post by Michael J. Mahon
Post by James Davis
Michael,
I think I read somewhere once that Woz intentionally used "Nibl" instead
of "Nibble" to distinguish the difference. But, we should just as Woz.
So, Steve Wozniak, if you are reading this thread, what was your purpose
in using "Nibl" instead of "Nibble"--to abbreviate or to distinguish a difference?
James Davis
You are making a mountain out of a molehill.
All that's going on (or, actually, went on a long time ago) is that the
slang term "nibble" was used for two different things. This is not unusual,
particularly when the use contexts are distinct.
Using "nibble" for half of a byte was actually deprecated by IBM, the
promulgators of the 8-bit "byte" (itself a neologism). The alternative
spelling "nybble" was suggested to clarify the relation to "byte", but
never caught on.
Woz abbreviated mercilessly, just as everyone did when identifier lengths
were limited. (BTW, identifier lengths were limited in the beginning
because computers were organized around the concept of "words", which
typically held six to eight 6-bit characters--micros just followed the
crowd. Check out FORTRAN.)
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
OK, sounds reasonable. But just going back to ask the original source does too.
Jorge
2017-09-16 08:37:34 UTC
Permalink
Raw Message
Post by Michael 'AppleWin Debugger Dev'
Post by Jorge
Sorry guys but just as 1200 baud is 872.7 bps, the disk II bps is 6µs/bit not 4 :-)
Your numbers are STILL off.
[ CUT EXCELLENT EXPLANATION ]
= 13,056 µs/sector / (256 bytes/sector * 8bits/byte)
= 6.375 µs/bit
[ CUT EXCELLENT EXPLANATION ]
Where are you getting 6µs/bit again ??
:-)

Cheers,
--
Jorge.
Michael 'AppleWin Debugger Dev'
2017-09-16 17:13:03 UTC
Permalink
Raw Message
More or less. No disagreement so far.
Post by Jorge
a track has 16 sectors,
BZZZT.

Not always.

i.e.
* Br0derbund games usually don't.
e.g.
* Prince of Persia,
* Captain Goodnight has E.25 - 1.25 = $D tracks = 13 tracks of _only_ 1 sector where each sector is 8*512 nibbles --> 8*256 memory bytes long.
* Copy ][ 4.x has just one BIG sector (IIRC on tracks 1 and 2)
Post by Jorge
a sector 256 bytes,
Nope, Not always. RWTS18 has 768 bytes/sector.
Post by Jorge
a byte 8 bits => a bit is read roughly every 1/(300/60)/16/256/8 -> 6µs
1. Again, you are assuming DOS3.3 / ProDOS.
2. The bigger the sector the more you can amortize the overhead cost. Thus driving the time down.

This can vary between ~5.1µs all the way up to ~8µs -- depending on which encoding scheme was used -- as I previously showed.

Why are assuming ONLY DOS3.3/ProDOS is valid ??
Loading...