|  Post Your Message | |
| |
| | Previous Messages | Posted By
BSZ
on 2024-11-10
08:23:06
|  Re: Building the Giana Sisters Sources
Moreover, it is a strange wait, with a simple JSR+RTS you could wait 12 cycles. (I think.  )
@ytm: On plus/4, the peripherals run on the (variable) clock of the CPU, there is no clock-stretchnig like on C128.
|
|
Posted By
Csabo
on 2024-11-09
18:37:06
| Re: Building the Giana Sisters Sources
Delay (done quick-and-dirty), to get the horizontal raster positioning within the IRQ just right. ASL $#### takes 6 cycles, which is the second longest "pause" you can do (7 is the most cycles). The address does not matter, but $FF3F is a safe memory location, no side effects (other than the RAM continues to be paged in, but we'd want that anyway). You can see the last one being commented out, that was "too much"
In other words, it doesn't matter what the CPU does there as long as it does something (and doesn't mess up the 3 pre-loaded values in A, X and Y). Placing 3 NOPs in place of one ASL would do the exact same thing as well (since one NOP is 2 cycles).
|
|
Posted By
ytm
on 2024-11-09
15:12:19
| Re: Building the Giana Sisters Sources
Does anyone know what's the purpose of several ASL $FF3F instructions here? Game seems to run from RAM anyway, so all I see is delay. Are there any side-effects? On C128 read-modify-write instructions on I/O area would cause clock stretching in 2MHz mode.
main_irq3
sta IRQ_save_a
stx IRQ_save_x
sty IRQ_save_y
lda $ff07
and #$f7
level_pixel_shift_irq
ora #0
level_ff13
ldx #0
level_ff14
ldy #0
asl $ff3f
asl $ff3f
asl $ff3f
asl $ff3f
asl $ff3f
asl $ff3f
asl $ff3f
;asl $ff3f
|
|
Posted By
Mike
on 2024-10-27
06:07:49
| Re: Building the Giana Sisters Sources
Hi,
this is great. I will wait your makefile then. Hopefully it will word for me as Mac User.
Regards,
Mike
|
|
Posted By
SukkoPera
on 2024-10-27
05:21:13
| Re: Building the Giana Sisters Sources
The LDA$1974 is a small fingerprint to identify the memory location where the compression code ends. When this fingerprint is missing, the loader will not start the loaded mi.prg, just turns the border red and dies.
Ooooh, this was the right clue! There was a problem in the commands I was issuing since $ is a special character in my shell, it is used to identify variables. Of course I was aware of that and I had "escaped" it but in the wrong way. I was using "$$" which seemed to do the job, but then it would be replaced with the shell PID behind the scenes  . Apparently the right syntax is "\$$". Now it works! I will post a complete Makefile ASAP.
Thanks for the help!
|
|
Posted By
TCFS
on 2024-10-27
04:26:46
 | Re: Building the Giana Sisters Sources
The "game data is corrupt" message can appear:
- when the loaded level data does not match the current level counter (you were renaming the level files to reach later levels under the name of level 1)
- when you started the main executable standalone, without the proper loader.
The first file on the disk just detects your hardware and puts a small irq loader to $700 corresponding to your current configuration. (Thanks, siz  ) The presence of the loader is mandatory as the main game module immediately starts loading the data of the first level.
I added a small code to check the presence of the loader and display an error message when something is wrong, instead just jsr$0700 assuming that the loader is there and gives a big crash to the player after calling a BRK opcode.
...one more thing:
compile the source under "main_u.prg" and then exomize the final prg using:
..\exomizer\exomizer sfx $1010 -t4 -n -o mi.prg main_u.prg -f "LDA $1974"
The LDA$1974 is a small fingerprint to identify the memory location where the compression code ends. When this fingerprint is missing, the loader will not start the loaded mi.prg, just turns the border red and dies.
|
|
Posted By
Mike
on 2024-10-26
10:11:33
| Re: Building the Giana Sisters Sources
Hi,
this is very intersting because i was just before to try it.
|
|
Posted By
SukkoPera
on 2024-10-24
19:57:36
| Building the Giana Sisters Sources
I'm trying to build the Giana Sisters sources that were released by TCFS.
I have installed Macroassembler AS 1.42 Beta.
I build the program with:
asl -cpu 6502 -o giana.p -L -u -x giana_sisters_source.asm
p2bin giana.p giana.prg -l 0
The resulting giana.prg at this point will load and start correctly in VICE/YAPE but then it will complain that "game data is corrupt". I guess this is to be expected, as I'm not providing any game data at all at this stage.
So I go on with the given instructions and run exomizer as recommended:
exomizer sfx $1010 -t4 -n -f "LDA $1974" -o mi.prg giana.prg
The resulting mi.prg at this point will NOT work anymore in VICE/YAPE, it will cause a CPU jam (it will still work if I run exomizer with SYS or BASIC, though). I am not sure this is to be expected but never mind, I just go on and update the mi.prg file in the image.
The resulting image starts up correctly and starts to load. A random monster from the game will enter from the bottom left of the screen, moving right, and will proceed until about one third of the screen, then the screen will just turn fully red and the whole thing will just hang there.
Has anyone ever tried to do this? What am I doing wrong?
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
