xboo cable

[nocash]

Hi, I am just updating my PC-to-CPC transfer tool. An old project from early 90ties (I think I've never released it back then). The old version reached around 10kbytes/second transfer speed. The new one should be about twice as fast.

The thing uses a connection from PC parallel port to CPC printer port. And requires some minor modifications inside of the CPC:
- a 74LS541 chip with /OE1,/OE2 = A12,/IORD to make strobe and 7bit data bi-directional
- a wire from printer init signal to the busreset line, to allow to autostart uploaded files
- a EPROM with patched AMSDOS that redirects sector I/O to the cable
For the actual connection, you can use a standard printer cable, which fits directly to the 36pin printer port on the german 6128. For other CPCs with 34pin, or CPC+ with 25pin ports one would need to make a small adapter.

Well, at the moment I am just announcing that I am working on it. Would be nice to know if somebody is interested in that project. Please mind that it's a soldering thing, so if you can't/don't want to do soldering: Best assume that you are not interested.

I'll upload source code for the amsdos patch later. In short, the low-level transfer works like so:
  init is reset from PC
  strobe is clock from PC
  data is 7bit data to/from PC
  busy is request to PC
It's still work-in-progress. So if you have some suggestions how to improve or simplify the project, please say something.

Oh, and one important question: Does somebody know for sure if the CPC+ can/cannot output data on the busy line? The normal PPI can do that. I think that there's been some speculation the ASIC might be unable to change port b data direction - but, does somebody every verified that?

Cu, Martin

PS. patched sector I/O means that it is accessed like a floppy, ie. you can type things like
  RUN"filename,
  SAVE"filename,
  |ERA,"*.bak
and so on, to access dsk-images on the PCs harddisk. You can also use whatever amsdos compatible file-copy software to copy files to/from the PCs harddisk to/from the real CPCs disc drive.

[Gryzor]

Hm, that's interesting... soldering shouldn't be that hard, but custom-blown EPROMs are harder to do...

[WinterMute]

Wasn't the CPC parallel port handled by the AY-3-8910? It's been a long, long time since I touched a CPC464 though - back in the 80s when I wrote Beach Head & Raid Over Moscow amongst other things.

You make me want to go see if I can pick one up now though :p

[redbox]

I would definitely be interested in this, and it seems a nice way of continuing on in electronics from building my first PC->CPC Parallel Cable.  I have a 6128+ so wouldn't mind doing the Plus testing for this project.

What platform are you writing the PC software for?  Low level stuff in Windows is difficult (directly accessing the parallel port for example), but of course this is the platform with the widest reach.  I wouldn't mind using Linux though because if a project like this was a success then I would have a low end Pentium or something as a dedicated server for the CPC.

I thought blowing EPROMs was relatively simple?  Can't you just connect a little adapter to PC parallel port and do it that way?

[nocash]

> What platform are you writing the PC software for?
I'll include the upload function in no$cpc debugger, so there'll be a windows version. And, maybe, DOS version (that version is using 16bit code, and after adding some features here and there, I am afraid that some code segments no longer fit into 64kbytes).

> Low level stuff in Windows is difficult
No problem there. Under win9x one can directly access the parallel I/O ports. Under winxp it's more difficult, especially if one doesn't have winxp (like myself). Fortunately, Sergey Anoufrienko (russian super programmer) has written a driver for no$xx, it unlocks the I/O ports, and then they can be accessed as usually. It's all working automatically - the proggy will prompt you if you want to install the driver, and thereafter you won't ever have to think about it.

> I thought blowing EPROMs was relatively simple?
Yup, EPROMs are quite simple, and FLASH chips are very simple.

You won't get around gathering some hardware: The most expensive solution is to buy an EPROM programmer. The cheapest, but most uncomfortable solution is too use an old mainboard (200MHz era or so, with BIOS in DIP sockets): Boot it, replace the BIOS by your FLASH chip while powered-on, and then write your software to it.

> Can't you just connect a little adapter to PC parallel port
That's the best (or maybe worst) solution. My own selfmade parallel port eprom burner consists of seven 74xxx chips (mainly for latching the address, data, control bits), components with plugs and sockets should be less than 5 dollars. Only problem is wiring the chips by hand can easily take some days :-)

[nocash]

> I would definitely be interested in this... I have a 6128+
> so wouldn't mind doing the Plus testing for this project.
Would be great!

Can you test if the printer BUSY signal can be reconfigured as output? For example,

  ld bc,0f780h
  out (c),c       ;set direction to output
  ld b,0f5h
  ld a,0ffh
lop:
  out (c),a       ;output busy bit
  xor a,40h
  jr lop

Pinouts are here, http://cpcwiki.eu/index.php/Connector:Printer_port, BUSY is Pin11 on either CPC and CPC+.

If the test program works okay then Pin11 should output a square wave. Which could be seen with an oscilloscope, or, if you have only a multimeter: you should see around 2.5V DC on that pin.

If it doesn't work, then you'd probably get a permanent 5V high level.

[redbox]

Fortunately, Sergey Anoufrienko (russian super programmer) has written a driver for no$xx, it unlocks the I/O ports, and then they can be accessed as usually. It's all working automatically - the proggy will prompt you if you want to install the driver, and thereafter you won't ever have to think about it.

This sounds great.  I have seen some DLL libraries (such as this one and this one) for accessing the parallel port in XP and later whilst I was researching the idea of writing a Windows version of Turbo Transfer.  But if you have one already written then that's even better.

The cheapest, but most uncomfortable solution is too use an old mainboard (200MHz era or so, with BIOS in DIP sockets): Boot it, replace the BIOS by your FLASH chip while powered-on, and then write your software to it.

What a fantastic idea.  I have exactly that - an old P200 mainboard, so will have to dig it out and see if it's suitable.  I guess you just use the mainboard's flash update utility and replace the update with the image you want to write?

Can you test if the printer BUSY signal can be reconfigured as output? For example,

I have a multimeter so will try this on my 6128+ when I get home tomorrow and let you know.

[arnoldemu]

Wasn't the CPC parallel port handled by the AY-3-8910? It's been a long, long time since I touched a CPC464 though - back in the 80s when I wrote Beach Head & Raid Over Moscow amongst other things.

You make me want to go see if I can pick one up now though :p

Sorry no. the Ay handled the keyboard.
The parallel port uses a 74ls latch chip.

[arnoldemu]

Oh, and one important question: Does somebody know for sure if the CPC+ can/cannot output data on the busy line? The normal PPI can do that. I think that there's been some speculation the ASIC might be unable to change port b data direction - but, does somebody every verified that?

I did test this and I don't think the ASIC "PPI" can change it, but then I didn't actually test the signal on the parallel port, I just tested it through programming.

[redbox]

If the test program works okay then Pin11 should output a square wave. Which could be seen with an oscilloscope, or, if you have only a multimeter: you should see around 2.5V DC on that pin.

If it doesn't work, then you'd probably get a permanent 5V high level.

I had to change the hex syntax in the program to assemble properly in WinAPE/Maxam (hope I got it right):

Code Select Expand


        org &8000

        ld bc,&f780
        out (c),c    ;set direction to output
        ld b,&f5
        ld a,&ff

lop:    out (c),a    ;output busy bit
        xor a,&40
        jr lop


Appears it did not work - I got a constant 5v whether I was running the program or not on my 6128+.

Would it be possible as a start to patch AMSDOS to work with the current Parallel Cable (because I've already made one of these  )...?

[nocash]

Got the overall send/receive byte procs back working with the new version. Sending /STROBE from PC to CPC didn't work. On my old PC it worked fine, but my current PC seems to have a weaker /STROBE signal, and it can't pull-down the /STROBE from the CPC (which is set high by software).
Okay... so I've replaced it by /AUTOLF. Now the schematic looks like so:

Code Select Expand


                  ____________
                 |   74LS541  |
  /IORD ---------|/OE1   D0..6|----- DATA0..6
  A12   ---------|/OE2      D7|----- /AUTOLF (instead of /STROBE)
  D0..7 ---------|Q0..7       |
                 |____________|
  /BUS RESET ----------------------- /INIT


Meaning that one would need to disconnect the /AUTOLF pin from the mainboard (in CPC it's wired to GND, in CPC+ to 5V). According to Kevin's printer cable doc the GNDing didn't worked well anyways; the doc recommended to leave that pin unconnected. So, disconnecting it should still stay compatible with normal printers, hope so!

[nocash]

> [busy-output] Appears it did not work - I got a constant 5v

Too bad. On normal CPC it's working great. And on CPC+...


One could latch BUSY externally with a 74LS74 chip, but the port decoding (A11=0, A9=1, A8=0, /IOWR=0) would be a bit complicated.


Another idea would be to use the strobe output (that from the CPC, not from the PC), and wire it to /ACK. So the CPC could send data requests via STROBE, and the PC would see them as ACK.


That should work fine for the transfer. But when connecting a real printer to the CPC, the printer may not work (if it outputs something on ACK, and drags the CPCs strobe to whatever state... :-/


Any better ideas?


> work with the current Parallel Cable


I think that's really too slow to be of any use.

[redbox]

> [busy-output] Appears it did not work - I got a constant 5v
Too bad. On normal CPC it's working great. And on CPC+...

Tell me about it, I was really looking forward to this project.

Oh, and one important question: Does somebody know for sure if the CPC+ can/cannot output data on the busy line? The normal PPI can do that. I think that there's been some speculation the ASIC might be unable to change port b data direction - but, does somebody every verified that?

Do you have a link to this - I take it from your comments that it's been discussed somewhere before?  I'd like to read about it after my discovery today...

[nocash]

The info (or speculation) on the emulated PPI in the CPC+ is here: http://www.cpctech.org.uk/docs/cpcplus.html since you didn't get BUSY pulsed, it seems to be correct about port B and C being fixed-directional on the CPC+.

Meanwhile, the sector loading is working again (though only with system discs yet, will be still some work to support data format, and error handling, etc.) Anyways CAT and LOAD and RUN are working. Loading a 16K file takes 1-2 seconds :-( maybe some reasons of the slow transfer can be blamed on AMSDOS, which relocates the sectors after loading.

Plus, booting the CPC takes 1-2 seconds, too. Damn, Amstrad. Couldn't they see that a Z80 is WAYS too slow to zerofill 42 kilobytes of RAM? Booting & transfer makes the "instant-autoboot" idea more a "please-be-patient-boot". Anyways, it should be still faster than loading from real disk drives.

For the request signal from CPC to PC, I'll probably drop BUSY, and use the strobe bit wired to ACK (or maybe better SLCT or so?). If you add a logic gate between STROBE and ACK, it'll become one-way, so ACK from printer can't creep to STROBE. On the CPC+ that requires less components than trying to latch BUSY externally. Though it's a pity to need to use that workaround as the original CPCs would work without that trick.

[Bryce]

Hi Nocash,
         sounds like an interesting project, especially if it would work with USB/Parallel adapters (my PC doesn't have a parallel port anymore). I'm not too sure about all the hardware changes that need to be made inside the CPC though. A lot of CPC users would be reluctant to mess about inside their hardware, no? Have you considered using the Joystick inputs for PC->CPC data and the printer port for CPC->PC data? Obviously the cable is more complicated, but it would negate the need for internal modifications. Another option might be to access the CPC directly through the expansion port, it's bi-directional and could be accessed faster if the PC was simply mapped to an address.

Just my thoughts on the hardware side, what do you think?

Bryce.

[arnoldemu]

Hi Nocash,
         sounds like an interesting project, especially if it would work with USB/Parallel adapters (my PC doesn't have a parallel port anymore). I'm not too sure about all the hardware changes that need to be made inside the CPC though. A lot of CPC users would be reluctant to mess about inside their hardware, no? Have you considered using the Joystick inputs for PC->CPC data and the printer port for CPC->PC data? Obviously the cable is more complicated, but it would negate the need for internal modifications. Another option might be to access the CPC directly through the expansion port, it's bi-directional and could be accessed faster if the PC was simply mapped to an address.

Just my thoughts on the hardware side, what do you think?

Bryce.

I too was thinking the joystick port may be a good solution on the cpc+ too.

But then I thought, it would be great to have a real USB like cable for the CPC, but then the software would be more difficult.
The reason for USB anyway is that I have not always been successful using the parallel cable with a PC, and Bryce's point is valid for these new pcs.

What about a PIC  connected to the expansion port, it could decode the I/O address and act like a buffer??
I too am thinking about low cost solutions..

I like it that the amsdos functions are redirected and you can download direct into the cpc, because it would make it a really good way to test cpc software.

Well I think a lot of the project could be adapted too for other cables...
I think this is a good project. Please continue.

[Bryce]

The software isn't all that difficult, I had intended putting together a "real" USB connection to the CPC, but I have very little time at the moment, so I never got around to it. I'm not much of a PC programmer, I can do it, but it wouldn't be pretty but I'd be willing to do the hardware, if someone else writes the software for both ends.

Bryce.

Nocash; Why's it called an XBoo cable? Sounds like something for an XBox.

[nocash]

Hi Bryce

> if it would work with USB/Parallel adapters
Probably not. I would assume that those adapater work only for printers, not for general-purpose things where one would control the strobe/busy/ack signals directly via I/O ports... Theoretically, protected mode drivers *could* trap accesses to parallel I/O ports, and *could* forward them via USB... but I would doubt that existing drivers do support such thungs.

> my PC doesn't have a parallel port anymore
Horror! :-)

> lot of CPC users would be reluctant to mess about inside their hardware, no?
Pretty sure. Myself, I'd prefer internal mods, it can't get lost once when it's in there.

> using the Joystick inputs for PC->CPC data
> and the printer port for CPC->PC data?
Joystick port only would be nice, too. But it lacks GND, and on the CPC+ most pins are input-only. Both joystick+printer port would be too many messy connectors... And for autoboot, one would even need a third connector for /BUS RESET on expansion port :-)

> access the CPC directly through the expansion port
Currently, I am aiming towards not using the PPI's busy. Instead, everything goes through port EFxxh. So, yeah, if preferred, it'd be relative easy to make an external expansion port adaptor. Unlike the internal variant, it'd also need to include the 74273 that latches the printer output.

Cu, Martin

[nocash]

Hi Kevin
> I have not always been successful using the parallel cable with a PC
Mine will be super-stable :-) as long as the PC does have a parallel port. Actually, it must be a bidirectional one, but I think one-directional ports haven't been manufactured since around 1992, so that should be no problem.

> What about a PIC  connected to the expansion port
It'd only need to handle reads/writes to port EFxxh, so an expansion port adaptor could be compatible with the internal mod. Making an external adaptor would require four or five 74xxx chips, so it may be easier to use a single PIC or PAL chip here. Though then you'd need tools for programming that chip, and if it should be a SMD chip you could forget about doing the wiring by hand. Altogether, I'd like it best to need only 1-2 standard 74xxx chips.

> I like it that the amsdos functions are redirected and
> you can download direct into the cpc, because it would
> make it a really good way to test cpc software.
Yup, I've used it for testing/rev-engineering.

> a lot of the project could be adapted too for other cables...
> would be great to have a real USB like cable for the CPC
Yeah... USB would be nice, too. I never got around to learn how the USB protocol works. I guess once when one is familar with it, it'll turn out to be pretty simple. Does somebody have some sample code for it? Something like how to send "Hello Test" to the PC.

As far as I know, USB can be programmed in software on PICs... though I've no idea if one does need a PIC... theoretically, it could be also programmed in software on the Z80 itself - or are there some minimum timing requirements, making the Z80 too slow to do that?

PS. No, xboo has nothing to do with xbox. There's no good reason for the name. It comes from a similar project for GBA, it was originally called boot.asm, then I made a modified version called xboo.asm, with the x being for extended or experimental, and then I somehow got stuck with that name... and also used it for NDS and PSX parallel port cables.

[Bryce]

USB hardware interfacing is a lot trickier than simple discrete i/o or RS232 interfacing, but it's worth the effort, there are several ways to interface to USB:

a) Use a purpose built USB controller/stack such as the FTDI / Vinculum range. These have everything you need ready to use and can communicate with your project through RS232 commands. Advantage is that you could probably even connect a Z80 to USB with it, dis-advantage they only come in SMD packages, so not very "hobbiest friendly" and they're not the cheapest solution.

b) Simulate the USB stack in a standard PIC/Atmel MCU. Has been done, but it's more bother than it's worth as far as I'm concerned. Simulating the USB interface in a Z80 would probably mean the Z80 would be too busy to do anything else while connected and may get bogged down if the data stream is too fast.

c) Use a PIC/Atmel MCU with built in USB connectivity. There are several available even in standard DIL packaging. Not sure about the Atmel parts, but the Microchip PICs have Drivers / Stack software and sample data online to aid development. And they're not too expensive, the 18F4550 used in the SDCard Floppy emulator has full USB support and cost around €4 - €5.

Bryce.

[nocash]

Found some source here, http://www.waitingforfriday.com/index.php/Building_a_PIC18F_USB_device - it's allowing to read a push-button, and to control a led. Sounds like a nice & simple example... But, the source code is 310K bytes in size. Imagine that, 310K for toggling a LED on and off! I think, I'll stay with the trusty centronics port. Unless... the 4-5 euro chip, is that easier to use?

---

Oh, and for the GX4000, basically, the cable should work on it, too. The RUN"FILENAME commandline is transferred via cable, so it can load the disk image without needing a keyboard, and of course without needing a FDC. But, once and when, I've heard that the GX4000 would be incompatible with the CPC+, is that true?

As far as I remember, somebody told me that inserting the CPC+ System Cartrige into the GX4000 would result in a "LINE DOES NOT EXIST" error message or so. What is causing that? Looking at the schematics, the only significant difference between CPC+ and GX4000 is that LK5 isn't connected. As far as known, LK5 should swap rom0 and rom7, so when it isn't connected, both BASIC and AMSDOS would be unstable. That would explain compatibility problems... On the other hand, looking at the photo of the GX4000 mainboard (see cpcwiki gallery), it seems as if LK5 is GNDed.

[nocash]

One more question: Does somebody know how AMSDOS clones are accessing double-sided disks?

All AMSDOS clones seem to support the standard read/write sector commands, RSX names chr(84h/85h), with AMSDOS style parameters C=sector, D=track, E=drive. The problem here is that AMSDOS doesn't define a parameter for the head number. Is there some kind of a standard how AMSDOS clones define the head?

It might be to assigned as E=head/unit (eg. with bit2=head, as it is internally handled by the FDC itself), or encoded in D=track/head, or it might be not implement at all in that RSX commands. And in worst case all AMSDOS clones may handle it differently :-)

At the moment I am only patching the normal, single-sided AMSDOS. Anyways, if there is a standard for double-sided BIOSes, it'd be great to know about it!

[Bryce]

The Chip used on the "Waiting for Friday" link you posted IS the 4-5€ PIC I mentioned, which is also used in the SD Card Floppy Emulator.

The 310K zip includes all the includes and libraries that are supplied by Microchip so you don't have to write these yourself, plus his LED code with comments. All of this is in uncompiled text form, so the actual program would be a lot shorter. His actual code for the LEDs is only a few lines long. Unfortunately, this is what scares people away from using USB from the very beginning. But as I mentioned earlier, yes, it's a heck of a lot more complicated than discrete i/o or RS232, but it also has some major (speed / compatibility) advantages.

Bryce.

[nocash]

> The Chip used on the "Waiting for Friday" link you posted IS the 4-5€ PIC
Igitt, that WAS the solution where the hardware does handle the USB transfer... and one still needs 310K source code? Yep, the main file is small, but if one needs all the other lib/include stuff, then... I don't like it.
My own experiences with USB are that one can be glad if it works. It took me some years to find a working generic driver for usb mass storage devices. So I wouldn't give it too many compatibility points.

The parallel transfer is working okay now. Read/write sector, with data/system format. Only, I still need to decide which signals to use instead of BUSY...

The "source" could be STROBE or /STROBE. The uninverted STROBE would be best to avoid conflicts with the PC pulling /STROBE high. Downside is that the CPC+ doesn't have STROBE, only /STROBE, so then one would need an extra inverter for it.

And the "destination"... PE, BUSY, /ACK, /ERROR, SLCT... maybe /ERROR would be best, with normal printer operation it should be always HIGH, so there's less risk that it could pulldown (/)STROBE. But, /ERROR is on the bottom-side of the mainboard... for soldering it'd be easier to connect everything to the upper pins... then SLCT would be better... I think it's defaulting to HIGH level, too. Except when the printer goes offline.

Uh, if I use STROBE and SLCT... then SLCT=LOW would pull-down STROBE only when the printer is offline, and in that situation STROBE should be LOW anyways, since one can't send data while the printer is offline. Does that sound like a good idea?

[Executioner]

It might be to assigned as E=head/unit (eg. with bit2=head, as it is internally handled by the FDC itself), or encoded in D=track/head, or it might be not implement at all in that RSX commands. And in worst case all AMSDOS clones may handle it differently :-)

Apart from Vortex, of which I have very little knowledge, AMSDOS "clones" such as ParaDOS, ROMDOS, S-DOS etc all use D = cylinder * 2 + head. ie. Track 0 is Cyl 0, Head 0, Track 1 is Cyl 0, Head 1, Track 2 is Cyl 1, Head 0 etc.