Tursi

I have not tried this for about 5 years, but about 5 years ago I found that my cell phone, which had free calling within Canada and the US, would function as a modem if I tethered it to my PC over serial. I actually called BBSs and even an internet dial-up with it. Might be worth investigating whether any modern cell phones are capable, since many plans offer discounted or free long distance nowadays.

Hehe, I like that idea, Marc. Owen, I should be able to Skype you in if I remember to bring my cellular internet adapter... do you have a way to reach us? I'm (predictably) Tursilion.

It was not the baud rate that was the problem on TIBBS, Extended BASIC is just very slow, and the way it is written, there's no way to interleave the even slower disk access with the modem access. The effect is that, in many cases, the disk spins down between lines of text, which makes it even worse. With a RAMDisk this effect is minimized, but you still have the slow XB file interface, and it's still pretty noticable. All that said, of course, you could probably set up a survey for the modems on TI question. I don't on mine, unfortunately. I thought many times of ressurecting FlipSide and running it through the emulator over the internet. But... didn't seem like it'd see enough traffic to be worth it.

TIBBS was the name of the popular Extended BASIC BBS package, IIRC. It ran on a lot of boards because it was easy to run and maintain, and very reliable software. It used assembly for the modem interface, though I don't know how much else may have been assembly. However, personally, I did not like calling BBSs that ran it, because they were very slow, loading each line of bulletins and the like from disk caused a noticable delay, even at 1200 baud, and my phone bills were already very high. RAMdisks helped but what would have helped more would be the whole text file dump routine being in assembly. My own BBS package, FlipSide, was written in c99, and the source code that I have is available for download here: http://www.harmlesslion.com/software/bbs (also on WHTech in communications/bbs/FlipTermBBS.zip)... speed was no problem here at all, even from floppy, but the software was not customizable at all, and took a long time to compile. Still, it was fun to run.

Cavern Quest was not too bad. I always used to like MoonBeam's stuff, though this was the only one I actually played as opposed to just seeing pics of.

This is pretty fantastic, Matthew! Amazing work!

Ooh, thanks for that link, Sometimes! Adamantyr - those old floppy drives had more go than you give them credit for! When I was running my BBS, the compilation of the c99 code, then the assembly code, for all the modules, took about 20 hours (assuming I stayed up the whole time to babysit the process), but I never had a drive give me any trouble. (Of course, by that time I didn't recompile the whole thing very often anymore, I only had to do the whole thing when a core function changed...) You learn tricks to debug without a debugger - I was actually suspicious of debuggers for a really long time when I finally did move to the PC, it wasn't till I started working with Visual Studio that I finally embraced them.

That Scott Adams story is pretty cool, save2600, I didn't know anyone did that! Regarding your book: That would be "BASIC Computer Games" by Creative Computing, unless I miss my guess, the prequel to the one I had (which was red). I'll put a Coke on it and give you a cover pic to jog your memory: I tracked down both books a couple of years ago, there were still enough copies floating around that it was easy to do.

We got the TI in 83 or 84, close to the end, anyway, and had just the console and cassette recorder. We didn't even have any cartridges. We did, however, have several books, including "Kids and the TI-99/4A", "Games for the TI-99/4A", and Creative Computing's "More BASIC Games". We all started by typing in programs to learn the machine. My cousin and I started with "Alligator Alley", a simple game that gave you a solid green screen and let you move from the center towards the edges. Alligators were scattered randomly, and you couldn't see them, but you had to avoid them. Not much of a game, but we saw what it was doing. We also changed the text to amusing statements like "Oh no! You got eaten! Now the poor alligator has indigestion!" Even my parents were working on it, taking the time to try and port some of the games from the BASIC Games book to TI BASIC. They successfully managed to port Keno and modify it to play Lotto 6/49 (the Canadian national lottery), noting the changes in the book. Ultimately I was the only one who really stayed with it, though my brother and I collaborated often on TI BASIC games. Sadly I lost all my old tapes in one big move, so I don't have a lot of that very old code. I finally got the Speech Synthesizer in '87 or so, $10 at a pawn shop. But I couldn't USE it for another six months till I saved up enough to buy Extended BASIC from the local TI User Group. About a year later I finally managed to get a PEB and disk system -- and it was quite a wonder for me setting that up and getting it working, not to mention copying my cassettes over! I managed to get a MiniMem cart and started learning assembly on that. I did two games in pure assembly - versions of Centipede (called Centiped) and Berzerk (called Berzark). I don't know if I ever uploaded them anywhere, though. I got my first modem in '89 - a 300 baud Tandy acoustic coupler, which I used with Terminal Emulator 2, and shortly thereafter I started writing a BBS in Extended BASIC, first using OPEN/INPUT/etc, and later using assembly for the RS232 interface. That necessitated a modem upgrade, and I got a 1200 baud modem for it. I wrote and ported silly little XB games for it, replacing all the PRINTs and INPUTs with CALL LINKs. Since disk was so limited, I had feedback go directly to my printer -- which until I got the RS232 card had run through the Minimemory and the joystick port using the Joytalk is Cheap project from 99er. Unfortunately, my friends realized that printing lines of hash symbols and asterisks made enough noise to wake me up, and thought this was hilarious, so the printer was turned off at night. My collection accelerated then, after all, most people were moving on, and over the next two years I added a RAMdisk, and even extra systems after moving to Ottawa. At that time I started writing a new terminal program intended to use the 80-column routines I had experimented with years later (sound familiar? ) However, after I got the I/O code working to my liking I turned it into a BBS system instead of a terminal, and never added the 80-column mode. (I met Jeff Brown through the TI User Group in Ottawa, and after showing him my proof of concept for 80 columns -- that is, that in bitmap mode 3 pixel wide characters which touch each other are still readable! -- he borrowed the idea with my blessings and produced a rather amazing terminal package called Term80.) I produced a game called Super Space Acer that I was proud of, intending to start pushing myself and the machine with this intended first major game. Mediaware down in Florida picked it up and sold it at a faire or two for me, but I never saw the final product. He said a dozen or so sold -- if anyone actually has a copy still with the color label he made for it, I'll pay double what you bought it for. The last major thing I did in that long, continuous period of being a TI User, was from 1994 to 1995 when I was editor of the Ottawa TI User Group Newsletter, putting out the final issues of the user group before it was closed down. This was the period when Classic99 was started -- then Ami99 as it ran on the Amiga. But after Ottawa I put the TI away for a while, only to come back later and cause all kinds of new drama on the TI OLUG, but that's a different story.

Pasting is working okay from IE8 from codeboxes, at least for me. It could be a line ending issue, especially since you get the same effect in Notepad. For a lighter weight solution than full Word, try WordPad (it's on all Windows systems). I use it when I am doing a copy and paste with line endings that Notepad doesn't like. If you paste into it, then copy and paste out, it usually gets the line endings correct for Windows.

Beautiful, thank you for the starting points. I expect I will get to play with this tommorrow and will see if I can get my copy generating functional code.

Unfortunately I needed a compiler this week (the TI Faire is in just 10 days!!) Do keep up your work but unfortunately I won't be able to help as much as I expected to, at least not right now. So the pressure is off for now! (I might still be able to use it to save myself some time if I can find the prologue bug. Been about a year since I dug into GCC so I have to remember how to find that code - I will take a peek this week). If you can show me where to fix the +4 comma bug, that would really help me too.

I had some difficulty building this... but then it's GCC so I'm not too surprised. I got the specified versions of GCC (using GCC-Core) and Binutils, and built under Cygwin. Your patches applied cleanly and only a couple of steps broke. For one, I had to manually "make elf32-header.h" -- I'm not sure why but that got me through binutils/bfd. The rest of the build seemed okay, but libiberty gave me all kinds of issues on the make install for GCC I should note that I couldn't make your steps work.. I fell back on a really old instruction set that I've used for years at Hitmen's page (it was meant for doing an SH4-cross, I just made the changes to tms9900 and didn't hack the GCC makefile). On the plus side, you seem to have done really well! All the tools built, which is worlds farther than my attempt got. I created this test program: int main() { volatile int y=10; return y+15; } This got a syntax error from the assembler: Test.s looks like this (and it is missing the , on line 13): pseg def main main ai r10, >FFFC mov r11, @2(r10) mov r10, r8 li r1, >A mov r1, @2(r8) mov @2(r8), r1 ai r1, >F mov *r10, r11 c *r10+ *r10+ b *r11 Unless I'm reading this wrong, I think there's a bug in the output code. It looks like the return address and the y variable are both stored at the same address on the stack. (Note that because I declared the variable as volatile, the optimizer is not allowed to simplify access to it, this way all the code is output ). Assume on entry that R10 (stack pointer) is >3FFE: main ai r10, >FFFC -> R10-4 = >3FFA mov r11, @2(r10) -> Return address to >3FFA+2 = >3FFC mov r10, r8 -> Save stack pointer in R8 (frame pointer) = >3FFA li r1, >A -> R1 (temp) = 10 mov r1, @2(r8) -> Save R1 at R8+2 = >3FFA+2 = >3FFC (same as return address) mov @2(r8), r1 -> Get value at R8+2 = >3FFA+2 = >3FFC, value is 10 (not bug! Variable is volatile) ai r1, >F -> Add 15 to the value, result is 25 mov *r10, r11 -> Get value at R10 into R11, R10 = >3FFA - not same address as return was written to! c *r10+ *r10+ -> Add 4 to R10 (reset stack pointer) - syntax error due to no comma but code is correct b *r11 -> Return to caller I made a second version with a subroutine to see if it was a bug pertaining to main() only (just in case), but identical code is generated. I did a quick search to see if I could see where either code was generated. Now, it IS late and maybe I'm reading it wrong... When I correct the syntax error, the assembler runs, but because of the issues with libiberty I don't have a libgcc so it can't link. Anyway, just wanted to report my results and see if you had any new patches available, since it's been a while! Regarding your comments above, about coding the 9900 for speed or size, one thing to remember about the TI-99/4A is that the system is intensely memory-bound, due to the 8-bit multiplexer. As a result, smaller code tends to be faster than even very clever larger code almost every time just for the instruction fetch overhead, with the sole exception being code running in scratchpad RAM where there are no waitstates, and my experience is that 9 times out of 10 smaller code is faster there, too.

I just wanted to note that the information attributed to me above isn't cut-and-dried. I don't know what the speech synth does on the bus or why the E/A manual says you can't touch the 8-bit bus during certain operations.. in the attributed conversation I was just confirming that the cartridge port IS the 8-bit bus since it sits on the back-end of the multiplexer. It's nice to have someone else working on the timing counts, hehe.

I'll be there Friday night, my flight gets in at 6pm, so an hour or two more and I oughta be in the neighborhood by 8pm. I'm at the Best Western too, so I'll come wander around.

I liked Picnic Paranoia, used to play it a lot. If we're just talking official cartridges... I'd probably go with Zero Zap too - wasn't much of a game there, I think.

I was only being dumb.. it's free so I'll implement it anyway. In truth I have my plan mapped out, but it's going to be hard to get both this and the project I want to show ready for the faire. As for emulation, my GROM side of it I can easily add to Classic99, not sure if I would be adding the programmable flash side. Maybe.. I hadn't thought about it. Classic99's configuration is starting to get complex again.. I might need to fix that. (We'll have documentation for others too, of course!)

8192 bytes is 8k, not 2k. Yes, thank you to everyone who pointed that out.

For those curious, the file in question was a valid beta, and Stone allowed me full diagnosis of it. The issue was pretty simple - it has a fake header on it of /almost/ all $FF bytes. JCP did not recognize it as fake because of the "almost" case, and uploaded it to the Jag. This caused all the code to be misaligned, and the Jaguar crashed badly. I suppose I should write a small article for people describing how to figure out how to run files, but it's not magic. If you have files from an unknown source, you need to figure out how it's meant to be loaded. In this case, all that was needed was to skip the fake header: jcp -f -h 8192 FILE.ROM The giveaway this time was the file size - it was exactly 4MB (4,194,304 bytes), but JCP reports "Headerless ROM: Skip 0 bytes". The filesize should be 2k (8192 bytes) less than exactly 2MB or 4MB if the ROM is headerless, so if you see that combination, you can try the -h 8192 part to see if it works. No harm in trying, anyway, worst it will do is crash again. I will also improve JCP's fake header detection with this case in mind. But the fact is that you do need to use a little bit of knowledge and skill to load unknown files on the system. The fake header is no problem for the Alpine, of course, but in that case you tell the Alpine where it loads. JCP needs to guess. Please do not reply to this post - I don't want to reawaken the thread that we calmed down, just save the data off for later use. I just felt that it was so public I owed the results, too.

Okay, guys.... please stop the discussion of piracy or not in this thread. All the points are made, and most of them are the same points that have been made on both sides for the last 20+ years. Skunkboard is the way it is because that is the path I chose to follow, and I do not intend to change that path for this release. Stone contacted me and we have a path to follow to see if we can get his beta to work. The big scary blacklist is a tiny thing with very little on it. It uses very, very specific tests and the odds of accidental collision are tiny, but in any hashing system collision is /possible/. Since we don't sell this as a device for running betas, complaining that one beta out of hundreds doesn't work isn't productive. Since we agree to help with them ANYWAY, it's borderline behaviour at best. I think that this, too, is now well established and needs no more embellishment. If you have points that must be addressed still, then please start another thread, since this one is about the Skunkboard release and not about the morality of the community.

Anyone who has been in the Jaguar community for a long time knows that it has a tendancy to be volatile. When I decided to commercialize the Skunkboard I decided to take steps to minimize the flamewars that releasing the device would inevitably cause - I did this by talking to the devs, and making agreements with them about what I would do. The blacklist that you are making such a huge deal about, Tyrant, is tiny. It is not updatable and never will be updated - there's no need to since new titles can detect the hardware if they care to. If a bug is found related to it, I will help correct it. Choosing to complain about it rather than help fix it is, in my opinion, a detriment to the entire community. Your personal stance on DRM is just that -- your personal stance. My personal stance is that the peace gained with a tiny change to the firmware was worth the investment of negotiation. I'm not forcing my stance on you (that is, I am not forcing you to use Skunkboard), it would be considered polite and equitable not to force yours on me. I am aware of your opinion and repeating it won't change anything. It seems likely to me, given the specific persons participating, the tone of those persons, and the fact that no such argument arose over revisions 1 or 2, that there is some beef with the timing of the announcement compared to the JagFlash announcement. Organizing this release took a great deal of time, and the announcement of a new product targetted to a different market with an unknown release date is not enough to change our plans. People have been asking for a new run for years, and we are trying to do one last run while it is still possible. Since the Jagware Flash IS targetted to a different market, and likely won't be ready until after this run is sold out, there should be no reason to cast aspirations on this one. (edit: I see at Jagware's forum they hope to take orders by the end of the year - didn't realize they felt they were that close.) There's really not much more to say. I'd like to ask people to knock off the sniping and snide comments on both sides of it. I don't see much need to rehash the same old discussions again and again. Specific questions about the release I will be happy to answer to the best of my knowledge. Anyone who knows about specific bugs with the current firmware, I am asking you to contact me and we will see if we can sort them out. I don't see how I can do more than that.

Not exactly - unless you modify the console. My pseudo GROM is already faster than the real ones, too. But it doesn't matter - all GROMs respond to all accesses. And so the console GROMs pull the READY line for every access, whether they are providing data or not. You would have to remove all real GROMs from the system (and not add any, ie via a cartridge) in order to see that benefit. It's not certain whether data writes will cause the same delay, though, I have not checked what the GROMs do in that case. The likelihood though is that they will induce the delay, since they do for write address. However, the open question remains because they only hold the ready line for as long as is needed to process the request - since write data is a NOP to them, it may be shorter. GROMs are comparatively slow, but less so than I used to think. It takes about 4 GROM clocks for the average operation, so that's about 9uS. This means you can do a sustained read from GROM of over 100k/S (not including the speed of the uP). Of course, this is about 30 times slower than normal clocking, but when you think about the 4 cycle wait states on most memory (which overlaps the GROM hold), it's only about 8 times as slow. Well, I don't have to expose the RAM if perfection is all that's acceptable. We can just waste it.

But you can't provide the name of the beta or give me a way to get access to it, so that I can fix the problem? Instead, you just diss the feature, over and over again. Since it was a beta, and we have repeatedly stated that no betas are on the blacklist, it stands to reason that it's a bug. I am actively fixing bugs - especially now is a good time since the new board will get a new BIOS. The "nobody is making money off it" argument is meaningless, though. I don't care about that, only the wishes of the copyright holders. It's just hearsay until we are given an opportunity to correct it.

In all honesty, I think the concern is more about titles possibly being locked out that may not necessarily belong on a blacklist of any kind. The odds are very low. If you find one, let me know and I'll fix it. I've stated this many times. Test me now, if you have one.

"Digital distribution" is not the same as "freeware downloads". There were games available for download before Jagware and Reboot came along. When people talk about the potential of the Skunkboard for future distribution methods, they are talking about commercial titles using the hardware to reduce piracy. While I don't expect we'll see much of that, the possibility is there for any developer interested. Skunkboard (rev 2 and 3) can run 6MB carts without modification (if any are ever created), and is the only existing or planned add-on since the Alpine that can do this, as far as I know. 6MB is the Jag's maximum cartridge size without bank switching. Games written specifically for the Skunkboard 2 or 3 can also use 8MB of flash by specifically switching the two 4MB banks. If you want to go bigger, you can tether to the PC over the USB cable, which will permit you to load code and data at will from the PC (works on all revs). It can even save in that case - there is full bi-directional communication. The included Skunklib has basic functionality for file access and Seb from the Removers was working on an even more advanced I/O system (though I can't see if it was integrated into their library..) Beyond that, there's a working GDB stub for the 68k to aid debugging, as well as fast turnaround time for debug (personally I love being able to reset the Jaguar without reaching for it, since mine is kind of buried). You can upload your permanent data to flash and run your code from RAM for the fastest testing. As for the evil blacklist, as Dan mentioned, unless you are pirating games, it won't bite you. And if you are pirating current games, that's your own problem. In the five years since release, with over 150 boards in distribution, nobody has produced a single false positive to me. Actually nobody has produced any hits for it to me at all. We actually started a compatibility list over at the JS2 Wiki, but it didn't get a lot of updates. Maybe there's a more public Jag Wiki somewhere?