Sheddy

I thought exactly the same. I'm already using widescreen in SH - but I'd get a couple of missiles back with the fine scroll on. (Still need some missiles as the screen is not tall enough to look right at normal width) I hadn't noticed the PMg - I'll have to have a closer look at how everything is working!

Hoped that would be easier Right for run ($2e0/$2e1) but what about init ($2e2/$2e3)? Guess i have to append the files than. Thanks Matthias Yep - INITADD won't work with ATasm if you use it like that. Guess most things can use $2e0 instead - or only call it in the prog after things are loaded. Maybe we should e-mail Mark Schmelzenbach about it though?

You're definitely on a roll at the moment Mark, with all these conversions - The adventures onto carts, and the xl/xe fixes of games. This one does look harder though - So, I guess you will need some luck (and please don't stop Elite either!). Stunt car racer next?

ATasm seems to assemble thing in address order, so I'm not sure you can change that. You could assemble 2 files and then copy them together (one as raw - to lose the header), or use a hex editor? Just curious, but why would you want to see this at the end? The prog will still autorun wherever the $2e0 adress happens to be in the binary file - the $2e0 address just won't be the very last thing that's loaded, is all.

Well Mux, thankyou for the lesson today - I had totally forgotten (or maybe never knew) that Antic retrieves more bytes when the fine scrolling is enabled! In fact I had to double check to make sure I could believe my eyes - and here it is, in De Re Atari - chapter 6. My well thumbed copy of "Mapping the Atari" doesn't seem to mention this at all. This is just such a great way of doing scrolling - and it looks like that was how it was intended to be done all along. I'm sure everyone here wishes you well on this project. I found the same encouragement here last year - After years of being "in the wilderness" with my project, it was like coming home to a warm reception. Only problem is, there's less excuse not to finish, now everything's in the open!

Oh! You are in narrow screen mode with LMS every line - so you are in effect hiding the end pixels to avoid the ends of a line showing the line above or below Very nice by the way. I'm looking forward to a game based on this already. Must have taken a while to get that level data done!

Thanks, that works now. Silly me - of course I needed to have turbobasic to start with! Now to check it out.

Am I the only one having problems? All I get is boot errors with scrprinc.atr in drive 1. But bootsmp3.atr in drive 1 gets a nice super mario title screen - but crashes on F4....

I've never had to write a proper interface before - all my converters run in MS Access with quite a sprinkling of VBA code - certainly won't get a full graphics editor with that very easily! Looks like you got good results with Blitz though, even if it was time consuming. Must check it out, thanks...

Hi Mux, I get it - and the exception lines to deal with the 4K boundaries idea is brilliant! But since I haven't tried it yet, I'm still wondering what happens on the left and right edges. Sure, I get that you put data in from the "hidden" column every line, but what about when things are halfway hard scrolled? Surely without LMS to include the "hidden" column or some way to hide the very end pixels you get half of what's on the next line down, or half of what's on the line above - rather than the data scrolling in smoothly from the "hidden" column. It's probably just my lack of understanding - I haven't done much scrolling in conjunction with the hardware scroll registers. Show us the demo already !

Gunstar is a true purist, but I would think a PC tool fully aware of Atari limitations is going to be easier to work with from an Artist's point of view. A converter tool alone is not enough to take full advantage of MCS. But writing either of these suckers on PC is going to be the problem. I know I couldn't do it without picking up quite a few more skills on the PC.

No, just the exceptional trouble lines. Let me make some demo pics soon, I've got a big load of homework now. Expect something tomorrow. It's not necessary to mask the sides. Just use a normal display, without any Missile tricks or something. ----- mux Thanks - No need to rush

OK - I'm beginning to get it....I think.... surely you still need LMS every line to avoid an ugly mess on the sides, rather than just a standard 40 byte screen, (one line straight after the other)? - or do we use widescreen so you don't see that? Waste some missiles to mask the sides? Or you have something more devious in mind, Mux So the 4K boundary problem crops up this way - but if you know which part of memory it's going to jump "incorrectly" to, you can have that place in memory prepared so it will look right. Way to go, Mux. Nice effort Heaven - but my brain is not in debug mode today though And those strange psuedo op codes you use in xasm confuse my poor little 6502 head when it is working

Still don't get how it could work Mux - you'll have to show us mere mortals an example!

Very intriguing Look forward to seeing how this works.. (Instantly some Q's arise...How can you avoid having almost 2 screens worth of memory set aside without having to do a large copy at some point???) Sounds clever! Hadn't really thought it all through to having double buffered software sprites...mode E - 30K - scary.

Will it work if we scroll back the other way though???..........no, too late for me, can't get my head around it tonight...

I think Analmux is talking about about something like this? I wasn't quite thinking along the same lines to start with, but his idea should work out better. Horizontal scroll: 2 normal screen widths. Grey box is memory area. black box the visible screen. Change the LMS pointers every 16 pixels to next lot. Draw just ahead, and prepare the screen behind. Get to the end of the memory area, and wrap back to the start again. Shouldn't be any problems with 4K boundaries either

Mark, there's always the "Megacart" format - supports upto 8Mbits=1MByte=1024K in 64 16K banks, or the XEGS format, which supports the same, albeit not fully switchable, in 128 8K banks. 256KB is one of the possibilities for both. Much more info in the Atari800WinPlus help under "Cartridge images (CAR, ROM, BIN)" and Jindroush's As to how to actually physically build these things, I'm sorry I have no idea! Sunmark (Super Genius) are making Megacarts, so they may be able to give you some pointers. I believe they use just the one chip even for even the biggest carts. Nice work by the way - I can't believe how many games you've converted or made XL/XE compatible recently. Thanks!

Which aspects are you concerned about in particular, Steve? I haven't ever done this over a full screen, but some things spring to mind that may be helpful (hopefully) Unfortunately there'll be a need to do a fair bit of copying screen memory around in these modes - unless you have loads of memory to waste. You can still hard-scroll over an area slightly bigger than the normal mode D/E screen - Just like mode 4, an LMS on every line. While that's happening you can be working on building up the next screen to display and hard scroll....could get awkward if the player decides, "hmmm, let's go back the other way" though - but of course you may not allow that possibility, and have a one way scroll. If you want any reasonable size of scrollable playfield area without using up loads of memory, you'll need to create your own "tiling" system - IE a kind of virtual character mode - Make all the background composed of blocks of a suitable size - say 8*8 or 16*8, and give 'em a reference number. Then you store the reference numbers and relative positions in a table, and get the drawing routine to scroll through it, and draw them at the appropriate time. It's a lot harder work to do than a character mode, and more CPU is required, but I expect a lot of the clever people here can figure out ways to greatly minimise that load (TMR has done a great side-ways shooter on C64 (which can't scroll the color attributes), so he must have thought about this a lot more than me!) The great thing is, you have complete flexibility over the size of the "virtual" characters this way - you can pick whatever size is best suited to the background requirements.

Very neat, but spooky on picture 3 - I've just started messing about trying to do pics in exactly the same modes but on a standard atari, interlaced. Maybe it won't come off - but if I end up using it in a game, it would be easy to enhance and move over to this great upgrade. Oops, nearly forgot - put me down for a PAL version

I figure for gaming purposes you wouldn't need to handle the whole screen, just certain ranges of lines. For images, you'd do the whole screen. -Bry Agreed, too much for the CPU to handle comfortably, but combined with a vast amount of storage - such as a megacart - it's quite possible to make graphics/soft sprites at least 30-50% faster than "normal" - so maybe less of a problem than you might expect.

what a cool upgrade!

Thanks! You'll have to wait until next week for a reply on any further questions as I'm away on vacation from now cul8r

It'll be great to have some more modern platformers for the old 8-bit. Good luck with it!

Here's the problem: There aren't that many colours to choose from to give things their own unique colours. What we have at the moment is two standard 4 colour atari screens on top of each other to give 8 colours plus some "mixing" colours where pixels overlap. The choices in the current palette are in the pic below. You've got screen A and its colours at the top then in the middle, screen B and then + at the bottom is the result of mixing the A and B colours I should point out that where black mixes with another colour you get the impression of a darker version of that colour (surprise!). But if you just use a colour on it's own (ie with a "transparent" colour), you will get a strange seethrough semi-transparent version of the colour - that's why I have black available on both the A and B screens. The outlined boxes are the representations of the "transparent" or "background" colour, not white. The enemy is flicker in this arrangement - which happens when you get different brightnesses of colours on the A and B screens. For example any of the colours and black flickers worse than say, grey and green - because the grey and the green are the same brightness, but black has no brightness at all. (This is why I cannot increase the brightness of the colours too much, or the flicker because of the contrast with the black becomes worse and worse.) If someone can come up with a better palette with some more interesting mixing (based on the same amount of colours - 4 per screen) - maybe we can do better?