horizontal scrolling on ST

[AtariZoll]

I don't have experience with Easy Rider. Disassembled Prince of Persia with Devpac 3, and TOS 1.04. It took lot of time to correct all not correct disassembled parts - must determine for instance all variables, which often are detected as code .

Devpac disassembles in way: if some location is inside defined area for disasm. it will be referred with label, otherwise as absolute address.

Even if you did right all addresses and labels, problems may happen when changing code length. For instance in TOS 1.04 there is segment where you must keep it's length, because processing code is made for that concrete length. Of course, it is possible to make it work with changed segment length, but it needs some time (a lot maybe) to understand how it works. Similar was on at least one place by Prince of Persia. All in all reassembling is hard job.
Ah, and i disassembled unfinished game Sideways too. Wanted to change it's working RAM location, but never succeed - it seems that there are some parts sensitive on exact RAM position in graphic output part. I say it, because reassembling on same location was OK.
And I did not change anything.

[Zamuel_a]

One of the first things that is done in the Giana sisters game is that it copies the source code to different locations in memory and then in the code there are JMP $123456.. and such instructions. So the code is not even at the location I see it at in devpac when it is running. Seems like the programmer wanted to make sure noone hacked this Just adding a NOP somethere in the code makes everything crash since all addresses will be wrong. Variablers are one thing, but if the actual code jumps to fixed addresses it's a bit messy.

[npomarede]

Hello
I haven't used easyrider, but I used other 68000 disassemblers on Amiga, and one of the goal of an "advanced" disassembler is to be able to turn absolute addresses into labels, so that the resulting code can be modified and compiled again (you can consider that each absolute address XXX is replaced by a label LXXX if you want to do it yourself, but it can be tedious for large program). I'm sure someone can give the name of a disassembler for Atari that replace absolute addresses with labels (or give the correct option to do it with easyrider).

Nicolas

[Zamuel_a]

From what I can see, the big problem is not the variables since they are at a fixed address < $FFFF so if the code is above that, it's fine.
The problem seems to be that the actual code is moved around and executed from different fixed addresses:

This is a part of the beginning of Giana sisters:

Code: Select all

      LEA       L0008(PC),A0

      LEA       8.W,A1
      MOVEQ     #23,D0 
L0003:MOVE.B    (A0)+,(A1)+ 
      DBF       D0,L0003

      LEA       $140.W,A1 
      MOVEQ     #95,D0 
L0004:MOVE.B    (A0)+,(A1)+ 
      DBF       D0,L0004

      LEA       $3BE.W,A1 
      MOVE.W    #3471,D0
L0005:MOVE.B    (A0)+,(A1)+ 
      DBF       D0,L0005

      LEA       $10000,A1 
      MOVE.L    #71014,D0
L0006:MOVE.B    (A0)+,(A1)+ 
      SUBQ.L    #1,D0 
      BNE.S     L0006 

      LEA       $48000,A1 
      MOVE.L    #103168,D0
L0007:MOVE.B    (A0)+,(A1)+ 
      SUBQ.L    #1,D0 
      BNE.S     L0007 

      JMP       (A0)

The first line L0008 is start of real code so the following routines copies it into several locations.
For examle the last routine here copies 103168 bytes from the code and put it at $48000

if I make any modifications into that part, the number of bytes will not be 103168 anymore and any jumps to other fixed addresses in this area will be corrupt. So it's a big mess

[AtariZoll]

In attachment is Great Giana Sisters code + start data, after all data moving, so code is at final place (it is not rare case at all, to move and mess around with code, data before real start). Starting address is 8 - so at very bottom of RAM - there is some protection data too, + some vectors, traps set for game.
For execution you need: move #$2700,sr ; lea $2500.w,sp ; jmp $4048.w .

GGS1.ZIP

[Zamuel_a]

I dissambled it and it assembles without any problems, but crash when I tries to run it. I tried to put your 3 lines of code at the beginning. It starts with some dc.b statements. How can the code know that it should be located at address 8? I tried to put in ORG $8 at the beginning but it crasched anyway.

[AtariZoll]

I dissambled it and it assembles without any problems, but crash when I tries to run it. I tried to put your 3 lines of code at the beginning. It starts with some dc.b statements. How can the code know that it should be located at address 8? I tried to put in ORG $8 at the beginning but it crasched anyway.

It starts with moveq #3,d0 ; nop ( maybe here was protection - I still did not see STX original of this game) at adr. $4048 . Then some bsr ...
There is code lower, you need to check where exactly it starts ( below $800 for sure, but there are data parts too) .

Code knows nothing in fact - code is very dumb thing . You just must put it on same place from where is dumped. Then everything will be at right address.
You should not disasm all it - main thing is to find exact area of code self, and threat all other as data by disasm. i remember that I needed to write on paper all those data parts, and type in it all when disassembled something larger.

For testing, you should use Steem Debugger - then can trace errors pretty comfortable. Try first to run what I posted. There may be some extra initialization needed. And maybe floppy image of game too.

[Zamuel_a]

Before that line with moveq #3, there is other code that is not an BRA och RTS or something, so that code must be directly before $4048

puting in an org $4048 before those lines made it krasch anyway so it doesn't work. I need a fully dissambled version that is runnable from Devpac. The one I dissambled runs without any problems, just that the relocation of the code makes it a mess.

Pacmania was so much easier. The code itself was handled in a easy way with dynamic labels and so on. It was just the work of understand what was going on

The best had been to have a good dissambled version of Giana Sisters on Amiga since it's more or less only the scroller that is different between the versione (and music ofcourse)

[AtariZoll]

Actually, I don't know how to disasm code placed in so low RAM with Devpac. It is easy with some TOS excutable, or even with ROM code, or some code placed in higher RAM area. But this (and many other games) have code and data placed very low, and you can not have it in original location while running Devpac. Very possible that with Amiga v. will have same problem.
Maybe best is to place it at $100008 , and disasm. And by reassembling just use org 8 (some parts will be needed to correct manually, likely). Launcher should do all needed initialisations - so loading and moving GG1 to correct place (best to load packed, and depack to end dest) , then set IR, SP and perform jump to $4048 .

I would not care about code before $4048 - it is anti-hacker part, and really not needed for game to run. You can even restart it by simple jmp $4048 during play.
In any case, you started something not easy, so be prepared that will take lot of time

[Zamuel_a]

Hehe, I know it's not easy, but the game version I dissambled atleast runs without any problem from Devpac. I guess I can try and take that code and place the code at the correct places. I would need a way of counting the bytes in the code, but maybe Easyrider can show that for me or if steem debug maybe could show it.

[AtariZoll]

As said, there is no STX of original. And not even some crack close to original. What I see is all based on same (Bladerunners or BOSS crack), and it needs 1MB RAM because later levels are in RAMdisk (about 240KB). So, org. floppy read part is already changed.
It works basically as I described - depacks initial RAM content in low RAM and RAMdisk content above 512KB, and starts game.
Start is as regular PRG. However, I'm sure that original is with autoboot floppy, and reads later stages via own floppy code (no other way, as TOS workspace is used by game).
I can post you floppy image which will start via autoboot, and first level will work. Reconstructing org. floppy code would be harder, but I think that is is enough for start. And it will run with 512KB RAM only too. Hopefully one day STX image will appear.

And I think that you have same version - there is not other, so any disasm. of intermediate state is not much useful. You need code on final location. There is some disassembler in Steem Debugger, but I found it not much useful (maybe did not try enough hard).

[Zamuel_a]

It is the version cracked by BOSS that I have. It assembles without problem, but the code location is messed up so I would need to relocate it to the correct positions first, which I guess won't be easy.

[AtariZoll]

It is the version cracked by BOSS that I have. It assembles without problem, but the code location is messed up so I would need to relocate it to the correct positions first, which I guess won't be easy.

And then you will get what I posted here
Code location is not really messed up. You can't load in so low RAM directly, so need first to load in higher RAM and then copy (or depack) from it down, with interrupts disabled. It is possible that it is done in multiple segments, if there are holes in game's RAM usage.
And it is not so hard, when you have some practice with such things.

[Zamuel_a]

The problem is that I can't touch anything before I have moved it around so that it doesn't relocate the code. I guess I must manually move it somethere and change all adress calling from a fixed address to a dynamic one.

Most of the code is not located below $FFFF anyway, so I don't understand why they move it around.

I guess it's more or less impossible to finish this project. I can't sit in steem debug and check the final address on each instruction in the entire game and since I need all the game code to be accessible it would be an enormus job to do it.
I checked some addresses with steem debug to try and located it in the code, but I couldn't find the instruction anythere in the code so I don't know what they are doing. Steem said that the instruction or.b #$ff,d2 was at that address but there is no such instruction in the entire code. It wouldn't had made sense anyway since there was no other instructions after this anyway, only dc.b statements.

[AtariZoll]

I don't see why you have problems ... Anyway, I will post you launchable version,. with source tomorrow.

The reason for this kind of RAM usage is very simple - they wanted that it work with 512K RAM. Placing code and data at very low address gives more RAM for game. But then you can not use GEMDOS for floppy access and some other functions. It is not big problem, since can make custom floppy code in few hundred bytes.
With GEMDOS at least some 40KB (depends on TOS version) RAM would be allocated.

Another reason why game coders like low RAM is possibility to use short addressing - when data/code is in lowest 32KB . Shorter code and faster execution.

[Zamuel_a]

The problem with the version I have is that as soon as I change anything it crasch since all the addresses will be wrong. What I need is a source for the entire game that uses dynamic addresses for the source code so that I can add, remove code without crashing

[AtariZoll]

I made floppy image with simplified start - you will get final code on final location right after depacking. There is RAMdisk with level datas, as it is needed right after start (load via trap #3). There is still original floppy code at $5B4, what is not used with this RAMdisk based crack (and all are same in fact, just some use more packing). And table with file locations on floppy is missing - should be at $F4E. I don't think that it is worth to make some custom floppy load, or trying to understand org. code and make image, as you plan to use regular GEMDOS file access, I guess. Trap #3 is simple: d0 is file number - 0-$31 (34 files total), and a4 is destination address. Source included ... I have all files extracted separately too .
Should be 100% OK - I played it until end couple times.

GGSFR.ZIP

Good luck with disassembling and reassembling

[Zamuel_a]

Hmm, I can't get it to work. If I autostart the ST image, the game starts, but from desktop I can't see any files on A: and from devpac I get 3 bombs if I run the .S file and have the floppy loaded into A:

[AtariZoll]

There are no regular files on floppy. Loading goes via XBIOS 8 - sector loadings from floppy.
In S file (source) says that it goes in bootsector. It must be executed in supervisor mode - what is case by autoboot. And you need to strip off TOS exec. header.
Should be clear - I added comments for every stage.

[Zamuel_a]

Ok, yes adding supervisor mode and low res started the game, but still, this is just the game. There are no prg files for me to dissamble! In the BOSS version I found, everything was depacked and placed in memory so I can see all code directly. The problem there is just that they move around the code at the beginning so if I makes any changes, I must make sure my change take the same amount of bytes as the original.

[AtariZoll]

I think that we don't move ahead ... You got final placed, complete game code with autoboot launcher - and it is closest to original, what I can make. That BOSS crack does in fact same, and it is easy to make my version to load that 2 packed parts via GEMDOS and with regular TOS executable. But after all movings, you will be on same, very low placed code what is not easy to disasm.
There is no PRG file in this game original - and I say it even not seeing original, but there are clues - like low placement and custom floppy code. Not to mention that there is no any TOS call in code. This is game not using TOS. It autoboots from floppy with RAW machine code, and performs not any TOS calls. And it would be not possible because game uses TOS workspace. So, forget PRG and focus on code and data at address 8 . There is everything you need to disasm.

I don't think that you must maintain same code len. if disassemble it properly. There are some parts possibly, where len must be kept, but it is usually only 1-2 segment, not too long. What is a must is to find all data segments, and give them as data when entering parameters for disasm. It may take several hours to find it all. If you include complete area at 8, you should get labels for all RAM access in low area too. Then reassembling it for some higher address should work fine. Doing TOS relocatible exec is maybe possible, but it depends on code, and may need lot of small changes, so could be not worth of effort.

[Zamuel_a]

I think I have to give up this project since it seems to be to difficult. I have only used Easyrider and it needs a file to dissamble.

[ljbk]

Hi !


Going back to the sync switches business and the impact in horizontal scrolling, i have just found out that i can detect via SW not 2 but 4 different wake up states for my Atari 1040 STF Rev. C !!!

The first difference is detected like before via the effects in the updates of sync register at address $FFFF820A.
There are two sets of timings: the early one and the late one. Let's call them early_820A and late_820A.
The reason for this is that the FFFF820A register is located only in GLUE that works at 8 MHz directly with the CPU, so it can be updated at CPU cycles 0, 2, 4, 6, ... so the preceding multiple of 6 instruction as impact on the timing of the update inside GLUE afecting the generation of the Display Enable signal that will then trigger the Shifter and the MMU.
That is also confirmed by the fact that only data bits 0 and 1 enter the GLUE allowing the updates of significant bits in FFFF820A and FFFF8260: the registers that are needed to produce the VSYNc, HSYNc and DE signals.
The MMU on its own will only allow the CPU access to the main memory, Shifter registers and internal counters registers (including the video address registers $FFFF820x) on mutiple of 4 cycles. This can be on cycles 0, 4, 8, 12, ... or 2, 6, 10, 14, ...
On the other multiple of 2 cycles, the MMU is reading data for the Shifter if Display Enable is active: 2, 6, 10, 14, ... or 0, 4, 8, 12, ...

As to go synchro code we sync with the $FFFF8209 register, we in fact sync with the MMU.
In one of these two FFFF820A set of timings, we can see that the TOS screen appears 2 pixels shifted to the right from RESET. This means that the MMU is two CPU cycle late in providing the data to the Shifter compared to the other FFFF820A set of times. So if we sync with a delayed MMU, we have to do the FFFF820A changes 2 cycles ealier in GLUE for this set of timings. And that is exactly what happens, the same effects are available but we have to do everything 2 CPU cycles earlier.
So we have:
- early_820A that corresponds to the old wake up state 1 where the screen appears shifted 2 pixels to the right;
- late_820A that corresponds to the old wake up state 2 (the most frequent with my machine) where the Nostalgic Main Menu does not work correctly;

The second difference is detected via the effects in the updates of resolution register at address $FFFF8260.
There are three sets of timings: the early one, the middle one and the late one. Let's call them early_8260, middle_8260 and late_8260.
The reason for this is the fact that this register consists in fact of two registers: the GLUE_8260 and the Shifter_8260.
The GLUE_8260 can be updated every 2 cycles and is used to produce the VSYNC, HSYNC and DE signals.
The Shifter_8260 can only be updated every 4 cycles when the MMU allows it: on cycles 0, 4, 8, 12, ...
or cycles 2, 6, 10, 14, ...
So we can have at least for periods of 2 cycles:
Glue_8260 / Shifter_8260:
Low / Low
Low / Med
Low / High
Med / Low
Med / Med
Med / High
High / Low
High / Med
High / High
So depending if the updates to $FFFF8260 are done at the same time inside GLUE and the Shifter or are 2 cycles later in the Shifter, we have at least two different situation that combined with a possible delay between the MMU and GLUE (see above) lead to at least 3 different set of timings for effects with updates to $FFFF8260 register.

Early_8260, middle_8260 and late_8260 set of timings allow the same effects but with 2 clock cycles between them of difference.

So we have the following combinations:

early_820A / early_8260 that corresponds to wake_up state 1 (dificult to get with my machine)
early_820A / middle_8260 that corresponds to wake_up state 3 (less common form of wake_up state 1)
late_820A / middle_8260 that corresponds to wake_up state 4 (less common form of wake_up state 2)
late_820A / late_8260 that corresponds to wake_up state 2 (the most common with my machine)

I attach a program that can detect the current wake up state.

There are other wake up states but that can not be detected by SW because they correspond to discrepancies between the internal cycle of the Shifter that works at 32 MHz and the wake up status of GLUE and the MMU.
An example of this is the funny Spectrum 512 dots. It depends if the write of the color register (ordered to the Shifter by the MMU in the CPU R/W multiple of 4 CPU cycle) happens before the color register is read to produce the RGB signal. In most cases the video signal was already produced so the color only really changes at pixel + 1. But sometimes it already occured so you get the new color for pixel 0 (funny color) or as the GLUE HSYNC/DE signals are not as precise as the Shifter clock, you get something in the middle (sometimes correct color / sometimes not). These flashing pixels or 16 pixels vertical black bars (see below) due to diferente internal Shifter cycles and relative GLUE unprecision (compared to the Shifter) can also be triggered by the motor of the drive to be active or not.
Another example of internal Shifter cycle is the type response and the timing of it to resolution changes while Display Enable is active:
- what to do if N pixels of the 16 where outputed in Low resolution and now we get High ?
- what to do if N pixels of the 16 where outputed in Low resolution and now we get Med ?
- what to do if N pixels of the 16 where outputed in Med resolution and now we get High ?
- what to do if N pixels of the 16 where outputed in Med resolution and now we get Low ?
- what to do if N pixels of the 16 where outputed in High resolution and now we get Med ?
- what to do if N pixels of the 16 where outputed in High resolution and now we get Low ?
N can be 0, High resolution shifting and ouputing occurs at 32 MHz,Med resolution shifting and ouputing occurs at 16 MHz and Low resolution shifting and ouputing occurs at 8 MHz.
Experience shows that the data comming from the MMU goes to internal register(s) before it is loaded to the ouput register(s) where it is shifted every 1, 2 or 4 Shifter cycles.
Experience also shows that if less than 4 words are required to complete the 4 words needed to produce Low resolution bitmap, the screen will start earlier by 12, 8 or 4 cycles depending on the words needed from the MMU.
Experience also shows that it is possible to force that buffered data out at least with some wake up states by means of the stabilizer (wake up 2 at least), forcing the Shifter to wait for new fresh 4 words from the MMU before displaying the bitmap.
There are some other possible impacts of having these old words inside the Shifter like vertical black bars: 16 pixels or bitmap, 16 black pixels. Again, this depends on internal Shifter start/reset cycle and it can not be detected by the SW. It can happen that for the same wake up state (1, 2, 3 and 4) we can have situations where the extra words at start lead to screen shift, lead to vertical bars, screen shift for line N and a diferent shift for line N+1, vertical bar for line N and a 16 pixels shifted vertical bar for line N+1 ...

There are at least 16 sweet spot timings in a normal hozintal line (512 cycles) where you can do effects: 5 with FFFF820A and 11 with FFFF8260 like Left Border, Right Border, stabilizer, BLANK line, 0 bytes line, start like if 60 Hz, end like if 60 Hz ... and i am counting of 1 for the dozens of 71/50 or 60/50 switches for each case.

For the purpose of 4 bit sync scrolling for normal screen, i have seen it work with wake up state 2 (most of the times), wake up state 4 (always), wake up state 3 (only once).
I have never seen it work for wake up state 1 (at least -4 shift never worked).


Sorry if you found this uninteresting.


Paulo.

[Dio]

Not at all. Next time I have the logic analyser on the ST I'll use your program and verify that the four wake up states correspond to the four different DE to screen start latencies that I observed last time I was investigating this issue.

I'm not certain there can be discrepancies because of the higher clock inside the shifter though. As each of the lower frequency clocks is dependent on the higher frequency one, synchronisation seems likely to be automatic to me. However, it may be clock skew effects - each fourth tick of the 32MHz clock must be a a few gate delays ahead of the 8MHz clock - assuming the clock dividers are just D-type flipflops in Shifter and MMU, the 8MHz clock is probably about 50ns behind. I haven't been able to get an exact figure for the skew on the analyser though - its resolution is only about the same as the skew, I really need a GHz digital scope to measure it properly.

Experience also shows that it is possible to force that buffered data out at least with some wake up states by means of the stabilizer (wake up 2 at least), forcing the Shifter to wait for new fresh 4 words from the MMU before displaying the bitmap.

There must be a simpler way the buffered data is cleared than just the stabiliser. Consider the 158-byte line case - that always flushes the Shifter's buffer, not reading the last word and generating no last 16 pixels on the line but otherwise starting the next line normally, no 4-pixel shift. This is the one I've been trying to understand, because it's a simple and predictable case and it always works. If that one can be worked out I think it should shine a lot of insight on exactly how the Shifter buffer clear works.

[ljbk]

There must be a simpler way the buffered data is cleared than just the stabiliser. Consider the 158-byte line case - that always flushes the Shifter's buffer, not reading the last word and generating no last 16 pixels on the line but otherwise starting the next line normally, no 4-pixel shift. This is the one I've been trying to understand, because it's a simple and predictable case and it always works. If that one can be worked out I think it should shine a lot of insight on exactly how the Shifter buffer clear works.

I am sorry to contradict you but my experience shows that the 158 bytes line or any of its variants (like 184) does not clear the incoming words.
I have a stable Degas Elite bee screen with one 158 bytes line (rest is 160 bytes at 50 Hz PAL) in front of me and i can see that the first 16 pixels of the screen are using data from the end of the pic (left in the Shifter).
Wake up state is 2.
How did i create this ?
I have a program where i can test and switch between different situations by pressing a F key.
If i do a 71/50 switch with 20 cycles between them at pixels 277 and 297 (16 cycles before 60 Hz RB switch and 4 after), i will get a 160 bytes line and an unstable screen with the several lines with different shift starts and planes (different number of words left in the Shifter at the end of the screen).
If i switch to the same situation but with a 60/50 switch, i will get the 158 bytes line and a stable screen.
The problem is that the screen will not always show the same: it will depend on the number of words that have been left previously inside the Shifter. I managed 3 different screens. I don't know why i can't get the 4th.
If the Shifter incoming registers would have been cleared then we would get always te same stable screen.
Don' t ask me why then the next line does not start "shifted" but i assume it has to do with the 60/50 switch effect inside the GLUE (HSYNC / DE timings).

The same strange situation occurs with the 204 bytes line (no right border). The 2 words (from the +44 bytes read) are kept inside the Shifter and used at the start of the next line but the screen does not start shifted by 8 pixels to the left.
Also that line without stabilizer does not clear the words as i can get different stables screens coming from an unstable situation.

Paulo.