Previous | Next
| From: TLC (all posts)
Date: 1998-06-02
Subject: Re: NTSC on PAL...
|
Hi!
> Did you got my posting about the inner state change positions of
> the TED? There are a lot of good infos about the inner states in that.
Not really. Usa.net seems to be buggy again. Could you repost it,
or send it directly to my address?
> Yep, some kind of a docs like that would be cool, and I guess we
> could gather a lot of of info together through this list for it.
O.K.
> We can forget about bad lines, there is simply no cycle between the
> start and the end conditions, so you can't delay it's end.
I guess there's not even more than 40 bytes of internal temporary storage in the TED for the color data.
> In the 40+2 char effect, the first and the last char is always the
> char 0 and its color is always black. I could do 40+3, but I couldn't
> change it's bitmap, because there was not enough cycles. (I haven't
> tried to put the charset to zeropage, that could solve it.)
I have an easier solution for this.
These heavy things came because your thoughts were around charactermode.
You're right, fetching extra data for the new places by the proc is hard.
But there's one thing that could help. ...I seem to know it by accident,
or rather: just because I wrote some bitmap mover effects recently. I don't know if you ever played with $ff1a-$ff1b (hope I remember it correctly). It contains the lowest 10 bits of the TED chr pointer/color mem counter. I mean,
it counts the number of characters which were fetched from the memory. In the top of the screen, it contains '0', and after fetching the characters for the first line, $28 (= 40) and so on.
I don't know why, but if you modify this register, the characters on the screen do not - but actually, an active bitmap screen gets affected!
That means, if you switch to bitmap mode (also using color- and scrmem as the appropriate color memories) and start to write to $ff1a-$ff1b in some positions, the bitmap will move (the color map stays unaffected).
(My demo started with such an effect - a tech-tech logo stuff which worked just this way line by line ).
I also tried some border effects in bitmap mode (I remember, Larry also did so). It seems like, if you make lines longer, this counter keeps synchronised. Ie. if your lines were 45 chars long, this counter increments 45 by each 8 rasterlines.
All in all, the TED doesn't stop fetching bitmask data in bitmap modes if you enlarge the lines, it won't even wrap around at the 40th character position. It also displays these bitmasks.
The only disadvantage, that you have absolutely no color ram for the extra places. That's what I've been complaining about. In hi-res mode, it makes the extra pixels hidden (since both color values are black, if I remember it well). Switching to multicolor mode helps, since you have both the $ff15 and $ff16 color to put pixels out.
> Also the normal 40 char stayed at the same position, from this I think
> the following can be deducted: there is a cycle, possibly it's the cycle
> where the CPU slowes down to slow mode at the beginning of the line.
> At this point, an inner mechanism starts in the TED, with which you
> cannot interfere. It will start to display the 40 characters some cycles
> after this point, and after the last char this stops.
Guess you know dma delay screen moving in C-64.
Since I played a lot with the TED $ff1e stuff, I'm sure this also can be done, at least, using $ff1e. I had sometimes wrapped screens - I mean my routine ran in IRQ while I fiddled with its variables at the keyboard. Sometimes, the charactermap on the screen moved by some places to the right or to the left (and wrapped around at the end of the lines), the cursor also went out of synchronization with the actual position.
All in all, I'm sure this mechanism you mentioned could be affected, I mean, one should be able to persuade it to fetch _less characters than a normal scanline. But well, we still didn't made it to fetch more data.
(Otherwise, I guess you should be right. Neither I think if it would be possible to affect the character pointer/color info fetch after it started.)
> For the NTSC mode I think the following could be done: we have to restart
> this mechanism in mid-line, this will result in the redisplay of some
> of the chars at the beginning in the line. (For example if your line
> was 012345678 it would display something like this 01234012345678 ...)
> We also have to change mid-line the value of $ff13 to give different bitmap
> for these redisplayed chars, and set it back at the end of the line.
Hmmm, I should be thinking a lot about it.
> I haven't tried this yet, as the idea was born right now, and I won't
> be here for the weekend, but you can also try this.
Guess you did. I had no time for this (I had no time for answering my e-mails either).
> I guess we do not await these tricks to be emulated, but this talks could
> shed light of the inner workings of the TED, and thus more common mechanisms
> of the TED could be understood, and emulated. (Example, all kind
> of normal $ff1d tricks, bad-line delay, FLI etc... Current emulators are weak
> at these things)
Yes, partially, I assume your opinion. But from the other side, emulator writers are known of the need to emulate the orig computers as good as possible. Just a few years ago, nobody expected to emulate just as easy tricks as rasters or even the pure emulation of the 'bad lines' of the VIC-II in C64 emulators. So, I guess, it's possible that once an emulator writer realises that he want 'real' TED emulation into his Plus/4 emulator.
BTW, all that I wanted to tell, emulating the TED in the Plus/4 implies inventing new, not VIC-II like methods in the emulation. The major difference,
that you don't have to deal with the actual screen parameters and such things when emulating the VIC. In other words, if you emulated the internal happenings of the VIC, you can be sure that you have a 100% VIC emulation and you'll see the same on the screen (as result) that you'd see on C64. But speaking of the TED, this still won't be enough as it can also affect it's relation to the display. What I mean, if you want a _proper TED emulation,
with _all the hardest tricks, you also have to emulate something from the actual behaviour of a real display.
Levente
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
