Rybags
-
Content Count
17,507 -
Joined
-
Last visited
-
Days Won
3
Posts posted by Rybags
-
-
The OS only checks for contiguous RAM when booting. So, the only way to have it see 52K of RAM would be to have no cartridge inserted.
I don't know if BASICXE will recognise that type of RAM upgrade (if it's actually installed).
-
The motor should spin up on the 1050s if you open/close the latch.
Next step is to check the drive ID switches (recessed at the back of the drive).
Both switches should be to the left (to ID it as drive 1).
-
Just powering on the Atari with the 1050 connected should give a BOOT ERROR at least.
Sometimes the cables play up and you have to jiggle them.
Next thing to do is build a SIO2PC/APE cable:
http://www.geocities.com/atarimods/howto-sio.html
It's a reasonable simple project, the 1489 IC is widely available through electronics outlets.
Then head to http://www.atarimax.com and grab the latest version of APE.
There are posts all over the place on these forums pointing to ATR disk images and DOS downloads.
-
Most >48K memory upgrades on the 400/800 map 4K banks at $C000-$CFFF.
Try POKEing and then PEEKING 49152 to see if there's RAM present.
-
The RF shield comes off easily. You have to pull the motherboard out of the case first.
It is probably an even tighter fit than the 800XLs, but I find that pulling the white plastic above the joystick and serial ports helps to ease it out.
Then, just bend the metal clips straight and you can unscrew about 6 screw/nuts. There are 2 shield pieces and 1 little bit which acts as a spring clipping mechanism for the PBI.
Static is less of a problem than for modern hardware but still, handle the motherboard by the edges.
-
http://www.atarimagazines.com/v3n2/anatomy.html - inside the 800XL.
http://www.atarimuseum.com/computers/8BITS...o/600proto.html - early 600XL prototype
There are at least 2 different keyboards for the XLs. When I had a 600XL, it had the nice positive feeling one with the stepped rows. My 800XL has the flat one, with mushy feel. The console indicators were different too from memory, but both have the text on an underlay beneath the clear plastic.
-
It's easy to build or buy a monitor cable to convert the 800's 5-pin plug to S-Video and/or RCA A/V.
http://www.geocities.com/atarimods/supervid2.html - scroll down, there is the pinout of the Atari 800 monitor socket. For an RCA setup connect gnd/composite to the outer/inner of one RCA cable.
For an S-Video cable, use gnd and the chroma/luminance lines. Audio is seperate if a S-Video cable is used.
The 7800 is a different matter. Internal mods would have to be performed.
As for switchboxes, I've seen ones that allow switching between 4 or so A/V input sets (ideal for those with modern consoles).
An alternative would be to just run the 7800 through a VCR.
-
Sounds interesting. You can post pics yourself. Just select "More Options" next to the Reply button.
Then upload each pic and select "Add into post".
My SIO cables are Chelco. Maybe they just did the casting of the plastic cases.
-
It won't be feasible to have too much DLI action happening. At best, several playfield color changes for the whole screen. Rendering up to 4 robot playfield sprites against static background objects will use up most of the machine cycles available.
Due to the fact that the player does sommersault jumps, changing the colors of it is not possible.
I just had an idea for the collision detection. The missiles could be used as P4. They could then be cycled between laser bolts and underlayed on the robot closest to the player. Flickering would occur but with the laser bolts it would not be a problem.
-
I've been contemplating a conversion for over 3 years. So far all I've done is some theoretical planning, and ripped/converted the player sprite animations.
Sample video (just open the .AVI inside the zip file):
The animation and movement is a bit jerky because it just uses a BASIC program to control paramaters that the VBI uses to create the sprite. I did a quick&dirty rip of the player sprites by vid-capping in WinVICe and just doing run/jumps against a wall, then using VitrualDub to output each frame into a .BMP file.
The problem with using PMGs for the player sprite is that to be faithful to the original, all 4 players would have to be used.
That would mean that software sprites would need to be used for the robots and floating ball, and the missiles could be used for the robot's energy rays.
An alternative would be to do the player as a software sprite, although with around 25 sprite definitions for the player running or jumping in each direction it would be fairly memory hungry. The advantage of doing so would be that the 4 players would be free to render the robots in multicolor PMG mode (there are only 2 rooms where 2 robots appear at the same vertical location, and the robot sprites are only 7 pixels wide).
For the background graphics, multicolor mode 4 (40x25 5 colors) would probably be the best bet. DLIs would allow reusing the 2 colors that the floors use for the furniture and other objects.
Collision detection would have to be done in software. Since the robots have basically the same shape in each animation frame, it makes it a lot easier.
With some tight coding the game should easily fit into 48K. Small memory machines would have to miss out on the digitized sound effects, and possibly have extra disk accesses.
-
I acquired the unfinished prototype.
It also goes some way to explaining the dreaded screens we see on todays systems...
-
Ebay is a good source to find original software.
Things to buy: at least 2 joysticks if you don't already have one. I still have a Wico I bought almost 25 years ago. Probably the most durable piece of computer hardware ever made.
An extra disk drive would also be a wise investment, but getting an SIO2PC/APE cable would mean you could semi-retire your floppy drive.
5200 games don't work directly on the computers. Some games back in the mid 1980s were released exclusively on that system. Many were converted soon after being released by hacking crews. Hardware on both systems is mostly identical except for the controllers and the addresses that the hardware is mapped to. The current situation is that many people are now converting games from the computer to the 5200.
-
http://www.geocities.com/atarimods/supervid2.html - scroll down, there is a pinout of the monitor socket.
Note that the pins aren't numbered sequentially.
I've built in S-video and 3.5mm audio out plugs into my 130XE. Building an external plug is easy too.
Note that many XLs though don't have chroma output, you have to add it yourself (Step 7 on that page explains how).
No point doing stereo output unless you have a 2-Pokey modded system.
The simplest mod to do would be a composite-out adaptor. Just use 2 female RCA plugs and a 5 pin DIN connector. Solder the outside conductor of both plugs to ground, composite to the inside of one plug, and audio to the inside of the other. All up, should be around $3 in parts.
To have audio on both speakers on a stereo TV, just use a 2 into 1 RCA adaptor.
-
Huge games archive:
Atari800Win+ Emulator for Windows:
http://atariarea.histeria.pl/PLus/downloads_us.htm
Games to download:
http://www.langesite.com/atari/games/
Plenty of 8-bit links here:
http://www.geocities.com/SiliconValley/Lak...t/megalist.html
Get the APE software here - emulate a 1050 disk drive on the PC:
Build the 1-chip SIO2PC interface + other mods:
-
It would just be for general tasks.
With my current setup I have 2 monitors available to the PC, and I view the Atari via my capture card. Remote control would be heaps easier than getting up and going over to the Atari each time I want to enter a simple command.
I might have to investigate one of the options for adding an external keyboard. I could then share my PC keyboard through my KVM switch.
-
Does anyone know if there is any software around to control a real Atari 800 from the PC? ie - send keystroke and joystick data.
Like many people, I've started using the 8-bit with an APE cable, and using my capture card to view the Atari display in a window or on the second monitor.
I can think of 2 possible (relatively easy) ways of doing it:
- through the existing APE interface. Modification to the APE software and/or an add-on program on the PC would be needed. At the Atari side, a small routine would have to poll every 50th of a second or so. The PC could then return keystroke and joystick data.
- through a parallel -> Atari joystick interface. A program on the PC would monitor the keyboard and (optionally) a controller device. Another routine on the Atari would monitor the joystick port/s and store the data in the relevant shadow registers.
With 1 joystick port, 32 combinations could be supported. Or, if the paddle inputs were used, that gives 7 bits (128 combinations). The PC-side program could alternate between sending keyboard and controller data every 50th of a second.
The disadvantage of both schemes would be that Atari-side software has to be resident. The only way to almost guarantee this to work in most cases would be to have a RAM-resident modified Operating System.
I'd have no trouble at all doing the Atari side of the programming, but the PC-side would probably need DirectInput calls, and a routine to take over the parallel port.
-
Changing Pokey to 15KHz mode affects all 4 voices.
The better alternative is to join 2 voices, which gives a wider range of notes available, and leaves 2 voices unaffected.
-
I was having similar problems today with my 800XL. With my machine, it appears that the inner contact on the RF output is worn and/or corroded.
Try rotating the plug or pulling it out a bit.
Of course, the composite video mod would be the go if not too much work is involved (I've never seen a real 5200 - don't think they ever sold here).
-
Armalyte music from C64.
-
If you must do it that way...
10 OPEN #1,4,0,"<picture file>":OPEN #2,8,0,"<output file>" 20 LN=1000:REM STARTING LINE # 30 TRAP 100 40 ? #2;LN;" .BYTE ";:GET #1,B:FOR A=1 TO 8:?#2;B;:GET #1,B:?#1;",";:NEXT A:?#2;B 50 LN=LN+1:REM INCREMENT LINE # 60 GOTO 40 100 POP:CLOSE #1:CLOSE #2
That should work, generating decimal .BYTE operatives, 8 per line.
-
I described it in detail and with examples years ago in Polish disk magazine "Syzygy" (issue #5 I think). If someone is interested, I may translate it here. Real-world example is in my portal engine in Numen, where I use both signed and unsigned variations and 16-bit * 16-bit with 32-bit result too. Using the Russian way it would be several times slower.
A translation and example would be appreciated.
Any hints on division would be great too.
-
I was browsing an 8 bit magazine disk last night and it had an article on Russian multiplication, and how it can be used for very fast binary calculations.
It works as so: C = A * B
Take the operands A and B, and place them into a row. For each new row, double A and divide B by 2 (discarding the remainder). Keep doing so until a value of 1 is reached in the B column
Then, derive the result © by adding up the values in the A column, but only where the B column value is odd.
Examples (values of B marked with # are ignored in the final calculation)
23 x 14 # = 322 46 7 92 3 184 1 === 322 = 46+92+184 (sum the values of A, only where the B column value is odd) 17 x 53 = 901 34 26 # 68 13 136 6 # 272 3 544 1 ==== 901 = 17+68+272+544
Thanks to 6502 shift/rotate instructions, this algorithm can easily be incorporated into programs to multiply 2 8-bit numbers for a 16-bit result. Very handy for games or demos needing quick calculations for graphics.
I did a quick Google Search and dug up some links:
http://mathforum.org/dr.math/faq/faq.peasant.html
Egyptian division: http://www.mathforum.org/library/drmath/view/57574.html
Division would be great too. The formula used is a similar concept, and could also be fairly easily programmed.
-
114 machine cycles per line on an 8-bit Atari (computer, not console). By writing to WSYNC twice in succession, you would halt the processor the second time for just under that amount of cycles.
As for accessing memory every cycle, what about cases like implied addressing? Instructions like INX and NOP use 2 cycles, but only 1 is a memory access.
I didn't know RDY was used for slow PROMs. I just thought it was specifically designed for external hardware to halt the processor.
-
Negative numbers aren't natively supported in Assembler.
If you are using an 8-bit value only, then having -1 represented by $FF is sort of OK, since adding it to any number results in subtracting 1.
But, that won't work for multi-byte binary values.
How you implement your add/subtracts should reflect the purpose you are doing it.
Bounds checking is another issue. Finding an out of bounds value is easy enough, but you have to take more complex corrective action if it's anything more detailed than a transition from 39 to 40, or 0 to -1.
I wrote a multi-PM mover once, which supported 4 players, each split at a number of vertical locations.
I used an 8-bit value for velocity as follows:
bit 7: 1=backwards, 0=forwards.
bits 6-4: velocity of object (which will translate to a whole number from 0 to 7)
bits 3-0: fractonal velocity of object - a value from 0 to 15 which is added to an accumulator variable. If this 4 bit overflows, then the object is moved 1 extra pixel backwards or forwards.
Such a scheme is useful for moving sprites around, but something similar could be implemented for character movement.
The only thing is that I didn't use bounds checking, most games with horizontal motion with PMs work fine with the X-pos just going from 0-255.
This is the game I used the routine in. Sorry, but the source code is long gone, but you could easily enough use the disassembler in Atari800Win to see what's going on:
Load the game, with BASIC enabled, using ENTER "<dev:filename>"
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
The best 8-bit setup
in Atari 8-Bit Computers
Posted
Ideal setup would be an 800 and a 130XE, both with 1 meg RAM expansion.
Incompatibility of games with the XL isn't too much of a problem. I can remember only 3 or 4 of >300 games having problems when the Atari was my only system 20 years ago.
M.U.L.E. is the game to have with a 4 player setup.
You can get multitap interfaces now, so 4 joysticks can be connected to an XL/XE. Not that it is compatible with old stuff, but hacking classic 4 player games to work with it would be fairly easy. Almost all software that uses controllers read the shadow registers rather than talking direct to the HW.