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

Started by ikonsgr, 08:17, 01 December 20

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

d_kef

Quote from: Brocky on 03:18, 18 January 24im 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

Quote from: eto on 23:26, 17 January 24
Quote from: ikonsgr on 22:42, 16 January 24can 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

Quote from: ikonsgr on 22:38, 16 January 24with 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

Quote from: ikonsgr on 09:56, 18 January 24These videos was using the previous firmware (before starting tests with the rev 7c)?
no, this is the latest firmware you provided

Quote from: ikonsgr on 09:56, 18 January 24Because 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

Quote from: eto on 11:24, 18 January 24It 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

Quote from: eto on 14:10, 18 January 24sure... 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

Quote from: ikonsgr on 17:47, 18 January 24Well, 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

Quote from: eto on 22:14, 18 January 24and 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

Quote from: eto on 22:12, 18 January 24Honestly 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...  :D )  , 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  :P   (i have a feeling that @Audronic will be particular happy with this :)  )

Devlin

Quote from: ikonsgr on 19:18, 19 January 24
Quote from: eto on 22:12, 18 January 24Honestly 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...  :D )  , 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  :P  (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.
CPC464 & CPC6128 + USIfAC II + Revaldinho 512k(universal cpld ver) - Schneider CRT TV
Administrator of Amstrad Discord : https://discord.gg/ksWvApv

eto

Quote from: Devlin on 00:57, 20 January 24Can 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

Quote from: Devlin on 00:57, 20 January 24Can 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

Quote from: ikonsgr on 13:00, 20 January 24as 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


GRAPHICAL Z80 MULTITASKING OPERATING SYSTEM

ikonsgr

Quote from: andycadley on 13:33, 20 January 24It'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

Quote from: andycadley on 09:53, 21 January 24Setting 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):
;; 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

Quote from: ikonsgr on 13:57, 23 January 24FIRMWARE 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)
CPC464 & CPC6128 + USIfAC II + Revaldinho 512k(universal cpld ver) - Schneider CRT TV
Administrator of Amstrad Discord : https://discord.gg/ksWvApv

ikonsgr

Quote from: Devlin on 18:03, 23 January 24The 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... :P  )
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"  ;D  )

Devlin

Quote from: ikonsgr on 18:19, 23 January 24
Quote from: Devlin on 18:03, 23 January 24The 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... :P  )
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"  ;D  )
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.
CPC464 & CPC6128 + USIfAC II + Revaldinho 512k(universal cpld ver) - Schneider CRT TV
Administrator of Amstrad Discord : https://discord.gg/ksWvApv

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.  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

ikonsgr

Quote from: GUNHED on 15:48, 24 January 24The 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

Quote from: ikonsgr on 13:57, 23 January 24FIRMWARE 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.
CPC 464, CTM 644, USIfAC II, 512K RAM/ROM, FD1 & DD1, mouse, Multiface II

Powered by SMFPacks Menu Editor Mod