| |
saimo
Registered: Aug 2009
Posts: 36 |
Release id #95320 : QUOD INIT EXIT
I have just started learning something about the C64 hardware and now I'm facing a problem that seems to be just beyond me, so I need help from you VIC-II gurus out there.
The problem affects the current release of QUOD INIT EXIT and can be seen on real machines or Hoxs 64 (not on VICE, which is why I didn't notice it): it consists in some pixels flickering on the 23rd visible line starting from the top.
The cause is the switch from HIRES bitmap mode (used for the top graphics) to ECM (used for the platforms). The solution implemented in the current release works as follows.
Preconditions:
* the bitmap is 24 lines tall;
* the last line of the bitmap is in solid color;
* the same color is also the background (not in technical sense) color on top of which platforms are rendered (for the record: light red for dawn, cyan for noon, orange for sunset, blue for night) - for convenience, let's call it the "canvas color".
Initializations:
* I select the 3rd VIC memory bank (address $C000);
* I put the bitmap dot data in the second half of the bank (i.e. $C000 + 8 * 1024 = $E000);
* I put the characters dot data in the last 2 kB slot of the bank (i.e. $C000 + 14 * 1024 = $F800);
* I set the VIC Memory Control Register ($D018) to 8 + 6 = 14, so that it correctly points to the abovementioned data in both modes;
* I set the 3rd row of the color RAM to the canvas color.
Dynamic operations:
* during the vertical blanking, I switch the HIRES bitmap mode on by poking 59 (32+16+8+3) to $D011 and set all the background colors (registers $D021-$D024) to the canvas color;
* after the 23rd line begins to be drawn, I switch the ECM on by poking 91 (64+16+8+3) to $D011;
* after the 23rd line is completely drawn, I set the background colors (registers $D021-$D024) as needed by the platforms.
As you have surely already guessed, the switch happens while the 23rd line is being drawn and the idea is to make sure that, during the whole rendering of the 23rd line, the VIC-II is fed with the canvas color under any condition: in fact, the 3rd row of the color RAM and all the background colors are set to the canvas color so that the output color is always the same, regardless of the dot data the VIC-II reads (I guess than when the switch happens, the VIC-II starts considering the bitmap color data stored in the screen memory as the indexes of characters to render, inclusive of the background color indexes, but even if it weren't so, it would be irrelevant).
Unfortunately, it isn't so: somehow, pixels of a different color are output occasionally. Since the operation done by the CPU basically boils down to an atomic write (the compiler should have no problem translating the POKE that activates the ECM as LDA #91; STA $D011), I thought that there could be only two reasons: the unlikely one being that the odd color was the only other color that hadn't been set, i.e. the borders'; the more likely one being that the VIC-II isn't able to cope corrently with the switch at that time and thus "stutters" a bit (is it worth noting that the odd pixels are always black? - mmm... now that I think of it, that's the impression I got, but I haven't verified it...).
I quickly verified that the border color, obviously, had nothing to do with the problem, so only the second possibility was left. I thought that the solution would be making the switch happen during the horizontal blanking and, therefore, I implemented a timer-based synchronization mechanism that would do just that. Bad luck, though: even if the switch is made after the 22nd line is drawn and before the 23rd starts to be drawn, still the horizontal blanking isn't long enough to cover all the odd pixels (at least, this is what I can see in Hoxs 64, not having a real C64 to perform the tests on). Trying the same 1 line later makes things even worse (I guess that since a new row of characters starts, the VIC-II has more job to do).
Now, is there anything I'm doing wrong or am I trying to do something which isn't possible at all?
Thanks for reading this far and any advice you will give me (and, of course, also many thanks to the guys who tried the game on real machines, reported the problem and helped me with testing). |
|
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
Hoxs is correct. the problem your seeing is caused by switching bitmap off and ecm on in the same cycle. enabling the ecm bit is ~0.125 μs ahead of clearing the bitmap control bit so for 1 pixel(may be 2 on older c64`s) VIC-II is drawing Invalid bitmap mode 1 -black pixels only! you have 2 options to solve your problem -you can change the mode outside of the display area or you can split the shift in to 2 phases,first clear the bitmap bit and then enable ecm in another command |
| |
saimo
Registered: Aug 2009
Posts: 36 |
The outside-view thing doesn't work, as said in the post (yeah, looong one... I can't blame anybody for missing this or that bit), but I'll try the second solution (and, if necessary, a combination of the two). I'll let you know shortly.
Thanks! |
| |
saimo
Registered: Aug 2009
Posts: 36 |
Splitting the POKE in two POKEs worked (at least on Hoxs 64), and I could even remove all the horizontal synchronization stuff altogeter :)
Thanks a lot again!
I'll release the fixed version as soon as tests on real machines confirm that the problem is fixed, stay tuned ;)
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
just for the record: it also "works" in vice/x64sc :) |
| |
saimo
Registered: Aug 2009
Posts: 36 |
I guess you mean that the current release doesn't show any jerk, right? That was indeed the problem: since I developed the game using VICE (because on AmigaOS 4 that's the only emulator available), I didn't realize the black pixels issue because it shows only on real machines and Hoxs 64.
Anyway, the problem should be fixed now: I've already been reported that the modified version looks perfect on a real C64 and now I'm waiting for the outcome of another test before releasing it. |
| |
saimo
Registered: Aug 2009
Posts: 36 |
I need somebody to test the beta version on real machines, to make sure that the next release isn't broken. Please send me an email to saimobvq at interfree.it if you'd like to help. Thank you in advance! |
| |
Moloch
Registered: Jan 2002
Posts: 2928 |
So you just deleted the last version (V1) and updated the entry to V1.1? Please read the rules here at CSDb.
|
| |
saimo
Registered: Aug 2009
Posts: 36 |
Whoops :p
Yes, that's what I did - I thought that such a minor update wouldn't be worthy of a new release. Sorry for breaking the rules, I wasn't aware I was doing something bad. I'll re-read them and refresh my memory. Apologies. |
| |
saimo
Registered: Aug 2009
Posts: 36 |
Rules re-read. I'll be happy to co-operate with administrators to bring the old release back and create a new one, if my help is needed.
I'm *very* sorry.
BTW: I had taken note of the original release date and of the number of downloads in the Production Notes, if that is of any help. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
generally new binaries should get new entries (with a few exceptions mentioned in the rules) ... so you should create a new entry for v1.1, and revert the changes to the old entry. (this eg makes sure that the comments on an entries page actually refer to the binary which is linked in said entry) |
... 6 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
