HRD 4000B

[HRD 4000B]

36 minutes ago, RickyDean said:

I believe using the base of each would be sufficient, the 2000 could only use 32k chips for populating, the 3000 was capable of using 32k or 128k chips. Both could be layerd up to a certain range. What they did was basically the same.

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

[New 99/4A DC Power Board]

4 minutes ago, arcadeshopper said:

ymmv but others have tried similar routes and had stability issues..

 

Does he even say what his input voltage is? 

 

Greg 

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?

[Beige Bug]

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. 😆

[New 99/4A DC Power Board]

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!

[HRD 4000B]

5 hours ago, mizapf said:

If feasible, I'd like to add the types 2000 and 3000 as well. If this turns out to complicate things too much, I'd have to define them as a distinct card.

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.

[HRD 4000B]

9 hours ago, mizapf said:

From the schematics I did not quite understand the idea of the second LED in the middle of the board.

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.

[HRD 4000B]

2 hours ago, mizapf said:

I'm currently reworking the Horizon emulation in MAME. Some questions:

 

I saw that you can put two different kinds of memory chips on the board (128Kx8 and 512Kx8). Also, you can put a maximum of 32 chips on the board (stacked in two layers). Chips must not be mixed; what else has to be considered?

 

- Does the bottom layer have to be completely filled?

- The top layer seems optional. Can you fill it partly?

- Can you fill each layer partly?

 

If layers have to be filled, you'd only have options for 16 or 32 chips. If only the bottom layer must be filled, you'd have min 16, max 32 chips. If the bottom layer need not be filled, you could have 1-32 chips, where the first 16 chips belong to the bottom layer (unless both layers could be partly filled).

 

I recently posted some more questions:

 

1. The only difference between HRD4000 and HRD4000B is the switchable DSR bank, right? (CRU bit 14)

2. How do HRD3000 and HRD3000B differ?

3. Is the HRD4000(B) the only HRD that decodes AMA/B/C?

4. Is "HRD2000" = "HRD+ Series 2000?"

5. Is there any further difference between HRD+ and HRD2000 besides the stacking of control chips?

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 🙂

[HRD 4000B]

2 hours ago, Shift838 said:

But do I need to configure any of the jumpers or just set the CRU address for this initial test?  I believe on the CRU needs to be set, just making sure.

 

 

Just set the CRU address

[HRD 4000B]

3 hours ago, Shift838 said:

I'm in the process of building my HRD4000B card.  I have already done the initial 'SMOKE TEST' with no issues.  Now I'm to the point of doing the MEGTEST program.

 

I have been following the construction guide, but I may be confused on it.  It states:

 

THE INTEGRATED CIRCUITS
Insert all ICs except for the memory chips. Make sure the notch of each IC points toward the top of the card (for the chips mounted vertically) or to the left (for the chips mounted horizontally), as shown in Figure 6. Install U9, the 6264LP-15, near the center of the board. TO AVOID MEMORY DAMAGE, NEVER PLACE THE CARD IN THE PEB WITHOUT ITS BATTERIES! Run the MEGTEST program as described in the MEGTEST instructions.

 

Now from my understanding the megtest program can run a simple U11 test, Memory Test and Loop test.  So but with the statement above from the construction guide is interpreted (by me) that I do not install the memory chips just yet and still run the MEGTEST.  If so, then what option do I need to choose?  U11 or what?

 

Or is this part of the guide wrong and i need to install the memory chips and set the jumpers before running any test with MEGTEST ?

 

 

 

 

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?

[Beige Bug]

On 11/5/2020 at 9:30 AM, grayin99 said:

Looking to get a beige TI-99/4a.  I was looking at this one https://www.ebay.com/itm/Texas-Instruments-TI-99-4A-Computer-Working-with-cables/303749528684

What can anyone tell me by looking at it?  From the expansion port silver "fingers" I would think this is a QI module, but the screen seems to show 1981 so maybe not.  What about that keyboard?  I know there are tons of FAQs on the QI's, but I thought I would ask the experts on this one.

 

Thanks.

 

Edit, looks like I put this in the wrong forum.  Maybe someone can move it to the right section?  Sorry about that.

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.

[Assembling a program on real TI hardware - interesting results]

3 hours ago, InsaneMultitasker said:

When I view the two protected files (from RDISK.DSK) using MENU/BOOT, there is problem with the file. I did not inspect the File Descriptor Record to determine the issue with the file but here is what I see as an example:  I'm guessing somewhere in the creation or transfer of these files, the EOF marker or record count has been corrupted.  Hard to tell which device may have caused it without further testing.

 

 

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.

[Assembling a program on real TI hardware - interesting results]

4 minutes ago, FALCOR4 said:

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?

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

[Assembling a program on real TI hardware - interesting results]

5 minutes ago, InsaneMultitasker said:

When I view the two protected files (from RDISK.DSK) using MENU/BOOT, there is problem with the file. I did not inspect the File Descriptor Record to determine the issue with the file but here is what I see as an example:  I'm guessing somewhere in the creation or transfer of these files, the EOF marker or record count has been corrupted.  Hard to tell which device may have caused it without further testing.

 

 

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?

[Assembling a program on real TI hardware - interesting results]

12 minutes ago, FALCOR4 said:

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?

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.

[Assembling a program on real TI hardware - interesting results]

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?

[Assembling a program on real TI hardware - interesting results]

4 hours ago, wolhess said:

Hi,

 

I renamed my files to a three letter name but always get the DSR ERROR:02F4!

 

I tested some ROS versions 8.41, 8.42 from 2/16/20 and 8.42c from 3/14/20 but with the same DSR ERROR.

 

So yesterday I made all the three RAM tests provided with the HRD4000B card. All tests passed without an ERROR.

Then I configured the HRD completly new and configured the RAM Disk DSK9. with 3200, 1600 and 800 sectores. In any case I got the DSR ERROR.

 

So it seems on my PEB configuration the HRD DSR has this problem all the time.

 

My PEB configuration is:

CRU:1000 TIPI Device

CRU:1100 TI Floppy Controller with 80 TRACK mod.

CRU:1300 RS232 and PIO

CRU:1700 HRD 4000B with RAMBO RAM

CRU:1E00 SAMS card 1MB

 

I used the original E/A cartridge, the E/A complete cartridge from Tursi, the EA version V from Fred KAAL and the RAG Macro Assembler.

All Assembly is working on the tipi device or on the real floppy drives. 

The assembler process begins on the HRD up to the point at which the first COPY command is to be executed.
At this point I am getting the DSR ERROR:02F4 (refers to an error reading a display variable file = the COPY source file I think) 

 

 

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?

[BQ4847 Frankensteined Battery Replacement!]

3 hours ago, RickyDean said:

Yea, I've recovered some Dallas chips by removing the cover and the old battery, and installing a coin cell battery there.

What did you have to do to remove the cover?

[Myarc DDCC-1 jumpers and switches]

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

[The 38th Annual Chicago TI International World Faire]

6 minutes ago, jedimatt42 said:

 

When you feel better, the direct link posted at the top of this thread has the entire video, so no need to record them. You can select to play the live chat back as well.

 

 

 

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!

[Assembling a program on real TI hardware - interesting results]

2 hours ago, wolhess said:

maybe it is because I have a tipi card on cru = 1000?

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.

[Assembling a program on real TI hardware - interesting results]

10 minutes ago, wolhess said:

6. The Ramdisk HRD4000B with the ROS842c cannot execute source files from a COPY command!

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.

[SAMS usage in Assembly]

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

[Original TI Source Code]

DSR code for the TI sidecar FDC

 

[HRD 4000B]

On 8/7/2020 at 12:40 PM, FALCOR4 said:

A software developers guide for the HRD4000B.  Special thanks to Ksarul, InsaneMultitasker, Retroclouds and BeeryMiller for their inputs.

 

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

[SAMS usage in Assembly]

17 hours ago, FALCOR4 said:

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.

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