Image Map Image Map
Page 29 of 36 FirstFirst ... 19252627282930313233 ... LastLast
Results 281 to 290 of 355

Thread: I wish to create a new DMA/RAM expansion card for the Tandy 1000 line.

  1. #281
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,462

    Default

    Quote Originally Posted by eeguru View Post
    You don't have to rely on the CF card to do such things. JR-IDE maps the ATA/IDE register map into PC memory space just above the option BIOS and aliases the data register at 512 consecutive address locations in PC memory space. It's so rep movsw can be used to transfer an entire disk block on an 8088 without intermediate instruction fetches slowing it down in a traditional loop.
    JR-IDE would need its CPLD do that to enable that function with plain IDE devices, certainly. (I assume it implements some auto-increment logic that tells the IDE drive to pull another data word every time one is read off the aliased space.) Section 4.3 of this datasheet briefly outlines the similar capability built directly into CF cards. I think it's actually closer to how JR-IDE works than I recalled; I thought it was actually mapping the 512 bytes of the block to a random access buffer but, no, a read to *anywhere* inside the address space it maps out for reading/writing increments the data register. Totally just faking it so those block move instructions can work, it actually doesn't care about the contents of address lines A4-A9.

    Using the capability built into the CF card would be useful if you want to get it for "free", but it does of course limit you to CF, not general IDE.

  2. #282
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,462

    Default

    Quote Originally Posted by blackepyon View Post
    Yeah, it does have CGA (with inverted colors), but I recommend playing games in monochrome if you're epileptic. It changes, either the AC frequency or the voltage (I don't remember which), of the pixel to get the two intermediate shades of the CGA pallet, and the flicker is noticeable.

    Anyways, it would make sense if that extra 16K is for a 32K video page, the display can do 640x200. Question is what the 32K page at A800 is for.
    Standard CGA only needs 16k for its standard resolutions (640x200)/8=16,000, so I'm not sure why the 1100 would need any more RAM than that. Have you tried poking around with BASIC to see if it's actually a writable store, or to see if it looks like it's an alias of something else? (One possibility is they really brutally skimped on address decoding logic, so the same 16k is phantom-ed across a smear of different locations. That wasn't uncommon in cheap computers back then; early Macintoshes in particular are notorious for having multiple phantom copies of RAM and I/O smeared across vast swathes of address space.)

    I just checked something, and you can actually confirm that BC00 block you see on a Tandy 1000 is a shadow of B800 within Checkit. If you view that area of "Hi RAM" you'll get a hex dump, and the contents have "17" for every even byte, and "C9 CD 20 42..." for the odd bytes. Looking at a chart of the PC character set "C9" is the "upper right corner" box symbol, CD is the "=" line symbol, etc. In other words, it's filled with Checkit's own output. Maybe Checkit on the 1100 will show the same?

    (The "17s" are the attribute code for blue background, white foreground.)

  3. #283
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,462

    Default

    Back to memory card matters, I have discovered something interesting. Prior to this week the one diagnostic that was regularly giving me pause was Checkit3's extended RAM test kept blowing "parity errors"; never consistent about where, sometimes in the built-in RAM. Anyway, just for laughs I decided to try again, since I'd made the major changes of adding the CF board and enabling UMBs. And... so far it's run three extended cycles with no errors.

    The things that have changed:

    1: I added the CF card
    2: Running under DOS 5 instead of Tandy DOS 3.2, and
    3. When I put in the CF card I removed the memory card, observed that the chips in the thrashed sockets seemed a little loose *again*, and really bore down on them to reseat them before attaching the CF card. (It's still on my to-do list to desolder them and either replace with new sockets or just attach the chips directly to the board.)

    Putting aside some possible incompatibility with DOS 3.2 either adding the CF card magically stabilized something or I still had a loose connection. I'm guessing it's the latter but it's "interesting", and possibly very encouraging, that it *can* pass that test.

    Machine totally flunks the DMA controller test on the "System Board" menu item, though.

  4. #284
    Join Date
    Mar 2011
    Location
    Atlanta, GA, USA
    Posts
    1,477

    Default

    Quote Originally Posted by Eudimorphodon View Post
    JR-IDE would need its CPLD do that to enable that function with plain IDE devices, certainly. (I assume it implements some auto-increment logic that tells the IDE drive to pull another data word every time one is read off the aliased space.) Section 4.3 of this datasheet briefly outlines the similar capability built directly into CF cards. I think it's actually closer to how JR-IDE works than I recalled;
    I don't know where you are coming from. Every time you read a word from the IDE data register at CS0/A=0, you get the next word in the sector. You read 256 times from the same IO address to transfer a sector. All I did was alias the data register at 512 consecutive memory locations by not qualifying the lower 9 address bits. It's the 8088 that auto-increments during a rep mov, so every time the CPU increments and reads or writes the next word of the string copy, it still gets the single IDE data register.

    The CPLD on the card is just for chip reduction because of the limited space of the side-car. Everything the CPLD does can be easily done in discrete logic; maybe 8 chips max.
    "Good engineers keep thick authoritative books on their shelf. Not for their own reference, but to throw at people who ask stupid questions; hoping a small fragment of knowledge will osmotically transfer with each cranial impact." - Me

  5. #285
    Join Date
    Mar 2011
    Location
    Atlanta, GA, USA
    Posts
    1,477

    Default

    Quote Originally Posted by Eudimorphodon View Post
    JR-IDE would need its CPLD do that to enable that function with plain IDE devices, certainly. (I assume it implements some auto-increment logic that tells the IDE drive to pull another data word every time one is read off the aliased space.) Section 4.3 of this datasheet briefly outlines the similar capability built directly into CF cards. I think it's actually closer to how JR-IDE works than I recalled;
    I don't know where you are coming from. Every time you read a word from the IDE data register at CS0/A=0, you get the next word in the sector. You read 256 times from the same IO address to transfer a sector. All I did was alias the data register at 512 consecutive memory locations by not qualifying the lower 9 address bits. It's the 8088 that auto-increments during a rep mov, so every time the CPU increments and reads or writes the next word of the string copy, it still gets the single IDE data register.

    The CPLD on the card is just for chip reduction because of the limited space of the side-car. Everything the CPLD does can be easily done in discrete logic; maybe 8 chips max.

    The result is a pretty staggering performance rate for an 8-bit machine. The 4.77 MHz 8088 performs DOS transfers at more than 300 KByte/s.
    "Good engineers keep thick authoritative books on their shelf. Not for their own reference, but to throw at people who ask stupid questions; hoping a small fragment of knowledge will osmotically transfer with each cranial impact." - Me

  6. #286
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,462

    Default

    Quote Originally Posted by eeguru View Post
    I don't know where you are coming from. Every time you read a word from the IDE data register at CS0/A=0, you get the next word in the sector. You read 256 times from the same I/O address to transfer a sector. All I did was alias the data register at 512 consecutive memory locations by not qualifying the lower 9 address bits. It's the 8088 that auto-increments during a rep mov, so every time the CPU increments and reads or writes the next word of the string copy, it still gets the single IDE data register.
    Where I'm coming from is I just didn't think very deeply about how you'd do it with discrete components; thinking about it just a hair longer you're absolutely right, you could just wire it up so the same 512 bytes would trigger the same port and it'd do exactly what's described in the CompactFlash documentation. The reason I was thinking there must be more to it is because the CF connector actually has pin assignments for A00-A10 inclusive, while an IDE port only has A0-3. (See page 3.1 of that PDF I linked to, the 11 address pins are 8, 10-13, and 13-20.) Frankly I don't understand why they're even there going through section 4-6 again because there *are* no circumstances in which A4-A9 seem to matter; A10 looks like the selector between the control/status registers and the page where they define that block moves should happen in? (???, because they also seem to show it overlaying the first page in section 4.3...)

    Seriously, I apologize for whatever offense, I didn't mean to dismiss anything about what the JR-IDE does. I was just pointing out that a technique for doing memory-mapped I/O that allows block moves is built into the specification for CF, IE, in the docs. If you invented it all on your own for the JR-IDE I'm genuinely sorry if you thought I was disparaging you somehow. I mean, it's there in the PDF, I'm not making it up, and the last thing I said was, huh, I bet that does work like how you did it on your device, because I'd initially misremembered and thought the whole point of it having A0-A10 lines on the CF connector was it actually did present a buffer that could be randomly accessed. (And that you had to hit some register to save changes to that buffer.)

    Really, I'm just trying to learn here, because I don't know all this stuff off the top of my head, and share what little I do know. Looking again at the design in the link Blackepyon threw out I see that the difference between how they describe it in the CF documentation and how they did it is they wired the "high" address line to a lower one on the CPU side so they *can't* use a block-move instruction, the data register is just a single location. (I have zero experience with 68HC912 assembly language but looking at the code it looks to me like the driver source is grabbing/writing a byte at a time and only incrementing a buffer-in-RAM location, not using a block move command that increments both source and destination.) So, basically, memory-mapped I/O that treats it like a port addressed device.

    Whatever is rubbing you the wrong way, I'm sorry. If you only want to see 100% fully baked and accurate information I'll look for another forum to bounce stuff around in.
    Last edited by Eudimorphodon; August 31st, 2019 at 01:49 PM.

  7. #287
    Join Date
    Feb 2017
    Location
    Chilliwack, BC, Canada
    Posts
    421

    Default

    Quote Originally Posted by Eudimorphodon View Post
    Really, I'm just trying to learn here, because I don't know all this stuff off the top of my head, and share what little I do know.
    I think most of us are in that boat
    My vintage systems: Tandy 1000 HX, Tandy 1100FD, Tandy 1000 RSX, and some random Pentium in a Hewitt Rand chassis...

    Some people keep a classic car in their garage. Some people keep vintage computers. The latter hobby is cheaper, usually takes less space, and is less likely to lead to a fatal accident.

  8. #288

    Default

    Quote Originally Posted by blackepyon View Post
    I think most of us are in that boat
    Most definitely, I'm just not as public with my failures.... Well except my smart watch reverse engineering video, I shared that because the mistakes I made were so dumb it was comical.
    My Retro Collection:
    CBM: C64, Amiga 500 x2, 600 & 1200
    Apple's: IIc, Mac SE, LCII, LC630 & Power Mac G3/233 Desktop
    PC's: K6-III+ 500 System + Roland MT-32 & Tandy 1000 EX 640kb, 3.5" FDD, CF-IDE 4GB HDD
    Visit my Tindie store for Tandy 1000 Adapters for EX, HX, SX, SL, TX & TL etc

  9. #289
    Join Date
    Mar 2011
    Location
    Atlanta, GA, USA
    Posts
    1,477

    Default

    Quote Originally Posted by Eudimorphodon View Post
    Seriously, I apologize for whatever offense. Whatever is rubbing you the wrong way, I'm sorry.
    Didn't mean to give off that impression. I'm lurking because the thread is an interesting read. Keep going!
    "Good engineers keep thick authoritative books on their shelf. Not for their own reference, but to throw at people who ask stupid questions; hoping a small fragment of knowledge will osmotically transfer with each cranial impact." - Me

  10. #290
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,462

    Default

    It's just the way I'm wired to find it useful to talk a problem through while figuring the answer. (Helps to mix some swearing in from time to time.) You'll wind up in some dead ends, but having forensic evidence to retrace where the logic went pear-shaped helps weed out the wrong paths further down. Whee.

    Anyway, I think the TL;DR from all that is theoretically at least if you're suck with a bus connector that only has memory support signals on it there's almost certainly some kind of solution for hanging a mass storage device off it. The question would be how hard it'd be to patch the XT-IDE bios. If it already supports configurations *like* that there's at least a path. (The worst-case scenario would probably be if you had a connector that was specifically designed to support a DRAM card and was set up for RAS/CAS multiplexed address signals, etc behind a memory controller. An example for that, assuming if I'm recalling correctly, which I may not, is the memory slot in an Apple IIgs. My recollection is it's basically wired like a SIMM socket.)

    In other new, left Checkit3's extended test loop several more times through lunch today and my RAM board is passing consistently now. (Also updated the firmware to the latest for the CF yesterday and it's still apparently working fine, although Checkit's disk test says it's running 5k a second slower. Guess it doesn't matter when it's 293 vs 298Kps.) So for an EX at least I'm almost optimistic that I managed to keep the "major deal-breaker design boners" count down to one this prototype round. Still wondering WTF is the deal with the HX, though...
    Last edited by Eudimorphodon; August 31st, 2019 at 09:01 PM.

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •