Jump to content

Recommended Posts

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 :)

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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 by retroclouds

Share this post


Link to post
Share on other sites

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 by sometimes99er

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by retroclouds

Share this post


Link to post
Share on other sites

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.gif

Edited by sometimes99er
  • Like 2

Share this post


Link to post
Share on other sites

Hi sometimes99er, are you planning to add support for bitmap mode colors to Magellan? If not then I think I will do it.

Share this post


Link to post
Share on other sites

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.

 

:)

Share this post


Link to post
Share on other sites

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:

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 by Tursi

Share this post


Link to post
Share on other sites

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.

 

:)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...