News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_Duke

Amstrad CPC WiFi

Started by Duke, 07:36, 07 May 16

Previous topic - Next topic

0 Members and 12 Guests are viewing this topic.

Duke

Quote from: Joseman on 10:26, 15 February 17
About Gunship and the save/load hang

I was thinking if the problem was with the game itself, but i've been  trying with the game on floppy, M4 connected, |disc, and the game never hangs.

@Duke, one doubt: When you do the |disc with the M4 connected, i presume you replace again the original amsdos routines, but the game do (from the start) a call #BCCB, i presume (again) that the M4rom is loaded and the routines are replaced after that. The game (on floppy and M4 and #BCCB) keeps saving and loding correctly, then the doubt about if the problem is the M4, the M4rom and the lack of memory is ruled out... what do you think?
If you run it from disc, with M4 connected and it does a BCCB it should load/save from the microSD, so the pilot.bin would be modified on microSD and not the disc, correct?
I have tried to save/load repeatedly a few times when starting it from M4 and it didn't hang. How do I replicate it?
Maybe you could keep a copy of the corrupted pilot.bin and upload it? which imo. points to a memory conflict (workspace of M4 being compromised)

Joseman

Quote from: Duke on 10:39, 15 February 17
If you run it from disc, with M4 connected and it does a BCCB it should load/save from the microSD, so the pilot.bin would be modified on microSD and not the disc, correct?
I have tried to save/load repeatedly a few times when starting it from M4 and it didn't hang. How do I replicate it?
Maybe you could keep a copy of the corrupted pilot.bin and upload it? which imo. points to a memory conflict (workspace of M4 being compromised)

But if i run it from floppy and the game do a #BCCB, then you're right, the M4 should start working again (and the floppy not accessible)... but the directory will be the root because i didn't use the directory of the game on HDD... but the game keeps saving on floppy!, it's clearly using the floppy because the slowness and the head sound... this is really strange... maybe i overlooked something... or i don't understand well what is going on with a call #BCCB and the M4!


Duke

#1327
Quote from: Joseman on 10:47, 15 February 17
But if i run it from floppy and the game do a #BCCB, then you're right, the M4 should start working again (and the floppy not accessible)... but the directory will be the root because i didn't use the directory of the game on HDD... but the game keeps saving on floppy!, it's clearly using the floppy because the slowness and the head sound... this is really strange... maybe i overlooked something... or i don't understand well what is going on with a call #BCCB and the M4!
Or maybe it does a BCCE somewhere? Did you try to put a breakpoint on it?

EDIT: It doesn't do either, quick test in winape and put breakpoint on BCCE and BCCB. So that explains why it keeps reading/writing to disc.

Joseman

Quote from: Duke on 10:49, 15 February 17
Or maybe it does a BCCE somewhere? Did you try to put a break point on it?

i think that i searched for it and didn't found any #BCCE, but maybe i didn't look well, but this doesn't make sense since the save/load works on the M4 (not always for me)


Duke

Quote from: Joseman on 10:53, 15 February 17
i think that i searched for it and didn't found any #BCCE, but maybe i didn't look well, but this doesn't make sense since the save/load works on the M4 (not always for me)
True, but it also doesn't use BCCB, so that explains it.

And another quick test with WinAPE, fill the memory below AMSDOS worksspace with some random bytes (-128+4 would be M4 rom workspace)... I don't see anything overwriting it when in the load/save dialog, before starting the actual game.
But when I start the game, this gets overwritten. So its using the himem upto AMSDOS workspace.
So if your hangs has to do with entering the game and going back, then load/Save stuff again, this is probably it.
How to fix ? - don't init amsdos and only M4 dos, then you will have no himem conflict.

Tolkin

Hy Duke,
just checked the |FCP with the B:-Drive-masscopy.
Sorry to say that, but it isn´t working.
With Parados, or without Parados (pure Amsdos) in Rom7, i have no luck.
It still takes the Directory from the A:-Drive and then tries to copy these files, found in a:, from the B:-Drive.
Thanks for help :)

HAL6128


...I can confirm.


After starting the |FCP,"b:*.*","c:" command (both drives with floppies inserted) drive A had been activated and printed the directory of A, but then the routine is looking those files listed on drive B? and don't find them. Always error are occuring...
...proudly supported Schnapps Demo, Pentomino and NQ-Music-Disc with GFX

Duke

Ok, thanks both for the testing.

Looks like I better dig up a drive B and test the next fix, before releasing it :)

jomicamp

Quote from: makinavaja on 16:47, 15 January 17
Nice!
Just upgraded my card 5 minutes ago.
By the way, I just discovered that my m4 board works perfectly on my 6128plus computer but not on my 6128, even after cleaning a lot of times the contacts with alcohol, a rubber or an specific contact cleaner liquid: The card is very unstable on my 6128 and freezes or hangs randomly after any command.  Also tested both methods to power up the card: with external usb wire and with internal power.
So, the defective hardware here is my computer. Does anybody know any possible cause for this problem? capacitors? tracks? power supply of the computer? (I use an 2A external power supply!)

Makinavaja


I had identical problems until I polished the connectors of the expansion bus. They were passivated with dark film connector´s cleaning solution was helping but too slow. Polishing yielded shining connectors in a question of minutes and the M4 got to work much more stable...


Help it works for you

Duke

Another small update, M4 Firmware V2.0.2 beta 2
Download: http://www.spinpoint.org/cpc/M4FIRM_v202b2.zip
(Only M4FIRM.BIN is updated, ESPFIRM.BIN is still v2.0.1)

- Fix |FCP (again) when using wildcard on Drive B. This time I dusted of an old 3.5" drive and tested it !
- Fix for some .dsk images where multiple file entries aren't ordered (@luismcv). I should have seen that bug long ago.
- New |CD feature. You can now |CD into converted CPR dsk images (http://www.cpcwiki.eu/index.php/Converted_GX4000_Software). Of course only non plus games.
  Not sure if it is of much use. Maybe some people like the patches for joystick/pad only. Most likely the majority of converted games prefer M4 as ROM 7.
  So for good success rate, if using 464/664 or plus, set M4 rom to 7. If using CPC6128 use the modified lowerrom and have M4 in slot 6.

Joseman

Quote from: Duke on 11:30, 15 February 17
So if your hangs has to do with entering the game and going back, then load/Save stuff again, this is probably it.

No, the game hangs going straight to save/load pilot as soon as the game is loaded.

anyway see my next post... i found one strange thing with the command FCP and symbos (and another bug)

Joseman

Hi again!

Here one thing that i saw on another copy some days ago, but today with another copy the same...

if you copy with |FCP the size of the files are different than if you copy with symbos!! (at least with symcommander)

to the left with FCP, to the right with symcommander

see:



and another strange thing today copying one game, the files are copied with another extension:



what do you think?

Regards!

Duke

#1337
Quote from: Joseman on 21:03, 18 February 17
if you copy with |FCP the size of the files are different than if you copy with symbos!! (at least with symcommander)
I am guessing that SymbOS rounds the filesize up to 128 byte alignment rather than using the amsdos header size. Will check later, but I did do tests copying back and forth and comparing the original files and found no differences in size.
Quote
and another strange thing today copying one game, the files are copied with another extension:
Actually it's just how it's displayed, the file extension in AMSDOS is or'ed with flags (ie. read only for your example *). So just cosmetic, will see to parse the filename text output next time.

rcmolina

Not sure if bug or just my fault, need more testing:


- If changing directory using partial name and "*", then |ls not showing at top with the full name
- Just playing with pacman emulator (with ROMs in dsk file): after !ls cpc6128 got hanged. Next attempt, after resetting I just tried executing without listing first and worked. M4 on ROM6, and no modified lower ROM .
- Playing around with another arcade emulator (I think it was invaders): after !ls the mode was changed and names did not displayed correct, anyway executing was ok.


Just a warning, wanted to know if someone experienced this kind of behaviour  :o


Duke

Quote from: rcmolina on 07:48, 19 February 17
Not sure if bug or just my fault, need more testing:


- If changing directory using partial name and "*", then |ls not showing at top with the full name
- Just playing with pacman emulator (with ROMs in dsk file): after !ls cpc6128 got hanged. Next attempt, after resetting I just tried executing without listing first and worked. M4 on ROM6, and no modified lower ROM .
- Playing around with another arcade emulator (I think it was invaders): after !ls the mode was changed and names did not displayed correct, anyway executing was ok.


Just a warning, wanted to know if someone experienced this kind of behaviour  :o

Noted.  One thing, |LS command isn't really intended for displaying files within a DSK image, here it would be best to use cat or |dir to have amsdos compatible displaying.
Of course I can add some <am I inside a DSK code> to |ls and re-direct it to the regular dir/cat displaying.

luismcv

Quote from: Duke on 03:49, 17 February 17
- Fix for some .dsk images where multiple file entries aren't ordered (@luismcv). I should have seen that bug long ago.

Thanks Duke! I've tried today a few of the images and they work now :)

Freakbam

Great hardware, I'm looking forward to trying it

Joseman

Hi @Duke

Here again the annoying guy with bug reporting  :laugh:

This time is with the game Dr. Doom's Revenge (original version)

source: http://www.cpc-power.com/index.php?page=detail&onglet=dumps&num=754

if i copy the game (side A is enough) to a directory with |FCP and run the game, the game loads but hangs when is displaying the initial texts

But if i copy the game with Symcommander, the game runs fine!

weird, no?

Duke

Quote from: Joseman on 23:45, 19 February 17
Here again the annoying guy with bug reporting  :laugh:
Always a pleasure :)
Quote
This time is with the game Dr. Doom's Revenge (original version)

source: http://www.cpc-power.com/index.php?page=detail&onglet=dumps&num=754

if i copy the game (side A is enough) to a directory with |FCP and run the game, the game loads but hangs when is displaying the initial texts

But if i copy the game with Symcommander, the game runs fine!

weird, no?

Yes, will need to check, to save me some time, can you tell what steps you did, just extracted the .dsk into a directory and then |FCP,"C:*","A:" and then run it from A: ?

Joseman

Quote from: Duke on 23:57, 19 February 17
can you tell what steps you did, just extracted the .dsk into a directory and then |FCP,"C:*","A:" and then run it from A: ?

i wrote the dsk with CPCDiskXP to a 3,5" floppy, then i inserted it in the cpc,  make a directory on the SD, and copy it with '|fcp,"a:*","c:"'




Duke

Quote from: Joseman on 00:06, 20 February 17
i wrote the dsk with CPCDiskXP to a 3,5" floppy, then i inserted it in the cpc,  make a directory on the SD, and copy it with '|fcp,"a:*","c:"'

Thanks, I finally had a bit of energy to look at the issue.

Problem with that game is the basic files are saved with protection (save"blah.xxx",p") and amsdos cas_in_char seems to try and decrypt it when reading it (and the ptr tricks for fast copy messes it up), I managed to fix this issue, so protection is retained.
Other than that regarding filesizes there was non crucial bug, when copying files less than 2KB, one extra byte would be added (doesn't matter as AMSDOS reads the filesize in the header). Anyway that's fixed too.

Now I would like to check the "Chicago" game you posted screenshots from, to verify filesizes are 1:1. Can you link me to the dsk image for it ?

Joseman


Duke

Thanks again.

Quick test:

27-02-2017  18:23               264 CHICAGO.BAS
27-02-2017  18:23            16.512 CHICAGO1.BIN
27-02-2017  18:23            40.821 CHICAGO2.BIN

So M4 is correct about the filesizes.

Duke

M4 firmware v2.0.2 beta #3, download: http://www.spinpoint.org/cpc/M4FIRM_v202b3.zip
(ESP firmware still at v2.0.1).
Only fix of |FCP command with system protected files, removal of excessive byte with file sizes less than 2KB and display filenames with ascii characters only (no or'ed flags).


@Maniac:   I took a look at the S-DAF program. It does some dirty things with the header, which is why it doesn't work on M4 nor the files it creates.
Try typing load"S-DAF.BAS"  ... it will run the program straight away (!!!), because it overwrites &BC77 (cas_in_close). Quite a cool program btw. But not easy to make a fix for M4.

Maniac

#1349
Quote from: Duke on 22:36, 27 February 17

@Maniac:   I took a look at the S-DAF program. It does some dirty things with the header, which is why it doesn't work on M4 nor the files it creates.
Try typing load"S-DAF.BAS"  ... it will run the program straight away (!!!), because it overwrites &BC77 (cas_in_close). Quite a cool program btw. But not easy to make a fix for M4.

Thanks for taking a look @Duke - I thought it probably didn't something funny to do what it does! I'll try out your tip but I guess anything I created with it will still have to run via my HxC. If it's a lot of work and no one else is using it it just isn't worth your time and effort. But thank you anyway.

Powered by SMFPacks Menu Editor Mod