Super Mario Bros. on Atari 8bit?

[ndary]

i cant the files to work.... i am using ATARI800WIN PLUS, and set to 64k 800xl, pal, basic off

and get this screen:

[Heaven/TQA]

that is the right screen you should get...

[ilmenit]

just for fun

[Kjmann]

Just for Giggles. I haven't even come close to finishing this one but here it is anyway. =)

 

 

[peteym5]

Using Antic 4 is the best bet, but you do only have 128 characters to play with. Would be a lot to do everything with one character set. Since Mario looks like its a tilemapped game, you probably do the 2x2 characters making up one tile, but limits you to 32 possible tiles. You could use 2 fonts, alternating with a DLI on every line to give you 64 tiles and would leave room to do the soft sprites.

[Synthpopalooza]

Using Antic 4 is the best bet, but you do only have 128 characters to play with. Would be a lot to do everything with one character set. Since Mario looks like its a tilemapped game, you probably do the 2x2 characters making up one tile, but limits you to 32 possible tiles. You could use 2 fonts, alternating with a DLI on every line to give you 64 tiles and would leave room to do the soft sprites.

 

One possible suggestion, perhaps, is using a software mode like Super IRG, where you can get 14 colors at ANTIC 4 resolution, or maybe a CIN mode overlaid with GTIA 11 (between 62 and 80 colors possible, depending on if you flicker between Graphics 12/12.11 or Graphics 12/0.11).

 

Another idea: use two character sets, but set up a special Antic 4 display list that essentially gives you a 4x16 grid on each character. You will need to use a display list interrupt to change the character set every other line, plus on every even number display list line use a LMS to point to the screen memory of the previous line. In effect, you get:

 

One line of one character set ...

Second line, different character set, pointing to the same memory location as the previous line ...

Third line, first character set, progressing normally to the next screen memory location line

4th line, second character set, LMS to point to the screen address where the third line is ... etc.

 

In effect, character resolution is 40X12, but each character is in effect 4x16 pixels with each pixel being a normal Antic 4 pixel. The second character set becomes in effect the lower 8 pixels of each character.

Edited September 22, 2009 by Synthpopalooza

[Rybags]

I think the method of duplicate LMS grouping 2 lines, plus charset change has merit, but any software mode using changes every scanline will leave too little CPU cycles to do much useful work.

As the charset is being changed every text line anyway, it also means you may as well just use as many of them as needed to give spares for SW sprites.

 

 

Not much of a fan of these "Super IRG" tricks... I find you get too much flicker on anything that's in Luma value 6 or higher.

[analmux]

Guys, guys....The first thing to focus on now, is if I can get a scrolling graphics 2 screen, and some moving PM rectangles (the vertical bars are no solution ), to have something representing....The antic 4 font / swsprite problems are for another time.

 

Not much of a fan of these "Super IRG" tricks... I find you get too much flicker on anything that's in Luma value 6 or higher.

Exactly. Super IRG might be a nice solution for some projects. Not for this one. Remember, the Nintendo itself already has problems sometimes to keep the game running. When there are 5 (or more) enemies, or 4 of those rotating firebars (in the castle levels) at once on screen, then all its frametime is used. Sometimes it needs 2 frames to have 1 frame of action. That's why sometimes the screen begins to flicker and we have some slowdowns in the 'busy' zones.

 

Thus, the game logic takes up very much CPU time already....and remember:

 

-NES has 64 hardware sprites, no need to handle gfx data itself

-NES runs at full 1.79mhz without any halts by video DMA

etc.

 

No time to do anything like HIP, RIP, TIP, Super IRG etc.

 

...but, I think some parts can be highly optimized, as I can throw out f.e. the sprite-shuffler, the screen buffer routines etc. We on atari can write directly to screen memory instead.

 

 

I think the method of duplicate LMS grouping 2 lines, plus charset change has merit, but any software mode using changes every scanline will leave too little CPU cycles to do much useful work.

As the charset is being changed every text line anyway, it also means you may as well just use as many of them as needed to give spares for SW sprites.

I indeed think that would be a nice solution: having 2 global fonts (one for the even, one for the odd charlines).

Then maybe we can do 2 extra zone-specific fonts when f.e. a row of goombas is walking at f.e. charline 12 and 13. Then these can be stuffed into specific fonts, and use these extra fonts on charline 12 & 13 only.

 

But, remember, another solution is to dynamically refill the fonts during playing the game, as not ALL metatiles are needed at once.

 

On the other hand, problems can arise when doing this even-/odd-fonting:

When we have a free sprite (i.e. not vertically restricted), see f.e. the flying fish frenzy, then the softwaresprite routines will need more care.

 

 

Maybe we can have a look at one of these solutions:

 

(1)

-use two global fonts (for even/odd charlines)

-use two (or maybe 4,6) extra zone-specific fonts for enemy zones

 

(2)

-use one global font (for whole screen)

-use an arbitrary number of zone-specific fonts

-use dynamical font redefinition, depending on need

 

(for both: Don't do enemy rendering EVERY frame, but f.e. once every 2 frames...)

 

anyway, many enemies are walking on charline boundaries and only moving horizontally. They can be precomputed, i.e. prerolled and stuffed into specific fonts. We could even precompute a goomba passing a small piece of background. But, I'm still not sure how all of this will fit into memory, or one-load. Thus, we should not get over-optimistic.

Edited September 22, 2009 by analmux

[Tezz]

(2)

-use one global font (for whole screen)

-use an arbitrary number of zone-specific fonts

-use dynamical font redefinition, depending on need

 

(for both: Don't do enemy rendering EVERY frame, but f.e. once every 2 frames...)

That's what I would suggest to do. I was going to ask actually if you were considering dynamically refilling the font data.

So with all the required precalc data, how much memory do you estimate the game will require upon completion?

 

EDIT * I re-read your post above and can see you are still planning what and where with regard to the preroll.

The methods you are outlining seem the right way to go anyway.

Edited September 22, 2009 by Tezz

[analmux]

So with all the required precalc data, how much memory do you estimate the game will require upon completion?

Hard to say...but I think not 48kb or 56 kb, but at least the full 62kb.

 

Code:

-The NES part is 32 kb

-Softwaresprite routines: 2 kb at most (at least when not doing unrolling stuff; I think selfmod code is a good solution here)

 

Variables/screen memory:

-2 kb (page 0-7) variables & buffers used by the NES code

-2 kb screen memory (double buffered)....but I'm still thinking of modifying the screen handlers

 

GFX data:

-4 kb (remember 8kb on NES, but we will convert to antic 4, i.e. throw away half of the data)

 

That's already 44 kb, still 18 to go.

 

When stuff must be precomputed, we need a list of precompute commands for every part of a level. I'm not sure about this, maybe another 2 kb.

 

Precompute handler: This might be a complex routine, at least complex enough to make it 4 kb.

 

Now still 12 to go.

 

The remaining 12 kb is needed for the font buffers / rotate buffers for swsprites.

 

I won't keep all rotated sprites in memory, but they should be precomputed at the right moments.

[Goochman]

Wow - awesome. Cant wait to give this a go, characters or not

 

Great stuff analmux

[Thelen]

This is getting really cool !

 

How much code did you need to rewrite/rework to get this going so far ?

[peteym5]

I would have never suggested anything like super irg, apac, cin, etc because they simply hog way too much cpu. Almost limited to a still picture. Alternating character sets on even/odd character lines takes much less cpu.

[analmux]

How much code did you need to rewrite/rework to get this going so far ?

Until now, I patched a handful of instructions in the Nintendo code, and then added another handful of instructions to eavesdrop the x-positions of the Nintendo-sprites and copy them to PM x-coordinates.

 

The real work may need lots and lots more, of course.

 

But, to give an idea of the next step, i.e. step 6 (just another test step), here's the following new test file:

 

http://www.phys.uu.nl/~bpos/1/6.atr

 

This time I changed from graphics 1 to graphics 2, and did some simple font-redefinitions to give an idea which direction it all will go.

 

AND: Most important: Scrolling is added....including sprite relative x corrections.

This was an additional ±100 extra instructions.

 

Still one bug: After dying or entering new level, the DLIST must be reset. Also the (new) screen memory must be erased in these cases.

So maybe that's the next step, or maybe not. Maybe the next step is not trying to go further with antic 7 / graphics 2, but directly with antic 4 / graphics 12 instead.

[+MrFish]

But, to give an idea of the next step, i.e. step 6 (just another test step), here's the following new test file:

 

http://www.phys.uu.nl/~bpos/1/6.atr

 

This time I changed from graphics 1 to graphics 2, and did some simple font-redefinitions to give an idea which direction it all will go.

 

AND: Most important: Scrolling is added....including sprite relative x corrections.

This was an additional ±100 extra instructions.

 

Still one bug: After dying or entering new level, the DLIST must be reset. Also the (new) screen memory must be erased in these cases.

So maybe that's the next step, or maybe not. Maybe the next step is not trying to go further with antic 7 / graphics 2, but directly with antic 4 / graphics 12 instead.

 

It's definitely getting easier to play. I think you should get it into antic 4, and do the player boxes or mock sprites.

[analmux]

And here's another one. It's the same as test 6, but now with a rasterbar included to show cpu usage.

 

The black part is the VBLANK engine running all game routines. The dark grey part below that is just the "jmp EndlessLoop" part.

 

http://www.phys.uu.nl/~bpos/1/7.atr

[Thelen]

truly magnificent !!!

[desiv]

Just want to add to the "very impressed and intrigued" part of this thread.

 

Don't have an Atari 8-bit (yet, browsing for a fair price one (OK, I admit it, I'm cheap!), and still haven't decided on which one), I was always a Commodore/Apple person (just what we could afford and what was in the neighborhood) but wanted an 800 for quite a while, before we got the Commie... (Which I was happy with too..)

 

This thread/project is just very impressive.

 

Also, when there's anything graphically different, posting a screenshot would be nice. I was interested before, but when I saw the screenshot, it made it clear where you were in the project.

(Yeah, I could fire up an emulator, and probably will, but I like a few well placed shots from time to time. :-)

 

Anyway, keep it up. Very kual!!

 

desiv

[Heaven/TQA]

cool and exciting project...

[+rdemming]

Its amazing to see the original SMB NES code being used for an Atari version. I'm hoping that this will indeed turn out to be a "playable" SMB but I understand that the graphics capabilities of the Atari make it quite a challenge.

 

An interesting idea would be to make a VBXE version of SMB. The VBXE graphics capabilities would make a near prefect conversion possible and possibly easier to convert. But of course, only few people will get a VBXE but you can always hope

 

Robert

[peteym5]

Interesting progress so far. Something I had been discussing with Candle is VBXE detection and at what location. I am working on a concept that will allow a game to be played with or without VBXE. If there is no VBXE it will just use standard graphics. If detected, VBXE routines will be called up. This will be done with an AtariMax 128k bank switching cart and the different routines will be in different banks and block copied to ram depending on what hardware is detected.

 

Going back to the alternating fonts, on trick to get more colors in Antic 4 is switch between fonts on alternating frames, like rapidly switch between a red & green pixel to get brown. This does work on the lower luminances, anything over 6 has a noticeable flicker. To reduce flick better, do the "flashing checkered" method, first frame be like RGRGRG, and next frame will be GRGRGR pixels. Of course he would need 4 fonts because of the need for all the tiles and doing soft fonts with them.

[+MrFish]

Even a version of this with simple hardware sprites only would be impressive.

[analmux]

Thanks for comments...

 

But, anyway to clear things up. I'm not sure if I'll spend the time to finish this idea of porting SMB over to A8. So, people please DON'T consider this as a new project for me.

 

Instead, and that's why I started posting here on this subject, I'm curious if others also have some ideas to port it to A8 in the best possible way.

 

 

Until now I mainly did some tests to see if the code would work at all on A8...and to my big suprise it seems to do so. Until now I only solved one problem: Sometimes the game engine tries to execute a subroutine to clear all workspace memory (pages 0-7). The game engine itself is purely Vertical Blank Interrupt based. However, clearing 2kb of memory takes more cpu time than there actually is in 1 frame (the problem gets worse for ntsc machines). That's why I hacked / patched the ClearMem routine, which now temporarily disables the NMI until it's finished.

 

Another patch was necessary to kill the waiting loops which look for the 'sprite 0' collision. This is needed to generate a screen split between the score bar and the rest of the screen.

 

Since I patched these, the code works without any weird lockups.

 

 

The main thing to do now is finding out if some routines in the NES code can be optimized / A8-transformed, f.e.:

 

(1) On A8 we can directly write to screen memory. We don't need such stupid things like the screen update buffers. Cancelling these will save some cpu time.

 

(2) Another thing: On the NES, the levels are decoded ON THE FLY. We however could do the AreaDecode parts in one go, before entering a level. On A8 we have more workspace to unzip the levels.

 

I'm still not sure whether it's a good idea to use PM underlays (and scrolling MCS, like one of my earlier demo experiments) to pimp up the screen, add some more colours here & there.

 

 

For now, I'm still trying to understand how the screen update buffers are operating, and thinking of how this can be simplified / optimized for A8.

 

I still don't dare to say anything about need of softwaresprites. This could really take (too) much cpu time. I'm trying to find out if it's possible at all, or to some approximation.

 

One next step could be another test file including antic 4 + PM boxes instead of antic 7 + vertical PM bars. But, after that a complete re-hack could be needed, and I'm not sure if I'll make it. I had some spare time last weeks, but this is over for now....

 

...so I'm curious if others are interested in co-work for this.

 

I have the source code and it's full of very useful comments.

[Rybags]

Without having seen the code, I'd say some major reworking would likely be needed.

 

Optimisations could be had, but of course they're a necessity to get the time back required for softsprites.

 

Some ground could be gained by optimisation of the scrolling. I assume the original doesn't just unpack an entire level into raw character data then just move the window over it?

 

One idea I had some time ago which I've not played with yet is the concept of allocating a Page to each text line, then just have a wraparound h-scrolling situation.

 

i.e. when you're writing characters to columns greater than 208 or so, also write them into columns starting at zero. When your window origin reaches position 208, set it back to zero. That way, you can have a level which can be infinitely long, and you can do H-Scrolling by rendering new data only and not having to perform any move operations.

 

We can also take advantage (regardless of the mapping method employed) of the fact that we can pre-render to the right of the visible window, doing a small bit each frame.

 

For a 20 character high scrolling screen region, one Page per line equals 5K. Not an entirely large amount.

[andym00]

Without having seen the code, I'd say some major reworking would likely be needed.

 

smbdis.zip