Universal Serial Interface for Amstrad CPC (a.k.a USIfAC)

[Etegar]

Hi Ikonsgr,


Very interesting project. I would like to order 1 board if it's available with the edge connector adapter.

Thanks

[Dandare]

Nice project,

I'm curious: at 32Mhz, a pic16 runs one instruction each 125ns.
Given that you need to identify the port, whether it's read or write, and either capture the bus or put the right response back in the bus (and take it out before the next instruction), I would say the timing is almost impossible to get right, considering you have less than 1us (8 pic asm instructions) to do it all.


Congratulations on the achievement. I can't imagine how you do it unless you are inserting wait states like there's no tomorrow 
(Does that pause switch gives a hint about this?)

[ikonsgr]

Nice project,
I'm curious: at 32Mhz, a pic16 runs one instruction each 125ns.
Given that you need to identify the port, whether it's read or write, and either capture the bus or put the right response back in the bus (and take it out before the next instruction), I would say the timing is almost impossible to get right, considering you have less than 1us (8 pic asm instructions) to do it all.
Congratulations on the achievement. I can't imagine how you do it unless you are inserting wait states like there's no tomorrow 
(Does that pause switch gives a hint about this?)

You are right, there is NO way all these to be done in less than 1uS, unless you have a PIC running at 200Mhz...  
So, of course amstrad need to be paused when circuit is activated (you just force "READY" signal to low and Amstrad can freeze.... for ever!),although the hole code execution for each sent/received byte is done in a few microseconds!
Now, apart from the need of instant activation of the curcuit and pausing of amstrad (which in the end ,was done using a logic gate chip, it was really impossible to do it using the pic and software routine, as they were too slow even @32Mhz),the most difficult part, was the correct reading of a  byte from serial port! The precise latch/unlatch of PIC's data port to amstrad's data bus, seemed to be impossible to achieve!
At some stage of development,i was so frustrated of not being able to sync everything right, that i thought the only way to do it, was using an extra octal 3state buffer chip (which is as big as the PIC itself   ), between cpc's 8bit data bus and pic's data port, and enable it by IORQ signal (so the buffer would "automatically" make the correct "latch/unlatch" of pic's port to cpc's data port).
But then suddenly...an idea "hits me": studying in detail how Z80's is reading a byte from a port and combining this knowledge with the way Amstrad allows access of I/O buses to Z80, i managed to resolve this, by using only a small rudimentary "sample & hold" circuit (just a small diode and a capacitor) of the READY signal that fed a pic's input pin! You see,i discover that in the proccess of reading a byte from a port, i can ensure that the byte was "downloaded" correctly to accumulator when the 1st high pulse of ready signal occured AFTER unpausing amstrad. So what i did, was, unpause amstrad for 0.25uS (e.g. 1cycle @4mhz, exactly the clock of Z80 ) and then repause it again. If in this time, the "sample & hold" pin was High, it means that byte was taken, and i could proceed to unlatching Pic's data port from amstrad's data bus and unpause amstrad completely! If not, then i issue again a 0.25uS cycle of "unpause/pause"  and do the same check! That way, i managed to "bit bang"  pic's port at exactly the correct time and with the minimum ovehead ,the hole check of "sample & hold" code, each time amstrad is paused, executes in only 0.5us!

I began to deal with this project since summer of 2017, and have spent literally many 100's of hours on this! In the process, i got involved with assembly programming (i even developed a code for fast read/write files byte by byte using firmware, because of this project!), DELPHI programming on the PC, PIC programming, basic programming on CPC, learn to configure and use bluetooth modules, wifi modules, usb to serial interfaces,and ofcourse  design the schematics and the pcb board for the circuit...

To get an idea, i began with this:
https://www.dropbox.com/s/g1zvz97hb67oql6/DSCN0752.JPG?dl=0
Which is evolved to this :
https://www.dropbox.com/s/dv9fo1zi7k6cpij/PROTOTYPE2.JPG?dl=0\
And finally end up to the pcb board shown in the 1st post...


Surely, it was a lot of trouble but, i did it  *mostly* as a hobby, a fun of making something creative,  and in the end,  sharing any knowledge and achievement with the community!


Long live Amstrad CPC!  

[Dandare]

Very nice,
just a hint for future projects you may get yourself involved with: (Maybe you already know about it)
PICs with a Parallel Slave Port will save you a lot of trouble and will let you interface with the CPC without wait states.


Downside is you'll have to go to a 40pin package at least to get that peripheral.

[ikonsgr]

That's really very nice feature! Sadly, microchip doesn't provide this feature to the parametric search list ,so it's difficult to find what models have this feature.
Anyway, if the "smallest" pic with such feature is with 40pins, i'm afraid it's way too large, bulky and with "overkill" pincount  (and probably much more expensive at least newer models with internal 32Mhz clock) for this project.
My first priority when i was looking for a suitable PIC, was to be able to operate at least @32Mhz (with internal osc), have 1Kb RAM, Hardware Uart, and have the minimum pin count for my needs (20 or 28 at most). Besides 16F1579, there is another  "pin compatible" and with similar features PIC ,16F1459 which operates at 48Mhz. I haven't tested yet, but i believe it can work directly (just with a different Hex file ofcourse) on the same board, and so you can have a "Turbo" version of the serial interface ,+50% faster!

[ikonsgr]

I just add a new "half price" purchase option (pcb board+PIC flashed with program).
With this, anyone can easily build the board by himslef, needing only a soldering iron!  

[LambdaMikel]

Hi John,
I'd like to order 2 - assembled, if possible  Please send me PM for payment instructions.
CheersMichael

[krusty_benediction]

Nice project@Duke: do you think it can be used in association with the M4 in order to debug a CPC runing application from the PC ?. The M4 read memory from the CPC and send it to the PC through this interface

[Duke]

Nice project@Duke: do you think it can be used in association with the M4 in order to debug a CPC runing application from the PC ?. The M4 read memory from the CPC and send it to the PC through this interface

Actually the M4 board already has a serial port exposed, its labelled (TX,RX,GND) on the top header, I can enable access to it, if anyone wants to use it.
 Could it or @ikonsgr serial port be used as link for debugging,  probably yes

@ikonsgr , nice project!

[remax]

Actually the M4 board already has a serial port exposed, its labelled (TX,RX,GND) on the top header, I can enable access to it, if anyone wants to use it.
 Could it or @ikonsgr serial port be used as link for debugging,  probably yes

@ikonsgr , nice project!

On which one would it be the easiest to have an RS232 port ? I'd love to test one of the wifi modems available (Retro Wifi SI or Wifi232)

(or perhaps one or both make those wifi modems not necessary ?)

[ikonsgr]

On which one would it be the easiest to have an RS232 port ? I'd love to test one of the wifi modems available (Retro Wifi SI or Wifi232)
(or perhaps one or both make those wifi modems not necessary ?)

Well, as far as my serial interface is concerned, legacy devices that require "full feature" RS232 port with all extra signals like DTR, DSR, RTS etc are not supported.
But as you already said, you don't actually need any kind of these modems anymore,since you can connect directly to internet using the Wifi module, either with M4 board or serial interface!

[GUNHED]

Actually the M4 board already has a serial port exposed, its labelled (TX,RX,GND) on the top header, I can enable access to it, if anyone wants to use it.

Yes, please, so we can connect. 

[VincentGR]

What gunhed said 

[Audronic]

@ikonsgr



Please see a PM from me


thanks Ray

[Etegar]

Hi,


Thanks John, board received and tested this weekend with my usb2serial cable.  All your aplications are working fine  !!!!
I,m surprised especially with the transfer speed time (set at 115200 for default). It takes really few seconds in transferring a file from PC to CPC (directly to the 3” Disk). I supose that wifi conected modules will do the same quickly job as the usb2serial cable.
When the dsk transfer utility will be finished this really will save time and inconveniences with another  hardware solutions.
You have done a great job and this board. Please go on with this project.


Eduard

[ikonsgr]

Thanks Eduard, and if you set speed, up to 576000 using a usb2 serial cable, it's even faster! 
I will surely add dsk image transfer support in the future, but currently i'm  working on,IMO, an even more interesting project:
 direct load and run of programs from PC, with blazing fast speeds of ~twice the actual disk loading speed! (for example, load and run of a single 42kb binary game takes  ~4seconds!!!)
I use a similar procedure with the "Cold start" function, you only need to type a small basic program (to enable the transfer of the assembly routine from PC to Amstrad), and then using redirections of firmware's loading routines (e.g. some pokes), you can use the very same BASIC  commands, RUN"" and LOAD"", to directly load and execute programs from PC! 

I've already manage to use it for load and execute of BASIC programs and single Binary files, and now i'm working the direct execution of games with multiple files (which proved much more difficult thing to do...) . I believe i'll have it ready soon for anyone to use it. And it would be very interesting to see if it will work on a CPC 464 too, thus, providing a cheap,easy and super fast solution of loading games and programs on the "Cassette only" 464!
It would be the revenge of the CPC 464, loading games, twice as fast as a CPC 6128 with disks! 

[HAL 6128]

... you only need to type a small basic program (to enable the transfer of the assembly routine from PC to Amstrad), and then using redirections of firmware's loading routines (e.g. some pokes), you can use the very same BASIC  commands, RUN"" and LOAD"", to directly load and execute programs from PC...

...how about creating a ROM which brings the CPC after booting in some kind of "listening" mode? Maybe also interesting for cross-compiling?

[ikonsgr]

Well, that would require to replace the hole Amsdos ROM with a custom one (like duke have done), which probably is something very hard and time consuming thing to do.
Also, in order to use a ROM for amstrad to read from it, the circuit  must implement full 16bit address decoding and most probable "on the fly" reading! That would require a much bigger PIC (possibly with 40pins) and far more complicated circuit... 

[GUNHED]

What do you mean with 16 Bit address? Doesn't it decode the 16 bit I/O completely? If yes, which are the shaddow ports?

[GUNHED]

...for example, load and run of a single 42 kb binary game takes  ~4 seconds!!!

Using FutureOS it takes about 2,7 seconds    But I'm sure the serial interface can do even better! 

[LambdaMikel]

Damn! Can't wait to get my serial board.... 

[ikonsgr]

What do you mean with 16 Bit address? Doesn't it decode the 16 bit I/O completely? If yes, which are the shaddow ports?

Nope, just 2 address bit needed A5 and A10 (and the A0 which used for having data & control port). Of course the address bit selection was not random,but it's based on Amstrad's I/O port allocation:
http://www.cpctech.org.uk/docs/iopord.html
If you take a look there, you will see that, A10=0 defines I/O peripherals, and A5=0 a serial port. These 2 address bits, are combined with M1 and I/O request signals (when IORQ=0 and M1=1 means exclusively Input/Output request) to enable interface exclusively on ports &FBD0-FBDF! ;-)  And that way, i was able to implement address decoding using a small and cheap logic gate chip! 

[GUNHED]

Then ports &FBDE and &FBDF should be used (instead of &FBD0/1) 

[ikonsgr]

I suppose so, but this is true for any device. The CPC IN/OUT design uses 16 bits address instead of the "traditional" 8 bits. These I/O addresses,according to port allocation document,  are not fully decoded, thus a hardware device can be accessed through, with more than one address! 

[GUNHED]

Exactly!    Therefore the more bits we set to "1", the less interference we have. Actually some other expansions I have to check, if the I/O port can in a more "compatible" way can be addressed. Because nowadays lots of users have lot's of stuff on their CPCs / Plus. 


But back to the USIfAC (Universal Serial Interface for Amstrad CPC): I'm looking forward to work with it. In two weeks I start to have more time for computers again and the handling of the USIfAC can't be more easy.