2
pr0be, on Sat Oct 3, 2009 3:35 PM, said:
I looked into disassembled SMB source code (smbdis.asm) and i have felling that it would be easier to write all code from scratch that modifing and analyzing orginal source code (Yep it is well commented but i don't think that i would have patient to do it 
it's quite impressive that you manage to run nes code on atari, i don't know exactly how nes handles a sprites but i suppose that very similar that my multiplexer so i think that sprites is not a problem... more difficult would be changing engine to use LMS feature to scroll screen
it's quite impressive that you manage to run nes code on atari, i don't know exactly how nes handles a sprites but i suppose that very similar that my multiplexer so i think that sprites is not a problem... more difficult would be changing engine to use LMS feature to scroll screen
Well, I'm already excited to make SMB run (and it's original code) on atari. I played SMB for the 1st time when I was just a little boy, say 8 years old. At that time my dad had bought the Atari 800 xl and was doing some gfx algorithms in basic. He learned me the basics, some ML and other stuff. The only game we had was on a tape (we only had A8 + Tape), it was Jigsaw puzzles (Parthenon/Bavarian castle). During the game the puzzle pieces were scrolling in the upper or lower border of the screen, and it was really 'scrolling by hand'. The programmers didn't use HW/Antic scrolling features. They really ROL/RORed all gfx data around on a gfx 7 type of screen. I never saw HW scrolling before. Then somewhat later I visited a friend who had a NES + SMB. The screen was scrolling smooth and my mouth fell open. I thought SMB is really no option for A8. Years later I learned about HW/Antic scrolling and started wondering: SMB must be possible on A8, -in some way-......years go by....
Now (20 years later): I printed the whole doc of the SMB source, and if I have to wait for a train or bus, or somewhere else, I'm studying it. It's not my primary goal to do the whole porting, but I'm just curious if it would be possible, and in which sense. I'm really learning much of just reading how they (the guys from nintendo) solved some problems. So no time is wasted for me anyway
... F.e. how they manage task control is really interesting. They use some kind of 'software CPU instruction' (JumpEngine). It works like a jump table, depending on the value of Acc. This acc can be anything, and can be increased/decreased when one particular 'subtask' is finished. Then, the next time (possibly next VBI) it will execute the next step. Imagine the main VBI routine making several JSRs to sub-treads of tasks, most of them independent from each other. So, (to me) it looks like an interesting method of some 'prehistoric multitasking' system.....Sorry for the whole story
(of topic off now)About the scrolling / LMS. The screen handling parts of the SMB code is concentrated in a small part of the total source code. It can be changed to do screens / fill the buffers the atari-way. So, that's not really the hardest part I think. The hardest part is still the sprites. The NES and the SMB code are dealing with sprites in some intermediate steps. The sprite shuffling routine is needed to handle correct flickering when the number of sprites in a scanline exceeds 8. These routines could however be disactivated, the whole shuffling stuff. Some code might need to be reorganized, or put into a different order. So, I'm afraid especially the sprite part must be rewritten for a large part.
