Rybags
-
Content Count
17,507 -
Joined
-
Last visited
-
Days Won
3
Posts posted by Rybags
-
-
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.
-
You could just use the 8-bit computer emulator and write a short program to display the ROM image in a bitmapped graphics mode.
e.g
10 GRAPHICS 6:SC=PEEK(88)+PEEK(89)*256 20 TRAP 100:OPEN #1,4,0,"<rom image filename>" 30 FOR X=0 TO 19:FOR Y=0 TO 79 40 GET #1,C:POKE SC+X+Y*20,C:NEXT Y:NEXT X 100 STOP
That program should display 1600 bytes worth of data on the screen. Since that mode maps 1 bit per pixel, you should be able to see where the sprites are.
To skip over a number of bytes, just insert an extra line:
25 FOR A=1 to 1600:GET #1,C:NEXT A
-
The fact that you get a boot error indicates that the drive is communicating with the computer.
About the only thing you can do without a disk is write a short program to send a STATUS command to the drive.
And all that will do is send back 4 bytes with bitflags telling you there's no disk in the drive.
-
It worked fine every time on my 800XL, although I have a cracked disk binary file, not the cartridge.
-
45 bytes (or even 44) per scanline in normal-width would be fine, since you never see the last 4.
Not that you'd save much memory, since you lose 2 bytes each for the LMS instructions. Plus, 2 more machine cycles which would put yet more strain on his DLI routine.
-
HSCROL doesn't change where data is fetched from. It just makes ANTIC fetch 8 extra characters, so a 40-column mode will fetch 48.
-
That looks fine. Just a few things:
For smoothness you should change the VSCROL value during VBLANK.
You have DLIs on many lines. How long do they run for? If one runs too long, then the Stage 2 Vblank won't get executed, which means that the system doesn't reload the Display List pointers in ANTIC. Even though you have your JVB setup right, you can still get glitches.
Note that since you have HSCROL enabled that each screen line will have extra DMA. For the first line of a character mode, that leaves virtually no cycles left for DLI processing.
Can you post your DLI code? I would suggest that you ditch any WSYNC stores that it has and replace with a few NOPs instead (just 1 or 2 might be enough). DLIs actually occur on the line before you need them, and a simple sequence like: PHA; LDA #<color>; STA $D01A would change the background color about 16 pixels to the right of a standard width display without HSCROLling enabled.
-
From memory, CTF didn't run too well on the XL to start with.
Just verified that with the emulator. The game still starts but there is some corruption. Seems OK in 800 OSB mode.
-
The game uses narrow playfield, and the first/last 8 bytes of screen data are masked by green PMGs.
That leaves 16 bytes which gets displayed.
I would guess that using 16 bytes per line would be to make screen calculations easier, plus save some memory. Although, I can't see any great advantage (other than memory saving) over using tables to store Y addresses for screen locations.
It also uses an interesting technique to change the DLI vector. JSR to a routine which then pulls the address from the stack, increments it and stores in $200,201, then issues RTI.
-
Driving controllers just generate alternating values on the joystick X axis, just like a mouse does.
-
I remember the first one. It was pretty common and crappy, IMO a cheap ripoff of the quality Wico arcade type sticks, with nowhere near the durability.
-
DOS 2.5 would probably be a better choice. About the same size, supports enhanced density, plus it has a RAMDisk option on 128K machines.
I've got a hacked version from way back that puts MEM.SAV and DUP.SYS in RAM under the OS. Good for 64K machines.
-
Probably OK. I just checked mine (Australian, for 1050).
It's 8.5 V AC, 4.2 amps.
-
Using HDs with the hole taped over, and DD in HD drives is a lottery. HD drives apparently use a less powerful magnetic field, so disks written on them will not always read back properly on DD drives.
-
From: http://www.cc65.org/doc/atari-3.html
3. Memory layout
The default linker script assumes that the BASIC ROM is disabled (or the BASIC cartridge unplugged). This gives a usable memory range from $2E00 - $BC1F. The library startup code examines the current memory configuration, which depends on the size of the installed memory and cartridges present, by inspecting the value in the MEMTOP ($2E5) variable. Then the initial stack pointer, which indicates the upper bound of memory used, is adjusted. The load address of $2E00 was chosen to accommodate having a DOS loaded and a driver that resides in low memory such as the 850 R: handler. You can override this behaviour by creating a custom linker config file.
Special locations:
Text screen
The text screen depends on the installed memory size and cartridges and can be obtained from the SAVMSC variable ($58).
Stack
The C runtime stack is located at MEMTOP and grows downwards, regardless of how your linker config file is setup. This accomodates the different memory configurations of the Atari machines, as well as having a cartridge installed. You can override this behaviour by writing your own crt0.s file and linking it to your program (see also Final note).
Heap
The C heap is located at the end of the program and grows towards the C runtime stack.
It's fairly standard memory management just as you might use with BASIC programs.
You would want to alter the load address if you aren't using DOS. You could either or both:
1. modify RAMSIZ ($2E4) and RAMTOP ($6A) to reserve memory above where the screen is allocated. The normal technique is to subtract the amount of memory you need from RAMSIZ, store it in RAMTOP, then open a graphics screen.
2. modify MEMTOP ($2E5,2E6) to reserve memory between the top of the C stack and the start of the Dlist.
Probably best accomplished by having a small routine as part of the binary file which does it before the main program loads and initializes.
-
I would say that if you factored in the XLs and XEs, that over 95% of 8-bit machines have the GTIA. Additional to that, there was an option for owners of older machines to have it retrofitted.
I think the screwed in covers came about once the 800 came standard with 48K. In the early days, RAM expansion was in 8K increments, plus the OS was modular in aniticipation of enhancements later on.
-
If it's PAL, 100% on GTIA. Apparently, the early NTSC (1st 18 months?) had CTIA.
To find out quickly, POKE 623,64. If nothing happens, it's the old CTIA.
I would suspect that the CTIA only had the Rev. A OS, but don't have any info on that.
CTIA also has different artifacting for slim lines in high resolution as well.
Unknown if you can detect the difference in software. The only way I could think would be to put a PM graphic on a fat pixel and test for a collision.
-
1
-
-
Video codecs get integrated into Windows.
They either have an installer that you run, or a .INF file that you Right-click->Install.
There. Just unzip anywhere, then use right-click method. You'll probably have to restart the emulator to get it to pick them up.
-
Get hold of the hacked MS-MPEG4 codecs. http://www.dvd-digest.com should have them.
Or, the Divx codec should work as long as your machine is reasonably fast.
Or, one of the freeware ones like HUFFYUV or LL50.
-
The lack of other formats (single, enhanced) is due to hardware. The 180K format is easily supported since it's similar to the old IBM 80 track 360K standard.
From memory, the only way I could get it to work was to format a never used before disk on the IBM drive, then write to it with the Atari.
-
There are programs around to write Atari disks with a 5.25 drive but they work best for double-density (ie - 180K, 256 byte sectors).
I've tried them with single density but with very little success.
An APE cable is definately the best choice there.
+ you are probably the only person ever to use a MP3 player in such a way.
-
There was also:
Danielle Bunton Berry (MULE, Ozark Softscape)
Kathleen O'Brien (Atari BASIC - contributor, Atari ASMEDIT cartridge)
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Atari 400 keyboard problems
in Atari 8-Bit Computers
Posted
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.