USIfAC II:Convert a PC or USB stick to Amstrad HDD,access dsk's,and many more!

[d_kef]

im seeing exactly the same as eto...

apart from one difference with my setup.. (with auto usb off)...
i type |usb and the stick is activated...
but if i type CAT ..like in eto's 2nd vid, then i lock up....
if i use |CAT it works as intended

Exactly the same here.

d_kef

[ikonsgr]

can you remind me what exactly was that behavior? is at least the board usable, even if it needs a reset or two? also did you try to disable `auto usb` function (OUT &FBD1,93) and see if that helps?

Auto USB on:

in short: CPC boots, USIFAC message is shown, CPC automatically resets, boots until "Locomotive Software ltd" is drawn - then freezes (before Basic 1.0 message)

video (auto USB on):
https://www.dropbox.com/scl/fi/3iqy2dp62z98dnh64f8ap/IMG_4555.MOV?rlkey=puqr37nhzyll6cf0w5xtp7w3h&dl=0
 
Auto USB off:
CPC boots, Usifac message is shown, I can access BASIC. Once I type |USB the USB stick content can be access. But as soon as I reset, I am stuck in the same loop as above.

video (auto USB off):
https://www.dropbox.com/scl/fi/iwo5ag2gjzmk042cfp66t/IMG_4557.MOV?rlkey=fms63gv1ey8ca27n4nodmomnx&dl=0

with previous fw the freeze should be done after `BASIC 1.0` is typed on screen, now it should freeze before that, is that correct?

 no. it always was freezing before the BASIC 1.0 is drawn on screen.

These videos was using the previous firmware (before starting tests with the rev 7c)?
Because i thought that using the last 2 firmwares, CPC didn't freeze for ever upon resets, and it only needed one reset to work with "Auto usb".
Btw, the message you quoted was addressed to d_kef  , the previous msg was addressed to you: https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/usifac-iimake-your-pc-or-usb-stick-an-hdd-for-amstrad-access-dsk-and-many-more!/msg235100/#msg235100
where i asked for making a video using the latest fw to check if there were any difference (mainly with exact messages on screen) with the previous fw that, as you said, seemed to work the same way (and gave the best behavior too).

[eto]

These videos was using the previous firmware (before starting tests with the rev 7c)?

no, this is the latest firmware you provided

Because i thought that using the last 2 firmwares, CPC didn't freeze for ever upon resets, and it only needed one reset to work with "Auto usb".

it depends on the USIFAC. the more recent one was working, the older one was not. 


I'll do another video this evening with a clear information about if it's the older or the newer model. Sorry... yesterday was a bit stressful and I was not clear here. 

[ikonsgr]

Ok,i made another test fw (probably the last one), this should keep the FDC CLC (logic cell that controls the FDC emulation) always active.
As this was that improved the boot behavior in the first place, i would like to see if there is any change when this is always 'on' (even when Basic rom kicks in, after USIfAC's initialize). I've noticed that the reset upon cold boot is made AFTER "BASIC 1.0" is shown on screen, meaning that this reset is actually NOT caused by USIfAC firmware, but rather from Basic rom it self!
So @eto, if you can try this fw too (marked 7d on boot msg),and tell me if you have any difference compared to the last fw that, as you said, didn't had any differences with previous fw

It depends on the USIFAC. the more recent one was working, the older one was not.

Btw, when you say "older board" you mean the green one?

[eto]

sure... will do hopefully later this evening. 

green = older one (without disk swap button)
white = newer one (with disk swap button)

I'll check with both version with 7c and then with 7d. 

[ikonsgr]

sure... will do hopefully later this evening.

green = older one (without disk swap button)
white = newer one (with disk swap button)

I'll check with both version with 7c and then with 7d.

Well, since green board is now obsolete for years, and most of the boards sold (~85%-90%) are the white ones, i'm mostly interested for the newer white board     

[eto]

Well, since green board is now obsolete for years, and most of the boards sold (~85%-90%) are the white ones, i'm mostly interested for the newer white board     

makes sense ... okay, so no more video of the green one ;-)

7c - USB on: https://www.dropbox.com/scl/fi/75xoi32fbzldj8yxt2js1/7c_USB_on.MOV?rlkey=x8ur4h6oyqzonvip9713px9aj&dl=0
 7c - USB off: https://www.dropbox.com/scl/fi/lh1q5pz9uuw9xdn99i4ke/7c_usb_off.MOV?rlkey=hoe9iofbod8acfrsq9kh2db6g&dl=0
7d - USB on: https://www.dropbox.com/scl/fi/wxh3d6z93kyrj8hzixeqk/7d_USB_on.MOV?rlkey=4x2nkq1jyfl01x0eme1zp58f1&dl=0
7d - USB off: https://www.dropbox.com/scl/fi/81k1cummkr15qpjd9mfvt/7d_USB_off.MOV?rlkey=4dbno4xzugztndz0uztwi2d9j&dl=0

There is no difference between 7c and 7d.

USB on:

• CPC boots until "USB Device connected at ..." messageautomaticall reset
• boots again until "... Locomotive Software Ltd"
• then freezes

after a manual reset, the USB stick can be accessed until the next full power circle (resets don't freeze)


USB off:

• CPC boots normally into BASIC prompt

after |USB the USB stick can be accessed until the next full power circle (resets don't freeze)


Honestly I think that is good enough. It's just a single RESET that is required after the computer is turned on.


PS: Just for sake of completeness: there is also no change in behavior for the old board with 7d. It's just no usable with the 464.

[eto]

and just out of curiosity: What's the difference between those 2 boards?

[ikonsgr]

and just out of curiosity: What's the difference between those 2 boards?

Apart from the addition of the dsk swap button, older boards used MCLR pin to "Hardware" reset PIC along with Amstrad, when reset button is pressed, but because this caused some problems (in some rare cases firmware was deleted), newer boards use "software" reset for PIC,  (MCLR-master clear- is disabled and there was also some rewiring along with the addition of an extra diode) and if i'm not mistaken, i never had a "deleted PIC" report again. Most probable this difference is what causes the "worst" behavior of the old board when flashed with newer firmwares designed to use "soft reset".

[ikonsgr]

Honestly I think that is good enough. It's just a single RESET that is required after the computer is turned on.

Honestly, i totally agree   
Pressing reset button once upon cold boot (and only when "auto usb" is active), is really not a big deal, and of course it's much better behavior than with previous firmware, which required unplug/plug usb stick or dual resets and repeat the process again, after every reset too, right?
Again, THANKS A LOT for your help in making USIfAC board better! 
I will soon release a new "official" firmware update to include the booting improvements, and with the addition of the small utility that @Devlin noted here which i incorporated as a simple rsx commnand: |RSX , which i believe would be VERY helpful for all Amstrad CPC 464 owners with USIfAC II boards (that are not lazy enough to use file manager all the time...  )  , as it will save them from the Basic 1.0 tedious operation ,of passing strings to RSX commands (the all known, a$="string":|RSX_COMMAND,@a$, instead of giving a simple: |RSX_COMMAND,"string" like on Basic 1.1), and also save them of replacing CPC464 fw+basic roms just for that    (i have a feeling that @Audronic will be particular happy with this   )

[Devlin]

Honestly I think that is good enough. It's just a single RESET that is required after the computer is turned on.

Honestly, i totally agree   
Pressing reset button once upon cold boot (and only when "auto usb" is active), is really not a big deal, and of course it's much better behavior than with previous firmware, which required unplug/plug usb stick or dual resets and repeat the process again, after every reset too, right?
Again, THANKS A LOT for your help in making USIfAC board better! 
I will soon release a new "official" firmware update to include the booting improvements, and with the addition of the small utility that @Devlin noted here which i incorporated as a simple rsx commnand: |RSX , which i believe would be VERY helpful for all Amstrad CPC 464 owners with USIfAC II boards (that are not lazy enough to use file manager all the time...  )  , as it will save them from the Basic 1.0 tedious operation ,of passing strings to RSX commands (the all known, a$="string":|RSX_COMMAND,@a$, instead of giving a simple: |RSX_COMMAND,"string" like on Basic 1.1), and also save them of replacing CPC464 fw+basic roms just for that    (i have a feeling that @Audronic will be particular happy with this   )

Can it have an autostart option too? It'd be nice to just have it active on start-up instead of having to run it every time.

[eto]

Can it have an autostart option too? It'd be nice to just have it active on start-up instead of having to run it every time.

Only if it can be (de)selected by a hardware switch. I do not want the USIFAC to automatically always start the same program. 

[ikonsgr]

Can it have an autostart option too? It'd be nice to just have it active on start-up instead of having to run it every time.

I'm afraid this can't be done, because this routine uses a rare form of basic CALL command with extra arguments (instead of a simple CALL address that executes assembly code from basic, starting from that address, it has an extra address for arguments, e.g. CALL adr,adr2, btw this was the 1st time i ever saw a CALL used that way...), so it can only executed using Basic CALL command. This means that it needs Basic rom to be initialized and active.
 Unfortunately Amstrad performs initialization of Roms "backwards", e.g. it starts from highest upper rom and goes down to lowest rom which usually is Basic (placed in upper rom 0). So by the time USifAC's init code is executed, there would be no Basic present to execute routine's  Basic code. The only alternative would be to "extract" the asm code and executed directly (i've already done that with other routines),but as i already explained, this can't be done, due to the exta arguments needed, and i really don't have a clue how CALL command manage this...
So, i'm afraid the only option is to have the routine as a simple RSX command, but in the end, i don't think it's that much trouble to give a simple: |RSX or... perhaps...to make things even faster, should i use a single letter RSX... like: |X  , what you think? 

[andycadley]

as i already explained, this can't be done, due to the exta arguments needed, and i really don't have a clue how CALL command manage this...

It's essentially the same as an RSX. That is the A register holds the number of parameters and IX points to them. Other than that it's a straightforward CALL.

https://cpcrulez.fr/coding_RSX-anatomy_of_an_RSX-part_1_AA.htm

[Prodatron]

CALL and RSX is like IP numbers and domain names

[ikonsgr]

It's essentially the same as an RSX. That is the A register holds the number of parameters and IX points to them. Other than that it's a straightforward CALL.

https://cpcrulez.fr/coding_RSX-anatomy_of_an_RSX-part_1_AA.htm

hmmm, so you think that if i set register a=1 and ix=the specific address from the CALL command in Basic program,and then execute the asm code it will work? Although i think these have a meaning only for the code of the Basic CALL command, so without Basic the asm code can't be executed correctly...

[andycadley]

Setting A to 1 and IX to point to memory containing "addr2" (assuming it's an integer parameter) - not setting IX to addr2 -. That will work, yes. That's all BASIC is doing with parameters behind the scenes. It's just a calling convention at the end of the day.

[ikonsgr]

Setting A to 1 and IX to point to memory containing "addr2" (assuming it's an integer parameter) - not setting IX to addr2 -. That will work, yes. That's all BASIC is doing with parameters behind the scenes. It's just a calling convention at the end of the day.

Yes, but here we are talking of executing correctly the asm code that normally is given through a Basic listing and a CALL command in the end, WITHOUT  BASIC interpreter, as this exactly is the case of "auto loading" the asm routine upon cold boot of Amstrad CPC!
As USIfAC's board Rom initialization would be always commenced BEFORE Basic rom (which by default is at upper slot 0), there would be no Basic available, so we examine the possibility of executing such "asm through Basic listing" code directly.
Now that i remembered, the games included in USIfAC board, are similar cases of having a small Basic loader, that places the asm code in ram, and then gives a final basic CALL command to execute. When i tried to "manually" copy the asm code to ram and then use a simple jp addr to start execution (in place of: CALL addr basic command used in Basic loader),it didn't work! I finally made it work only when i created a small basic program with only one line: 10 CALL addr, and run it, only then game was executed correctly.
 I also took a look at the CALL code of the disassemble basic 1.1 rom (unfortunately i couldn't find Basic 1.0 in disassemble form):

Code Select Expand

;; CALL
f25c cdf5ce    call    $cef5 ; get address
f25f 0eff      ld      c,$ff
;; store address of function
f261 ed5355ae  ld      ($ae55),de
;; store rom select
f265 79        ld      a,c
f266 3257ae    ld      ($ae57),a
f269 ed735aae  ld      ($ae5a),sp
f26d 0620      ld      b,$20 ; max 32 parameters
f26f cd41de    call    $de41
f272 3008      jr      nc,$f27c         ; (+$08)
f274 c5        push    bc
f275 cde3ce    call    $cee3
f278 c1        pop     bc
f279 d5        push    de ; push parameter onto stack
f27a 10f3      djnz    $f26f            ; (-$0d)
f27c cd37de    call    $de37
f27f 2258ae    ld      ($ae58),hl
f282 3e20      ld      a,$20 ; max 32 parameters
;; B = $20-number of parameters specified
f284 90        sub     b
;; A = number of parameters
f285 dd210000  ld      ix,$0000
f289 dd39      add     ix,sp ; IX points to parameters on stack

;; IX = points to parameters
;; A = number of parameters
;; execute function
f28b df        rst     $18
defw &ae55
f28e ed7b5aae  ld      sp,($ae5a)
f292 cdccfb    call    $fbcc
f295 2a58ae    ld      hl,($ae58)
f298 c9        ret     

f299 3e0d      ld      a,$0d
f29b 1803      jr      $f2a0            ; (+$03)
 It has quite a lot of calls all over the rom, so i doubt it would be easy to find out what exactly is doing and try to "emulate" it "By hand", not to mention the fact that as this routine alters the behavior of Basic interpreter, it should require to have Basic rom initialized and be active, BEFORE executing the routine, which of course is impossible to do it upon cold boot...
And in the end, i doubt it's worth all this trouble, just to save giving a simple:|X whenever you want to avoid the tiresome way of passing strings to Basic commands of Basic 1.0...

[ikonsgr]

FIRMWARE UPDATE (rev.7c):

- New initialization Code of USIfAC II rom, offering better behavior ragarding freezing upon cold boot with some CPC464

- New RSX COMMAND: |RX installs a small routine that allows an easier way of using string arguments with Basic & RSX Commands, like with CPC 6128 Basic 1.1,e.g. instead of giving: a$"string":Command,@a$ you can now give directly: Command,"string".FOR CPC464 ONLY!

I expect this new rsx command to be a very nice addition for all CPC464 owners that prefer to use commands (now it would be much easier to use arguments with |CAT, |CD, |SNA etc) and it would eliminate the need of replacing firmware+Basic roms, just for having this ability 
Btw, @Devlin ,you were right about the previous rev7b, it indeed had a problem with dsk image access on CPC6128,but the new rev7c should work fine.

[Devlin]

FIRMWARE UPDATE (rev.7c):

- New initialization Code of USIfAC II rom, offering better behavior ragarding freezing upon cold boot with some CPC464

- New RSX COMMAND: |RX installs a small routine that allows an easier way of using string arguments with Basic & RSX Commands, like with CPC 6128 Basic 1.1,e.g. instead of giving: a$"string":Command,@a$ you can now give directly: Command,"string".FOR CPC464 ONLY!

I expect this new rsx command to be a very nice addition for all CPC464 owners that prefer to use commands (now it would be much easier to use arguments with |CAT, |CD, |SNA etc) and it would eliminate the need of replacing firmware+Basic roms, just for having this ability 
Btw, @Devlin ,you were right about the previous rev7b, it indeed had a problem with dsk image access on CPC6128,but the new rev7c should work fine.

The RSX command |RX doesn't work - to get the BASIC 1.0 string patch working, one has to use |X (i prefer this, actually)

[ikonsgr]

The RSX command |RX doesn't work - to get the BASIC 1.0 string patch working, one has to use |X (i prefer this, actually)

Yeap, "slip of the keyboard" , rsx command is |X, one letter only to get it as fast as possible
Btw, initially i had the whole basic listing of the routine patched into memory and executed by Basic, but this took ~1sec. So,i removed the assembly code from the Basic listing, and instead, used a simple ldir to copy it directly to Ram from USIfAC's Firmware, thus reducing Basic progran to only a few pokes and a call, resulting in instant execution of the rsx command (we are very impatient people nowadays indeed...   )
And, @Devlin , i suppose now dsk access works as it should on CPC6128, along with non "eternal freeze" upon booting your CPC464, right? (well the last one,at least... "as good as it gets"    )

[Devlin]

The RSX command |RX doesn't work - to get the BASIC 1.0 string patch working, one has to use |X (i prefer this, actually)

Yeap, "slip of the keyboard" , rsx command is |X, one letter only to get it as fast as possible
Btw, initially i had the whole basic listing of the routine patched into memory and executed by Basic, but this took ~1sec. So,i removed the assembly code from the Basic listing, and instead, used a simple ldir to copy it directly to Ram from USIfAC's Firmware, thus reducing Basic progran to only a few pokes and a call, resulting in instant execution of the rsx command (we are very impatient people nowadays indeed...   )
And, @Devlin , i suppose now dsk access works as it should on CPC6128, along with non "eternal freeze" upon booting your CPC464, right? (well the last one,at least... "as good as it gets"    )

All working great, now I've done a wee bit of soldering as it turns out that my serial programmer bricked itself because of spiked drivers to brick clones (boo, thank the gods it was cheap) so I had to populate the ICSP header on my second board to use the pickit3 and didn't fancy chip swapping again, but it's working great on both the earlier revision "short" white board, and the newer "long" white board one.

[GUNHED]

The RSX command !X is part of some DOS (f.e. X-DDOS) and it's purpose it to exchange drive A and B. Maybe it would be better not to use !X a 2nd time. 

[ikonsgr]

The RSX command !X is part of some DOS (f.e. X-DDOS) and it's purpose it to exchange drive A and B. Maybe it would be better not to use !X a 2nd time. 

Ok, then maybe i will change it to |R then? 

[NigeNigeNige]

FIRMWARE UPDATE (rev.7c):

- New initialization Code of USIfAC II rom, offering better behavior ragarding freezing upon cold boot with some CPC464

- New RSX COMMAND: |RX installs a small routine that allows an easier way of using string arguments with Basic & RSX Commands, like with CPC 6128 Basic 1.1,e.g. instead of giving: a$"string":Command,@a$ you can now give directly: Command,"string".FOR CPC464 ONLY!

I expect this new rsx command to be a very nice addition for all CPC464 owners that prefer to use commands (now it would be much easier to use arguments with |CAT, |CD, |SNA etc) and it would eliminate the need of replacing firmware+Basic roms, just for having this ability 
Btw, @Devlin ,you were right about the previous rev7b, it indeed had a problem with dsk image access on CPC6128,but the new rev7c should work fine.

First of all thank you for sticking with this and trying to get the interface functional for everyone.
I have just upgraded my white USFfAC II to 7c. The behaviour is much better than before - the same as @eto described, with a USB stick inserted I only need to press reset once for the board to load with a USB stick inserted, which is great!
Unfortunately when used with your 512k RAM board, this means I can't switch to "6128 mode" - once 6128.BAS has loaded, the machine resets - which then causes it to be stuck at the "and Locomotive Software Limited" prompt. So I don't think I can use any of the features of the board apart from the extra memory.