Subject: IDE pulse check.....

From: "Marc H" <[email-masked]>
Date: Wed, 09 Mar 2011 16:48:22 -0000

There has been some discussion on AA about the possibility of redesigning the IDE card to either use through hole components or possibly as a side car device that passes signals to the PEB in correct fashion so you could daisy chain them together.

There has been some minimal interest but not really enough to continue a lot of discussion so I am wondering if there is any interest here before the idea gets dropped ?

Just for clarification...

The purpose of the through hole design would be to simplify building and repair.  There is only so much Richard can do.

-or-

The purpose of a side card design (with through hole components)would be to allow those who do not have a PEB set up to have access to this wonderful device.  I would imagine a design similar to the C64 IDE project as far as the side car could go.

A little FYI...

Before some one claims no components.... The BQ4847 clock is still available in quantity as is the 128K SRAM both at reasonable prices, as well as the logic required.

I don't know if Fred's DSR supports this particular chip but perhaps he could be cajoled into a smallish rewrite.

I fully realize that there is the CF7 and NANO PEB available but those devices seem to have issues that AFAIK the designer doesn't wish to address where as the IDE system is a mature, working one that has been through the growing pains.  Fred's DSR is a fully functioning directory/sub directory system which as far as I am concerned is better than the DSK system of the a fore mentioned devices.

At any rate the floor is open for discussion.  Please lets keep to the topic and not delve too far into other matters.

---

From: "Postle" <[email-masked]>
Date: Wed, 09 Mar 2011 16:58:49 -0000

Mark,

The IDE Card was a wonderful project and it works.  It was also a wonderful time for the TI-99/4A.  An IDE Card or the SCSI Card should be a serious consideratin for any user of the real TI-99/4A hardware.  Save they are both rare and costly.

With other groups and the IDE Card, one individual became the mad builder of useful boards. Maybe that could happen again?  Or...  I wish it could.

Postle

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

---

From: Tony Knerr <[email-masked]>
Date: Wed, 09 Mar 2011 12:16:00 -0500

I like the idea of the through hole design, I've steered clear of this 
device so far because of the SMT.
I'd prefer it be a Pbox card, though, so it could be used with a Geneve.

Tony

Marc H wrote:
>  
>
> There has been some discussion on AA about the possibility of 
> redesigning the IDE card to either use through hole components or 
> possibly as a side car device that passes signals to the PEB in 
> correct fashion so you could daisy chain them together.
>
> There has been some minimal interest but not really enough to continue 
> a lot of discussion so I am wondering if there is any interest here 
> before the idea gets dropped ? ...
>

---

From: Marc Hull <[email-masked]>
Date: Wed, 9 Mar 2011 09:42:16 -0800 (PST)

That is a good point I had not considered.  

--- On Wed, 3/9/11, Tony Knerr <[email-masked]> wrote:

From: Tony Knerr <[email-masked]>
Subject: Re: [TI994A] IDE pulse check.....
To: [email-masked]
Date: Wednesday, March 9, 2011, 11:16 AM

  

      

Tony

Marc H wrote:

  There has been some discussion on AA about the possibility of
redesigning the IDE card to either use through hole components or
possibly as a side car device that passes signals to the PEB in correct
fashion so you could daisy chain them together.

---

From: "epergrem" <[email-masked]>
Date: Wed, 09 Mar 2011 17:48:23 -0000

Thierry originally created the IDE card as a through hole and even built a wire wrap version which was demonstrated at the Chicago Faire.  However he couldn't get anyone to draw the board, so it was abandoned.  

The SMT version exists only was because he became fascinated with USB and was able to reuse much of that work to create the IDE card.

The orignial though hole information still exists on his site as "old version".

Ernie

---

From: fdos <[email-masked]>
Date: Wed, 09 Mar 2011 10:50:33 -0700

I, too, like the idea of getting away from SMT projects.  My eyes can no 
longer deal with that technology from an assembly perspective, and I'm 
sure the "debug/repair" process is even more eye strain.

Of the three IDE cards that I own only one is working.  The other two 
are out for repair by someone with better eyesight than I.  As to the 
design of a non-SMT device being either a PEB card or sidecar, I would 
prefer it be a PEB card designed so that it can fit in a case designed 
to adapt the new card to a sidecar with through connector for a 
CF7/NanoPEB, and power supply to power the new card.  Which may even 
require a different adapter to mount it in a PEB, if 
necessary--flexibility plus!

However, real estate may be at a premium once all the SMT parts are 
exchanged, so this could put a serious crimp in the flexible design 
above.  So I'll understand if the IDE card designers nix this idea.

As to MDOS compatibility we need to check with Tim, as I don't use my 
one working IDE card in the Geneve due to GPL mode only at this time.  I 
did try to use it in my TI-99/4P, but without success.  Does anyone have 
and IDE card working in a TI-99/4P (full SNUG-TI system)?

Bill S

-- 
Bill R Sullivan (FDOS)
Go Forth+ or X4th99

---

From: "Tursi" <[email-masked]>
Date: Wed, 9 Mar 2011 09:58:43 -0800

The IDE discussion made me wonder a bit.. what does a designer need to keep 
in mind to make a PEB card compatible with the Geneve?

---

From: ti99_forever <[email-masked]>
Date: Wed, 9 Mar 2011 10:08:19 -0800 (PST)

--- On Wed, 3/9/11, Marc H <[email-masked]> wrote:

> From: Marc H <[email-masked]>
> Subject: [TI994A] IDE pulse check.....
> Date: Wednesday, March 9, 2011, 11:48 AM
> There has been some discussion on AA
> about the possibility of redesigning the IDE card to either
> use through hole components or possibly as a side car device
> that passes signals to the PEB in correct fashion so you
> could daisy chain them together.
> 
> There has been some minimal interest but not really enough
> to continue a lot of discussion so I am wondering if there
> is any interest here before the idea gets dropped ?
> 
> The purpose of the through hole design would be to simplify
> building and repair.  There is only so much Richard can
> do.
> 
> -or-
> 
> The purpose of a side card design (with through hole
> components)would be to allow those who do not have a PEB set
> up to have access to this wonderful device.  I would
> imagine a design similar to the C64 IDE project as far as
> the side car could go.
> 
> A little FYI...
> 
> Before some one claims no components.... The BQ4847 clock
> is still available in quantity as is the 128K SRAM both at
> reasonable prices, as well as the logic required.
> 
> I don't know if Fred's DSR supports this particular chip
> but perhaps he could be cajoled into a smallish rewrite.
> 
> I fully realize that there is the CF7 and NANO PEB
> available but those devices seem to have issues that AFAIK
> the designer doesn't wish to address where as the IDE system
> is a mature, working one that has been through the growing
> pains.  Fred's DSR is a fully functioning directory/sub
> directory system which as far as I am concerned is better
> than the DSK system of the a fore mentioned devices.
> 
> At any rate the floor is open for discussion.  Please
> lets keep to the topic and not delve too far into other
> matters.

I like llamas. Do you like llamas?
How about we design a game about llamas and how far they can spit.
Llamas (or is the plural llymae?) are the animals that are famous for spitting, right? Or is that just the camel?

Ok, I have it... you are a fly on the wall of a llama (or camel) pen (?) and are trying to avoid the spitting, which will seriously damage you or cause fatal death.

Oh wait - isn't that redundant? Death is fatal, after all, right?

---

From: "hjalmarii" <[email-masked]>
Date: Wed, 09 Mar 2011 18:22:50 -0000

I have a working IDE card in my main system.  --Hal

---

From: Gregory McGill <[email-masked]>
Date: Wed, 9 Mar 2011 10:31:29 -0800

OH NO! THE LLLLAMAS BUSTED OUT!

On Wed, Mar 9, 2011 at 10:08 AM, ti99_forever <[email-masked]>wrote:

> Llamas (or is the plural llymae?) are the animals that are famous for
> spitting, right? Or is that just the camel?
>
> Ok, I have it... you are a fly on the wall of a llama (or camel) pen (?)
> and are trying to avoid the spitting, which will seriously damage you or
> cause fatal death.
>

---

From: fdos <[email-masked]>
Date: Wed, 09 Mar 2011 11:46:34 -0700

Tim Tesch should respond to this question.

However, I would venture to say that as long as it's not a memory card 
or some adapter for another device and has a DSR with selectable CRU 
addressing, no conflicting names with other resident DSRs then it should 
work in GPL mode using ROMPAGE.  MDOS compatibility will require the DSR 
code to be in the MDOS Master DSR, so will require Tim or other MDOS 
maintainer to do that if there is room and need.

You did say Geneve not MDOS, but if you're really good you can write a 
stand-alone (no EA module support required) EA5 program, so whatever you 
want the card to do or to be controlled by the user can be accomplished 
with your EA5 program using EXEC -R from MDOS.  Not exactly MDOS 
compatibility, but maybe close enough?

Bill S

-- 
Bill R Sullivan (FDOS)
Go Forth+ or X4th99

---

From: fdos <[email-masked]>
Date: Wed, 09 Mar 2011 11:49:22 -0700

Hal,

Is your main system a full SNUG-TI card set system (SGCPU, HSPL & EVPC 
minimum)?

Bill S

On 3/9/2011 11:22 AM, hjalmarii wrote:
> --- In [email-masked], fdos<fdosbrs@...>  wrote:
>>

-- 
Bill R Sullivan (FDOS)
Go Forth+ or X4th99

---

From: tursi <[email-masked]>
Date: Wed, 9 Mar 2011 10:59:12 -0800 (PST)

> How about we design a game about llamas and how far they can spit.

You want to talk to Yak, at Llamasoft: 
http://www.llamasoft.co.uk

Great guy. Loves llamas :)

---

From: tursi <[email-masked]>
Date: Wed, 9 Mar 2011 11:02:44 -0800 (PST)

> maintainer to do that if there is room and need.

Thanks, Bill. It's just for file systems - my Linux device interface. If I 
did a PEB version, I should ensure it will work in the Geneve too, since 
there are people using it. I thought there were some electrical concerns 
though, extra bus lines or something.

But I guess if all the TI cards work then in theory there's not too much 
to worry about. ;) I don't know the difference between ROMPAGE and MDOS 
modes though.

---

From: "Michael Zapf" <[email-masked]>
Date: Wed, 09 Mar 2011 19:53:30 -0000

Hi Tursi,

> in mind to make a PEB card compatible with the Geneve?

check for AMA=AMB=AMC=1. This is necessary to avoid mirroring in the 19-bit address space.

Michael

---

From: fdos <[email-masked]>
Date: Wed, 09 Mar 2011 12:58:04 -0700

Some kind of memory card using bus addressing or adapter that is similar 
could require AMA, AMB, AMC, (AMD and AME GenMod) decoding especially 
when used with a GenMod Geneve.  RAMDISK and Corcomp mass storage 
devices along with early RAVE99 adapters (newer ones have some 
decoding).  TI and Myarc FDC/HFDC, SCSI, IDE and all RS-232 cards seem 
to be OK, but the Corcomp Triple Tech card is not for whatever reason. 
Speech and sound cards like Forti seem to be problematic, therefore 
require further decoding or addressing changes.

How do you plan to communicate between your Linux file system and the 
TI/Geneve?  Will there be data transfers over the PEB data bus?  Or will 
such transfers take place over a serial or PIO port?

Bill S

-- 
Bill R Sullivan (FDOS)
Go Forth+ or X4th99

---

From: Marc Hull <[email-masked]>
Date: Wed, 9 Mar 2011 12:43:52 -0800 (PST)

< I don't know the difference between ROMPAGE and MDOS modes though.>

I think I know that......Rompage on a Geneve  forces the computer to use the DSR's on the peripheral cards. Other wise the DSR's in MDOS are used in place of them.  I still don't know if this is tied directly to TIMODE or not.  Tim?

---

From: tursi <[email-masked]>
Date: Wed, 9 Mar 2011 12:45:12 -0800 (PST)

> when used with a GenMod Geneve.

I don't have much idea what you are talking about here. I understand AMA, 
AMB and AMC are additional address lines from Michael Zapf's message, and 
since I seem to remember some mention of them on Thierry's page, I can 
further research that and Genmod, I guess.

I've never owned, studied, nor honestly intended to support the Geneve (I 
wanted one back in the day though!), but if I do get the device working, I 
don't want to leave them out if they are easy to support. :)

> such transfers take place over a serial or PIO port?

It's going to be a standard DSR-based device, so yeah, everything over the 
data bus. The backend isn't so important and will be transparent to the 
machine. I originally resisted the concept of making a PEB version at all, 
but some people seem to want it, so I am entertaining it. :)

---

From: "hjalmarii" <[email-masked]>
Date: Wed, 09 Mar 2011 20:49:31 -0000

Bill, my main system consists of a TI keyboard with Tursi's keyboard adapter, P-Box with Ramdisk, Triple-tech card,SCSI card with three SCSI drives, IDE card with 1 GB CF card with four partitions, and the usual other stuff.  I still do most of my writing on that system every day.  I only use a clone to check email and the various TI sites.  --Hal

--- In [email-masked], fdos <fdosbrs@...> wrote:
> > --- In [email-masked], fdos<fdosbrs@>  wrote:
> >>

---

From: Marc Hull <[email-masked]>
Date: Wed, 9 Mar 2011 12:52:04 -0800 (PST)

< I originally resisted the concept of making a PEB version at all, but some people seem to want it, so I am entertaining it. :)>

http://www.circuitspecialists.com/prod.itml/icOid/5926

I guess we will see this interface in a couple of weeks ? ;-)

---

From: Gregory McGill <[email-masked]>
Date: Wed, 9 Mar 2011 12:51:39 -0800

TIMODE can use the mdos dsrs or ROMPAGE depending on how you set it in GPL
when you select the cart images etc theres a press XX for rompage. that
pulls in the dsr's from the cards. So for instance if I don't rompage I can
access the hdfc hd as HDS1. but if I rompage its WDS1.   If I rompage and a
emulation drive is configured it takes the place of DSK1. otherwise I just
get regular DSK1. etc.

Greg

On Wed, Mar 9, 2011 at 12:43 PM, Marc Hull <[email-masked]> wrote:

> I think I know that......Rompage on a Geneve  forces the computer to use
> the DSR's on the peripheral cards. Other wise the DSR's in MDOS are used in
> place of them.  I still don't know if this is tied directly to TIMODE or
> not.  Tim?
>
>
>
>
>
>
>
>
>
>
>   
>

---

From: tursi <[email-masked]>
Date: Wed, 9 Mar 2011 13:13:57 -0800 (PST)

> I guess we will see this interface in a couple of weeks ? ;-)

Thanks! That will be handy!

That's my summer project. At least, I say that to justify my working on 
the higher priority stuff right now. ;) In the meantime I'm still trying 
to source the Linux boards. It looks like the only way to do it on the 
cheap may be to do it myself, though it's a more complex board than I like 
(still, only three major ICs...)

---

From: Marc Hull <[email-masked]>
Date: Wed, 9 Mar 2011 14:30:46 -0800 (PST)

Uhhhh... Isn't it summer every day in sunny California?  I'll give you three weeks  then ;-)

How about the 5 cent tour on your I/O please....

--- On Wed, 3/9/11, tursi <[email-masked]> wrote:

From: tursi <[email-masked]>
Subject: Re: [TI994A] PEB Cards on Geneve
To: [email-masked]
Date: Wednesday, March 9, 2011, 3:13 PM

---

From: tursi <[email-masked]>
Date: Wed, 9 Mar 2011 14:50:44 -0800 (PST)

> How about the 5 cent tour on your I/O please....

I love you guys.

It's overcast today.

But, uh, what do you want to know about the I/O? My plans for the Linux 
device? It's not built yet, but will be based on the GROM-based I/O chip I 
used for the demo cartridge. Guess I could You-Tube that.. :)

---

From: "Michael Zapf" <[email-masked]>
Date: Wed, 09 Mar 2011 23:20:42 -0000

Hi Tursi,
 
> further research that and Genmod, I guess.

yes, the AMA-AMC lines are the 2^16, 2^17, and 2^18 positions. Due to the big-endian bit numbering, if you wanted to continue the address bus line numbering you would have to call them A(-1), A(-2), A(-3). 

If you have a look at the line definitions in the technical specs of the TI you will see that these lines are pulled up all the time. Interestingly, all TI peripheral cards check these lines, and thus work without problems in a Geneve system. There are some cards from third party, however, which lack this check. This works perfectly with a standard TI, and is likely to cause trouble with a Geneve, especially when you want to use a memory expansion.

As a technical detail, the Geneve has a memory mapper which adds 8 bits to the front of a 13-bit address. There are 8 such values for each of the memory areas 0-1fff, 2000-3fff, ..., e000-ffff.

That is, if you put a value of 3a into the first mapper byte, an access to 0000 will be routed to [0011 1010] [0 0000 0000 0000], or with another grouping: 0 0111 0100 0000 0000 0000.

To access a peripheral card, you would put the value ba into the third mapper byte. When you access the address 4567, this yields

[1011 1010] [0 0101 0110 0111] or 1 0111 0100 0101 0110 0111

(010 = A0-A2 as index for the mapper table)

Going from left to right, the digits are 
AME = 1
AMD = 0 
AMC = 1
AMB = 1
AMA = 1
A0 = 0
A1 = 1
A2 = 0
A3 = 0
...
A15 = 1

The normal Geneve only routes accesses with AME=1, AMD=0 to the P-Box, but does not set those lines (which are actually not specified as address lines, unlike AMA-AMC), so it suffices to check for AMA-AMC=1. A Genmod, however, routes all bits to the box, using (redefining) two more lines.

Michael

---

From: tursi <[email-masked]>
Date: Wed, 9 Mar 2011 15:27:28 -0800 (PST)

> yes, the AMA-AMC lines are the 2^16, 2^17, and 2^18 positions. Due to 
> the big-endian bit numbering, if you wanted to continue the address bus 
> line numbering you would have to call them A(-1), A(-2), A(-3).

All very useful, thanks! :) I will save this information off.

---

From: "Dan" <[email-masked]>
Date: Wed, 9 Mar 2011 18:28:29 -0500

I received one of those emails entitled "IDIOT SIGHTING"
this part was just too good not to share
Dan

At a good-bye luncheon for a dear, old coworker who was leaving the company 
due to 'downsizing.'
Our manager commented cheerfully, 'This is fun. We should do this more 
often.'
Not another word was spoken. We all just looked at each other with that 
deer-in-the-headlights stare.

This was a lunch at Texas Instruments.

---

From: Gregory McGill <[email-masked]>
Date: Wed, 9 Mar 2011 16:04:02 -0800

http://chzgifs.files.wordpress.com/2011/03/ohhaip1.gif

---

From: "fredkaal" <[email-masked]>
Date: Thu, 10 Mar 2011 16:06:22 -0000

My IDE DSR supports the BQ4847 and BQ4852 clock chip. Whatever you do ... please create something simular to the existing IDE card: same addresses, same memory layout etc.

Fred ;-)

---

From: Marc Hull <[email-masked]>
Date: Thu, 10 Mar 2011 08:39:17 -0800 (PST)

Thank you for responding Fred.

The truth of the matter is that the only change's to be made (tentatively of course) are the redesign of the card to use through hole components and the addition of another CF port.  The latter idea was inspired by using COPYFAT...

If there was an CF card buried in the middle of the board somewhere which could be maintained as IDE1 with a TI file structure then the one on the back of the card could be used as IDE2 and be the available for swapping in PC data to be transferred to the TI.  This begs the question of whether or not COPYFAT supports IDE2 ?

--- On Thu, 3/10/11, fredkaal <[email-masked]> wrote:

From: fredkaal <[email-masked]>
Subject: [TI994A] Re: IDE pulse check.....
To: [email-masked]
Date: Thursday, March 10, 2011, 10:06 AM

  

Fred ;-)

--- In [email-masked], "Marc H" <marc.hull@...> wrote:

---

From: "Jens-Eike Hartwig" <[email-masked]>
Date: Thu, 10 Mar 2011 19:48:27 +0100

My IDE card is in a full SNUG system, working with SGCPU, EVPC, HSGPL,
HRD16, BwG, SPVMC and ASCSI. Now I need a ninth slot for the RS232...
In the Geneve group, I asked for advice on using the IDE card under
MDOS. The conclusion was, that ist is possible to boot from the IDE
after some heavy tweaking of LOAD/SYS and the EPROM, but the MDOS master
DSR lacks support for IDE operation.

Jens-Eike

-----Original Message-----
Date: Wed, 09 Mar 2011 18:50:33 +0100
Subject: Re: [TI994A] IDE pulse check.....
From: fdos <[email-masked]>
To: [email-masked]

Bill S

---

From: fdos <[email-masked]>
Date: Thu, 10 Mar 2011 13:06:52 -0700

Marc,

On the most part TIMODE would be required.  Although I suppose you could 
write programs that don't require DSRLNK, GPLLNK, XMLLNK, and your own 
VDP utilities, etc, but I'm not good at that.

Bill S

On 3/9/2011 1:43 PM, Marc Hull wrote:
> I think I know that......Rompage on a GeneveÂ  forces the computer to use the DSR's on the peripheral cards. Other wise the DSR's in MDOS are used in place of them.Â  I still don't know if this is tied directly to TIMODE or not.Â  Tim?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

-- 
Bill R Sullivan (FDOS)
Go Forth+ or X4th99

---

From: fdos <[email-masked]>
Date: Thu, 10 Mar 2011 13:11:00 -0700

Tursi,

If worse comes to worse we who might have a problem with your device can 
always add the address decoder later, if necessary.

Bill S

-- 
Bill R Sullivan (FDOS)
Go Forth+ or X4th99

---

From: fdos <[email-masked]>
Date: Thu, 10 Mar 2011 13:12:39 -0700

Hal,

Your system doesn't qualify for what I'm seeking.  Thanks.

Bill S

On 3/9/2011 1:49 PM, hjalmarii wrote:
>> Is your main system a full SNUG-TI card set system (SGCPU, HSPL&  EVPC
>> minimum)?
>>
>> Bill S
>>

-- 
Bill R Sullivan (FDOS)
Go Forth+ or X4th99

---

From: Insane Multitasker <[email-masked]>
Date: Thu, 10 Mar 2011 14:57:43 -0600

I think others already explained this, so I'll be brief to answer your direct interogatory:
 
ROMPAGE:  The peripheral cards are controlled and accessed just as they would be in a TI system. Special Geneve IO routines,like the internal RAMdisk, horizon RAMdisk support, etc. are not available when the card ROMs are paged in. 
Normal Geneve IO:  The peripheral cards are controlled by the Geneve's master DSR. The on-card DSRs are bypassed and not accessible. 

In the case of the IDE card, the Geneve's master DSR doesn't know how to use the card. In the PC world, this is akin to installing a peripheral for which no driver is installed.  Same situation.  Unfortunately, the Geneve OS doesn't have an easy driver interface.  As I've noted earlier, I have a proof of concept version which patches MDOS to utilize the IDE's on-board DSR, through the Geneve OS, as SCS3.  So I am able to access my IDE drive just like a SCSI or MFM drive.  
 
Probably more than you thought you wanted to know.  ;)
 
Tim

To: [email-masked]
From: [email-masked]
Date: Wed, 9 Mar 2011 12:43:52 -0800
Subject: Re: [TI994A] PEB Cards on Geneve

---

From: fdos <[email-masked]>
Date: Thu, 10 Mar 2011 17:37:28 -0700

Jens-Eike,

Thanks for this info.  You have a slightly more SNUG-TI system than I, 
as I have a WHT SCSI card in my system.  I have a BwG FDC, but I prefer 
an HFDC to be in my very important TI-99/4P system.  I also must admit 
that my HRD-16 is in my TI-99/4A system which only has a 4 bank HSGPL 
card versus the 16 bank HSGPL in the TI-99/4P system--fair trade off I 
guess.

However, now I have to find out why my IDE card won't work in my 
TI-99/4P system.  There's never an end to some of these weird problems.

Bill S

On 3/10/2011 11:48 AM, Jens-Eike Hartwig wrote:
> From: fdos<[email-masked]>

-- 
Bill R Sullivan (FDOS)
Go Forth+ or X4th99

---

From: "hexbus" <[email-masked]>
Date: Fri, 11 Mar 2011 16:26:14 -0000

In my SNUG system, I tried the IDE card instead of my ASCSI, and the IDE card kept losing it's DSR (the DSR became corrupted).   I would have to reload the DSR quite frequently for some reason.

The IDE card works great with the 99/4A system, but since my PEB has the SNUG stuff (except the floppy controller), it's sitting on the shelf for right now, since my 99/4A system has the Corcomp 9900 Mini PES on it :-)

Jon

--- In [email-masked], fdos <fdosbrs@...> wrote:
> > From: fdos<fdosbrs@...>

---

From: "fredkaal" <[email-masked]>
Date: Fri, 11 Mar 2011 18:30:18 -0000

Maybe it is easier to use one of those double CF card adapters. That is what I used when I wrote copyfat and yes ... the IDE DSR supports a second IDE device. Depends on the number of partitions on the first device if the second one will become IDE2, IDE3, IDE4 or IDE5. A maximum of 4 partitions is allowed on the master and slave IDE device.

Fred ;-)

--- In [email-masked], Marc Hull <marc.hull@...> wrote:
> The truth of the matter is that the only change's to be made (tentatively of course) are the redesign of the card to use through hole components and the addition of another CF port.Â  The latter idea was inspired by using COPYFAT...
> 
> If there was an CF card buried in the middle of the board somewhere which could be maintained as IDE1 with a TI file structure then the one on the back of the card could be used as IDE2 and be the available for swapping in PC data to be transferred to the TI.Â  This begs the question of whether or not COPYFAT supports IDE2 ?
> 
> 
> 
> 
> 
> --- On Thu, 3/10/11, fredkaal <fgkaal@...> wrote:
> 
> From: fredkaal <fgkaal@...>
> Â 
> --- In [email-masked], "Marc H" <marc.hull@> wrote:
> 
> >
>

---

From: Marc Hull <[email-masked]>
Date: Fri, 11 Mar 2011 11:47:00 -0800 (PST)

Good info and excellent idea on the two headed connector.  Did not know they exist.

Another question.  If the clock chip were not installed and everything else was equal,  Would that affect the DSR in a catastrophic way ?

--- On Fri, 3/11/11, fredkaal <[email-masked]> wrote:

From: fredkaal <[email-masked]>
Subject: [TI994A] Re: IDE pulse check.....
To: [email-masked]
Date: Friday, March 11, 2011, 12:30 PM

  

Fred ;-)

--- In [email-masked], Marc Hull <marc.hull@...> wrote:

---

From: "fredkaal" <[email-masked]>
Date: Sat, 12 Mar 2011 10:58:25 -0000

No, I suppose not (I say carefully). The DSR only use the clock for time/data stamping the files. If the clock isn't set (some internal  flag tells the DSR so) it will not be used. The DSR loader checks what kind of clock chip is installed if one of those two can't be detected the simplest one is assumed (the one without the RAM).

Fred ;-)

--- In [email-masked], Marc Hull <marc.hull@...> wrote:
> --- On Fri, 3/11/11, fredkaal <fgkaal@...> wrote:
> 
> --- In [email-masked], Marc Hull <marc.hull@> wrote:
> 
> >
> 
> > --- On Thu, 3/10/11, fredkaal <fgkaal@> wrote:
> 
> > 
> 
> > From: fredkaal <fgkaal@>
>

---

From: "Tony Knerr" <[email-masked]>
Date: Sat, 12 Mar 2011 12:16:35 -0000

Perhaps the new IDE design can include an Eprom or Flash Memory to 
better hold the DSR contents?

Tony

---

From: Marc Hull <[email-masked]>
Date: Sat, 12 Mar 2011 06:49:37 -0800 (PST)

That would require some serious circuit changes I would thing.  Something we are trying to avoid.  Tell me if I'm wrong.

--- On Sat, 3/12/11, Tony Knerr <[email-masked]> wrote:

From: Tony Knerr <[email-masked]>
Subject: [TI994A] Re: IDE pulse check.....
To: [email-masked]
Date: Saturday, March 12, 2011, 6:16 AM

  

Tony

--- In [email-masked], "hexbus" <jon@...> wrote:

---

From: "epergrem" <[email-masked]>
Date: Sat, 12 Mar 2011 16:06:03 -0000

One possible solution might be nvSRAM.  There is a brief description at; http://en.wikipedia.org/wiki/NvSRAM.  

I'm not sure if it's available in a non-SMT version or not, but it may require very little in the way of a circuitry change.

Ernie

--- In [email-masked], Marc Hull <marc.hull@...> wrote:
>
> That would require some serious circuit changes I would thing.Â  Something we are trying to avoid.Â  Tell me if I'm wrong.
>

---

From: mark wills <[email-masked]>
Date: Sat, 12 Mar 2011 18:34:28 +0000 (GMT)

There's a very nice RAM chip available on the market that has a battery built 
into it. No extra circuitry required.

________________________________
From: Marc Hull <[email-masked]>
To: [email-masked]
Sent: Sat, 12 March, 2011 14:49:37
Subject: Re: [TI994A] Re: IDE pulse check.....

That would require some serious circuit changes I would thing.  Something we are 
trying to avoid.  Tell me if I'm wrong.

--- On Sat, 3/12/11, Tony Knerr <[email-masked]> wrote:

>> In my SNUG system, I tried the IDE card instead of my ASCSI, and the IDE card 
>>kept losing it's DSR (the DSR became corrupted).   I would have to reload the 
>>DSR quite frequently for some reason.
>> 
>> The IDE card works great with the 99/4A system, but since my PEB has the SNUG 
>>stuff (except the floppy controller), it's sitting on the shelf for right now, 
>>since my 99/4A system has the Corcomp 9900 Mini PES on it :-)
>> 
>> Jon
>
>

---

From: "fredkaal" <[email-masked]>
Date: Sun, 13 Mar 2011 08:52:01 -0000

The IDE DSR is it is now has some sector buffers (800 bytes per file) and data buffers here and there in allmost every page. Using EPROMS or FLASH memory will require a redesign of the DSR. A DSR for storage devices like IDE and SCSI does need same (paged) RAM for buffers. The IDE design as it is now (4k RAM Fixed, many 4k pages) made it doable. The USB memory design for example (many 8K pages) will make it IMHO more complex.

Fred ;-)

--- In [email-masked], "Tony Knerr" <tonyknerr@...> wrote:
> --- In [email-masked], "hexbus" <jon@> wrote:
> >

---

From: Tony Knerr <[email-masked]>
Date: Sun, 13 Mar 2011 08:43:46 -0400

Fred,

Is the Fixed 4k where the actual DSR code is contained, and the 4k 
banked ram are the buffers?
My comment about having some eprom for the DSR is to make the device 
more stable. If the Fixed
4k could be in Eprom or Flash, then the card would be as stable as the 
other hard disk controllers.
As it is now, my understanding is that the card is comparable to a 
Horizon Ramdisk or Pgram card,
where you have to reload the DSR every so often because of corruption 
issues.

If the new design contains a separate socket to address that 1st 4K, it 
could be a multipurpose socket
where the user could place either Ram or Eprom (an 8K chip would work 
well), depending on their
needs/wants. I'll bet more individuals would want the Eprom for 
stability over Ram for easy upgrading.
If it's working well enough with the current code, there should be no 
major concerns about upgrading
the DSR.

All that being said, it appears that it wouldn't be to difficult to do a 
hack to stack an eprom on top of
the Ram chip to accomplish the same result.

Tony

On 3/13/2011 4:52 AM, fredkaal wrote:
>
> The IDE DSR is it is now has some sector buffers (800 bytes per file) 
> and data buffers here and there in allmost every page. Using EPROMS or 
> FLASH memory will require a redesign of the DSR. A DSR for storage 
> devices like IDE and SCSI does need same (paged) RAM for buffers. The 
> IDE design as it is now (4k RAM Fixed, many 4k pages) made it doable. 
> The USB memory design for example (many 8K pages) will make it IMHO 
> more complex.
>
> Fred ;-)
>

---

From: Tony Knerr <[email-masked]>
Date: Sun, 13 Mar 2011 08:49:43 -0400

"Light bulb lights up above head"

If the card is going to have Compact flash, can 4k of it be used for the 
DSR?

Tony

On 3/13/2011 8:43 AM, Tony Knerr wrote:
> If the new design contains a separate socket to address that 1st 4K, 
> it could be a multipurpose socket
> All that being said, it appears that it wouldn't be to difficult to do 
> a hack to stack an eprom on top of

---

From: Marc Hull <[email-masked]>
Date: Mon, 14 Mar 2011 09:34:41 -0700 (PDT)

I think Jim is going to try to make this as flexible as possible while staying within the original  design in order for there not to be any DSR changes necessary.

probable changes are (nothing set in stone) ....

Through hole design.
Add a coin cell battery holder in case clock chip is not desired or battery dies.
Add 5V and GND vias at back of card to power IDE/CF converter.
Add the extra Geneve address decoding.

Jim should probably chime in here as he is doing the work ;-)

--- On Sat, 3/12/11, mark wills <[email-masked]> wrote:

From: mark wills <[email-masked]>
Subject: Re: [TI994A] Re: IDE pulse check.....
To: [email-masked]
Date: Saturday, March 12, 2011, 12:34 PM

  

      There's a very nice RAM chip available on the market that has a battery built into it. No extra circuitry required.

From: Marc Hull <[email-masked]>
To: [email-masked]
Sent: Sat, 12 March, 2011 14:49:37
Subject: Re: [TI994A] Re: IDE pulse
 check.....

 

Tony

--- In [email-masked], "hexbus" <jon@...> wrote:

---

From: "fredkaal" <[email-masked]>
Date: Mon, 14 Mar 2011 16:45:58 -0000

The IDE DSR consists of a root part at >4000 and pages at >5000.
All often used routines by the pages can be found in the root.

When entering the DSR a stackpointer is initialized, page 0 is
selected and writing the RAM is enabled.

When leving the DSR page 0 is selected and writing to RAM is
disabled. This is done to prevent loosing the DSR because of 
illigal writes at the >4000->5000 area! This made CALL IDELOAD()
work properly from TI basic.

First part of the root code @ >4000
All equates and DSR headers. First part of the init code and jump table to all level 2 and level3 functions and functions for reading	and writing file data from and to users PAB etc. (like VMBR & VMBW etc) 
Basic IDE controller functions. Sending commands and reading and writing secors

page 0 @ >5000: All the calls to be used from TI basic

Page 1: conatins all level 2 opcodes (>8x). These are >8x codes because debugging was a crime when I also used the >2x codes like HFDC and SCSI. In this way a knew for sure that the IDE card was found when placing a breakpoint at the BL *R9 instruction in the DSRLNK function.

Read / Write Sector >80
Format disk >81 (not used)
Modify file protection >82
Rename file >83
Read File Information >84
Write File Information >85 
Set Current Pathname >87
Create Subdirectory >88	
Delete Subdirectory >89
Rename directory >8A
Identify drive >8C 
Initialize IDE card
Functions for reading and creating FDR, DDR etc.	

Page 2: Various	
Time functions, sector allocation and sector free functions.
Miscellaneous routines for setting up VDP and character set
 
Page 3: Base level 3 IO functions. Thise IDE DSR can handle a maximum 
of 4 open files. The functions in page 3 jumps to the same function
belonging to the open file at page 11, 12, 13, 14.

Close a file
Delete a file
Level 3 initialization. 
Load a program file
Open a file
ead from a file
Rewind a file
Save a program file
Scratch record (not supported)
Return file status
Write to a file
Misc routines for checking if a file is allready open. Walk a path reading FDR, DDR etc.
Also contains sector buffers for:
	DDR	Directory data record
	FDIR	File descriptor index record
	FDR	File descriptor record
	SEC	File sector

Page 11, 12, 13, 14: These pages all contains the functions below for 
the main level 3 IO functions. These functions are called from the same functions in page 3.

Close a file
Read a directory
Open a file
Read from a file
Rewind a file
Write to a file
Misc routines for writing back changed sectors, reading in next sectors from open file, extending the number of AU's used by a file.
Also contains sector buffers for:
	DDR	Directory data record (only used by L3ODR$ and L3RDR$)
	FDR	File descriptor record
	FDIR	File descriptor index record (only used by L3ODR$ and L3RDR$)
	SEC	File sector

---

From: "Ksarul" <[email-masked]>
Date: Mon, 14 Mar 2011 12:48:43 -0400

That's pretty much it for now, Marc.  It really depends on how much of a
space hog the components end up being once I switch modes.  I won't really
do too much until I finish the pair of classes I'm taking right now (end of
April).  They are killers that suck the life out of my spare time, but I
needed to do them for the job, so all is well. . .and I've reached the
midpoint, so it is all downhill from here.

I'll probably set up an extension out the back with space for some CF
adapters, but will design it as a bit that can be easily removed so that it
can be moved around to the front of the PEB in a project box, connected via
IDE cable.  That way, those who use it regularly won't jiggle the card and
trash their system by accident.

Jim

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Marc Hull
Sent: Monday, March 14, 2011 12:35 PM
To: [email-masked]
Subject: Re: [TI994A] Re: IDE pulse check.....

I think Jim is going to try to make this as flexible as possible while
staying within the original  design in order for there not to be any DSR
changes necessary.

Through hole design.
Add a coin cell battery holder in case clock chip is not desired or battery
dies.
Add 5V and GND vias at back of card to power IDE/CF converter.
Add the extra Geneve address decoding.

There's a very nice RAM chip available on the market that has a battery
built into it. No extra circuitry required.

  _____  

That would require some serious circuit changes I would thing.  Something we
are trying to avoid.  Tell me if I'm wrong.

Tony

--- In [email-masked], "hexbus" <jon@...> wrote:
>
> In my SNUG system, I tried the IDE card instead of my ASCSI, and the IDE
card kept losing it's DSR (the DSR became corrupted). I would have to reload
the DSR quite frequently for some reason.
> 
> The IDE card works great with the 99/4A system, but since my PEB has the
SNUG stuff (except the floppy controller), it's sitting on the shelf for
right now, since my 99/4A system has the Corcomp 9900 Mini PES on it :-)

---

From: fdos <[email-masked]>
Date: Mon, 14 Mar 2011 10:53:34 -0700

Thanks Jon,

This pretty much matches my experience.  Which DSR are you using with 
your IDE card (IDEAL or Fred's)?

Bill S

-- 
Bill R Sullivan (FDOS)
Go Forth+ or X4th99

---

From: "Stuart" <[email-masked]>
Date: Mon, 14 Mar 2011 18:40:34 -0000

If you're looking at not using a clock chip and using a battery, I'd advise using a Dallas DS1210 IC to inferface the battery and chip select to the RAM. It stops the RAM being corrupted as power to the rest of the system dies. If you're using a BQ4847 clock chip, that chip provides this functionality.

Stuart.

--- In [email-masked], Marc Hull <marc.hull@...> wrote:
> --- On Sat, 3/12/11, mark wills <markrobertwills@...> wrote:
> 
> From: mark wills <markrobertwills@...>
> From: Marc Hull <marc.hull@...>
> --- On Sat, 3/12/11, Tony Knerr <tonyknerr@...> wrote:
> 
> From: Tony Knerr <tonyknerr@...>

---

From: Marc Hull <[email-masked]>
Date: Thu, 24 Mar 2011 09:02:58 -0700 (PDT)

I looked at the data sheet.  It appears that it may require two different batteries.  Am I reading that wrong ?  Is it one battery to two chip pins ?

--- On Mon, 3/14/11, Stuart <[email-masked]> wrote:

From: Stuart <[email-masked]>
Subject: [TI994A] Re: IDE pulse check.....
To: [email-masked]
Date: Monday, March 14, 2011, 1:40 PM

  

Stuart.

--- In [email-masked], Marc Hull <marc.hull@...> wrote:

> I think Jim is going to try to make this as flexible as possible while staying within the originalÂ  design in order for there not to be any DSR changes necessary.

---

From: "Stuart" <[email-masked]>
Date: Thu, 24 Mar 2011 22:22:06 -0000

The chip does support a second backup battery but for your application just the one battery should be sufficient IMHO - it should last at least a year or two. So you connect the battery to the VBAT1 pin, and ground the VBAT2 pin as described in the datasheet description.

--- In [email-masked], Marc Hull <marc.hull@...> wrote:
> --- On Mon, 3/14/11, Stuart <ti99@...> wrote:
> 
> From: Stuart <ti99@...>
> > --- On Sat, 3/12/11, mark wills <markrobertwills@> wrote:
> 
> > 
> 
> > From: mark wills <markrobertwills@>
> 
> > From: Marc Hull <marc.hull@>
> 
> > --- On Sat, 3/12/11, Tony Knerr <tonyknerr@> wrote:
> 
> > 
> 
> > From: Tony Knerr <tonyknerr@>
>