+retroclouds Posted August 6, 2010 Share Posted August 6, 2010 Bumping this thread; just want to check how Magellan development is doing ? I know in the past we talked about a "feature request" list, at one point it was even added to one of the posts. Is that still the most current one, or does a newer version exist ? Would like to suggest to add it to the first post if possible Quote Link to comment Share on other sites More sharing options...
The Codex Posted August 6, 2010 Author Share Posted August 6, 2010 Thanks for the reminder! I haven't done much new with the app lately, but from your excellent suggestion I have updated the first post with the KNOWN BUGS and FEATURE REQUESTS. That's a whole lot of data in one post, basically a developer's log. Let me know what I've missed out on the lists and hopefully I can get back to work on this soon. Cheers! Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted August 7, 2010 Share Posted August 7, 2010 Did a cross-post in the colecovision programming section. Check it out here. Quote Link to comment Share on other sites More sharing options...
The Codex Posted August 10, 2010 Author Share Posted August 10, 2010 Thanks, we'll see if any ColecoVision peoples have ideas to add! Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted June 14, 2011 Share Posted June 14, 2011 (edited) Codex has been very busy and also didn't visit the TI-99/4A forum for a long time. Myself I urgently needed a few little features for handling my Tutankham maps. So I made a few tweaks & fixed a few bugs. Magellan V1.3 ------------- Modifications by retroclouds (September 2011) * Fixed some bugs in the assembler data export: a) Colorset export was using data statements instead of byte statements and values misaligned. b) Map row data: The 2nd byte of the generated data statement was wrong if it contained zeroes. This caused some messed-up screens. Magellan V1.2 ------------- Modifications by retroclouds: * Additionally show the screen XY position in hexadecimal. * Added new item to Options menu "Base 0 for Position". Normally the map upper left corner is identified as position 1/1. However, if the "Base 0 for Position" option is in effect it will be identified as 0/0. This is useful when dealing with maps for assembler programs. * Show version number in window title * Added changes to Magellan.txt You can download it here: Magellan.zip EDIT: The JAR file was missing. I've added it to the zip file now. Note that in this zip file there is no EXE file for windows. I don't know what tool Codex used for adding an executable wrapper. Googled and came up with some freeware stuff. Considered this is too risky. So you'll just have to double click on the jar file for now. I used JDK 1.6 on Windows for compiling. Edited September 4, 2011 by retroclouds Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted September 4, 2011 Share Posted September 4, 2011 While working on Tutankham, I bumped on some bugs in Magellan. I fixed them and you can download the unofficial 1.3 version here. 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 31, 2013 Share Posted January 31, 2013 (edited) Unofficial 1.4 version Import, VRAM Dump + Fixed bug with color extraction. + Fixed bug when VDP tables overlapped. + Added filetype ".bin" (Classic99 naming). + Looks for VDP registers at end of dump (Classic99 feature). If found, then dialog is skipped, and everything is set automatically including screen color (remember characters can use transparency). + If both the screen and patterns start at >0000 then the Basic/XB offset of >60 is assumed, and everything (patterns, character codes and colors) are adjusted. Making something like the space character 32 and not 128. Images + Added filetype ".gif" (alongside ".png"). Edit: New unofficial version here. Edited February 19, 2013 by sometimes99er Quote Link to comment Share on other sites More sharing options...
RXB Posted February 1, 2013 Share Posted February 1, 2013 Screens look great man! I've got some XB rendering code in the export now. You can export either XB Data or XB Exec, the latter has the added command lines but makes some other changes too. Namely, it comments out the CALL COLOR lines that are not available in XB (color sets 15 and 16), and it excludes characters above 143 (which are also not available in XB). In the map DATA statements it replaces these disallowed characters with spaces. So if you are designing for XB, don't use any characters above set 14. If anyone knows how to make these higher character and color sets available in XB, please let me know and I'll amend the export process to implement this change. In the meantime, if you want to get all your data, export using XB Data. This doesn't exclude anything, but it means that there are likely to be some disallowed lines in there should you choose to move it into XB without modifying it first. I will post this new version soon. There are other fixes in this release as well. I hope to bring down the CPU hammering at some point too. Well here is page C7 from the RXB manual: COLOR subprogram PAGE C7 ------------------------------------------------------------- Format CALL COLOR(#sprite-number,foreground-color[,...]) CALL COLOR(character-set,foreground-color, background-color[,...]) CALL COLOR(ALL,foreground-color,background-color [,...]) Description See EXTENDED BASIC MANUAL page 66 for more data. Presently modifications to the COLOR subprogram is ALL that will change all character sets from 0 to 14 to the same foreground and background colors and sets 0 to 16 may be individually set. SET NUMBER CHARACTER CODES 0 30-31 1 32-39 2 40-47 3 48-55 4 56-63 5 64-71 6 72-79 7 80-87 8 88-95 9 96-103 10 104-111 11 112-119 12 120-127 13 128-135 14 136-143 15 144-151 (RXB addition) 16 152-159 (RXB addition) Programs This line sets all character | >100 CALL COLOR(ALL,2,11) sets to foreground 2 and the | background 11 | | Sets all to transparent, then | >100 CALL COLOR(ALL,1,2,ALL,2 all to black on transparent. | 1) Go start over. | >110 GOTO 100 | Options While characters 144 to 159 are being used, you cannot use sprites. Quote Link to comment Share on other sites More sharing options...
unhuman Posted February 2, 2013 Share Posted February 2, 2013 Codex is gone Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted February 2, 2013 Share Posted February 2, 2013 A small demo of the fixed and enhanced "VRAM Dump". Classic99 includes the 8 VDP registers in its dump, and Magellan now uses this information (if found). http://www.youtube.com/watch?v=dSTXgRI1qSQ 2 Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 2, 2013 Share Posted February 2, 2013 Really nice!! Does Magellan support bitmap mode, by any chance? Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted February 3, 2013 Share Posted February 3, 2013 Really nice!! Does Magellan support bitmap mode, by any chance? Thanks. No, it's Standard Mode (Graphic 1) only. Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted February 3, 2013 Share Posted February 3, 2013 (edited) Really nice!! Does Magellan support bitmap mode, by any chance? Not Magellan, but codex did start work on a bitmap version of Magellan. Can't remember the exact name, think it was a japanese name. Edited February 3, 2013 by retroclouds Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted February 4, 2013 Share Posted February 4, 2013 (edited) New unofficial 1.5 version. A new item has been added to the Export menu. Namely XB Display Merge. Exports a map (screen size must be 32x24) in MERGE format for use with XB DISPLAY AT or XB C-XTRAS' VWRITE. With DISPLAY AT, you could use this to display the 28x24 part: 100 CALL CLEAR 110 FOR I=0 TO 5::READ T$::DISPLAY AT(1+I*4,1):T$; ::NEXT I 120 GOTO 120 With C-XTRAS' VWRITE (Wilhelms XB Compiler), you could use this to display all of the 32x24: CALL INIT CALL LOAD("DSK1.C-XTRAS") 100 FOR I=0 TO 5::READ T$::CALL LINK("VWRITE",I*128,T$)::NEXT I 110 GOTO 110 Here's a quick demo: mergexb.mp4 Edited January 13, 2023 by sometimes99er 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted April 21, 2013 Share Posted April 21, 2013 Hi sometimes99er, are you planning to add support for bitmap mode colors to Magellan? If not then I think I will do it. Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted April 22, 2013 Share Posted April 22, 2013 Hi sometimes99er, are you planning to add support for bitmap mode colors to Magellan? If not then I think I will do it. I would certainly consider implementing half bitmap mode, the one with all the colors, but only one character set (full bitmap mode uses 3). Only problem with half bitmap mode is, that it's apparently only safe to use the first 8 sprites without getting unpredictable debris (on hardware 9918A). The Codex did work on another project for full bitmap, and it's called Tadataka. Link is here. It looks like the source is not there. Maybe retroclouds or Opry99er knows how to get in touch with Codex. Codex got a retro-site here. Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 22, 2013 Share Posted April 22, 2013 Yeah.. I played with the sprite problem and took some notes on it.. it's reproducible but a little tricky to completely characterise. Most of the time, you end up with the sprites higher than index 8 mirroring in groups with the mirrored pattern tables. Sprites 0-7 always work fine. BlueMSX tried to emulate it, but got it wrong enough that they had to take it back out again. I wrote a test app to experiment with it, but I don't fully understand it myself. I have a video here: Quote Link to comment Share on other sites More sharing options...
Opry99er Posted April 22, 2013 Share Posted April 22, 2013 Unfortunately I have also lost touch with Codex... His eMail addresses are no longer good and I cannot find him anywhere... He has a LinkedIn profile, but as I'm not a member, I cannot obtain access to his page. He is sorely missed... A great guy and a fantastic contributor for the short time he was a part of the community. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted April 22, 2013 Share Posted April 22, 2013 Isn't this his website? http://www.dreamcodex.com/ Quote Link to comment Share on other sites More sharing options...
Asmusr Posted April 22, 2013 Share Posted April 22, 2013 I would certainly consider implementing half bitmap mode, the one with all the colors, but only one character set (full bitmap mode uses 3). Only problem with half bitmap mode is, that it's apparently only safe to use the first 8 sprites without getting unpredictable debris (on hardware 9918A). The Codex did work on another project for full bitmap, and it's called Tadataka. Link is here. It looks like the source is not there. Maybe retroclouds or Opry99er knows how to get in touch with Codex. Codex got a retro-site here. I was also thinking about about half bitmap mode, but I wasn't aware of the sprite issue. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted April 22, 2013 Share Posted April 22, 2013 Yes, that is his website. the link to his eMail on there is bad, though... unfortunately Quote Link to comment Share on other sites More sharing options...
Asmusr Posted April 22, 2013 Share Posted April 22, 2013 In relation to sprites and half bitmap mode, I was wondering if the VDP memory areas that are masked off by this mode (>0800->17FF) and (>2800->37FF) - and are therefore impossible to write to - can be used for sprite pattern tables if you copy your data into VPD memory before enabling the half bitmap mode? It seems to work fine on Classic99. Could the sprite bug have anything to do with where you place your sprite tables? Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 23, 2013 Share Posted April 23, 2013 (edited) Hmm.. I didn't test moving the sprite attribute list to see what effect it has. (It would be read issues by the VDP itself, not write, you can write all of VRAM regardless of the video mode masking bits). Also, it still tends to /display/ the sprites, but they are mirrored -- look towards the end of the video I posted. TI doesn't say a lot about it except that the issue exists, and I learned about it on an MSX forum while researching problems in a ColecoVision app. Unfortunately I didn't know about it back when we had a chance to ask the chip designer questions, or it would have been a good one! It must have something to do with the way bitmap was added to the chip, though. Classic99 doesn't attempt to emulate this bug/glitch/feature because I don't understand it well enough. Edited April 23, 2013 by Tursi Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted April 23, 2013 Share Posted April 23, 2013 I still do most of my graphic work (9918A) in a dedicated graphic editor, but it’s nice to have Magellan which has its own thing. With games the idea of half bitmap mode is very nice. Colorful graphics and a Screen Image Table (SIT) for quick and easy display changes. If you want to use more than 8 sprites you “simply” go for full bitmap mode, and copy the character set (patterns and colors) to all 3 character sets. As a design tool, and graphic editor, I think Magellan should support half bitmap mode. It should fit nicely there with 1 character set edit already there. I would like to have the character set magnified though (x2). When it comes to full bitmap mode, I don’t think Magellan needs to be pushed there. There are a few implications and in particular the user-interface to be considered. If you got the time, then by all means, as long as existing stability and functionality is not compromised too much. Full bitmap mode in itself, mostly leaving the SIT in an initialized state, has potential in many game ideas, but the bitmap becomes more of a “drawing area” (even if just two thirds). Playing around with full bitmap mode is fun, but I don’t think you design “pictures” using characters. Painting tools, moving across characters, in an iterative design phase, will most likely demand the initialized state of SIT. Giving up some functionality and then maybe just for a while. I wonder if Tadataka is the answer for that, and then perhaps the ability to import from Tadataka (and the other way around - losing specific SIT info). The development of Magellan has been driven by different needs and ideas. And there are certainly many ideas for further development like text mode, multicolor mode, sprites, animation, onion-skin, scripting, vectors, 3D, perhaps even sound and more. Anyway, encapsulating the 9918A within Magellan might be an idea. Whatever editing features we can think of, the target is known (relatively). Change mode from graphics to text, move the SIT forth and back, watch the display consequences and shake your head in disbelief. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted April 23, 2013 Share Posted April 23, 2013 It would be read issues by the VDP itself, not write, you can write all of VRAM regardless of the video mode masking bits I see. For some reason I thought that the masking was for both read and writes, but it's clearly more useful if it's only for reads done by the VDP. 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.