Jump to content

Rybags's Photo

Rybags

Member Since 29 Sep 2005
ONLINE Last Active Today, 9:58 AM

#3460734 dump my Atari OS ROM

Posted by Rybags on Sun Mar 6, 2016 5:44 AM

OK... my suspicion is that it's probably got a window covered with sticky label that has barely readable printed text on it.




#3460693 Blue Max source code for you.

Posted by Rybags on Sun Mar 6, 2016 3:34 AM

I've not looked at it but is there any special comments or stuff relating to corrupted screen when you bomb your own runway?




#3460664 dump my Atari OS ROM

Posted by Rybags on Sun Mar 6, 2016 2:36 AM

Shift + Ctrl was never used in any official OS.  Ctrl-1 is pause screen output and Ctrl-2 is bell in all OS versions.  Shift + Ctrl probably avoided as some combinations won't generate a keypress.  Though 0-9 all work fine, which is sort of a missed opportunity as it would have made for an easy set of F-keys.


  • P1r likes this


#3460372 dump my Atari OS ROM

Posted by Rybags on Sat Mar 5, 2016 7:02 PM

I never knew Atari did regional versions of XL with different Rom and keyboard.

Is this an actual Atari revision though, or is it just something that's done by aftermarket kit or the local distributors there?

 

Seems weird to me that Atari themselves would generate an OS modification in such sloppy fashion.

Even though much of the expertise was lost even at the XL release time, even in later XE years they revised the OS but managed to keep it compatible and do the checksumming properly.

Plus if it's using $6FF - that's just asking for trouble.  There's plenty of spare memory locations in the OS region that could be used to implement a new function.


  • P1r likes this


#3459894 Glenn 5200 to A8 Conversions, ROM files to burn to EPROM anywhere?

Posted by Rybags on Sat Mar 5, 2016 10:29 AM

Just checked a few more games (curiosity took over from the need to sleep).

 

It seems to be a common trait - 16K games have mirror images within the 32K window that carts can live in and it seems that some will favour running at the lower address.

Not sure how the mapping works exactly, it probably varies depending on how the cart is wired up, what size it is and whether it's 1 or 2 chips.

 

Star Raiders, 16K Rom has mirrors 8K apart.

$4000-$4FFF, $6000-$6FFF blank (return FF)

$5000-$5FFF and $7000-$7FFF read the same, code seems to execute in high copy.

$8000-$8FFF and $A000-$AFFF read the same, code executes from low copy.

$9000-$9FFF and $B000-$BFFF read the same, block is mostly blank some data at bottom, cart vectors at top.

 

 

As such, this would mean some games when converted would easily run on smaller Ram computers.

So maybe Atari shot themselves in the foot here... they made it hard for the games to be put onto cart if hacked to work on the computer but made it easier for more people to be able to run them if they only had 32 or 40K Ram.




#3459804 Glenn 5200 to A8 Conversions, ROM files to burn to EPROM anywhere?

Posted by Rybags on Sat Mar 5, 2016 8:15 AM

Not sure.  Quickly looking at Qix from Atarimania - it's a 16K program and appears to reside at $6000 - $9FFF which is 8K lower in memory than you'd expect.

5200 can map cartridge ROM from $4000 - $BFFF but the computer can only map it from $8000 - $9FFF (disregarding the small IO hole $D500).

 

What might work is to rearrange things a bit and compress part of the Rom then depack it to Ram.

 

Have the bottom 8K of 16K hold what goes from $8000-$9FFF which in the case of this game is the top part of the Rom.

Have the top 8K of the cart hold a compressed copy of what lives at $6000-$7FFF, plus the usual Init / Run / flags that a cartridge requires.

 

Prerequisite for this would be a machine with minimum 32K Ram.  Also, if the game was modified in such a way that the (now) Rom based portion needed to actually be Ram then the game wouldn't work.

 

 

For other games, not sure how they're done.  A potential problem is that in the conversion process the game size might bloat to be bigger than the 8 or 16K which it started at.

 

Better option IMO - just put the games onto Atarimax flashcarts as executables.  Advantage is you then fit several at least per cartridge and likely no program modifications needed.




#3458143 RIP 1200XL motherboard

Posted by Rybags on Thu Mar 3, 2016 8:08 PM

Nice find.  The lesson in there is don't always assume it's a major component stopping your machine working.

Though of course if you're around when the puff of smoke is emitted it serves as a bit of a clue as to where to start looking.




#3458021 "Space Zap" Clones?

Posted by Rybags on Thu Mar 3, 2016 6:21 PM

I think I mentioned before but the problem with the game is it's just too simple.  It's like the grandfather of a poor man's "Plants vs Zombies".

Except there's next to no variation in the enemies or weapons they use like that game.

 

It is what it is.  Sort of like Space Invaders.  Ask for an improved SI, you get pointed to Galaxian or Galaga.  Ask for an improved Space Zap you get pointed to stuff like Plants vs Zombies.




#3457239 RIP 1200XL motherboard

Posted by Rybags on Wed Mar 2, 2016 11:28 PM

The problem with anti-static mats... the name sort of sends a wrong message.  They're often conductive material in which case powering up something sitting on it or otherwise allowing power to flow to it could be real bad.




#3456957 RIP 1200XL motherboard

Posted by Rybags on Wed Mar 2, 2016 6:55 PM

A userid change might be in order.

 

Probably a warning to all of us - I do soldering expecting nothing but heat to be coming out of the iron but in reality it would seem a lot of them pass through some AC.




#3456950 ANTIC architecture; as flexible as the VCS?

Posted by Rybags on Wed Mar 2, 2016 6:52 PM

Using equates from other sources comes down to expected syntax.

With assemblers there's generally a few common differences that you might find, the first 3 here especially relevant to equates files.

 

1. Assigning labels is usually done by = but some assemblers use EQU.  Some allow both.

2. Comments are usually started by ; in rare cases it'll be different.  In most cases, anything coming after a parsed instruction and operands will be treated as comments regardless of leading character.

3. Some only allow and expect upper case, others ignore case, some are case sensitive, e.g. WSync different than WSYNC or wsync.

4. Controlling location counter usually by *= in some cases by ORG.  * on it's own usually in any to allow location counter to be used for calculations and assignments.

5. Some difference in expression of instructions, usually types with multiple addressing modes which can also act on Accumulator, e.g. LSR.   Some expect LSR A, some just LSR, some allow both.




#3455824 ANTIC architecture; as flexible as the VCS?

Posted by Rybags on Tue Mar 1, 2016 9:37 PM

Rally Speedway is character mode - it's probably the case that charmode would be more suited to your needs.  Additionally you can add detail at little extra cost if you're just dealing with maze type game worlds where movement boundaries are constricted and snap to certain pixel boundaries.

 

Basketball - they could have done it various ways but similar techniques have been employed in later games.  Jungle Hunt is a good example, it keeps a colour map of the hero's colours per scanline.  Pole Position changes fine H-Scrolling values on the fly as well as doing colour and positional change for PM objects.




#3454821 Atari 130XE on Hackaday.com

Posted by Rybags on Tue Mar 1, 2016 6:17 AM

*headdesk - he calls it a 130EX !

 

*headdesk #2 - they're rescuing MT Ram chips... PMSL !

OK, obviously the video is for illustrative purposes.

 

Have to wonder though, how do the flaky traces cope with the heat?  Got to say though it's a fast process.

 

For whatever reason though, you just don't seem to hear about the method of heating pins with the iron individually and using a solder sucker.  I did about a dozen Pokeys off 7800 carts that way, and other DIPs as well, practically all rescued and reusable.

The other thing is it's a whole bunch cheaper than having to buy a hot air station.




#3454811 ANTIC architecture; as flexible as the VCS?

Posted by Rybags on Tue Mar 1, 2016 5:45 AM

There's multiple playfield modes in bitmap and text and software tricks can expand on that even further.

 

There's no direct equivalent to TIA playfield 40x192 @ 1bpp.

As Avery mentioned there's Graphics 3 which is 40x24 @ 2bpp.  Tricks can be employed to turn it into 40x192 but at great cost in CPU cycles.

Probably easier would be to just use one of the GTIA modes which allows 80x192 @ 4bpp.

 

The thing is you don't necessarily have a direct equivalent so it's either throw together some sort of emulation layer, change the intermediate processing or just change the individual game's programming.




#3454306 ANTIC architecture; as flexible as the VCS?

Posted by Rybags on Mon Feb 29, 2016 7:49 PM

Doing screen stuff on the computer is very different to 2600, and porting games across is usually not straightforward.

 

Part reason for Antic's existence is so you don't need to do that kernal based stuff though of course it still applies for doing lots of colour changing or PM repositioning.

I imagine your virtual worlds are represented somewhere as bitmaps or otherwise procedurally generated.

The trick with porting such things is to replace the middle-man (kernal) with code that simply renders the graphics in a way the computer can easily display them.

 

Realistically, the only thing similar on both systems is player/missiles and the method of dealing with them is very different.  But for the purpose of porting, it's way easier to go from 2600 to computer vs the other way around.