Jump to content
Savetz

Neanderthal Computer Things 810 Turbo

Recommended Posts

I acquired a complete-in-box "810 Turbo" device by Neanderthal Computer Things about a year ago, and finally got around to scanning the manual and imaging the disks. I didn't realize at first that this is a pretty rare beast. According to the flyer, it adds true double density, faster reads/writes, and "backup" capabilities to the Atari 810 drive. I have found a handful of references to it here in the forums, but never a picture or software or manual — until now.

 

Check out my photos of the board — looks like they opted for security through obscurity by scratching off the info about all of the chips.

 

This seems to be the only product this company made. Take a look around and let me know if you learn anything interesting.

 

Manual

Pictures of the board and images of the floppies

(ATR files also attached)

 

Neanderthal Computer Things 810 Turbo 810T Utilities.atr

Neanderthal Computer Things 810 Turbo NDOS Generator.atr

Neanderthal Computer Things 810 Turbo OS A+ V21S.atr

Neanderthal Computer Things 810 Turbo OS A+ V41D.atr

Neanderthal Computer Things LC Williams side A.atr

Neanderthal Computer Things LC Williams side B.atr

 

-Kevin

  • Like 18

Share this post


Link to post
Share on other sites

Hi,

 

It supports the Percom block for describing the disk characteristics (Page F-2 in the manual), but the notes are on page F-3, which is missing.

 

I'm guessing the chip on the underside is a WD-2793 FDC, the CPU is probably a 6502 due to the size of the address space you would need to support (I am guessing it is the one with the square bit stuck on it), and there are maybe 2 ram chips, probably 2 * 4K or 2 * 2K for the double density track buffer (you could probably get away with buffering half the track at a time, but 18 * 256 byte sectors is 4.5K). They seem a bit vague on 1050 enhanced density support, though I haven't sat down and read the manual properly.

 

I wonder if the 810 needs adjusting for a new FDC in the same way that a 1050 does?

 

Would be a fun project to make a new one.

Edited by E474

Share this post


Link to post
Share on other sites

More info in an email from the programmer, James Hugard:

 

"To help reverse engineer the hardware:

Pretty sure we used a WD2791, mainly because it needed fewer external components (had an internal phased-locked-loop data separator) and used a 1MHz clock. I was originally going to use an FD1781, but the WD sales rep convinced me the newer chip would be a better choice. Nice guy. He ended up moving to a company that was also trying to produce a double-density for the Atari, but they were manufacturing the whole drive. Can’t recall if they ever shipped, though.
Also, the PROM was 2K (not 4K like I said in the interview), but we did add 4K of RAM to replace the original 128 bytes. I was sure I could fit the firmware in 2K and wanted 4K to buffer a whole track. Later I added a download command, so I could upload code to the drive at runtime (like the disc copy firmware). Have a story about getting the code down to 2K, lol.
IIRC, we also needed to either stabilize the clock or bump it to 1MHz.
My memory on versions is a bit fuzzy, but I *think* v1.0 firmware was just double density, v1.1 added upload for disc copy, and v1.2 added 56 kbs transfer rate (over the stock 19.2 kbs)."
  • Like 4

Share this post


Link to post
Share on other sites

I just talked to the programmer. Only 300 of the device were made.

 

-Kevin

Thanks for sleuthing and scanning, Kevin! I wish every storage mod we get these days would come with a manual as detailed as the 810T’s.

 

May we expect an interview?

 

I guess the 810T mod was too pricey and too late to sell more. I did a quick search for 2791s and unless that can be done in FPGA already, they don’t seem to be plenty, so even recreating an 810T might be tough or at least expensive.

 

 

Gesendet von iPhone mit Tapatalk

Share this post


Link to post
Share on other sites

Is the drive firmware planned to be dumped Kevin...

 

It claims to use a Happy Menu but its clearly been modded as the Happy Disk included shows a working drive but the diagnostics disk says it NOT a turbo :)

 

Just wondering how it rates on the merit scale as a backup drive?

Share this post


Link to post
Share on other sites

Interesting upgrade. Seems something similar to the Happy. They even copied some Happy ideas like the compactor, but they went further with the double density upgrade.

They mention problems with the CPU on the manual. It used a plain 6507 (as the Happy 810 did), not an upgraded 6502. The user was supposed to reuse the same CPU originally on the 810 board. But according to the manual not all chips were compatible and they recommend replacing it with a new chip if needed, that should have been MOS or Rockwell branded, but not Synertek. Strange. May be this has to do with the upgraded frequency. The original 810 runs the CPU at 0.5 Mhz, and for double density they likely increased it to 1.0 MHz. Still, all 650X should run fine at 1.0 MHz.

I did a quick search for 2791s and unless that can be done in FPGA already, they don’t seem to be plenty, so even recreating an 810T might be tough or at least expensive.


The 2791 FDC is identical to the 2793 used in the 1050 but with an inverted data bus. Shouldn't be too difficult to adapt a 2793 if needed, or just modify the ROM.

I wonder if the 810 needs adjusting for a new FDC in the same way that a 1050 does?


It doesn't depend on the drive. The chip itself need adjustment. But because of this they could have shipped the FDC already adjusted at the upgrade board.

Edited by ijor
  • Like 2

Share this post


Link to post
Share on other sites

It claims to use a Happy Menu but its clearly been modded as the Happy Disk included shows a working drive but the diagnostics disk says it NOT a turbo :)

I missed that the LC Williams disk is actually a Happy disk ...

 

Was it really included with the upgrade? Wouldn't make much sense.

Share this post


Link to post
Share on other sites

I missed that the LC Williams disk is actually a Happy disk ...

 

Was it really included with the upgrade? Wouldn't make much sense.

 

 

I found the LC Williams disk in the Neanderthal binder, but it was not an official-looking label. Maybe just someone's project that was not really part of the upgrade.

 

-Kevin

Share this post


Link to post
Share on other sites

Is the drive firmware planned to be dumped Kevin...

 

 

I don't know how nor have the equipment. Perhaps I can lend the card to someone to do the work.

 

-Kevin

  • Like 1

Share this post


Link to post
Share on other sites

>May we expect an interview?

Yes. It's already done, actually, just waiting on some things before I publish it.

 

-Kevin

  • Like 4

Share this post


Link to post
Share on other sites

Thanks for the reply Kevin, and the Happy disk is now mostly explained...

 

As for the dump, I'm sure there's numerous people who could help with that...

Share this post


Link to post
Share on other sites

Late to the party (topic) here, but WOW, this is amazing Kevin!

 

This upgrade was always a mystery to me, as I believe it was the *ONLY* upgrade that ever gave the 810 double density support. Ads in the magazines, and Michael Current's FAQ were very sparse on details. It is widely known that the 810 was completely incapable of MFM encoding (double density) due to the WD1771 controller chip, and every other upgrade out there continued to use the same controller chip and CPU at 500Khz clock rate. Looks like a LOT of work went into the creation of the hardware upgrade, as well as the included customized software and utilities. I suspect that the release of the 1050 seriously cut into people's interest in the 810 and upgrading them by the time this upgrade was available... The 810's had a long series of troubles and upgrades before they were finally 'reliable' so understandable that people 'had enough' with them. And they were loud, haha. :)

 

Reading through the manual and the authors notes confirmed a few unique things about this upgrade:

 

- The CPU is a 6507 (actually clearly documented in the manual), but clocked up to 1Mhz. It had to be removed from the 810's side board, and installed into the 810T board. The many references to the likelihood of an "Incompatible CPU chip" was most likey due to the original 6507 that Atari installed being incapable of 1Mhz. In the tradidion of Atari re-using overstocked parts, the 6507's used in the 810's maybe units that failed QA for the 2600 running at 1.19MHz, but ran fine at 500Khz. Supporting this is the reference in the manual to preferred brands if you have to seek out a replacement: "DO NOT get a SYNERTEK". Atari was one of Synertek's major customers, so avoiding them was probably a good way to avoid the inferior chips. :)

 

- PERCOM block support is interesting. Although, the density detection/configuration seems much more manual compared to an actual PERCOM drive, or other DD capable drives and upgrades, but this could just be because of the lack of DD capable DOS's at the time. Smart DOS, TOP DOS, and SpartaDOS I suspect will switch densities much more transparently... (ie Switch & retry after r/w error was the big 'feature' of smart-dos)

 

- Interestingly it requires removal of the Atari data separator board if one is installed, which means that the controller on the 810T includes it. (And confirmed by Kevin's note from the creator "...WD2791, mainly because it needed fewer external components (had an internal phased-locked-loop data separator")

 

E474 mentioned above "I wonder if the 810 needs adjusting for a new FDC in the same way that a 1050 does?"

- The manual states "Under no circumstances are you to alter the two small components on the left of the board. They are preset for proper operation, DON'T TOUCH THEM!"

- Looking at Kevins pictures of the top side of the board, these sure look like a variable resistor and trimpot that would tuned specifically for MFM and the specific controller chip on the PCB. Makes sense that they would be calibrated and loctite applied before shipment.

 

- Since the author has noted to kevin that the EPROM is 2KB, it's most likely a 2516.... but no larger than a 2532 or 2732, at 24 pins. Being that this ROM is labelled as v1.2 (with "56000" speed support), this will be the most interesting version. Kevin, if you are willing to carefully peel up the label on the chip, you can hopefully see the EPROM part #.. If it is a 25xx EPROM, it is possible to dump the ROM without having to ship it to anyone using a socketed 8KB Atari brown-shell cartridge (ie BASIC). I've recently had success with this method dumping the Astra 1000 2516, and 850 2332. I can PM you details if this looks like a feasible prospect. If you are not comfortable doing this, I would love to assist getting this EPROM dumped. (I'd also love to install this into an 810 and document it in action haha!)

 

The manual was well written, detailed. and a fun read. There's a few gems:

  • "The floppy disk controller chip in the 810T will blow sky high if you attempt to use it directly in the 810 side board"
  • "...ground yourself one last time by touching something (refrigerator, another person) before sitting down to work."
  • "...IC chip (the little rectangular components with a million legs coming out of them)."
  • "Atari service centers don't like altered 810's."
  • "FROM HERE ON YOUR DISK DRIVE WILL BE CALLED THE '810T'. IT IS NO LONGER JUST A MUNDANE 810 DISK DRIVE."
  • "If the first disk is single density, the 810T just backs up, kicks into single density mode and reads its' little heart out."

This passage in the "Do's and Don'ts" section is interesting: "DO... re-format your disks from now on. The ones you have formatted now will work okay, but formatting them with the 810T will give you a faster read/write."

- The 'standard' skews created by the stock Atari rev B/C/E ROM's formatted disks with a slower skew than the hacked 'Chicago' firmware (which I've delved into in a previous topic) which was later adopted by the 810 Chip/Archiver, 810 Happy, and the 1050 US Doubler, and more. Given this enhancement is such a latecomer to the game, I'd like to learn what skew it formats, and I suspect it has also adppted the "chicago" skew. Disks formatted with this skew provide enhanced burst read/write speed even for stock Atari 810's.

 

The passage regarding Mach 2XH DOS that will "read and write data from double density disks at a rate that is equal to or in excess of 4 times the rate of a vanilla 810" sounds a lot like Ultraspeed support. The Happy 810 was originally only capable of its proprietary "Warp Speed" at ~38Kbps, and the v7 ROM added 'UltraSpeed' emulation at 54Kbps. Kevin's notes above from the author indicate "v1.2 added 56 kbs transfer rate", (54 vs 56 is a common misconception) So i wonder if it really is 56Kbps capable, and if that speed uses standard UltraSpeed negotiation introduced with the US Doubler, and adopted by so many other upgrades.

 

- Given that the 6507 has an 8KB address space, and the author indicates there was 4KB of RAM, the two 'unmarked' 24 pin chips on the PCB are most likely 2x2KB 6116 SRAM's like seen on the earlier Happy boards. 4KB is enough to buffer a whole single density track (2304 bytes) but not enough for a whole double density track (4608 bytes) so I am doubtful this drive employs track buffering. The mentions about reformatting disks for enhanced speed would lend to support this, but the "56K" speed would complicate this... Happy does it with a track buffer, US Doubler does it with an optimized skew without a track buffer...

  • Like 3

Share this post


Link to post
Share on other sites

Interesting... in a review in the August 1984 issue of Antic: https://archive.org/details/1984-08-anticmagazine/page/n55

 

"The Turbo also lets you use Mach DOS, which is included with the circuit board. Mach DOS speeds data transfer to about four times its normal rate (which makes it comparable to Happy Computing's Warp Speed)."

 

So the highspeed routines used by Mach DOS may shed some insight as to the protocol the 810 Turbo supports.

 

"In addition, because the Turbo uses track buffering, it permits faster data transfer even without Mach DOS."

 

Track buffering! What is this sorcery.... in a drive that doesn't have enough RAM to buffer an entire double-density track.... Maybe some intelligence to cache 'most' or 'recent' sectors... Secrets to be revealed. :)

  • Like 2

Share this post


Link to post
Share on other sites

I recently bought an 810 side board with the vague plan of hacking it into a Happy 810 (and still have the original in case I botched it) but converting it into an 810T would be even better 🤪

  • Like 1

Share this post


Link to post
Share on other sites

I recently bought an 810 side board with the vague plan of hacking it into a Happy 810 (and still have the original in case I botched it) but converting it into an 810T would be even better

Are 810 Happy boards still available somewhere?

Share this post


Link to post
Share on other sites

Are 810 Happy boards still available somewhere?

B&C ComputerVisions aka myatari last published price list from June 2018 listed: (before they took it off the website) https://web.archive.org/web/20180602020226/http://www.myatari.com/atarixlh.txt

 

810 Happy gives an 810 disk drive 100% faster data transfer
plus allows easy backup of almost all software.

ACA008   HAPPY 810 UPGRADE               99         
Turns a stock 810 into a 810 Happy drive
ACA009   HAPPY 810 ROM UPGRD >5000       24.95
ACA010   HAPPY 810 ROM UPGRD <5000       24.95         
Upgrade Rom for original 810 Happy Drives
  • Like 2

Share this post


Link to post
Share on other sites

Lemme see if I can clear up a few questions from above:

 

  • My recollection is we used the WD2791, but it is possible we inverted/buffered signals and actually used a 2793.
  • The Synertek 6507 didn't implement all the same instructions as the Rockwell and MOS versions.  I needed to reduce code by about 8 bytes to fit a 2K ROM when adding turbo-speed serial I/O and code-upload (for disk copy, etc), and it took me a couple of weeks of hard thought.  Had to reach for several undocumented opcodes, but as we found out after the fact, Synertek didn't implement those instructions, so was totally incompatible.  No way could I fit everything otherwise, and man I tried.  IIRC, a couple of people hit problems with 1MHz, but largely the issues were all Synertek.
  • No, with DD, 4K can't buffer an entire track at once.  IIRC, it was either 1/2 track at a time or I bank-switched RAM.  We had a spare PIO pin available & Charles  suggested bank-switching the ROM (making it 2x2K pages), but I wanted RAM not ROM!  Pretty sure we ended up with 2x2K SRAM, though, and pretty sure we didn't bank switch anything in the end.
  • Can't recall the exact transfer rate (thought it was 56.4KB/s), but I do remember figuring out how to eliminate one clock cycle from the loop.  Unlike the Happy, we were running 1MHz so it might have even been 64KB/s or 72KB/s.  I think I hit the max transfer rate supported by the 400/800 SIO, but will probably take someone disassembling my code or measuring the rate and my recollection might just be wishful thinking, lol.
  • On the sector interleave, someone will need to disassemble the code to check.  I think I formatted single density with something akin to Chicago interleave (but better?) after a lot of empirical testing.  (@Nezgar called this skew, which is IMHO incorrect).
  • In addition, best I could tell, factory format floppies used the physical disk timing hole to align sector 1, which means when stepping track-to-track, there was a delay waiting for sector 1 to rotate under the head.  My formatting code put sector 1 under the head with a small delay after a step, so was in general faster track-to-track (this is called track skew).
  • Interleave didn't matter, though, because IIRC my code would read the first track and record the sector interleave, then buffer the entire track in one revolution.  (Possible I just wanted to do that, but never implemented it - curious what the disassembly shows)
  • For double density, I think I went with sequential 1,2,3,4 because with buffering I could read data that fast (or, it was 1,3,5, etc.) .  I might have also used the interleave-storage trick above for DD.
  • Have not re-read the manual, but the Atari disks ran at 288 RPM.  We supplied a utility to read the rate and there might have been some performance gain to be had by tuning that upwards towards 300 RPM, but TBH don't remember the details... 300 RPM was too fast for the number of sectors we put on the disk though, so probably best to tune for 288 RPM. 
  • Like 11
  • Thanks 2

Share this post


Link to post
Share on other sites

Hi James,

 

Welcome and thanks a lot for your input. It is always so great to have information first hand from the original developers. And congratulations for what seems to be a great development. Guess you were unlucky and were a bit too late with Atari releasing the 1050 soon after your product.

 

Quote

The Synertek 6507 didn't implement all the same instructions as the Rockwell and MOS versions.  I needed to reduce code by about 8 bytes to fit a 2K ROM when adding turbo-speed serial I/O and code-upload (for disk copy, etc), and it took me a couple of weeks of hard thought.  Had to reach for several undocumented opcodes, but as we found out after the fact, Synertek didn't implement those instructions, so was totally incompatible.  No way could I fit everything otherwise, and man I tried.  IIRC, a couple of people hit problems with 1MHz, but largely the issues were all Synertek.

 

I don't have a Synertek 650X to actually try, but I'm not sure that can be right. All the original 650X manufacturers used (almost) the same fab mask provided by MOS. They only changed the branding at the metal layer. But they didn't developed their own version. All the undocumented opcodes should be supported. It was only years later, when they started manufacturing extended CMOS versions that they actually remade the design adding some new opcodes, and then the undocumented opcodes were gone.

 

The undoc opcodes were used by several programs. If the Synertek doesn't implement them then it would be incompatible with all that software and we surely would have known.

 

Quote

On the sector interleave, someone will need to disassemble the code to check.  I think I formatted single density with something akin to Chicago interleave (but better?) after a lot of empirical testing.  (@Nezgar called this skew, which is IMHO incorrect).

 

Both terms were sometimes used to refer to the same thing. Yes, skew was used mainly for the alignment between tracks. But unfortunately ICD use the expression "sector skew" to actually refer to sector interleave, introducing some confusion to the terminology.

 

Quote

In addition, best I could tell, factory format floppies used the physical disk timing hole to align sector 1, which means when stepping track-to-track, there was a delay waiting for sector 1 to rotate under the head.  My formatting code put sector 1 under the head with a small delay after a step, so was in general faster track-to-track (this is called track skew).

 

Not really. Most Atari 8-bit original disks, especially the older ones, were duplicated without physical alignment to the index hole. But, yes, many do were aligned and sometimes that was even used as part of the protection.

 

Do you remember anything about the software to copy copy protected disks?

 

Thanks again! :)

Edited by ijor

Share this post


Link to post
Share on other sites
13 hours ago, ijor said:

If the Synertek doesn't implement them then it would be incompatible with all that software and we surely would have known.

Are you certain the 6507 from Synertek wasn't a cleanroom design?  My recollection is that every drive sent to us that wouldn't boot had a Synertek part.  It might have been speculation, but I believe I verified that the opcodes in question were being executed as NOPs.

 

13 hours ago, ijor said:

Both terms were sometimes used to refer to the same thing.

Much to my annoyance, lol.

 

13 hours ago, ijor said:

Do you remember anything about the software to copy copy protected disks?

Well, the program was written in Val/Forth and IIRC uploaded dup firmware to the drive at runtime.  My code handled arbitrary sector interleave (which gives different read timings), duplicated sectors (with different content), and specific track-to-track skewing (which also gives different read timings).  Fairly certain I also recreated intentionally bad sectors and omitted sectors.  Minor story around choosing Val/Forth, but will save that for the (amended) interview.

 

Anything else you'd like to know?

  • Like 5

Share this post


Link to post
Share on other sites
50 minutes ago, jhugard said:

Are you certain the 6507 from Synertek wasn't a cleanroom design?  My recollection is that every drive sent to us that wouldn't boot had a Synertek part.  It might have been speculation, but I believe I verified that the opcodes in question were being executed as NOPs.

 

 

Anything else you'd like to know?

Thanks for sharing information about this fascinating add-on!

 

You might mix up the 6507 and 65C02 here. The latter executed illegal 6502/7 opcodes as NOPs but would have allowed saving space with some extra opcodes (such as STore Zero or direct pushing of X and Y registers onto the stack).

  • Like 1

Share this post


Link to post
Share on other sites
7 hours ago, jhugard said:

Are you certain the 6507 from Synertek wasn't a cleanroom design?  My recollection is that every drive sent to us that wouldn't boot had a Synertek part.  It might have been speculation, but I believe I verified that the opcodes in question were being executed as NOPs.

 

Synertek was an official second source for MOS. It used almost the same mask. But as said, you might be mixing up with CMOS variants. CMOS parts were a complete new design and they didn't implement the undoc opcodes. I don't remember hearing about any 6507 CMOS part though. May be you tested a Synertek CMOS 6502 somehow, and assumed 6507 Synertek NMOS (not CMOS) would behave the same?

Quote

Well, the program was written in Val/Forth and IIRC uploaded dup firmware to the drive at runtime.  My code handled arbitrary sector interleave (which gives different read timings), duplicated sectors (with different content), and specific track-to-track skewing (which also gives different read timings).  Fairly certain I also recreated intentionally bad sectors and omitted sectors.  Minor story around choosing Val/Forth, but will save that for the (amended) interview.

Very interesting. Seems you invested a lot of time and effort. Just out of curiosity, did you have any contact with the other people/companies involved in similar developments, like Happy, Spartan/ICD (The Chip/Archiver)?

 

Thanks once again :)

  • Like 2

Share this post


Link to post
Share on other sites
On 6/18/2019 at 6:07 PM, ijor said:

May be you tested a Synertek CMOS 6502 somehow, and assumed 6507 Synertek NMOS (not CMOS) would behave the same?

Quite possible as this was a loooong time ago, lol.

 

In any event, IIRC we had 100% failure on the Synertek 6507 for whatever reasons - hence, the compatibility note in the manual.

Share this post


Link to post
Share on other sites
On 6/18/2019 at 6:07 PM, ijor said:

Very interesting. Seems you invested a lot of time and effort. Just out of curiosity, did you have any contact with the other people/companies involved in similar developments, like Happy, Spartan/ICD (The Chip/Archiver)?

Pretty sure we had a phone conversation once with the Happy folks.  I was a HUGE Scott Adams fan and consumed everything he produced, so even speaking with his brother was kind of a big deal.  Can't remember details of the conversation, but we may have brainstormed on copy protection schemes.  They may also have expressed concern we had used some of their code.  Furthest thing from the truth - everything was clean room.  Well.  Ok.  Tom did manage to get a printout of the source code for the original 810 firmware when I was stumped on something (reliable track formatting, maybe?), but at best it pointed to an answer and at worst was unhelpful; in either case, the code was all mine.  Never disassembled the Happy code, but I did work damn hard to beat them on features, reliability, and performance.

 

On 6/18/2019 at 6:07 PM, ijor said:

Seems you invested a lot of time and effort.

End to end, was over a year of effort.  I think it was about 3 months to get to working v1.0 firmware going after building the hardware prototype, but then spent 9 months or so on bug fixes, copy protection, timing utilities, high-speed I/O, and working with Stace on OS/A+ (though he wrote all the code for that).

 

Edited by jhugard
  • Like 1

Share this post


Link to post
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.

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...