Neanderthal Computer Things 810 Turbo

[ijor]

5 hours ago, jhugard said:

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.

 

May be you are not aware, but Happy 810 firmware is actually just the original Atari ROM patched. Almost all the original Atari code is there verbatim. We had a thread about that some time ago. We wondered if that was legal or not. If he received some kind of authorization from Atari  (I really doubt that), and if Atari was aware about this at all.

 

Quote

Never disassembled the Happy code, but I did work damn hard to beat them on features, reliability, and performance ... 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).

 

Very interesting again. Looking forward to actually test your code We might be able to do that under emulation.

[+Nezgar]

On 6/21/2019 at 11:56 AM, jhugard said:

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.

I commend you on your efforts to engineer your own code! There's pretty lengthy thread here on AA where the Happy ROM's were disassembled and analyzed, and it was found that most of Atari's original 810 ROM code was still there, with patches to the additional Happy code. Which is funny when looking at the efforts to 'protect' the work, by making a custom bank switched ROM, scratching off chip identifiers, and even using 209 bytes of 458 extra bytes in the 1050 ROM to taunt would be hackers.

THIS ROM PROGRAM COPYRIGHT (C) 1984 HAPPY COMPUTERS, INC.  ALL RIGHTS RESERVED.  VIOLATORS WILL BE PROSECUTED.  (OPINION):  IF YOU SPEND YOUR TIME TRYING TO FIGURE HOW THIS PROGRAM WORKS THEN YOU HAVE REDUCED YOUR MENTAL CAPACITY TO BECOME A SLOW IDIOT!  A $1.00 MICROPROCESSOR (CHARACTERIZED AS A SWIFT IDIOT) FIGURES OUT THIS PROGRAM IN JUST SECONDS....JUST SOMETHING TO CONSIDER AS THIS PROGRAM IS MORE COMPLICATED THAN ANY PREDECESSOR.  IF YOU VIOLATE OUR COPYRIGHT BE PREPARED TO PAY THE FULL PENALTY PROVIDED BY LAW

I guess Atari was too busy losing billions to care.

[+Nezgar]

Many thanks to Kevin @Savetz for entrusting me with a loan of this rare board after some logistics to get it to me in Canada safely.

 

I have now had a chance to take a look at the EPROM. Carefully lifting the label shows that it was spared the scratching off of the identifiers like the other chips, and revealed its a TMS2516JL-35.  (A 2KB EPROM as expected, J=Ceramic, L= 0°C to 70°C temp range, and access time max 350ns, mfg Jul 1983)

 

Conveniently, the pinout is similar to the 2732 (NOT the 2532), so I was able to simply read it as a 2732 without any pinout adapting. This resulted in a successful read of the 2KB repeated twice as 4KB. Repeated verifies proved the read consistent, so I hope this is good!

 

It also means if the board is ever straight up replicated, a more common 2732 EPROM may be a compatible direct replacement.

 

The code may be tight, but the 6 bytes of text "(c)NCT" managed to be squeezed near the end of the ROM.

 

I look forward to seeing what we can learn from the ROM dump, and finding answers to some of the questions presented in this thread. In the mean time, it will be a little more time before I attempt installing this in a real 810 to see it in action.

 

810TurboV1.2.BIN

[phaeron]

Commented disassembly attached.

• Single and double density only, no medium density support in the firmware (though the hardware should support it).
• Supported commands beyond stock 810 are Read PERCOM, Write PERCOM, and a combined read/write/execute command ($20). There is no ROM read protection like on the Happy.
• Command table is in RAM and can be extended.
• Idle timeout, step rate, and retry count are all configurable, but only through code upload as the firmware exposes no commands to change them.
• No high-speed or track buffering in the firmware. 4K RAM is almost completely unused until code is uploaded.
• Not sure write verify works correctly. It is checking bytes with the V flag instead of the Z flag.
• Most code has been rewritten or extensively reworked, but there are a couple of routines that are nearly the same as their 810 counterparts, notably the track/sector division routine.
• Density check is a bit long as it waits for the normal full sector not found timeout, and requires a computer cycle to reset.
• The receive data frame code is, uh, interesting.

I have the firmware almost working in Altirra but there is a problem with hanging in the double-density test in the diagnostics that I need to debug.

 

810turbo.s

[Mclaneinc]

All you guys amaze me, terrific work by all...Thank you!!

 

Don't want to interrupt the thread but allround work like this deserves more than a like box ticked..

 

On with the progress....

Edited August 2, 2019 by Mclaneinc

[+Larry]

Question... how reliable are DD disks from the 810 Turbo?  Scuttlebut back in the day was the the mechs. just weren't good enough to give stable DD performance.  Still, a great find.

Larry

[+Nezgar]

19 hours ago, Larry said:

how reliable are DD disks from the 810 Turbo?  Scuttlebut back in the day was the the mechs. just weren't good enough to give stable DD performance.

I expect this belief is just hearsay from trying to explain why nobody tried to do DD on the 810. I havent had a chance to look up specific model numbers for the mechs involved, but I'm pretty sure the tandon mechs used in 810's mfg from November 82 onwards were similar to the double sided mechs used in the original IBM PC. (Which was very definitely MFM double density) Even pictures I've seen of venerable Atari 815 have both MPI and Tandon single sided mechs, same as the 810.

 

I think most of the problems with the 810 that gave it a bad reputation were the original production run units, prior to the updates for the separated power/analog boards (original was combined) that improved power stability which in turn stabilized RPM.

 

I don't think there's any other upgrades for the 810 that replaced the controller chip, all others (happy, the chip/archiver) only changed the ROM and RAM.

[+Nezgar]

Thanks so much phaeron, interesting findings, especially the apparent lack of track buffering, at least in this firmware.

 

For those that may have missed it, I just saw phaeron posted an update to Altirra which now includes Turbo 810 emulation according to the release notes:

 

[+Larry]

15 hours ago, Nezgar said:

I expect this belief is just hearsay from trying to explain why nobody tried to do DD on the 810. I havent had a chance to look up specific model numbers for the mechs involved, but I'm pretty sure the tandon mechs used in 810's mfg from November 82 onwards were similar to the double sided mechs used in the original IBM PC. (Which was very definitely MFM double density) Even pictures I've seen of venerable Atari 815 have both MPI and Tandon single sided mechs, same as the 810.

 

I think most of the problems with the 810 that gave it a bad reputation were the original production run units, prior to the updates for the separated power/analog boards (original was combined) that improved power stability which in turn stabilized RPM.

 

I don't think there's any other upgrades for the 810 that replaced the controller chip, all others (happy, the chip/archiver) only changed the ROM and RAM.

You well could be right about the reliability -- for sure the IBM's MFM DD was quite reliable. Still, that was only 9 sectors/track for IBM, so that makes things a bit easier.  I always had some reliability issues with Atari 1050 5-1/4" (Tandon) DD, even with good disks.  Not terrible by any means, but not as good as Atari 3-1/2" DD or 5-1/4" DD from IBM or the later Atari XF551.  I still have IBM 5-1/4" disks that can be read today.

 

[Mclaneinc]

Oops, missed a post 2 above...

Edited August 5, 2019 by Mclaneinc

[jhugard]

phaeron, excellent job on the disassembly!

 

On 8/2/2019 at 2:01 AM, phaeron said:

Not sure write verify works correctly. It is checking bytes with the V flag instead of the Z flag.

On checking the V flag, that would be testing bit-6 of the RIOT Port A.  For the life of me, I cannot recall exactly what the bits were wired to.  Do you have definitions of bit-7 and bit-6 of that port (schematic of what they were wired to)?

 

I'm suspecting they were hooked to the 279x DRQ (data request) on bit-7 and INTRQ (interrupt request/command complete) on bit-6.  That makes for loops checking bit-7 for data ready (BMI) and bit-6 for error (BVS).

 

If so, then the code should look like the following (sorry for the tabs):

;===============================================================================
; Verify sector
;
FB8D: A9 77		LFB8D	LDA		#$77		;inverted $88 (read sector)
FB8F: 20 94 F8			JSR		LF894		;issue FDC command
FB92: A2 06				LDX		#$06		;~1.5s total timeout
FB94: A0 00				LDY		#$00
FB96: A9 FF		LFB96	LDA		#$FF		;~260ms timeout
FB98: 8D 9F 03			STA		$039F		;start timer
FB9B: B8				CLV                 ;JH: clear error flag
FB9C: 70 1D		LFB9C	BVS		LFBBB       ;JH: exit if error
FB9E: 2C 80 03			BIT		$0380       ;JH: get ready/error
FBA1: 30 11				BMI		LFBB4       ;JH: jump if byte ready
FBA3: AD 85 03			LDA		$0385       ;JH: check for timeout
FBA6: 10 F4				BPL		LFB9C       ;JH: jump if not expired
FBA8: CA				DEX                 ;JH: dec timeout
FBA9: D0 EB				BNE		LFB96       ;JH: loop if not timed out
FBAB: F0 0E				BEQ		LFBBB       ;JH: exit on timeout

FBAD: 70 0C		LFBAD	BVS		LFBBB       ;JH: exit on error
FBAF: 2C 80 03	LFBAF	BIT		$0380       ;JH: get ready/error status
FBB2: 10 F9				BPL		LFBAD       ;JH: loop if byte not ready

FBB4: A5 03		LFBB4	LDA		$03			;read byte from FDC
FBB6: D1 88				CMP		($88),Y		;JH: compare with expected byte
FBB8: C8				INY                 ;JH: bump write buffer index
FBB9: 50 F4				BVC		LFBAF       ;JH: loop if no error detected earlier

FBBB: A5 00		LFBBB	LDA		$00			;read inverted FDC status
FBBD: 85 8C				STA		$8C			;stash it
FBBF: 49 FF				EOR		#$FF		;uninvert to return
FBC1: 60				RTS

 

 

 

Edited August 6, 2019 by jhugard

[jhugard]

On 8/2/2019 at 2:01 AM, phaeron said:

The receive data frame code is, uh, interesting.

Wa'cha mean by "interesting"?

[+Nezgar]

2 hours ago, jhugard said:

For the life of me, I cannot recall exactly what the bits were wired to.  Do you have definitions of bit-7 and bit-6 of that port (schematic of what they were wired to)?

I saw this near the top of phaeron's disassembly: (I'm not adding any authority to the accuracy of this!)

;RIOT port A:
;	Input	D7=1	FDC data request
;	Input	D6=1	FDC interrupt request

I don't believe we have a schematic. (yet) But I do plan to take some more detailed photos of the board with more chips removed as it may help in that endeavour. Looks like only the 2 SRAMs and the 3 LS-logic type chips are not socketed. The EPROM, CPU, RIOT, and WD controller are all socketed. With those removed it may be easier to see where the traces go.

 

Looking further through the disassembly, I saw the notes about the format sector interleaves:

Single density: 2 4 6 8 10 12 14 16 18 1 3 5 7 9 11 13 15 17 (Looks like there was a typo, 15 was repeated twice, the first 15 should be 16)

Double density: 13 7 1 14 8 2 15 9 3 16 10 4 17 11 5 18 12 6

 

The single density 9:1 interleave essentially matches the Atari 810 stock Rev "C" ROM's interleave (18 1 3 5 7 9 11 13 15 17 2 4 6 8 10 12 14 16) but starts sector 1 later in the rotation. This would potentially help reduce the wait for sector 1 of the next track after reading sector 18 and stepping from the last track. Otherwise, the same single density 9:1 interleave is also used in the stock Atari 1050, XF551, Happy 1050, Speedy 1050, but most of those have sector 1 at the beginning.

 

The double density 3:1 interleave is unique. But in practice without buffering, it would be a full rotation + 3 wait for the next sector, so 21:1. Other known implementations use 14:1 (1050 Turbo, Toms 1050, Tygris 1050), 15:1 (Happy 1050, Speedy 1050, XF551, Percom, ATR-8000), or 17:1 (US Doubler, Super Archiver). 21:1 might allow for more time between each sector for RPM variance or processing delays in the drive or computer without blowing revs without track buffering.

[phaeron]

11 hours ago, jhugard said:

On checking the V flag, that would be testing bit-6 of the RIOT Port A.  For the life of me, I cannot recall exactly what the bits were wired to.  Do you have definitions of bit-7 and bit-6 of that port (schematic of what they were wired to)?

I had forgotten that CMP doesn't set the V flag, so yes, that does check for an interrupt from the FDC. However, that then means that nothing is actually using the result of the compare against the sector buffer. Which works, as the CRC-16 verification by the FDC is good enough, but then the CMP (zp),Y / INY instructions might as well just be removed -- the routine just needs to drain the data bytes as they come in while waiting for error or completion.

 

11 hours ago, jhugard said:

Wa'cha mean by "interesting"?

The receive routine takes the last byte out of the sector buffer and saves it off, backs up a byte, jumps back into the receive loop with a special flag set, receives and stores one more byte to finish the buffer again, sees the flag it set, then pulls the checksum byte out of the sector buffer and puts the last data byte back. Bit roundabout. Generally receive routines handle this by instead moving the buffer store to the beginning of the loop and jumping into the middle, so that the receive routine exits without storing its last byte into the sector buffer.

9 hours ago, Nezgar said:

I saw this near the top of phaeron's disassembly: (I'm not adding any authority to the accuracy of this!)

;RIOT port A:
;	Input	D7=1	FDC data request
;	Input	D6=1	FDC interrupt request

I don't believe we have a schematic. (yet) But I do plan to take some more detailed photos of the board with more chips removed as it may help in that endeavour. Looks like only the 2 SRAMs and the 3 LS-logic type chips are not socketed. The EPROM, CPU, RIOT, and WD controller are all socketed. With those removed it may be easier to see where the traces go.

 

Looking further through the disassembly, I saw the notes about the format sector interleaves:

Single density: 2 4 6 8 10 12 14 16 18 1 3 5 7 9 11 13 15 17 (Looks like there was a typo, 15 was repeated twice, the first 15 should be 16)

Double density: 13 7 1 14 8 2 15 9 3 16 10 4 17 11 5 18 12 6

Oops, fat-fingered the comment.

 

There are a couple of things I can't ascertain from the firmware that would be nice to figure out for completeness. One is which chip is providing $80-FF memory and whether RIOT memory is still mapped to $0180-01FF. The firmware leaves the last part of page zero unused and doesn't explicitly access page one, so it works regardless of whether one or both of 6810/RIOT memory are still present.  This might be determinable by issuing SIO memory read/write commands without having to trace the board. The second is whether the FDC is a 2791 or 2795, again since the firmware issues command compatible with both.

 

Also reminds me, I don't think I saw any code in the firmware to enable write precompensation in MFM mode.

 

 

[jhugard]

15 hours ago, phaeron said:

I had forgotten that CMP doesn't set the V flag, so yes, that does check for an interrupt from the FDC. However, that then means that nothing is actually using the result of the compare against the sector buffer. Which works, as the CRC-16 verification by the FDC is good enough, but then the CMP (zp),Y / INY instructions might as well just be removed -- the routine just needs to drain the data bytes as they come in while waiting for error or completion.

Sweet!  I may have trimmed the BNE & code to load an error return, but left the compare as a reminder to add it back (or just forgot about it and focused on other areas to save bytes instead).  You just saved another 3 bytes!  So, 9 available...

 

16 hours ago, phaeron said:

The receive routine takes the last byte out of the sector buffer and saves it off, backs up a byte, jumps back into the receive loop with a special flag set, receives and stores one more byte to finish the buffer again, sees the flag it set, then pulls the checksum byte out of the sector buffer and puts the last data byte back. Bit roundabout. Generally receive routines handle this by instead moving the buffer store to the beginning of the loop and jumping into the middle, so that the receive routine exits without storing its last byte into the sector buffer.

Agree; that would be a better approach and should save a few more bytes.  Inexperience at play; didn't realize at first I needed to read the checksum byte, so had to retrofit the original code.

 

16 hours ago, phaeron said:

There are a couple of things I can't ascertain from the firmware that would be nice to figure out for completeness. One is which chip is providing $80-FF memory and whether RIOT memory is still mapped to $0180-01FF.

IIRC, we didn't change the existing mappings, just dropped 4K static RAM in at $0800.

 

16 hours ago, phaeron said:

The second is whether the FDC is a 2791 or 2795, again since the firmware issues command compatible with both.

I want to say it was a 2795, but bottom line is I can't recall.

 

The 2795/7 have a side-select output, which is only interesting for double-sided drives.  OTOH, that pin is used for ENABLE MINI_FLOPPY on 2791/3 and must be open/high for 1 MHz clock.  Since it didn't matter in our application, either part could be used (2791 or 2795), as long as pin 25 is left to float/isn't connected.  If it's tied high, then it's probably a 2791.  If there's an inverter between 6507 and 279x (which we might have done to buffer to tie-down the signal lines), then it's 2793/7.

 

16 hours ago, phaeron said:

Also reminds me, I don't think I saw any code in the firmware to enable write precompensation in MFM mode.

Positive that we never even considered changing write precomp for inner tracks; I didn't even realize adjusting it on the fly was a thing until just now (had to look it up on Wikipedia :P).

 

The 279x data sheet made it seem like a set-and-forget value that didn't need to be adjusted at run-time.  Nor did our sales rep mention anything about it.  To me, looked like a one-shot hardware setting (especially since it is controlled by ~TEST on pin-22) and that was Chuck's department.  We probably just tied ~TEST to high (precomp off) and might have tied WPW (pin-33) either high or low, rather than adding a 10K pot.  IIRC, the on-board pot is probably a 50K and tied to RPW (pin 18), to adjust the internal data separator.  Again, that was a Chuck thing.

 

Note that there is an unused RIOT pin on one of the two ports, which we decided to NOT use to bank switch either ROM or RAM.  Would take some surgery to wire things up, plus add well over a dozen bytes to detect crossing the middle track and flipping precomp on-or-off accordingly...

 

 

[+Nezgar]

10 hours ago, jhugard said:

I want to say it was a 2795, but bottom line is I can't recall.

 

The 2795/7 have a side-select output, which is only interesting for double-sided drives.  OTOH, that pin is used for ENABLE MINI_FLOPPY on 2791/3 and must be open/high for 1 MHz clock.  Since it didn't matter in our application, either part could be used (2791 or 2795), as long as pin 25 is left to float/isn't connected.  If it's tied high, then it's probably a 2791.

I toned out a few pins on the the controller chip socket. Pin 25 seems only connected to a test pin header next to the controller chip, nothing else on the board - not even the header pin coming in from the 810 side board.

 

On removal of the controller chip, I saw the following printed on the bottom of it:

BB2193BL-22
72569828318
MALAYSIA

Couldn't find much in a brief search for "BB2193BL"...

 

10 hours ago, jhugard said:

We probably just tied ~TEST to high (precomp off) and might have tied WPW (pin-33) either high or low, rather than adding a 10K pot.  IIRC, the on-board pot is probably a 50K and tied to RPW (pin 18), to adjust the internal data separator.  Again, that was a Chuck thing.

Controller Pin 22 (~TEST) seems only connected to a test pin header next to the variable resistor

Controller Pin 33 (WPW) seems not connected

Controller Pin 18 (RPW) is connected to the rectangular multi-turn 50K trimpot output

Controller Pin 26 (VCO) is connected to the round trimpot (not sure value, multimeter is showing infinite resistance)

 

Hopefully this helps narrow it down... Let me know if you'd like any other connections tested, or what to test to identify the mystery logic chips?

 

Here is a 600dpi picture of the undersides of the EPROM and controller chip, and component side of the PCB with removable chips removed:

Interesting to see this board seems to have had a previous life - scuff marks under the controller and CPU sockets indicating the chips were previously removed with hasty screwdriver prying... Some of the controller chip pins also look like they were bent/buckled in a previous re-insertion attempt...

 

And the bottom side:

[Savetz]

My interview with James Hugard (jhugard) is (finally) published on the ANTIC podcast: http://ataripodcast.libsyn.com/antic-interview-377-james-hugard-neanderthal-computer-things

 

-Kevin

 

[Mclaneinc]

Thanks for the pod etc Kevin, also love the interaction on this thread between developer and Phaeron, its just seems that Avery has the equiv of a 1024mb ram upgrade in his head whilst running on a 65C816, there seems to be almost nothing he does not know about but when talking to an old dev its never condescending, always helpful and positive.

 

Great to see all around and superb we get these life snippets from you dedicated work Kevin....So important they get recorded as todays UK news of the death of Martin Peter's a world cup winning footballer in 1966 shows how fickle life is and some of our devs from the old days are not as young as they used to be...Brilliant work...

Edited December 21, 2019 by Mclaneinc

[Mathy]

Hello Paul

5 hours ago, Mclaneinc said:

... some of our devs from the old days are not as young as they used to be...

Something tells me none of them are.

 

Sincerely

 

Mathy

 

 

[Mclaneinc]

9 hours ago, Mathy said:

Hello Paul

Something tells me none of them are.

 

Sincerely

 

Mathy

 

 

Ack, you caught me using good old logic

 

I'll claim senior moment on this one as I also from back in the day am not as young as I used to be

 

I award myself

 

Edited December 22, 2019 by Mclaneinc

[_The Doctor__]

If ever there was a thing that needed cloning or possibly a new implementation... this thing is it!

[+slx]

On 7/8/2020 at 6:45 AM, _The Doctor__ said:

If ever there was a thing that needed cloning or possibly a new implementation... this thing is it!

It‘s been almost two years since the last post here but unfortunately no one has taken the baton yet. It would be great to have a modern implementation of this for all those cheap 810s out there…

[+Nezgar]

5 hours ago, slx said:

It‘s been almost two years since the last post here but unfortunately no one has taken the baton yet. It would be great to have a modern implementation of this for all those cheap 810s out there…

Hey All,

 

I still have Kay's 810T PCB which he graciously lent me, and we've been in touch about it recently as well -- I apologize to all on the lack of timeliness on my intended plans of getting this thing installed to witness a real-world working double-density 810. The effects of Covid-19 and my job moving to primarily work-from-home the last few years has taken a toll on the organization of my home office and space allocated to Atari projects... but this post gives me renewed impetuous to get that corner of the world back into order!

 

I absolutely would also like to see this board reverse-engineered and replicas made. I had emailed tf_hh in the past and he expressed interest in receiving it after I am done with it for exactly this intention. Previously I was able to identify 1 of the two LS logic chips that weren't soldered directly to the PCB using the LS test options in my miniPro programmer, but the others will likely require probing once it's in operation, and/or careful desoldering from the PCB (& socketing of course) to test separately. (The loose chip with the white wire attached is a 74LS04)

 

So, I hope to have more to say in the near future with more updates, and hopefully this thing actually works!

[+slx]

2 minutes ago, Nezgar said:

 So, I hope to have more to say in the near future with more updates, and hopefully this thing actually works!

Excellent news and good luck exploring!

[HarjitS]

This is awesome to see.

 

I was a member of Atari Computer Association of Orange County (ACAOC). Tom (can't remember his last name but IIRC it was a Greek name) was the president of ACAOC. He was also president of NCT. Tom was a hoot, fun, charismatic, gregarious guy to be around. Chuck was the electrical engineer. IIRC, he worked at Rockwell. I remember meeting James (I remember him as Jim) wrote the code. He was very young - late teens, early twenties. This was probably around 1982/1983. I don't believe the 1050 existed at the time.

 

At one point in time, I did get this upgrade for my 810. I don't remember what happened to it.