TILES / PATRONES / BLOQUES en el FM77AV2

[jimbobaby]

I cannot see the error in the loader comments, so if anyone found it, I would appreciate any hint/comment about

Look at the table with the "remix" ... i have joined both of your comments in one, just for this very reason.
In this case, track 21 is loaded onto $8000 in RAM, that, with MMR ON, is mapped to physical $05000 (extended RAM).

Código: Seleccionar todo

; mapped   $8000-$8FFF <-- $05000-$05FFF      ; $08000-$08FFF  <-- track 21 side 0

Easy!

[pser1]

Hello,
looking at BLK 142 and BLK 136 it seems that they draw on screen a big tile made out of four parts
Code and code+1 in a row, code+2 and code+3 below them.
This could imply that the only call that maybe able to draw a game screen will be BLK 161 that uses as pointer for tile codes
the area $F1DD- this is a working area, so probably some data is copied there before a screen change or it is read from disk.
This could be the last chance to find out how this damn game draws the screens
cheers!
pere

[pser1]

I cannot see the error in the loader comments, so if anyone found it, I would appreciate any hint/comment about

Look at the table with the "remix" ... i have joined both of your comments in one, just for this very reason.
In this case, track 21 is loaded onto $8000 in RAM, that, with MMR ON, is mapped to physical $05000 (extended RAM).

Código: Seleccionar todo

; mapped   $8000-$8FFF <-- $05000-$05FFF      ; $08000-$08FFF  <-- track 21 side 0

Easy!

Absolutely right!
I want to do things faster to compensate for the less time I have, but that's a very bad idea indeed
Let's see if we can find the place(s) where $F1DD is filled somehow (copy or read disk) because this area will contain
the layout of the screen to be drawn ... hopefully!
I don't think that the RAM area $C553 will be overwritten (is the one used by BLK 438)
cheers!
pere

[jimbobaby]

Let's see if we can find the place(s) where $F1DD is filled somehow (copy or read disk) because this area will contain
the layout of the screen to be drawn ... hopefully!

When on the initial loading screen, BLK 01 gets called ($809C). Iterates X from $F000 upwards in $80AA.

When in game (or entering the cove), while CRT display off, it gets called BLK 88 $D025). On address $D04D, the Y has the $F1DD value for writing.

[pser1]

Hello,
I have traced the game execution after adding a breakpoint at BLK 438 and BLK 161
The last one, as we were hoping, is called every time the screen has to be redrawn.
The area beginning at $F1DD extending 240 bytes (12 rows of double high tiles x 20 columns of double width tiles)
this means 24 rows x 40 columns of std 8x8 tiles
I am attaching here a lot of screenshots of the debugger showing the data in the aforementioned area ($F1DD-)
I have zipped them so that you can have a look at them in a better resolution ...
You will see that going twice by the same screen results in the very same bytes there, of course.

Now we need to find where the program refills that area while transitioning from one screen to another
This block is only called from BLK 4 and from BLK 222. By now I just can say that it seems a bit convoluted to understand at first sight
So it will need, probably, some debugging of these two 'callers'
cheers!
pere

ShounenMike Tracing screenshots.zip

[jimbobaby]

Now we need to find where the program refills that area while transitioning from one screen to another

Put a breakpoint at $D04D...

[pser1]

Put a breakpoint at $D04D...

Hi,
this BLK 88 only fills 4 rows of data in $F1DD, due to the value assigned to regB = $04 stored at $F001 as row counter
It also stores $0A in $F000 as column counter using as data origin $F600 ...

There is another nice point where all 240 bytes of a screen map are copied to $F1DD
You can see in BLK 04, that seems to be the main caller of the subroutine that draws tiles 16x16,
that it first clears screen (fore and backgroud) sending a command 0 to the SUB at the beginning (JSR ZD284)
Then calls BLK 88 where in case that variable $F067 isn't zero it jumps to ZD05B where it copies 240 bytes ($0F)
from pointer $F06A to area pointed by regY = $F1DD on

There are two subroutines BLK 186 and BLK 217 that calculate the value to be stored into $F06A that way
value = $E000 + 2 * ($F068) + 1
$E000 must be the beginning of the screen layouts, so $F068 would be screen number, I assume.

Finally BLK 222 loads $F06A with value $591D so the data at this address would be copied into $F1DD
This results in 220 bytes ($DC) with value $48 and then 20 bytes from fixed data tables ...

Now we need to know the contents of $E000 table (screen maps) and $F600 (data to draw 4 rows)
cheers!
pere

[jimbobaby]

Now we need to know the contents of $E000 table (screen maps) and $F600 (data to draw 4 rows)

<rant>
My head hurts . Why it has to be so... weird?
</rant>

Anyway, back on topic.

I have progressed some more. $E000 is loaded directly from disk, by Z7F01 (read sector) throguth BLK 37.

Entering the cave, it loads at $E000 two sectors ($18/$7/$0 and $1a/$8/$0). Starting at $4C it contains the tile numbers to make the background, that is, 20x12 numbered 16x16 tiles ($01 is cave wall -brown- and $F0 is cave entrance floor, for example).

Speaking of which, the tile number is used fro drawing but also for behaviour (i.e. can't go "up" to a wall tile, and going "down" on a wall tile, you fall). This is true for both, the cave entrance and the game.

Entering the game, it loads at $E000 four sectors (from $1a/$9/$0 to $1a/$c/$0). Of which, starting at $15, it has the tile definition of ten game screens, with the same structure:
1) 10x4 byte tile number data (??¿¿), so $28 (40bytes) for each screen. Yes, i know.
2) Some extra data (aprox. 21h bytes , but it can be a litte byte more or less) . And yes, seems that it's after the screen data.

Conclusions:
1)The definition of the screens is simple. There is no hierarchy (like screen definition and screen map), only the definition of the N screens, with clear duplicates and lack of efficiency.
2) I can't make out the variable "header" data (it seems to contain the screen number, and probably fixed objects on the screen)
3) There are more levels, so it seems to load them on demand.

[jimbobaby]

About the header data, for what its worth

First screen has $21 byte header (should be footer? , it goes after the data). The rest, $24

Of this header:
The first 4 bytes are the screen number that you can go to on each direction: UP DOWN LEFT RIGTH. $FF for no exit.
Byte 9 indicates the number of object on the screen: 00 is the chest. $FF for no object.
Byte $C: position Y of the object with 8 pixels granularity. So, 0 is top of the screen (it eats the hiscore zone), $18 is 192 (bottom).
Byte $D: position X of the object with 8 pixels granularity. So, 0 is left, and $26 is 304 (as the chest is 16x16)
Both can do wrap around, i guess, if you put higher values.

[pser1]

About the header data, for what its worth
First screen has $21 byte header (should be footer? , it goes after the data). The rest, $24
Of this header:
The first 4 bytes are the screen number that you can go to on each direction: UP DOWN LEFT RIGTH. $FF for no exit.
Byte 9 indicates the number of object on the screen: 00 is the chest. $FF for no object.
Byte $C: position Y of the object with 8 pixels granularity. So, 0 is top of the screen (it eats the hiscore zone), $18 is 192 (bottom).
Byte $D: position X of the object with 8 pixels granularity. So, 0 is left, and $26 is 304 (as the chest is 16x16)
Both can do wrap around, i guess, if you put higher values.

Hi jimbobaby,
thanks for these two last messages. Great job!
I have been tracing/debugging the game and writting everything down into a doc that I will upload later tonight, I hope
There are a few surprises when preparing the tile codes to fill a screen, but this will be uncovered with the text doc I am working on.
It seems that we have almost found everything related to drawing screens using tiles ...
cheers!
pere

Ps In AGD games, the tiles have a byte that defines its type, say WALL, EMPTY, WATER, CUSTOM ... and this value affects
the movement of the player too.

[pser1]

Hello,
as I commented before, I am attaching here the document I have created with the code that affects the drawing of a screen
using tiles. I have debugged/traced the game in XM7 adding quite some breakpoints ...
The text is long, but contains the values of the variables in the comments area of each code line.
Besides I have zipped some screenshots of the debugger (windows Main memory RAM) for the most important areas required
along the process.
Any comment/question that could arise, don't hesitate to comment here in this thread
Thanks a lot
cheers!
pere

Drawing Tiles.zip

Memory Screenshots.zip

Code03-v34.zip

[pser1]

Hello everyone!
After the last findings done by jimbobaby and me, I think it is time to dare to use this information to begin a very challenging
project I have had in mind since the very first day we talked about the FM77AV ...
It would be "Converting AGD games for this machine"
I have already converted the AGD engine for the Dragon and CoCo machines that use the MC6847, so PMode4 Black and White
and for the wonderful add-on by John Whitworth named "SuperSprite-FM+" that adds a video chip V9958 so having MSX2+ graphics
capability. I hope that some code could be reused for the FM77AV machines!
The first test that I was thinking of is to create the DrawRoom function that works with tiles.
So I need to convert the std AGD tile definition made by 8 bytes for the shape, 1 byte for the colour and another for the type of tile.
The FM77AV would require 8 bytes x 4 bitplanes in order to stick to the 16 colours that can be used on AGD games, being the tiles 8x8
This means that for each pixel the four bitplanes have to be calculated and then put together. There are 64 pixels, so I will try to do
that in java for speed reasons.
Of course I could stick to the fact that Spectrum AGD games only have two colours for each tile and a lot of times background is Black
This could be done with the very same AGD info and when loading the tiles put the shape on the bitplanes defined by the tile colour
but knowing that sometimes the background is another colour I prefer to go for the first method (java app)
I will open a new thread for the comments about that AGD engine conversion to have things better classified
cheers!
pere

[jimbobaby]

Hello everyone!
After the last findings done by jimbobaby and me, I think it is time to dare to use this information to begin a very challenging
project I have had in mind since the very first day we talked about the FM77AV ...
It would be "Converting AGD games for this machine"

Totally agree

[pser1]

Hola,
he conseguido preparar un programa que permite crear pantallas usando tiles.
Estoy utilizando el juego "SPRINGBOT" que convertí para el V9958. De ahí he tomado todas las tiles/patrones y las he convertido
para el FM77AV2 usando un programa java que hice hace pocos días.
Los layouts de las pantallas los he extraído del fichero .ASM que se genera al procesar el original AGD con el compilador en C
para V9958. He tomado 'prestadas' 11 pantallas ...
El programa empieza mostrando la pantalla 0. Pulsando 'P' pasará a la siguiente y pulsando 'O' a la anterior. Para salir hay que pulsar 'E'
He tenido problemas al pasar de una pantalla a otra. En ocasiones me pintaba la pantalla en blanco y a veces en negro
Al añadir un chequeo del estado del subsistema tras detenerlo y poner unos pocos ciclos de retardo tras mapear la I/O a RAM
parece haberse solucionado el problema. Ya me diréis como os funciona a vosotros.
Os pongo tres pantallazos y un zip con el fuente y el .d77
saludos

SHOWSCR2.ZIP

SPRINGBOT-SCR0.jpg

SPRINGBOT-SCR4.jpg

SPRINGBOT-SCR9.jpg

[jimbobaby]

Hola,
he conseguido preparar un programa que permite crear pantallas usando tiles.
Estoy utilizando el juego "SPRINGBOT" que convertí para el V9958. De ahí he tomado todas las tiles/patrones y las he convertido
para el FM77AV2 usando un programa java que hice hace pocos días.

He tenido problemas al pasar de una pantalla a otra. En ocasiones me pintaba la pantalla en blanco y a veces en negro
Al añadir un chequeo del estado del subsistema tras detenerlo y poner unos pocos ciclos de retardo tras mapear la I/O a RAM
parece haberse solucionado el problema. Ya me diréis como os funciona a vosotros.

A mi (en el emulador) me va genial. He pegado un vistazo asi en el codigo para ver los delays que comentas (y quitarlos para probar a ver que ocurre).
¿Es el de UpdVdpLay, justo despues del HALT?

[pser1]

He tenido problemas al pasar de una pantalla a otra. En ocasiones me pintaba la pantalla en blanco y a veces en negro
Al añadir un chequeo del estado del subsistema tras detenerlo y poner unos pocos ciclos de retardo tras mapear la I/O a RAM
parece haberse solucionado el problema. Ya me diréis como os funciona a vosotros.

A mi (en el emulador) me va genial. He pegado un vistazo asi en el codigo para ver los delays que comentas (y quitarlos para probar a ver que ocurre).
¿Es el de UpdVdpLay, justo despues del HALT?

Efectivamente,
ahí añadí el chequeo del Subsystem y si NO tiene el bit 7 a uno le hago esperar, luego tras el mapeo del area I/O es donde he puesto
el pshs x,y,d y luego el puls x,y,d para retrasar algunos ciclos ...
saluods!