Jump to content
IGNORED

5200 Doom


Skatepunk60

Recommended Posts

There sure is a lot of manipulation going on somewhere. The GRAM only has room for 64 8x8 (1 colour) tiles...although it can be changed on the fly by overriding the EXEC (according to an Intellivision site I just found)

 

[ 06-09-2002: Message edited by: Sheddy ]

Link to comment
Share on other sites

Well, now everyone else who spent the time trying it out isn't going to have the satisfaction of knowing that others will be following them to their doom...

 

Nearest you'll get to Doom on 8-bit is going to be Vector (you'd have to ask Fox, but I don't think it'll be for 5200 too)

 

shame. hoping that would run a bit longer. Better techo-babble next time, Nukey?

Link to comment
Share on other sites

Skatepunk,

 

Could this be done - well the INTV could and did do 3D mazes (Treasures of Tramin anyone). But to do a non gridbased, free floating game like doom - I doubt it.

 

Whilst the 8bit Atari did things like the Eidolon by Lucasarts (and this I feel was the first REAL Doom precursor - including big enemies, free angluar movement and aiming etc etc) and Way out or Capture the Flag buy Sirius - and they were free floating 3D mazes too - I suspect the INTV (and certainly the 2600) lacks the horse power to do such a game :(

 

And although the 5200 could so this - ROM size would be against it - all the games mentioned above require at least 48K of RAM and a DD...

 

sTeVE

Link to comment
Share on other sites

Good question...

 

Can anyone make a BIG 5200 cart - one that can be used to create bigger than 16K games - a bankswitcher?

 

I know I said (in an earlier thread) that I didn't understand why anyone would want to port over the 8bit games that never made it to the 5200 (DK, DK jnr etc) - but I've had a change of heart since I set up my 5200 in the lounge - could anyone do it - at least bring over all those 16K 8bit carts...?

 

I'm sure the mods to the code required to do it are not that difficult (it happened a lot the other way) - any 5200 programmers care to comment???

 

sTeVE

Link to comment
Share on other sites

I know that there sombody who is actively pursuing the conversion of Atari 8bit games to the 5200. I know because I was asked to help in the conversion of a certain game for this year's Expo. Not sure if you'll see the results of that labor at this CGE or not.

 

THe problem is to get a good disassembly of the 8bit game. If you had documented source code, you could reasonably change it over to 5200 just by changing the proper memory addresses which this site's programming forum and 5200 forum have documented over the past year.

 

Jet Boot, I don't understand how bank switching would help since we are already making 32K ROM games. The idea of bankswitching on the Atari 2600 (and Bounty Bob I believe) is the get you more ROM, not RAM.

 

In fact, the only game I know of that expanded the RAM was Jr. Pac-Man on the 2600 -- and it clearly shows! The game is excellent, if not a bit too difficult.

 

Getting back to the 8bit. I've never properly understood this, maybe you can help me. Atari 800 Game1 is a 16K game; it runs on the 400 and 800. The game comes on a diskette. Does this mean that the 16K game file is loaded into 16K of code RAM, and it additionally uses 16K of memory RAM during execution?

 

To compare with the 5200, say you have a 16K cart. It's game code is on the cartridge, it's a 16K ROM chip. However, it uses the 16K RAM on-board memory for storing variables, sprite, and screen etc stuff. The game code is never physically loaded into that 16K RAM, so you have that 16K RAM to work with in your game.

 

Now you have a 32K 5200 game -- it uses 32K ROM for more game code, hence more space for better music, more data for visuals and stuff. But it still has only 16K RAM to use.

 

Finally, you have a 48K Atari 800 game that comes on a diskette. What does it do, load the entire 48K into "code RAM"? Or does it have to use the 48K RAM for both code and data?

 

If that's true, you'd seem to have an advantage on the 5200 over a 400 computer diskette game. Can somebody resolve all this for me?

Link to comment
Share on other sites

Yeah - that's what I meant more ROM - more storage for data and larger program space. I understand your description of the 5200 RAM/ROM process - its the same on almost all cart based systems...

 

Lots of games load into the 8bit's RAM in one load and never touch the disc again. And even if they do they only access upto the Disc's capacity (88k usually) - so most games could in theory be made to work with ROM size LARGE and 16K of RAM space perhaps...

 

A disc/cassette game loads and runs in the RAM footprint - all data and code is in the RAM - so a 16K game loads into and runs in one block of 16k.

 

A 48k disc game behaves the same - 48k for all code and data - unless the game goes to the disc to load stuff incrementally when the game could be as big as the disc capacity, but the code has to execute in the 48k RAM...

 

sTeVE

Link to comment
Share on other sites

Glen the 5200 man's conversions from 5200 to 8bit -- how big were those files on diskette?

 

You'd think that a 16K 5200 game like Centipede would have to be a 32K game on Atari 8it, OR it would have to load levels. There's no way 16K of ROM and 16K of RAM (5200) would fit in 16K of RAM for a Diskette game, right?

 

So,were they 32K or 48K diskette files?

Link to comment
Share on other sites

The binary would still be roughly the same in size give or take a few bytes because of conversion issues like the joystick. Now once it's loaded into the 8-bit it may need more RAM but then again I don't think most 5200 games used all 16K of RAM.

 

Actually the game could be smaller because there would be no need for ROM filler. Just because the game is on a 16K ROM doesn't mean all 16K is used. But this would depend on if he did a hack or a conversion.

Link to comment
Share on other sites

Well, lets get more specific here.

 

5200 Centipede is 16K. On the 5200 itself, that means that code and data resides in memory locations $8000 thru $BFFF, correct? RAM exists in $0000 thru $3999 -- 16K of it.

 

Now Glen the 5200 man puts it onto a 16K disk file. It ain't gonna happen! Because , and correct me if I'm wrong, the 400 has 16K RAM which is probably $0000 through $3999. It can't access $8000 thru $BFFF because that is ROM space, and this game is on disk. So where does the code fit?

 

So you can't just do a blind 16K port, 5200 to 8bit, right? HOWEVER, if you make it for the 800 computer, with 48K RAM, then you can put the code in the higher RAM addresses and still have your 16K RAM to match the 16K used by the 5200 game (Whether it is all actually used or not).

 

Question: did these 5200-to-8bit-Glenn conversions work on a 400 computer or not? Anybody know?

Link to comment
Share on other sites

Cafeman--

That is absolutely correct. If the game is being ported from a 5200 cart to a 8-bit disk...the addresses of where the cart's code was would need to be Ram in the 8-bit (otherwise, it wouldn't load at all). You can't write to something that isn't there.

If, however, the game's source code is changed to lower the point of origin to match that of the 8-bit's Ram area...it should work provided that the game itself did not use any additional Ram above the 16k (so some variables would need shifting about. Good luck finding one.

With the 800 computer, this is moot (since all memory below the OS is Ram).

Link to comment
Share on other sites

Cafeman--

That is absolutely correct.  If the game is being ported from a 5200 cart to a 8-bit disk...the addresses of where the cart's code was would need to be Ram in the 8-bit (otherwise, it wouldn't load at all).  You can't write to something that isn't there.

If, however, the game's source code is changed to lower the point of origin to match that of the 8-bit's Ram area...it should work provided that the game itself did not use any additional Ram above the 16k (so some variables would need shifting about.  Good luck finding one.

With the 800 computer, this is moot (since all memory below the OS is Ram).

 

That's what I meant by hack or conversion. When I said conversion I meant him knowing the code and moving things around that need to be shifted.

 

BTW the disk file wouldn't run on an unexpanded 400. Doesn't the 8-bit have to have at least 48K for a disk drive? Doesn't DOS take up something like 8K itself?

 

Cafeman, as you stated lets say the ROM code is 16K well that's 16K for the code. This is what would be stored on the disk so the actual game could be ~16K depending on what he did. Now when you load the game yes it would have to load into RAM so that's ~16K taken for the code and then you would need ~16K for the game RAM.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...