JamesD

I had to write a driver for a GPIB chip in an embedded system. Anyone ever read the specs for GPIB? EVIL!!!

I've purchased most of my old 8 bit machines off of the net. Most would have been difficult if not impossible to find without it.

The only thing I remember about this magazine was that the CoCo versions of the games were for non-extended BASIC and minimal RAM. In other words... the CoCo version always stank.

I've found it kinda funny that the drives have gone back to serial. Actually, so has the system bus. It's less susceptible to noise at really high speeds. I really wish USB had come out in the 80's. <edit> Actually, the highest speed devices like RAM still use parallel.

I think their inspiration for this demo is obvious.

I've continued to play GOW and it's fun but it still seems to involve banging buttons fast rather than much logic. I wouldn't expect anyone to get stuck anywhere for long.

Actually, the sound is probably from the Plus/4. It might use a SID add on card though. SID music has also been emulated on the TED chip pretty well too so it might just be the standard TED sound. The TED internal registers are all modifiable by the CPU so you can do all sorts of crazy things with it that were never intended. A lot of C64 titles have been ported to it by hackers in spite of it's lack of sprites or a SID. The demo is available for download if you want to check it out on an emulator. http://plus4.emucamp.com/home <edit> looks like someone beat my reply and it uses a SID card.

Oh please. There were some insanely quick fast loaders, both hardware & software for the Commodores. One of the best was a tiny public domain software wedge that could load 200k in about 3 seconds. And lets not forget the C128's fast serial when using a 1571 or 1581. I have to agree that the C64 wasn't as slow for most people due to fast loaders. There's also a minor hardware mod and free patch to use the high speed mode of the 1571 and 1581 with the C64. However, it's still not as fast as a parallel drive interface. But like I said... some sort of FLASH drive/ROM combination is the most likely way to do this. <edit> BTW, 200K in 3 seconds? I don't think so. Thats more than an old floppy disk holds. Seek times alone would make that impossible. 200K in 3 sec = 1024 x 200 x 8 bits / 3 sec or 546,133 bits / sec. 20K (about 1/3 an 8 bit's memory capacity) would certainly be possible if the CPU is fast enough.

Actually, if you are building a robot you probably won't use a floppy disk drive. Your software will probably be all in ROM or on a FLASH drive. You need a real time OS to do the job right. You would also need a system bus connector (card slot) for adding new hardware interfaces to control the robot. Built in ports for different things certainly wouldn't hurt. The CoCo fairs well on all points. Buss connector with full address and data lines provided OS-9 boot ROMs are available making the OS part easy A standard IDE design with OS-9 drivers (perfect for Compact Flash) D/A and A/D converters built in (could be handy) serial port... not a bad combination.

Also try the forums on CoCo3.com. Lot's of helpful people there.

I'd guess it's a cold solder joint. You might retouch the solder connections.

I wouldn't chose a 6502 machine... sorry. For my 1st choice I'd use the Tandy CoCo. The 6809 was used by NASA for the computers on the first space shuttles and OS-9 was commonly used for robotics applications. Actually, I'd prefer a CoCo with a 6309 since it's faster than the 6809. Standard CoCo's are also inexpensive. My 2nd choice would have to be the fastest Z80 based machine I could find since it is better supported by C compilers than the 6502 and is commonly used in a *lot* of embedded systems. The fastest "Z80" based machine was actually an MSX machine, the Turbo R but it is so rare you couldn't make much of a robot army with it... an elite robot death squad maybe. If we were strictly talking about a CPU used at that time or a derivative it would be some sort of Z80 decedent like the ez80, Rabbit or possibly a Z80 compatible FPGA core... one of which has been run at several hundred MHz when used in a custom ASIC. If we are talking about an ASIC, the free 6809 compatible FPGA core is around 15% faster than the 6809 at the same MHz and with some tweaking could probably reach the same MHz as the Z80 one in a custom ASIC and should be more efficient code wise than a Z80. However... if a gun were held to my head and I had to pick a 6502 machine to run a robot my first choice would be the Plus/4. Atari fast clock speed, dirt cheap to buy, plenty of ROM space if you use it's paging capability and why does a robot need sprites or sounds beyond what the TED chip can handle? 2nd choice would be the Apple since there were versions with 4MHz 65c02 CPUs, 3.5" drives and 1+MB RAM upgrades. Also, I believe the IIgs had 65816 CPUs long before any of the other machines. IDE/Compact flash drive interfaces have also been around for some time as well.

There are a few Apple related forums out there you should try on. This site has links to most things Apple II related. http://home.swbell.net/rubywand/A2FAQs4MAJORSITES.html

I don't know that they were considered obsolete just yet. Apple IIe's, Tandy CoCo's/Model III/IVs, Atari's and C64's continued to sell in large numbers for several years. Americans had seen several computers announced, introduced and promptly abandoned between '79 and '84. I think consumers were cautious of new players in the market. Even once large players in the US market bailed. Ti left the market in the fall of '83 and Timex in the spring of '84 (after setting sales records in previous years). PC clones were hitting the market in droves, the Mac had just been introduced and some of the MSX manufacturers had already failed to break into the US market with earlier machines.

I actually own a JVC MSX1 machine I picked up cheap on ebay. Some plastic broke off the corner while on it's way from Europe in a box with absolutely no packing foam or paper. Grrrr.... stupid seller. The power supply is internal and sooner or later I'll get around to replacing or rewinding the transformer so it works with US power. I just figured it would be fun to play with.

I have one of the silver Yobo game systems and it was compatible with everything I have. I only noticed sound problems in a couple places but they really should fix that instead of continuing to crank out models that have that problem. BTW, if I hadn't known what the sound was supposed to be like I probably wouldn't have known. I also have a real NES and I definitely prefer the size of the Yobo. BTW, I got the NES free... someone was throwing it away.

I believe it's a bow.

The Wiki claims 29MHz for the R800 and the Z80 in the machine runs at 7.14MHz. *If* that's accurate and it's 8 times faster than the Z80 then it would be the equivalent of a 232MHz Z80. I have my doubts but if true it would be fun to play with. <edit> I'm guessing someone is saying the equivalent of a 29MHz Z80.

Some illegal instructions in these 8 bit CPUs may have been the result of the hand layout process used at the time. It could have been tricks to keep the die small or just to save time.

So please tell me where in which hardware manual, errata, data sheet, or whatever, any of the issues I mentioned is documented at all (directly or indirectly)? Next time I go digging through my storage unit I'll see if I can find the book. I know at least some of that info is in it since I had to count cycles using the book. The timing diagrams were clearly aimed at hardware designers instead of programmers so I didn't look it over in detail. The company I worked for was engineering their own system and that's how I got the books.

I'll name: Where is documented the exact timing of the DIV instructions? Where is documented the exact timing of bit manipulation instruction on data registers? Where is documented that CLR is a read/modify instructions? Where are documented the higher bits of the lowest word on a group 0 exception stack frame?" Where is documented the exact behavior of the prefetch on self-modifying code? For that matter, where is documented the cycle by cycle execution of each instruction? The standard programmers reference manual just breaks down the instructions and only the more hardware oriented docs for a specific CPU had timing info. You still had to calculate cycles for a specific addressing mode but that's easy. I have a non-Motorola book somewhere that had the info as well. Seems to me it was the same publisher as the 6809 book I used and I even think I have 6502 and Z80 books by the same author and publisher. Exception stack frames are diagrammed in the Programmers Ref Manual... but I wouldn't count on all versions of the 68000 to exhibit any undocumented behavior from there. I'm guessing you'd need to refer to the more hardware oriented stuff or errata for behavior that differs from the Programmers Ref Manual. I'd have to look up specific instructions to see if it states whether they are read/modify or not but the programmers reference manual clearly states than on the 68008 and 68000 the CLR instruction exhibits that behavior. Other CPUs in the series do no. You mean the self modifying code that Motorola and Amiga said *not* to write because it wouldn't work on all CPUs? Sorry, never wrote self modifying code on the 68000 because my code was either in ROM or had to run on CPUs where it would break... but then I wasn't a game developer. However, if you were to need such information... you'd need to look at when the prefetch takes place in the clock cycle diagrams. I think that's in the more hardware oriented docs... it wouldn't be in the programmers reference manual. It wouldn't be specifically documented but you could look at where the prefetch takes place in an instruction execution to see if the instruction was fetched before you modified it. I wouldn't count on it working the same way on a 68020 or higher CPU. For that matter I wouldn't even count on it being the same in later embedded versions of the CPU where they went to a newer die process. It might but I wouldn't count on it. About the only thing I remember about the prefetch is writing code that ran faster on the 68010 because the loops were only two instructions and both were in the CPU thanks to the 68010 taking advantage of the prefetch buffer. Since playing well with the OS was important on the Amiga I didn't mess with certain interrupts... though I did use interrupts through the OS for some code. All that stuff is interesting but did the software written with those tricks work on later versions of the machines? I remember a lot of games from Europe breaking on the Amiga do to people being clever. Expecting Chip RAM only, a certain amount of Chip RAM, 68000 cpu... but that's a different issue. The 6502 doesn't exactly have "undocumented" opcodes. It has undesigned illegal opcodes which is quite a different thing. Undocumented opcodes (at least in the strict sense of undocumented as hidden and secret) are present in some Intel x86 processors. Since there is no "illegal" instruction trap and they are executed I would assume they are legal but not documented. Some of the "undocumented" opcodes on the Z80 are now "documented" and legal on the eZ80. I'm pretty sure that's how they worded it... pardon me for following Zilog's their lead. Beg to differ. The 68000 is considered a 16/32 bit CPU because its internal architecture. Not because of the data bus width. Most internal buses are 16 bit wide. And most important, the ALU is 16 bits. Of course that later 680X0 CPUs, starting with the 68020, are 32-bit. I stand corrected... however it is still 16/32... not 16. There are true 16 bit CPUs that don't have 32 bit instructions or registers so there is a difference.

How exactly was the 6502 better documented than the 68000? I have some of the Motorola docs on the 68000. There are complete explanations of the programmer's model, timing diagrams, cycle counts... you name it. This was available from the manufacturer when the CPU was released. It doesn't look any different than the docs I've seen for any other 8 bit cpu. But then these are books from the manufacturers that aren't commonly carried in the local bookstore. You would need to order them from an electronics distributor or the manufacturer. But then, if you've never programmed embedded systems you may never have seen the manufacturer docs. They aren't for beginners but everything you need is there. If anything, manufacturers were more forthcoming with developer info on later CPUs than earlier ones. I'm sure that was because of past experience. When the first CPUs like the 8008 or 6800 were introduced there wasn't the demand for widely available documentation. With the exploding personal computer and embedded cpu market that changed. There might have been more third party books on the 6502 because it entered the home PC market sooner but that doesn't mean better documentation. If the books I have for the 6502 are any indication... quantity does not equal quality. It looks like publishers and authors were in a hurry to release anything for the 6502 and Z80. I even have a book that was published under two different names in an attempt to resell the same useless book twice. In a way the 68000 was better documented because it didn't have undocumented opcodes like 8 bits. There was nothing undocumented about the 68000. Sure, you could discover ways to do the same pieces of code with fewer instructions by using them in less obvious ways... but that's STILL happening to this day. BTW, the 68000 series is not 16 bit. The series is available with an 8, 16 or 32 bit data bus but it has 32 bit registers. Th 68000 is often referred to as 16/32 bit due to the 16 bit external bus. Many Amiga and ST machines came with full 32 bit versions. I see illegal instruction interrupts as more modern and better in a lot of ways but that totally depends on what you want to use the CPU for. The 6809 and Z80 don't have illegal opcode interrupts either but the compatible Hitachi 6309 and 64180 (aka Z180) do so it's not like it wasn't available in the 8 bit world. I believe the 65816 has illegal instruction traps as well but I haven't programmed it so I'm not 100% certain.

Yeah... about that... have you ever even seen the Amiga ROM Kernel Manuals? Comprehensive would be an understatement. Good... they were more for a professional developer than a beginner so if you are a pro they are great. If you are a newb... you wouldn't even know where to begin. I spent a lot of hours searching for stuff in those books and invaluable would be the word I'd use. But then I was part owner in a software company and majored in CS so no big surprise there. For beginners, the AmigaBASIC manual was pretty good but it was just a reference manual for the most part if I remember right. I don't know anything about the C64 docs so... whatever. As far as Amiga... the OS takes up more ROM than there is total memory in a 130XE and the hardware is more complex. The volume of docs required to understand it has to far greater. BTW, there were a lot of books that came later for the Amiga as well and good luck equaling the volume of source code that was released on Fred Fish disks or Aminet. Not fair to compare one machine that was out over 5 years before the other one was introduced? Gee... I think the 8 bit had a hell of a head start... that should have been more than fair. I think what you are really saying is that it's not fair to compare the Atari in any way that would show it to be inferior to another machine.

I just purchased a new PS2 and both games. (I'm more of a PC gamer than a console fan) GOW is a good game... it's much better than some of the games my brother has. However, it kinda emphasizes button smashing. Ok, want to kill a minotaur? Beat the button senseless and you win. What? No 4 button combo that drives me insane to learn? That's good and bad. Easy to learn but I'm not sure there's much to mastering the game. Some of the puzzles have seemed to draw a "oh please" response. One of the best of 2005... sure... but I think calling it Game of the Year is a stretch. Shadow of the Colossus... I started playing it at 8 something pm. After battling the 3rd colossus for who know how long I realized it was midnight and I had to work early in the morning. (ok, so I had a little trouble getting onto the 2nd one) The graphics are stunning, the game play is unique and first rate. The first colossus was quite the experience. I whistled, he looked down and I said "oh crap... what was I thinking". I had no idea of what to expect. LOL One of the best titles I've played on any system.

The Amiga docs were all produced by CBM and the text inside clearly shows it. I actually have one of the first AmigaDOS programmers manuals and the Copyright date is before the release of the Machine and guess who owns the Copyrights on the ROM Kernel Manuals? Commodore Amiga. That means a lot more than who published it. I'm not sure what the IBM PC has to do with this but PC Clones were available long before the Atari ST came out. The PC came out in '81 and major brand clones like Columbia were introduced in '82... though I'm pretty sure some import clone parts were already out in '81. A former business partner of mine started selling clones long before the ST was introduced. Given the decision of Apple vs. Franklin licensing to other companies was a non-issue as long as they developed their own compatible BIOS. Ever hear of a Phoenix BIOS? Developer docs for the PC/MS-DOS were available when the PC was released but I'm not sure at what cost. The reason Apple clones disappeared from the market was they copied the ROMs instead of developing their own and Apple pursued them rigorously. Franklin made a compatible ROM through reverse engineering and they were ruled legal in court after they did so. VTEC Laser machines also had their own ROM. One of the two even licensed Applesoft BASIC... Apple hadn't made the agreement for it exclusive. I think it was VTEC. The Lasers were a pretty decent machine and later versions could run at 4MHz... much faster than the Apple. That prompted the introduction of the IIc Plus with it's high speed mode. I have a couple of those and a Laser 128. They were nice machines for the time... at least as far as 8 bits go. Apple actually licensed a third party product to do the high speed circuit if I remember right. Apple II's included a disassembler/monitor in the Apple II, schematics of the machine and a lot more. They published a lot of ROM calls as well and WOZ even publicly released source to the Sweet 16 interpreter in the Apple II ROM. I'm not sure how that qualifies as withholding information since most of that was in the manuals that shipped with the machines. You have to remember that the founders of Apple came from the hobby computer community of the '70s where everything was given away. They protected their copyrights but their systems were open as far as developer info.