Vorticon
-
Content Count
4,690 -
Joined
-
Last visited
-
Days Won
2
Posts posted by Vorticon
-
-
Clearly my best cart game in my families collection.
I absolutely second that
-
Go for it! Who knows, there may be a lot of TIers willing to learn assembly but are intimidated by the EA manual (who wouldn't) or other books. You will probably need to broadcast at least weekly though in order to enhance retention of the material, until you have a good number of shows available.
-
Wow! That is brilliant! I really like the end of the TI one!
Trouble is, I am torn... I mean, I really love the TI, and I really love the old rubber keyed ZX Spectrum! I owe my career to both of these computers... Oh the hours I spent locked in my bedroom typing in magazine listings and playing games!
Thanks for posting this!
:thumbsup: :thumbsup: When I see in Retrogamer Magazine the number and quality of games made for the Speccy, I always lament the terrible blunder TI made by shutting out third party developers. Clearly from the games programmed in recent years as well as the projects in progress, the TI was every bit as good as the Speccy, and in many ways much better. About 5 years ago, I bought a Spectrum +2 (it has a proper keyboard, a cassette deck, 128K RAM and an RGB port) on Ebay as well as a whole stash of games on cassettes and got it to work using an RGB monitor and a power converter. However, the loading process of the programs was excruciatingly slow, and the colors were just awful, although the games were for the most part good. I just could not get hooked on it, so I sold it all back a few months later (sorry Willsy, had I known you back then I would have offered it to you!).
Unlike many on Ebay, I don't like to collect classic computers unless I actually use them...
-
1
-
-
There is a map of how the VDP memory is used by the floppy controller here:
http://nouspikel.gro...ti99/vdpram.htm
There's no point using Classic99 to examine the VDP memory after a disk access, as it doesn't use a "TI" disk controller, and thus doesn't use VDP memory. I used TI994W and I saw some stuff in VDP memory but that also didn't make much sense. You'll probably have to use to a real TI to see whats in the VDP. VDP address >3EEB (number of drive last accessed) looks useful, and also >37DB (CRU base of the controller card). I'm assuming that AFTER a disk access, one could look at >37DB to get the CRU address of the card. You then map DSR at that CRU address in (you'll need a bit of assembly code for that) and from there you can walk the DSR header and extract the device name (DSK, RD, HDS etc). You can then combine the value at >3EEB to make a full device name, i.e DSK1 RD3 etc and append the filename that you want to access. So you end up accessing the file that you want to access, on the device that was last accessed.
More investigation will be required on real hardware though to ensure my theory is valid - and even if it is, looking at how the emulators use the VDP (which doesn't seem to adhere to the documented behaviour on Theirry's site) there is a good chance this technique won't work on emulators.
I did not think about compatibility with emulators... In this day and age, one can no longer ignore this. Maybe I'll just ask the user to simply input their disk path at the start of the program. It's not seamless or elegant, but at least it will guarantee compatibility with anything outthere.
-
Turboforth v1.1 already does sams
although you might not need it at all - Turboforth gives you just over 31k of free RAM on a 32k TI.Take a look at bcd to encode your values in hex strings in xb - one *nybble* per digit. Very simple to encode and extract...
I will. Thanks
But first I need to finish the debugging. Everytime I play the game, something unexpected comes up because it's such a complex simulation and testing every possible situation is difficult. I will declare the game fully debugged (well sort of) when I can play 5 games in a row without any issues. Not there yet, but close 
-
Ah excellent! Thanks guys
I am not familiar with the XB environment from an assembly standpoint, but I understand the gist of this routine. I will need to look up these addresses though. -
Hi. How does one achieve boot tracking from within XB?
-
Well, shot that one all to shyte. Better save this thread for the benefit of others who tread in our foot steps
Nothing like trying to push the envelope
I am set on learning Forth this year, and apparently Wilsy is working on providing direct SAMS access from within it, so I just might convert that program to TurboForth as a learning exercise. The TRS80 version is in 80col but with only ASCII graphics and text, monochrome of course, and with Matt's 9918 replacement project, I will be able to use 80cols too!
-
Well, I spent the entire evening reworking the program, and I managed to store over half of the variables inside character definitions. The single integer ones were stored as is, whereas the 2 and some of the 3 integer ones were first converted to hex format. The rest of the variables were stored on disk. The verdict? The additional code needed for these modifications ended up forcing me to break up the project into 4 instead of 3 sections, adding more delays, and in the end a single turn was taking about 4 minutes instead of the original 2
The encoding and decoding process for so many variables is probably just as slow, if not slower, than disk access.So that's a bust. I don't think XB is well suited for recursive chaining of programs as compared to linear chaining, and I may have to just live with the loading delays...
I suppose I could try to explore the possibility of embedding some assembly routines to store variables in the VDP, but I think I'll focus on finishing the program and documentation first and see how much energy I have left.
-
The hard part is XB has no HEX conversion built in. But I found these DEF somewhere a long time ago, they convert 1 byte numbers so 0-255, 0-FF
10 HEX$="0123456789ABCDEF"
20 DEF HEX2DEC(X$)=(POS(HEX$,SEG$(X$,1,1),1)-1)*16+POS(HEX$,SEG$(X$,2,1),1)-1
30 DEF DEC2HEX$(X)=SEG$(HEX$,INT(X/16)+1,1)&SEG$(HEX$,X-INT(X/16)*16+1,1)
40 PRINT HEX2DEC("FE")
50 PRINT DEC2HEX$(256)
I'm going to keep that in my files for future use!
-
Given that the majority of my variables are either 1 or 3 digit integers, the latter frequently greater than 255, it's just simpler to encode them as is. For floating point variables, I will multiply them by 100 and encode them as 3 digit integers. There is a loss of precision as a result, but for the purposes of this game it should not make a huge difference. For strings, I guess just encoding the ASCII value of each character is the way to go. There is no significant benefit in doing Hex conversions under these circumstances.
Now the problem lies in finding enough free characters to use for storage... Worst case scenario is that I'll encode as much as I can in char defs, and the leftovers will go into a disk file. I should still see that way a significant improvement in loading time.
I'll keep you posted as I test this out.
-
How would one encode string data within a character definition given that only letters A to F are valid? I suppose I could convert each character in a particular string to its individual ASCII code and encode it that way, but is there something more efficient available?
-
couldn't you save the varibles as one long string which would be only one record then. sure the program would have to break it out but that would be alot faster then disk access. I try to do as much as possible with strings cause they are the fastest way in basic and the lowest memory usage.
Yup, that's one option I'm exploring
-
I seem to remember passing variables between chained programs by coding them as a character definition in one program and then disassembling the code in the receiving program. I do not remember much details but I do remember that I was not passing many variables and although I had 3 or 4 programs in the chain, only one was very active. The principle being that characters 96 to 143 hold their definition between program runs.
I did not know that. This would be problematic for non-integer variables though but not impossible. I have somewhere around 30 different variables to track for each ship, for a total of around 60, a mix of integers, decimals and characters. I'll have to give it some thought to see if I have enough free characters for storage and devise an encoding scheme. Thanks for the tip!
-
Similar game from SSI and a complex looking manual - http://www.atarimani...dsides_796.html
Interesting! The description seems almost similar to Clear for Action, and since it came out a year earlier, I wonder if it was not the inspiration for it. I should look up that game on Ebay. The screen shots look incredibly detailed as it seems like the Hires mode was used. This level of screen detail could probably be achieved in bitmap mode on the TI under assembly, but it would magnitudes more of time to program.
-
The demo for this at the Faire was pretty neat, even with the one BSOD
Is the video posted, yet?As for speed, how about recoding in TurboForth? I assume compiling it would not speed up as the wait time is loading. What exactly is it loading? Maybe some way to pre-load program or data into expansion RAM?
The actual execution speed is fine for XB. The problem lies with loading the chained programs and the data form disk. As you know, large XB programs take a noticeable time to load when run, and this game goes back and forth between two main large programs. In order to preserve the large number of variables needed for this rather complex simulation, I'm using a data file that is updated prior to calling another program, and read by the called program. Apparently XB allows only one variable or data item per file record, and so the disk is accessed for each variable, creating a significant slowdown in loading. Using Forth or another language is probably not the answer.
On the other hand, I do like the idea of loading the variables in RAM rather than disk outside of the XB space, but I don't know if that is possible or even where I would find a protected space. Obviously assembly will be needed for saving and loading of the variables, and I can do that if somebody here can give me some guidance... How about using the SAMS card? Can it be accessed from within the XB environment? Clearly RAM will be much faster than disk access...
-
Nice I remember a print out version of this using print outs.
There is a board wargame called Close Action that is quite similar and has a big following currently. Steep learning curve.
-
This is an overview of my upcoming XB game called Clear for Action, which is a naval combat simulation in the age of sail. Given that my Ultimate Planet project was still lagging, I had decided about 3 weeks prior to the Chicago Faire to quickly develop a program I could demo at the Faire, and XB was the fastest way to do it. And so it happens that I had recently bought an Avalon Hill game of the same name on Ebay for my TRS80 Model IV which came on tape and was also programmed in Basic (Also available for the Atari 400/800), and it was a blast to play.
Even better, the simulation was extremely detailed, and the game came with 2 manuals that practically laid out most of the guts of the game it terms of mechanics, formulas and tables (but unfortunately not all, most notably the AI algorithm). I my infinite wisdom, I figured I could do it in the 3 weeks available to me, and in some fashion I did have a workable, albeit very buggy, version just in time for the Faire, with over 760 lines of code so far... A minor miracle. Clearly the program would not fit in one piece, and so I had to break it up into 3 separate programs chained to each other, exchanging variables via a common data file. I have nearly completed all the debugging, and am working at optimizing the AI a bit more, although at it stands it will shred you to pieces if you are too cavalier (see below), but there is still a lot of improvement to be made if it is to provide a decent challenge to a strategically astute player.
My main problem now is that it simply takes too long to load each chained program when it is called, even though the execution speed itself is quite acceptable for XB. As a result, a single turn from ship movement to combat to status display will take about 2 min and 14 seconds, most of it spent waiting for the programs to load. You might as well be playing chess... Do you guys have any suggestions for improvement here? I am aware of prescanning, but my early experimentation has not resulted in huge improvements because most of the loading time is taken by the data file which contains a large number of variables, each occupying a single file record thanks to the designers of XB...
When I play the game in Classic 99 with CPU overdrive on my high end Alienware desktop, the delay is only a few seconds, but for the average computer, the delay was still quite substantial as the owners of laptops at the Faire figured out as I harassed every one of them to try to run my game prior to the demo
In the mean time, here are some snapshots of a game I played this morning:
There are 8 built-in historical scenarios, but you can also create your own.
You can set the sails and then the ship direction, taking into account the wind, sailing speed, and points of sail.
If you get too close, you may grapple to enemy ship. There is also a chance your sails will become fouled.
Fire away! You control your guns' loadout which in turn affects the ballistics and the range of the guns. Reloading is not instantaneous either and is affected by the number of gun crews, gun damage factor, and type of load.
If your ship is grappled or fouled, you may attempt to board. This can be devastating to either ship in terms of crew casualties...
I'm in real trouble here, with all of my port guns destroyed and a third of my masts and sails gone!
My computer opponent on the other hand is fairing much better...
And it just handed me my ass
-
regarding the hybrid: gerhard w. from our austrian ti group brought one of these boards to our ti meeting:
http://ti99blog.webs...otoid=124346176
as you can see, tom seems to love it
Now that's love! The scary part is that I can relate!!!
-
My favourite card is like a hybrid TI-99 and TI-59: the TM-990/189 http://www.vintageco...i/TI-TM990-189/
Nice. I did not know this existed...
-
I have a complete in box Science Fair one. I messed with it for a little bit, was pretty cool, maybe I'll have time to get into it again one day. Was lucky enough to pick mine up for $5 at a garage sale.
I'd say that's a good price
I always get a kick out of pushing these little machines to their limit, and there are some cool things being done with them on YouTube. With that trainer, all the connections are very easily accessible, so interfacing should be easy enough. The only problem is that you have to type in your program all over again after you shut off the machine... Maybe I should design a cassette interface for it he he... -
Heh. I think I'm getting my "build your own computer" fix via HDL these days. :-) It is not so much having a 4-bit CPU trainer, but more the idea of having an old TI-trainer. There has to be the nostalgia and authenticity to it, otherwise it is not quite the same.
I'm definitely with you there.
-
oh oh, me me !! I want one! :-)
Well Matt, it's your lucky day.
I was browsing Ebay for classic computer kits and came across this item: eBay Auction -- Item Number: 190592146479
, the Gakken GMC-4 4 bit computer trainer from a Japanese company. It really looked very interesting, so I downloaded the PDF English manual, and it all looked really familiar... Then it hit me: this computer is a complete rip-off of the Science Faire Microcomputer Trainer I mentioned above featuring the TMS1000 CPU! It has the same op codes, callable subroutines, memory addresses and architecture, and even the programming examples are straight out of the Science Faire manual... I don't recognize the chip which seems to be an SMD square about maybe 1/3" per side, and there is no mention anywhere about the manufacturer or the specs.
Who knows, maybe this company has a licensing agreement with TI to clone the TMS1000, but then maybe not. At $32.80 plus another $22.80 shipping to the US, it's not exactly a bargain for what you get in terms of capabilities, especially when you can get an ELF or a KIM replica in kit form for under a $100... Nonetheless, it is interesting, and definitely less bulky than the Science Faire trainer, ideal for a long plane or train ride
So if you still want one, here you go!
-
TIdBit might help you some. Although the end result is still BASIC or XB code, you get structure without sacrificing GOTO (is that a good thing?
)Not really, as the problem is with the unavoidable use of GOTO... I would just kill for a CASE statement, a WHILE DO loop and RECORDS just to name a few. I finished the rough coding at 2am this morning, but as expected the program is still full of bugs. But much more problematic is the fact that it uses 3 large chained XB programs that loop back to each other, and the loooog pauses that happen when one section is loading turn the game into an exercise in frustration. The only way to mitigate this at the current stage is to run the game under Classic 99 emulation in overdrive mode. I may be able to improve the situation a little by prescanning, by how much remains to be seen. I will be off to Chicago in about an hour, and will try to debug the program at the hotel tonight.
See you there
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Clear for Action
in TI-99/4A Development
Posted
Well, it appears that the RUN command will not accept a variable for a disk path and filename, so that makes manual boot tracking impossible. Therefore, the program will now only run from DSK1...
On the bright side, Clear for Action is now complete and for the most part debugged. It still has very slow loading times on the real thing, but is very playable under Classic 99 in overdrive mode. It ended up being comprised of 4 different program units...
I will write up the manual over the next few days then upload the game here for you guys to test out before I release it to the TI community at large.