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

  1. Posted

    Interesting stuff. I'm thinking about adding a new section to the "Development Resources" sticky thread.

     

    I don't have a name for it yet, but this is the kind of stuff I'd like to add references to.

    I'd see this as the basics every good homebrew game programmer should know about :D

     

    * Algorithms used in game development (e.g. Bresenham, pseudo 3D, ...), pseudo random generators, ...

    Hey I don't know much about these but I'm willing to learn :P

    * Free Bit-map font resources, sprite graphics, ...

    * Tutorials about graphic conversion, ...

    * Video's on how to create cartridge labels, how to create cartridge boxes, ...

    * ...

     

    If you have stuff you want to contribute, just let me know and I'll be more than happy to add it to the list.

    Also if you have an idea for a proper name for this section let me know. "Miscellaneous" sounds rather boring.

     

    Any feedback on what you like or dislike about the "Development sticky thread" is appreciated.

  2. Posted

    Don't worry about the scrolling guys, it will be as good as the colecovision version ;)

    In this early prototype I just do a basic dumping of the screen while it is being displayed.

    There are smarter ways to do this, but first want to have some more functionality in place before I get into the optimisations.

     

    The sprite is moving 1px at a time and should be smooth. The video was recorded in MESS. I then took the uncompressed AVI and converted it using DIVX converter before uploading to Youtube.

    I guess some frames are skipped. Just give the binary in the zip file a try ;)

     

    As far as the original TI prototype is concerned, I prefer to stay out of that discussion :P

    In the end each version will have its pros/cons.

     

    What I can tell is that Brian gave me a valuable hint on how to deal with the joystick handling, so am happy about that.

  3. Posted

    Not really sure, but I seem to recall that Tursi has plans on adding a cartridge library (perhaps something in the style as win994A has?).

     

    At this time, I suppose the only way to add cartridges to the menu in classic99, is to add the appropriate entries in the classic99.ini file.

     

    Something like this:

     

    [usercart0]
name=Tutankham
rom0=3|0000|8000|D:\Projekte\tutankham\tms9900\TUT.bin

     

     

    I'm afraid you'l have to read the manual (in this case classic99.txt) ;)

    Here is an extract on the ROM section

     

    [roms]
cartgroup
0	Apps
1	Games
2	User

cartidx
-1	No cartridge selected
??	index of the cartridge from the appropriate menu

[userCart0]	 (and so on up to 99)
name
Name of the cartridge. If blank or missing, the cartridge is ignored.

message
Compatibility notes, if desired

rom0	(0-3 for a total of 4 ROMs per cartridge)
Contains notes for loading the cartridge. This is a pipe-limited row
of data, formatted like so:
T|AAAA|LLLL|filename

T is the single character ROM type. Most carts only use G, C and X types.
C	CPU ROM
D	DSR ROM
E	DSR ROM bank 2 (used for p-code)
G	GROM*
P	P-Code GROM
R	CPU RAM - this is loaded like CPU ROM but is not flagged as read-only!
S	Speech ROM
V	VDP RAM
X	XB Bank 2 ROM (called 'D' in some systems, but I used D already)
A	AMS memory, RLE encoded (not working correctly yet)
K	Paste string for the keyboard after boot (to autostart tasks, not a filename)
3	Packed banks with a '379 style decoder. Similar to XB style but more banks and 
	all in one file. Note that this assumes a load at >6000, so you are specifying
	the offset in the banking space, with bank 0 at >0000, bank 1 at >2000, etc.
	SuperSpace carts (CRU >400) can be loaded this way for now, too, but will 
	likely split them up later. Max size is 64k.

(* GROM is special - to support multiple GROM bases, you can now load GROMs
into different memory bases - up to 16 of them! By default, GROMs load into
memory base 0. Append a hex number 1-F after the G to specify a different
base (like: G1). The console will detect these and add them to the start menu! 
Note that not all GROMs will work at alternate bases. Also note, in the real 
console, the console GROMs appear at all bases, so you can't load alternate
bases at less than >6000. Classic99 does not support using this with cartridges that
include CPU ROM. Each GROM base is offset 4 from the previous, ie: GROM Read
is >9800, >9804, >9808, etc.)

AAAA - load address in hexadecimal

LLLL - length of data in hexadecimal (will override actual size of file)

filename - filename on disk to load

This system supports both raw ROM files, and ROM files with a 6 byte GRAM
Kracker style header. The header is detected by checking if the first byte
is >00 or >FF, and if the 5th and 6th bytes represent the load address. The
header will be ignored if detected - the data in this INI file is
considered authoritative.

  4. Posted

    Here is the first early prototype of my homebrew version of Tutankham.

     

    It's a remake of the colecovision game that will be enhanced with title screen, theme music and speech (when using TI's speech synthesizer).

    This game is 100% pure TMS9900 assembly language, only using the 256 bytes scratch-pad memory and designed as cartridge ROM image from day 1.

     

    The idea is to release this game as cartridge with instruction manual and cardboard box in early 2011.

    Note that my homebrew version is not related to the ultra-rare-only-1-to-find-prototype mentioned at the Videogame House.

     

    Here's a YouTube video of the v0.1 prototype:

    http://www.youtube.com/watch?v=If6C6jPQR9w

     

    Version 0.2 (05-25-2010)

    * Teleporters are working

    * Level 2 maze in place

    * "white-flash" working (press fire button or space bar to engage)

    * Movement is a bit smoother, and resembles colecovision version more closely

    * Bug-fix: you can't walk through walls anymore

     

    Version 0.1 (04-04-2010)

    * Initial version

     

    EDIT:

    I've decided I won't be releasing any ROM images of WIP versions anymore.

    There will be a BETA phase for a closed group of people before the cartridge comes out.

    I might release the final ROM to the cartridge buyers and release to the public domain at

    a later stage. But that isn't confirmed yet.

    • Like 4

  6. Posted

    Just gave it a try. Pretty slick for Extended Basic :)

    Guess if you want to get more out of this you'd have to implement some assembly language routine.

    Then again, I'm not that much a fan of hybrid extended basic/assembly programs.

     

    But for this type of game (with complex logic) writing everything in assembler seems pretty hard/time consuming/cumbersome.

    Wonder if C99 would be the way to go in this case.

  8. Posted

    I will be looking into this one ...

     

    Tile Studio

    Tile Studio download

     

    :cool:

     

    I used Tile Studio for my (currently stalled) Time Pilot project.

    Had a real basic exporter for handling VDP9918 16x16 sprites.

    What I like about Tile Studio is that the source code is available.

     

    Don't ask any questions about this, I have totally forgotten how it works :D

     

    ; --------------------------------------------------------
; Tile Studio Definition File
; TI994A_sprites_16x16.tsd
;
; Generate 16x16 sprite raw data for the
; Texas Instruments TI-99/4A
;
; by RETROCLOUDS
;
; v0.1   12.07.2009
; --------------------------------------------------------

#file sprites_16x16.raw
#tileset
*--------------------------------------------------------------
* Sprite 16X16 pattern data by Tile Studio <TSVersion>
* <CurrentDate> <CurrentTime> - <TileSetIdentifier>
*--------------------------------------------------------------
* Tiles: <TSTileCount>
#tstile
* Tile: <TileNumber>
#tiledata "\[email protected][email protected]:" "" "" "|" ""
<(Pixel+1) :"%01x">
#end tiledata
#end tstile
#end tileset
#end file

     

    tp.png

  9. Posted

    Not knowing anything about hardware. Too bad the load interrupt signal is not on the cartridge port.

    That way some genius could put a timer on a cartridge PCB for generating the load interrupt.

    ok, this would require 32K memory as the vector is located at >FFFD and >FFFE.

     

    hhmm, thinking about it more I recall we had some discussions about a cartridge PCB that plugs into the sideport.

  10. Posted

    I have several rare and uncommon, but nothing super-rare like "Arcturus" or "Tutankham". Tutankham can still be bought from the designer--- in cart form. For a few thousand dollars, you can have one too! That guy strikes me as a jerk... He should make them $100 and sell the sh** out of 'em. Bryan Roppollo bought one for an insane amount of money. He and Bill Gaskill are probably the foremost cart collectors out there--- along with Jim Fetzner and one or two others. I would crap myself if I could see Bryan's collection... :). Bryan (I think) owns the only known copy of Robotron for the TI. He was kind enough to release the code, and it can now be put on one of our dance cart boards Jon Guidry built. Jon owns an Arcturus cart... A-hole. :). We have such a great community, man... And AA gives us a modern home. List servers are fine, but this forum is just what we needed

     

    No need to spend some thousand dollars on the "Tutankham" prototype. I'm working on my own homebrew version.

    It is based on the Colecovision version, not on the TI prototype and will be better ;)

    Currently going for a 32K ROM image but might end up with a 64K ROM image.

     

    Oh, this is not some april fool (living in Germany, we already have April 2nd) :D

  11. Posted

    hehe, thanks man. It was fun to do, but in the end as I was glad I finished it. I don't wanna take a second look at that game.

    Done with that. I'm hoping my next game will be a blast, but unfortuntatly work has been a killer lately. So we'll see how it goes.

     

    Well for me the true heroes are those that implement new game ideas all by themselves. Looking what you guys came up with in the competition, it's

    just amazing. I definitly want to see Flyguy as a homebrew cart. And I'm sure Karstens' Destroyer will kick butts big time.

     

    Looking forward seeing how this all further develops. Have to admit, I now check this place out more often as the yahoo group.

     

    Atariage rocks! :D

  13. Posted · Edited by retroclouds

    If Nintendo themselves would have designed Colecovision DK, I think they could have borrowed quite a lot of code from the original arcade version (which uses a Z80 processor as well), and this would likely have improved the quality of the game.

     

    opcode games is working on a new Donkey Kong version for the colecovision. I think they are using this procedure

    where they change the frontend (graphics engine) but keep original code for getting the version as close as possible.

     

    check out this thread.

  15. Posted · Edited by retroclouds

    Below is the article I mentioned yesterday. It is extracted from The Smart Programmer February 1984 and deals with Basic programs that are too large to run from disk.

     

    A gentleman from Georgia recently asked us how to get a Basic program that is stored on disk and is too large to

    run with the disk drives attached to run.

     

    The problem was such that the program could be loaded into memory from the disk but it contains a large number of

    numeric and string variables which eat up a lot of memory when the program is running. In Basic the computer does

    not recognize Expansion Memory as a place to load programs so they must load and run from VDP RAM.

    Unfortunately the disk buffer space is also in VDP RAM and uses up some of the space that may be necessary to run

    large Basic programs. Even with the CALL FILES(1) command there is still aprox 500 bytes retained as a disk buffer

    and this may be just enough to crash the program. The CALL LOAD, which is listed below, will shut off the disk drives

    but in Basic you must type in NEW to open up the memory space.

    Naturally whenever you type in NEW your program is cleared out of memory and that was the problem.

     

    The solution requires the Mini-Memory module to be plugged in the cartridge port and Expansion Memory to be attached

    and turned on. With the Mini-Mem in the port there are a few new commands added to the Basic language, even though

    you have selected TI BASIC. The ones that we are concerned with are SAVE and OLD, MINIMEM, EXPMEM1, EXPMEM2 and out of

    these we really only need SAVE and OLD EXPMEM2.

     

    The procedure for running these large Basic programs from disk is as follows:

     

    1. Power Up, select Basic and type in CALL INIT. This will initialize memory expansion and it will also clear out what

    ever was stored in the Mini-Mem module. If you want to retain what is in the Mini-Mem just turn off the memory expansion

    and then turn it back on and that will clear out without erasing the Mini-Mem.

     

    2. Load the program you want to run from your disk. OLD DSK1.xxxxxxx

     

    3. Type in SAVE EXPEM2 and press ENTER. This will copy the

    program in VDP RAM into the expansion memory.

     

    4. Type in CALL LOAD(-31888,63,255) and press ENTER. This tells the computer not to reserve any room in VDP RAM for the disk buffers.

     

    5. Now type in NEW and press ENTER. You have just opened up the extra memory space in VDP RAM that the disk was reserving.

    But since Basic does not recognize expansion memory your program is still intact in high exp-memory, addresses hex >A000 through >FFFF.

     

    6. Just type in OLD EXPMEM2 and press ENTER and this will copy the program in the exp-memory back into the VDP RAM program area.

    A copy of the program is still in the exp-memory and it will remain there until you turn off the exp-memory, save another program into

    that space or type in CALL INIT. No, you can't MERGE Basic programs.

     

    7. Type in RUN and press ENTER and the program should now run without giving you a MEMORY FULL ERROR.

     

     

    We didn't use SAVE MINIMEM or SAVE EXPMEM1 because neither one of these spaces are large enough to store a large Basic Program, 12K+.

    The MINIMEM space is 4K of RAM, the EXPMEM1 space is 8K of RAM and the EXPMEM2 is 24K of RAM. Also the EXPMEM1 space will allow you to

    save a program out there but it doesn't like OLD EXPMEM1 so you can't bring it back. You can use any one of these three names in an OPEN

    statement for files provided you are not linking to an assembly language subroutine in which case it is best to just use EXPMEM2 in your OPEN

    statements for files.

     

    The best solution, if you have exp-memory, is to rework the programs to allow them to be loaded directly into exp-memory via Extended Basic.

    You will probably have to rework some of the CALL CHAR's, HCHAR's, VCHAR's and CALL COLOR's to compensate

    for the lack of characters sets 15 and 16 in Extended Basic.

    You will however find that they run a little faster and they are easier to edit in Extended Basic.

  16. Posted

    You expect me to know how to do any of that? :)

     

    Do you see any reason for my original, somewhat cumbersome plan not to work? If I OLD CS1, delete some lines, then save it... then OLD CS1 again, delete the other lines, save THAT... then merge the two half-programs and run it through BXB to make it work in Extended BASIC. Suddenly we can access the 32K, problem is solved. Then we find out what the contents of the data file are that the program loads, replace that with hard-coded variables in a subroutine, and we're all set.

     

    I'm hoping to get a bunch of this done tomorrow -- big project is over and I may have some TI time before the next wave of work submerges me.

     

    ok, that's a good plan ;)

     

    Think this may work.

     

    Guess it mainly depends if the BASIC game uses character set 15 and 16, which aren't available in Extended Basic.

    I don't know what BXB is. Is it used for dealing with the character set issue ?

     

    Good luck :)

  17. Posted

    I think that the problem with Atlantis will be that it won't work if there any disk drives (or CF7+) connected to the console.

    Most likely the game requires all of VDP memory (which it won't get as there are some disk buffers in VDP).

     

    Just this morning I came accross an article in the Smart Programmer (february 1984), the trick for actually running the game from disk would be to use the Mini Memory module and some of it commands (SAVE MEMEXP2, OLD MEMEXP2) in combination with CALL LOAD(-31888,63,255) for turning the disk drives off.

     

    I have no TI time at all today :( but will get back tomorrow with the article from the Smart Programmer.

     

    Could be that an initial conversion program will be required for writing the BASIC program from >A000 to disk (that would be a one-time thing) and for the data files. Don't have the details on this yet.

     

    Would help if the cassette file would be available as WAV for processing with CS1er ;)

  19. Posted

    I've had my TI since 1982 but never could afford the PEB (always drooled over it in the catalogs/magazines) and now I've gotten serious about it. The enthusiasm within this TI community is also quite infectious and I need to start dabbling in the programming as well. To that effect, I'll likely need Extended Basic, Editor/Assembler and other programming goodies as well.

     

    Steve

     

    Welcome Steve! The more the better I'd say; we can always use some more TI-99/4A programmers ;)

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...