desempolvando injektor prisma(AYUDA) y aprendisaje

[dogdark]

Bueno desde hace un tiempo, que ya he tenido varios progresos y proyectos de la mano de assembler en la programación. El ultimo desamble que me pegue, fue el de prisma injektor, les dejo al github.

github injektor prisma

Son dos los archivos desamblados, el injedu y el enjgam, ambos son sistemas injektor pero con diferencias internas.
El injedu. tiene la posibilidad de recuperar el bloque en caso de que algun byte no cargue, el famoso, retroceda 3 vueltas, a diferencia del injgam que no cuenta con aquello por tener un irg más corto y con carga más rápida.

El código en si del sistema injektor, esta en la carpeta paginas como injektor.asm, ese es el código principal que permite poder cambiar la velocidad a 4000 baudios.

En su primera instancia logre poder modificar el loader a mis necesidades, tal como lo hice con el nhp 3.6.
obviamente ya tengo la guía anterior para seguir los pasos para realizar los cambios. Pero hice algunos cambios para dejarlo compatible con 256k, ahi empezo mi drama, al querer volver atrás, resulta que ya no resultaba nada, tome la desición de comenzar desde 0, porque a veces es mucho mejor, todo bien, con la pag7 y pag4, que son los 4 primeros bloques del sitema de casete, el problema que tengo es con el loader nuevamente, la verdad me maríe porque solo con poner un byte adicional este se cuelga y deja de cargar.

proyecto personal en github por si lo quieren ver completo
proyecto personal

de partida tengo que eliminar los colores centrales que eso lo tengo claro, pero si se pueden fijar, solo agreguen un .by 0 y el loader ya no les funcionará, revise linea por linea para ver los jsr, los jmp y que esten bien direccionados, a diferencia del original que ya tiene muchas correcciones.
el loader cuenta con una función que reconoce de forma automática el largo completo del mismo archivo y que es pasado de forma directa y automática al pag4 que es el encargado de cargar el loader.

de antemano cualquier ayuda sería buena, para este mareado.

[xt5]

Bien por seguir dandole a los cargadores.

resulta que ya no resultaba nada, tome la desición de comenzar desde 0, porque a veces es mucho mejor, todo bien

Es lo mejor, aunque parece que trabajas el doble, aprendes un montón más.

el problema que tengo es con el loader nuevamente, la verdad me maríe porque solo con poner un byte adicional este se cuelga y deja de cargar.

Esa parte no la entiendo muy bien, al poner ese byte adicional donde?

No tienes como depurar las partes importantes en el debugger de Altirra?? porque el ciclo completo de probar en un Atari es lentísimo.

Así solo mirando el código no puedo ayudarte mucho tendría que compilar e irlo probando.

[dogdark]

hola xt5,,,, el proyecto lo tengo muy bien avanzado, ya tengo la versión para el 130xe trabajando, aunque puede tener detalles aún que se reparan en el camino, la versión de 256k esta casi en el final, solo estoy teniendo problemas del buffer, estoy viendo donde lo meto, porque son 255 bytes que deben estar disponibles y que no topen con ninguna posición de memoria que ocupen los juegos que son extremadamente largos, como por ejemplo el commando256k. Este juego se carga completo pero no parte, por el tema del bufferin, los demás juegos todos cargan.
Ahora respondiendo a tu duda, sobre el byte adicional, este es el famoso byte fantasma que yo le llamo, todos los copiadores tienen la facultad de poder cargar archivos hasta los 255 bloques no más, entonces se representan en un byte que se recupera en el loader del cargador, donde se pasa los siguientes parámetros.

20 bytes para el titulo del juego
3 bytes para los bloques en atascii
y un byte con la cantidad de bloques que se maneja en descuento para ver el final de la carga.

en el super ultra, cuando lo arme, como tiene la capacidad de trabajar con mas de 4 bancos, hasta 17 aprox, los bloques que se cargan son mayor a 255, ejemplo el commando 256k, tiene 512 bloques, entonces como el byte final solo puede llegar hasta $FF(256), tengo que pasar un byte más para decir que la carga ya no es de 256 si no que 512, entonces el byte final queda en $00 y el byte fantasma toma el valor de $02,, $0200 son 512 bloques, entonces el primer byte se descuenta en 1, al pasar el primer bloque de carga del juego y al restar este queda en $ff y el byte fantasma pasa a $01, y el loader va validando si el byte fantasma esta en 0, puede parar oreja hasta que el byte final también este en 0 y se termina la carga. El byte fantasma lo paso después del byte final de forma automática cuando este calcula el total de bloques del juego.

[xt5]

Te entiendo lo del contador, yo le llamaría al "byte fantasma" el MSB (Most Significant Byte) en este caso, y si el loader tiene la logica para decrementar ambos, entonces sería cosa de poner ambos bytes con sus valores adecuados y ya. Como se llaman esas variables?

Mirando el código tratando de buscar donde está ese byte fantasma no lo pude encontrar en el primer vistazo, me llamó la atencíon este código.

Código: Seleccionar todo

RESTORE
    LDY #$13
?RESTORE
    LDA #$20
    STA ??FILE,Y
    LDA #$00
    STA NAME,Y
    sta NAMEG,y
    STA FILE,Y
    sta TITLOP7,y
    sta TITLO2P7,y
    STA CRSR,Y
    STA FILE,Y
    sta general,y
	DEY
    BPL ?RESTORE

Donde dejas en 0 muchas copias del titulo del juego (NAME, NAMEG, FILE, TITLOP7, TITLO2P7, CRSR, y nuevamente FILE) y eso me mareo mucho buscando las variables, de verdad cumplen funciones distintas y necesitas tenerlo tantas veces?

Si me dices como se llaman o donde están las variables relevantes lo vamos viendo paso a paso

[dogdark]

https://github.com/a8dogdark/doginjk
ahi se encuentra el proyecto del copiador injektor 256k en pañales, no es el que aun se da por oficial, esta solo para pruebas, porque cuenta con errores.

Código: Seleccionar todo

Te entiendo lo del contador, yo le llamaría al "byte fantasma" el MSB (Most Significant Byte) en este caso,
y si el loader tiene la logica para decrementar ambos,
 entonces sería cosa de poner ambos bytes con sus valores adecuados y ya. Como se llaman esas variables?

Este se encuentra en el loader

en el archivo paginas/ploader.asm, encontrarás dos variables

Código: Seleccionar todo

RECUPERO3
;RECUPERO LOS BLOQUES EN ATASCII
    LDA FINRECUPERO+20,X
    STA CONTADOR,X
    DEX
    BPL RECUPERO3
    lda finrecupero+24		;recupero bytes falso para 256k
    sta pfalso
    LDX #$03
    LDA FINRECUPERO+23		;RECUPERO LOS BLOQUES EN BYTE
    STX $41
    STA PFIN
    LDY #$7F
    LDA #$00

LDA FINRECUPERO+23, recupera el byte principal contador y se guarda en pfin
LDA FINRECUPERO+24, se recupera el byte fantasma(MSB), que no lo llame así, porque después no me acordaría, siempre uno usa variables de las cuales sepas y te acuerdes que son y para que son.

Código: Seleccionar todo

serabye
	lda pfalso
	cmp #$00
	beq bye
	dec pfalso
	jmp ?grab

y acá valido si el byte fantasma esta en 0 se lo salte para que valide el byte principal pfin

NAME, NAMEG, son variables que se usan para colocar los títulos en la portada principal y desde ahí se saca la data para ser pasadas a al loader y a la pagina7, como yo trabajo en wudsn de eclipse, al principio coloco muchas variables que puedes ser eliminadas, pero como es proyecto las dejo y cuando ya optimizo, esas variables llegan a ser de 10 bajan como a 5 o 4. hay muchas de ellas que no se pueden quitar por tema de anexar códigos al principal, porque no permite poder usar la misma variable en dos paginas diferentes.

PD: enfócate solo en el proyecto en el que estoy trabajando para que hablemos en el mismo idioma y te pueda explicar bien de que se trata cada una de las variable y funciones.

[xt5]

Eso mismo, para que estemos muy claro de lo quieres revisar, entiendo que el código relevante es este:

Código: Seleccionar todo

GRAB
    LDA $D40B
    BNE GRAB
    LDA PFIN
	beq serabye
;    BEQ BYE
    JSR LNEW
    JSR NEWDL
?GRAB
    LDX #$0B
MSIO
    LDA LSIOV,X
    STA $0300,X
    DEX
    BPL MSIO
    JSR $E459
    BMI ERROR
    LDA BAFER+2
    CMP PFIN
    BCC ERROR
    BEQ RETURN
    JMP ?GRAB
RETURN
	LDX #<DERROR	;$CB
    LDA #>DERROR	;$CC
    STX DLERR		;$CC4E
    STA DLERR+1		;$CC4F
    LDA BAFER+255
    STA NBYTES
    LDX #$02
C01
    LDA CONTADOR,X
    CMP #$10
    BNE C02
    LDA #$19
    STA CONTADOR,X
    DEX
    BPL C01
C02
    DEC CONTADOR,X
    JSR NEWL
    DEC PFIN
    LDY #$00
    STY $4D
    JMP GBYTE
serabye
	lda pfalso
	cmp #$00
	beq bye
	dec pfalso
	jmp ?grab
BYE

Que llevandolo a pseudo-código estructurado y obviando algunas partes vendría as ser algo parecido a esto:

Código: Seleccionar todo

func GRAB {
    wait_for_zero( *$D40B)

    if(*PFIN==0) {
        /* serabye */
        if(*PFALSO==0) return
        *PFALSO--
    } else {
        LNEW()
        NEWDL()
    }

    for {    
        /* ?GRAB: */
        move_bytes(0x300, LSIOV, 11) /*dst, src, size*/
        if($E459()<0 || *(BAFER+2)<*PFIN) {
            /* ERROR: */
        } else if((*BAFFER+2)==*PFIN) {
            /* RETURN: */
            ....
            NEWL()
            (*PFIN)--
            (*0x4D)=0 
            JMP GBYTE /* desde aquí no se puede estructurar */
        }
    }
}

Creo que mi traducción no está tan mal, aun no entiendo muy bien que pretende hacer y como eso, si ese es el código y profundizas en que hace y que quieres logras, pues super!

[dogdark]

la consulta, ¿en que sistema estas trabajando? se parece a python.

[xt5]

la consulta, ¿en que sistema estas trabajando? se parece a python.

No no, en no es Python, es pseudo-código totalmente inventado con sintaxis similar a C, es que assembly desestructurado es muy difícil de entender, entonces me conviene el ejercicio de estructurarlo, según yo eso es copia fiel del assembly que cité, puede tener errores, claro!