Tearing apart da giant pinball program once again, made each code section into an include library. Little bit of fun festivities and tales to bring back.

Basically, it was executing code in la la land from any code in an include library. Far as I can tel, it doesnt seem to like the included lbirary labels and simply goes to the beginning of the include file, even if it is a header or data. (I am luvin the step through debugger, remind me to marry the F11 key when all is said and done)

The basic workaround I am playing with is to set each module into memory explicitly and using a text label to tell me where the hell things are.

*= $9000
.DB "Module name"
Program1
code continues here and working

questions, thoughts or I am simply doing it wrong again?

_________________
"My biggest dream in life? Building black plywood Habitrails"

I'm not sure that I understand the problem you apparently seem to possibly be experiencing,:) but the BIOS ROM code I wrote for my POC unit is built out of 33 .INCLUDE files. I loaded the entire mess (some 6500 lines of code) into the Kowalski simulator, fixed the syntax were required (e.g., substituting @ for %) and assembled. It assembled without a hitch. A byte by byte comparison with what is emitted by my UNIX cross-assembler was error free.

One thing that is necessary is that each .INCLUDE file end with an .END assembler pseudo-op. Also, all static declarations should be made in the base file from which assembly is started. Dunno if that's what you are doing, but if not, might be why things are not working for you.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I didn't put a .END directive. It seems to compile fine right now, though and the code is also running in the simulator. Fun to watch the simulator flip through the various include files

Is there other gotchas I should know in using as includes? If you want, throw me an email, I can zip up and send it all to you to check it out...

_________________
"My biggest dream in life? Building black plywood Habitrails"

Never done this and I just tried it with a version of EhBASIC that has extra modules .INCLUDED and it doesn't seem to matter whether or not there is an .END in any of the files.


Bother! I wish I'd remembered that recently when I wanted to use a couple of binary constants.

Lee.

Sometime in the dim past I recall I had a problem with using .INCLUDE and somehow "fixed" it with a .END at the end of each .INCLUDEd file.

I don't use the Kowalski simulator all that much, but it is handy for testing code snippets before I write them into a large program and shove it through my UNIX cross-assembler. The slightly non-standard syntax (e.g., @ instead of %, ROL instead of ROL A) is a bit of an annoyance but doesn't prevent it from being used for large projects.

It would be nice if the simulator could be fixed up to emit '816 code (as well as the syntax deviations), but compiling the source with anything other than Micro$oft Visual C is apparently out of the question. I tried once with GCC++ on my trusty Linux mule and got one compile-time error after another.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I will try it later on since the code isnt working worth a damn. It does seem to run in the simulator and when I commented out the clear zero page init, I got lights and display. That means the main game loop is running, the hardware kernal because the hardware matrix has to be kept stroked all the time. Any meaningful interactive code otherwise wasnt working, blah

by the way for giggles, I posted this on facebook. If you dig old school arcade games, guess the song...
http://www.youtube.com/watch?v=mNKDPKEank8
"the dog policeman"

http://www.dailymotion.com/video/x59u0z ... shortfilms

Both combined to make a famous arcade game song.

_________________
"My biggest dream in life? Building black plywood Habitrails"

Dinosaur: Thanks mucho on the help. Got most of it running now. THE biggest problem was that I dummied up the varies sections, the firmware library was completely blank, so the software logic couldnt affect the hardware! Test passes is running, so now onto the attract mode. thanks again with all da help!

and the firts post thing is because I never learned about the .START directive. DUH here...

_________________
"My biggest dream in life? Building black plywood Habitrails"

I forgot to mention in that little writeup I sent you that .START can take an address argument. For example, .START $E412 means start execution in the simulator at $E412, regardless of where the actual code starts.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!