Vic Wolf

[Kweepa]

These are randomly generated, so yes there is
I can have 10,000 if I want!

[EDIT]
Improved, with start - white, doors - yellow, and exit - green.

[GreyGhost]

Oh, I thought you meant you just randomly drew them.

[nbla000]

WOW ! Impressive

[orion70]

Kweepa, could you implement your random maze generator in the program? And BTW, how about my idea to have separate (separately loaded?) routines for turn-based actions when you encounter enemies, find objects, etc.? Sort of a 3-D roguelike...

[Kweepa]

I am implementing it in-game. It's taking up 1k though

The source code will be available, so if anyone wants to take the engine and make a game with it they are free to

[orion70]

Thanks. Still trying to fit the whole stuff in the unexpanded machine eh?

[Kweepa]

Yup! It will be done! I need a better debugger than VICE's though

[Kananga]

Yup! It will be done! I need a better debugger than VICE's though

What's missing from VICE's debugger that you urgently need?

[Kweepa]

What's missing from VICE's debugger that you urgently need?

It's not so much what's missing, just how clunky it is.

Importing symbols. I don't even know how to do it, or if it's possible with output from CBM Prg Studio.

Setting and clearing breakpoints is not a one click/one keypress operation. Setting initial breakpoints when the game starts is very irritating, unless I've missed that in the docs.

There isn't an "auto/locals" window (which would display whatever memory the nearby instructions are operating on).

Code: Select all

lda $20                 [$20 = 0xfe / 254]
                        [A = 0xf7 / 248]
ldx ($88),y             [$88/9 = 0x1e00]
                        [Y = 0x02 / 2 / 'B']
                        [$1e02 = 0x01 / 1 / 'A']
                        [X = 0x60 / 96 / '+']

This could even show a 16 byte window around the destination, with the appropriate byte/word highlighted.

The biggest problem I have is that I am using callbacks and pushing the return address on the stack manually. VICE's step over function matches JSR and RTS calls, rather than just setting a temporary breakpoint on the return address, so if I try to step over a function that uses the callback, the debugger stops after the callback's RTS. I can work around it by rewriting the code to JMP to the return address at the end of the callback instead of using RTS, but it's a pain.

Code: Select all

callbackfn:
lda #40
sta $1e00,x
rts

funcwithcallback:
ldx #100
loop:
lda #<returnaddress-1
pha
lda #>returnaddress-1
pha
jmp (callbackfnaddress)
returnaddress:
dex
bne loop
rts

...
lda #<callbackfn
sta callbackfnaddress
lda #>callbackfn
sta callbackfnaddress+1
jsr funcwithcallback  // can't step over this - the PC ends up at returnaddress
...

What I would love to see is a debugger integrated with a code editor so that code stepping and breakpoints are in assembly source and not reconstituted assembly. I understand the problems... relocated code, compressed code, self-modified code, etc. A man can dream though...

[Mike]

Code: Select all

callbackfn:
lda #40
sta $1e00,x
rts

funcwithcallback:
ldx #100
loop:
lda #<returnaddress-1
pha
lda #>returnaddress-1
pha
jmp (callbackfnaddress)
returnaddress:
dex
bne loop
rts
...
lda #<callbackfn
sta callbackfnaddress
lda #>callbackfn
sta callbackfnaddress+1
jsr funcwithcallback  // can't step over this - the PC ends up at returnaddress 

How about using the following construct instead? By the way, what you're using is a vectored function call, not a callback. Callbacks are done by the OS on exit of an interrupt or kernal call in case a non-reentrant routine is necessary to perform work requested within an interrupt server. That also means the routine called back is usually at the same hierarchy level than the foreground process, which is clearly not the case with your 'callbackfn' - it is still two levels below the main function.

Code: Select all

vectoredfn:
lda #40
sta $1e00,x
rts

funcwithvectoredfn:
ldx #100
loop:
jsr trampoline
dex
bne loop
rts
trampoline:
jmp (fnvector)
...
lda #<vectoredfn
sta fnvector
lda #>vectoredfn
sta fnvector+1
jsr funcwithvectoredfn

I use the same construct for example within MINIGRAFIK for point plots: depending on whether hires or multi-colour pixels should be plotted, the address of the correct routine is first written to the vector, and then the point plot routine is JSR'd to through that vector, with a indirect-JMP 'trampoline'. When a line is drawn, this method eliminates repeated checks/branches to test that hires/multi condition.

Greetings,

Michael

[Kweepa]

Tomato, tomatoe
http://en.wikipedia.org/wiki/Callback_% ... ramming%29
If callback is redefined by the kernal, then phooey to it.

Thanks for the suggestion! I'll just self-modify the inner JSR, to avoid the trampoline. Saves a couple of bytes and a few cycles

[Mike]

I'll just self-modify the inner JSR, to avoid the trampoline.

As long as there is only one JSR into the sub-routine you can do that, of course. The trampoline allows for several 'users' of the vectored sub-routine, and you can have the vector in RAM, while the code is in ROM.

Actually, the spelling of kern_a_l in my posting above was a typo - I really meant kern_e_l as the core of an OS in general, and not only the CBM one. Again, Callbacks are issued by the kernel or an interrupt routine to do work which requires the kernel has been threaded out before, so there are no issues with non re-entrant routines.

That mechanism requires that the kernel knows exactly when it is about to re-enter the user program, with enabled interrupts, and nothing in the stack still amounts to kernel processing. In that situation, and when a callback is requested, the kernel jumps to the callback routine first, which itself now is able to do operations on the same hierarchy level than the user program, and which then handles control over to the user program by popping its address off stack and jumping to that again. The CPU should feature privileged modes, and the kernel needs to hold a semaphor to implement this efficiently.

[TNT]

How about using the following construct instead?

And here is one more construct I've used myself when setup time is significant (for example executing virtual machine instructions where the actual function does very little). It loses its advantage if you often call the same function repeatedly.

Code: Select all

vectoredfn:
lda #40
sta $1e00,x
rts

...
lda #VFN0_ID
jsr trampolineA ; call function defined in register A
...
jsr trampoline ; call function defined earlier
...

trampolineA
sta trampoline+1
trampoline:
jmp (fntable)

fntable:
dc.w vectoredfn, vectoredfn2, ...

Just make sure that fntable stays withing a single memory page...

The above is ROMable if you copy trampoline code to RAM, 5 or 6 bytes depending on whether you can sacrifice 5 zero page locations or not.

[Kweepa]

Very interesting, thanks!
I'm not sure it works as coded here - there seems to be something missing in trampolineA. [EDIT] Ok, I understand now. Durrr. [/EDIT]

I considered using a table of functions too, although like this:

Code: Select all

callbackfn1:
lda #40
sta $1e00,x
rts

funcwithcallback:
lda functable,y
sta loop+1
lda functable+1,y
sta loop+2
ldx #100
loop:
jsr $1000
dex
bne loop
rts

...
ldy #(2*funcindex)
jsr funcwithcallback
...

functable:
word callbackfn1, callbackfn2, ...

Obviously this would only be a size saving if I call funcwithcallback several times. I currently have two different funcwithcallbacks, one called 3 times, and one 4, so it's a marginal saving.

[Kweepa]

Small update:
Still working on the map generation code. It's over 1k and I haven't debugged the corridor generation yet.
Once that's done I'll probably have to chop the textures down to 8x16 to get everything to fit.