Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > cleaning up between demoparts
2005-08-06 15:58
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)

 
... 20 posts hidden. Click here to view all posts....
 
2011-07-12 22:42
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. ;-)
2011-07-13 05:42
Oswald

Registered: Apr 2002
Posts: 5094
how about copying the kernal routine to the ram below, and patching the vic reg writings ?
2011-07-13 17:52
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.
2011-07-13 18:00
Oswald

Registered: Apr 2002
Posts: 5094
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.
2011-07-13 20:54
chatGPZ

Registered: Dec 2001
Posts: 11386
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\)
2011-07-14 14:31
Stainless Steel

Registered: Mar 2003
Posts: 966
Cleaning up after a demoparty must be a worse job than jizzmopper in a stripjoint :-)
Previous - 1 | 2 | 3 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Holy Moses/Role
iAN CooG/HVSC
deetsay
DJ Space
Unicorn/TWA
t0m3000/hf^boom!^ibx
iceout/Avatar/HF
Steel/SCS&TRC/G★P
Guests online: 100
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top Musicians
1 Rob Hubbard  (9.7)
2 Mutetus  (9.7)
3 Jeroen Tel  (9.7)
4 Linus  (9.6)
5 Stinsen  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.064 sec.