FALCOR4

Very good point, thanks RickyDean. And I believe that they had 12 not 16 SRAMs for a first layer?

I think I heard say 13v from his bench P/S. Is there a thread discussing different things people have tried for replacing the console P/S?

From Michael Bunyard's "Hardware Manual for the TI-99/4A.....": ".....The CRU options were apparently never used, and were removed from the late model TI-99/4As with a Gate Array for Timing and Control." The *CRUCLK, pin 4, and the CRUIN, pin 6, are non-connects on the cart port of the QI models. Another, "why'd you do that TI?!" to add to the list. 😆

That's interesting. You could probably pare it down even further to only +5v and -5v regulators and use +12v directly from a PC P/S through a standard four-wire molex connector. Hmmmm, I already have a P/S for my IDE drives and SD card boards. Plenty of power left over for a mod like this. Now you have me thinking about it!

The problem with the earlier versions is that there were many modifications and configurations the popped up over the years. It might be difficult to account for those. Again, fact check me. I'm only going off of what I have personally seen and read.

That LED is part of a circuit that protects memory from corruption during power cycles. It became necessary (from what I've read) when ROS 8.+ was introduced that used HRD SRAM as a disk buffer instead of VDP RAM revealing instances of memory corruption. It's a bit unusual of a design but it works. I believe it is known as change 3 or change 91-1 in the Horizon literature. Someone more familiar with the Horizon RamDisk history fact check me here. BTW, I recommend using a blue LED because the forward voltage drop is generally greater than the other colors. It offers a bit more margin for protection.

VERY good questions. I may be able to answer most of them but, grandkids in the house right now so give me a day or so 🙂

Just set the CRU address

Chris, I only used the U11 test. I couldn't get MEGTEST to work properly to test the memory on the HRD4000B but, that is very well just me. I didn't spend a lot of time trying to figure it out. After I put it down I just wrote some hack code to fill up all memory and then read it back using the MG Explorer. So, you should be able to test U11 before you install the rest of the SRAM. If memory serves...... Ksarul, did you get the Memory Test option to work for you?

I usually send these two pics to the seller and ask them to id which side port is on the console. But, in either case, the Matsumi keyboard is a killer. Also, like arcadeshopper mentioned, I have a QI with the old GROM 0 in it but it has the cartridge port limitation that Ksarul talked about.

You and Fred understand this much better than I do. I did play around with it some more this morning and am convinced it has nothing to do with the filename length (8+ chars) or the protection bit. The fact that the E/A editor doesn't error out until the file is completely loaded should have been my clue that there may be an EOF issue. The files seemed to have been corrupted somewhere along the line as you point out.

Just tried using the TI DM2 and got the same results.

That would explain that particular error code. I added some more information to my previous post. For the record, I used DM2K to transfer the files from my GoTek to the HRD. I suppose I could try another DM to see if that makes a difference?

But that also begs the question as to why those two files generated the code 7 error with the E/A Editor from the HRD? Because, and here's a big because, those two files loaded into the E/A Editor just fine from my GoTek even with the write protect bit on.

Ok, here's what I found: Loaded the files on my GoTek DSK4. Used E/A and assembled RFILES1-S4 just fine. Loaded the files on my HRD4000B DSK9. Used E/A and assembled RFILE1-S9 and got DSR ERROR: 02F4 and I/O ERROR code 0 when it got to COPY "DSK9.99DSRLNK-S" Then, I loaded the files one by one into the E/A Editor. Files 99DSRLNK-S and 99SUB2-S gave an I/O ERROR code 7, RFILE1_S9 and 99VDP4-S loaded just fine. Went into DM2K and noticed that 99DSRLNK-S and 99SUB2-S had write protect on them so I removed the write protect. I loaded the files again into the E/A editor and got the same I/O ERROR code 7 on files 99DSRLNK-S and 99SUB2-S. But this time I re-saved them back out to the HRD from the editor with the same filenames. Now they do not generate the error when loaded into the E/A editor. I assembled the RFILE1-S9 now and it assembled correctly. So, something to do with the write protect bit that the HRD DSR doesn't like?

When I started with your files I also got the same DSR errors. Another clue, maybe, is that each one of the files generated an error when I loaded them using the E/A editor but, they loaded. Then I saved them back out which was successful. Let me try again this weekend and I'll be a little more methodical this time. This shouldn't be happening. Question, what did you use to create the source files?

What did you have to do to remove the cover?

Would this be of interest? I haven't tried it yet; would like to hear if someone has. I don't remember if my original Myarc DDCC-2 will read a disk that has already been formatted with 18 sectors per track or only 16 sector tracks. MYARC FDC Format routine 18 sec-track DSDD.txt

Anyone notice that the alpha lock is up? Ha! That was great today, thanks to everyone for the work that you put into it. Definitely a homerun!

I renamed your source files to have 8 chars or less in the filenames and they assembled ok. I put my HRD4000B at CRU >1000 and assembled your RFILE_S9 (I changed the name slightly) and it assembled, with list and cross table, in 1m 15s using the E/A assembler.

That's interesting. I wonder what's going on, I assemble source code using the HRD4000B with COPY commands all the time. I have used both the TI assembler and the RAG assembler. This deserves some sleuthing.

Attached is an attempt to explain why an application should modify a SAMS register by writing a WORD and not a BYTE. It looks like most software is doing that but there still seems to be some questions about it. My thanks to apersson850 and Stuart for their inputs and edits. Would also like to thank TheBF and mizapf for good discussion on the subject. SAMS registers explained_Srt_AP edits.rtf

DSR code for the TI sidecar FDC

I corrected an error in this version of the "software developers guide to the HRD4000B"; this is ver 1.1 Barring any significant inputs from the community, I will call it done. Thanks everyone! Software Developers Guide to the Horizon HDR4000B_ver_1-1.pdf

Finished burn in on the second 4M board and it passed with flying colors <yipee>. I did a double check on reading back the register values and it indeed only reads back 1M of pages and not the bank you may be in. Example: LI R12,<1E00 CRU ADDRESS LI R0,>0A01 SET REGISTER VALUE WITH PAGE >0A AND BANK >01 SBO 0 ENABLE WRITING TO REGISTERS MOV R0,@>4014 LOAD REGISTER FOR MEM LOCATION >A000 MOV @>4014,R1 READ BACK REGISTER, WHAT YOU GET IS NOT >0A01 BUT RATHER >0A0A. THE BANK VALUE >01 DOES NOT READ BACK. SBZ 0 TURN OFF ACCESS TO REGISTERS