hhos

😄 You can find more details on this subject in the first page of posts in this thread. HH

First, I'll assume they would refer to the Super AMS design team.🙂 They were probably just wanting to use the RAM spaces that had been already allocated, and for good reason I might add. Whenever you depart from the default memory map you risk having two memories dueling for control of the same data bus. This is always a bad idea, obviously. I would bet on all the 0s winning in any data bit conflicts myself.😀 In the case of the cartridge port memory that's probably not a big deal. Your software can easily test for the presence of a cartridge before turning on the switch that makes the RAM mapped to 6000-7FFF available. Someone plugging in a cartridge while the RAM is available will just cause a reset of the system, so very little harm done? This is not so with the 0000, 4000, and 8000 banks. The 0000-1FFF space has the system ROM there until it is disabled(requires console modification). Once the system ROM is locked out the majority of conflicts would probably be related to the GPL interpreter being unavailable? It's something to plan for if you're going to do it. I believe there is someone who has his console modified so he can have 64K of RAM mapped in all inside the console. Apersson850 is the one that comes to mind, but I'm not absolutely certain on that. Anyway, there are far better sources than myself on what the loss of the system ROM would mean. The 4000-5FFF space is a bit more complicated. If you have this activated and then find you need to access the floppy drive or the RS232C port then you are back to the dueling data scenario. The bit that activates the 4000-5FFF region on my design is bit5 with the CRU base address at >5FC0. To shut it down: LIMI 12,>5FC0 the SAMS doesn't have a plan for this AFAIK LIMI 12,>1E00 the SAMS doesn't have a plan for this AFAIK LI 12,>1E00 SBZ 5 Then you can do your call to the DSR of your choice. In short, to answer your question, it's a pain to do use these areas for extra RAM, but it might be worth it. They decided it wasn't worth the trouble. You decide if it's worth it for you.😊 HH

I posted some schematics at Two of these should give some idea of what is needed to add the function you want. I also included switches for 0000-1FFF and 8000-9FFF which would be somewhat more problematic. I wouldn't recommend trying those without significantly altering the console. There is also a switch to shut off the output of the mapper. These could be implemented on an existing board, but I will not be doing it. For one reason I do not have a SAMS board. Trying to work out how to alter a board without having one to apply an ohmeter to doesn't sound like a good idea to me.🙂 Another reason is Its dependence on SRAM is expensive, and has much less promise for capacity than a DRAM solution, so I won't be getting one. HH

The only thing preventing this usage of memory space in the 6000-7FFF range is the fact that the memory control circuitry on the SAMS does not bring that out. You might want to pay a visit to the SAMS thread for more information. It should also be noted that when the SAMS registers, or any other DSR device, are not being accessed you should be able to use the RAM space at 4000-5FFF, should it be similarly decoded. HH

On the CoCo1 pin 1 is the -12VDC output and pin 2 is the +12VDC output, so 23VDC is pretty close. You could check the voltage between ground, pins 33 and 34, and +5VDC, pin 9. You should check both DC and AC. The DC should be about 5 volts, probably slightly more, and the AC should be negligible. That first picture looks like something I've seen before on several different game consoles and computers. It can be caused by a bad RF switch, or just dirty contacts in same. Also, the channel switch might be in the wrong position. Make sure you have the TV and the computer on the same channel. The channel switch inside the CoCo might be bad or dirty so switch it back and forth(wiping the contacts) a few times to see if it makes a difference. Try using channel 4(assuming you are on channel 3). Since regular cartridges work, the second picture makes me think your disk controllers are made for CoCo2 or CoCo3. Is that possible? Pins 1 and 2 are grounds on the CoCo2. In that case the controller might be receiving a ground where it requires -12 and +12 VDC. They are supposed to be no connection on the CoCo3. If you give the model #'s on those controllers someone on this site might be able to tell you whether they are compatible with the CoCo1. HH

Trivia that isn't on topic: I don't think most EPROMs would be fast enough to do that, but Williams Electronics used some smaller, very fast memories to strobe pixels to the screen in their video games. They are 7489s,74189s, etc. Also, for the cocktail tables models there was a larger one that gave line numbers so flipping one bit in the hardware flipped the entire display around to the player on the opposite side. 🙂 The 74LS612 is another example of this used primarily for memory management. (Super AMS) HH

@Ksarul, there is one error on your schematic that I found, corrected on my copy of it, and promptly forgot. The Latch Enable(LE) on the '373 chip is not an active low input. An active high designation is also consistent with the logic from which this signal is derived.

*If the mod in Thierry's tech pages is "Controlling the wait-state generator" I have just finished skimming through it about 2 hours ago. It is not the way to go if you want to be able to read from a 4116 DRAM. Thierry's 0 wait-state has read timings of 70 nS and 83 nS. A 250 nS 4116 RAM requires 165 nS on the CAS for reading. That 83 nS isn't going to make it. The 70 nS would work on a 200 nS RAM, but I think it would fall short on a 250 nS one. It might squeak by, though. But more than that, he tells us right out that it won't work with the 32K memory expansion. *I'm not interested in putting the PEB on the 16 bit bus right now. When you do that you have to have two of everything. The 16/8 MUX interface in the console allows the peripheral to have just one ROM, RAM, etc. I might try that some time, but that sounds like it would be a lot of work. Where would I be able to get a description of that mod? *If you examine the schematics you will find that two of them do not alter the CRU base used to access the 74LS612 registers. But if you were to access them as if the CRU base was >5FC0, which is the address I selected with the other two with ROM included, you would never know the difference. This is because the entire 8K at >4000 - >5FFF is selected by an output from the '138. No other address decoding is done except that which is done by the 74LS612 itself for distinguishing the individual registers. It is just 256 mirrors of 16 word memory addresses, all pointing to the same single bank of 16 12-bit registers. Unless I've misread something in the schematic, or there is an inaccuracy in the schematic uploaded by Ksarul, this is not only true of my design, but the 1M SAMS as well. If I'm wrong I would appreciate someone setting me straight. Oh, BTW I do not have a SAMS, or any other memory expansion board, other than the 32K expansion that came in the PEB I bought 12-15 years ago. All I know about the SAMS is from reading about it, but mostly what I can glean from analyzing the schematics. In the schematics with ROMs ("ROM" is in the name of the file I uploaded) the CRU base address is >5FC0 and there is one mirror at >5FE0. All of the functions of the mapper are available to any software that you want to use. The CRU base address is the only change if you wish to ignore the DSR. A port from the SAMS to the "16M SAMS W/DSR" might only require changing "SAMREG EQU >4000" to "SAMREG EQU >5FC0". *Some people will see value in it, or what it might lead to. Everyone is allowed to make their own assessment as to cost vs. function. If they want it they can beg or hire someone to do it for them. These United States are still free, but even in China or Iran I think people can spend their money on a 16M SAMS(it might have to be made in China if they don't want to donate a kidney😨), if they wish. HH

What is so special about the 1B00 CRU that it would make XOP and GPL opcodes available? Did that board design use SRAM, DRAMs, SIMMs, or other?

I was intending to start a thread for creating a new design for a memory expansion, but I have thought more about it, and I think that would be premature. What I really want is a UNIXy operating system for the TI99/4A. An operating system would give us the system for allocating memory and other resources that I'm looking for. I personally am not interested in the PEB SRAM based memory expansions. They have their merits. For instance they have far fewer timing requirements. The timing requirements they do have are almost nonexistent, seemingly solving themselves. Inside the console they might be the only solution I would go for in fact. But in the TI99 PEB they are not any faster than the DRAMs, unless you apply some of Nouspikel's "Controlling the wait-state generator" mods. And as Ksarul has pointed out, they are expensive. DRAMs are much cheaper and have greater capacities, especially when you get into memory modules. Solving the 4 wait state per access problem is far more problematic for them, but I do have an idea that doesn't have much to do with the aforementioned Nouspikel mods. The math works out so far, but the actual application almost always deviates from perfection.🙂 I've done some schematics for SAMS to expand to 16MB. Two add a possibility of using 48K-64K of physical memory address space. Two provide further address decoding to provide a DSR ROM. I'm uploading these files as an offering to anyone who wishes to continue to support a larger SuperAMS, or add DSR ROM to their own SAMS. This thread is dedicated for the express purpose of creating an alternative to the zero wait state mod offered by Thierry Nouspikel's "Controlling the wait-state generator". While Thierry did a remarkable job coming up his solution, it doesn't have a chance of satisfying the specs for reading from a 4116 DRAM, not even close, in fact. I believe it is possible to do so without altering the 16/8 bus multiplexer(Thierry's "wait-state generator"), which I just call 16/8MUX. My current goal is to raise the 3 MHz clock rate that governs the 32K RAS/CAS logic to 9 MHz. 16M-SAMS-(0.1).zip

BLWP @>005A(9) past eof: expand file DATA >D800 save R0, R1, R3, R4 MOV 0,3 desired sector offset BL @A4658 call subroutine DATA A4964 append enough sectors to reach offset in R3 BLWP @>005A(9) DATA >D801 restore R0, R1, R3, R4 This is from the disk controller DSR ROM. Every instance of BLWP @>005A(9) that I checked is followed by a DATA directive. If I remember right there are 5? services that this routine handles? One of them is store(save) registers, another is restore registers. There are 203 instances of BLWP @>005A(9) in the dc.ROM.asm source file. I'd say it's a fairly common practice.😃

.....Ten years later.... I don't know that it will matter to anyone now, or even at any time for that matter, but if the info from the "Hardware Manual for the Texas Instruments 99/4A Home Computer", page 8-4(81), is reliable, it is possible to have more than one 32K board in the PEB. Pen 14 of the PAL on the memory board is described with the following boolean expression: PCBEN*MEMEN*AMC*AMB*AMA*/A1*A2 + PCBEN*MEMEN*AMC*AMB*AMA*A0*A1 So if you had a way to alter to the signals on the AMC-AMB-AMA bus(CBA-bus), you could switch between the boards. It's not a particularly elegant system, but TI put these in there. You could have up to seven boards this way, using every slot in the PEB, No disk drives, no RS232s, etc. The memory board is the only hardware that I've run across that uses these lines, and only for CBA-bus=111. It's not very useful, but I have to wonder, what did they have in mind for these lines when they included them in the PEB bus design? I can't help but try to include them anytime I consider designing new hardware for this platform. 😄 For instance, is it possible to stack PEBs? Pure insanity!!😆 HH

That's a long period of stagnation. I suppose the problems presented by the 4 wait states per memory access, and the price of SRAM are the chief causes for that? A DSR cannot reside outside the space of >4000 - >5FFF without breaking the rules set out by TI 40+ years ago AFAIK. There is no reason I can think of to change the CRU address. C, Forth, Pascal, Assembly, and "anything else" exist in the ia32 world of computers, and in far greater numbers. Each of them do things in different ways and co-exist on the same platforms, but they all have a way to request memory allocations from the system, be it Windows, Unix, Linux, BSD, etc. A C compiler is even available for many of the game consoles, but C sources, even on those platforms, have to be able to co-exist with assembly language. Those are single application machines. They're game consoles. Adding a DSR to the SAMS does not mean a huge change in how these applications would be written. A port from one to the other system might be as simple as changing "MAPPER EQU >4000" to "MAPPER EQU >5FC0", or the equivalent in a higher level language, in some cases. Everyone could then continue to just grab up all the memory available and use it in just one program. But for the few who might want to run something a little bit more sophisticated some sort of memory sharing needs to be implemented. MS-DOS/PC-DOS did this in software on the IBM PC and its compatibles, as well as providing many other services. Tandy's early systems had software systems that did it on the Model II, Model III, Model 4, and even the Color Computer. The Color Computer had at least 3 UNIXy systems written for it (although I have to admit it is hard, or maybe even impossible, to distinguish between OS9 and NitrOS9). The C64 had an operating system called GEOS I believe, though I don't know when that was created (I think I have it in my C64 collection). The SAMS DSR I'm proposing would pretty much be memory allocation only, though I've thought about attempting, in hardware, to prevent a process from stepping on memory that belongs to another process. If I go that way, that hardware would have to be switched on by an operating system, or user process, and have no off switch accessible to a user process. That may be a bit too far for me to venture, but we'll see. I don't have an inkling what you mean by "insanely good memory manager", but the "huge problems" already exist. I am only suggesting a path toward resolving them. If an operating system were already in place, like Linux, or even MS-DOS, I probably wouldn't have seen a need for this. AFAIK there isn't, though I saw that there was someone making an attempt at Linux on the TI99. Was it 3 years ago? What does "down the line" mean? RXB, you say you received a SAMS 20 years ago? When does "down the line" start? Many, if not all, of those other operating systems I've mentioned were in place back in the '80s. You decide how far "down the line" you are. It looks a lot like 40 years to me, though it certainly is at least 20. I'm not going to start cluttering up this thread with all this, so I think I'll start a thread on this subject soon, with a couple of my ideas. To anybody who is interested in a better memory expansion board, watch for it. If I go for it I am certain of only one thing. I will need some help. HH

I'm just grousing about the fact that none of the expansion memory boards uses a proper DSR ROM, Lee. The 32K board is understandable. They just wanted to put 32K of RAM into 32K addresses. No ROM needed. There needs to be a system for allocating RAM to applications. Otherwise, it's just a game console, not a computer. A well written DSR ROM on the memory board would go a long way towards establishing a standard.

I didn't think Myarc had a ROM on its memory expansion board. TI started it with its own board, I guess. They only had to map 32K worth of memory into 32K of memory space, though. They didn't need DSR ROM to do that. While I would agree that they should have a DSR, I don't think they do, but if I'm wrong I would be pleased. The Super AMS does not have a ROM. HH