Random program techniques

Got a brilliant program idea? Let us know!

Moderator: MaxCoderz Staff

Post Reply
User avatar
driesguldolf
Extreme Poster
Posts: 395
Joined: Thu 17 May, 2007 4:49 pm
Location: $4080
Contact:

Random program techniques

Post by driesguldolf »

Some stuff I came up with during boring classes:

EDIT:The explanations are better now
- I was wondering how you can get extra RAM when prgramming apps because the free RAM (not used by the OS) is all scattered and not very large. Maybe you could just use $8000 - $9D95 and quit the app with a "reset defaults"? Even better you could swap in an empty ram page at $8000 - $BFFF and swap back at the end (after reading what wikiti says i guess that $40 is the os its ram and $41 can be freely used by an app?)
Another idea was that for 1 page apps you could just swap in your app as a ram page at $8000 - $BFFF? This way you can use smc in an app! I don't know yet if a rom page can be mapped as ram but this can be remedied easily.
A drawback (is it?) is that you can't use B_CALLs so you have to include some routines yourself

- Shuffling a list: have a list with values to shuffle and now go through every element of that list and swap it with another random element

EDIT:The idea preseted here doesn't entirely work (points at the next posts)
- If you use a costum isr try to avoid using the stack, that way you can use SP always during execution, or use the stack to save your values when an interrupt triggers then you can always use exx and ex af, af' don't worry about the speed, your interrupt isn't called so much that you won't notice the speed difference or a combination of both:

Code: Select all

interrupt:
	ld (savesp), sp
	ld sp, tempstack
	; Only save the regs you'll need
	push af
	push bc
	push de
	push hl

	; The main body

	pop hl
	pop de
	pop bc
	pop af
savesp		equ $ + 1
	ld sp, 0
	; Make port 3 and 4 happy here
	ei
	ret

	; Your temp stack, make it large enough
	.dw 0,0,0,0
tempstack:
This way you can use SP and exx, ex af, af' instructions without disabling the interrupts
Too bad this techinque won't make ti flash debugger happy (it expects sp-$FFFF to be the stack)

More random ideas are always welcome
Last edited by driesguldolf on Thu 07 Jun, 2007 10:03 am, edited 1 time in total.
User avatar
Jim e
Calc King
Posts: 2457
Joined: Sun 26 Dec, 2004 5:27 am
Location: SXIOPO = Infinite lives for both players
Contact:

Re: Random program techniques

Post by Jim e »

driesguldolf wrote:- If you use a costum isr try to avoid using the stack, that way you can use SP always during execution, or use the stack to save your values when an interrupt triggers then you can always use exx and ex af, af' don't worry about the speed, your interrupt isn't called so much that you won't notice the speed difference or a combination of both:

This way you can use SP and exx, ex af, af' instructions without disabling the interrupts
Too bad this techinque won't make ti flash debugger happy (it expects sp-$FFFF to be the stack
I'm afraid that won't work. This isn't like x86 protected mode, the interrupt handler pushes onto the stack, which is pointed by sp. If SP is not pointing to some ram the interrupt will not return to the place you wanted it to go. If it is pointing to ram, then memory before that point will be corrupted.

Now on the other hand, if you are in situation where the memory before sp is not vital, and it is safe ram, then you could use SP freely. The Best situation I can think of where this is applicable is in block fills using an unrolled push instruction to gain speed.

Generally though if you need sp, its best to DI or make sure its impossible for your code to get interrupted.
Image
User avatar
driesguldolf
Extreme Poster
Posts: 395
Joined: Thu 17 May, 2007 4:49 pm
Location: $4080
Contact:

Post by driesguldolf »

Crap, yeah your right, I see it now
well luckily you can still avoid the exx and ex af, af' and because the interupt isn't executed that many times the speed loss when using the stack isn't that great
King Harold
Calc King
Posts: 1513
Joined: Sat 05 Aug, 2006 7:22 am

Post by King Harold »

About that block fill.. it can corrupt the bytes directly under the buffer if you're in bad luck - an interrupt can trigger between the last push and the restoration of SP, when that happens (it won't in practice, but it's possible) the 2 bytes before the buffer will be trashed.
In fact, it can happen earlier when the interrupt has more pushes internally. and when there are more pushes in the interrupt it can also corrupt more bytes.

So listen to Jim E, DI before using SP
Post Reply