Image Map Image Map
Page 36 of 55 FirstFirst ... 2632333435363738394046 ... LastLast
Results 351 to 360 of 543

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

  1. Default

    Quote Originally Posted by Eudimorphodon View Post
    I did get a toy in the mail I'm going to try to test soon. I ordered one of those very compact direct-plug 44 pin (laptop) IDE to SD adapters, because I found a couple pages that said their bridge chips were 8-bit mode compatible. I have the parts I need to to try hooking it up to my prototype, if it works I'm considering the idea of making a board with a 44 pin 2mm pitch connector on it. It wouldn't save *much* space on the board but it is a lot smaller than the CF->40 pin sleds and SD has convenience advantages. (And it's still through-hole for dinguses like me who keep putting off tackling surface mount.)
    I have a selection of those adapters and have read that claimed spec as well, none of them worked in my 1110HD which has 8 bit IDE. That laptop is known to be very picky about HDs so it could be the laptop's fault. SMT isn't all that scary for assembly for single components like passives, even for most ICs like you would probably use getting it right on the first try for solder paste and bake is pretty easy. I manually populated a few SMT PCBs and it wasn't that bad. It gets more complicated to get a good result when you start trying to do BGA components manually, and more specialty masks and such are needed. If you could save a ton of real estate and make the project happen by using some SMT components I think you will find the bark worse than the bite.

  2. #352
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,576

    Default

    Quote Originally Posted by dJOS View Post
    I havent gotten that far TBH, I havent had the time today to even look sideways at KiCad. That said I assumed it'd be no larger than an OEM PLUS card.
    I've been aiming for the 100x100mm size because it's *so* cheap to get boards under those dimensions. A full Plus card is closer to 100x160, which would make life a lot easier, but using the insta-quote on PCBway that'd make a prototype run cost $35 instead of $5. (Before shipping.)

    Since I have technically proven the individual circuits I could try laying out a "Production" board at the larger size. I'm kind of hesitant to blow the money unless I actually had some "preorders", though. I want to run another prototype of the RAM circuits incorporating some fixes and extensions, I'd hate to go straight to a big, expensive boards with those and have it be wrong.

    Oh nice - however if you stick the CF sled on the bottom of the board (Tandy Style) along with a pair of DB9 sockets then you'll have more realestate for SMD parts on the top side.
    Two DB9 sockets actually come pretty close to filling the available back panel space in these machines, there's definitely not room to have a CF and two DB-9s accessible from the outside on the same card. I'm actually pretty happy with my current arrangement of having the CF facing inside the machine, where it sits now it's not hard to pop the top and fish it out, but if I had the same sled on a longer card it would push it into the area under the keyboard and make it less accessible. (I've actually only pulled it a couple times since I got it running, and that was to experiment with a different DOS installed on another card. I've been transferring software and data via the Gotek, or increasingly via Kermit since I got that running.)

  3. #353
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,576

    Default

    Quote Originally Posted by RetroGaming Roundup View Post
    I have a selection of those adapters and have read that claimed spec as well, none of them worked in my 1110HD which has 8 bit IDE. That laptop is known to be very picky about HDs so it could be the laptop's fault.
    Here's one of the pages that reports success with the laptop IDE-to-SD adapters:

    http://www.enide.net/webcms/index.ph...adapters-8-bit

    I don't think the 1110 HD is really "8-bit IDE"; my understand is that the short-lived XTA "standard" used on late-model XTs back in the day is different from CF's 8-bit ATA subset in both a wiring and an API standpoint... but maybe the 1110 HD uses some other weird variant.

    SMT isn't all that scary for assembly for single components like passives, even for most ICs like you would probably use getting it right on the first try for solder paste and bake is pretty easy. I manually populated a few SMT PCBs and it wasn't that bad. It gets more complicated to get a good result when you start trying to do BGA components manually, and more specialty masks and such are needed. If you could save a ton of real estate and make the project happen by using some SMT components I think you will find the bark worse than the bite.
    I've been thinking of going ahead and laying one out with SMT just to see how much it gains. I'm actually not entirely convinced it'll make a ton of difference in the real estate without also going to a multi-layer board, but it's probably worth going through the motions. If nothing else I have four SMT DS1315s I need to use up.

  4. #354
    Join Date
    Jul 2017
    Location
    Portland, Oregon, USA
    Posts
    211

    Default

    Quote Originally Posted by Eudimorphodon View Post
    Yeah, I'm not comfortable leaving it like that forever, which is why I'm being nitpicky about making *absolutely* sure there's not a conflict before we say that a no-decoding 512k base RAM solution is OK.



    I think the easier solution is just playing it safe and decoding 384k. That one-chip 74LS/HCT00 solution totally works, for reals! Did you already post how you're trying to use a '151 to decode 384k? I grant I'm not familiar with that part, and maybe I'm especially thick today because I'm not quite clear how you'd use it for this function... (think, think) oh, wait, I see it. Sure, that should work too. I wouldn't think that gate delay from that part should be a problem. With my board, which uses a couple strategies depending on which chip select, there can be as many as three levels of gates in the decoding line, and it seems to work fine. (And doing what may well be flawed math based on the propagation delays in the datasheet and my reading of the timing charts also suggests it should be fine.) If it's not working with the decoder I'd definitely suspect wiring noise?

    The worry I'd have with using some sort of utility to poke a new value into the Big Blue and assuming that settles it is I wouldn't be confident that the Tandy doesn't keep in its back pocket somewhere what the value is "supposed" to be and resets that register when it changes graphics modes or something via BIOS calls. Again, it'd be really nice to be able to *read* that register.



    I assume the behavior would be the same as the TX/TL, which I believe just swaps pages around in the B0000 area. I read a blog entry once that described how the 768k TX/TL breaks compatibility with some Tandy 1000 titles, and that makes perfect sense if the problem is that assume they can write to the graphics page's low RAM location like you can in a PCjr. On one hand setting up an EX like that would be a neat parlor trick and the way to get absolutely the most base RAM, because you could have 640k instead of 624k, without adding a VGA card, but the compatibility tradeoff realistically probably wouldn't be worth it. I wonder if there's any software that actually uses all 256k possible video RAM in a regular EX/HX anyway. Apparently BASIC can't.
    Hi all! Sorry I was away on holiday since the 4th and just got back. Decided to take a fresh look at the 1000EX memory card.

    I ended up trying a 74LS157 MUX (versus a LS00) just because it's much less wiring. I wanted to map the extra 128k up to C0000h to DFFFFh and while you can do that with a 74LS00 (quad NAND) and 74LS32 (dual OR) I just did it with a 74LS157 MUX and the 74LS32 since it's just simpler wiring. (As I'm doing it be hand.) And this won't be conflicting the upper 128k with the motherboard RAM anymore.

    Here is the logic diagram:


    I wired up the LS157 and it works. (Testing in my 1000EX) Memory check is good in checkit.

    https://imgur.com/cvmYXqM
    https://imgur.com/f6Wadko

    And since I don't have the OR gate installed yet, I will be seeing Hi-RAM but it's just a mirror. 40000h - 5FFFFh is mirrored to C0000h - DFFFFFh.
    https://imgur.com/hbgx35k

    Working exactly as I had hoped.

    Ok need to read more of the thread, I see lots of activity since I was away!!
    -- Adrian's Digital Basement

  5. #355
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,576

    Default

    Quote Originally Posted by misterblack View Post
    I ended up trying a 74LS157 MUX (versus a LS00) just because it's much less wiring. I wanted to map the extra 128k up to C0000h to DFFFFh and while you can do that with a 74LS00 (quad NAND) and 74LS32 (dual OR) I just did it with a 74LS157 MUX and the 74LS32 since it's just simpler wiring. (As I'm doing it be hand.) And this won't be conflicting the upper 128k with the motherboard RAM anymore.
    That's 74LS157 in an interesting part, I need to wrap my head around its possibilities a little more. It looks like you're using essentially the same scheme I am to split the RAM chip between base and UMBs, IE, selectively inverting (with that OR gate) A17 for the otherwise overlapping 128k page.

    Don't forget that if you fill up all of C0000-DFFFF on an HX you'll have no place for a BIOS extension ROM. On an EX you could put an XT-IDE in the E-page, shouldn't be a problem. My card uses three chips for the combined RAM/ROM decoding because it seemed like the most straightforward way to get a 64k resolution for enabling either RAM or ROM in the UMB area; I'm currently trying to figure out of there's any way I could enable splitting the C-page into 32k chunks without adding another chip (so far I haven't come up with one) to enable a 96k UMB from C8000-DFFFF in an HX with ROM at C0000-C7FFFF, or doing flash at C0000-C7FFFF or C8000-CFFFF in an EX, keeping the 128k of UMBs from D0000-EFFFF and leaving 32k open for a network card. (Which requires 4k or so of space for the packet buffer.)

    I think I will need to bite the bullet on the extra chip, but it's fun to fool with the most minimal possible solutions.

  6. #356
    Join Date
    Jul 2017
    Location
    Portland, Oregon, USA
    Posts
    211

    Default

    Sorry got so sidetracked before I replied. The proto board worked well (on the EX) with the LS32 and LS157 giving me 128k of working high memory.... My board isn't working properly in the HX though (won't even pass boot memory check) -- due to those spurious 40ns pulses on the address lines... Need to investigate what's going on there. (Possibly bad latch on the address bus....)

    Good call on the E0000-EFFFFh! I didn't even think about the fact the 1000HX has the boot ROM there. DOH!

    Ok so here is a two chip solution to map 0-384k and then D0000-DFFFFh (wasting C0000-CFFFFh in the SRAM) -- and not mapping any ROM.



    Truth table:


    I'm building out a board with the RAM expansion and a XT-CF on a single board so I just changed it to only map the 64k. Let me try to figure out that 32k + 64k mapping. I'm using a LS688 to map the XT-CF ROM on this board -- so it's 3 chip too. Allows mapping anywhere into C0000 through EFFFF ....
    -- Adrian's Digital Basement

  7. #357
    Join Date
    Jul 2017
    Location
    Portland, Oregon, USA
    Posts
    211

    Default

    Quote Originally Posted by Eudimorphodon View Post
    That's 74LS157 in an interesting part, I need to wrap my head around its possibilities a little more. It looks like you're using essentially the same scheme I am to split the RAM chip between base and UMBs, IE, selectively inverting (with that OR gate) A17 for the otherwise overlapping 128k page.

    Don't forget that if you fill up all of C0000-DFFFF on an HX you'll have no place for a BIOS extension ROM. On an EX you could put an XT-IDE in the E-page, shouldn't be a problem. My card uses three chips for the combined RAM/ROM decoding because it seemed like the most straightforward way to get a 64k resolution for enabling either RAM or ROM in the UMB area; I'm currently trying to figure out of there's any way I could enable splitting the C-page into 32k chunks without adding another chip (so far I haven't come up with one) to enable a 96k UMB from C8000-DFFFF in an HX with ROM at C0000-C7FFFF, or doing flash at C0000-C7FFFF or C8000-CFFFF in an EX, keeping the 128k of UMBs from D0000-EFFFF and leaving 32k open for a network card. (Which requires 4k or so of space for the packet buffer.)

    I think I will need to bite the bullet on the extra chip, but it's fun to fool with the most minimal possible solutions.
    Have been thinking about the issue too -- I think the best I came up with is using a spare LS32 OR gate I had to chunk up the wasted space to just allocate the high memory from C8000 to DFFFF... leaving that 32k free for the XT-IDE BIOS to reside in, etc. Hmmm.... or use that extra OR gate to allow for a jumper to disable the high memory entirely? What would be more useful? My board has no passthrough connector so it's not like I'll be ever adding anything else.



    So many decisions! I don't see a way of being more dynamic with the mapping (Allowing you to select) without adding more chips either.
    -- Adrian's Digital Basement

  8. #358
    Join Date
    Jul 2017
    Location
    Portland, Oregon, USA
    Posts
    211

    Default

    I fiddled around a bit with Logic Friday and figured out how to have either 128k or 96k without adding a gate:



    Using this decoding logic with one LS00 and one LS32 and adding two jumpers gives you the ability to have either C0000-DFFFF or C8000-DFFFF. Well one jumper. The other jumper disables high memory entirely.

    A second set of eyes on this layout to confirm it'll work would be great.
    -- Adrian's Digital Basement

  9. #359
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,576

    Default

    Quote Originally Posted by misterblack View Post
    A second set of eyes on this layout to confirm it'll work would be great.
    I'll try to wrap my head around it when I'm done banging my head on that stupid day job thing.

    My decode solution is probably a lot less clever than yours; the bottom 384k is the three-gates-of-the 7400 thing, while for the upper decoding I went with a bog-standard 74138 arrangement to slice the upper 512k into eight 64k chip selects that can be used for arbitrary purposes. The third chip is a 7408 quad AND that's used to collate the individual chip selects and, in combination with the leftover '00 gate, do the a17 invert select. The ROM uses one of the 74138's selects so I don't need a separate decoder for it, but that sticks it with a 64k slice. It does make it easy to add per-page enable/disable jumpers, though. (With a three-position jumper it would be possible to select RAM *or* ROM for a given address.)

    The original thought I had for increasing the resolution for the upper page was wiring the 74138 so instead of giving me 8 selects from 80000h-F0000h it gives me 8 32k pages from C0000-F8000h. The problem with that is I'd need more AND gates to tie everything together. So my choice seems to be either add another AND package or chain some logic to split the current 64k C select in half (A quad NAND would do). I was leaning towards the latter but there are flexibility advantages to the former. The three configs I see the most value in supporting are:

    1: ROM: C8000-CFFFF, RAM: D0000-EFFFF. (128k UMBs for EX only, leaves 32k for other peripherals at C0000-C7FFF.)
    2: ROM: C0000-C7FFF, RAM: C8000-DFFFF. (96k UMB, upper memory is full in an HX. 64k @ E0000 open in EX.)
    3: ROM: C8000-CFFFF, RAM: D0000-DFFFF (64k UMB, leaves C0000-C7FFF for other peripherals in an HX)

    Which can all be handled by splitting the C-page. Maybe it's worth running it through Logic Friday to see if it's possible to handle these three decode situations more efficiently than the '138+ANDs can; I fiddled idly with it at some point and didn't come up with a solution that looked better, at least with the logic packages it knows. There are some solutions that work if I add just *one* more gate, I'm kind of tempted to try to incorporate one of those little surface-mount single-gate packages like a 74HCT1G08. (Although I think I can fit another DIP-14 if I need to.)

  10. Default

    @misterblack I had commented on your recent Youtube video in regards to this, and to be honest, I have not read through this entire thread here to see if you have already done this.. but is there a particular reason why you aren't buffering the datalines through a 74xx245 on your SRAM card? Both currently freely available designs that I have tried on my HX have no issues, but have the data lines buffered, usually with an ACT245

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
  •