Jump to content

Rybags's Photo


Member Since 29 Sep 2005
OFFLINE Last Active Today, 6:59 PM

#3063900 Missile Command arcade -> A8

Posted by Rybags on Sun Aug 31, 2014 12:12 AM

I've spent a few days looking at the game program code (disassembly from IDA Pro) and MAME driver for this game.  The MAME driver (C program) is useful in that it provides rough documentation for the hardware used within the machine.


The hope was to be able to take the arcade Rom, put a bit of an emulation wrapper around it and have it run on the computer - both on standard hardware and VBXE.


But... some problems.  Looks like there's practically no way the game would work on a standard machine without extensive reworking, and it's likely the reworking would make it too slow anyway.


A few things about the arcade game:

- it uses 256x231 resolution.  The horizontal res is somewhat incompatible with Antic modes, it's 4-colour for most of the screen, 8-colour for the bottom 32 pixels.  The solution I had in mind was use Antic E with scrolling and pan the view when the cursor gets near the edges of the screen.

With VBXE it wouldn't be so much a problem, it can do 256 pixels in narrow mode although the aspect ratio of the game would be somewhat screwed up, it'd be near 1:1 where the arcade pixels are about 4:3.


- the video RAM uses a weird access/addressing scheme.  At first glance it seems ridiculous but the way it works allows accessing pixels on byte boundaries rather than having to do shifts/masks etc.  This allows the code to run faster when doing pixel access operations.

The system board uses 1-bit RAMs, so there is little/no wastage.  The accesses are only redirected when a CPU instruction with lower 5 bits=00001 is active.  Such instructions are the (ind,X) ones - this allows the system to use this addressing scheme for the video Ram with almost 60,000 unique addresses but still allow the system to have a "normal" type memory map where the normal RAM, 12K ROM and IO devices can reside and not resort to any bankswitching tricks.


- it uses a single Pokey at 1.25 MHz and 6502 at ~ 1 MHz.  The lower Pokey speed would mean frequency translation or reworking parts of the code would be required (shouldn't be too much work).  The lower 6502 speed means the computer has some nice spare cycles to do emulation layer stuff and hopefully still be able to maintain the same pace as the arcade.


- trackball.  There are a couple of hardware registers that maintain 4-bit X/Y for the trackball, simulating this should be possible, this is where the extra spare cycles come in handy.


- Interrupts.  The game appears to generate IRQs at VSync and periodically during the display (every 64th scanline) - I suspect the scanline IRQs are mainly for reading the trackball position.


I'm thinking this game could probably be made to run under VBXE without too much effort.  There are about 30 (ind,X) graphics access instructions in the game although there might be normal access to the video RAM as well (quite possible things like the explosions are done by normal writes to the video RAM).

#3063885 Does the XL OS still have the 1200XL ATARI rainbow hidden?

Posted by Rybags on Sat Aug 30, 2014 11:30 PM

Pretty sure it's gone completely - there's a system jump table point at $E480 in the XL OS called PUPDIS (PowerUp Display).  On 1200XL it displays the rainbow, on other XL OSes it just goes to the Self-Test.

The code that draws the rainbow doesn't seem to be in the ROM on later XL - it appears to use some optimizations to draw it in high RAM, so the amount of ROM used was probably somewhat less than the raw graphics data otherwise would use (it's in Antic D aka Gr. 7 )


You can call up the display within Basic - Z=USR(58496)

#3063319 New pacman for atari 2600

Posted by Rybags on Fri Aug 29, 2014 11:19 PM

Practically everyone agrees the original is a turd but you can't entirely blame the author - he was an employee tasked to do a job and we've all heard the stories of bad games from Atari where the short deadline is a major contributor to the fact.


In the modern day, homebrew can be done at your own pace, plus there's 30 years of accumulated wisdom - practically any 2600 game of the 80s could be recreated today and done better.


Not to take any credit away though... on any machine in 4K this is pretty amazing.

#3063279 New pacman for atari 2600

Posted by Rybags on Fri Aug 29, 2014 9:42 PM

Looks/plays great.


IMO you should just go for broke - do it proper justice by going for an 8K Rom for more comprehensive title and intermission sequences.

Maybe even a credits roll.


You can always do a 4K version with just the game and what'll fit in, then have the option for people to buy/burn/flash the short or extended version.

#3062366 7800basic and the 2600 Keyboard Controller

Posted by Rybags on Thu Aug 28, 2014 11:15 AM

Not sure that description in the link is right - the Atari documented method as used on the computer should also be applicable to 2600 & 7800.


The 4 directional pins can be configured as outputs - to read each row in turn you select it then the values are read from fire button + 2 Pot inputs to give the state of the selected keys.

#3059506 M.U.L.E. - For the Apple, is it Impossible?

Posted by Rybags on Sat Aug 23, 2014 10:59 PM

I'm not sure that getting MULE going on A2 warrants creating a new controller interface/standard.


The ability to run 3 paddles is sufficient.  On the Atari 800 you can have 3 players by paddle and 1 by joystick.

At least 1 joystick is mandatory there as it is required (shared in some cases) for each player to do their development phase.


On A2 you should be able to use keyboard as replacement for joystick, so 3 paddles + kb would be sufficient.

#3059091 Color capabilities question

Posted by Rybags on Sat Aug 23, 2014 9:28 AM

You could probably say for each DLI where a few quick changes are made, that's a scanline worth of CPU gone.

312 scanlines in PAL, so about 0.333% per DLI.


For long running DLI or kernal you generally lose all the CPU in that region.


One exception is the Project M engine - he uses Timers instead of DLIs and narrow mode - this frees up some cycles that otherwise would be lost.  In most game situations we wouldn't care much but with the raycast + render there every extra saving becomes important.

#3058428 Color capabilities question

Posted by Rybags on Fri Aug 22, 2014 2:53 AM

5 PF colours + 4 PM colours = 9 colours.  Tricky mixing can give 23 colours.


GTIA modes give 16 colours.


More colourful modes usually mean more memory used, although multicolour text mode gives effective 160x192/5 colours at the cost of about 2K including 1 custom character set.


More colour still usually means DLI usage to change colour registers.  The CPU penalty can be small, medium, large depending on what's being done.


Generally for games the CPU isn't the problem there, it's more often the case of limitations imposed on you by having regions of fixed colour.


"All games" ... the fact of the matter is that 98% of games barely push the ability of the system and in many cases could easily have been made to look better.

#3057651 600XL Garbled Display After RAM Upgrade

Posted by Rybags on Wed Aug 20, 2014 8:41 PM

The Ram itself might be bad.


You can install the Ram chips without doing any of the other upgrade process - that's what I did initially.  You can then verify that 16K of it actually works, then do the rest of the process.


Note there was a "wrong" procedure floating around, but I'd guess if you took instructions from here they should be right.


There's always the chance the problem is somewhere else, but if the machine was stable with 16K then it tends to point to something you added.

I should think if you bungled the other stuff that the machine wouldn't work properly at all.


Do the Ram chips get hot?  Also, do you have another XL you can swap parts from?  Maybe try the PIA, MMU and CPU from another machine.

#3057139 Starting out with VBI

Posted by Rybags on Wed Aug 20, 2014 5:25 AM

Calling it from Basic?  You need RTS after the JSR SETVBV.


Potential problem you might see is that the DLI might execute first up before the VBlank (and not necessarily the first of multiple DLIs).


You can avoid that with something like a wait:


  lda $14
  cmp $14
  beq waitvb
  lda #$c0
  sta $d40e ; enable DLI when VBlank finishes

#3056559 SIO2BT

Posted by Rybags on Tue Aug 19, 2014 8:06 AM

I steer clear of anything to do with Apple.

#3055706 SIO2BT

Posted by Rybags on Sun Aug 17, 2014 7:48 PM

Cool... if the price is right this could become the predominant SIO upgrade.  I have a second cheap smartphone just gathering dust that could be serving up Atari files.

#3055201 Remember what you put in the garbage 25 years ago?

Posted by Rybags on Sun Aug 17, 2014 1:55 AM

Just under 20 years ago before moving I chucked out a crapload of Page 6, ST User and other assorted magazines of the era.

2nd-hand bookshop wanted nothing to do with them, and I had nowehere to store them.

#3052038 What's your favorite text based game?

Posted by Rybags on Tue Aug 12, 2014 9:12 AM

I wasn't much into them and Infocomm adventures the only ones I thought worthwhile on home computers at the time.


Probably Zork 1, Hitch-hikers Guide, Zork 2, Zork 3 in that order.

#3049521 [ATARI 800XL] Using extension bus

Posted by Rybags on Fri Aug 8, 2014 12:29 PM

I think the 74HC are best suited but someone more knowledgable could confirm.


I guess with the propogation delays... add up to get your worst-case scenario.  1 cycle = about 558 ns, you want to get in under half that.  I remember reading that the longest acceptable latency for RAM was 250 ns.

The PDFs for the custom chips Pokey & GTIA have the timing diagrams showing the relationship among Phi2, r/w, CS etc.