Author Topic: Universal Serial Interface for Amstrad CPC (a.k.a USIfAC) (Read 40534 times)

madlax39 · « **Reply #275 on:** 13:46, 02 February 21 »

I have finished the new card,
I keep the TTL serial connector of the USIfAC card, and add an subD9 RS232 connector, TX / RX/ Power indicators. the card can be used as a classic USIfAC (by removing the max232), or as an RS232.
The prototype is being manufactured by pcbway. (Around 3 weeks to come)
I'm waiting to be able to test it.
If anyone is interested I can give the Gerber file.

Gryzor · « **Reply #276 on:** 14:28, 02 February 21 »

Sooo what will v4 bring? A Multiface II built-in?

kolleykibber · « **Reply #277 on:** 16:38, 13 February 21 »

Hi Ikonsgr,

I wonder is it possible to use this as a z80dart emulator to use with existing comms software? Are the address lines fixed? If it just opened a socket, should get away with only the cpc facing part of the protocol.

Thanks for this project. I'm looking forward to receiving my card!

GUNHED · « **Reply #278 on:** 02:25, 14 February 21 »

You mean to emulate the Amstrad RS232 interface?
This would be a great idea, but it need a MAX232 to get from 5V to 12V IIUR.

ikonsgr · « **Reply #279 on:** 12:47, 14 February 21 »

Quote from: kolleykibber on 16:38, 13 February 21

Hi Ikonsgr,
I wonder is it possible to use this as a z80dart emulator to use with existing comms software? Are the address lines fixed? If it just opened a socket, should get away with only the cpc facing part of the protocol.
Thanks for this project. I'm looking forward to receiving my card!

I suppose you mean this. Well USIFAC is actually a simple UART serial interface an not an implementation of an old RS232 one, it responds to specific ports (&FBD0 I/O data port, &FBD1 control port-mainly to check if input buffer is empty or not) and uses only Rx and Tx lines. But perhaps the implementation made by madlax39 could be modified more easily to emulate this chip, although it would need some serious redesgin of circuit in order to add all the extra signals needed...

kolleykibber · « **Reply #280 on:** 16:37, 14 February 21 »

I wonder if a simple connection to the wifi serial mentioned would be easier to achieve, rather than physical rs232?

Excuse my layman logic, it's been a while since I've worked with hardware. It looks like only &FADC (data) and &FADD (control) would be needed. The data IN/OUTs seem similar to the USIFAC and the control registers could be greatly simplified, all the timing stuff ignored and present the old code with what it needs.

If say an old rom was hacked to use the usifac ports. Do you think it would be possible to program the usifac to respond as needed? Maybe it could be set to enter z80dart mode before launching software.
Thanks!

madlax39 · « **Reply #281 on:** 14:05, 20 February 21 »

The card that I modified with an integrated max232, allows to make the serial link RS232 (convertion 5v UART to 12v RS232).

BUT Currently, the USIfAC V1 card allows to change only the Baud rate...
To have a fully operational RS232 it would be necessary to be able to change the data bits, the parity, the stop bit...

But i dont know if it is possible for pic 16f1579 to change data bits, the parity, the stop bit...
[/size]

If the PIC can support this, maybe ikonsgr can add other instruction to modify this for example:
OUT & FBD0.X with
x:
40: partiy none,
41: parity even,
..
45: 1 bit stop,
46: 1.5 bit stop,
Etc ...

ikonsgr · « **Reply #282 on:** 22:26, 23 February 21 »

Unfortunately parity is not supported on hardware UART port of PIC 16F1579.
BUT, it might be possible to use software serial port, although this would limit speed @19200bps.
But on the other hand, this implementation of serial port would be completely configurable, and you will be able to change data bits, stop bits, parity, even invertion of byte is supported!
And all these could be configured, using a simple method of OUT commands like madlax39 proposed.
If the data rate limit is not an issue i might give it a try and give you the new code to test it! ;-)

ikonsgr · « **Reply #283 on:** 22:33, 23 February 21 »

Quote from: kolleykibber on 16:37, 14 February 21

I wonder if a simple connection to the wifi serial mentioned would be easier to achieve, rather than physical rs232?

Excuse my layman logic, it's been a while since I've worked with hardware. It looks like only &FADC (data) and &FADD (control) would be needed. The data IN/OUTs seem similar to the USIFAC and the control registers could be greatly simplified, all the timing stuff ignored and present the old code with what it needs.

If say an old rom was hacked to use the usifac ports. Do you think it would be possible to program the usifac to respond as needed? Maybe it could be set to enter z80dart mode before launching software.
Thanks!

Address decoding is partially done by checking only address bits A5=0, A10=0 (and M1, IORQ signals too, these 4 signals are combined in a seperate logic chip to determine whether the interface should be activated or not). So, since &fADC and &FADD are also have A5=0 & A10=0, i suppose you can also use these 2ports instead of &FBD0 &FBD1.
In 2 words, most probable responce to these ports should be achieved directly!

madlax39 · « **Reply #284 on:** 17:24, 24 February 21 »

For me a speed limit at 19200bps is good enough for the use that I have,
Don't forget that this card is connected to an amstrad CPC ^^

ikonsgr · « **Reply #285 on:** 22:56, 24 February 21 »

I'm afraid it can't be done using software serial port, because there is no way to receive a byte without constantly waiting for it...
You see, using hardware serial port, you can assign an interrupt event whenever a byte is received, so data reception is done completely indepentantly from normal code execution.
With software serial port you can't do that, and the only way to receive a byte from the port, is to wait until you get it, e.g. if i give a "receive byte" command from the port, code execution will hold until you get a byte...
So, it seems that it can't be done after all...

madlax39 · « **Reply #286 on:** 09:58, 28 February 21 »

It does not matter, USIfAC that you created already does a lot of things

.
From my side I received the components of my RS232 card.
Unfortunately a false manipulation and a FAKE max232 made I partly damaged my CPC

.
The image is all blurred and by adjusting VHOLD behind the screen I get a partial image.
I think it's CRTC sync
So I'm waiting for new parts ...

ikonsgr · « **Reply #287 on:** 13:55, 02 March 21 »

Very nice!

But,how on earth you damage your amstrad from a faulty MAX232 chip? Maybe this +/-12volts from rs232 went somewhere in the circuit that accepts only 5v?

And now i remembered some years ago, when i fried my amstrad cpc 6128, by accidentally giving 12volts instead of 5volts from an HDD molex connector, from an old AT PSU...
And it took me YEARS to restore it,by replacing EVERYTHING on board...
Only good thing is that know i have an Amstrad with a... "development" board, where ALL chips are socketed and thus,can be easily replaced!

madlax39 · « **Reply #288 on:** 10:16, 03 March 21 »

I connect the RS232 cable between my PC and my CPC already powered on both ...
The leakage currents from the PC accumulated and suddenly discharged into the CPC ...
the fake MAX232 did not isolate anything.
Putting all the chips that I would replace on sockets is an excellent idea, I will do that!

ikonsgr · « **Reply #289 on:** 11:31, 04 March 21 »

Yeap, that was something that you also need to take care using the cheap usb2serial adapter cables, you DONT need to connect the 5v pin to usifac's UART connector, only Tx,Rx and Gnd is needed!
Fortunately in that case, no harm was done, probably because supply was 5v and current was limited from the usb port itself.
One good solution to avoid such problems maybe would be to add a small signal diode like 1N4148 (or even 2 in parallel, if you need to supply more current to external device up to ~400mA) on 5v pin, in order to avoid leakage input currents from external devices, although i don't know if the ~0.5v voltage drop that diode would issue, can provide proper supply to external device, if needed. I've noticed that power supply measured at expansion port power pin is ~0.5v lower than of supply at Amstrad's 5V power connector, so if you add voltage drop from an inline diode, expansion port would give ~4volts instead of 5v. Of course if you don't need to power anything from the board this wouldn't be a problem...

evert · « **Reply #290 on:** 16:30, 11 March 21 »

Did you publish any source code (firmware for the PIC controller) of this project ?

I am curious to understand the handshaking method used + timing with the former version (PIC16F1579)
If these are not yet online or on Github, would you consider doing this still ?

I am also missing the schematic in the download section.
I didn't find it here :Amstrad CPC serial interface.zip (dropbox.com)

ikonsgr · « **Reply #291 on:** 12:14, 13 March 21 »

I'm planing to give all this, maybe at git hub, but for now you can check this: https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/usifac-iimake-your-pc-or-usb-stick-an-hdd-for-amstrad-access-dsk-and-many-more!/msg198918/#msg198918
These links contain many info about "Inner workings" of the board.
For programming PIC MCU i'm using cowbasic, it's a very good and powerful tool for programming 8bit PIC's! And there is also the ROM code for the board, which of course is written in Z80 assembly.
Now, for USIfAC II ,all address/signal decoding, is done using a feature of the specific PIC called CLCs, configurable logic cells. These are small programmable modules inside PIC MCU that can take up to 4 inpupts and give one output, using many different logic schemes like AND/OR/XOR/NAND gates, J-K, D flip flops , S-R latches. The 18F47Q10 provides up to 8 modules, so i'm using one module for each function i need (ROM READ, Serial I/O, FDC I/O,Upper ROM selection) by setting proper inputs (e.g. address bits/signals) and logic, and with all outputs going in a "Master" CLC ,which controls the activation of the interface. This optimizes performance and responce speed, as PIC code, only needs to check one pin (the output of master CLC which at the same time, activates READY signal and pauses Amstrad) in a very tight loop, that is executed ~5-6times/usec!

btw,i've added the schematics of the board into zip file

issalig · « **Reply #292 on:** 20:29, 15 March 21 »

Thanks for the info about CLCs, I read sth about CLC on a comment from Dandare but never played with CLCs.I have not still started to play with Z80+microcontrollers but it seems that one of the main problems are that reading so many GPIOs takes a lot of cycles. I've seen reading several GPIOS at a time (in atmega2560) by just reading a port once and then checking every bit, in this way the program is fast enough not to miss anything. I can imagine you are doing sth similar with PIC

It would be great to have the sources and understand how it works. I think this will improve USIFAC and inspire others.

If opening is not in your plans, a developer guide with the theory of operation would also be nice (but I know documentation is always hard while you can use this time to develop more things)

madlax39 · « **Reply #293 on:** 21:50, 28 March 21 »

I'm back with an healthy Amstrad!
It was the CRTC controller that had been damaged, I change it and now my CPC is back to live

My new card works, with TX and RX LEDs light up when I send or receive data.

I did some tests between an original Amstrad RS 232 and my new card. The two cards communicate well with each other, that's good news!

I made a little video on my youtube, sorry it's in french ...

https://youtu.be/9lpgiISFx7s

madlax39 · « **Reply #294 on:** 10:41, 01 April 21 »

If anyone is interested in this evolution of the USIfac card, you will find attached the GERBER file as well as the KICAD file.
The components to be added to the base card are:
MAX232 (1)
Capacitor 10uF 25V (4)
10Kohm resistor (3)
3mm LED (3)
DB9 male connector (1)

And if you make this card, don't make the same mistake as I did, connect the RS232 cable to your computer POWER OFF!!!

issalig · « **Reply #295 on:** 13:15, 02 April 21 »

Hi, I have modified your schematics using "Global labels" in order to make the schematic clearer. (Also some no-connections have been added for nice ERC)

WARNING: Not sure if everything is ok. Some ERC are failing but i think it is ok.

News:

Author Topic: Universal Serial Interface for Amstrad CPC (a.k.a USIfAC) (Read 40534 times)