JamesD

There was one called something like The Incredible Monster Machine

A woman I worked with has a VCS and Atari computer and plays the "classics" with her great nice when she comes to visit. She says she likes those games more than her PS2 she has at home.

Some later carts require 64K and don't work on earlier machines. Some carts supposedly have issues with the ROMs of newer machines. I haven't seen it but it's possible. The 1200 had some ROM issues so it might not run some stuff.

A French guy started the disassembly and he continued from there. Babel Fish would come in handy.

I could have done without his dislocated shoulder during sex blog entry. It was funny but a bit of an overshare. Oh, and the entry you linked too was pretty good. Funny how you remember places because of their smell, the lighting or other atmosphere. I'm from a pretty rural area and we'd go to the bar to play space invaders, pinball or pool. The place was dark, nasty, smoky and full of power drinkers. We'd drive to the next town to bowl, play Wizard of Wor and pinball but it was only open certain days. You could hear the Wizard taunting you as you bowled. Another bowling alley had Star Castle, pinball and pool but during league bowling the smoke would make you choke. The only local arcade was in a old building with little room but the games were crammed in. I still remember Omega Race next to Defender. Asteroids, Pac Man, Krull (never could master it). It had a slight musty smell and you'd have to wait for someone to make a shot on the pool table to get around it and people crowded at the games. The jukebox was expensive. When it moved to a larger building I remember Joust, Robotron, Venture... ahhh the left over smell of cigarette smoke from the bar that used to be there. They didn't even paint the walls. Now you could buy pop and there was plenty of room for the pool tables. The jukebox was still expensive. Pacman was in the Safeway and later Sinistar. It made going shopping with my mom tolerable. A sit down Asteroids Deluxe sat in the Dairy Queen and was later replaced with Donkey Kong Jr. It was a great spot because the owner's daughters worked there and they were HOT! It also had the best chicken, burgers and shakes. The only problem was that some kid would always be there hogging the game and the owner would have to kick him off so paying customers could play. When I went to college the game room in the student center had a pinball machine I could play a half hour or more on a quarter. It was my favorite spot between calculus class and history. I worked out my frustration on it. 'Rock Me Tonight' by Billy Squire or 'The Warrior' by Scandal always seemed to be playing on the jukebox. I remember hearing that Asia broke up around that time. The local bowling alley had Time Pilot and Decathlon among others but it was at the other end of town and I spent most of my time playing basketball or at the bar... California Coolers were the thing then. I remember Van Halen's 1984 came out around that time and the kid on the cover looked EXACTLY like my nephew. 'Jump' was constantly playing on the jukebox as well as 'Love Grammar' and 'Summer of 69'. After transferring to a University their student center game room had Mortal Combat at some point and some sit down games but I didn't even know it was there for a long time. The only game I remember was Mortal Combat. I was more interested in a woman and video games were the last thing I though of. The arcade at the mall had the pinball game Genesis but I don't remember much else except the attendant giving me an hour of free play on Joust after the token machine didn't give me tokens. It seems to me things were going down hill at this point. The arcades were asking for more tokens/play or reduced the number of plays. On top of that games that were coming out were starting to be copies of each other. I also became a partner in a business the 2nd year I was there and ended up spending all my time working. Now I have to go to Dave & Busters or Red & Jerry's in the Denver area to see anything like an arcade. The $10 that would last me hours now lasts about 15 minutes... counting wait time at the games.

The parents are usually the problem anyway. They pay no attention to what their kids are doing and expect them to turn out ok. I'll never forget leaving a Best Buy behind a woman and what had to be her 8 year old. She was buying what he wanted... a rated M game and a cheat guide to another rated M game. I guess she thought her child was mature or just didn't pay attention. One of the things I hate about the M rating is it's more obscure than an R or PG type of rating.

But did you do anything useful with it?

BTW, just because a compiler isn't 100% ANSI doesn't mean it isn't any good. Also, I did some reading on a Oric forum and found that lcc65 or whatever they are using promotes int to 16 bit. While this does follow the standard you do need to be aware of it. If you want to use a byte then use char. This should hold true for any ANSI compiler.

Ok, first of all ANSI requires floats so that alone means it's not. Second, have you run any compatibility tests to verify compatibility like the test suite GCC uses? I'm guessing no. Those tests are nasty and bring out minor flaws in compilers that can cause some real problems. ANSI isn't just changing calling parameters from K&R format and a few things like that. Certain code must be compiled a certain way. If ANSI is the final goal and you are close... fine that's cool, but that isn't the same thing as writing some C, testing it natively on a PC, then expecting it to recompile and run as is on a target 6502 machine. I'm not trying to be nasty, its just that I've tried porting code from one compiler to another way too many times where I had to rewrite valid code because of a flaw in the parser or code generator and that's even with commercial compilers. The linker and drivers sound neat. Free is always good and I have checked on the project from time to time so I do know a lot of progress has been made over the years. My comment about lcc65 was because I know it's based on a proven ANSI front end that optimizes intermediate code pretty well even before generating 6502 assembly. In spite of the ANSI front end that still doesn't mean lcc65 is full ANSI because the code generation may not be right... but at least it has a high probability of being ANSI.

Yeah, but how ANSI compatible is it? While I here it's very usable, I thought you did have to program around it's limitations. But I haven't tried it so I don't know. Still no floats I'm guessing. Wasn't there another 6502 compiler that had a better compiler front end but didn't optimize well on the back end? I think people claimed it still produced faster code. I think it was called lcc65? I know Z88dk is a pretty decent Z80 cross compiler but the last version I used still had some missing stuff that my program needed. I haven't tried the latest version but it sounds promising... still no support for what I needed though. SDCC looks like another good Z80 cross compiler but the version I tested crashed at times. The current version fixed the crashes but I haven't tried building any of my stuff because I'd need to port the Z88dk libs. I was working on a port of SDCC for the 6809 and actually had a large portion of the code generator completed but other things have taken my time for the last few months... which wasn't a bad thing since it's given me time to think a few things through and see how another 6809 compiler works. I started looking at how GCC for the 6809 does things and I realized it would be better to allocate registers in a different order. Trivial to fix but it *should* result in faster numeric conversions. There were a lot of other things I needed to figure out before going on (PC relative code, system vs user stack, DP addressing...) and I've finally decided how to deal with them. I guess it's time to get busy again.

But they weren't tokenized in GOTO/GOSUB statements. Trust me, I've disassembled lots of versions of MS-BASIC, starting with the TRS-80. Atari's BASIC was the first "pack-in" BASIC to tokenize line numbers inside a line. I wasn't aware of that... and it makes me wonder what they were thinking since it's such an obvious way to speed up BASIC.

I think line numbers were normally stored as a 16 bit integer all the way back to the early tiny BASIC interpreters for the first hobby computers. That also explains the limit on what line numbers can be used. I'm not aware of any versions that use floats for line numbers including many that otherwise only use floats. That includes Atari BASIC, Tandy CoCo BASIC and I think Sinclair BASIC. Those would be the first ones that come to mind. I don't remember if Applesoft had INT or not but since the Apple Integer BASIC was much faster I'm guessing it also was float only for numeric variables. On the other hand, the Atari corp Assembler cartridge (from what I understand) used floats for line numbers and it was much slower than it's competitors. I think the test to see if the line number called by a goto or gosub follows the current line was common. The pointer idea used by that version of Atari BASIC was pretty unique and the way it *should* have been handled. A similar optimization could have been used for variables but I'm not sure if it was ever used. Variables should have had an index into a table of pointers that linked to the actual variable. That way if the interpreter moved a string or other variable at runtime all that would need adjusted is the pointer in the table and it's much faster than searching a linked list.

As stated, most BASICs parse the line when you enter it, tokenize it, execute it in immediate mode or store it. Computers where you input the keywords with a single keystroke did so to reduce the size of the interpreter. No parser means a smaller/cheaper ROM. Later Speccy's used a tokenizer like everyone else as did the American version from Timex. To interpret a BASIC program the interpreter finds the current line and looks for a token. To interpret a token, BASIC just uses a jump table that has pointers to the routines they represent. Some tokens were two bytes long. The first byte was usually 255 which pointed to a 2nd table and the 2nd byte of the token was the routine to call from that table. If an unsupported token is found it just jumps to a routine that gives an error. Once a routine is called it has to parse the current line after the token to find parameters for that BASIC keyword. The more options for a keyword the longer it takes to parse. If the parameter is a variable there is even more work to do. Compiled languages do type checking at compile time and any conversion must be explicitly handled by the program itself. BASIC does it at runtime and is constantly checking what type variables are every time you used them and the constant conversion from one type to another. The typical way to store a BASIC program isn't exactly geared for speed either. The program is usually stored line by line with the line number, a pointer to the next line and then the tokenized code for the line. In the factory supplied BASICs I've looked at, they don't embed a pointer to lines that are called by GOTO or GOSUB with the call, they do a search by line number. That is done by searching through the program line by line looking for the line number. This made long programs slower than short ones. At least one replacement for Atari BASIC about doubled execution speed by adding pointers along with the tokenized lines. It did a scan of the program when you ran it to add all the pointers if you enabled that mode. Variables are handled in a similar manner. The variables are stored in a table as they are created and whenever you access them the interpreter looks them up in that table. That's why a program would run faster if you placed variables that were used the most first. Several BASICs omitted INT (integer) variables. Even loop counters are stored as FLOAT which goes back to the constant conversion. That alone slowed down many machines. On top of that a lot of the design of BASIC interpreters from back then was to fit everything in a small ROM and use little RAM instead of doing it in the fastest possible way. If someone were to rewrite BASIC for one of the 24 bit address buss CPUs (65816, ez80, etc...) where RAM and ROM limitations aren't an issue then I'm sure they could run BASIC much faster even without a lot of tricks. No, most BASICs didn't include support for sprites. I think the Tandy CoCo was the first machine to include an extended BASIC and even then it was an option. People had always used PEEK and POKE until then so nobody dealt with it any other way. After Microsoft created Level III BASIC for the TRS-80 Model 1, Tandy thought it was a good idea and decided to offer it with the CoCo as Extended BASIC. After a few magazines proclaimed the CoCo's Extended BASIC as the best, everyone else offered an enhanced or Extended BASIC. I have no idea why Simon's BASIC is so slow. The Plus/4 had most of it's features and did a lot of bank switching but was still pretty fast. But then the Plus/4 did have a faster CPU. FWIW, the Plus/4 also offered the largest amount of memory for a BASIC program of any 8 bit I'm aware of. It just didn't have hardware sprites or a SAM chip so people shunned it. I think there were plenty of BASIC compilers for most machines but many were pretty limited and usually just converted the code to a machine language program that made a lot of ROM calls. In the end they skipped most of the parsing or type conversion stages and made variable manipulation a lot faster but they were still hampered by slow ROM routines and little if any optimization to the machine code. The compiled programs were also very dependent on ROM routines being at a certain address and any upgraded ROM might cause them to fail. I think the Amiga was the first machine that really dealt with the ROM call issue well but then it was a much later 16/32 bit machine. I know Small C compilers made it to most 8 bit CPU's but the commercial ones were expensive on a lot of machines so very few people every bought them and it never really caught on. On top of that the size of the code the compiler could handle was pretty limited and they didn't optimize code very much if at all. Limited compatibility with the C standard was often a problem and you still see that on most of the open source cross compilers available now. Even the 6809 port of GCC fails over 1000 ANSI C compatibility tests and GCC is very compatible on other CPUs. Others don't even support floating point numbers or worse! Pascal was actually pretty popular on the Apple II and many commercial games such as Wizardry were written in it. It was a PCode interpreter (similar to Java) but by elimination of run time type identification/conversion and much more efficient code representation it was very fast. It also allowed programs that were larger than RAM to be written by swapping modules in and out of RAM. Still, the PCode interpreter it used is now looked at as pretty inefficient compared to what it could have been from what I've read. I think part of Turbo Pascal's popularity was due to people moving over from Apple II Pascal. Operating systems like CP/M, FLEX and OS-9 had many languages including Cobol, Fortran, Pascal, C, APL.... the list goes on and on but I'm not sure any machine but the CoCo had many graphics games written under such an OS. BASIC-09 was pretty popular on the CoCo and it also used a PCode type interpreter. Several commercial games were written in it.

I learned on a TRS-80 Model 1 my school had (and they only had 1). I did it by taking home the manuals from school and buying a couple other books. Then I programmed a Model 3 which is pretty close to the same. I actually wrote some account tracking software (not to be confused with accounting software) for my high school. I finally bought my own computer shortly after that... a Tandy Color Computer 1. The Extended Basic on the CoCo was almost identical to GWBasic if I remember right. I also programmed on my friend's Apple II+ a lot.

My understanding was that the Tomy Tutor was that it actually had a pretty advanced OS but I'm not sure. There's a Yahoo group dedicated to it if anyone wanted more info.

I didn't find the Exidy Sorcerer that attractive myself but I wouldn't give it an ugly award either. It would earn the "my cartridges look like 8 track tapes" award! BTW, I think the CDTV was one of the best looking machines made now that I think about it. The Tandy Color Computer Multipack interface was another expansion box that you could have connection issues with. If you bumped the computer so it twisted you could break the connection. A Coco with a multipack and a bunch of long carts plugged in wasn't exactly a pretty sight either.

Actually, the keyboard part came with 4K or 16K of RAM and the ROMs. It also had a cassette interface built in. The expansion interface brought it up to 32K or 48K. Ah, Level 1 Basic, 4K RAM and a cassette interface. Who would ever need more? Star Trek III, V3.4, BASIC Trek at it's finest! You have to remember the Model 1 was one of the first major commercial shots at a home computer and was released in something like 1977 or 1978. I know I first used one in 1979.

What was under the keyboard and what was under the monitor? The keyboard unit seems awfully thick if there wasn't anything inside it, but if the CPU is under the keyboard what's under the monitor? First of all, that's not the regular monitor. The part under the monitor is the expansion interface. It holds additional RAM, serial ports, cassette ports, parallel interface and disk interface. The cable between the keyboard and expansion interface often had problems making proper connections and caused the computer to crash. Cleaning the edge connectors with an eraser would fix it but this is where the term Trash 80 came from. Technically the term only referred to that model but owners of other brands soon adopted it for all things TRS-80.

The Commodore PET is the hands down winner for SCI-FI looks. Some of the Euro computers like the early Speccy or Oric models were cute. The Atmos with it's Black and Orange keyboard was very striking. The MC-10 was also cute as was the Matra Alice which was a modified MC-10 in a red case. The followup model with a full size keyboard had angled corners and looked like a museum piece. The Ti99/4 looks pretty spiffy with the brushed aluminum. The TRS-80 Models II,III and IV all looked very professional and neat. The Atari 800 looked real slick. I guess the IIgs looked pretty good too if you had the monitor to go with it.

I gotta admit that Silent Hill could be scary to a kid. I'm to old to have played most of these games when I was young enough to be bothered. I thought of another game that might be scary to a kid. I picked up a 2 PC game pack for $10 from WalMart that included American McGee's Alice and Clive Barker's Undying. Let me tell ya, Undying had me ducking, bobbing and weaving all over the place when the howlers came at me. Those 2 games were definitely worth the $10!

I've heard people claim a game called Phantom Slayer on the Tandy CoCo was scary. A 1982 first person shooter with a whopping 4 colors. Actually, the sound was what I think did it. Personally, I've had games where I was ducking all the time but I was never scared. AVP would probably be the closest to scary I've seen.

Where from? I'd happily pay $10 if there's more of them to be had from the same vendor. I bought it on eBay from myatari. BTW that's without shipping so it's $15 unless someone bids it up. I think they list one about once a month to keep from driving down the price. They have a lot of NOS Atari games and other items. Might even have an XEGS if you ask. Here is their eBay store: myatari

Actually, the copyrights aren't expired. The changes to copyrights regarding abandoned software were passed after they were released. But since nobody is making money on them they aren't willing to spend money to go to court. That or the copyright holders don't exist anymore. I picked up a NEW cart of Archon for $10 last month. Fun game btw... even if the computer kicks my butt all the time.

I played Half Life 2 all the way through and loved it but I thought a lot of the puzzles were a bit easy. I hate Steam... took over an hour to install and run Episode One thanks to it. BTW don't buy Episode One. I completed that in a couple evenings.

My ex business partner owned an Amiga dealership. The 1200 was more popular so he didn't sell that many CD32's. I think it would have been better in the CDTV packaging. People thought it looked a little cheap.