playsoft
-
Posts
656 -
Joined
-
Days Won
3
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by playsoft
-
-
The 24 byte cartridge "header" is located at $BFE8..BFFF containing 20 characters for the title, 2 for the year and 2 for the run address.
If the second year character at $BFFD is $FF it indicates a diagnostics cartridge which on initialisation jumps immediately to the run address instead of going through the full initialisation process with the Atari rainbow display etc. Full details in Claus' article: http://www.atarimuseum.com/videogames/consoles/5200/conv_to_5200.html
-
I was able to reproduce it - it occurs when you've got far enough in the game that the snake starts planting red saucers.
It's a bug from the original game. There is a table of screen addresses and when it plants a saucer (at the bottom of the screen) it reads beyond the end of the table and ends up incorrectly writing to zero page locations. Once the saucer is bouncing around the screen it is fine, it is only the initial placement of it where the issue occurs.
The 5200 and A8 use zero page differently which is why the bug is more evident here, although it could still lead to problems on the A8 original.
I made the table of screen addresses longer and it now seems fine, as far as I can get in the game anyway.
-
This is a 5200 version of Alien Swarm with JAC!'s fixes as described here: http://atariage.com/forums/topic/224914-alien-swarm-hack-request/
Instructions can be found here: http://www.atarimania.com/game-atari-400-800-xl-xe-alien-swarm_202.html
JAC! provided me with the source code which I've modified for the 5200 and tested on my 4-port with Atarimax Ultimate SD.
Edit: updated version below
-
1
-
-
There is no source because a tool converts them from an A8 Rasta Converter executable. There is some code in there which checks for user input which should really have been removed because if it gets any it will RTS and crash. So although on Altirra or Atari800Win Plus or real h/w the image will display ok, if you press the trigger it will crash.
Each image will use different amounts of memory so I can't say for sure, but if your RTS is at $9492 then I think you'll find the user input check around $9463. It should look like this (with different addresses):
A364: AD 10 C0 LDA TRIG0
A367: F0 13 BEQ $A37C
A369: AD 11 C0 LDA TRIG1
A36C: F0 0E BEQ $A37C
A36E: AD 1F C0 LDA CONSOL
A371: 29 01 AND #$01
A373: F0 07 BEQ $A37C
A375: AD 0F E8 LDA SKSTAT
A378: 29 04 AND #$04
A37A: D0 18 BNE $A394
A37C: A9 00 LDA #$00
A37E: 8D 1D C0 STA GRACTL
A381: AA TAX
A382: 9D 00 D0 STA $D000,X
A385: E8 INX
A386: D0 FA BNE $A382
A388: A9 FF LDA #$FF
A38A: 8D 80 02 STA $0280
A38D: A9 40 LDA #$40
A38F: 8D 0E D4 STA NMIEN
A392: 58 CLI
A393: 60 RTS
A394: 4C 1E 78 LA394 JMP $781ERunning through the above code in Alrirra (without pressing anything!), TRIG0 returns $01, TRIG1 returns $01, CONSOL returns $0F and SKSTAT returns $FF which avoids the RTS. Atari800Win Plus returns the same.
I couldn't work out how to repeat this in Jum but of those locations I guessed at CONSOL because you wouldn't normally expect to read it on a 5200. I wrote a program to repeatedly read CONSOL and it returns $00. I hacked one of the files to avoid the CONSOL check and it no longer crashes, but it does not display the image correctly.
So if you change a read of CONSOL to return $0F it should not crash at least. The way the Rasta Converter images work is that the 6502 is precisely timed to the display and changes the h/w registers at the exact moment necessary mid-scan line, I don't know if that might be the display issue here?
-
2
-
-
These are some of the early versions:
(1) ag.xex - the initial NYD 2013 version.
(2) ag2.xex - adds control and missiles, no collision detection.
(3) ag3.xex - Harvey joins, include his first sprite designs.
(4) first_bg.xex - shows the early background designs from the first version of the editor where screens were composed out of 4x4 character tiles. Other than the café wall illusion, I think the other designs were all mine so you get an idea of how Harvey has improved the look of the game.
-
3
-
-
Since Mario has found his way here, my initial intent after being inspired by Crownland was to do some sort of Mario game as you can see by the sprites included in my original multiplexer demo (test.xex) which I released with the player editor tool. I never got around to doing anything though.
-
3
-
-
MrFish, on 22 Jul 2014 - 02:34 AM, said:
Crownland is an amazing piece of coding. There is no small amount of work on the graphic design side either, and Miker did a great job creating music for the atmosphere. Some people leveled criticism against it here, after it's release, for some of it's shortcomings, because they were disappointed it didn't turn out to be all they'd hoped. Subsequently I think the author was discouraged from doing much further along the same lines. I think he's the same guy that did do some of the really nice multiplexing experiments after that though, such as Ripper, Contra, and SMB, which use an improved engine based per sprite, rather than scanline based as Crownland's engine was. I think these were done in part to answer some of the criticisms about the multiplexing sprite engine used in Crownland. Ripper bears some relation to your project, in that it's a vertical shooter and uses multi-color sprite multiplexing. It has some nice backgrounds by way of quite a few DLI color changes too. Maybe you've seen it already?
It was 2011 when I discovered Crownland and I was in awe of all aspects of it. And yes, the music is great especially that first track which is so catchy.
It had never occurred to me, nor had I ever heard of, the idea that when you have too many sprites to display horizontally you simply draw different ones each frame. When I figured out that's what Crownland was doing, I had to dig out the 8-bit and have a go at writing one myself. I could see that Crownland was drawing as much of each sprite as it could, but in mine I only draw a sprite if it is fully visible. I did that for no other reason other than simplicity and regarded Crownland as the more sophisticated approach. I'd seen the Ripper video before but did not realise it was by the same author. In the other demos it looks like he has gone that route too, so presumably opinion was that it's better to see no sprite at all rather than parts of it?
-
Synthpopalooza, on 22 Jul 2014 - 12:01 AM, said:
I had a couple of thoughts, and I think I might have discussed them with you a few months back ...
You can use a hardware mode that I call Graphics 12.10 ... that is, engage GTIA to mode 10 while in ANTIC 4. You still get all 9 colors, with the limitations of 7 colors per character cells, but it makes inverse characters work better. How it works is, the color combinations PF3 and PM3 replace PF2 and PM2 whenever you inverse the character. Very easy to get tiles with two color palettes here.
Also, I wonder how possible it would be, to do a double font flicker on the scoring bar, switch the font and the mode between 9 and 11 (ICE APAC/Pryzm mode), and have the scoring area be in 256 colors. It would flicker, but since it's not on the whole screen, maybe you can get away with it. You can also change the color scheme if you use inverse characters, set CHACT to kill inverse, and alternate CHACT as well if you want to switch up the color scheme.
Do you have the font set for the scoring area? I may be able to play with it for you in ICE editor.
At the moment there are no plans to add another GTIA 10 level, but if we do then we can try ANTIC 4 underneath.
The status area graphics were just thrown together quickly to have somewhere to put a score. I'm not sure what will end up here, but as the sprites do not pass over it using PMs to colour it would be my preferred option rather than a flicker mode.
I can send you the font if you want to play around with it anyway, and it'll be easy enough to try out anything you come up with, but I don't want to add flicker.
-
1
-
-
MrFish, on 21 Jul 2014 - 9:02 PM, said:MrFish, on 21 Jul 2014 - 9:02 PM, said:
Is this in any way a hindrance to project, seeing you're attempting to exploit the full potential of the machine?
Exploiting the full potential of the machine is really more Harvey's motivation. Obviously I want to make it as good as I can, but for me it was to see if I could write a sprite multiplexer like Crownland and now it's to see if I can write something to the same sort of standard. Crownland was what got me interested in the A8 again, I couldn't believe it when I first saw it.
It is a hard question to answer because it started off as a 48K program, so memory was tight from the start. One example I can give you is that each level has always been comprised of two character sets. After a previous tidy up exercise I offered Harvey a third but he didn't want it. So you could say that more RAM would make no difference to how the levels look today but Harvey's choice may have been down to not wanting to change completed designs.
From my point of view I've not yet had to throw anything out because of lack of RAM. There is quite a lot of bank switching going on, so putting more core code/data in RAM may free up the cpu to do some more work, but to what extent I don't know.
-
José Pereira, on 21 Jul 2014 - 05:38 AM, said:
To a coder it shouldn't be hard and Paul sure can get it.
That ship its already done and with that middle part rotation just adding someting like I said and it quickly fast 4ways moving it would look amazing.
You already have it and its a shame that no one ever thought in using it because its ideal for an end last to destroy.
Ask Paul and see whats his opinion...
It may make it in there somewhere. I did extract it and the robot a while back. I managed to get the robot into a character set quite easily but the mother ship will need some (a lot) of work. That was for putting it in a standard level though, I suppose if it is a special level then things could be done differently. So it's a possibility, although the end level seems far off in the future at the moment!
-
1
-
-
MrFish, on 21 Jul 2014 - 7:47 PM, said:
That's cool. Is the final also planned to run on 16K machines?
Yes, the final version will run in 16K too. That came about when we decided to go the Maxflash cart route. On one hand less people will run it on real h/w because they'll need a cart, but by making it run in 16K makes it of interest to 400/600XL owners too. As it turned out that was a good decision as it meant a 5200 version was possible with minimal effort (the 5200 only has 16K RAM).
The only annoying thing is that before deciding to go the cart route I had a 16K 400 which I upgraded to 48K as that's what we were originally targeting!
-
Sorry, I should have explained a bit about the Maxflash cart files.
They are in ab_maxflash.zip and there are 3 files:
ab.bin is the raw cartridge image that you'll use with Maxflash Cartridge Studio to flash a real cart with the Maxflash Cartridge Programmer
ab.car is the above image with a cartridge header added --- use this with an emulator as it saves having to select the cartridge type
ab.atr is the ATR programming image which you'll use to program a real cart if you do not have a Maxflash Cartridge Programmer
The Maxflash cart version will run on a 16K machine.
-
1
-
-
I would like to thank everyone who has provided feedback, without which there wouldn't be 5200 or RAMBO 1088 versions. There probably wouldn't be any background interaction either without the number of people who voiced it was needed.
The rest of this year will probably be spent doing some tidy up and more foundation work. Next year it will be to try and make something playable out of it. I feel a little daunted to try and match in playability what Harvey has achieved with the graphics but I will give it my best shot.
-
5
-
-
There is a new demo available here:
http://atariage.com/forums/blog/573/entry-11165-atari-blast-demo-july-2014/
Andreas: I managed to use Superpacker/Exomizer to make a smaller .xex file (I'm not 100% sure I did it right, but it seems to work ok on Altirra) but I don't know what you did to make an ATR.
-
6
-
-
There's a new demo available here:
http://atariage.com/forums/blog/573/entry-11165-atari-blast-demo-july-2014/
-
1
-
-
Hi Al,
Glad it worked! I'd used diagnostics mode because there was data at the end of the cart which I did not want to disturb so it bypasses the BIOS which would normally do these things (clear RAM & h/w).
Paul
-
1
-
-
In this one I've cleared down all the hardware locations too... if this doesn't work I am out of ideas!
Paul
-
1
-
-
Albert, on 17 Jul 2014 - 4:04 PM, said:
Does anyone have any idea what could be causing this?
Thanks!
..Al
It's uninitialized RAM. You don't see the issue on an Atarimax since the loader will clear memory. You don't see it on Altirra either... unless you select Debug -> Options -> Randomize Memory At Cold Reset.
I've cleared down memory during the initial boot and that now runs in Altirra with the above option selected, so hopefully it'll work on your cart now.
Paul
-
An untested one, also missing one of the paper roll spindles, sold for £51 on ebay in the UK recently:
Let me know if you'd consider shipping to the UK as since returning to the Atari 8-bit I have wanted one, although I am not sure why. I am not a collector and can't see myself printing much with it, but I suppose it's because I used to have one back in the day and have fond memories of using it.
-
I'm disappointed not to see the dancing girls animated as I found them the most recognisable of all the images. It would have been interesting to see if fluid animation lessened the impact of the coarse resolution.
Although no game was released, I don't think it was a complete fabrication. It looks like Pete has a software graphics mode working, has written an editor/converter for it, has sprite routines partially working and has put together all those background images. So some development effort has been spent to get this far. Under normal circumstances there would be more positive responses but unfortunately the bravado sales pitch backfired.
-
KABOOM
in Atari 5200
Blue Azure, on 08 Sept 2013 - 12:45 AM, said:Thanks for the update Bohoki. I haven't opened my stick or taken a photo yet, so unknown what's in there. It's a bit of a pain to put it back together so I'll probably wait on that one. The stick works so why mess with it? It seems the speed that the controller can go across the screen is about right to me. Too slow and you can't fetch the harder bombs to get.
I have updated my KABOOM disassembly as I know the function of a few of the bytes, approximately 6 bytes I know what they do, just 4,090 more bytes to go (!,?). And there were a few adjustments to clean things up a bit. I attempted to find things like adding lives count and invincibility but didn't get anywhere. So that probably answers why no one has been able to crack this one. I think it was B'atari who claims correctly you can delete the 1812 overture by no opping one command: change the data at $BC8A from $8D$02$E8 to $EA$EA$EA. I much prefer the game this way. I doubled my all-time high on the first game without the music. You can also delete the burning bomb fuse sound but then the game doesn't make any sounds until you lose. You can see the sparse comments in the disassembly to see what we have so far. I also found some code that's part of the death sequence, which will aid me some day when I attach a logic analyzer to find out where/how the death occurs.
KABOOM_5200_4K_DC07_Disassy1.rtf///blueman///
Referencing your disassembly and playing around with Altirra, the number of buckets is stored at $90. So if you modify:
B937 DEC $90
B939 BNE LB947
To:
B937 JMP LB947
B93A NOP
Then you should never lose a bucket.
Also the x positions of the bombs are stored at $A4..$AB and the bucket at $89 so you could do something like the attached...
-
Could be that the controller pot inside the machine was mistakenly adjusted instead of the colour one since they are close together.
I'm sure there's a post on here somewhere explaining how to adjust it but I couldn't find it - found a youtube video though: http://www.youtube.com/watch?v=NoaiF-xqzEg
-
1
-
-
Thanks Paul, your version is working great on mine as well. There were some pole position hacks in the hack section to add new tracks and also hacks that added new tracks but also sped up the game as well. Is there any chance of getting these to work with a joystick also? Here's a link to the thread
http://atariage.com/forums/topic/120642-pole-position-x-courses-hacked-to-a-5200-rom/
Thanks,
Mike
There seem to be quite a lot of them! If based on the original cart then they should all fix up in the same fashion - I'll take a look later in the week.
Paul
-
1
-
-
It's not an uninitialized variable, it is the PP joystick detection code:
6011: A9 00 LDA #$00 6013: 8D 1F C0 STA CONSOL 6016: A5 11 LDA $11 6018: C9 E4 CMP #$E4 601A: F0 04 BEQ $6020
It's disabling the joystick and expecting to read back a POT0 value of $E4 if one is connected (or rather a track ball is not connected). That logic is correct, what's wrong is that the shadow POT0 location ($11) is not updated until the next vertical blank. So rather than reading the POT0 value with the joystick disabled, it is reading the POT0 value from whatever the previous state was.
When I tried it on my Atarimax Ultimate SD I did not initially see the problem. Only after I enabled the "Game Quick Start (bypass BIOS)" option (from the * key menu) did it occur.
So that is one thing to try, disable the Quick Start option if you want to run the original ROM. If you've already tried that and it didn't work perhaps you have older Atarimax firmware. My version numbers are:
hardware version 20110115 bootflash version 20110115 menu version 20110115 firmware version 20130504
I added a bit of extra start up code to disable the joystick and wait a few vertical blanks. This means the shadow POT0 location already contains the disabled value by the time it gets to the dodgy detection code. This was ok on my Atarimax with Quick Start enabled.
-
9
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
What made crownland so colorful?
in Atari 5200 / 8-bit Programming
Posted
I'm not sure about it being a universal sprite multiplexer but attached is my code.
I'd done nothing on the A8 for over 20 years, happened to see Crownland on youtube and couldn't believe it. That was the impetus for seeing if I could do something similar with the sprites.
It's based on what I knew back then, the usual interrupt to update the registers each character row. I have a draw list (actually two, one for each player pair) which for each row indicates which sprite (if any) occupies that space. It's double buffered and each frame the non-active draw list is cleared and a pass made over all the sprites in a random order. If all the character rows a sprite needs are free, it books them. Otherwise it tries the draw list for the other player pair - if that is not free then the sprite is not displayed. Next frame the same process occurs but as the sprites are processed in a random order hopefully it's not always the same sprite being dropped when a conflict occurs.
In demo1 it uses a DLI, in the others it uses a Pokey timer. I swapped when I started vertically scrolling but that was probably unnecessary as I could have just adjusted the first screen row based on the vscrol offset.
As the interrupt updates a number of registers I leave the top two lines of sprite data empty. Initially I used Pokey in 15kHz mode for accurate screen timing but I was unable to come up with any satisfactory sound effects. So I switched to 64kHz and approximated the screen position by alternating between waiting too long and then too short a time. The two blank lines at the top of the sprite seem to give me enough wiggle room (the demo released in July uses 64kHz Pokey http://atariage.com/forums/user/16447-paul-lay/ ).
The 3 demos folders are all buildable using cl65. This was the first time I'd ever built A8 code on a PC and you can see that it wasn't until demo3 that I'd figured out how to do it with no C code present at all. The other folder contains the current multiplexer code I am using in the ongoing cart version.
sources.zip