News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_jamesots

SD Cards on the PCW

Started by jamesots, 23:21, 03 November 17

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamesots

Some of you may have already spotted my PCW project, but in case you haven't, I thought I should introduce it here.


So far I've added an AY sound chip and joystick port, composite video output, 512Kb of extra RAM, 32Kb of ROM and an SD Card. The SD Card uses its own FID drivers, rather than emulating a floppy drive like the HxC things. The PCW can boot from the ROM, which in turn loads CP/M off the SD card.


This evening I got it working with 4 logical 16Mb drives on the SD card, and I'll soon be updating the drivers so that an SD card can appear as potentially hundreds of partitions, which can be mapped to any of the 4 drive letters. (The FID driver already has some of this functionality, but it's not complete yet).


I'm hoping to produce a proper PCB at some point, but I'm not going to do that yet because I'm still trying to think of more features to add!


I also need to make my github projects public, but currently they have a lot of junk in them, or copyright things like J15CPM3.EMT, which I need to remove before I can publish them.


You can follow my project here: https://hackaday.io/project/27549-the-pcw-project

Zoe Robinson

FID drivers? As in the SD card is being accessed like a giant floppy disk? That's pretty sweet on its own. Could that be ported to the CPC?


Well done on the rest, too. That's a really cool project.

GeoffB17

Yes, James, some very interesting things you're doing.


Just now, my PCW (still the same machine I got new back in 1983) is quite happy with JonB's uIDE drive.  OK, that provides 13 @ 8 Mb drives, and your setup would provide lots more, but the present setup provides WAY MORE than enough for my needs.   Anyway, how efficiently could the PCW, and CP/M, cope with 16 Mb drives regarding directory entries, block sizes, dir searching, etc?   I'd wonder if the 8 Mb drives are already near the practical limit?


The AY chip sounds interesting, but I've seen dubious comments about that.   All relative of course!  I've got an old PC with a SB clone in, that has an AY chip.   I was asking elsewhere if it was worth trying to do much with the AY, given that I've got a Roland LAPC-I card in a different old PC.   I was told that the Roland is so much better than the AY that it wasn't worth the bother.  So, this leads on......


The Roland card uses an 8 bit ISA slot.   Is there any possibility that one might interface such a card to the PCW?   That would be interesting, just now, the PCW seems more durable than my old PCs!!   One thing that MIGHT be a trouble, the Roland interface uses &H330 etc ports, I'd guess these are 16 bit ports?   I think all the PCW ports (?) are 8 bit.   Although the ISA link is certainly 8 bit?  It connects to only part of the 16 bit ISA connector.   But this is all above my head!!


Best wishes for your projects.   Must keep any eye on your 'blog'.


Geoff

HAL6128


Quote from: Zoe Robinson on 13:16, 04 November 17
FID drivers? As in the SD card is being accessed like a giant floppy disk? That's pretty sweet on its own. Could that be ported to the CPC?
I think not. That's what JonB tried to develop together with his uIDE hardware. It seems that the CPC CP/M+ version (which is different and older from the PCWs ones) are not capable of working with FI-Drivers. Instead the CP/M itself (C11CPM3.EMS) should be compiled with a new drivers integrated.
...proudly supported Schnapps Demo, Pentomino and NQ-Music-Disc with GFX

jamesots

Quote from: GeoffB17 on 15:42, 04 November 17
Just now, my PCW (still the same machine I got new back in 1983) is quite happy with JonB's uIDE drive.  OK, that provides 13 @ 8 Mb drives, and your setup would provide lots more, but the present setup provides WAY MORE than enough for my needs.   Anyway, how efficiently could the PCW, and CP/M, cope with 16 Mb drives regarding directory entries, block sizes, dir searching, etc?   I'd wonder if the 8 Mb drives are already near the practical limit?


It seems to be ok with 16 Mb drives, although I can only fit 4 drives into memory rather than 13. I could probably get 8 drives if I increased the block size to 4096. I'm not sure I need that many drives though. Also, I only have 512 directory entries on my 'massive' drives, so I'll probably run out of directory space before I run out of disk space. It's all swings and roundabouts when trying to decide on all the drive parameters, and since I expect I can fit all PCW software ever written on one 2Gb SD card, it probably doesn't really matter which way I go :)


Quote from: GeoffB17 on 15:42, 04 November 17
The AY chip sounds interesting, but I've seen dubious comments about that.   All relative of course!  I've got an old PC with a SB clone in, that has an AY chip.   I was asking elsewhere if it was worth trying to do much with the AY, given that I've got a Roland LAPC-I card in a different old PC.   I was told that the Roland is so much better than the AY that it wasn't worth the bother.  So, this leads on......


I used an AY chip would be good as Head over Heels already supports it. I'm tempted to also add an SN76489 or two as well (the chip used on a BBC Micro) since I have a few of them. Just for the fun of it — and because I want to get my PCW to make the BBC start up sound :)




JonB

#5
Quote from: HAL 6128 on 21:36, 04 November 17
I think not. That's what JonB tried to develop together with his uIDE hardware. It seems that the CPC CP/M+ version (which is different and older from the PCWs ones) are not capable of working with FI-Drivers. Instead the CP/M itself (C11CPM3.EMS) should be compiled with a new drivers integrated.


If anyone would like to show me how this is done on the CPC, I would be very happy to integrate the uIDE drivers. As you know, I have the boards (and a list of people who want them).. :)

JonB

#6
Quote from: jamesots on 23:21, 03 November 17

So far I've added an AY sound chip and joystick port, composite video output, 512Kb of extra RAM, 32Kb of ROM and an SD Card. The SD Card uses its own FID drivers, rather than emulating a floppy drive like the HxC things. The PCW can boot from the ROM, which in turn loads CP/M off the SD card.


I wonder if you might help me to get the PCW booting directly off the uIDE? I'm going to take a look at your web page, see if there is enough info to work it out, but I expect I'll need your help with it, if that's ok.


[Update: I PM-ed you in too.. ]

JonB

#7
Quote from: jamesots on 22:50, 04 November 17

It seems to be ok with 16 Mb drives, although I can only fit 4 drives into memory rather than 13. I could probably get 8 drives if I increased the block size to 4096. I'm not sure I need that many drives though. Also, I only have 512 directory entries on my 'massive' drives, so I'll probably run out of directory space before I run out of disk space. It's all swings and roundabouts when trying to decide on all the drive parameters, and since I expect I can fit all PCW software ever written on one 2Gb SD card, it probably doesn't really matter which way I go :)

The problem with a single huge drive, apart from directory entries, is that you only have 16 CP/M user areas in which to organise your files, so you will soon end up with enormous DIR listings on all of them. I think that is one reason to stick with smaller partitions but have more of them. The other problem which you will come across is performance. I noted file and directory accesses were getting slower as I added more files. It becomes quite noticeable after a while.

The uIDE FID gives you 13 possible drives (c: - p: with m: still a RAMDISK) having 8MB and 512 directory entries each. I thought the practical limit on CP/M drive size was 8MB per, but I see you have done better. Nice one! The main constraint is memory (as ever) and the size of the ALVs that are needed to track the free / used space on each (logical) drive. The DPB for each drive looks like this:

         ; Block size = 4096 bytes
dpb:      dw 128  ;SPT - sectors per track
      db 5    ;BSH - block shift factor
      db 31   ;BLM - block mask
      db 1    ;EXM - Extent mask
      dw 2039 ;DSM - Storage size (blocks - 1)
      dw 511  ;DRM - Number of directory entries - 1
      db 240  ;AL0 - 1 bit set per directory block
      db 0    ;AL1 -            "
      dw 8000h;CKS - DIR check vector size 8000=CP/M 3 fixed disk
      dw 1    ;OFF - Reserved tracks (for warm booting)
      db 2   ;PSH - Phys sector shift (2 => 512 byte sectors)
      db 3   ;PSM - Phys sector mask (3 => 512 byte sectors)


As you can see, I reserved a track for a boot sector... ;)

The driver also has a map built into it. This is so that you can switch logical drives in / out at will, although the feature isn't implemented yet because I'm not sure how to access the map structure as held in the FID's memory and the PCW seems to cope fine as-is. I built the map for a CP/M 2.2 uIDE driver along with a set of tools to allow on the fly remapping and this was so that the user could choose how much memory (really, ALV buffer space) to give the driver, then switch drive partitions into / out of the CP/M logical drive letters that their choice allowed for. This included a second slave drive, giving a possible 32x8MB drives accessible, although not all at the same time. A similar approach might be a way forward for you, if you really want to have 2GB of online storage on your PCW.

Actually... on reviewing the uIDE driver's LBA code, I think it may be possible to extend the number of drives considerably, but that would mandate full implementation of the mapping scheme. With a big enough IDE device I think 1024 partitions of 8MB are possible by modifying the current uIDE driver, and you can double that with a slave drive fitted.

Regards
JonB

jamesots

Quote from: JonB on 10:47, 05 November 17
The problem with a single huge drive, apart from directory entries, is that you only have 16 CP/M user areas in which to organise your files, so you will soon end up with enormous DIR listings on all of them. I think that is one reason to stick with smaller partitions but have more of them. The other problem which you will come across is performance. I noted file and directory accesses were getting slower as I added more files. It becomes quite noticeable after a while.


Do you have hashes turned on for your drives? I'm guessing you don't, as I don't think there'd be enough memory for 13 drives otherwise, given your settings. I don't either at them moment, as I can only load 2 drives when I turn directory hashes on, but I'm guessing they would improve performance. I'm tempted to drop down to 8 Mb drives just so I can turn hashing on and still have 4 drives though.

Quote from: JonB on 10:47, 05 November 17
The uIDE FID gives you 13 possible drives (c: - p: with m: still a RAMDISK) having 8MB and 512 directory entries each. I thought the practical limit on CP/M drive size was 8MB per, but I see you have done better. Nice one!


I think 8Mb was the max drive size in CP/M 2.2, but CP/M 3 says it can support 512Mb drives with 32Mb files in theory. Which is tempting to try, just to see if it can be done, even though it wouldn't make much sense.


[/size]
Quote from: JonB on 10:47, 05 November 17
As you can see, I reserved a track for a boot sector... ;)
[/font]


I also have a track reserved for the boot sector — it's where my boot ROM loads the modified J15CPM3.EMT file from. All the other partitions also have the boot sector because I didn't want to mess around with multiple disk formats.

[/size]
Quote from: JonB on 10:47, 05 November 17
The driver also has a map built into it. This is so that you can switch logical drives in / out at will, although the feature isn't implemented yet because I'm not sure how to access the map structure as held in the FID's memory and the PCW seems to cope fine as-is.


I got my mapping working last night. One of the key changes I had to make was allocating space for a checksum vector, otherwise CP/M doesn't believe you've changed disks even if you call svc_d_changed.


To communicate between the FID and a programme running in the TPA isn't difficult — I just copy stuff into common memory (c000-ffff) and then follow John Elliott's instructions for talking to a FID (http://www.seasip.info/Cpm/amsfid.html). I initially tried using the XMOVE and MOVE bios functions but they didn't seem to be working as I was expecting them to.


I've just made a public github repository at https://github.com/jamesots/pcwplus — it only has the bootstrapping and FID loading code in it at the moment (stuff I compile on my PC), not any of the ROM and SD Card code (which I compile on the PCW).


Prodatron

Quote from: jamesots on 23:21, 03 November 17So far I've added an AY sound chip and joystick port, composite video output, 512Kb of extra RAM, 32Kb of ROM and an SD Card.
Sounds really cool! I need that for the SymAmp player (AY sound), controlling my mouse pointer (Joystick), and FAT 16/32 access...
Is it possible to access the 512byte sectors of the SD card directly (low level sector read/write)?

GRAPHICAL Z80 MULTITASKING OPERATING SYSTEM

jamesots

Quote from: Prodatron on 01:38, 06 November 17
Sounds really cool! I need that for the SymAmp player (AY sound), controlling my mouse pointer (Joystick), and FAT 16/32 access...
Is it possible to access the 512byte sectors of the SD card directly (low level sector read/write)?


Yes, it just uses two IO ports, one which controls the SD card's select signal and whether or not communication should run at 16Mhz or 125Khz (needed during initialization), and one which writes/reads bytes to/from the SD card in SPI mode. So you can send any instructions you like to the SD card. I've got a small library of Z80 code to do this, which is gradually gaining more features at the moment.


JonB

Hi James


Hope you saw my PM. Would you be prepared to share details of your design with me? I would like to get my uIDE cards to boot without accessing the floppy drive, but I think I will need a bit of help..



Cheers
JonB

jamesots

Quote from: JonB on 15:29, 06 November 17
Hope you saw my PM. Would you be prepared to share details of your design with me? I would like to get my uIDE cards to boot without accessing the floppy drive, but I think I will need a bit of help..


Yes, I'm happy to help. Did you see my post further up the thread? Would anything else be useful at the moment?


James Ots

JonB

#13
I probably need:


       
  • Schematics of your interface (so I can recreate it with uIDE compatibility).
  • Details of the mechanism by which it detects the end of the first level boot - port addresses, ROM disassembly, etc.
  • Source code of the second level boot (the code you put in the SD card's boot track).
  • CPLD programming details (I assume you're using some programmable logic).
  • Your patched EMS file.
  • Probably some advice on build tool chains you are using (I use TASM for Z80 assembly) especially for the programmable logic.
Basically, everything required to boot the PCW from a mass storage device.. I would substitute your SD card boot code for IDE code (same thing functionally - read boot code off the first track).

jamesots

Quote from: JonB on 13:09, 07 November 17
I probably need:


       
  • Schematics of your interface (so I can recreate it with uIDE compatibility).
  • Details of the mechanism by which it detects the end of the first level boot - port addresses, ROM disassembly, etc.
  • Source code of the second level boot (the code you put in the SD card's boot track).
  • CPLD programming details (I assume you're using some programmable logic).
  • Your patched EMS file.
  • Probably some advice on build tool chains you are using (I use TASM for Z80 assembly) especially for the programmable logic.
Basically, everything required to boot the PCW from a mass storage device.. I would substitute your SD card boot code for IDE code (same thing functionally - read boot code off the first track).


Some of that is in the github repository, although not the interface schematics and CPLD code. I don't think a CPLD is really necessary for doing the boot from ROM stuff — it really comes into its own for the SD card interface — and it's also fairly expensive, although without the SD card code you could fit it into a smaller, cheaper chip, I guess. I don't have the schematic documented at the moment, I'll have to sketch that out in KiCAD, and I need to get a public repo up of the CPLD code.

JonB

#15
Maybe you could walk me through how we might do this without a CPLD in principle. I'm all for something cheap and simple!


Cheers
JonB

jamesots

At the moment I'm trying to rebuild my circuit on stripboard, as something is slightly dodgy with my breadboard since I knocked it and at least one of the wires somewhere is slightly loose. Hopefully once it's on stripboard and working reliably I'll be able to tell whether my improved VHDL boot code works properly or not. If it does work, the circuit will be a lot simpler to build without a CPLD.

JonB

OK, James I'm keeping my fingers crossed...


A CPLD isn't necessarily a no-go for me though, it just depends on how much discrete logic is needed to implement the boot.

jamesots

Just letting you know I haven't forgotten about this — I'm still working on the stripboard circuit. Nearly got it all soldered.


Re CPLDs — I reckon without the SD code it would fit into one of the small, cheap CPLDs, so it might still be the best way to go. You would need a 3.3v regulator though if you were using the XC9500XL CPLDs like I'm using, which I think is a good choice as they accept 5V inputs. One downside is the outputs are 3.3V, but that is still TTL compatible, and the PCW is happy with those levels. Also, the CPLDs are surface mount.


JonB

#19
Thanks James

It's a matter of documentation - I can understand it as long as it is explained. Being able to boot from something other than the floppy disk is a bit of a holy grail for PCW owners, so I think your success is a great achievement. Documenting it will hopefully lead to renewed interest in the machine and more bootable devices appearing.

I am happy to document your design if you would rather not go to the effort, but of course I will need to build one first (and get the understanding).

Would this CPLD suffice? https://www.ebay.co.uk/itm/271333636888


Cheers
JonB

jamesots

Yes, that CPLD should do the job. I'm working on documenting what I've done — I'll PM you a link to the draft.

pollito

@jamesots did you get any further with this? It would be great to be able to add SD, sound chip and joystick support to my PCWs. I checked your Github repo and Hackaday project but I can't find any schematics there.

Kman

May I point you to this URL: https://joyceforum.de/viewtopic.php?f=11&t=92

I've done some work around my PCW to get it using mass storage (CF-Card), sound, an RTC etc. It's a compilation of the work of others (from this forum) and my own. May be it helps you further. You will need Google Translate, because it's all in german.


pollito

Quote from: Kman on 04:37, 19 December 23May I point you to this URL: https://joyceforum.de/viewtopic.php?f=11&t=92

I've done some work around my PCW to get it using mass storage (CF-Card), sound, an RTC etc. It's a compilation of the work of others (from this forum) and my own. May be it helps you further. You will need Google Translate, because it's all in german.


Many thanks, I will check this out. :) 

coolchilli

Hey @Kman - would you (or someone else on this forum) be willing to make one of these for sale?

I'm nursing a PCW with a very sick disk drive, and would greatly value the ability to use solid state storage as well as curious about other capabilities that could be added to the machine (especially a wifi modem)...

... looking on eBay it seems there are many PCWs for sale that have also lost the ability to boot from disk, and I think a bootable SD/ CF/ DOM solution would be very well received (albeit to a niche audience)!

Powered by SMFPacks Menu Editor Mod