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

retroclouds

+AtariAge Subscriber
 View Profile  See their activity

  • Content Count

    2,123

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by retroclouds

  3. Posted · Edited by retroclouds

    wow, almost an hour without Atariage :(

     

    What happened? Was this due to database backup or was there a maintenance.

    Something happened to the skin too, the fonts appear smaller now.

    This makes the bold fonts harder to read.

  4. Posted · Edited by retroclouds

    Not having done much with Small C, I can't vouch for the quality or content of this free book, but here's a link for those who are interested:

     

    http://rapidshare.com/files/4300500/M_T_Books_-_A_Small-C_Compiler.rar

     

    Thanks for pointing this out codex! This is the online version of the Small C Compiler book I mentioned earlier.

    I looked for the online version for a long time, but didn't get lucky.

     

    This is good stuff! :thumbsup: :thumbsup: :thumbsup:

  6. Posted

    Walid, is there a dedicated site for C99 programming? Possibly a place to get all the docs and disks needed to work in C99?

     

    I think it would be a great idea to add C99 to the Development resources thread ;)

     

    For those who don't program on the TI-99/4A directly (or emulator). There is also an (old) cross-compiler version for running on the PC, available on whtech.

    I believe that Fred Kaal has programmed most of his disk utilities using this cross-compiler and a custom loader.

     

    Anyway, I'll look at my notes and add C99 to the development resources thread. If anyone has URL's/resources to share concerning C99 then please contact me and I can add it to the mentioned thread :)

     

    On a sidenote, I've checked in making SPECTRA compatible with C99 and that certainly looks doable.

    The main issue is that SPECTRA uses another register as stack pointer and the stack itself grows in the wrong direction, but that would be quite easily to fix in a new version. The reason I would make SPECTRA compatible with C99 is that it

    would be possible to do a cartridge only game (256 scratch-pad memory). Ofcourse you would also have to fiddle with the C99 library itself, but should be doable.

     

    I got myself the "a small C compiler book", which not only explains small C, but also explains the inner workings of the compiler. Even though not directly TI-99/4A related a very interesting read (haven't found this book in an online version).

  9. Posted

    Played around with the latest version. The below screenshot shows I definitly have zero drawing skills :rolling:

     

    post-16219-12721846202_thumb.png

     

    While playing with Magellan, I noticed following things would be nice.

     

    1. Undo functionality: Revert the latest modification(s)

     

    2. Would be cool if you could move/copy certain parts of the screen. e.g. in my screenshot copy letters to complete

    the title screen as "FRANKY AND FRANK". In this example I would only need to add one additional letter.

    Now I have to draw them all again.

     

    3. When the "look at character mode" is active it would be nice if the matching character in the character set would be

    highlighted as well. That way you know exactly what character you are looking at.

     

    4. Possibility to shift character pattern 1 pixel left/right or up/down.

     

    5. Copy character patterns by drag and drop in the character set. This is only minor as there is a workaround; go the character pattern; select hex codes, go to other pattern, insert hex codes.

     

     

    Anyway, Magellan rocks :thumbsup:

  10. Posted · Edited by retroclouds

    I have a minor amendment to the binary format that I would like to suggest. It should be possible to include the colorset and character data as chunks as well, but optionally so. That gives the developer the option to control how much map is stored in a single file, and how much they wish to obtain from secondary files (or assign programmatically). Here is my proposed version of the binary format, please let me know your thoughts on this.

     

    Data map export: Proposal for binary file format
================================================

<FILE HEADER>
<COLORSET CHUNK (optional)>
<CHARDATA CHUNK (optional)>
<MAP 0 - MAP HEADER>
<MAP 0 - MAP DATA>
<MAP 1 - MAP HEADER>
<MAP 1 - MAP DATA>
  .
  .


A) FILE HEADER
=================
byte 0-1        2b: String constant MG
byte 2-3        2b: Magellan version identifier
byte 4          1b: Chunk header *
byte 5          1b: Number of maps in file

B) COLORSET CHUNK
=================
byte 0-15       16b: Full colorset definition table (16 1b foreground/background pairs)

C) CHARDATA CHUNK
=================
byte 0          1b: Number of character definitions
byte 1          1b: Character to define
byte 2-5        4b: Character data
  .
  .

D) MAP HEADER
=================
byte  0-3       4b: Magellan option flags for map 
byte  4-11      8b: Size of (E) in bytes
byte 12-13      2b: Number of columns in map
byte 14-15      2b: Number of rows in map
byte 16         1b: Screen background color

E) MAP DATA
=================
byte 0-xxxx     Tile character values (0-255) or RLE encoded data

     

    * The "chunk header" specifies if optional data chunks are included, using bit flags. The colorset chunk is 01 and the character data chunk is 02, so specifying both would be 03 and neither 00.

     

     

    Sounds great. Thinking of it more, you could add new sections following (E) as Magellan evolves.

    They again would contain a header and a data section. For the first 12 bytes, they could also follow

    the same format as the map header. Suppose you are adding a new section for sprites positions per map.

     

    F) MAP SPRITE HEADER
====================

byte  0-3       4b: Magellan option flags for sprites in current map  
byte  4-11      8b: Size of (G) in bytes 
byte  12-xx     Some Specific stuff for sprites

G) MAP SPRITE DATA
==================
byte 0-xxxx     Sprite data

  11. Posted

    Well, I'm not sure I understand the intent of the binary file. Is it intended for use on a real TI (or emulator), so something else?

     

    Matthew

     

    If you are on a PC, I don't think it's that important. You have XML parsers for about any language you can think about.

    I mainly program perl and like to do things myself, that is why I mainly opted for a binary format.

    Also thinking that I could dump the binary file directly to ROM (Sorry was more thinking about Colecovision here).

    It's not that hard to write a converter for turning the XML structures in binary format, so I won't complain that hard if we get an XML structure in the end :)

  12. Posted

    There are a few problems I have with a binary format:

     

    1. You have to know and agree on the byte order

    2. You have to know and hard code the format

    3. It is hard to change, i.e. add new stuff later

     

    It seems that this is a perfect example of where something like XML would actually be useful. I'm assuming of course that this universal format is intended to be process on a modern computer, and not the TI (either real or emulated) directly? I'm not clear on that.

     

    Matthew

     

    Even though I use XML on a regular basis, I think its a bit of overkill for what we are trying to accomplish here.

    I understand that when doing an import from XML, it could help you to get the different sections nicely separated into your

    programs' memory and may help in terms of extendability.

    However, if you are writing a converter, you have to know what to access when for generating your output anyway.

     

    Nonetheless, as far as the data structures in the export file itself are concerned, I don't think it will make that much of a difference if they are wrapped in XML or are plain binary, so I'd say let the majority and Howard decide ;)

  13. Posted

    Thinking about this: Adding the possibility to run an executable file after the export has finished would make

    this a pretty transparent process. You could define the command line options in a Magellan settings file.

  14. Posted

    I have a proposal for the binary file format to use when exporting map data.

    Note that this proposed file format is only for the map data itself.

    For the patterns and colors, I think we have a good solution with the PNG format.

     

    The reason I'm proposing this file format for binary export, is because the export format for

    the source data statements will be havily depending on the actual player code and the language it's written in (Assembler, Extended Basic, Forth, C99).

     

    By using an intermediate binary format the game developer can write his own "converter" for turning the maps into source code focussing on his particular needs.

     

     

    Data map export: Proposal for binary file format
================================================

<FILE HEADER>
<MAP 0 - MAP HEADER>
<MAP 0 - MAP DATA>
<MAP 1 - MAP HEADER>
<MAP 1 - MAP DATA>
  .
  .


A) FILE HEADER
==============
byte 0-1	2b: String constant MG
byte 2-3	2b: Magellan version identifier
byte 4		1b: Number of maps in file


B) MAP HEADER
=============
byte  0-3	4b: Magellan option flags for map 
byte  4-11	8b: Size of (C) in bytes
byte 12-13	2b: Number of columns in map
byte 14-15	2b: Number of rows in map
byte 16         1b: Screen background color

C) MAP DATA
===========
byte 0-xxxx	Tile character values (0-255) or RLE encoded data

     

    Remarks

    * Note that bytes 0-3 in the map header (B) can be used for setting Magellan map status flags.

    Would be up to Codex to decide what to put in there. An example could be a status bit

    telling if RLE compression is on for (C ).

     

    * Byte 16 in the map header (B) indicates the screen background color. I added this as I presume this is not present in the PNG format. We can easily drop byte 16 should the background color be present in the PNG.

  16. Posted · Edited by retroclouds

    Oh no, now I getting even more stupid ideas - like loading modified graphics to the VDP while a game or something is running. Hmmm, the Debugger should already do that.

     

    Have to check this out. I thought you can't write to (VDP) memory from the classic99 debugger ?

     

    This reminds me of openmsx (MSX emulator). They have those TCL scripts for doing "stuff" while a game is running. I seem to remind a youtube video where they demo writing to the VDP from such script while a game is running.

  17. Posted

    I'm for sure no expert on this. But the bin files are basically dumps of the bankswitched ROMs.

    Unless the source code for this game shows up, the only way to make this a disk-only game running from the 32K memory expansion would be to

    disassemble the ROMs. Re-allign all branches and relocate code to high memory. Also you'd have to remove the bank-switching.

     

    So basically you would have to disassemble the game and understand what part of code is doing what.

    I'm not saying it's not possible but it is a big task. You'd write some kind of disassembler/scanner first.

    Considering the amount of effort that would need to be invested, I guess you could as well rewrite the game from scratch.

  18. Posted

    Picked up my 50 PCB's and 50 cartridges at customs today. Guess they have tracked me now :ponder:

     

    Costed me 74 euros. And the lady from customs, man let me tell you; I thought I was facing russian KGB this time.

     

    The boards do make up for it nicely. It was well worth it. They are of the finest quality!

    Also the way everything was shipped, very very professional.

     

    If there ever will be a next shipment, I won't mind the electroshocks at customs.... hmmmm not really :-D

     

    Thanks for the hard work on this Jon! Appreciate it a lot.

     

    retroclouds

  20. Posted 

    * VDP#6 SPT (Sprite pattern table)     at >0400  (>80 * >008)

    I think the multiplier is >800 as with the PDT.

     

    ;)

     

    Yep, I just checked the VDP programmer's guide: the multiplier for VDP#6 is >0800 :ponder:

    Lucky for me I wasn't using any sprites.

  21. Posted · Edited by retroclouds

    Hey you other TMS9900 assembly language programmers out there :)

     

    What format would you guys propose ? For starters my proposal would be to go for a basic export format. Something not too complicated nor optimized.

    This would keep both the Magellan exporter and the assembly player code easy (as long as no final format has been established).

    That is why I also requested the possibility to export color/map/pattern data as a raw binary file.

    That way if a developer sees a need, he can write his own converter for his specific needs.

     

    Any thoughts on that ?

  22. Posted · Edited by retroclouds

    If you are interested you also might want to checkout the TECH MANUALS section in the development resources sticky thread.

    Look for the "VDP Programmer's guide" for further details on the VDP.

     

    The thing is that the tables in VDP memory which are responsible for holding characters definitions, colors and tiles, sprites etc.

    are controlled by a bunch of VDP registers. In assembler these tables pretty much can be located according to the programmers' needs.

    Now in Basic and Extended Basic there are a lot more constraints as far as the size and location of the tables is concerned.

     

    And I have to mention it again, after having played with Mangellan a bit, this is a mighty fine tool ;)

  23. Posted · Edited by retroclouds

    ok, I took the assembler export output of citymerg.mag and was able to make it work in editor/assembler after tweaking it a bit.

    I used the winasm99 cross-assembler and did the testing with the classic99 emulator.

     

    For testing you can just drop the MAGELLAN.obj file in your classic99 DSK1 folder and load it using EA#3.

    **WARNING** This is not an actual player. It's merely a dumb assembler program for testing the export functionality.

     

    magellan_asm.zip

     

    I made some adjustments that I'll try to explain below.

     

    Before we get into the details; Here is how I did the VDP setup for graphics screen mode 1.

     

    ***************************************************************
* VDP graphics mode 1 
********@*****@*********************@**************************
* VDP#0 Control bits
*       bit 6=0: M3 | Graphics 1 mode
*       bit 7=0: Disable external VDP input
* VDP#1 Control bits
*       bit 0=1: 16K selection
*       bit 1=1: Enable display
*       bit 2=1: Enable VDP interrupt
*       bit 3=0: M1 \ Graphics 1 mode
*       bit 4=0: M2 /
*       bit 5=0: reserved
*       bit 6=1: 16x16 sprites
*       bit 7=0: Sprite magnification (1x)
*
* VDP#2 PNT (Pattern name table)       at >0000  (>00 * >400)
* VDP#3 PCT (Pattern color table)      at >0380  (>0E * >040)
* VDP#4 PDT (Pattern descriptor table) at >0800  (>01 * >800)
* VDP#5 SAT (sprite attribute list)    at >0300  (>06 * >080)
* VDP#6 SPT (Sprite pattern table)     at >0400  (>80 * >008)
* VDP#7 Set background color to gray
***************************************************************
VMODE1  DATA  >0000,>01E2,>0200,>030E,>0401,>0506,>0680,>070E

     

     

    Color definitions

    * In assembler you only need 1 byte for setting both the foreground and background color of a color set.

    * Also the colors start with base 0 instead of 1

    * This is my colorset statement. Note that I used BYTE instead of DATA here.

     

    CLRSET  BYTE >10,>10,>10,>10,>10,>10,>10,>10,>00,>BA,>3C,>45,>61,>10

     

     

    Patterns

    * I did a raw dump to the VDP in a continious block. This means I first stripped the character code and inserted some empty patterns in the assembly source. Actually the idea of having the character code in front of the pattern code isn't bad. However it would be best to make this optional and go for a table driven solution as suggested by Matthew.

     

     

    Map data

    * I noticed that even though there are 3 screens, it repeatedly exports the same screen.

     

     

    Anyway, great job Howard! :thumbsup: :thumbsup: :thumbsup:

  25. Posted

    Thanks for the format example Filip, that's a huge help. And binary format should be easy as well. Any suggestions for the most desirable form for that? Just a bunch of concatenated hex strings, or perhaps standard image formats like PNG?

     

    hmmm, I'd go for concatenated hex strings ;)

    Keep up the good work :thumbsup:

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...