TheMole Posted September 2, 2015 Share Posted September 2, 2015 (edited) I'm seeing a strange issue with non-positional attributes in js99er (maybe issue is the wrong word, I might not be understanding how it's supposed to work). Haven't been able to test on real hardware yet, but I'm hoping you guys can help regardless. So, I've got a setup with two tile layers, with TL2 being the foreground, and TL1 a parallax scrolling background. Hence, a lot of tiles in TL2 are either fully transparent or have transparent pixels. I'm using the following register values: VDP_SET_REGISTER( 4, 0x04); // Pattern table at 4 * 0x800 (0x2000 - 0x3800) VDP_SET_REGISTER( 2, 0x04); // Nametable, 0x04 * 0400 (0x1000 - 0x1400 & 0x1800 - 0x2000) VDP_SET_REGISTER( 3, 0x4c); // Attribute table, 0x4c * 0x40 (0x1300 - 0x1400) VDP_SET_REGISTER(10, 0x00); // Second name table at 0 * 0x400 -> 0x0000 - 0x0300 & 0x0400 - 0x0700 VDP_SET_REGISTER(11, 0x0c); // Second attribute table at 12 * 64 = 0x0c * 0x40 -> 0x0300 - 0x0400 & 0x0700 - 0x0800 VDP_SET_REGISTER(25, 0x00); // Reset scroll registers TL2: Horizontal VDP_SET_REGISTER(26, 0x00); // Vertical VDP_SET_REGISTER(27, 0x00); // Reset scroll registers TL1: Horizontal VDP_SET_REGISTER(28, 0x00); // Vertical VDP_SET_REGISTER(29, 0x20); // Set 2 horizontal pages for TL1 VDP_SET_REGISTER(49, 0xb0); // 0xb0 = TL2 enable | ECM3 for tiles VDP_SET_REGISTER(50, 0x01); // Per tile attributes: TL2 adheres to sprite/tile priorities So, attributes are per pattern and not per nametable entry. I have copies of the attribute table in both pages for TL2 and a copy for TL1. I'm unsure whether it is necessary to have all three copies, but I figured better safe than sorry... This seems to work just perfectly, but when I 'wipe' stuff out by dynamically changing the nametable entries for the changing location of TL2 (in either page) by writing zeroes to it (pattern zero is all zeroes and has the transparency flag set in it's attributes), it neatly writes the pattern as expected, but it forgets about the transparency. At the end of this video, you can see an example of this in action (around the 40th second or so, Alex punches two blue blocks and they get replace by black squares while it should be transparent, like the rest of instances of that pattern all around it). I only see two possibilities at this moment: either I'm completely misunderstanding how per-name attributes work (entirely possible and perhaps even way too likely), or there's a bug in js99er (but that would be the first I've seen in the F18A implementation)? Edited September 2, 2015 by TheMole 3 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted September 2, 2015 Share Posted September 2, 2015 Dude, that's freaking beautiful! https://www.youtube.com/watch?v=X82yJGrWG44 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 3, 2015 Share Posted September 3, 2015 Perhaps you could pause js99er.net at that point and copy a dump the VDP RAM from the debugger? That would make it possible for me to check if there is a bug. Quote Link to comment Share on other sites More sharing options...
matthew180 Posted September 3, 2015 Author Share Posted September 3, 2015 This seems like a js99er bug based on what you describe, but I won't rule out a bug in the F18A either. Your understanding of the layers and attributes is correct, and probably the easiest way to test the problem would be to try the code on real hardware. If you are willing to post the binary (or send it via PM) I'll check it on a real F18A, otherwise a quick program that reproduces the problem would be needed. Since you are using the same tile name and pattern in other areas of the same tile layer, if the problem is on the F18A then I would expect the issue to only be visible for the duration of a single scan line, and certainly the problem would be gone after a full frame. Quote Link to comment Share on other sites More sharing options...
TheMole Posted September 3, 2015 Share Posted September 3, 2015 Ugh... I gotta stop posting late at night when I've been looking for a bug for too long. Sorry for pointing fingers, turns out that there was a bug in my (long standing) loading code, which loaded the wrong values in my replacement table. That piece of code had been working great for a long time, so I never bothered checking it. Thanks for the quick replies regardless guys, much appreciated! Quote Link to comment Share on other sites More sharing options...
Asmusr Posted November 15, 2015 Share Posted November 15, 2015 A question for matthew180: Is it not possible to define a bitmap layer 256 pixels wide? I thought setting the width register to 0 would accomplish that, but I'm getting a 1 pixel high bitmap instead (unless I'm doing something else wrong), Quote Link to comment Share on other sites More sharing options...
matthew180 Posted November 16, 2015 Author Share Posted November 16, 2015 Yes, you *should* be able to have a bitmap width of 256. VR35 is the bitmap width register and translates like this: Values: 0,1..255 == width 256,1..255 You can't have a width of zero. Also, the bitmap layer must be enabled (VR31 bit >80), the bitmap x,y location (VR33,VR34) must be on the screen, and the bitmap height (VR36) must be greater than 0. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted November 16, 2015 Share Posted November 16, 2015 Yes, you *should* be able to have a bitmap width of 256. VR35 is the bitmap width register and translates like this: Values: 0,1..255 == width 256,1..255 You can't have a width of zero. Also, the bitmap layer must be enabled (VR31 bit >80), the bitmap x,y location (VR33,VR34) must be on the screen, and the bitmap height (VR36) must be greater than 0. It looks like there is a problem, it could be with my program, but it could also be with either the bitmap layer, the pix instruction of both. The attached is plotting 5000 24x32 soft sprites on the bitmap layer in around 4 seconds using pix - very impressive performance of the GPU - but when the bitmap width gets large bad things starts to happen. Obviously it all works on JS99er or I would have been able to identify the problem. Try running F18AISO80, F18AISOC0 and F18AISOE0 - they should all work and show an increasingly wider screen. All that is changed is one of the first lines of the program "BMPW EQU >100 * Bitmap width". When the width is greater than >E8 the screen becomes garbled (see F18AISOF0) as if the pix instruction fails. When the width is >100 I only see a single line (F18AISO100) as if the bitmap layer fails. I have checked that the bitmap doesn't overwrite the GPU program as it grows larger, but it could be something stupid like that. Thanks, Rasmus F18AISO.dsk f18a-isometric.a99 Quote Link to comment Share on other sites More sharing options...
matthew180 Posted November 16, 2015 Author Share Posted November 16, 2015 It looks like there is a problem, it could be with my program, but it could also be with either the bitmap layer, the pix instruction of both. Thanks for the test programs, I'll try them out tonight. It is certainly possible that there is a bug in the F18A firmware. The attached is plotting 5000 24x32 soft sprites on the bitmap layer in around 4 seconds using pix - very impressive performance of the GPU - ... About 1,000,000 pixels per second. I wonder what era of computers is was when a PC (personal computer, not specifically an x86 box) could render that many pixels per second? Try running F18AISO80, F18AISOC0 and F18AISOE0 - they should all work and show an increasingly wider screen. All that is changed is one of the first lines of the program "BMPW EQU >100 * Bitmap width". When the width is greater than >E8 the screen becomes garbled (see F18AISOF0) as if the pix instruction fails. When the width is >100 I only see a single line (F18AISO100) as if the bitmap layer fails. I have checked that the bitmap doesn't overwrite the GPU program as it grows larger, but it could be something stupid like that. The PIX instruction cannot address memory other than the base 16K, so it can't be used to render to the 2K of GPU-only RAM. The number >E8 is not jumping out at me either, as being anything special or having any kind of bit boundary. I'll let you know as soon as I find something out. Thanks for the help, sorry for the troubles. 2 Quote Link to comment Share on other sites More sharing options...
matthew180 Posted November 17, 2015 Author Share Posted November 17, 2015 (edited) Well !@#$%. So there is a bug in the PIX instruction, but it should only be affected by the width of 0 (256). And the bitmap layer should still display correctly. I can't account for the >E8 problem yet. Edit: I take that back, I'm not sure the PIX instruction has a bug. The PIX instruction works with *coordinates*, which are 0-based, however the width and height are 1-based. I have to keep reminding myself of that as I work through the HDL. Edited November 17, 2015 by matthew180 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted November 17, 2015 Share Posted November 17, 2015 Well !@#$%. So there is a bug in the PIX instruction, but it should only be affected by the width of 0 (256). And the bitmap layer should still display correctly. I can't account for the >E8 problem yet. Edit: I take that back, I'm not sure the PIX instruction has a bug. The PIX instruction works with *coordinates*, which are 0-based, however the width and height are 1-based. I have to keep reminding myself of that as I work through the HDL. Sorry, I must have made a mistake with my tests last night. The value >E8 is wrong, it is only with widths >FD and greater that it fails. This makes more sense as it indicates an problem with the last 4 pixels. I have attached a screenshot showing the problem with a width of >FD and only one sprite. Edit: In my first implementation in JS99er I used the current line pixel count instead of the total pixel count when calculating the pixel mask, and this caused problems when the width was not a multiple of 4 pixels. Could it be something like that? Quote Link to comment Share on other sites More sharing options...
matthew180 Posted November 20, 2015 Author Share Posted November 20, 2015 I have not had much time to look into this, but I should be able to figure something out this weekend. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted November 20, 2015 Share Posted November 20, 2015 I have not had much time to look into this, but I should be able to figure something out this weekend. Thanks, I understand. Quote Link to comment Share on other sites More sharing options...
matthew180 Posted November 22, 2015 Author Share Posted November 22, 2015 I found a problem with the width multiplier circuit for both drawing and the PIX instruction. What is the most frustrating is that the correct code was commented out just above the incorrect code! Grrr. I'm not sure when I screwed that up, but most likely in an attempt to optimize. With the fixed FPGA bit-stream I can run all of your programs and I get results similar to this: Very interesting looking monsters! It would be cool to see these animated in some sort of hack-n-slash. Anyway, the programs all run for a few seconds then stop. I have to power-cycle to clear the program. If this is correct, then it looks like the problem is fixed. Of course the next question is, are there any more bugs to be fixed since this will require yet another firmware release. 3 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted November 23, 2015 Share Posted November 23, 2015 Great that you found the problem. Yes it's only running for a few seconds (drawing 5000 sprites) and then you have to power off. I'm not aware of any other issues, but I suggest that I test the firmware update for some time before you release it in general. 1 Quote Link to comment Share on other sites More sharing options...
Willsy Posted November 23, 2015 Share Posted November 23, 2015 Wow! You hear that? That was the sound of me falling off my chair! Quote Link to comment Share on other sites More sharing options...
matthew180 Posted November 27, 2015 Author Share Posted November 27, 2015 I came up with something else I can roll into this update. I have always wanted to have the F18A display a version number for a short amount of time at power-on. I did have what I thought was a solution for this, but I was thawarted by systems that zero-out the VRAM at startup (like the 99/4A), so the quick and easy way is a no-go. I'm going to spend a little more effort on this idea before giving up, so an updated bit-stream will be a little delayed (but not too long.) Quote Link to comment Share on other sites More sharing options...
matthew180 Posted January 1, 2016 Author Share Posted January 1, 2016 (edited) Not nearly as exciting as Asmusr-M's gift to the community (Mario game), but I'm happy to announce the F18A v1.7 firmware. This is a small update that fixes the problems described above with the bitmap-layer (BML) display and related GPU PIX instruction. I have also added a graphic that displays the firmware version when the system is powered on. A nice side effect of the version display is that it is only triggered by a *real* electronic reset, so in some cases it could be used as a troubleshooting aid (or to let you know if your system is doing a hardware vs software reset.) On the 99/4A you should see it any time you power-on your system or insert/remove a cartridge. The new update file is available in the first post of this thread, but I will also attach it here. Edit: I removed the download so the only place to get the file is the 1st post of this thread. Having the file in one place makes life simpler. Edited January 10, 2016 by matthew180 3 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted January 2, 2016 Share Posted January 2, 2016 Thank you, sir! And, I must have missed Rasmus' gift... where it be? Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted January 2, 2016 Share Posted January 2, 2016 Matthew,I downloaded and ran the v1.7 update from post #1. The update was successful. It told me to power cycle. I did. I see the new boot-badge showing F18-v1.7 in the upper left corner for a little while after power on.However, when I re-load the F18A Firmware Updater, it lists the version information and shows "CRC 1CFB, and FOUND F18A: V1.6, UPDATE FILE: V1.7"Did you miss a version number in the firmware? The instructions for update procedures on your web recommend reloading the updater to validate the version. But after successful update to v1.7, the updater still reads v1.6 out of the board. Clearly it updated as evidenced by the boot-badge showing up. -M@ Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted January 2, 2016 Share Posted January 2, 2016 Thank you, sir! And, I must have missed Rasmus' gift... where it be? Best gift for the new year, hidden by New Year: http://atariage.com/forums/topic/247359-happy-new-year-2016/?p=3404289 (pls sit down before you klick) Quote Link to comment Share on other sites More sharing options...
matthew180 Posted January 10, 2016 Author Share Posted January 10, 2016 ... The update was successful. It told me to power cycle. I did. I see the new boot-badge showing F18-v1.7 in the upper left corner for a little while after power on. However, when I re-load the F18A Firmware Updater, it lists the version information and shows "CRC 1CFB, and FOUND F18A: V1.6, UPDATE FILE: V1.7" Did you miss a version number in the firmware? ... Uh, yes I did, thanks for pointing that out! I have uploaded a new v1.7 firmware to the 1st post of the thread that corrects this issue. Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted January 14, 2016 Share Posted January 14, 2016 man teaches me to keep up on this topic nice stuff copying the 1.7 update to the nanopeb now Quote Link to comment Share on other sites More sharing options...
Asmusr Posted January 15, 2016 Share Posted January 15, 2016 This is the project I was working on when I discovered that there was a problem with the bitmap layer in the F18A v. 1.6 firmware. Matthew has fixed the problem in the 1.7 firmware, enabling me to release this demo. Before you get too excited: this demo is only drawing a single room without any interaction. But the room is displayed in a proper isometric way by the GPU as separate soft sprites displayed back to front. Perhaps you can see which game this was ripped from, but can you also spot the machine? I'm not currently working on this, but if anyone has information about how 8-bit isometric engines worked (especially how they choose which blocks to redraw each frame), I would be very interested. If you want to open the demo in JS99er you can simply click "Open DSK/Files" and choose the .obj file. This will load and run the object file without involving E/A. I use this feature all the time for development. F18AISO.dsk f18a-isometric-xas99.a99 f18a-isometric-xas99.obj 7 Quote Link to comment Share on other sites More sharing options...
Willsy Posted January 15, 2016 Share Posted January 15, 2016 Oh my god. It's not fair! How do you do it? ??!!! Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.