andym00

You said before it would have been more optimal to use a packed LSBs versus packed MSBs, now you're saying there's not much difference.. That difference between the two methods is as best as I can figure something to the tune of 2-3 cycles per sprite assuming an entities x-position is accessed at least once per frame by logic.. In a 64 sprite multiplexer that's 3 or 4 scanlines in C64 slowland, which is pretty far from optimal, and is actually a big difference..

Can't edit the post now, but no worries, it's all clear to me now about this..

Could have sworn it was a Silica Shop, but maybe it wasn't after all.. It was on the far end of the High Street away from the main centre.. But it was a long time ago 25+ years so my memories probably failed me here

And it does this how exactly ?

It offers some redemption I guess

Braben & Bell still get a vote simply because they were pretty much the first to say I wonder what happens when we put all this 3D maths stuff onto a 2Mhz 6502 GridRunner, Hellgate, LazerZone are all top stuff, but I couldn't abide the AMC, RMC, Iridis Alpha and what came after.. The graphical style of the games just weren't my cup of tea, too amateurish.. But Crowther is indeed a one-man games industry The MSX stuff I have very high regard for.. In some of those games they just clearly disregarded the hardwares limitations and just gone for it.. Funnily enough, I've just taken delivery of Gofer no Yabou: Episode II on MSX and it's a great example of how they manage to write some great stuff with properly shitty hardware.. I know it's not politically correct but I envision an office of bandana wearing crazy z80 Japanese programmers writing that thing and wringing every ounce of goodness out of the machine.. I know I'm wrong, but it feels like it to me.. I mean the MSX sprite system is pretty much sub-par to what the A8 can do, yet they still wring so much of the machine it's bloody admirable.. Hell, so it can't smooth scroll, it's only here and there that it actually affects things too much.. I really think that the A8 games should take a leaf from that book and just go for it like GnY:eII (and many Japanese originated MSX titles) do.. Anyway fanboy mode off now..

Maybe it's just me being slow this morning, but I don't quite get what you're saying there.. It's the 'high frequency (sub-frame speed)' bit that's confusing.. What exactly do you mean ? Not true at all, then every man and his dog would have been lazy and just used 2 pixel positioning, which looks pants.. Just look at some Ocean games (as I recall them being mostly guilty of this).. As for being more optimal, the cost of handling the LSB in a sprite multiplexor would have been more expensive than having to handle the MSB.. It would require more code to generate the packed LSB than for a packed MSB, or require messy setting of positions (like swapping around D0 & D8) in the game code which eats cycles.. Having a seperate MSB keeps the code logical, simple and faster at every single stage of the process.. If the code was working with a regular 9bit position in 16bits then the code to extract the LSB, and shift the remaining 8bits into position, is more expensive than just comparing the hi-byte and doing a ROL A to generate the MSB.. Of course you can swap that around and hold the LSB in a seperate byte, but then that makes game-logic code handling positions messier than it should be.. Unless you stored the LSB in D7 to enable you to use the Carry sensibly, but then you've limited yourself to 9 bits of positioning in your game logic when often it's important to have more than that.. So.. They did the right thing I think.. The only thing they could have done would be maybe to give each sprite a seperate hi-byte for the position, but that would have been wasteful, and in 99% of cases not bring any speed advantage to it all.. But hey, either way, it's nice that we got proper full resolution pixel positioning of the sprites, PackedMSBs or not

Ah okay.. I thought given that I'd seen references to Freddie improving the performance of the system that it did something funky with memory accesses.. So it'd be okay to buy a 130XE and it'll behave exactly the same, cycle-wise, as normal a regular A8..

Atari archives has lots of info... One of the best sources is this book: http://www.atariarchives.org/agagd/ Thanks for that, though I'm finding the hardware manual to be sufficient for now, though hard reading as a PDF.. I think it might be time to type up a page like this.. I've got one question for the Atari guys.. I'm programming for a 6502c right ? Which means most of the traditional 6510 undocumented opcodes ? SBX DCP LAX etc ? And that's guaranteed across all the Atari lines ? Or is there some reason not to go down that route ? And one more question (I'll put it here rather than polluting the forum with it).. I saw the thread the other day about the guys 130xe that died, and went reading up on what this Freddie chip is.. I couldn't find much, but if I understand right you can point Antic at another RAM bank, and as long the CPU isn't using the same RAM bank there'll be no contention for the memory given the high speed of the memory, so that means no cycles stolen by ANTIC during display ? Do you still lose refresh cycles to it though ? And is it common to support this in A8 land ? Or have I got this completely arse about tit ? I quite like the A8 already from the little fiddling I've had so far.. I'm especially liking your faster processor, a lot.. It makes me giggle how quickly you can change the border colours compared to the 64

Preppie That for me is the one game that made me want an A8 I love the look of it and that bigg butt ugly font and for me it defined (for me) what the Ataris were, and I wanted one.. Ah. memories of the Silica Shop in Slough... But back on topic, it seems that once the programmers got into their stride that things actually look really quite good, I mean really jolly colourful looking screens that could well be from another platform entirely, but then suddenly they take a dive, and bar a few exceptions the games become rather dull graphically.. I know it's not a completely representative list of games, but that's the picture I get from these.. Around 89/90 suddenly things become not so polished and it feels like not as much effort is going into the games to get really good results from the machine, certainly with regards colour anyway..But that's just me, and I know there's some great looking games in the later years, but they feel few and far between compared to the earlier years.. But maybe it's just my hungover brain seeing it like that this morning through rose-tinted spectacles

Sorry, A8 PMgs are narrower, cover less area horizontally, and are less colorfull, and can not be in hires. And in my opinion are more difficult to multiplex, and not better in most of cases. For gods sake, just step away from the keyboard..

Stupid question, but how can I reset its saved settings ? I inadvertently closed the graphics output window this morning after starting it up, thinking it was an already running instance of Altirra.. Now when I start it up I get no graphics display, just the empty white main window.. Everything seems to be working best I can tell, but the display doesn't appear.. Alt+1 (view->display) doesn't change anything.. How can I get it back ? edit: Okay, I found the settings in the registry, but nothing related to enabling the graphics display.. Okay, I have it now The registry key virtualdub.org->Altirra->Pane layouts->Standard is set to empty when I close Altirra with the graphics window closed.. It never opens again after that.. Deleting the pane layouts key and exiting restores it to its 'normal' value of (1,4,0.00000) and it all works again..

That's mostly meaningless to me at the moment Lots of bedtime reading ahead..

Perfect.. Thanks

Well I've got some time.. How do I make Atari executables from binaries ? What magic data do I need to put in to make it runnable ? And what's the best emulator right now ? I never thought I'd see this day

Edit: Sorry misread.. Since you've entered the IRQ on the last line of the player that was last used for this sprite, you just cross your fingers and hope you're going to get it done in time.. Obviously the catastrophic case is 8 sprites, seperated by one line, then 8 more sprites.. Not much you can do in that case.. I didn't use the not seperated case because then I assume you'd be building big glued together sprites, and that's best done other ways.. No plexer can handle *everything*.. But a common solution I use, is where you'd have that scenario, you offset the sprites by 1 in the Y.. Even in a big 4x4 sprite you'd still offset each sprite column by one in the Y to avoid exactly what you've suggested.. The 64 can handle a lot of that problems, since the Ys can be reloaded before the old sprite has finished, and sprite pointers can be double buffered since they're the top 8 bytes of the screen memory.. But on the A8 you've got less to reload, and the Y-position can't be missed, so even if you can't fall through the 4 sprite handlers in time the worst case is that the x position is wrong for one line, or a colour is wrong for one line.. The plexer isn't going to magically fix everything since you've still got a finite amount of time to reload registers and only a small window to do so in, but you can minimise those effects with care..

Regards the speed issue, surely you're just looking at 8 cycles per player line to copy in, and 4 cycles per line to erase ? That's surely just (including some overhead) about one scanline per sprite ? And it that's too much, move the erasing into the display portion of the screen and erase the sprites in the plexor interrupts ? You know which sprite you've just finished displaying, so after you've set the new player position and colour up, ack your interrupts and then start the erasing of the sprite data and let the plexor interrupt re-enter if you're too slow.. Then clearing sprites doesn't have to be done in the VBL, which'll save you a bit of time.. If you're sprite code is jumping to IRQs for each different hardware player, then clearing is dead simply since you now exactly which strip you need to clear, so it just load an index, load zero, stomp stomp stomp Have each virtual sprite have its own interrupt handler where it knows which sprite it's going to load, then have it update the lo-byte (occasionally the hi-byte) of the interrupt vector as it progresses through to the next one, as I said above, makes the clearing a bit quicker since you don't have to muck about branching off to the correct unrolled code to clear, since you know you're about to erase player 0 data.. As for 2 sorts, I only use 2 sorts when there's variable sprite heights in use, since the allocation of sprites is no longer just 1,2,3,4,5,6,7,8,1,2,3,4,5,6,7,8,etc..... And I wanted to be able to have a sorted list of where the sprites end.. I also use this on more traditional plexers, where you want to glue together multiple sprites without having to have scanline perfect IRQs, and then use the overlapped graphics technique to give you a few scanlines (~5 or so) grace to glue them together.. This means you can then have nice big big sprites on screen, along with lots of little ones very little cost, bar the secondary sort, and the additional handling of a parent link.. And I'd really say don't use 'zones' they will make life hell as you try to work around them when things are not so under your control When you want to load a new sprite, interrupt on the line it was last used, load the sprite, and then check if the next sprite is ready to load in the same interrupt, if so do it I wrote many multiplexers based on 'zones' back on the 80s and everyone of them was flawed in some way, I don't know why it took me so many attempts before I realised that they're just absolutely crap.. Maybe because they seemed easier to manage.. They just never work perfectly, always letting you down in some fashion when you least want it.. Interrupting a few lines early, or on the last line of its last use always works better.. The flickering stuff would work beautifully if you use a 9bit sort key which a 2 pass radix with 4 and 5 bits would do very nicely.. Then you don't even have to worry about it.. Just once you've displayed a sprite in the interrupt, you set it's displayed flag, which is then picked up next time round in the key generation phase as you sort.. You don't even have to take it into account since they'll naturally sit higher in the sort results than the undisplayed sprites.. I wouldn't even call it a ring-buffer since the right results jsut naturally fall out of the system.. Though on the A8, I'd think some other means would be better, rather than simply not displaying an entire sprite, display what you can of it before you have to cut it off, again having priorities in the sort key is probably beneficial to doing that.. Edit: Oh, and one more thing.. The main advantage to having a seperate IRQ for each virtual sprite is that you can pull out all the data you need to reload, and have it buffered in the irq code itself, meaning you're no longer tied to having to try and run the sprite processing logic in the vbl, or trying to use messy double buffered schemes.. The game code sees one constant set of sprite arrays, the multiplexor code as well, and best of all you can run your logic during the main display, not trying to keep it running inside the small VBL time.. The data stuffing pass is dead quick as well, especially since you'll only be touching an x-position and colour.. One more thing.. Where's the best tut. for getting started on the A8s.. I want to use my favourite assembler and carry on using DevStudio, so is there some simple way I can create Atari executables from a binary ? I mean some magic data and addresses I need to insert at the start of my bin ? I'm useless here.. I don't know about running stuff on Ataris.. I'm hoping it's going to be something like the 64.. It's not is it ?

I'm curious, since Heaven just pointed me at this thread from the war torn Atari vs CBM thread, how far it got with all of this multiplexing.. As I mentioned in the other thread I tried using 64 sprites like players and good results, except that it wasn't practical given I burnt nearly all the display time in a kernel repositioning sprites.. The aim being for some like 200+ sprites, it works, but wasn't practical, well not without a REU to speed up data transfers and sprite register loads, but that was not playing fair really.. I just wanted something that allowed me smaller vertically sized sprites than the regular 21 high for a bullet hell test I was working on.. Anyway.. I mentioned there I don't see why you can't have bucket loads of sprites on the A8 with your player setup ? What's the problem ? Surely you've just got to. 1) Sort sprites indices by Y.. 2) Copy in sprite data to correct positions, allocating in round robin fashion.. 3) At VBL, load 1st 4 sprite x-positions and colours.. 4) And then repeatedly interrupt on the last line that the next sprite *was* used, so you can gain as much time as possible to set the sprite up.. Though there's 2 schools of thought here, interrupt early and cross your fingers you can set it up in time, or interrupt after the last time the new sprites actual hardware sprite was used.. I prefer the later.. If you're using variable height sprites as I liked to do in my mad setup Then you need to allocate the sprites in a sensible fashion, though I found there are surprising patterns to this which meant never searching more than one sprite to find a free slot, and then you have to do a 2nd sort on the end Y-positions of the sprites.. This is the key here, and using a Radix sort is perfect[1] in the 1st pass, but for the 2nd pass, the 'Ocean sort' (which I'm sure you've had off Lemon) is perfect for this.. Only a few sprites change end co-ordinates and this sort is ideal for it.. There's a much better version of it sitting on Codebase64, along with a demo 48 sprite multiplexer that show you how little time it really takes, bar the copying of course.. I'm on the verge of getting my hands dirty with this, but the A8 scares me Too many new registers names and unfamiliar hardware... As for intelligent flickering of sprites that I guess you'd need, I thought about this long and hard for what I was working on, and the best solution I came up with was no really practical given my choice of an radix sort.. The idea was to have the lower bit of a sprites Y represent if it was drawn last time or not, if it was the bit was set, so it would naturally end up higher up the sorted result indices.. The problem was this then meant I either needed to halve my y-resolution, or introduce more work into the Radix sort, which I wasn't prepared to do, but it would have been a very elegant solution I think No matter how many sprites you have on the same line, they'll just cycle in their native order with no overhead from the sprite code at all, well bar the extra code required to sort 9bits of position.... The 2nd tier sort wouldn't need to worry about that since it would only see sprites that have been deemed displayable anyway..I didn't get so far with that, because then I got distracted with the idea of using extra bit(s) to encode the priority of the sprite into the sort as well, which naturally led to a complete meltdown of the code.. But maybe you've got enough power to do this on the A8, I guess you probably have.. What exactly is stopping the A8 from doing lots of multiplexed sprites ? I thought this is something that it would excel in, given you've got a bucket load of additional CPU off the bottom of the screen without many cycles being eaten by the hardware.. I'm confused reading through this thread why the goal wasn't achieved ? And I'm not looking for a fight here.. Honest This stuff genuinely interests me.. I was looking to make a big bullet hell game on the c64, but sadly it just won't cut it for what I want.. And don't you dare cut'n'paste that back into the other thread! [1] I say perfect, but for the bullet hell style game it was where Y positions are going a fairly crazy each frame.. If your positions are fairly stable like most horizontal shooters, then the 'Ocean sort' is the best way, but needs keeping an eye on when the loads fluctuates rapidly, and in some cases using both is valid.. ie: using a metric to guesstimate which will be better, even something like running one cycle of the Ocean sort and seeing how many changes occur, then if its beyond some magic amount, Radix sort the lot.. It depends what you want.. I want a level performance.. I don't care if it's not the fastest, but I don't want it to budge from that if possible.. I don't want something that's blindly fast in 99.9% of cases and makes the game drop a frame in that other 0.1%.. Anyway, I'l shut up now Bloody hell.. Sorry for the long post and dredging this up after 5 and a bit years of slumber, but Heaven pointed me here.. Blame him

Edit: Petes right.. I fell into the Atariski trap.. Post removed

The old point, yes.. Your newly adopted, completely unrelated to the original, point, sorry, no.. And don't care really.. To remind you, hardware timers, 8/16/32 bit was the point, not about paddles, not about PCs, not about doing it in software either zeropage or absolute memory addressing, but purely and simply about the hardware.. And you were given the example of linking together a CIAs independent timers so one counts underflows of the other to generate a 32bit timer..

Well you asked, and you had your answer.. And now you twist the point around as usual.. We were talking about the hardware doing it, you had proof that it does it, and now it's not important since we can do it all in software anyway.. Nice

[quote name='emkay' date='Sun Sep 6, 2009 10:47 AM' timestamp='1252230421' It's a matter of taste. The colours may always impress. But for Movies it is better to have a good basement of greyshades available. The movie was posted before, but it shows more detail on the screen than the charblocks of the speccy. And this (graphics and sound) is done with simple data polling, no pageflipping or DMA is used. I've seen that.. Too blocky and not-enough colour, and the sound isn't exactly amazing either.. The Spectrum looks better when it comes to displaying a convincing image.. More colour yes, but also since it's got the resolution under the attributes, it looks much more defined..

And also, I forgot to mention, that the REU can change the way things are done on a C64, quite radically.. One thing I've experimented with in the past it treating c64 sprites like your Atari players and splitting them full screen height, copying data into the strips, and loading colour, x-expansion and positions on each scanline.. The C64 gets overloaded with this technique (reloading so many sprites that is), but since you can now transfer memory into hwardware registers you can load all the sprite registers in a very short time now on each scanline directly from the REU And you can also using it for transferring sprite definitions into the sprite strips when you order them.. You need to realise the REU is like a little blitter, except that it performs no logical operations between the source and destination, just copies.. Though it can perform memory compares for you.. It was only a test for a bullet hell game where I wanted 200+ sprites on screen at once, and the CPU is just overloaded by it all, well it'll manage the sprite display, but anything else is off limits.... But with a REU it's very very very doable.. I've never understood why you Atari guys don't put more effort into using your Players in a *very* multiplexed fashion.. You could do some killer stuff with them, and you've got the procesing power for a fast sort (I mean my radix sort takes a constant 38 cycles per sprite to be sorted) and don't see why you couldn't easily handled ~128 players on screen with colours per line.. I just don't get why you haven't gone down that avenue yet.. As for the Turbo boards ? Nobody develops for them, because hardly anyone will see what you write.. There's no emulators for them, and it's unlikely there ever will be.. I'm not about to buy a SuperCPU board for the absolutely mental prices their going for, especially when the only game out there is pretty shite given the acceleration its got.. That doesn't mean that the C64 can't benefit from it at all, it can, but I don't think anyone really cares to be honest.. In the C64 world it's all about reaching your largest audience.. And that's a C64+1541 pretty much what you bought 25 years ago.. And that's the fun of it as well.. A known limit to work with.. You all know this as well.. I don't get where the fun is in adding additional hardware to an old machine to make it perform new tricks.. I've done some 2600 stuff (first time around and this century) and I know that the bank switching stuff is essential to those, but with new stuff adding more and more to them I feel the spirit is being lost, which after all isn't that what it's all about ? I mean, much as I love Harmony and will get one of course, I'm nervous about what's going to come out of it.. It's not really a 2600 game anymore when inside the cart is sitting a 72Mhz ARM chip.. I really toyed with something similar on the 7800, but decided that it's just not a 7800 game when it's powered by an ARM chip and the Host is literally being used as a display device.. If you get some kick out of that then fine, but like VBXE + the new sound boards and the big new mem carts with RAM (and god knows what else will end up in there) it feels like you've lost the reason you loved the machine and want to turn it into something it's not.. And in some ways feels like it's cheating the machine itself.. Anyway.. The REU is a damn fine piece of kit, just there's not so many of them out there in the world, and what's the point of writing something that uses it when your audience is going to be mainly emulator bound ? If Commodore had put it's functionality into the 128 I suspect there would have been a far bigger uptake in its support, but they didn't and that's the end of the story really..

More of the "we could, but we haven't".. It's time to swap this around to "we could, and we have!!".. Anyway, the Spectrum already has my vote for the 'lets play video on old'school hardware' award..