Jump to content

matthew180

Members
  • Content Count

    2,700
  • Joined

  • Last visited

  • Days Won

    3

matthew180 last won the day on August 13

matthew180 had the most liked content!

Community Reputation

1,524 Excellent

2 Followers

About matthew180

  • Rank
    River Patroller

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Castaic, California
  • Interests
    My family, FPGA, electronics, retro/vintage computers, programming, coin-op games, reading, outdoor activities.
  • Currently Playing
    With my son: Divinity2, Borderlands, TorchLight2. With the family: Minecraft

Recent Profile Visitors

18,720 profile views
  1. In ECM3 you basically have eight groups of 8-colors. The worst case is index 0 (zero) in all of the groups is treated as transparent, in which case you lose 8 of your 64 colors. However, index 0 being treated as transparent is configurable on a per-tile basis, as well as the color-group (palette select) the tile belongs to, so it is totally possible that only one color is ever treated as transparent. It is up to you to decide how you want to organize your tiles and colors. More bits per pixel means more VRAM used for pattern data. 4bpp would mean 8K of VRAM for patterns, and 5bpp would mean 10K of VRAM. And that is just for the tiles. If this were expanded to sprites as well, you are out of VRAM and would have to absolutely share pattern definitions between tiles and sprites. The bitmap layer (BML) offers 4bpp right now in fat-pixel mode, and is very memory efficient since its x,y size is specified in pixels. No matter how many colors the F18A offers, there is always talk of getting more. 5bpp, 6bpp, 8bpp, alpha channel support, etc. At some point the capability stops aligning with the host computer system (early 80's computer) and the F18A. The other problem is technical. From a hardware perspective I can't add 5bpp and skip 4bpp, so this would be two more color *modes* (depths) to support. I don't know if there is enough time to access the additional pattern bytes, per tile, to support more bits per pixel (scan line time *is* limited). It also means wider multiplexers for the data and addresses to VRAM, which consumes more FPGA resources, and I'm already at 95% utilization for the original F18A's FPGA. I'm also hesitant to add more features for many reasons discussed previously, ad nauseam.
  2. True. I'm not sure why I wrote that as an option for sprites. Must have been thinking too hard about the tile layers.
  3. I just checked the HDL and, yes, apparently TL2 has its own page size bits... Sad I can't remember everything I implemented. I really need to write some documentation! Yeah, the pseudo-code does not look right. The "if have_pixel == false then" block should just be deleted. Yes, there are those flags too... which I forgot about. The TL1_OFF is pretty easy, it does exactly what it says. When it is off you should end up with just the background as the base color behind TL2, the BML, and any sprites. The TL2 Priority I had to look up. I don't remember why I implemented this, but I have to assume it was a request from you (Rasmus). It is a *global flag* that affects TL2's priority: Mode TL2 Priority Select/Enable -------------------------- Original 0 TL2 covers sprites 1 sprites cover TL2 ECM1..3 0 TL2 covers sprites 1 Tile's attribute bit >80 selects tile's priority over sprites So depending on the mode, the TL2 Priority controls if all of TL2 is above or below sprites, otherwise it is an enable as to whether or not the tile's attribute sprite priority bit is considered. This could be work into the pseudo-code by replacing: tile_priroity = priority-over-sprite With a check that considers the TL2 Priority flag and mode. get TL1 pixel if TL1_OFF == 1 or (pixel == 0-value and pixel-transparent == 1) then pixel_color = background-index else have_pixel = true tile_priority = priority-over-sprite pixel_color = pixel-index end if if TL2 enabled get TL2 pixel if mode == original then pri_over_sprite = not TL2_PRI else pri_over_sprite = attr_pri_bit or (not TL2_PRI) end if if pixel != 0-value or pixel-transparent == 0 then have_pixel = true tile_priority = pri_over_sprite pixel_color = pixel-index end if end if
  4. I did? Oh no! I secretly hate Verilog. Do you have a link? Verilog looks too much like a familiar programming language to most people (like C or C++), and tends to mislead people and promote hard to read HDL. Just my opinion though. It is very popular with the new kids trying out FPGAs. Hmm. Yeah, where you have overlap between the pattern bits and the palette select bits, the MSbits remain: 5 4 3 2 1 0 palette index ----------- 3 2 1 0 palette select bits 2 1 0 ECM3 pattern bits ----------- 3 2 1 2 1 0 combined bits Where the two overlap, the LSbits of the palette select are replaced by the pattern bits. In thinking about it now, it seems I might have chosen poorly. Dropping palette select MSbits would probably have been a better choice. Sorry. This is what happens when you use hardware without context of the best way it might be used. It was this kind of failure that resulted in the big V1.6 release that blew away a lot of original useless design and introduced things like TL2 and other features (after a lot of feedback mostly from Rasmus as he tried to use the enhanced features).
  5. Something to keep in mind, the 99/4A is 30+ years old, and things will fail. The FPGA on the F18A does a checksum when it loads the bit stream, and if there is a problem the board will not come up. There is an LED on the F18A that looks like a power LED, but it is actually a "done loading configuration" LED. If that LED is on, then the FPGA loaded its bit stream correctly. If you get the older "green screen" (which means you are running an old firmware on the F18A and should update it), or the newer F18A power-on screen, then you know the FPGA loaded correctly. Uh? Can you elaborate what this means? The F18A uses a single FPGA which contains Block RAM that is used to implement the VRAM. If the FPGA has a problem, see my comment above, i.e. it would fail to load the bit stream, the done LED would remain off, and the screen would never show anything. What is it you are learning about these new products and their lack of protection? The F18A has buffers for I/O to and from the host system. And yes, if your power supply spikes, you can certainly blow up the F18A's buffer and / or power regulators. It has happened, and I have a repair service for the F18A when it does. The main problem the F18A has in some systems is that the host's Power-On Reset (PoR) circuit brings the computer out of reset before the F18A's FPGA is done loading its bit stream. When this happens, the F18A misses some of the initial commands the host computer tried to send to the VDP. On the 99/4A that means you might not see the Mater Title Screen, but typically just pushing any key will continue as normal. The 99/4A is known to generally have a slower PoR than most computers, so the F18A is usually ready in time. If the system does not come up, and pushing a key does not move to the normal selection screen, then something else happened during the power-on. Again, with a 30+ year old computer, you should expect problems like this. Something like a dirty or worn out power switch can be as guilty as anything.
  6. Ah, sure, so those won't be changing at this point. I messed that up when I chose to use those VRs, so I'll have to deal with it now. I'm not going to break existing F18A software.
  7. When I was writing the pseudo-code, I realized it is easier to do this in hardware than software. If you can read VHDL I'm happy to provide you the F18A tile and sprite source if that would help with the emulator. I really should write an F18A reference in C as well, so other emulators can incorporate the features... yeah, just what I need, yet another project I don't have time for... However, I do plan to open-source the F18A HDL at some point in the near future.
  8. I think the majority of the 99/4A (geneve?) software that would use the 9938 is mostly looking for the extra VRAM and ability to relocate tables. I might have interfered in making this seamless when I put TL2's registers in the VR range 8..14. The 9938 has a lot of bits for using things like interlace and the color bus, which the F18A-compatible MK2 will never support, so I'm not worried about those registers. I have not looked at the addressing in enough detail to come to any conclusions yet; I have to get the video section rewritten first to support the DVI output (and free up 4K to 6K of Block RAM for the original F18A). What VRs in the 8..14 range does Super Mario use?
  9. Yes, I tried to stay out of VR8..14 in case I tried to be more 9938 compatible in the future. I kind of blew that when I added TL2. I'm not sure how it will map out now. Yes. Probably in VR37. If I had given more thought to expansion I would have set up the new registers a little better. That was my first pass at making a chip... I sure hope so. If I can get my way about things, I'm planning to have access to all 512K on the MK2, otherwise an rather expensive SRAM chip will go under utilized. A lot of the table registers have room for the needed address bits (5 more bits are needed for the full 512K). Even if I can't get table access to the full 512K, the VRAM should still be fully addressable by the host interface and GPU. Also, I'm having to do a lot of rework for the DVI video output, and I should be able to free up at least 4K of VRAM for the original F18A. I could also make the 2K of GPU RAM part of the overall VRAM, which would give the original F18A 22K of VRAM total.
  10. I'll try to pseudo-code the sequence. First, any bits in the VRs or attribute-bytes that specify "transparent", that determines how the zero-value pixels will be considered. A zero-bit ("0") means not-transparent, a one-bit ("1") means transparent: Mode Bits per pixel Attribute Result color from pattern trans bit ---------------------------------------------------- Original "0" NA Backgroud color from color byte "1" NA Foregroud color from color byte ECM1 "0" "0" Use color from palette "0" "1" Pixel is transparent "1" NA Use color from palette ECM2 "00" "0" Use color from palette "00" "1" Pixel is transparent "1x" NA Use color from palette "x1" NA Use color from palette ECM3 "000" "0" Use color from palette "000" "1" Pixel is transparent "1xx" NA Use color from palette "x1x" NA Use color from palette "xx1" NA Use color from palette There is also a priority bit in the tile attribute byte, which gives the tile's pixels priority over sprites. The BML has its own transparent bit, and priority over tiles bit. The BML transparency works the same as the tiles, a zero-value pixel is either transparent or the palette color based on the transparent-bit in VR31. With that out of the way, a pixel's color is determined like this: for every screen x,y location have_pixel = false tile_priroity = false get TL1 pixel if pixel == 0-value and pixel-transparent == 1 then pixel_color = backgroud-index else have_pixel = true tile_priroity = priority-over-sprite pixel_color = pixel-index end if if TL2 enabled get TL2 pixel if have_pixel == false then if pixel != 0-value or pixel-transparent == 0 then have_pixel = true tile_priroity = priority-over-sprite pixel_color = pixel-index end if end if end if if BML enabled get BML pixel if pixel != 0-value or BML-transparent == 0 then // if BML on top of tile-layers, or previous tile pixels were transparent. if BML-priority == 1 or (BML-priority == 0 and have_pixel == false) then // DO NOT SET *have_pixel* to true. The BML is always under sprites. pixel_color = pixel-index end if end if end if for each active sprite at this x,y location get sprite pixel // if there is a non-transparent sprite pixel, and the tile pixel is transparent // or the tile does not have priority over sprites, display the sprite pixel. if (pixel != 0-value or sprite-transparent == 0) and (tile_priority == false or have_pixel == false) then pixel_color = pixel-index end if next sprite lookup pixel_color in palette show pixel color next x,y screen position I think that is right, I'll have to look at it again later to see if I missed something. Basically for every pixel you want to display, in the order of TL1, TL2, BML, Sprites, you have to see if the pixel is zero-value, see if a zero-value is considered transparent, and when it comes to the BML and Sprites see if the tiles have priority or not. For TL1, check for non-transparent pixels vs background, and replace BG if there is a pixel. For TL2, check for non-transparent pixels vs TL1, and replace TL1 if there is a pixel. For BML, check for non-transparent pixels vs tile-layers, and priority over the tile-layers, replace if priority over tile-layers or both tile-layers are transparent. For Sprites, check for non-transparent pixels vs tile-layers, and priority over tile-layers, replace if priority over tile-layers or both tile-layers are transparent. Priority of tiles vs sprites is considered only when ECM1..3 is true. Original mode does not. Same with the TL2 and BML, the F18A must be unlocked and those features enabled.
  11. I have never been able to come up with a diagram that explains the pixel color stack-up, most due to the complexity of all the possibilities. The BML can be above or below the Tile Layers depending on VR31 bit >40 (which is incorrectly indicated as "sprite priority" in the register use spreadsheet, which will be corrected in the next release). Also, VR31 bit >20 specifies if a BML pixel value of "00" (two zero bits) is transparent or if the zero-index palette color is used. BG BML if priority = 0 Sprite if TL1 tile-priority = 1 TL1 Sprite if TL1 tile-priority = 0 Sprite if TL2 tile-priority = 1 TL2 BML priority = 1 Sprite if TL2 tile-priority = 0 Transparency for the tiles depends on the transparent setting (tile attribute byte bit >10) for each tile (in ECM1..3). Like the BML transparent setting, this bit determines if a zero-value pixel is the zero-index palette color, or treated as transparent. The interaction between the BML and the Tile Layers also depends on the transparency of each pixel at each layer. Can you clarify? The MK2 will expand the addressing of the tables with more address bits, as close to the 9938 as possible. Is this what you mean?
  12. Yeah, scrolling always presents the problem of "where does the new data come from?" I thought about this a lot when doing the scrolling in the F18A, and ultimately it is left as an exercise for the programmer. The ROW30 options does not give you extra non-visible rows, it give you 32x30 tiles, all visible. There are a few options, the easiest is probable to use TL2 to mask a row and or column. But if you need both tile layers to scroll, then you will need to set up the 1x2, 2x1, or 2x2 page sizes. However, keep in mind that just because you specify a 2x1 page, for example, you do not have to use the entire second page. After scrolling 7-pixels, you can reset the scroll register and tile-shift the display left or right. This way you only need two extras rows or columns from the neighboring name tables, and the reset of the VRAM can be used however you like. It gets harder to be efficient with the 2x2 page size though. Also, the color/tile-attribute table has the most flexible options for locating in VRAM, and I like to tuck it in unused name table VRAM. The GPU can also be used to do the name-table adjustments very fast, i.e. when you have scrolled 7-pixels and need to do a tile-sized scroll and reset the pixel-scroll. There are also options to restrict the number of tiles you use, which means you can trade unique tiles for pattern VRAM.
  13. You are the topic starter, and this is clearly your personal vision, so what are you waiting for? All the tools you need are at your finger tips, and this community will certainly help you work through various problems and/or design issues, but it is unlikely that anyone else is going to do the work you want done. If you really want this to happen, it is better to start the project yourself and get something working, at which point others might be inspired to contribute. I would not hold my breath.
  14. Well, in the model I suggested you never have a 1yr subscription lower than the $30/yr you have right now. If it is not complicated to add, what does it hurt to try the higher rates? Still gotta do something about the joystick meter though.
  15. Probably the only way to finally know for sure how each version of the SN sound chips actually differ, would be to get each one and test them. You would need to be able to adjust the input clock frequency to verify the divider input stages, have an audio input source to see if it mixes with the output, and a way to send programming data to the chip to set the count to 0 (zero) and see if the output flat-lines. Any volunteers? You could *almost* use the TI console for the test, other than being able to modify the input clock frequency (easily).
×
×
  • Create New...