 Previous Messages |
Posted By
Mad
on 2018-09-03
18:00:23
|  Re: AGSP
bubis good one, so 2019 will be the year where the plussy finally loses it's bad reputation then. Should be possible to display some more sprites like the c64 does easily while scrolling then! Nice!
|
|
Posted By
bubis
on 2018-09-03
06:16:37
| Re: AGSP
@Murphy: Actually, I meant that it will be a world first when I release it. Unreleased stuff doesn't count as far as I am concerned.
I am sure that TLC has it, almost sure that Istvan-V has it too (his fli converter does a 24 char shift), but as a generic 0-39 shift routine no one has released it before I think.
|
|
Posted By
Murphy
on 2018-09-03
05:50:47
| Re: AGSP
bubis: I used to read that TLC had already made VSP routines years ago.  Unfortunately, he never released the routine
|
|
Posted By
Sandor
on 2018-09-03
05:24:25
| Re: AGSP
Hello bubis,
It's quite possible that you'll release your trackmo before I get to the stage where I do have anything really impressive for plus/4 (If ever, lol). I work as a freelancer, so I am 100% unable to predict when I have any time for hobbies and how much of it I do have.
Plus I am right now mainly focusing on the pinball game, where I only need the vertical scroll. I never finished my DFLI project because of lack of time, lack of skills to make the sprites look good enough, and because I thought I probably should do something easier as my first project.
The main reason I made this thread was mostly to see if we can get an AGSP routine into public domain. I feel like there are so few actual resources out there that people who want to jump into it might get discouraged before they even start.
|
|
Posted By
bubis
on 2018-09-03
05:05:34
| Re: AGSP
Hi Sandor!
I have an unreleased HSP routine that does the horizontal scrolling of the color matrix by 0-39 characters by hacking TED registers. You just have to add line crunching to that to have full AGSP.
As it is an unreleased routine what I developed for my upcoming trackmo (this is a world first, so this is a big deal) you have to give me serious reasons to share it with you. 
As you have no track records yet: I will send you my email address in PM and you have to send me some truly impressive stuff first!
I am serious about this, you have to have some working prototype (without scrolling) or some other impressive stuff. I will release the source code of that routine after my trackmo is released (targeted release date is 2019 at the moment), but it is not public domain knowledge yet. Please see this as an opportunity, not an option.
|
|
Posted By
Luca
on 2018-09-03
02:19:58
 | Re: AGSP
From what we remember, a kind of AGSP has been used in one demo only, namely the 5th part of Xmas 92 demo. Anyway, the two bitmap based games coded by Mad, Majesty Of Sprites and The Lands Of Zador, should actually use AGSP, moving some big bitmap areas along all the ways, even with sprites and parallactic raster horizon.
Sandor: omg yes, a pinball game, yes, feed me \o/
|
|
Posted By
Sandor
on 2018-09-02
10:17:21
| Re: AGSP
You have to fill the entire color memory every time you swap the character buffer you're using. Still it's only 1000 bytes total because you don't need to copy 2 color values per character.
edit: of course it uses 6000 bytes for the buffers, but the 5000 bytes in the inactive buffers can be used as work memory since we're always copying from the currently active buffer to the next active buffer.
|
|
Posted By
Murphy
on 2018-09-02
09:41:05
| Re: AGSP
How can you manage the character colors with this method?
|
|
Posted By
Sandor
on 2018-09-02
08:38:06
| Re: AGSP
I think I have an idea that just might be fast enough.
All the graphic is in character sets and we are just changing the character set at the proper scanline.
We have 6 precalculated character screens, like this:
screen1:
row0: chars 0-39
row1: chars 40-79
row2: chars 80-119
row3: chars 120-159
row4: chars 160-199
row5: chars 200-239
row6: chars 0-39 (this is where we swap to next character set)
.. and so on
screen2:
row0: chars 40-79
row1: chars 80-119
row2: chars 120-159
row3: chars 160-199
row4: chars 200-239
row5: chars 0-39 (this is where we swap to next character set)
row6: chars 40-79
.. and so on
In this case we can simply select the character pointer of the screen we need to display and only swap in up to
5 character sets and we only need to scroll the 1000 bytes for the color data.
The memory consumption would be:
character sets: 20480 bytes
color data: 2560 bytes
character memory: 6000 bytes
color memory: 1000 bytes
--------------------------------------------------
total: 27.736 bytes
Compared to this, the memory usage for a bitmap solution would be:
bitmap data: 20480 bytes (if we are scrolling through the bitmap data without having a second screen buffer)
color data: 5120 bytes
color memory: 2000 bytes
--------------------------------------------------
total: 27.600 bytes
So, for the character mode solution for up-down scroll we only need to move 960 bytes, which can be done in
8903 cycles with a 147 bytes loop, leaving us ~11.500 cycles per frame for the rest of the code.
In the bitmap mode we need 17.806 cycles for the color scroll, which would only leave us 2.597 cycles for everything else - which definitely isn't enough for much. We could unroll the copy to get to 15.360 cycles, but that would require extra 11.226 bytes of memory while the remaining cycle count will still be only 5.043.
The bad thing is that this solution wouldn't work for horizontal scrolling or 4 direction scrolling, only for up/down.
|
|
Posted By
Murphy
on 2018-09-01
18:30:01
| Re: AGSP
Sandor: The pointer reads the memory continously after the line 25 from the same 1K page. So what we jumped at the top of the screen will appear from line 26.
Update: Now I understand your problem. If you want bigger screen you need more crunched-lines. I think 40 required for your 512 pixel tall flipper table. (Or you need to use the map switching trick what we talked before)
|
|
Posted By
Gaia
on 2018-09-01
18:15:53
| Re: AGSP
Murphy: that's true... and extending with $FF1D writes might just work so that at least optically it's normal. Another possibility would be to delay resetting the matrix counter by skipping the appropriate line (203 or 204 I am not sure by heart now) in the previous frame but it's kind of an unexplored area and it's easy to mess up the bus accesses this way to such extent that the machine goes berserk.
|
|
Posted By
Sandor
on 2018-09-01
18:04:31
| Re: AGSP
Sure if you don't want to display anything then 24 would be ok. But if you want it to fetch actual color data, you need the 2 scanlines for that.
edit: That would seem to imply that you'd need 24x40 precalculated color values too, which would pretty much mean copying the same amount of data as if you were simply doing a full screen scroll - unless I missunderstood something.
|
|
Posted By
Murphy
on 2018-09-01
18:01:48
| Re: AGSP
Sandor: I'm not sure about that, but since there is only one character pointer you probably do not have to.
You only use the first lines to increase the pointer, and you do not want to display anything, and then the TED works normally.
|
|
Posted By
Sandor
on 2018-09-01
17:46:28
| Re: AGSP
But if you'd use precalculated color maps, wouldn't you need to do it for 48 rows due to 2 badlines needed to properly load the colors?
|
|
Posted By
Murphy
on 2018-09-01
18:04:34
| Re: AGSP
Gaia: There is a problem with LineCrunching. You can increase the char pointer by one row in every pixel row. So you lost a 24 pixel high area on the top of the screen if you want upscroll the char pointer by 24 line.
On the Pinball Dreams C64 they put sprites to that area.
https://www.youtube.com/watch?v=NgcSN6e68jA
On C64 the only know solution to overcome this limitation is several precalculated colormap and bitmap (started from the first char row, started from the 6th char row, started from the 12th char row...). They scroll up to 5 line with LineCrunch and after the 6th line they switch the bitmap to the next one.
Clarence used this trick in the Rocketry.
https://youtu.be/yCxDzq0rFGo?t=1m39s
We have hardware scroll register for the bitmap, so only the precalculated colormaps required on plus/4.
But very hard to manage this on a game.
Maybe I found another solution. If you extend the screen height to 28 char, but you used the first 3 char row only for the LineCrunching you get a vertically moveable 25 char height screen. Maybe :) I've never tried this before.
|
|
Posted By
Gaia
on 2018-09-01
16:53:41
| Re: AGSP
I have never done it properly myself but it should be possible by writing to $FF1F (vertical sub address)... when the lowest three bits are 6 and the TED finished fetching the current matrix data it'll check this and fires a trigger that will generate a latching of the matrix position counters which are used for reloading the counter in the beginning of each window line for fetching matrix data.
In bitmap mode (what Murphy posted) you can move around in the bitmap mask data relatively easily by writing to $FF1A/$FF1B but I understand you're in character mode. Anyway, in bitmap mode you'd have one more free colour per character cell as you rightly pointed out but as a proof of concept you'd be perhaps better off in character mode first.
BTW: the image is great!
|
|
Posted By
Murphy
on 2018-09-01
14:47:47
| Re: AGSP
it is possible in theory to produce combination of LineCrunch with multiple color maps and the hardware bitmap scroll, but I do not think anyone has ever used it on plus/4.
this is not a bitmap? incredible!
|
|
Posted By
Sandor
on 2018-09-01
14:41:48
| Re: AGSP
So there is no way to hack the TED into reading the color values at a given position at all?
Moving the color data in this case would mean moving 1920 bytes which is 15360 cycles (fully unrolled lda/sta) plus drawing the new 80 bytes, which is additional 480 cycles (lda #$/sta), totaling 15840 cycles, with an additional 320 bytes - 2880 cycles (lda ,x/sta, x) - for the incoming data that would add up to 18720 cycles, which would pretty much kill anything else if I try to do 50 fps scroll with maximum speed of 8 pixels per frame. A 4 pixels per frame speed seems possible, but doesn't look like you can get any faster than that if you have to copy the color data.
edit:
@MMS: Thanks, it was designed for text mode though, so it only uses 1 variable color per 8x8, if I have to switch to bitmap mode then it can look much better with 2 variable colors per char... I'm not sure if I can run it in bitmap mode though. Seems like I'll be way too short on the cycle count.
|
|
Posted By
MMS
on 2018-09-01
14:17:31
 | Re: AGSP
wow, this look magnificent!
|
|
Posted By
Murphy
on 2018-09-01
14:23:03
| Re: AGSP
Looks great!
You can scroll the bitmap with registers but you need to copy the color memory by cpu.
Look at the intro of this demo:
http://plus4world.powweb.com/software/Waiting_For_Promised_Land
Or watch the intro of this game:
http://plus4world.powweb.com/software/Trans_Logic
|
|
Posted By
Sandor
on 2018-09-01
14:06:13
| Re: AGSP
I have several half started "projects" that I never finished due to complete lack of time to focus on fun stuff.
At the moment I am just trying to scroll this up and down with minimum possible CPU usage possible:
But I also want to do some 4 directional scrolling for other stuff I am doing.
|
|
Posted By
Murphy
on 2018-09-01
13:58:00
| Re: AGSP
The ff1a/1b only scrolls the bitmap.
What is your goal?
|
|
Posted By
Sandor
on 2018-09-01
13:36:11
| Re: AGSP
That is what I tried first, but it doesn't look like it does anything when I write to it.
Even this does absolutely nothing:
1000 lda #$00
1002 sta $ff1a
1005 sta $ff1b
1008 jmp $1002
You would expect the screen to be filled with the first few characters, but it isn't, the screen is filled with the normal stuff. Or are you saying this doesn't work in character mode?
|
|
Posted By
Murphy
on 2018-09-01
13:09:16
| Re: AGSP
Sandor: You can scroll a bitmap with the ff1a-ff1b registers for free, so only the color information need to be copied.
|
|
Posted By
Sandor
on 2018-09-01
13:34:07
| Re: AGSP
Any Given Screen Position, AKA 4 directional scrolling.
From here it definitely seems like it is possible to do:
http://plus4world.powweb.com/plus4encyclopedia/500217
But I couldn't do it myself so far.
|
|
Posted By
Patrick
on 2018-09-01
12:19:53
| Re: AGSP
What is AGSP? explain it please..
|
|
Posted By
Sandor
on 2018-09-01
08:59:53
| AGSP
Hello,
I am off and on trying to do something for the plus/4 (mostly off but that's life)... I was experimenting with a lot of stuff in the past with more or less success, but I got really stuck trying to do AGSP.
Is there any info out there on how to do this effect on the plus4?
I searched all over this site but was unable to find anything useful.
Regards,
Sandor
|
|
