Jump to content
IGNORED

On the Edge by Brian Bagnall


Chris++

Recommended Posts

 

< SNIP >

 

The included books were a godsend. Like my prayers were heard and a whole machine called Silicon Valley was created so that I may enjoy computers up front and personal. You see, the public school system was of zero help. Students had to have like an "A" in order to get into the computer lab, let alone take a computer course. "C" or even "B+" wouldn't cut it. Math wizards only. The computer lab in my high-school was totally off limits to normal kids.

 

It seemed like the school system was still stuck in the slide-rule era from the space program where engineering and tech were still considered elite, with rocket science and all that.

 

< SNIP >

 

You were lucky to at least get that....

 

I discovered the Apple ][+s at my High School in the 10th Grade... They really didn't have any structured classes, except for some Advanced Business Classes, so Three of the Four Apple ][+s were in the one Business Classroom.. And could be used by anyone Before School, during Lunch, or After School..

 

The following year, they setup an actual Computer Lab, but it was only available to Students that took Computer Classes... The Only Classes available were, Keyboarding!!!!! If I Knew Then, what I Know Now!!!!!

 

 

MarkO

Link to comment
Share on other sites

Compared to the Apple ][. the Only Things I was envious of on the C64 was the VIC-II and SID.. Including such Powerful Capabilities in the "stock" Machine, means that Lots software utilized them....

 

Yes, the Apple ][ is so expandable, in that you can add the Super Sprite Card and MockingBoard, but how many of each of those were sold, compared to the Total Number of Apple ][s??

 

Just for Fun, Someone should Rig Up a Disk II on the C64, to see just how fast you could load stuff.....

 

MarkO

 

As a kid I wanted the Apple II to have colored text and blitting abilities for graphics. The VIC-II had a lot of nice features that games used as much as they did the SID.

 

Disk II on the C64 would be amusing. Can the C64 output a data bit every 32 microseconds without fail? Because that's what will be needed for starters.

  • Like 1
Link to comment
Share on other sites

 

Just for Fun, Someone should Rig Up a Disk II on the C64, to see just how fast you could load stuff.....

 

I had considered doing this on the TI, but it would be a major pain. The floppy controller and painful synchronization with the CPU are both required. Aside from that, with the electronics "missing" from the drive, I believe those drives are capable of only GCR encoding.

 

That said, it might be possible to interface the Disk ]['s controller to the C64 via the I/O port. They are compatible hardware architecture, one would just need the software and the precise 32μs timing.

  • Like 1
Link to comment
Share on other sites

 

As a kid I wanted the Apple II to have colored text and blitting abilities for graphics. The VIC-II had a lot of nice features that games used as much as they did the SID.

 

Disk II on the C64 would be amusing. Can the C64 output a data bit every 32 microseconds without fail? Because that's what will be needed for starters.

 

 

The C64 has the 6526, which like the 6522 has Programmable Timers.. I would be willing to bet that a IRQ could be setup to feed data to the Disk ][ at the perfect rate...

 

MarkO

Link to comment
Share on other sites

For what it is worth, the C2N232 which connects to the cassette port, is capable of communication up to 38400 bps, although buffered IIRC.

 

What is the transfer speed per second on the Disk ][? It seems like a simple question, but no matter how much I searched on the Internet, including FAQ's and other documents, I didn't find any reliable number, just that the interface is blazing fast.

 

For comparison, actual measured loading times (bytes/second) on the C64:

 

 
Speeder     C64+1541      C64+SD2IEC
No speeder   400 b/s        650 b/s
Turbo Disk  2280 b/s       5050 b/s
Jiffy       2400 b/s       8600 b/s
FC3         4150 b/s       8000 b/s
AR6         5700 b/s       n/a
SJLOAD                    10000 b/s
Proof-of-concept speeder  15300 b/s
Thus your Disk ][ interface would need to output at least 4 kB/s (32768 bps) in order to be worthwhile to implement. Perhaps that is trivial? Edited by carlsson
  • Like 1
Link to comment
Share on other sites

 

I had considered doing this on the TI, but it would be a major pain. The floppy controller and painful synchronization with the CPU are both required. Aside from that, with the electronics "missing" from the drive, I believe those drives are capable of only GCR encoding.

 

That said, it might be possible to interface the Disk ]['s controller to the C64 via the I/O port. They are compatible hardware architecture, one would just need the software and the precise 32μs timing.

 

I really doubt that the Disk ][ would read Native TI, or C64 ( or Tandy CoCo ) Disks, but the Disk ][ System being Light Weight and Speedy, and matched up with a non Apple Computer, it would interesting to see just how "optimized" you could get a Classic Computer system..

 

If all else failed, you could add an Embedded Processor to handle the communication..

 

MarkO

Link to comment
Share on other sites

Although you would throw compatibility out of the window, in theory you might be able to use Apple DOS floppy disks with Commodore compatible binaries. Compare to e.g. those ZX-81 and some Spectrum users who interfaced a 1541 to their computer, and thus got to live with Commodore formatted disks, even if the actual content were Sinclair programs.

  • Like 1
Link to comment
Share on other sites

For what it is worth, the C2N232 which connects to the cassette port, is capable of communication up to 38400 bps, although buffered IIRC.

 

What is the transfer speed per second on the Disk ][? It seems like a simple question, but no matter how much I searched on the Internet, including FAQ's and other documents, I didn't find any reliable number, just that the interface is blazing fast.

 

For comparison, actual measured loading times (bytes/second) on the C64:

 

 
Speeder     C64+1541      C64+SD2IEC
No speeder   400 b/s        650 b/s
Turbo Disk  2280 b/s       5050 b/s
Jiffy       2400 b/s       8600 b/s
FC3         4150 b/s       8000 b/s
AR6         5700 b/s       n/a
SJLOAD                    10000 b/s
Proof-of-concept speeder  15300 b/s
Thus your Disk ][ interface would need to output at least 4 kB/s (32768 bps) in order to be worthwhile to implement. Perhaps that is trivial?

 

 

The Two Drive Disk Duplicator, "Disk Muncher 1.0", can copy a 140K, 16 Sector ( 256 Bytes each ), 35 Track Disk in about 21 Seconds..

 

Rounding up to 25 Seconds, that is 5734.4 Bytes per Second, which is Both Reading and Writing, ( possibly with Verify ), so it seems reasonable to Double that Number for possible Speed, to 11468.8 Bytes per Second.

 

MarkO

Link to comment
Share on other sites

Although you would throw compatibility out of the window, in theory you might be able to use Apple DOS floppy disks with Commodore compatible binaries. Compare to e.g. those ZX-81 and some Spectrum users who interfaced a 1541 to their computer, and thus got to live with Commodore formatted disks, even if the actual content were Sinclair programs.

 

That is what I was thinking... The Benefits out weigh the Inconveniences...

 

MarkO

Link to comment
Share on other sites

Doing some thinking about Apple Disk ][s...

 

 

Standard Apple DOS 3.3 / Pascal / ProDOS

Standard AS390 Disk ][, 143360 Bytes ( 256 * 16 * 35 )
Newer Alps & Clone Disk ][, 163840 Bytes ( 256 * 16 * 40 )


EA ( Electronics Arts ) Copy Protection 18 Sector RWTS ( Read/Write, Track Sector ), by possibly 40 Tracks ???
( Slower Disk Speed needed to prevent Overwrite.. )

Standard AS390 Disk ][, 161280 Bytes ( 256 * 18 * 35 )
Newer Alps Clone Disk ][, 184320 Bytes ( 256 * 18 * 40 )

 

 

MarkO

Link to comment
Share on other sites

How many of those bytes are lost in pointers to the next sector, directory listing, block availability map and other meta data? On the 1541, you can in theory use 254 bytes out of every sector for your own data. There are 683 blocks (171848 bytes per disk side) of which 19 are used for directory track and BAM and the other 664 blocks (168656 bytes) are useable for your own files. Physically you can reach track 40 or 41 on the 1541 too, which some copy protection schemes and non-DOS disks use. So when it comes to squeezing in as much data as possible, the Disk ][ won't make an improvement, even if you can make it load faster.

Link to comment
Share on other sites

Two parts of the book that I found very interesting were the bit about the connection between one of the key people at Nintendo and Commodore (and the comments by a couple of Commodore engineers when they took a look at the NES graphics chip).

 

The other was the part about how the C64 disk drive would have been one of the fastest on the market, hadn't it been for a nasty blunder (and an imposed rush situation).

 

Had the C64 disk drive been implemented as planned, it would have helped a lot. However, I suppose people wouldn't have had as much time to sit and enjoy the cool SID tunes while waiting for a game to load.

 

Regardless, the Apple II still had the advantage of a display well-suited for productivity apps.

Link to comment
Share on other sites

What is the transfer speed per second on the Disk ][? It seems like a simple question, but no matter how much I searched on the Internet, including FAQ's and other documents, I didn't find any reliable number, just that the interface is blazing fast.

 

156,000 bits per second

Link to comment
Share on other sites

So about 19 kilobytes per second? Wow, that is very fast! A 48K game then should be able to load within 3-4 seconds, assuming it is one continuous file aligned to well interleaved blocks so the drive doesn't have to wait an extra rotation for the right block and can move the head in time. Well, at most 8 seconds to add some overhead for mechanics.

Link to comment
Share on other sites

The additional overhead would be around 25ms track-to-track seek, 600ms full stroke, 150-200ms average. Rotational latency ~100ms.

 

Artificial (and adjustable) motor spin-up time of about 1 second. Though you could shorten it or deal away with that altogether and just watch for valid data to come in, but to be safe you'd need to read the data 2x to BE SURE it was valid!

 

Yes you could load 48K very quickly - if you set that interleave correctly. And used a DOS that was matched to it. And of course there were utilities to adjust the interleave. IIRC some fast and custom DOS'es worked by loading the whole track and sorting out what was needed in memory, then discarding the rest. And these fast DOS variants didn't like non-default interleave. So.. fast dos + modded interleave = potential slow ass access.

 

I remember in the pirate days, we'd get a cracked disk tuned for speed. And it would load an Atarisoft game or some other arbitrary single-file game instantly. Click-click-click-done! And we'd copy it using standard copy utilities like FID or COPYA or something and it would slow down to "normal" load speeds. And it befuddled us kids. Somehow the "magic" got damaged unless we used a bit-copier. And yet the disk wasn't copy-protected in any way. Just the interleave & skew had been changed and DOS patched account for it.

 

Skew is like preserving interleave. Each track is a ring. And you can rotate each ring. The whole track is rotated and offset from the previous one. Just enough so that when the head jumps, its traverse time and the disks's rotational speed bring the next required sector into view perfectly. The head's trajectory and the the data's trajectory coincide perfectly and the only delay is the movement time. There is no wasted rotational slack.

 

Modern day HDD do a variant on this technique too, except they speed up the head or slow it down so that it arrives right on time. When the head gets there, the data is right under it. However we're still waiting on a spinning disk. The savings come in the form of power dissipation and noise. Millions of watts of power have been saved worldwide by doing this.

 

Another trick used to speed up disk access was to place important files near the VTOC, or the VTOC near the files. And all of it near the edge of the disk next to DOS. or turn-on delay.

 

For example Tracks 0-2 loaded DOS. Track 3 had the Volume Table of Contents or CATALOG. And 4 onward had the data. Once information was looked up in VTOC, for the file in question, you didn't need to refer back to it. So the head could progress smoothly and straight from track 0, through the catalog, then load the program with minimal seeks.

 

We had utilities to do it all, file placement, change vtoc location, modify interleave & skew, patch dos, modify/add/delete commands, relocate DOS to higher memory.. To a 10-year old kid all this mucking around was hardcore computer science! With the side effect of loading Moon Patrol at near cartridge speeds!

Link to comment
Share on other sites

Much of the DISK II was conservative 70's engineering.. Thus providing room for performance gains through tricks and stuff.

 

The workings of the Disk II mechanism were under control of the main console's 6502 exclusively. Individual parts like the stepper motor, spindle motor, read/write latches, clocking of the data.. All orchestrated by the CPU and that demanded 100% of its time. It was an exercise in industrial controls.

 

And Apple did a wonderful job of packing all this tech into a simple package where the user simply typed "LOAD PROGRAM" or "SAVE PROGRAM".

 

The next advancement in storage access wouldn't come until we had mice with point'n'click icons. And then touch screens.

Link to comment
Share on other sites

  • 4 weeks later...

Much of the DISK II was conservative 70's engineering.. Thus providing room for performance gains through tricks and stuff.

 

The workings of the Disk II mechanism were under control of the main console's 6502 exclusively. Individual parts like the stepper motor, spindle motor, read/write latches, clocking of the data.. All orchestrated by the CPU and that demanded 100% of its time. It was an exercise in industrial controls.

 

And Apple did a wonderful job of packing all this tech into a simple package where the user simply typed "LOAD PROGRAM" or "SAVE PROGRAM".

 

The next advancement in storage access wouldn't come until we had mice with point'n'click icons. And then touch screens.

 

I don't think many in the UK had experience of the Apple II , but I certainly find it fasinating to learn about what it was capable off. I was lucky enough to be able to afford 1541 for the Commodore 64 and it was far better than tapes but slow!

 

I did move onto an 800XL and a 1050 with doubler and I did prefer Atari Dos to Commodores offering. How did the Apple compare to either of these?

 

Barnie

Link to comment
Share on other sites

I really never got hung up on the Commodore 64 Basic, the user manual was decent and had lots of good examples. I actually found using POKES to use the full features of the hardware was a benefit, I learnt more about the actual machine.

 

Just to add I think its something of a myth that machines like the Apple gained because of "coding to the metal" and everything having to be done for maxium features, that was more out of necessity. Just because the Commodore 64 and Atari 8-bits had sprites , better sound and scrolling didn't mean coders didnt exploit the machines. I think because of shelf life and popularity the Commodore 64 gained more from this.

 

 

 

 

I have the Kindle Version of "On the Edge by Brian Bagnall" that I bought 3 years ago, or so..


Commodore was the leader in Getting Computers to the People, "Computers for the Masses, Not the Classes"..

But I was surprised to learn from the book that:

The Pet Sold really well in Europe, and got Commodore a much better return, so they sold few Pets here, and a lot over there..

To save costs on the Vic-20 and C64, they use the less advanced BASIC v2.00, rather than the BASIC v4.00 the Pet used.. The Vic-20 and especially the C64 Were Power Houses in RAM, Graphics and Sound, but the limited BASIC, the Poor Expansion Options ( C1541 Drives ) caused a Superior Machine to the Apple ][, to be Much Harder to do anything Practical Data Processing ( Word Processing/Data Base ) with..


Commodore provided some great products, but Fell Short in other Areas.. Over All we are all better off, for Commodore having been part of the Computer Revolution...


I still have my SX-64, and other Commodores I acquired, along the way, as well as my original Apple ][e, plus a few more Apple ][ I acquired along the way..

( Disclaimer: I was the Apple ][ owner of my family, the rest had the C64, except the Math Teaching Uncle that had the Atari 400 and 800 )

MarkO

Link to comment
Share on other sites

 

I don't think many in the UK had experience of the Apple II , but I certainly find it fasinating to learn about what it was capable off. I was lucky enough to be able to afford 1541 for the Commodore 64 and it was far better than tapes but slow!

 

I did move onto an 800XL and a 1050 with doubler and I did prefer Atari Dos to Commodores offering. How did the Apple compare to either of these?

 

Barnie

Sadly, when the Atari 800 was released, the majority of the population in the market for a computer didn't really appreciate the significance of its specifications. This was a time before a machine's capabilities as a gaming platform was a measure of its prowess.

 

So the Atari ended up being lumped into the 'toy' category (albeit an expensive toy). When I first saw one, I knew exactly what I was looking at (and I kind of freaked out). The graphics were phenomenal for the time. It was like it was alien technology or something. Later on the C64 would provide similar performance but would fight the same battle of perception by joe public.

 

The Apple II was in its own separate world and a pretty large number of Apple II users had monochrome monitors. The monochrome screens were nice and sharp and (in my opinion) easy on the eyes. It was a prominent platform in the business and education sectors. And this was before the IBM compatibles appeared on the scene. Other than that, the other obvious choice was one of the Z80-based machines like the TRS-80 series.

 

Interestingly, despite being a bare-metal no-frills computer, the Apple II really had a lot of fun games. It didn't seem to really bother (most) people that it didn't slide images around as smoothly as an Atari (or have as many colors). I liked Lode Runner on a green-screen Apple II so much that I sold my color monitor to get an Apple Monitor III instead.

 

I think that nowadays, a lot of people who didn't really appreciate the Atari 8-bit line are looking back at it in context and kind of marveling at what it could do. As with the Amiga, the fact that the Atari 800 didn't have a nice sharp screen for text display kind of hurt it from a business standpoint.

  • Like 1
Link to comment
Share on other sites

The Apple II was important in the sciences more than most people think. It found a home, believe it or not, in the space program and energy research. It just wasn't publicized like the education sector was.

 

I also thought the Atari was underrated. And by the time it was appreciated it was eclipsed by progress overall.

 

Its downside in business was lack of expansion slots AND the way the text screen was accessed. The Apple II had a simple memory array that was scanned by stupid simple 74LS logic. A most primitive "videocard" to be sure. Not many internal operations were needed to get text on the screen.

 

But the Atari had several custom chips weighing it down when it came to text. It also didn't have an 80column card, whereas the Apple had like 10 different mfgs making them. One even made a 160column board, but that was niche market.

  • Like 1
Link to comment
Share on other sites

The Apple II was important in the sciences more than most people think. It found a home, believe it or not, in the space program and energy research. It just wasn't publicized like the education sector was.

 

I also thought the Atari was underrated. And by the time it was appreciated it was eclipsed by progress overall.

 

Its downside in business was lack of expansion slots AND the way the text screen was accessed. The Apple II had a simple memory array that was scanned by stupid simple 74LS logic. A most primitive "videocard" to be sure. Not many internal operations were needed to get text on the screen.

 

But the Atari had several custom chips weighing it down when it came to text. It also didn't have an 80column card, whereas the Apple had like 10 different mfgs making them. One even made a 160column board, but that was niche market.

I was actually going to mention the sciences. I'm glad you did. I recall going to play Apple II games at a friend's house and finding out that we couldn't play any games until the Apple II finished running some physics calculations (his dad was a physics professor).

  • Like 2
Link to comment
Share on other sites

  • 3 months later...
  • 2 weeks later...

I read On The Edge from cover to cover last week during my vacation; while I knew Commodore's history in broad strokes, it really was an enlightening and compelling read - at least through the 8-bit era. I felt like the Amiga story got a short shrift largely due to his reliance on Chuck Peddle and BIll Herd's stories, but with "The Amiga Years" coming soon, hopefully that will be rectified.

 

Brian certainly had a specific story he wanted to tell, but he makes that clear from the beginning - that history is written by the victors. Commodore/MOS played a huge role in shaping the current technological landscape that has been virtually forgotten in the intervening years. I wish he was able to interview Jack or any of the Tramiel sons - that would have made it a much more balanced read. But overall it was a great book, and I look forward to his upcoming book.

Edited by Laner
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...