The Mystery of the Missing 253 [3]

by Wes Brzozowski

A Hearty Thank You

The heading really says it all, I've been quite pleased and encouraged by your response to Part 1. This is really turning into an "interactive series", as I'd hoped, and I want to invite you to keep writing and calling with your ideas and questions. Your're truly making these articles much better than I could have done alone.

I wish I could have said all this sooner, but the publication delays on my end do get in the way. I have to submit my "stuff" about a month ahead of the publication date. The result is that I'll be submitting Part 4 about the same time you read this. In the same way, your first responses began to come just as I submitted Part 2, when it was too late for me to include a mention of them.

So you see, there's no escaping this little nuisance, and I'll just have to be content in extending a late, but very sincere thank you.

"...And Now, The Mail..."

A number of you deserve much more than just a mention for the valuable contributions you've provided. Sadly, that's all I can do. Please don't be insulted if I didn't include you here; I have to limit this much more than I'd wish.

The first pat on the back goes to Robert Orrfelt, from Redwood City, CA. He shows that you needn't use my trick to SAVE the EXROM code to tape; just put your disassembler into RAM, then type: OUT 255,128:OUT 244,16. This will switch the EXROM into chunk 4, starting at hex 8000. Really clever! If you use a Spectrum disassembler, and your emulator is in the cartridge slot (as I use), this won't work, since it would require enabling Dock and EXROM chunks simultaneously. Also, if you want to disassemble in decimal, you can't get the code to start at decimal location 4000. Still, this should be a big timesaver for almost everyone.

For reasons to be seen later, I'd like to thank Eric Johnson of Orange City, FL, and fellow SINCUS member Dave Schoenwetter for making several "dead" SCLDs available to me.

Marty Egan of Herndon, VA has also been busily studying the EXROM code, and working out Timex's bank switching protocol. I've spent a great deal of (very pleasant) time with him over the phone, as we compared out notes. I hope my infor was as helpful to you as your insights were to me, Marty. I don't just owe you one... I owe you a million.

Marty has also suggested that I include a cross-reference between a few of my terms and some of the acronym-like bank switching names that Timex included in a few spots in the Tech Manual. I chose to try to "expand" these acronyms in this series, to make the text clearer.

Timex NameNew "Improved" Name Used Here
BNABank Number Access (register 80)
ABNAssigned Bank # (A0, in setup mode)
HSHorizontal Select (regiser 40)
HSPUniversal Deselect Byte (A0, in normal mode)
Timex also referred to HSP as HS-prime, but this seemd too redundant.

I avoid acronyms as much as I can, and was surprised (and suitably humbled) when Rick Best, from Largo, FL asked if I couldn't include a glossary of terms in my articles; explanations of things like AROS, LROS, SCLD, ect. Well, I'll certainly be glad to explain them. (It's amazing how we can let acronyms become a part of our vocabulary without even realizing it!)

AROS (Application ROM Oriented Software) and LROS (Language ROM Oriented Software) are the two types of cartridge programs that the system can run. TM5.0 tells about these in detail. Note that AROS and LROS are "nested acronyms"; that is, one of their letters actually stands for another acronym. (A sign that these things have long since gotten out of hand. I gleefully enjoy pointing out such verbal perversities.)

The term SCLD probably stands for either Semi Custom Logic Device, or Standard Cell Logic Device, (both are true) and usually refers to the specially made "workhorse chip" inside the TS 2068. It appears that this term was intended to refer to any "special" chip to be used in TS 2068 products, and so I've also used it to refer to devices that we can only speculate about.

Another reader who's sent a large amount of infomation is William J. Pederson, owner of the Widjup Co. Mr. Pederson tells me he has a bank switching system working, which he expects to incorporate into a pcoduct. Note that some of his bank switching concepts are VERY different from what we'll be discussing here. Interested readers may wish to drop him a line to find out what's available.

If you've wcitten me with a request for a reply, please be patient. I get swamped sometimes, and my time for writing replies is limited. Between queries on my articles in the newsletter for the SINCUS user group and now my acticles here, (not to mention actually WRITING the articles) things can get very busy. But I will get to you just as soon as I can.

A Bit 'O The Hard Stuff

We talked hardware last time, but some updates may be useful. You may have noticed that it requires a huge quantity of TTL chips to implement the functions we've described. But there may be easier ways to do it. Marty Egan is investigating ways to persuade a 74LS610 chip to do some of the grunt work, and I might suggest looking at an AMD290l bit slice chip to do the same. [The 74LS610 is very rare in 2005 year. The 74LS610 to 74LS613 are 40pin chips that convert 4bit address into 12bit number using a 412 register. The register has data lines for write and read separated from convertion outputs. JA]

Further, if we wish to rewrite the READ_BS_REG and WR_BS_REG routines, as was suggested in Part 1, a really dramatic drop in parts count seems possible. Since these routines are the only ones that actually access the bank switching haraware, they can be changed to control circuitry that's simpler to build. Since we already have to make massive bug corrections to both ROMs anyway, changing these two is trivial.

Last time, I said that the RESET signals in my block diagram were probably not what Timex really intended, and that some odd "unlock" code was instead intended to disarm some power-on "lock up" circuitry. I'd mightily appreciate it if you'd forget I'd ever said this. (Sometimes we look at a simple problem and imagine complex solutions. Sorry, gang.) The odd code will be explained later. The reset signal really should be there, but it probably doesn't go to the backplane's RESET line.

This is because the RESET signal doesn't go to a pin on the standard TS 2068 SCLD either, and so wouldn't reset the standard Horizontal Select register. If RESET only worked on an expansion bank, then applying that signal could result in some chunks not being allocated to any bank. That would hang the machine up, were it to exclude chunk 0.

Were does the signal go, then? A quick look at the sales literature for the NCR Corporation's standard cell devices (of which the 2068's SCLD is one) shows that they can include a power-on-reset circuit right on the chip. I've extracted the actual silicon chip from a dead SCLD, and sure enough, near one edge, is the large capacitor needed to pedorm such a function, (Well, it LOOKS large, at 500 mag.) The SCLD circuits needed to control an expansion bank probably would have had the same function inside, As such, both TS 2068 and its expansion banks would have gotten their Hocizontal Select registers reset ONLY at Power-Up. That way, if an expansion bank were in control of chunk 0, and a RESET occurred, someone would still be in control.

It turns out that Chapt.5 of the "T/S 2068 Intermediate/ Advanced Guide" (SAMS) has a tutorial on Extended Bank Switching, which has useful information. Unfortunately, that chapter was obviously written before the 2068's design cycle was completed, and a lot of its information has been rendered incorrect by engineering changes in the machine. It shows the old scheme, with I/O ports FC and FD as bank switching controls, making no mention of the memory mapped I/O scheme we can see in the TS 2068 code. It also makes no mention of the Universal Deselect Register, and the bank switchiog example given sometimes sends data out in nybbles, and sometimes as a byte.

Among the more useful gems to be found is the fact that bit 0 of a bank's status byte (bit 0 of register AO, to us) would have been set to 0, if that bank had caused an interrupt. The "Interrupt Pciocity", shown in the SYSCON table last time, affects the final renumbering of the banks. (High priority gives a low bank number.) This means that if we poll each bank to learn if it caused an interrupt, startiog with bank #1 and working upward, we will have automatically first checked the ones that demand a fast response.

As a final (and totally unrelated) hardware note, the designer should use caution in designing a Daisychain circuit. Since the clock signal is generated separately by each bank (as I showed it), the Daisychain flip flops aren't really being clocked synchronously, as is required for a shift register. This type of situation requires the use of master-slave flip flops, or two flip flops in a master-slave configuration. This will prevent one flip flop from changing its data before the next one clocks it in. If all the banks to be used are on the same circuit board however, only a single clock signal is needed, and synchronous operation is possible.

Why Bother?

This is a reasonable question. With considerable circuit complexity and ROM bugs galore, reconstructing the thing would first seem like an exercise in self-punishment. There are already simpler expansion schemes available.

As it turns out, this would be a very bad method if all we wanted was extra memory. We can now buy RAM cards that plug into the cartridge slot, and one of the available disk systems can "switch banks" that overlay one another in the Dock bank. User group newsletters have published various "RAM in the Dock slot" methods. (I published one in 1984!) But the level of 2068 software being developed today doesn't even make full use of the machine. Why would we need another way to expand it?

We don't simply need more memory, but we CAN use many of the undocumented (and presently bug laden) capabilities that are hidden in the ROM. If you're aware of the stream-and-channels I/O system that the 2068 uses, you understand how it's possible to LOAD in a "print driver" program that redirects the Basic LPRINT and LLIST commands to a large printer. The 2068 tries to expand on this "Spectrum-based" theme allowing such print drivers, or any other software for an intelligent I/O device, to be located permanently in an expansion bank. These programs would take up NONE of your Home Bank memory and so wouldn't conflict with anything else running there.

But there's no reason for an I/O device to completely dominate a bank. While the extra memory space could have been taken up by something like an interrupt driven printer buffer, it sould also have been possible to include extra RAM, or utilities in a ROM. Further banks might have contained a disk operating system, or spiffed-up versions of the 40/64/80 column display utilities in the Technical Manual. And they could have been made directly accessable from Basic! No PEEKs, POKEs, or USR calls should have been needed.

These things just scratch the surface. The point is that the expansion banks, and some extra BEU circuitry similar in function to Sinclair's Interface One for the Spectrum, would have easily extended the TS 2068's repertoire of Basic commands to handle some very nifty I/O functions, and they'd have been immediately available when you powered up your machine. We'll begin a discussion of the 2068's I/O system and extended commands later on. Until then, keep in mind that this is where the extended bank switching system would have really made the 2068 shine!

Taking Care Of Old Business

Let's first consider Flowchart 2, which describes the BANK_ENABLE routine in the RAM Resident Code. To use this, we would first put the bank number in B, and the Horizontal Select byte we want for the bank in the C register. This will work for the standard banks and expansion banks both. No one really uses it for the standard banks at the moment; it's a lot easier to program the standard banks directly. As we'll see, that's not the case if there are any expansion banks in the system.

At 64A2, we check if there are any expansion banks. If there are, we run some code to deselect the chunks specified from any expansion bank that might have them. Note that if no expansion bank has them, this can't hurt, and if we're about to give the chunks to a bank that already has them, this momentary loss won't be noticed. At 64B7, we check if it's the Dock bank we're selecting. If so, we program it directly, and we're done.

If not, we check if we're selecting the EXROM bank. If so, we pretty much do the same thing, except the code only allows us to give chunk 0 to that bank. Remember, that's the only chunk originally intended to be used there.

If it's not the EXROM bank, then it's either the home bank or an expansion bank. In either case, it doesn't hurt to try to give it to the home bank, because an expansion bank will override this if it has to. We do this at 64EC. The code from 64F6 to 6505 appears benign, but useless.

At 6506, we see if we were selecting the Home Bank. If so, then we're done. Otherwise, we send the bank number to register 80 (Bank Number Access), and the the Horizontal Select information to register 40. And that's that.

Flowchart 3 is a bit of an embarassment, because it references that incorrect "unlock" scheme I asked you to forget. (You don't remember, I hope.) My explanation wlll correct two errant lines in it. Since I first thought this routine controlled special hardware, it was mentioned last time. Unfortunately it doesn't, and now it would be more appropriate if I first describe the routine that CALLS it. That's the routine that builds the SYSCON table.

Daddy, Where Do SYSCINs Come From?

Well, we're mature enough in our understanding of bank switching that we know that the stork does NOT bring them! The high level initialization routine (Flowchart 1, in Part 1 of this series) CALLs the routine to build the table. Shown here in Flowchart 4, it works as follows.

We start by pointing to the SYSCON table and assuming there are no expansion banks (we'll update this assumption if and when we find some). We then transfer the 4 LROS bytes into the SYSCON table. (TM 5.1.1 explains these bytes.) If no LROS is present, the 8 AROS overhead bytes are transferred (see TM 5.1.2). In either case, if the device wasn't present, its space is marked to show it inactive. The "bug" described in TM 6.1.4 can be corrected by having the JR at XOA1A go to XOA1E, if no LROS is present.

At XOA3E, we point to the SYSCON space for the first expansion bank and enter the setup mode. In this mode, anything written to register A0 will become the Assigned Bank Number of the bank selected by the Daisychain. Also, during the bank initiallzation, the HL register is always supported to point to the SYSCON location we're working with.

At X0A4C, we CALL routine that tries to install a bank number, checks to see if it succeeded, and ends the setup mode, if not. Returning from that routine, if we've run out of banks, we leave the setup loop to X0AD4, mark the end of the SYSCON table, and CALL a routine that RE-ASSIGNS the bank numbers, according to their value in SYSCON 17. This is called the Interrupt Priority.

[Editor: WOW! Wes, we ran out of space already! And just when it was getting good. We will all have to hold on to our hats 'til next issue!]


End of part three.
See part one, part two, part four, part five.

See also BEU - Bus Expansion Unit on http://8bit.yarek.pl.