Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Asmusr

Members
 View Profile  See their activity

  • Content Count

    4,006

  • Joined

  • Last visited

  • Days Won

    13

Posts posted by Asmusr

  1. Posted

    F18A - Mission Impossible

     

    Okay, I’ve come up with a challenge for all you Uber Programmers of the TI! I’m wondering if anyone has the skill set to design and implement a GUI loader for the TI. If a program such as this could reside in a SuperCart “, it would be ready at a split seconds notice.

     

    Now with the ‘extended graphical features of the F18A, it might finally be possible to make a really nice graphical user interface.

    The closest thing I remember to this was in TI-Artist, something like that could be updated, modified, and F18Aified. If I remember right it accepted arrow keys, letters or joystick input.

     

    So, what do you think? Are you up to it?

     

    I think it's a great idea. Using the F18A's 4 color bitmap layer it should be possible to create a reasonable looking WIMP interface (perhaps WIJP - with Joystick instead of Mouse). For the GPU it should be an easy task to move windows around etc. - all controlled from the TI side. There is also some unused flash memory on the F18A that could be used for storing frequently used files, managed through this loader.

    • Like 1

  4. Posted

    The F18A is not a 9938/58 replacement. And in this case it has nothing to do with the memory configuration. There is no "standard" for setting VR2 in the VDP. I also did follow the 9938 datasheet, however as I explained above I made a decision to add the bits versus truncate. Had I known there was code setting those LSbits, I probably would have truncated vs. add the bits, and this would not be causing any problem.

     

    I don't think you should change anything because: 1. The flexibility of placing the name table on 1K boundaries is a good feature. 2. The software that sets those bits can easily be patched. 3. It is not desirable to have several functionally different firmware versions.

    • Like 2

  8. Posted

    While searching for 80 old column utilities to dig up and bring out into the open for F18A users, I came across the attached 80 COLUMN VERSION of Mass Transfer.

     

    Now this program comes up just fine in the emulation of the F18A under Classic99, but on the actual F18A itself, it's screwed up. This should be an easy tweak for one of you TI-Gods out there.

     

    So anyone want to pick up the baton and run the final lap for the rest of the team?

     

    Mass Transfer is also setting VDP reg. 2 to 1. It can be patched by setting the word at >DDB4 to >0200 (in Classic99 debugger: CDDB4=0200).

  9. Posted

    VR2 is the name table base address. The 9918A and F18A only use the low 4-bits, while the 9938 uses the low 7-bits to support the expanded VRAM. The F18A will ignore all but the low 4-bits, so I don't see how setting the 4 MSbits would affect anything? I'll have to get some details from Tursi. Unless the original code was expecting to place the name table in VRAM over 16K?

     

     

    The original BOOT is setting VR2 to 1 in 80 color mode and 0 in 40 column mode. The patched version sets it to 0 in both modes. Apparently on the 9938/58 the two least significant bits are ignored in 80 column mode, but on the F18A they will move the name table.

    • Like 2

  20. Posted

    Since you asked about it, I tried to assemble a new object file based on my own map, in this case, the 2nd level of Marble Madness (as reduced in Magellan). The result (after I finally managed to correctly convert it to run) does display the top of the map, but instead of scrolling, it just shakes up and down by one pixel repeatedly.

     

    I've attached a ZIP file with the assembler source files used. The archive should contain all relevant files... the object file on the DSK is called VERTICALC and starts automatically. I haven't done anything but replacing the reference to the included source code in your code from "Titanium.a99" to "Marble Screen 2.a99". I've tested it both in Classic99 (QI342) and MESS (0.135), and it does the same in both emulators. By the way, I've also tested your object file (which is also on my DSK) in MESS 0.135, and there it doesn't show the glitch which is visible in Classic99 (QI342).

     

    attachicon.gifMarble2.zip

     

    You version is also shaking for me, but when I reassemble it, it works see VERTICALRC on the disk. I'm using WinAsm99 version 3.010 and Classic99 version QI372 (and MESS 0.150).

     

    Edit: In the release notes for Win994a 3.010:

    • The assembler application has been revised and updated to correct a problem with the resulting machine code generated by a few conditional branch op codes.
    Your version: 94  A056 1601            JH   CHGDY
My version:   94  A056 1B01            JH   CHGDY

    Marble2.zip

  21. Posted

    OK, I see. Seems like I misread the comments for the strips... I thought #XX - YY and the end of each line means a transition from character XX to character YY. Instead it's transition character XX, followed by the character number YY which is the half of the transition displayed here, the first line being the "from" and the second one the "to" character, or vice-versa. Sorry, I didn't look as far as I should here.

     

    For exporting from Magellan, I used the options that are given in the listing "Vertical bitmap scroll" - Bottom to Top, Wrap Edges: off, No compression, Generate Scrolled; Character Frames: 2-character Strips, Current Map Only. I left everything else the way it was, as far as I know, except for turning on bitmap mode colors.

     

    I guess the comments could be more clear, perhaps include the words 'to' and 'from'

     

    If you switch off the option 'Include character numbers' you shouldn't see the PCH labels. I have never used them myself, they were added before I started to develop Magellan further.

     

    Have you tried to assemble a new object file based on your own map?

  23. Posted

    Hmmm... something doesn't seem to be quite right in this version.

     

    There's probably a problem somewhere, but I haven't found it. The strips are split into two lines each. For some of them the character transitions into itself, so the lines are duplicated. I don't see the problem in Classic99 either. Which options did you use for exporting from Magellan?

  24. Posted

    Now that I have resurrected this thread I might as well blog a little about some is the ideas I have for further developing the scrolling algorithms.

     

    My first idea is to make a game based on 2 pixel scrolling in graphics mode 1. You could store one full pattern table for each of the four frames in VDP RAM and would therefore be able to use up to 256 transitions without any performance penalty. At 60 FPS 2 pixel scrolling looks very smooth, and I think it would be great for a racing game in lines with Spy Hunter or Bump'n'Jump.

     

    My second idea is to create more variation in the graphics by paging the transitions. In its simplest form a page would equal a computer screen. Page 1 and 2 would share pattern transitions 0-63, page 2 and 3 would share transitions 64-127, page 3 and 4 would share a new set of transitions 0-63, and so on. The idea is that the previous set of transitions would just have disappeared from view when it's time to load the next. The trick would be to avoid a delay while new transitions and uploaded to the VDP (in graphics mode 1).

     

    My third idea is to take the second idea further and have a sliding window of the currently visible transitions. Magellan would have to be programmed to supervise that when one transition appears into view another one disappears, to keep the number of transitions steady. I'm not sure how the algorithm to select which transitions to upload for a given frame would work.

     

    My fourth idea is to make more usage of animations during scrolling. In Titanium I have the blinking lights, and in Scramble I have some tile based explosions, but this could be taken much further by implementing a generic system for changing some of the patterns every frame, dividing the load evenly between frames.

  25. Posted

    Here is the second version of my code that turns a generic Magellan export file into a smooth vertically scrolling demo. This is using far less memory than the first version thanks to the suggestions made by Kurt Woloch.

     

    To use the code for your own project, follow these steps:

     

    1. Download the latest version of Magellan (currently 1.8.1).

    2. Create a map in bitmap mode colors with a width of 32 characters.

    3. Check that the map contains no more than 128 vertical transitions using the analyzing tool in Magellan. To reduce transitions, eliminate those with fewest occurrences first.

    4. Choose Export > Assembler Character Transition Data.

    5. Export with the options: Bottom to Top, Wrap Edges: off, No compression, Generate Scrolled Character Frames: 2-character Strips, Current Map Only.

    6. Edit the 'Vertical bitmap scroll.a99' file and replace the file name in the COPY directive at the end with that of your own export file.

    7. Add the file to a project in WinAsm99, assemble and run.

     

    There's more information inside the 'Vertical bitmap scroll.a99' file.

     

    I have chosen vertical scrolling in bitmap mode (actually half-bitmap mode) as my first example because this doesn't impose further color restrictions than bitmap mode already has. Let me know if you need sample code for horizontal scrolling or for graphics mode 1, and I will consider adding that to the 'library'.

    MagellanScroll-1.1.zip

    • Like 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...