Sheddy

quote: Originally posted by David Wyn Davies: The learning curve on the ST wasn't that great. The biggest learning curve was actually 68000 assembler if you'd just moved up from an 8-bit. The ST's OS was a dream to program - I actually learned to program it in assembler before I managed it on the 8-bit! The Amiga, on the other hand, was a nightmare to program and did have a very steep learning curve. That's why the ST initially took off. I remember Jeff Minter commenting on this aspect of the two machines some years ago. I never programmed ST so I can't say, but if its OS is anything like the Amiga's, it sure would have scared most people used to talking straight to the metal! All those extra WIMP/memory management etc. abstractions to get your head around......(please,just let me write to the screen buffer!)......most of the time on 8-bit all you needed the OS for was to load your program! [ 05-13-2002: Message edited by: Sheddy ]

I think maybe the reason we remember more bad games on the ST is because the ST became very popular early in its life and some developers were keen to rush stuff out the door, knowing that being first would guarantee sales. I think it was around this time the industry started taking more notice of management decisions not to take too many risks with games....and knowing a good licence was a sure fire sales generator whatever the quality of the game. Also, don't forget the ST (and Amiga) was much more complex than what had gone before, and there was a much steeper learning curve to overcome. There were much more ambitious titles on it, with a correspondingly greater risk of being unable to perfect them.

You guys sure it's using fractals, anyone looked yet? Although I haven't looked at the game in a while, I would have thought something simpler could have done it?? Still it is a fine game, but I remember it being very difficult (but that's just me I expect!) and also frustrating because of the "dead body" rule (where you killed something and its explosion gets you instead - although I guess that's kind of realistic) Must check it out again though (we wore out the original disk!) [ 05-12-2002: Message edited by: Sheddy ]

Looks like Albert has just posted some news for some good references.www.atariarchives.org Also a recent 8-bit thread may help out. 8-bit programming.... [ 05-07-2002: Message edited by: Sheddy ]

That character unscrolling should work nice, cool! So who's going to do this game then? You seem to have it pretty much figured already El Destructo. Then David can try Elite if he really has his heart set on it. (But I wouldn't count it as a real biggie project unless he promises not to peek at the original BBC 6502 code) [ 05-07-2002: Message edited by: Sheddy ]

Atari800Win Plus 3.0 has a half decent disassembler built into its monitor too. No good for extracting a whole program though (well, you could mark,copy,paste every page...) But on the plus side you can play with changing simple stuff while the code's running. Heaven posted he was doing this recently to Zone Ranger to figure out his Time Pilot sprite engine. [ 05-06-2002: Message edited by: Sheddy ]

Although I'm not up to speed on all the latest 2600 goings on, I'd have to put in a vote for David Crane too - pretty consistently good stuff. Also a nod to Thomas himself (no blushing, please Thomas!) - Thrust is a mighty fine achievement for a 2600. (Mind you, getting anything much out of the machine is also a mighty fine achievement) Nukey, you did some stuff? Please tell

Sad news indeed, if Jet Boot Jack really decides to go The 8-bit and programming at least will sure be worse off without him. On a slightly more upbeat tone... sounds like there was some real interesting stuff in the pipe-line so I can't wait till the Harlequin archive is available. [ 05-04-2002: Message edited by: Sheddy ]

It only looks good because I'm stupid enough to try using interlacing, which has given mixed results (no pun intended) In 4-colour mode (which I have to consider now) it's no better than anything else, so you must still show us your stuff Steve!

quote: now DLIs work in the kernel routine... (well...i switch for speed reasons the complete ROM OS off...so thats why i had to modify the kernel routine for DLIs as well... thanx Fox for help!!! ) The OS also steals your precious RAM! [ 05-03-2002: Message edited by: Sheddy ]

That's a brave offer David! I'm a big shoot-em-up fan so I'd have to say side-scroller too (anything similar to R-type), or how about Mad Planets/Crazy Comets (not sure how well the controls would translate though, but it was on C64). Steve (Jet Boot Jack) may be able to fill you in with some more info on what ever happened to Beast - he mentioned it in a post, and it was Harlequin he was involved with.

There are some good articles on many aspects of atari 8-bit machine and programming (basic and assembler) in the Digital Antic Magzine. Seeing how the small examples work and trying some simple stuff first is a good way of getting into it, especially with assembler. The references David pointed out are excellent. You'll also want to read up on programming in general, about data structures, common algorithms etc, when you want to tackle something bigger. I can't actually think of any specific reference places for this, although there is a lot about from a casual google search on algorithms or programming.

Some interesting (and slightly worrying) stuff there David, certainly it's something I would need to consider carefully too, if I ever got anywhere near releasing the game. Thanks for the info

Just for complete clarity: I didn't start the topic. But I have had some pleasant previous e-mail conversation with Nir, and noticed he had joined this board to clear his name. Some of my projects may be "UNOFFICIAL" but the intention is that they will never be sold (but no license, still technically illegal, I suppose). I guess I was thinking out loud, with huge carts merely a hypothetical possibility of getting something working for 64k ataris. The prospect of Loopz development resurrected - Excellent!

Nice to know it's possible, guys. Maybe oneday the program will be ready to put in this big a cart! I know nothing about bank-switching carts though, that would be custom to each cart design I suppose.

Nir, what a welcome to the board! Glad you have cleared up the misunderstandings. Maybe I should start a new thread (or do a google search), but was there ever a "standard" 256kb cart for 8-bit, I know there were some 128k ones, but were there ever ones that big? If not, is it possible to do easily? (hypothetically) Chris

It's a cool engine, maybe you can get 50/60 frames per second, with luck (and skill of course! ). It really does looks ideal for Time Pilot - Can't wait to see more. I'm just sad I can't steal more of its tricks too - (but I saved 450 cycles on my background drawing using self modifying code inspired by it) Do you know how you're going to do the clouds yet? I take it you're using all the player/missiles just for extra colours now? Chris

A small Work in Progress update: www.sheddyshack.co.uk Chris [ 06-02-2002: Message edited by: Sheddy ]

Congratulations! You are the best.

Not much time to look at it but........... Looks like Zone Ranger has sprite copy pretty optimized from your fragment. no indirect access to screen, no add to next screen line, x reg for the x pos on the screen, y reg for position in sprite strip. But how does it exit when done? Does it self modify the code? Makes sense to use indirect y rather than x. Working with the y register not against it. iny only 2 cycles inc zp 5 cycles... Chris PS my routines not optimized for fixed width they'd be not as fast as this for time pilot Guess this should go here now too.... quote: Heaven, no big deal on the masks. just an "or" then an "and" with the mask. slower than eor of course though... the mask should have bits set when there is a seethrough pixel in the data though, otherwise the mask bits should be the same as the data, for the most straightfoward "seethrough" effect. some eg using 2 bit pixel, data ends up on top: screen pixel=00, data pixel=01, mask=01 01 or 00 = 01. 01 and 01 = 01. screen pixel=10, data pixel=01, mask=01 01 or 10 = 11 11 and 01 = 01 screen pixel=10, data pixel=00, mask=11 00 or 10= 10 10 and 11= 10 If anyone knows a better way, now would be a good time to share! Of course you want to avoid masking at all if you can...you could draw the big clouds with no masking, then underlay the enemies, using the same method. PS I don't think having a wider, shorter normal "landscape" screen would affect the gameplay much - Unless you're going for arcade exactness, or for speed/memory reasons. [ 04-22-2002: Message edited by: Sheddy ]

Heaven, no big deal on the masks. just an "or" then an "and" with the mask. slower than eor of course though... the mask should have bits set when there is a seethrough pixel in the data though, otherwise the mask bits should be the same as the data, for the most straightfoward "seethrough" effect. some eg using 2 bit pixel, data ends up on top: screen pixel=00, data pixel=01, mask=01 01 or 00 = 01. 01 and 01 = 01. screen pixel=10, data pixel=01, mask=01 01 or 10 = 11 11 and 01 = 01 screen pixel=10, data pixel=00, mask=11 00 or 10= 10 10 and 11= 10 If anyone knows a better way, now would be a good time to share! Of course you want to avoid masking at all if you can...you could draw the big clouds with no masking, then underlay the enemies, using the same method. PS I don't think having a wider, shorter normal "landscape" screen would affect the gameplay much - Unless you're going for arcade exactness, or for speed/memory reasons. Regards Chris [ 04-19-2002: Message edited by: Sheddy ]

Makes sense Dan. Not much point taking the timing further if all the 5200 stuff already works fine with that. I guess only a handful of even all the other 8-bit stuff around would ever rely on any tricky mid-line timing. look forward to checking out the new version

Steve's had a lot of experience doing different things, so I hope he's come up with some good stuff for how to do this game. What you are thinking seems reasonable enough for doing with character mode. But just a few thoughts spring to mind...just speculation, only to think about.... Seem to be a lot of clouds for just PM graphics (although maybe if chunky and single colour...). Suppose you don't really want to try multiplex them vertically, if you still want to keep a parallax effect. Maybe in character mode, big clouds as characters and playfield scrolls around? Yes, too many enemy planes for PM graphics. But, what about PM graphics for parachutists and Boss planes?? Chris PS Nice trick with the 96*256 to speed the sprite routine.

Dan, actually, the cycle counting sounds really complicated for the emulator. How are you managing that? Is it fast enough to actually simulate every exact cycle as the beam crosses the screen, or do you have to do some housekeeping at the end/beginning of every line, to make it all even out right? Whatever way, it's all very impressive. You have any plans to support other 8-bit models in the future? Chris

If anyone's interested there's some detailed stuff re that on Dan's own site in De Re Atari Manual. Check out chapter 5. It's an excellent referrence for 8-bit Cafeman, From what I can gather (people, please correct me if I'm wrong), you may not have an "overrun" there. The DLI happens towards the end of the current line, so a WSYNC delays it till the next line down. (In character mode maybe not quite that straightforward) No need to worry about the timing too much. Just do any colour change and WSYNC early, Then you have a little time left for other stuff. Only if there are blank dlist instructions will antic not be stealing. It will be having to get your black data. Chris PS Keep up the good work on Koffi. [ 04-16-2002: Message edited by: Sheddy ]