
You are not logged in 
CSDb User Forums

Forums > CSDb Entries > Release id #95320 : QUOD INIT EXIT
2010-11-04 14:22

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.

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

* 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).
2010-11-08 15:49

Registered: Jan 2002
Posts: 2666
So you just deleted the last version (V1) and updated the entry to V1.1? Please read the rules here at CSDb.
2010-11-08 16:01

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.
2010-11-08 16:08

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.
2010-11-08 16:24

Registered: Dec 2001
Posts: 10359
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)
2010-11-08 16:33

Registered: Aug 2009
Posts: 36
The problem is that I no longer have the old binary. Also, I'd probably not be able to move the comments appeared after the v1.1 release to the new CSDb entry. Anyway, again, I'll be happy of cooperating with administrators to fix the problem, if that's possible at all.
2010-11-08 16:40

Registered: Jan 2003
Posts: 402
Saimo, don't be sorry, it's a stupid rule. ;)
2010-11-08 17:12

Registered: Jan 2002
Posts: 2666
I saved a copy of the old d64 just for this purpose, no worries. ;)
2010-11-08 17:24

Registered: Aug 2009
Posts: 36
Moloch, can you send it to me by email, please?
BTW, I'm wondering whether removing the link actually removed also the disk image from CSDb: maybe it would be sufficient to restore the old download link? Also, when I create a new entry for QIE v1.1, may I just specify the current download link without uploading a new disk image?
2010-11-08 17:34

Registered: Dec 2001
Posts: 10359
here is the old file: http://noname.c64.org/csdb/getinternalfile.php/92860/QUOD INIT EXIT.d64
2010-11-08 17:39

Registered: Aug 2009
Posts: 36
Great, I'll try to fix the entry right now. Thanks!

EDIT: page fixed to the best of my possibilities:
* restored original download link;
* restored original picture;
* restored original scrolltext;
* removed a comment from me;
* added a note about the original downloads number in the Goofs section.
Note that the votes are correct, since no additional vote was cast after the wrongful update of the page.

EDIT2: new entry created (QUOD INIT EXIT V1.1). I've noted down the original downloads number in the Goofs section.
Previous - 1 | 2 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Users Online
Guests online: 47
Top Demos
1 Edge of Disgrace  (9.6)
2 Coma Light 13  (9.6)
3 Bromance  (9.6)
4 Memento Mori  (9.6)
5 Uncensored  (9.6)
6 Comaland 100%  (9.6)
7 Lunatico  (9.5)
8 Unboxed  (9.5)
9 Wonderland XII  (9.5)
10 Christmas Megademo  (9.5)
Top onefile Demos
1 Copper Booze  (9.6)
2 Daah, Those Acid Pil..  (9.5)
3 Cityscape 2730  (9.5)
4 Plasma Ninja  (9.5)
5 Dawnfall V1.1  (9.5)
6 Lovecats  (9.5)
7 Barry Boomer - Trapp..  (9.5)
8 Square Booze  (9.5)
9 Elite Code Mechanics  (9.5)
10 To Norah  (9.4)
Top Groups
1 Booze Design  (9.4)
2 Oxyron  (9.3)
3 Crest  (9.2)
4 Censor Design  (9.2)
5 1001 Crew  (9.2)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Horizon  (9.9)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2022
Page generated in: 0.05 sec.