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

Vorticon

Members
 View Profile  See their activity

  • Content Count

    4,690

  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Vorticon

  1. Posted

    To be honest, it's really hard to sit behind a keyboard when there is nice and warm weather outside, especially when one lives in Minnesota ;) Between the pool, R/C planes, model rockets and backyard astronomy, my spare time is all used up :)

  3. Posted

    You are a good dad! When I was a kid, all I got was a $150 99/4A... ;-) Heh, new PC... bah. Give him a 99/4A and ToD cart, tell him he can have a new computer once he rescues the king from a 10 level dungeon on the hardest skill level. :-)

    Unfortunately, I was never able to get either of my two kids interested in the TI despite my best efforts... There was a brief time a long time ago (they are now 16 and 21) when they played Terry Turtle's adventure and Soundtrack Trolley on the MBX, but that did not last long :(

    My son still makes fun of me when he sees me playing an old TI game, and he can't seem to get past the relatively primitive graphics. I really think kids these days are less imaginative than a generation or two ago when one's imagination filled in the gaps left by the blocky graphics (or even ASCII text). I guess who needs imagination when we can now recreate entire worlds in exacting detail on modern machines... It's a damn shame if you ask me :(

  4. Posted

    Exactly. I think Mr. Gates himself said "software *makes* hardware", and even if you don't like Micro$oft, you can't argue with their success. Hardware is a much bigger deal for us to do now since it is hard to justify. You are forced to ask "if I make this, is there any software that will use it, or will anyone write software to take advantage of it?" But if the hardware does not exist, then no one will code for it. Kind of the chicken and egg problem. But with emulation we can provide the hardware, and if people start to take advantage of it, then some of us might make the real hardware. :-)

    Tell me about it. I just built a brand new PC for my son so he can play Crysis 2, because his two year old laptop can't cut it anymore :x . This time around, I put in the best components I could lay my hands on (top shelf Alienware performance at half the cost. Thanks Newegg.com!), so maybe it will last him 3 years. Maybe...

  6. Posted

    Where's the damn rope!

    But seriously, I have to agree with you (reluctantly). I think our inclination to code for the lowest common denominator may be limiting the kind of projects we could do with the TI. I think the SAMS card is woefully underutilized, and so is the P-Code card, simply because not a lot of TIers have the needed hardware.

    I like using real hardware for nostalgic reasons, even though practically speaking emulation is far better from an efficiency standpoint. I will definitely obtain an 8K cart somehow (buy one or build one) just so I can play Adam's game on the real thing, and I think I will not be alone in this. Maybe the old adage will hold true: if you code it, they will build the needed hardware :)

     

    I'm probably going to be lynched for saying this, but...

     

    I would not worry about what people have or don't have. I'm going to go out on a limb and say the majority of people who will actually play the game will do so under emulation. Those who are going to play it on real hardware will have a means to run it too. I don't know why everyone is so worried about the handful of people out there who might expect to try this on an unexpanded console with only with a cassette deck. If everyone only writes programs for the lowest common denominator, we may as well all throw out our PEBs, hard drives, expansion systems, etc. and start working with dual cassette decks only.

     

    Realistically, your target "market" is about 50 people max in the world, and half of those are probably on A.A., the other half are randomly bumping around in the ether.

  10. Posted

    Quick update:

     

    I have the AI broad lines on paper but have decided to delay implementation until the combat mechanics are finalized. I'm currently in the process of setting up the combat resolution tables, satellite and production centers attacks, and meteorites auto-motion. Completed the targeting implementation where now a unit can target an enemy unit at a distance depending on its firing range. Also, when you select a unit that has already been committed to combat, the target hex will be highlighted. This is very useful when you have a lot of attacking units and you forget what each is targeting.

     

    I should (hopefully) have another updated download and pictures with all this stuff finalized within the next couple of weeks.

  12. Posted

    I see that there are some great resources for Atari books and magazines here and elsewhere. I can find nearly every book or magazine ever produced for Atari computers. What about the TI? My big interest now is 99er, 99er Home Computer, and Home Computer magazines. I have all but the first 5 of 99er and would like to get all of them. Let me know if you have them available.

     

    What about e-resources? I've found the whtech web site that has some very poor quality and only partial scans of the 99ers. Are there any other, better, scans? Same question for TI-based books.

     

    -Kirk

    Check out the pinned programming resources topic.

  14. Posted

    Classic99 v351

     

    -Added SRAM to MPD

    -Fix FIAD disk paths to always end with backslash

    -Make MPD repair broken configuration bytes

    -Fix lockup problem after browsing a disk folder

    -Added TurboForth

    -Numerous tweaks to P-Code card, still doesn't work. I don't think I have disk images for this!

    -Updated long filename support - open as IV0 to get long filenames

     

    http://harmlesslion.com/software/classic99

     

    TF was the main reason for the release. :) But I also wanted to tweak the long filename support before anyone tried the old system. ;)

    Ahhh.... There is actually some life to the P-Code project in Classic 99. Excellent! :)

    By the way, where can I find documentation for Turbo Forth? I have a couple of Forth books, but I'd like some kind of user manual specific to TF itself...

  15. Posted

     

    The routine basically reads the characters under the sprite, extracts their pattern data and parses it down to needed bits to create a pattern that is a match to the 16 x 16 grid under the sprite. It then defines the sprite as such. Not complete as detection in itself but......

     

    If this sprite were made transparent and a game play sprite was laid on top of it then normal sprite/sprite collision detection can be used as sprite/background collision detection.

     

    The routine is currently set up for graphics 1 mode and a 16 x 16 sprite. It would have to be modified for bit map mode so you would most likely need two different routines. It "should" work for regular sized sprites through double size but not double sized and magnified.

     

    The VDP RAM set-up is hard coded but making that relative shouldn't be too tough a task.

     

    At any rate I'll send you Source this evening and post it here when it is fully pared down.

     

    Marc

     

    Marc, I suspect collision detection will deteriorate proportionately to sprite velocity given all the background work that is happening, more so than with usual sprite to sprite detection, unless you predefine sprites for selected areas on the screen that you want to detect collision against. Am I understanding this correctly?

    I also assume that this is useful only for mobile tiles, because otherwise you could simply check the (X,Y) position of the sprite against a fixed table of tile coordinates with appropriate range checking, i.e. if sprite is within X and Y of the uppper left corner of a tile, then detection occurs. If Sprite is X,Y and tile is x,y, then the sign of X-x and Y-y should tell you which quadrant you are in to further refine the detection.

    Am I completely off here?

  16. Posted

    We're on the way. I'm hoping that Monday will be a big day. I have to do some "work for pay" but should be ready for TurboForth by mid-afternoon.

     

    My Eprom came in the mail today and I am now the proud owner of a Turbo Forth cart! Now if I can get my hands on that mystical TF book. Hmmm....

  17. Posted

    I have been attempting to attach a .dsk image to a message but keep getting the error saying "I can't upload that kind of file". I have tried it plain and zipped. Anyone tell me what I am doing wrong ?

    You should not have a problem with any kind of file as long as it is zipped, at least in my experience... I assume the file has the .zip extension, right?

  18. Posted

    I think you need some GRAM of some sort: A gramkracker, a HSGPL or something like that. I'd like to see a plug-in cart with 512K GRAM and say 32 or 64K of paged flash. :lust:

    So basically any GPL programs I produce in the future will have to be emulator only... Bummer.

  19. Posted

    OK I have a really dumb question, but please bear in mind that my architectural knowledge of the TI hardware is pretty basic:

    I figured out how to make REA work under Classic 99. Now, what is needed to get it working on a real TI? I assume a cart will have to be made with an REA Eprom, but are there any other hardware requirements?

  22. Posted

    Using a mask and re-randomizing if unwanted nubers are returned will provide well distributed numbers. I'd start with that and change it out only if performance becomes an issue.

    Unfortunately I will then still have to do comparision instructions...

     

    BTW, I had no idea you could display pictures on a VCS machine! Looks like a great program, especially on that limited platform. I recently programmed a full casino blackjack program for 5 players (4 computer controlled) for the TRS80 Model IV in Turbo Pascal, and it was a b*** to design, so I am impressed at what people can still pull off with the VCS...

  23. Posted

     

    There should be no need to copy code from one file to another at all. Sounds like you're doing something wrong there.

     

    However, the best approach is classic99 with asm994a and multi file projects. I can do a video to show how to do it if that would help.

     

    Mark

    Copying code between files is sometimes necessary when I add code to a large file which makes it too big to fit in the editor buffer, and so I have to transfer some code to another file to make some room in the original file. It is a cumbersome process at best.

    I have already shifted the development of Ultimate Planet to Classic 99/asm994a/Kate running under Ubuntu Linux :) However, I am in the process of upgrading my console with 32K on 16bit bus and a faster crystal, and so my next project will likely be again done on real hardware :D

  24. Posted

     

    The bias I only learned about recently, when a friend of mine started an encryption job, and it was one of his interview questions. The reason makes total sense, but I'd never thought about it before.

     

    For sake of simplicity (and human understanding rather than code), let's say the random number generator gives you a perfectly random number from 0-9. But as in your case, you want a number from 0-5.

     

    If you use modulo, certain numbers are now more likely to come up than others. You would do val%6, and get this result table:

     

    0 % 6 = 0

    1 % 6 = 1

    2 % 6 = 2

    3 % 6 = 3

    4 % 6 = 4

    5 % 6 = 5

    6 % 6 = 0

    7 % 6 = 1

    8 % 6 = 2

    9 % 6 = 3

     

    Note that this sequence makes the numbers 0-3 more likely to come up than the numbers 4-5, because there are two sets of them in the output range! The easiest solution is to use the random number as a percentage or fraction, instead of masking. So instead of saying x % 6, you would use x * 6 / 10. Unfortunately, for a small range like this, the end result is the same, two numbers still come up short! But the concept apparently balances out better with larger ranges. ;)

     

    But if you can use the masking, it's generally better for speed if you can adapt your algorithm to use all the results than to compare and skip. If you can't, might as well just DIV! :)

    Fascinating... As you said, it's simple, but one would have to look at it in detail to notice. Thanks for the explanation. I'm afraid I'm going to have to stick with DIV though because Ultimate Planet is based on a classic table top 1980 wargame, and all the combat resolution tables use a 6-sided dice. I worry that I may unbalance the game if I expand the tables arbitrarily... Here are a few screen shots of the original game for the curious:

    http://laurent36.typepad.com/.a/6a013486df16fc970c0133f3bd044c970b-pi

    http://laurent36.typepad.com/.a/6a013486df16fc970c0133f3bd0471970b-pi

    http://laurent36.typepad.com/.a/6a013486df16fc970c0133f3bd0492970b-pi

  25. Posted

    What I still don't understand from you is what do you do when a certain file refers to a subroutine in another file? How do you get it to compile independently in this situation?

     

    That's what REF and DEF are for.

     

    DEF defines a label in a file which makes that label globally available to any other file. The label can be anything - a memory address, a function, a table, it's just an address.

     

    REF tells the assembler that this file needs to look for the specified label in that global space.

     

    REFs are not resolved by the assembler, they use a special syntax to link. The E/A#3 loader handles resolving all the addresses and patching in the correct values when the files are loaded.

     

    That's why, to use the E/A utilities, you can just "REF VSBW" without knowing where in memory VSBW is. The cart pre-loads the global REF/DEF table with its own utilities.

    You know, I figured that one out shortly after typing in my message :ponder: Sorry about my little brain fart here...

    Another issue I have is when I need to hunt and fix bugs that span more than one file, which is a frequent occurrence with large programs, as this usually means opening a file, editing it, saving it, closing it, opening another file and repeat... And I'm not even mentioning the awkwardness of copying code from one file to another and the risk of running out of space in the target file... I guess this part of the charm (?) of retrocomputing, but sometimes a little less charm and a little more efficiency is helpful :D

     

    This one is a little harder. Ideally individual files are kept small enough to reduce the issue of running out of space, but you still have the loading issues. Large projects may be easier handled on the PC, where you can use an IDE to keep all the files open at once.

     

    Incidentally, you can also do a "poor-man's" batching in Classic99 to load all the files. The "paste" function just sends keystrokes, so if you need to load, say, four E/A#3 files and run them, you can type the following into a notepad window:

     

    123DSK1.FILE1
DSK1.FILE2
DSK1.FILE3

START

     

    Then when you want to launch, reset Classic99 (FCTN-= or File->Reset). Switch to the notepad, Control-A to select all, Control-C to copy. Switch back to Classic99, select Edit->Paste, and your program will be loaded (in Overdrive!) then start normally. (Naturally, use your actual filenames and start program name).

     

    The '1' clears the master title page.

    The '2' selects Editor/Assembler

    The '3' selects Load and Run

    Then the filenames are typed with an enter at the end of each.

    The blank line sends just an enter to get the PROGRAM NAME prompt.

    And the program name is typed with an enter at the end. If you'd rather it wait for you, end the file without the "enter" after 'START'.

    Very cool.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...