Image Map Image Map
Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: Compact flash on the Amstrad NC200

  1. #1
    Join Date
    Feb 2017
    Location
    Zürich, Switzerland
    Posts
    173

    Default Compact flash on the Amstrad NC200

    So someone just emailed me regarding my CP/M port to the NC200 saying that they managed to plug a Compact Flash card into the thing --- turns out that it fits fine if you remove the plastic case. And, completely to my surprise, the NC200 detects it, and they claimed they managed to format it.

    Received wisdom, including from Amstrad, is that you can only use the now very expensive SRAM cards on it: the hardware interface just maps the card RAM into memory. So, my suspicion is that the NC200 has spotted a PCMCIA card in memory-mapped-register mode, decided it's an SRAM card, and has just memory mapped the thing. Formatting only seemed like it worked due to no error checking (the NC200's internal file system is ridiculously simple).

    But this is really exciting because it suggests that if the card's in memory mapped mode, then the IDE registers are accessible. Which means it should be possible to write an IDE driver for it.

    Before I add this to already ridiculous list of projects:

    (a) does this sound at all plausible? My knowledge of PCMCIA isn't great.
    (b) has anyone done anything like this on the NC200 or other hardware?

  2. #2

    Default

    Quote Originally Posted by hjalfi View Post
    So someone just emailed me regarding my CP/M port to the NC200 saying that they managed to plug a Compact Flash card into the thing --- turns out that it fits fine if you remove the plastic case. And, completely to my surprise, the NC200 detects it, and they claimed they managed to format it.

    Received wisdom, including from Amstrad, is that you can only use the now very expensive SRAM cards on it: the hardware interface just maps the card RAM into memory. So, my suspicion is that the NC200 has spotted a PCMCIA card in memory-mapped-register mode, decided it's an SRAM card, and has just memory mapped the thing. Formatting only seemed like it worked due to no error checking (the NC200's internal file system is ridiculously simple).

    But this is really exciting because it suggests that if the card's in memory mapped mode, then the IDE registers are accessible. Which means it should be possible to write an IDE driver for it.

    Before I add this to already ridiculous list of projects:

    (a) does this sound at all plausible? My knowledge of PCMCIA isn't great.
    (b) has anyone done anything like this on the NC200 or other hardware?
    I assume they used a PCMCIA adapter with the case removed, rather than directly plugging in the CF card.
    Wikipedia says that all CF cards support memory-mapped mode. It should also be possible to use 8 bit data transfers.

    Here is a copy of the PCMCIA specs, volume 7 covers ATA devices:
    https://web.archive.org/web/20180809...andard_8.1.zip

  3. #3
    Join Date
    Feb 2017
    Location
    Zürich, Switzerland
    Posts
    173

    Default

    They showed me a picture, and yes, it's a PCMCIA adapter. There's plenty of space inside the NC200 itself and the only modification is removing the cover because the bulge in a PCMCIA II card won't fit through the slot in the cover.

    I haven't spotted anything in the spec which indicates what the default mode of the card is. It's entirely possible that the NC200's very limited PCMCIA interface doesn't allow the card to be reconfigured. I have found a reference in the NC200 docs to a bit which apparently allows access to attribute space, but I haven't had a chance to find out if it works yet.

    The other thing I'm concerned about is whether the voltage selection / power draw is compatible. Amstrad's hardware design was, um, famous for shortcuts here; I don't want to accidentally blow the driver chips in my increasingly-rare NC200.

  4. #4

    Default

    Quote Originally Posted by hjalfi View Post
    They showed me a picture, and yes, it's a PCMCIA adapter. There's plenty of space inside the NC200 itself and the only modification is removing the cover because the bulge in a PCMCIA II card won't fit through the slot in the cover.

    I haven't spotted anything in the spec which indicates what the default mode of the card is. It's entirely possible that the NC200's very limited PCMCIA interface doesn't allow the card to be reconfigured. I have found a reference in the NC200 docs to a bit which apparently allows access to attribute space, but I haven't had a chance to find out if it works yet.

    The other thing I'm concerned about is whether the voltage selection / power draw is compatible. Amstrad's hardware design was, um, famous for shortcuts here; I don't want to accidentally blow the driver chips in my increasingly-rare NC200.
    Yes, you can access attribute space, but after reading some of the spec I don't think it is necessary. Every card powers up in memory mode.
    The ATA registers are mapped at 0-7, with the lower and upper half of the data register also at every even/odd address in the range 400-7FF (perfect for block moves).

  5. #5
    Join Date
    Feb 2017
    Location
    Zürich, Switzerland
    Posts
    173

    Default

    Well, the good news is that I took the lid of my NC200, removed the card slider, and with a little programming I can now positively identify ATA PCMCIA cards via the attributes and when I read from the IDE sector register I get a 0x50, which is a sensible result telling me that the drive is ready and the last seek was correct.

    The bad news is that I wrote some code which initialises the ATA interface into 8-bit mode, and while that all seems to work, when I send an IDENTIFY command the NC200 starts making a funny noise and the screen changes slightly in a way which is compatible with the CPU voltage not being right (the funny noise being caused by the backlight driver changing frequency). And the device never responds to the command.

    This sounds suspiciously like the CF card is drawing too much current. But surely it wouldn't have to go into high-power mode for a measly IDENTIFY?

    Alternatively, and more plausibly, my hacked together init code is bad. Does anything here look obviously wrong? https://github.com/davidgiven/cpmish.../tools/flash.c

  6. #6
    Join Date
    Feb 2017
    Location
    Zürich, Switzerland
    Posts
    173

    Default

    Bah, turns out you have to multiply attribute RAM addresses by two, but not common RAM. So I was writing to all the wrong IDE registers... It now works; I can initialise and communicate with CF cards. I haven't tried reading or writing yet but I expect that to work, more-or-less.

    I say 'more or less' because there is something marginal with the power supply. Accessing the card causes noticeable brownouts which manifest as screen glitches and floppy drive stuttering. I have two CF cards; an old Lexar 16MB model and a much newer Crucial 1GB card. The old Lexar card causes the worst glitching, which makes sense as I'd expect the early tech to draw the most current.

    So while it works, it may not be reliable enough to actually use, and may risk damage to the machine. (Presumably why Amstrad didn't put a PCMCIA type 2 slot in it.)

  7. #7

    Default

    Quote Originally Posted by hjalfi View Post
    Bah, turns out you have to multiply attribute RAM addresses by two, but not common RAM. So I was writing to all the wrong IDE registers... It now works; I can initialise and communicate with CF cards. I haven't tried reading or writing yet but I expect that to work, more-or-less.

    I say 'more or less' because there is something marginal with the power supply. Accessing the card causes noticeable brownouts which manifest as screen glitches and floppy drive stuttering. I have two CF cards; an old Lexar 16MB model and a much newer Crucial 1GB card. The old Lexar card causes the worst glitching, which makes sense as I'd expect the early tech to draw the most current.

    So while it works, it may not be reliable enough to actually use, and may risk damage to the machine. (Presumably why Amstrad didn't put a PCMCIA type 2 slot in it.)
    Maybe you could turn off the floppy motor before accessing the card? The original IBM PC couldn't have both drives active because of power issues too.
    You don't need to set 8 bit mode explicitly, two consecutive reads from the data register should return the low and high byte. Also in assembly language you can do this:

    Code:
    	ld hl, 0c400h
    	ld de, Buffer
    	ld bc, 512
    	ldir

  8. #8
    Join Date
    Feb 2017
    Location
    Zürich, Switzerland
    Posts
    173

    Default

    Even with the floppy drive motor off it still chatters a little during a card read. I believe this is the stepper motor jittering.

    Sadly I've discovered that a CF card in Fuzix is out of the question because Fuzix needs a lot of SRAM card space for extra RAM --- 320kB. But it should work for CP/M. Deblocking and handling the partition table will be the usual annoyance. At least IDE should be fast enough not to need caching (unlike the floppy).

    The biggest issue will be the classic CP/M hard drive angst of trying to decide how big to make the volume. I'm using ZSDOS, which apparently supports volumes up to a gigabyte... provided I'm willing to lose 8kB of RAM to the allocation bitmap!

  9. #9

    Default

    There is a CP/M driver for IDE devices on Grant Searle’s web site. I derived my drivers from it, and can support 32 x 8GB partitions (16 on the master, 16 on the slave) which is more than enough. Blocking / deblocking is handled by the DRI code. You can choose how many drives to have active at once, then size your ALV accordingly. Implement a drive mapping table that can be accessed by a utility and you have full access to the IDE device, just not all partitions at the same time.

    Here’s a demo of the uIDE system on a Superbrain: https://youtu.be/8hshdu2_P7Q

    There is little point in having really large volumes on a CP/M implementation because you only have 16 user areas, so you’d a have lots of files per user area and a slow DIR (which as you know scans all the files on the directory to find those in your current user area). On my driver there is a noticeable pause in DIR output on C: while the system skips the files in user areas 1-15. I set it up for 512 files per partition, and it is loaded with the contents of the N8VEM demo image, so lots of files on drives C-F.

    I find your power issues strange. I agree that a tiny CF card shouldn’t make any difference to it. I wonder if a DOM would improve matters? I use them exclusively because some CF cards fail to identify in 8 bit mode. You’d need an adapter, of course.

    I’m still hunting for an NC200..
    Last edited by JonB; November 19th, 2019 at 12:04 AM.

  10. #10

    Default

    In this routine

    Code:
    read_byte:
        ! HL = card offset, B = common/attribute
        
        lxi d, 0xc000
        dad d                   ! hl = absolute address
    
        di
        mvi a, CARD0_BANK
        out PORT_BANK3          ! 0xc000 is now pointing at card memory
        mov a, b
        out PORT_BAUDRATE       ! PCMCIA reading attribute memory
        mov e, m                ! read byte
        mvi d, 0
        mvi a, USER3_BANK
        out PORT_BANK3          ! 0xc000 is now pointing at user space
        ei
    
    ret
    the value in B is output to port 30h to select attribute or common space (bit 7). Bit 5 must be set to disable the floppy motor, but the calling code leaves it clear. But maybe you already fixed this?

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
  •