Super Skweek M4 version for download

[Joseman]

Hi guys

This confinement days allowed me to start from scratch my loader of Super Skweek for M4 (all CPC, only 128k), with savegame working and all 180 levels.

You can grab it from here:

https://github.com/sJoseman/amstrad/blob/master/Super%20Skweek%20%7BJoseman%202020%2C%20M4%20Mass%20storage%20compatible%7D.zip

unzip it and copy all the 208 files to a folder on the microsd of the m4.

Have fun!!

[XeNoMoRPH]

Nice work !!!

[VincentGR]

Great!!!

[SOS]

This confinement days allowed me to start from scratch my loader of Super Skweek for M4 (all CPC, only 128k), with savegame working and all 180 levels.
....
unzip it and copy all the 208 files to a folder on the microsd of the m4.

Ok, i checked it against CubeMDOS and it doesnt work. 

And check,check,check  - hmmm... found the problem
Ok, the next version of CubeMDOS will support Super Skweek.

[Joseman]

Ok, i checked it against CubeMDOS and it doesnt work. 

And check,check,check  - hmmm... found the problem
Ok, the next version of CubeMDOS will support Super Skweek.

Hi

Im aware of that because of XeNoMoRPH

I think that the problem is of the two sides 


I was preventing the mass storage roms to display text after the roms activation (silly)

You can test U.N.Squadron too, is a similar loader than Super Skweek, but with the display text problem.

Grab it here if you want:

https://github.com/sJoseman/amstrad

Regards
Jose
P.S. One question, Why the load was failing on the primary load too? (there is not any rom reactivation there), maybe a problem with ram banking?

[SOS]

I was preventing the mass storage roms to display text after the roms activation (silly)

You have not handled &be78 completely. You set them, but on BCCE it's gone.
It looks like that you set them, but not in your working-copy of the OS-RAM at C22B.
(after LDIR-Restore to &a000 - &c000 &be78 is destroyed)
But i do not intensive check this, because with my Workaround it's working (maybe the same Problem with some other games).

You can test U.N.Squadron too, is a similar loader than Super Skweek, but with the display text problem.

It has an important difference to Super Skweek: It does not save the RAM between BE00-BEFF, so it can never run on the XMASS of CubeMDOS, Maybe later with the SF3-Version of CubeMDOS.

P.S. One question, Why the load was failing on the primary load too? (there is not any rom reactivation there), maybe a problem with ram banking?

I counted 19 reinits of ROM7 from your loader ;-)
Or do i not understand you correctly?

[Joseman]

You have not handled &be78 completely. You set them, but on BCCE it's gone.
It looks like that you set them, but not in your working-copy of the OS-RAM at C22B.
(after LDIR-Restore to &a000 - &c000 &be78 is destroyed)
But i do not intensive check this, because with my Workaround it's working (maybe the same Problem with some other games).
*1


I counted 19 reinits of ROM7 from your loader ;-)
Or do i not understand you correctly?*2

*1-but when the roms are restored &be78 it's handled again. when &A000 - &BFFF is restored, it's for the code of skweek. Or i'm missing something important?
*2 yes, you're totally right, it reinits all the times the original code wants to read a 512 sector, and in the main load they are a lot of this reads. I wasn't thinking on it when i asked the question!

[SOS]

*1-but when the roms are restored &be78 it's handled again. when &A000 - &BFFF is restored, it's for the code of skweek. Or i'm missing something important?

Yes 

When i make anchors at
(1) bc77
(2) bcce
(3) read/write of &be78
(4) LDIR to save the System-OS-RAM
(5) LDIR to restore the System-OS-RAM

The anchors will be hit in this steps:
1. A lot of (1) until the loading screen appears
2. 5* (1)
3. (4)
4. (2) !!   (be78 is "0")
5. (2) !!   huh
6. (3) - set to "0"   CubeMDOS (hmmm....  )
7. (3) - set to "ff"  SuperSweek 
8. (1)
9. (5) !!   - now it's "0"     (restore from Step 3 the RAM, and overwrites the Step 7 "Set to FF")
10. (4)
11. (2) - it's "0"

[Joseman]

Hi @SOS

My loader do this steps (if i'm not mistaking anything)

**in the first part of the process the loader is working with firmware/os untouched:

** the loading screen is the first being loaded, 1-BC77
** next lvls.bin in #C000 &C1 (+1 bc77)
** next patch.bin in #F000 &C1 (+1 bc77)
** next fac1.bin in #4000 &C5 (+1 bc77)
** next sx.bin in #1000 &C0 (+1 bc77) (original code untouched)
** next sk.bin in #4800 &c0 (+1 bc779 (original code untouched)

6 - BC77

then i put 2 nops on one ldir on the original code, the one that move some code to #bc00

then the control is given to the original code, but i don't allow to move his code to #bc00, instead i have mine there. when the original code calls #bc00 then the patch is applied.

from this point, and with the patch applied, the original code decide to load 19 - 512bytes sectors until the menu appears.

My code intercepts this calls on #2029, do the save firmware/os zones, activate firmware, activate roms (&be78 handled), load the files and make that the code loaded is at where the original code wants. then restore firmware/os zones (&be78 unhandled) and RET at where the original code called #2029, SP and registers as original.

technically the original code of the game don't have a clue of what was the process on #2029 and continue working as expected.

With the levels ist's exactly the same process (#2029 is called).

by the way, i dissable txt output before the roms activation this way:

LD A,&C9
LD (&BB5A),A

maybe is not the best mode of doing it?

Regards
Jose

[SOS]

by the way, i dissable txt output before the roms activation this way:

LD A,&C9
LD (&BB5A),A

maybe is not the best mode of doing it?

It's ok, or BE78 is also good (BE78 is more OS-Style-Guide-Like). I like the save of the Firmware
ld hl,&a000
ld de,&c22b
ld bc,&2000
ldir
(&c171 adress)
before you make an BCCE.

AFTER(!) the ROM-Init you set both BE78+BB5A   (too late)
and AFTER that, the original RAM is restored (&C188), where the previous RAM-Content of BE78+BB5A is restored, so you previously changed RAM-Values are lost (and never be used)
The Position of BE78+BB5A you must change...

[Joseman]

It's ok, or BE78 is also good (BE78 is more OS-Style-Guide-Like). I like the save of the Firmware
ld hl,&a000
ld de,&c22b
ld bc,&2000
ldir
(&c171 adress)
before you make an BCCE.

AFTER(!) the ROM-Init you set both BE78+BB5A   (too late)
and AFTER that, the original RAM is restored (&C188), where the previous RAM-Content of BE78+BB5A is restored, so you previously changed RAM-Values are lost (and never be used)
The Position of BE78+BB5A you must change...

What version do you have?
Yes, was my mistake and was fixed!
I uploaded another where bb5a is set before the rom init (&be78 is still late but with bb5a set to &C9 i think it's ok?

The code for load files is this (english in capital letters, some in spanish sorry):

Code Select Expand


.carga_fichero

    call salva_datos_corrompen **DATA OF GAME CORRUPTED BY FIRMWARE AND OS IS SAVED
    ld sp,#c000 ;colocamos nuestro stack en zona firmware friendly.
           

    ;activamos firmware
    call activa_firmware ;firmware activation **WITH BB5A Y BE78 HANDLED

.realiza_carga

    ld hl,nombre_fichero ;YA CAMBIADO EL NOMBRE SEGUN TRACK Y PISTA
    ld b,8
    ;de debe tener una direccion para el buffer de 2k que se usa para leer fichero (no se usa en disco, solo en cinta)
    ld de,#a900 ;lo ponemos aqui para guardar compatibilidad con cinta en cpc464
    call #bc77    ; CAS IN OPEN
    ld hl,(dire_carga_temp) ;la guardamos ahi porque al cambiar stack se nos desvirtua.
    call #bc83    ; CAS IN DIRECT
    call #bc7a    ; CAS IN CLOSE

   

;acabamos de cargar ficheros

di


    jp restaura_datos_corrompidos ;**RESTORE GAME DATA CORRUPTED BY FIRM/OS WITH JP OR THE ORIGINAL STACK IS CORRUPTED.


Do you see something wrong? maybe it's but i don't see it!

Regards