FALCOR4

Correct. The SAMS circuitry is simplistic, and I don't mean to say that is a bad thing. It's not, it just means that not all possible functionality is implemented which would require more ICs and board space. It will put the same page number (repeats) for a 1M segment in both the LSByte and the MSByte from the LS612 when you do a register read (>00 to >FF). The LSByte that is latched (which gives you banks beyond the first 1M) is not connected in such a way that it can be read back. So, you'll only be able to see page numbers for any one particular 1M bank, you won't be able to read back what bank you're in which would be in the LSByte if it were implemented. If needed, the software will just have to keep track of banks. I just put together another 4M board and am doing a burn in right now that should run through the night. When it's done, I'll play with it to verify that what I'm telling you is true or not. I'll report back with what I find.

What's worked for me is to clean the contacts and use a very thin layer of dielectric grease on the contacts. But, personally, I wouldn't apply solder to the contacts as that, will over time, oxidize and give you further problems. Back to the clean and grease........

Please do not depend on being able to read the SAMS registers in your software! Yes, you can read back the registers but only in 1M segments, the SAMS greater than 1M boards will not read back anything beyond 1M segments; i.e. if you have a 4M or 8M or 16M SAMS it will not give you any granularity beyond 1M. Just a caution to those who are writing software. And, currently there is only a 4M SAMS available but, the possibility for a 16M does exist and, in my opinion, should be accounted for in software development. Again, IMHO.

I suppose its possible but you would have to add a couple of components and do some trace hacking. If the components on your 1M card are in sockets, why not just move them over to a 4M board, add the caps/resistors and new 2Mx8 memory? It would be a lot easier.

Greg, as much as I love the idea of adding capability to the SAMS card (DSR, CRU register address tables, etc.) I wholeheartedly concur with you. Changing how the cards works more or less negates any software work done to date. IMHO, it should be and remain as THE standard expanded memory card for the TI.

I suspect that the RAG Assembler captures the DSR address as well. At least, watching it in action it appears to be doing so. When I have my HRD set to an address beyond >1100, the only time I see the disk controller card LED flash is when the assembler opens a new source file. After that, all the action in with the HRD card until another file is needed.

My 4M SAMS only has 2M installed right now because of a bad SRAM but, 1.7 found it, ID'd it as 2M and seems to have tested it successfully. I've also done some hack code testing on my board and the 2M seems to be good. I will tell you (and I mentioned it to you during one of our conversations, @Jetimatt42), there is a very nefarious possible error in the SRAMs that I don't believe every test program will find. I speculate that it has something to do with the internal addressing architecture of the SRAM in the way it addresses rows and columns of bit cells.

Very good point! So, you would need to include the +5v and +12v regulator draw as part of the calculation. I totally missed that, thanks @Ed in SoDak!

I found this in the PEB theory of operation and technical training manual: 2.2 POWER ALLOCATION ASSUMPTIONS The following is a guide for maximum load current a PCB should present to the PEU. * 250 ma on the +15V unregulated bus. * 500 ma on the +8V unregulated bus. * 30 ma on the -15V unregulated bus. So maybe times eight on each of those voltage rails plus some additional comfort overhead would be a good gouge on current requirements?

Mine: 120VAC input. Center tap (blue/wt) to Yellow = 18.6VAC. Center tap (blue/wt) to Blue = 10.86VAC. Don't know the current rating for those outputs, however.

This might help, the voltages out to the bus are in one Thierry's PEB discussion. http://www.nouspikel.com/ti99/titechpages.htm

The 4M SAMS has the same address space as the 1M SAMS; >2000->3FFF, >A000->FFFF.

On the numbering convention, I don't know; maybe leave that to the community that is writing software for SAMS (hey guys, pick one!)? I know that sounds like a cop out. Maybe it depends on which language you're using for the application you're writing?. Also, slight edit if I may (don't hate me); 0 to 1023d and >0000 to >03FF. To be technically correct. I like the added feature for the 4K pages in all the 32K space, that was a great change that offers more flexibility! The card can do it, might as well be able to use it!

I re-read your question so, to be clear, you can't write-a-byte then write-a-byte. You have to write it as a single word; MOV not MOVB, MOVB. I can go into more detail as to the "why" but I don't think most folks would be interested. I'm getting off course for this thread, too. I'd be happy to talk to you some more about it if its helpful, PM?

Exactly, you got it. Just another way to slice the pie. And, BTW, you can do the same for the 1M card; write a word instead of a byte. That way the same code can be used for both versions of the SAMS.

Rich, I'm using some hack code just to check the card's SRAM; fill each page with the page number and reading it all back through the MG Explorer. (avoiding the space where Explorer resides). Super simple. But, one way to page a 4M SAMS--> Put the page number in a word, SWAP the bytes in the word, write the word out to the SAMS register for the 4k block of the 32K memory space you're interested in presenting the page. So, to page in page 392 (>0188) into the >2000 memory space: enable the SAMS load register bit, load the page number into a word (>0188), swap it (>8801) and write it out to >4004.

Its been a while but I'm happy to say that my SAMS 4M card is up and running (thank you Ksarul!). I had a bad DALLAS SRAM that was giving me intermittent fits so I switched to ZEROPOWER SRAM and now I'm showing the entire 4M and, it seems to be stable so far. I've paged and written to all 1024 pages several times successfully; I'll continue to work with it and use it as my main memory expansion card.

Well, tiddlywinks, there's a couple of nit things I didn't catch in the document. Most notably, change the two references from "M32" in figure 5 to "U9". The other nits are cosmetic. For all of you who downloaded a copy of the guide, if you find something that you would like better explained or any errors please PM me and let me know. Sometime down the road I'll send out corrections/changes in an errata sheet or subsequent version depending how much change is needed. Thanks everyone for your support.

A software developers guide for the HRD4000B. Special thanks to Ksarul, InsaneMultitasker, Retroclouds and BeeryMiller for their inputs. Software Developers Guide to the Horizon HDR4000B_ver 1-0.pdf

I managed to get the missing GROM pages thanks to Regulus. We have a "retype" of the original ROM listing but I've not seen the original listing it came from; would love to have a copy though.

Thank you, Fred! These are great!

I hope this is not too far off topic but this thread reminded me of an old cartridge I put together BITD. Just something fun. Some of the crazy things we did!

Thanks! Pretty nifty program! I used it on a 1M board but I'm still waiting on a few parts for the 4M board. I will report back to you once I get a chance to use it on the 4M.

Hmmm, IIRC, I got them off of Ebay quite a while ago. They're still listed there as coming from China and are a bit pricey. Someone might have a better source for them?

If you want to use the MG Explorer on old iron to help troubleshoot XB code let me know. I will post a version that loads into the lower part of upper memory specifically for use with XB. Also, I would selfishly recommend the Paisley version of the MG Explorer. It is a slightly smaller code version that fits into two ROM banks with a loader; adds help screens and a few other additions for GRAM devices and memory mapped devices. One way you can use it is to load it into memory then set a breakpoint in your code to branch to >A000 or, launch it and then point to your code in memory to start step-by-step execution.