Ikrananka Posted January 4, 2019 Share Posted January 4, 2019 (edited) I too just updated my F18A ColecoVision with the v1.9 firmware. Flawless update using Tursi's excellent updater via my AtariMax Ultimate SD cart. Huge thanks to Tursi for making this such a painless process. Even more thanks to Matthew for this awesome update. One of my issues was that the VGA output from my F18A would not display on my relatively old (2006) Sharp LCD TV. I would get just a blank screen. The v1.9 firmware has fixed this problem and for the first time ever I can now play my F18A enabled CV on this TV instead of my other displays. Thanks Matthew Edited January 4, 2019 by Ikrananka 4 Quote Link to comment Share on other sites More sharing options...
matthew180 Posted January 4, 2019 Author Share Posted January 4, 2019 I'm glad it fixed problems with your display. It is amazing to me how much trouble 6.4 pixels can cause! 2 Quote Link to comment Share on other sites More sharing options...
matthew180 Posted January 4, 2019 Author Share Posted January 4, 2019 Hi Matthew, do you have a (direct?) link to the v1.9-update ? I cannot find it. (I used the link from post #1 and some more). I only see this: thx There is a zip file in the first post of this thread. It appears to be what you are looking for. Did you find it? Chue's comment was spot-on, you are looking for the F18A_V19.zip file at the bottom of the first post. Here is a direct link (I think): http://atariage.com/forums/index.php?app=core&module=attach§ion=attach&attach_id=612778 I have not updated my website yet, it ends up being lower on the priority list. 2 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted January 5, 2019 Share Posted January 5, 2019 update works flawlessly off TIPI tossed dsk image onto tipi drive, auto unpacks to a f18A_V19 folder make that folder DSK1 in tipicfg or tipimap load ea3 DSK1.F18AUPD folllow on-screen instructions Greg 2 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted January 5, 2019 Share Posted January 5, 2019 I need to burn a 512K cartridge image and try it against one of my TI machines. . .then I'll have a fully portable update device. 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted January 5, 2019 Share Posted January 5, 2019 (edited) The update gave me a good 'excuse' to set up my F18A / CF7+ system today. It took me a while to figure out that my ubergrom UART/serial connection was plugged into a cable that went... nowhere. Ugh. Anyway, once I get the files transferred and update my F18A, I'll upload a TI archive to Heatwave, as a few people nabbed earlier updates that way in the past. Edit: updated to v1.9 successfully and uploaded the files in the disk image. Edited January 5, 2019 by InsaneMultitasker 1 Quote Link to comment Share on other sites More sharing options...
sparkdrummer Posted January 5, 2019 Share Posted January 5, 2019 Matthew I just attempted to update my F18A to version 1.9, but the CRC in the upper left shows A374. It also states FOUND V 1.8. i did continue per your instructions on your website. What should I do? Quote Link to comment Share on other sites More sharing options...
sparkdrummer Posted January 5, 2019 Share Posted January 5, 2019 I meant to say I did NOT continue. Quote Link to comment Share on other sites More sharing options...
matthew180 Posted January 6, 2019 Author Share Posted January 6, 2019 My website is not up to date with the V1.9 firmware, you need to download the F18A_V19.zip file from the *first post of this thread*. Here is a link to the file: http://atariage.com/forums/index.php?app=core&module=attach§ion=attach&attach_id=612778 I suppose I should update my website too... Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 6, 2019 Share Posted January 6, 2019 I just reprogrammed my F18a with the v1.9 firmware. It was a flawless update using Tursis excellent updater on my Super ColecoVision. I can't take full credit, all I did was wrap Matt and Rasumus' original excellent updater with some more GPU code so it could be easily ported. Quote Link to comment Share on other sites More sharing options...
sparkdrummer Posted January 6, 2019 Share Posted January 6, 2019 I had the right file, but I copied again from your post above.. Still shows A374 in the upper left. FOUND F18A: V1.8 UPDATE FILE: V1.9 I'm fearful to continue Quote Link to comment Share on other sites More sharing options...
Asmusr Posted January 6, 2019 Share Posted January 6, 2019 I had the right file, but I copied again from your post above.. Still shows A374 in the upper left. FOUND F18A: V1.8 UPDATE FILE: V1.9 I'm fearful to continue I think A374 is the correct checksum for the disk version of the updater. Quote Link to comment Share on other sites More sharing options...
matthew180 Posted January 6, 2019 Author Share Posted January 6, 2019 Ah, yes, that is correct, I forgot that the CRC will be different between the disk updater and the ROM updater (and probably the CV ROM updater). A374 is correct for the 99/4A disk updater. Sorry for the confusion, and thanks Rasmus for pointing this out. 1 Quote Link to comment Share on other sites More sharing options...
sparkdrummer Posted January 6, 2019 Share Posted January 6, 2019 Thanks gentlemen! Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 6, 2019 Share Posted January 6, 2019 The updater is pretty paranoid, and every block is checked before the F18A is modified. Don't be too worried about the initial checksum displayed on the screen - that is the program checksum and has /also/ been verified by the program to be correct. It's displayed only to make it easier for people who are BUILDING the tool to get the correct checksum to put in the code. 4 Quote Link to comment Share on other sites More sharing options...
Swim Posted January 16, 2019 Share Posted January 16, 2019 The update gave me a good 'excuse' to set up my F18A / CF7+ system today. It took me a while to figure out that my ubergrom UART/serial connection was plugged into a cable that went... nowhere. Ugh. Anyway, once I get the files transferred and update my F18A, I'll upload a TI archive to Heatwave, as a few people nabbed earlier updates that way in the past. Edit: updated to v1.9 successfully and uploaded the files in the disk image. Thanks for continuing the real TI file ARC tradition on Heat Wave. I mirror it on the Hidden Reef. Quote Link to comment Share on other sites More sharing options...
Swim Posted January 20, 2019 Share Posted January 20, 2019 Just an FYI here that the F18A 1.9 update package works as expected when the F18A is installed in a console with the 32k on the 16 bit buss running a 3.58MHz clock crystal. However, if you have just completed updating some F18A equipped consoles running at stock 32k and 3.0MHz clock speed and then move to update a 32k on the 16 bit buss console running a 3.58MHz clock crystal your heart may wind up in your throat and you may look for something to hold on to as the binary code rolls by almost faster than you can read it and you finish in almost half the time it takes to update a stock console. The F18A is a fantastic piece of hardware and the F18A firmware update software is a fantastic software package. That is all. 8 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted September 27, 2019 Share Posted September 27, 2019 With the F18A, what's an effective setup to do pixel-scroll in all directions, on an unbounded map? With 2x2 name table, there is a 48x64 area to draw in, so tiles scroll smoothly on and off all sides of the screen. But there is no wrapping, so when the visible area approaches the edge, you must relocate chunks of the name tables and recenter. Perhaps GPU can help there. With 1x1 name table and scroll registers, it wraps in both directions. But there's no buffer zone to park new columns off-screen, so you need a blank column, and both sides can't have smooth entry and exit. Row-wise, does the 30 row mode get you some extra off-screen rows? An optimization I see to 2x2 is to keep the written area of the name tables to 24+1 rows, so as not to chew up too much memory. Update it every row move. I end up keeping 64x48 of map chunks in RAM. (I think chunks will be 16x16.) Another idea is to hide some rows with the BML. Since the "non scrolled" feature went away, the BML could provide a non-scrolling status panel. With 1x2, there is a horizontal 64 columns, which would be useful if the row buffering problem were solved. Finally, I want to do parallax scrolling, so I need TL2 and TL1. I planned the memory map like so, but this ain't gonna work out: ; VDP Memory Map ; 0000 | TL2 | TL2 | TL2 | TAT | ; 0400 | TL2 | TL2 | TL2 | SAT | ; 0800 | TL2 | TL2 | TL2 | ___ | ; 0C00 | TL2 | TL2 | TL2 | ___ | ; ; uhoh TL1 and TL2 have to be the same size? ; ; 1000 | TL1 | TL1 | TL1 | ___ | ; 1400 | TL1 | TL1 | TL1 | ___ | ; 1800 | PAT ECM3 | ; 1C00 | PAT | ; ; 2000 | PAT | ; 2400 | PAT | ; 2800 | PAT | ; 2C00 | PAT | ; ; 3000 | SPT ECM3 | ; 3400 | SPT | ; 3800 | SPT | ; 3C00 | free | ; ; 4K TL2 ; 6K PAT ; 3K SPT VR29 bits set the size of SPT or PAT to 1K or 32*4*8 ; 2K TL1 ; Quote Link to comment Share on other sites More sharing options...
matthew180 Posted September 29, 2019 Author Share Posted September 29, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 29, 2019 Share Posted September 29, 2019 With the 2x2 layout you need to update the column and row just outside the visible screen in the direction of scrolling. I did that in a demo, but only for one layer. If you have two layers you won't have enough RAM for full ECM3 tables for both sprites and tiles. You can overlap the tables, reduce the number of patterns, or use ECM2 instead. Using the BML as a mask doesn't seem to be an option since a full BML takes 12K. And I don't think you can place it on top of TL2? (I always get confused about how the priorities of layers work.) It would be great if the MK2 would allow you to specify a RAM page for each table. 1 Quote Link to comment Share on other sites More sharing options...
matthew180 Posted September 30, 2019 Author Share Posted September 30, 2019 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. 19 hours ago, Asmusr said: It would be great if the MK2 would allow you to specify a RAM page for each table. 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? 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 30, 2019 Share Posted September 30, 2019 11 hours ago, matthew180 said: 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? I hadn't thought about the details, but yes, that's what I mean. The F18A is already using R10 and R11, is that what you mean by "as close as possible"? Will the BML also have a register for the high bits? Are you planning to allow access to more than 128K RAM? Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 30, 2019 Share Posted September 30, 2019 17 hours ago, matthew180 said: 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 Thanks for the info. It's still difficult to understand, but I think I'm missing a clause in JS99er that allows BML to be displayed on top of TL2. I'm drawing the layers in the order BG, TL1, BML, Sprite, TL2, and before I draw each pixel in each layer I'm checking if a pixel with higher priority has already been drawn. Is that also how the F18A works? Quote Link to comment Share on other sites More sharing options...
matthew180 Posted September 30, 2019 Author Share Posted September 30, 2019 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. 2 Quote Link to comment Share on other sites More sharing options...
matthew180 Posted October 1, 2019 Author Share Posted October 1, 2019 14 hours ago, Asmusr said: The F18A is already using R10 and R11, is that what you mean by "as close as possible"? 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. 14 hours ago, Asmusr said: Will the BML also have a register for the high bits? 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... 14 hours ago, Asmusr said: Are you planning to allow access to more than 128K RAM? 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. 4 Quote Link to comment Share on other sites More sharing options...
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.