hawk

Yeh, thanks Ken. I'm as much interested in your perl script as I am in your asm. Even though I'm using mostly 'C' from CC65. I'm sure when I get something running, I'll want to optimize parts, and also compress other parts. Cheers, Mike.

i started work on a graphics library for cc65. Not the TGI library, but a custom one that took into account all atari graphics modes, pm graphics, etc... All of the functions are written in C, but could easily be hand-tuned where they needed a speed up. I have textout functions for all graphics modes, blit, etc... Might be time to dig it out and put it somewhere for other people to play with. 944369[/snapback] I'd like to put my vote in for this. I've been playing with CC65 with both the C Compiler, and Assembler. Being a C coder by nature, I think it's great. But I've not been very motivated to use the common platform routines. They don't take the best advantage of the native platform. I'd rather create multiple compilable versions if I'm going to support multiple platforms. Thanks, Mike.

Hi All, I have an XEGS which has the following display problem... When it is first switched on, it has a rolling vertical sync problem which eventually reduces the longer it is switched on, until it disappears. Does anyone have any experience with this kind of display problem that could point me in the right direction? Thanks, Hawk.

Hey thanks very much Cybernoid. I've been playing with CC65 for the Atari, and have found few samples that show how to use it for Atari specific programming. Many samples try and show the cross-platform development advantages of CC65. I hope to put my code out there when I've got something decent up and running. At the moment, it's just a demo trying to impliment a Gameboy style RPG. (I know...YAZG ) I'm interested to see how you integrated RMT using CC65. I will also find the xasm2ca65.pl script most useful. Thanks again. Hawk.

Having pondered this topic for a while longer (and also investigated the various joystick circuits), I have come to the conclusion that for backwards compatibility, it would be better to leave the direction switches and main trigger as they are, and use the pots for the extra button functionality required. Then these extra functions could be overloaded with keyboard keys as well for anyone who does not have a moded joystick. You would still be able to have 5 buttons, but the two buttons associated with the same pot would not be mutually exclusive. One button would always override the other if they were both pressed. Not really a problem, as when using a gamepad, you usually only use a thumb to press buttons...unless you have sholder buttons. I've picked up some NES gamepads to test this theory, and plan to map the 'B', Select and Start buttons to the x and y pots. Mike.

Sure, you'd want to start with an existing gamepad, but for the 8-bit computers, it's a way of getting more buttons on the controller. Admittedly, the software would have to be written for the controller. I think any of the existing "Digital" analog controllers for the PC would need modification, as I believe the resistence that's across the Pot pin is different. (This probably has to do with the source rating of the +5V pin of the joystick port. Mike.

Has anyone played with the idea of modifying a modern multi-button gamepad for the Atari 8-bit. From what I understand, you could use the A and B pots for the directions, much like a Gravis Gamepad, giving you up to 5 buttons on the game pad. (The 4 directions, plus the trigger.) Does anyone know if this is feasable from a hardware point of view? Cheers, Mike.

I understand what you were saying about the double line resolution now, it's to maintain the aspect ratio. What you're saying about the "Hero" is that he has set dedicated characters into which are blitted the background he's walking over, and whatever animation he requires at the time, not limiting me to having to fit all his animations into one character set, and allowing the background to be visible behind him. Thanks very much for that emkay. Sorry if these ideas aren't new, but they're new to me.

The original Gameboy could only do 160x144 in 4 colours. So I figured that Antic 4 would be the best match. However, to duplicate the number and size of the sprites would take a lot of charater sets. I would like to have done the main character using PM, but that would limit me to 16x16 in two colours. Is there any way I could increase the number of colours of of a single 16x16 sprite to 4? I guess another alternative would be to use Antic 14? Then I'd do all the blitting by hand. However this would use significantly more RAM. The console RPGs are relaxing to play, as all commands are via the controller. I guess the closest game I can think of would be Ultima. Although, having looked through the lists provided by Jetset, "The Temple of Asphi Trilogy (1986)" appears similar.

I know some of these games...I remember playing Wizards Crown when it first came out for PC. However it is a lot more detailed than I was thinking. I was thinking more like Final Fantasy Adventure. More story, and less action (You have to remember that beer dulls the reactions ). I realise that storage is probably the main issue with this sort of game. But it shouldn't be too difficult to come up with something similar to this. The challenge is probably more to do with compression of the story and scripting. If I follow the Gameboy style, I only have to come up with 4 colours on screen at once, which shouldn't be too difficult. Hawk.

Hi All, Just wondering if there are any console style RPGs for the Atari 8-bit machines? You know...the beer-n-pretzels style RPGs that you can play with your feet up. I was considering trying to reproduce something similar in style to those that appeared on the Gameboy. Hawk.