Posted By
funkydude
on 2005-09-02
19:34:37
|  Writing to the borders of the screen
Anyone have any sample code of how to write to the screen borders in assembly? My Commodore Plus/4 reference book does not cover it.
Thank you 
|
|
Posted By
JamesC
on 2005-09-02
21:49:32
| Re: Writing to the borders of the screen
Write to the screen borders? Is that like putting the postage stamp on the table instead of on the envelope?
I thought the screen borders were to keep the pixels from falling out of the monitor. If we start putting pixels where they don't belong, how will we see them? (My new LCD monitor doesn't have borders... the screen goes all the way to the edge)
|
|
Posted By
funkydude
on 2005-09-03
00:32:37
| Re: Writing to the borders of the screen
James - Like in Udo's Summer Event game. Come on...
|
|
Posted By
Rachy
on 2005-09-03
03:23:59
| Re: Writing to the borders of the screen
I don't have sample code at hand, but it is easy as soon as you got the idea: by writing into $FF1D you can reschedule the "beam" on the screen. Which means the drawing is going on, while you can change the logical position and thus adjust what is drawn there. So, all you have to do is waiting for the exact rasterline position (border start) then change $FF1D to the same value which is on the top of the screen (it is 2) and also adjust $FF14 (screen matrix address). Then wait until it reaches the real end of the screen and change back to normal value.
This sounds very easy, but there are a few pitfalls (especially in timing and bad lines), which I don't remember exactly, so it is up to you to find out... 
Before you ask: no, FLD is not working like this...
For FLD (flexible line distance) you have to adjust $FF1F, which is holding the internal couter inside a character row.
|
|
Posted By
funkydude
on 2005-09-03
10:19:45
| Re: Writing to the borders of the screen
Thanks Rachy
|
|
Posted By
SVS
on 2005-09-03
15:03:55
 | Re: Writing to the borders of the screen
Hey, please do not close this argument. It is very interesting for me and even for the future of Plus4, I think.
Really I ever dreamed to own routines for general purpose, regarding border writing.
I released a short utility-demo with 31 lines of text and a HiRes/Text switching (the file is named 31linesdemo.prg ).
But the best of the best is IMO the Invincible game: both horizontal & vertical borders are used. Funkydude you must to load & run it and WOW!!!!
Any volonteer able to extract the routines used on it? 
|
|
Posted By
Csabo
on 2005-09-03
15:53:54
| Re: Writing to the borders of the screen
Horizontal border? I'm not sure what you mean. It appears to me that it only writes to top/bottom, that's usual for The Mad. He did this in a lot of other games as well: Digital Ball (upscroller), Godzilla (intro screen).
The sideborder is a completely different story. I think the history roughly goes something like this:
- First ever side border effect: Master Computing in MC Demo then TCFS in Dynamix intro. They were release about the same time, but TCFS admits that the idea is from MC. This effect is pretty weird, it uses a side effect of the monitor display (that's why YAPE can't emulate it properly).
- Five Magics is the first real one by Crown. It extends the sideborder by one char in each direction. The effect is rather limited though. However it's the only HIRES one so far.
- Chaos: Larry's old SAS ( = eagle) routine is finally public. Extends the screen by a total of 3 chars, has to be multicolor by the nature of the effect, and the colour map goes bye-bye, so it's 3 colors only.
- Crackers Demo 4: Larry improves on the effect by interlacing it, so now we have 7 colors.
This is Plus/4 Encyclopedia material
|
|
Posted By
TMR
on 2005-09-03
20:14:29
 | Re: Writing to the borders of the screen
Ummm... is there any way to stop that annying memory wrap around on the 26th line at all...?
|
|
Posted By
JamesC
on 2005-09-03
23:55:13
| Re: Writing to the borders of the screen
Yeah, TMR, by stopping the use of borders for screen data! You do not realize the havoc you play on us NTSC users when you use areas that do not exist here!
funky: I am a utilities person, and in USA so those Euro screen-defying programs do not work here except in YAPE.
|
|
Posted By
Rachy
on 2005-09-04
02:37:23
| Re: Writing to the borders of the screen
Don't forget the fake screen border opening by Crown and Fusion in Digital Dream! I was amazed when I had seen this first time. (Big scroll across all borders, all around the screen.)
This effect was really tricky, the screen is turned off, the chars appearing by manipulating (quite fast) the border color by the processor.
|
|
Posted By
TMR
on 2005-09-04
05:08:46
| Re: Writing to the borders of the screen
S'never stopped me using the borders on the C64 or overscanning on the Atari 8-bit... i'm a PAL coder, most of my stuff isn't aimed at the NTSC hardware because it's usually getting close to the upper raster time limit of the hardware and NTSC gets less cycles a frame.
That 26th line is a bit of a nuisance, i've got it all working nicely but can't think of an easy way around the sprite plotting to that area; well, lets be accurate i'm trying to think of a good way that isn't a cycle-stealing hash. =-)
|
|
Posted By
Crown
on 2005-09-04
10:00:15
| Re: Writing to the borders of the screen
You can work around the memory wrap by a couple of ways.
1. Change the screen memory address before the DMA kicks in for the 26th line. The 26th line would be still wrapped of course in this case, and would need special code handling for its updates.
2. Use the other method writing to the border. Instead of extending the main screen area, you create a second (or third in some cases) screen area. Those are starting form $0000 char positions and much easier to work with. The only drawback is that you will need to have a couple of border lines beetween the two windows, so the effect is not completely continous. It might be possible to enhance this so that it doesn't need the border in beetween, but I haven't experimented with that.
3. Start a DMA mid line before the DMA for the 26th line happens, this could increment the screen offset with the number of characters the DMA is doing and not by 40 so it could offset the wrap to $0000. I don't know if this effect ever has been used on the Plus4, but theoretically it should be possible.
|
|
Posted By
SVS
on 2005-09-04
14:19:01
| Re: Writing to the borders of the screen
Any goodman could supply with some code lists? (Please! )
|
|
Posted By
Csabo
on 2005-09-04
15:46:00
| Re: Writing to the borders of the screen
SVS, you actually WROTE a program that writes onto the border. Why would you need the code???
Shameless plug: I've just updated DisAss, some bugfixes and much better documentation in the help file. Feel free to grab it. You want to see how an effect is done? Just disassemble it.
|
|
Posted By
SVS
on 2005-09-05
02:25:16
| Re: Writing to the borders of the screen
Yes Csabo, but the algorithm wano not mine :]. Furthermore my program obtains the effect statically, I mean the lone goal of the prg is that fx.
What I wish is a routine able to do something *while* the fx is performed.
|
|
Posted By
Gaia
on 2005-10-20
07:15:40
| Re: Writing to the borders of the screen
A bit late on this one, but here it goes anyway.
Crown: method 3) will not work on the plus/4. Unlike on the C64, the counters used for the DMA always count until 40 no matter if you delayed the DMA or not. This can happen, as possibly an existing counter has been applied for the DMA. It is already counting - when the TED is not in an idle state of course -, disregarding the fact if it's a DMA or a "normal" screen line. The actual character position comes to mind as best candidate. The only way to force the DMA to latch with a different value is to write to the horizontal count register ($FF1E). By the way, the place where the DMA counter is set to 0 seems to have a weird connection to the vertical sub counter (lowest 3 bits of $FF1F).
|
|
