Feel free to submit issues at https://github.com/hernandp/xemu/tree/megawat.
Hallo Besucher, der Thread wurde 28k mal aufgerufen und enthält 227 Antworten
letzter Beitrag von LGB-Z am
XEMU - VIC-IV implementation update
- adtbm
- Erledigt
-
-
Looks like the sprite is switching to H640, instead of staying H320 unless the sprite H640 flag for that sprite is enabled. (On a C65 sprites are always 320H resolution. Only the MEGA65 allows making sprites higher-res than 320x200).
LG
Paul.
-
Looks like the sprite is switching to H640, instead of staying H320 unless the sprite H640 flag for that sprite is enabled. (On a C65 sprites are always 320H resolution. Only the MEGA65 allows making sprites higher-res than 320x200).
LG
Paul.
Thanks Paul, i did not understand this logic. So default aspect is H320 in both 40/80 column modes.
-
Correct.
-
I've also built this version. Tried to check out the sprites, but I don't know if I'm doing something wrong.
Maybe I need to put in some proper sprite data, but this is how it looks in the old and new version of Xemu:
This is how it looks with xc65:
-
Yes, the solid block will be due to different memory initialisation.
Hernán now knows what was causing the wrong aspect ratio, and this will get fixed.
Do try loading some proper sprite data, and see how that goes. It should display correctly, even if the aspect ratio is wrong.
LG
Paul.
-
Thanks guys for your amazing work!
Are you also planning to support variable sprite height ($d056)?
Or is it already in there and I am doing something wrong?
(never mind the random sprite data, but the colored blocks should be square with 64x64 pixels)... -
Thanks guys for your amazing work!
Are you also planning to support variable sprite height ($d056)?
Or is it already in there and I am doing something wrong?
(never mind the random sprite data, but the colored blocks should be square with 64x64 pixels)...Variable sprite height is not implemented yet. It will come soon, thank you.
-
ubik
Wow that looks very nice and promising. I like the Font !
If you need help testing or verifiing it on a real machine, send me the PRG as a PM.
-
This is a minimal example, but what more do I need to do to get 64-pixels wide sprites?
-
This is a minimal example, but what more do I need to do to get 64-pixels wide sprites?
Do you see the same effect in C64 mode?
Also did you enable VIC-IV extended register set with the knock knock sequence?
ubik did you get 64-pixel wide sprites working it seems?
Thanks for the very useful reports, guys. -
Do you need to knock in Mega65 mode? I tried: poke 53295,71:poke 53295,83 but it just hangs the Basic.
-
Did the same program in assembler and now it works!
-
ubik did you get 64-pixel wide sprites working it seems?Yep, works for me (apart from the 64 pixel high part ;-)) using this little function:
-
Do you need to knock in Mega65 mode? I tried: poke 53295,71:poke 53295,83 but it just hangs the Basic.
If you knock in C65 mode from BASIC, in between the first and the second poke the extra registers get hidden, which is highly likely to crash either the Kernal and/or Basic..
-
UPDATE 31/07/2020
Thanks to all guys for reporting bugs.
Fixes:
* Honours SPR640 register. Default is H320 aspect for horizontal resolution. (V400 not implemented).
* Honours extended height register.
Use as always my "megawat" branch at https://github.com/hernandp/xemu/tree/megawat
Have fun.Hernan & Xemu Team.
-
Hi!
First of all, many thanks for the fixes and enabling variable height sprite mode
I gave variable height mode a try, and so far it seems to work (sprites have the correct width and height). But then I tried initializing the sprite to a solid color, using SPRPTRADR ($d06c-$d06e) to place the sprite pointers at 0x46000, and SPRPTR16 ($d06e bit 7) in order to locate the sprites themselves at 0x48000.
Here's the code:
Code- void initSprites(void) {
- int spritePointer;
- mega65_io_enable();
- POKE(0xD057U, 255); // enable extra wide sprites
- POKE(0xD055U, 255); // enable custom height for all sprites
- POKE(0xD056U, 64); // sprites are 64 pixels high
- // -------------- testing 64x64 sprites ------------------
- // set location of sprite pointers to 0x046000
- // (and set SPRPTR16 for arbitrary sprite locations)
- POKE(0xd06CU, 0x00);
- POKE(0xd06DU, 0x60);
- POKE(0xd06EU, 0x04 | 0x80); // SPRPTR16
- // set first sprite pointer
- spritePointer = 0x48000U/64;
- lpoke(0x46000U,spritePointer/256);
- lpoke(0x46001U,spritePointer%256);
- // fill 64x64 area at 0x48000 solid
- lfill(0x48000U,255,0x1000);
- }
This should (at least in theory) make the first sprite a solid block of color. But what I get is this:
Screenshot from 2020-07-31 12-24-14.png
As you can see, the sprite has the correct dimensions, but it's not solid, i.e. the sprite data is not fetched from the pointer. Any ideas what I am doing wrong?
Kind regards
Stephan
-
Hi ubik Glad to see you got extended height to work as you needed.
16-bit pointers to go in the next update, keep tuned. -
Does starting a program by supplying a -prg argument to XEmu work? I can't get it to work myself and I don't know if I'm doing something wrong.
-
adtbm
Hat den Titel des Themas von „MEGA MAZE running on XEMU - VIC-IV implementation update !“ zu „XEMU - VIC-IV implementation update“ geändert. -
i have moved all the XEMU VIC-IV update threads into this single on. this should it make easier to keep track