PM multiplexor

[Heaven/TQA]

in my example I used Antic E as display mode because I can easily set the DLI bit based by y-pos+offset to trigger rasterinterrupt... and in the VBL I am resetting the DLIs.

[andym00]

atari executables have following binary header

 

$ff,$ff

lo,hi byte of starting adress in memory

lo,hi byte of endinf adress-1

 

and end of your code you are putting

 

$e0,$02

lo, hi run adress

 

$2e0,$2e1 tells DOS or nearly all boot loaders where the code should start

 

(just a small introduction to file format of A8)

 

Perfect.. Thanks

[andym00]

in my example I used Antic E as display mode because I can easily set the DLI bit based by y-pos+offset to trigger rasterinterrupt... and in the VBL I am resetting the DLIs.

 

That's mostly meaningless to me at the moment

Lots of bedtime reading ahead..

Edited September 6, 2009 by andym00

[Heaven/TQA]

well... in Bitmap mode I have one mode byte in the display list per scanline...so I can set easily without any lookup table DLI bit per scanline to toggle the interrupt... nothing special...

[MaPa]

atari executables have following binary header

 

$ff,$ff

lo,hi byte of starting adress in memory

lo,hi byte of endinf adress-1

 

and end of your code you are putting

 

$e0,$02

lo, hi run adress

 

$2e0,$2e1 tells DOS or nearly all boot loaders where the code should start

 

(just a small introduction to file format of A8)

 

Perfect.. Thanks

 

IMHO not perfect... should be this:

 

$ff,$ff

lo,hi byte of starting address in memory

lo,hi byte of ending address (not address-1)

 

and end of your code you are putting

 

$e0,$02,$e1,$02

lo, hi run address

[Heaven/TQA]

thanks MaPa for correcting me... seems I am tired the last couple of days in posting 90% correct stuff...

 

But I was nearly 100% sure that it is end adress-1 but well...

[popmilo]

One more thing.. Where's the best tut. for getting started on the A8s..

Atari archives has lots of info...

One of the best sources is this book:

 

http://www.atariarchives.org/agagd/

[peteym5]

So this multiplexer changes the Dispay List to alter DLI positions to where it needs to change player/missile positions? I use fixed Display List since some of the stuff I do require color changes, work Antic Mode 4, etc. I use tables to detect what zone the sprite is begins and ends at, and check if zone has been used by a sprite already.

[PeteD]

This is a perfect time for a timer 15khz so you can just say 1 "tick" = 1 line, they wont intefere with your DLI colour changes and if you make sure you dont have 1 line or no line gaps between "sprites" it wont matter if a DLI pushes the timer off by a line, although you'd have to take that into account on your next "trigger line" calculation.

 

 

Pete

[Heaven/TQA]

yeah... I searched a method or quick hack how can I trigger a DLI to a certain rasterline and the easiest way was to use a static displaylist. the 2 TQA logo is simply there because of I am not using the requiered 2nd LMS command to load the next 4k into the adress counter of antic...

 

of course the zone approach would work, too but with little bit overhead... (did I really say that? ) and 15kHz timer I never used in more than 20 years... seems I should touch new land.

 

btw... my new iMac is setup including Eclipse so I hope to make progress in Gridrunner this week... and maybe I can get in touch with my old multiplexor...

[Heaven/TQA]

So this multiplexer changes the Dispay List to alter DLI positions to where it needs to change player/missile positions? I use fixed Display List since some of the stuff I do require color changes, work Antic Mode 4, etc. I use tables to detect what zone the sprite is begins and ends at, and check if zone has been used by a sprite already.

 

Tempest is done in mode4?

 

yeah... it was easy to do...

 

VBL is running the sorter and while the mapper is preparing all necessary stuff for the DLIs I setup the DLI bits in this easy displaylist... I could have had used blank lines but well... I wanted to have gfx there...

 

and for insiders... nobody realised for ages that the Taquart logo was drawn by a c64 scener...

[andym00]

One more thing.. Where's the best tut. for getting started on the A8s..

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

[Heaven/TQA]

Andy... look here:

 

http://members.chello.nl/taf.offenga/illopc31.txt

[analmux]

...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 ?

Sadly, there's only 1 databus, so display DMA to another bank will just halt CPU.

 

 

...Do you still lose refresh cycles to it though ?

All the memory chips receive the REF signals at the same time, so no extra refresh cycles. They will indeed still be there.

[andym00]

All the memory chips receive the REF signals at the same time, so no extra refresh cycles. They will indeed still be there.

 

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..

[andym00]

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

[Shawn Jefferson]

Not very many applications or games used the ability of the 130XE to map ANTIC to a seperate memory bank than the CPU would see. A neat feature, but since (most) other memory upgrades did not replicate this behaviour, it didn't get supported by software. If you do write something to utilize that feature you have to realize that only people with a 130XE will typically be able to run it.

[Allas]

Not very many applications or games used the ability of the 130XE to map ANTIC to a seperate memory bank than the CPU would see. A neat feature, but since (most) other memory upgrades did not replicate this behaviour, it didn't get supported by software. If you do write something to utilize that feature you have to realize that only people with a 130XE will typically be able to run it.

 

That means 80K of linear space for programmers.

 

But exactly, what are the things that ANTIC could read by himself without cpu help?

When i try to use this feature I'm a little confused on what antic read.

[Heaven/TQA]

i guess something like

 

code is at $4000-$7fff while gfx window is at $4000-$7fff in another bank...

 

antic reads different bank but same adress while code still remains at the same adress so actually the gfx data or display list would be overlayed?

[popmilo]

How fast can these "multiplexers" be on A8 ?

I wrote "multiplexers" because as I see it, its not only changing sprite position and color few times during one frame but also moving sprite data up and down in pm buffer ?

 

In case of vertical shooter, that would mean lot of work on moving data up and down. But 4+1 players should be enough in horizontal, and vertically you could put more than double of that number...

In case of horizontal shooter, not much need for moving data, more movement is in horizontal. But 4+1 players limit number of objects in horizontal..

 

Does anyone have some speed comparissons or how many shapes can be controled with cpu time left for game logic, sound and stuff like that ?

[andym00]

How fast can these "multiplexers" be on A8 ?

I wrote "multiplexers" because as I see it, its not only changing sprite position and color few times during one frame but also moving sprite data up and down in pm buffer ?

 

In case of vertical shooter, that would mean lot of work on moving data up and down. But 4+1 players should be enough in horizontal, and vertically you could put more than double of that number...

In case of horizontal shooter, not much need for moving data, more movement is in horizontal. But 4+1 players limit number of objects in horizontal..

 

Does anyone have some speed comparissons or how many shapes can be controled with cpu time left for game logic, sound and stuff like that ?

 

Some rough figures.. I'll assume 16 pixel high players for simplicity..

For each line of player image copied, you're looking at 9 cycles for a typical copy, so if your sprites are 16 lines high then ~144 cycles for each one, plus a little overhead..

You also have to add 4 cycles per player scanline to be erased, but that's fairly straight forward.. So ~208 cycles per 16pixel high player (that's copy and erase)..

So very roughly 2 and a bit scanlines of raster time per sprite is what I think..

You could speed the copy up enourmously on mission critical sprites at the expense of some memory, but I'd leave that until absolutely necessary..

 

So in 100 lines off screen, you can probably manage to copy over 50 16 pixel high players, but since it's a multiplexer and you've got the sprites sorted, you don't have to be limited by the VBL time.. You can just carry on copying whilst the frame is drawing and hope you stay ahead of the raster.. So god know how many you could really manage.. More sprites = more sorting time = more IRQ chain prep time = more raster time.. But I think you could easily manage ~100, *IF* you can find the screen real estate to do something useful with that many given the limits per line without giving the multiplexer a coronary in the process

 

Personally I've got a few idea, and whilst I was initially gagging to throw 100 odd sprites on screen, I've changed my mind a bit now, and want to try to go for 32+ soft-sprites plus 32+ player overlays (and the wacky PRIOR stuff) for them.. I've got a few ideas for things you might say

 

As for trying to reduce memory copies by trying to keep the data in one player for as long as possible, good luck

 

I've been working on a multiplexer but haven't actually implemented the image copying yet because it's been so much fun doing raster interrupts using the Timers And besides the copying stuff is a fairly known quantity and will probably remain out until quite late..

 

But it works, and quite nicely, thanks to Atariksi's idea of using the Pots as a timer[1].. So thanks Atariksi, I owe you a beer one day for that

 

 

[1] Except Altirra has no Pot emulation whatsoever The Pots just go straight to 228 once you hit POTGO, which is a bummer since it's the only one with cycle accurate emulation of the Timers.. And then Atari800Win Plus, the Pots work, but has only scanline emulation of Timers, so I can't try out Pokey SKCTL initialisation shifting thing to move my irqs around along the scanline..

[Lazarus]

Some rough figures.. I'll assume 16 pixel high players for simplicity..

For each line of player image copied, you're looking at 9 cycles for a typical copy, so if your sprites are 16 lines high then ~144 cycles for each one, plus a little overhead..

You also have to add 4 cycles per player scanline to be erased, but that's fairly straight forward.. So ~208 cycles per 16pixel high player (that's copy and erase)..

So very roughly 2 and a bit scanlines of raster time per sprite is what I think..

You could speed the copy up enourmously on mission critical sprites at the expense of some memory, but I'd leave that until absolutely necessary..

That however would refer to 8 pixel wide single color players. Now imagine 3 color players which doubles the time. And maybe you want 10 instead of 8 pixel wide players using some missiles, so you need the same again but with a lot of additional LDA AND ORA STA instead of LDA STA. That would result in a few 10x16 pixel size 3 color sprites where you can place two on the same rasterline. Pretty laughable when you compare it to 12x21 @ 8 per rasterline on C64.

[andym00]

That however would refer to 8 pixel wide single color players. Now imagine 3 color players which doubles the time. And maybe you want 10 instead of 8 pixel wide players using some missiles, so you need the same again but with a lot of additional LDA AND ORA STA instead of LDA STA. That would result in a few 10x16 pixel size 3 color sprites where you can place two on the same rasterline. Pretty laughable when you compare it to 12x21 @ 8 per rasterline on C64.

 

Don't bring this nonsense in here as well, please.. I'm just very curious to explore the possibilities of the various modes they have here, with lots of sprites in the process..

 

Without wishing to sound like I'm swapping sides, they have a big advantage over the 64 and that's not being limited to 21 pixel high sprites which are a fecking bugger at times, and sometime the damn things are too wide as well

 

Would have preferred 16x16 sprites (plus a bit to flag the 9th bit for the sprite pointer) and maybe 12 sprites, or at the very least a register to write to allow termination of a sprite and the shutdown of its DMA when it's 6bit internal address counter matches.. But it's not going to happen, and you can easily see why they chose 24x21..

 

Anyway, I don't want 10 pixel wide players Mr.SmartyPants

I just want to see what you can do with this machine, that's all

Edited September 12, 2009 by andym00

[Heaven/TQA]

where can I find the info for the pot stuff? I am courious as I never used timers & pot stuff for that?

[andym00]

where can I find the info for the pot stuff? I am courious as I never used timers & pot stuff for that?

 

I don't know, Atariksi mentioned it in the 'thread from hell' when him and I were squabbling about timers.. Then it popped back into my head the other day when I was getting frustrated with VCOUNT and it's half resolution.. A quick chat with Atariksi about it, and there's nothing to it.. Just hit POTGO, and then it starts counting up once per scanline.. If there's no paddle connected they finish at 228.. So you just start them with an IRQ at the top of your displayed screen, and then you have a scanline accurate raster line register (that is directly related to the current visible screen scanline or offset by however much you want) whenever you want it in POT7

I used POT7, since I hope no-one will ever run my stuff on a 400/800 and have a paddle connected.. Though I guess you'd use whichever number you liked best between 4-7

Edited September 12, 2009 by andym00