| |
H.O
Account closed
Registered: Oct 2002
Posts: 70 |
cleaning up between demoparts
One of favorite projects (or maybe not) -- I am currently trying to integrate some code made by others (basically, I am planning to do a release of some unreleased demo parts)
Problem is, one of the demo parts seems to be assuming a helluva lot of the c64. If I link the parts together, and do a soft reset I can start the last part with no problems.
But, if I have run some other demo part first, this part will just freeze up.
But, since I dont want anyone to have to use soft reset inside a demo, I want to clean up so that the final part works fine. Currently I am using the following calls:
sei
jsr $ff5b ; Initialize screen editor
jsr $fda3 ; Initialise I/O
jsr $fd15 ; Restore Kernal Vectors
lda #$00
ldx #$00
cleanme
sta $d800,x
inx
cpx #$28
bne cleanme
cli
Anything else that I can do? I am trying to avoid my worst case scenarios (which are releasing each part as they are as standalone applications, or rewriting most of the code that I didnt do; none af them are very appealing to me)
|
|
| |
Monte Carlos
Registered: Jun 2004
Posts: 355 |
First check, which $01 value is assumed by the foreign (F) part.
Than make sure, that the init routine of F doesnt disturb the
irq of the part before, else write an intermediate irq routine.
Some codes initialize the irq and clear $d019 directly. Thats wrong, because while initiating, an irq request may occure.
This one is waited to be fulfilled, until the next cli.
If you start such a part, if there is tricky raster timing in it, it works sometimes and sometimes not, dependent on the framepos when the part is started.
Make sure, that the cli after initialisation of this part is executed always at the same time relative to the first irq.
Or place the lsr $d019 directly before the cli.
If the part disables nmi by $dc0d make sure, it does an bit $dc0d additionally, because else exacly one nmi may be executed after.
|
| |
TDJ
Registered: Dec 2001
Posts: 1879 |
By the end of my 'active' coding career (circa 1994) I had it all figured out, knew exactly what to set and which routines to call to clean the system. The demos I released later on were oneparters, so there was no problem at all.
Last year WVL/Xenon, Jayce/Focus & me were working on the WWE demo 'Primal Scar', which is a one-filer with three parts, thus there was a need for a clean exit.
We failed. For some reason 3 of the last few remaining Dutch coders, including one who's amongst the absolute best in the world, couldn't get the job done. Hence we competed with a 'preview' version, and Jayce had to spend some extra time at home, linking it all together.
We suck. What's your excuse? ;)
|
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
This might help.
I had the same problem sometimes..
Before starting everything..
JSR $FF81
JSR $FF84
JSR $FF8A
Hope it´s any good.. |
| |
Vai
Registered: Mar 2002
Posts: 50 |
Quote: This might help.
I had the same problem sometimes..
Before starting everything..
JSR $FF81
JSR $FF84
JSR $FF8A
Hope it´s any good..
If I'm correct those are the same as jsr $ff5b, jsr $fda3 & jsr $fd15 ... only they are direct. |
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
Quote: If I'm correct those are the same as jsr $ff5b, jsr $fda3 & jsr $fd15 ... only they are direct.
Haha,you are absolutely right. 8)
Stupid me... |
| |
V-12
Registered: Nov 2003
Posts: 206 |
are you cleaning also screen and colours ? you can turn off the screen ($d011) or just use kernal routines. |
| |
tasche
Account closed
Registered: Apr 2004
Posts: 12 |
remember the Kernel-Bug in $fd15 !!!
;----------------------------------------------
FD15 A2 30 LDX #$30 ; low FD30
FD17 A0 FD LDY #$FD ; high FD30
FD19 18 CLC
FD1A 86 C3 STX $C3
FD1C 84 C4 STY $C4
FD1E A0 1F LDY #$1F
FD20 B9 14 03 LDA $0314,Y
FD23 B0 02 BCS $FD27
FD25 B1 C3 LDA ($C3),Y
FD27 91 C3 STA ($C3),Y ; this writes into RAM, which
; can kill placed Data !!!
FD29 99 14 03 STA $0314,Y
FD2C 88 DEY
FD2D 10 F1 BPL $FD20
FD2F 60 RTS
;---------------------------------------------- |
| |
Oswald
Registered: Apr 2002
Posts: 5076 |
when will all pc headed dude finally learn that:
kernel != kernal
anyways, the code clears the C bit, and I dont see instruction that changes C until the bcs takes place.
|
| |
tasche
Account closed
Registered: Apr 2004
Posts: 12 |
@oswald:
till it could have been a spelling mistake??
i might be wrong, but kernal is the name of the c64 kernel, coz i learnt in former days, that in computer engineering, the kernel is the core of an operating system, or am i wrong?
btw: this routine is 100% writing into the ram under the rom. regardless if c is set or not. |
| |
Honesty
Registered: Jan 2003
Posts: 117 |
Hm i tried it to be honest...
I filled area from f000 to ffff with 0 and then with ff
and after switching of the rom there is only ff...
|
| |
tasche
Account closed
Registered: Apr 2004
Posts: 12 |
@honesty: do you have a non-moded rom? means, the posted routine is the same, as in your rom? coz if so, u must have the io-vectors in your ram, located from $fd30 to $fd50. |
| |
Oswald
Registered: Apr 2002
Posts: 5076 |
taschentechno:
the rom at e000-ffff is called KERNAL. The name "kernal" has nothing to do with "kernel" it just sounds similar. Kernal can be looked at as the WHOLE OS of the c64.(or show me the core of the OS where it is ?) Then we got the basic rom at a000-c000.
"btw: this routine is 100% writing into the ram under the rom. regardless if c is set or not."
thats sure, but if C is not set then then it wont alter the information stored in the ram (lda (c3),y sta (c3),y). if c is set it will. |
| |
tasche
Account closed
Registered: Apr 2004
Posts: 12 |
@oswald:
hmm... ok, but it seems, that i differ with you by the meaning of core-routines (:
back to the real problem:
i thought of using the routine by its jump-vector, as Tch posted. so there wouldn't be any requierment in thinking, if the io-vectors are set or not.
this routine just reminds me, when i used it years ago, i had this ram-writing problem and nearly got a headache, till i found this lousy bug. ^^
|
| |
Stryyker
Registered: Dec 2001
Posts: 466 |
If I have a really troubling piece of code I hand reset any needed vectors, fix the stack pointer, fix both CIAs and VIC II so the proper interrupts happen then test. |
| |
midiland
Account closed
Registered: Nov 2004
Posts: 4 |
Just cheat....
Set the cartridge auto start at $8000 and then do a soft reset :D |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
@Oswald:
You're wrong, the LDA ($C3),Y STA ($C3),Y will read from ROM and write to RAM. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
H.O: If you have access to the source code of the parts that won't work you could insert some "logging" to find out where it fails, e.g. by setting a byte somewhere in the memory to some different values at some different places in the code, and then look at which value it has when it crashes. |
| |
Oswald
Registered: Apr 2002
Posts: 5076 |
graham: damn, I was blind :-/ |
| |
tlr
Registered: Sep 2003
Posts: 1762 |
How about the code below?
I pasted this together from my implemention in the Over5 code, so I haven't tested it and may have forgotten a line or two, but it should mostly work.
It will give you a fairly good idea of what gets initialized during startup.
; Do complete reset, load basic program, and then do RUN.
;
sei
cld
ldx #$ff
txs
jsr $fda3 ;Init interrupts /d418=0
;*** $fd50 Init Memory Subst (to avoid the annoyingly slow memory test, and avoid trashing one byte at $a000) ***
lda #0
tay
lp1:
sta $0002,y
sta $0200,y
sta $0300,y
iny
bne lp1
ldx #$03
lda #$3c
sta $b2
stx $b3
ldx #$00
ldy #$a0
jsr $fd8c ;Set MemBounds
;*** end $fd50 subst
;*** $fd15 Init Vectors subst (to avoid trashing of memory at $fd30) ***
ldy #$1f
lp2:
lda $fd30,y
sta $0314,y
dey
bpl lp2
;*** end $fd15 subst
jsr $ff5b ;Init video
cli
;*** Init Basic! ***
jsr $e453 ;Init basicvectors
jsr $e3bf ;Init basic zp + other stuff
; <---- HERE is probably enough initialization for most programs!
;* Set stack for basic *
ldx #$fb
txs
;* Init I/O for basic
jsr $ffcc ;CLRCH
lda #0
sta $13 ;Keyb input
jsr $ff90 ;Program mode
;* do "LOAD"
;* setup end address in $2d/$2e
lda #<end_of_prg
ldx #>end_of_prg
sta $2d
stx $2e
jsr $a68e ;set pointers to program start
jsr $a533 ;relink basic program in memory
;* do "RUN"
jsr $a659 ;do run.
jmp $a7b1 ;Basic mainloop...
|
| |
MagerValp
Registered: Dec 2001
Posts: 1065 |
Good stuff, especially for us xfer system coders!
|
| |
Kaizen
Registered: May 2009
Posts: 24 |
Hi,
if I want to init only the screen editor leaving unchanged VIC registers, could I use JSR $E51B instead of JSR $FF5B os there are contraindications (e.g. Kernal modified or so...)?
THX. ;-) |
| |
Oswald
Registered: Apr 2002
Posts: 5076 |
how about copying the kernal routine to the ram below, and patching the vic reg writings ? |
| |
Kaizen
Registered: May 2009
Posts: 24 |
If I call $FF5B, and this address then will call $E518.
The first subroutine which get called at the address $E518 is the one that starts at $E5A0 and it's the one that sets the values of the VIC, but I want to bypass it.
So the idea is to do a direct call to the routine that stars right after $E51B.
But I've a doubt about the compatibility.
I don't that if I call directly the routine at $E51B could create problems in case of modified kernals (ie: speed dos or similiar, which I assume using a kernal ROM modified, so it could possible a system crash, in this case).
Or not?
THX. |
| |
Oswald
Registered: Apr 2002
Posts: 5076 |
it may be incompatible, but a stock rommed c64 is considered and used as the standard anyway, so I dont see it as a show stopper. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11293 |
from my experience, you almost always want to implement your own version of the reset routine. especially from a demo point of view the kernal routines suck hard.
(wtf, i read "cleaning up between demoparties" ... /o\) |
| |
Stainless Steel
Registered: Mar 2003
Posts: 966 |
Cleaning up after a demoparty must be a worse job than jizzmopper in a stripjoint :-) |
