Rybags
-
Posts
18,806 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Community Map
Posts posted by Rybags
-
-
One of the most complete Atari 800 games archives.
Generally, the most downloaded games are the best ones.
For someone who's been out of things for a while, I'd recommend Dropzone, Defender, Alternate Reality (+ The Dungeon), Mule, 7 Cities of Gold, Spelunker.
I'd also heavily recommend building an APE (SIO2PC) cable. Fairly simple, just 1 chip and a dozen or so solder connections:
http://www.geocities.com/atarimods/index.html
New 1050 disk drive? About 20 years late there. What to look for? Probably things which don't show unless you open the drive.
R/W head, drive belt, stepper drive belt, excessive noise.
Edit: almost forgot. The write protect sensors have a habit of failing or developing problems, but should easily be fixed.
-
I have a full copy of both the OS Manual and Hardware Manual for 400/800 in factory condition.
But, my scanner is kinda dead, so I can't really scan/upload parts of it.
-
Electraglide
-
Self-modifying code is easily the fastest way.
But you lose a lot of versatility and debugging becomes harder.
A reasonable fallback can be to use NOPs instead of WSYNC. All it means is that you have to do a bit of cycle counting.
You really only need about a 35 cycle delay once the DLI routine is entered. Often, screen DMA will account for half of that, and saving registers, loading the colour values will account for a lot of the rest.
All you need then is to pad out before the first colour store. Don't forget, WSYNC actually halts the 6502 until about 8 pixels to the right of a standard display window, which leaves a reasonable amount of time for doing display stuff.
You just have to remember, you will lose cycles along the way for Display List DMA, memory refresh and PM graphics. You also lose at least 8 cycles more if using HSCROLling or wide-screen DMA mode in hires or multicolour.
Using zero-page for counters and indexes is a must. In fact, you can even use zero-page instead of PHA, TXA, PHA etc. but then it becomes absolutely critical that you don't have any overlap in your interrupt routines.
-
Found your problem. You are on the borderline of using too many cycles before the WSYNC store. Since interrupts allow the current instruction to complete, you get jitters.
Try just replacing the STA $D40A with NOP, NOP, NOP and you will see.
To save cycles, try the code I suggested before. Also, using a zero-page address for the colour index will save a cycle.
-
Converting software to be XL compatible is easy anyway in most cases.
Illegal OS calls are easily found and fixed.
The only other real issue would be code that writes into PORTB, inadvertantly changing the memory configuration.
-
It doesn't matter what value gets written to WSYNC.
Jumping can occur, with 3 causes:
- The 400/800 OS uses WSYNC to generate the keyboard click. The problem with that is that it causes DLI routines to lose their timing.
- IRQs occurring can cause problems. The keyboard IRQ is usually the one.
- If you try to execute too many instructions, sometimes the WSYNC happens too late and colour changes are delayed 1 pixel. Your routine looks fine, but could be sped up a little:
PHA TXA PHA LDX COUNTR INX LDA COLTAB,X Use page two for color table STA WSYNC Wait STA COLBAK TXA AND #7 STA COUNTR PLA TAX PLA Restore accumulator RTI
-
As I remember it, Gorf ran fine on my XL. Although I have it as a binary file so it's probably been hacked/fixed.
It would be theoretically possible to just load the translator then insert a cartridge, but I don't know if it will work.
-
I think they released the source to it. I know that you can get PD Doom, and it has been ported to the Amiga.
Plays fine, although that's on an emulator running at unlimited CPU emulation speed.
It would theoretically be possible to do a simple 3D game engine. Look at the Numen demo as an example.
Graphics 10, using the VSCROL trick allows an 80x48 display, which = 1920 screen bytes to be manipulated.
Or, it could be done in character mode with GTIA mode enabled. Less data manipulation but you might run into character set limitations.
-
They would need to come down. I've seen the classic Namco arcade systems (~ 5 games, Galaga, PacMan etc). going near half the FB price.
-
Very weird that it would still have a READY prompt if you swapped the ROMs.
All versions run at $A000, and swapping the ROMs should stuff up the normal cartidge flags/vectors for starters.
A dodgy solder joint or trace could be the culprit? Do you have another 8K cartridge you can try the ROMs in? Or, you could take the ROMs out again and run a multimeter between all the edge contacts and pins on the chip sockets.
-
I'm in Canberra. I have original hardware but these days I just use the emulators a lot.
Old stuff I've got:
Atari 800XL. Bought new back in 1984.
Atari 130XE. I picked it up a few years ago for all of $5. At the recycling depot at the rubbish dump. Works fine, I've added S-Vid and audio plugs to it.
Atari 1040ST/FM. I bought one new in 1988 but sold it a few years ago, then was given one a while after.
1050 drives (standard) x 2. First one new from "Computer One" in Sydney in 1984. Second one for $5, same place as the 130XE.
ST Megafile hard drive. 20 meg, I think. Only used it a couple of times.
Commodore 64 + 1541 drive + 2 datasettes.
3x Amiga 500s
1xApple Quaddra (68030). Virtually never used. Boring system, I bought it off the bloke I sold my first ST from.
Various bits of junk of the modern era. Aside from the main Athlon XP2400+, about 8 PCs varying from Socket7s to 370s, most dissasembled.
-
I've found a number of memory upgrades for the Atari, problem is that they are either incomplete or not in English.
Ideally, I'd love schematics and instructions for just putting a 1 meg SIMM into an 800XL or 130XE.
I did the Super Video mod on the 800XL. Didn't turn out so great.
But on my 130XE, I added S-Vid and 3.5mm audio outputs. The quality jump just from that is enormous over RF video.
-
Can you do a System Reset OK once BASIC has started?
Maybe the cartridge just has a solder joint gone bad. Pulling them apart is easy enough.
I suppose it's only a 16K machine? If it's 48 or more, you could always just make a boot disk with Rev C BASIC on it.
-
I learned a lot from source code examples. There is heaps around, especially since so much software has been made public domain.
The Atari OS and Hardware manuals are also must-have publications.
For beginner-intermediate skills, try getting hold of BASIC games that use machine code routines. You can use the Monitor in Atari800Win+ to browse the assembly parts.
De Re Atari is fairly helpful too.
But the best method is to actually get in and write your own programs. 6502 is probably the easiest Assembly Language to learn, although you need to string together lots of instructions to do anything useful.
-
One of the big problems with the older computers is that moveable objects are usually 2D sprites with a fairly defined pattern, as compared to more modern games with anti-aliased 3D textured objects.
Once you start moving objects at fractional rates (which you would have to do to get the same speed with PAL/NTSC) you can really see some jerkiness coming in.
I found that I could get the best sprite movement using the following method for velocity control. Imagine the sprite as having a byte as follows for velocity:
76543210 DIIIFFFF
D is a direction flag (1=left, 0=right)
III is the increment component. The number of pixels per frame to move the object to the left or right (as flagged by D).
FFFF is a fractional component. It gets added to a 4-bit counter. If the counter overflows, then for that frame only, add 1 to the increment component.
With variations of that technique you can have multiple objects with unique speeds, and not have to use too much processing overhead.
-
Boulderdash doesn't really need sprites. All animation is done on character boundaries. It does use scrolling though, which easily explains why the C64 version is so much slower.
Apart from that, the only other trick is the scrolling colours in the diamonds, which is easily achieved by either flicking character sets (which both the 800 and C64 do equally well), or just changing the actual character data for the objects which are animated.
-
The problem is that Creative went and changed the design of the initial joyport to include MIDI.
However, I think there are hacks around to fix the problem.
In any case, I'd suggest spending a few dollars, and just going USB.
-
Most games use timers based on the VBI. Although you can get near identical timing using POKEY, I feel it to be a bit of a waste of time, plus you lose the use of 1 sound voice.
Of course, well written software could use fractional increments for sprite movement, and other techniques to keep music the same speed, but in my experience, I haven't really come across any such software.
Machines like the ST and C-64 had the advantage of 100Hz timer interrupts which were built in to the OS/HW, but games tend to ignore them since they're not based on the VBlank interval.
-
I've even heard of "hard sectored" floppies being fine with a 1050.
Modern (OK, 15 year-old) HD disks might pose a problem. Since they are used in higher density configurations, they tend to have a thinner oxide coating, since HD floppy drives use a weaker field.
-
The best thing to do is take the keyboard out and wipe the ribbon edge connector with VCR head-cleaning fluid.
I've noticed that they have a habit of gathering corrosion, which is why certain groups of keys will intermittently drop out.
-
Hint: when you go off on an expedition from your ship, take all of your men, and about 7 food.
If you leave men behind, they will eat food at an enormous rate. Travelling by river is fastest, and it is best to pace your journey.
Once you are established with a good ranking, get as many ships as possible, and just leave some behind (with supplies but no men) at river mouths.
If you are "gentle" towards the natives, they will just eventually ask you to start Missions there. It seems best to leave enough men behind to start a mission, rather than a simple fort.
-
Lack of, or disappointing endings is par for the course for 8-bit games.
Just 2 that spring to mind on the 800:
Spelunker: simple text message with cycling colours. All of about 30 bytes of program code in that one.
Rainbow Walker: I can't remember the ending, but it was anti-climactic.
-
I'd say it's fair to assume that the GTIA was the original spec. The OS supported the GTIA modes despite the chip not being present in early machines.
HAM is very different.
In HAM, you use 6 bit-planes.
The first 2 define the action to take:
00 = normal. ie: use the next four bit-planes to select a palettized RGB value.
01,10,11=load new R, G, or B value using the next four bit-plane values. The remaining components of RGB are used from the previous pixel.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Newbie 8-bit assembly questions
in Atari 5200 / 8-bit Programming
Posted · Edited by Rybags
A cartridge has an end address of BFFF. Assuming you're not using bank-select trickery, then it either starts at B000 (4K) A000 (8K) or 8000 (16K).
There are flags and pointers you must set.
BFFE/F = initialize pointer (or run address for a diag cart)
BFFA/B = run address for a normal cart.
BFFC should = 00
BFFD should = 01 for a diagnostic cartridge. It is run via BFFE very early in the initialization stage.
02 for a normal cartridge. BFFE is an init address, BFFA contains the run address.
Many games use 02 in the BFFA flag, but don't return after the INIT call. This allows an almost full system initialization, but prevents cassette and disk from booting (which for games was an extra method of copy protection).
Normal 6502 IRQ/NMI/Reset vectors are at $FFFA, and aren't affected by a normal cartridge.
The main thing to remember with a cartridge is to make sure the vecors/flags are present at the top of the ROM. So, if you only have a 7K program for example, you would have it's .ORG around $A400.
But in a development environment, you might find it easier to build executable binaries which load from disk.