Jump to content

Dr. Van Thorp

  • Content Count

  • Joined

  • Last visited

Everything posted by Dr. Van Thorp

  1. I'll give a mention to the Spectravideo SV-318. Really rather bland looking, with rubber chicklet keyes in a white plastic case with angles that resemble several other machines from the era, but it is distinguished from all other machines by the presence of a red arcade-style joystick built right into the keyboard. This, during a time when most home computer makers were trying to distance themselves from game consoles. This machine became the basis for the Japanese MSX standard, but the built-in joystick, alas, was never standard on any other machine.
  2. The best place is in the development facilities of game companies in the 70's and 80's.
  3. Without a devil, what will the gamers unite against?
  4. A not uncommon practice; Commodore had an enhanced BASIC ready for the C-64, but instead reused the old PET basic out of fear that the C-64 would steal the market from a more expensive machine in the planning stages. Even more recently, Intel sold a hobbled Pentium called the Celeron, and used the weak Celeron's price as a justification for charging more for the Pentium, which had the same manufacturing cost. Stupid, stupid marketing people.
  5. I have no idea that that means. Is this supposed to be code that makes the Antic display an Apple HiRes screen? The Apple maps hires graphics in horizontal rows of bytes, and the rows have a really screwy arrangement in memory. To convert position order to memory location, you switch around the bits in the x coordinate and multiply by 40, then you add y/7. Apple Hires also uses a only the lower 7 bits in a byte to map pixels, with the highest bit being used to select between 2 color pallets. Each pallet has black, white, and two complimentary colors. But the colors displayed in the 7-pixel block are also determined by the pattern of pixels displayed. Can the Antic really recreate this screwy screen map?
  6. Are you familiar with how Apple II graphics are mapped?
  7. So how does this emulator work, then? Does it do some kind of translation of the apple II software?
  8. I don't think so. Not entirely. Yes, the Apple II has a simple (though rather eccentric) video system that is easy to emulate, but I'm 99.9% sure that this emulator is using an interpreter to execute Apple 6502 code. I hypothesize this model for the emulator's operation: The 6502 code in interpreted. No big trick; interpreters for 6502 code were built into every 6502 monitor from back in the day; this is how the monitor was able to "STEP" through sections of code and display the contents of the registers after each instruction execution. The emulator's interpreter would execute code at maybe 1/10 the speed of actual direct execution by the CPU, and would interpret native Apple II machine language software including the Apple's ROMs (which include the Integer BASIC interpeter). Since the Atari and Apple both need zero page memory, and each needs its hardware memory maps in a specific fixed place; so pretty much all of Apple's memory would have to be virtualized into new locations in the Atari's memory; this is why the Apple's machine code need to be interpreted instead of executed directly. A portion of the Atari's memory would contain the emulated Apple II's memory, but another portion of the Atari's memory would have to contain the Atari's screen maps. The machine code interpreter would have a list of memory locations that have input/output functions in the Apple II; whenever virtualized Apple memory is written to, this list is consulted; if, say, part of the screen's memory map is changed, the emulator pauses in the interpretation of code, and updates whatever part of the Atari's screen needs to be changed. Likewise, the emulator would know how the Apple's keyboard, paddle controllers, etc. are mapped in memory so that when this memory is referenced, the correct information can be read from the real Atari and transliterated to the virtual Apple. And the whole thing is slow. Ten or more times slower than a real Apple II. So the Apple II and Atari having the same CPU is not a big factor in the feasibility of this emulator; an interpreter can be written to run any instruction code on any CPU. Maybe someone will write an Apple II emulator for the TRS-80 Color Computer. Now I just read somewhere else that in the early 1980's, a software company developed VIC-20 games on an emulator that ran on an Apple II. I bet that the VIC's graphics screens really looked like crap on the Apple's HirRes screen.
  9. I google translated the page. It emulates the earliest Apple II's with Integer BASIC; not much Integer BASIC software requires 80 columns. So I guess that a few people aren't impressed by this software becuase it doesn't have 80 columns. Maybe those peope should write a better emulator. I want to run Apple II stuff on my VIC-20.
  10. I don't know if this emulator uses the technique, but there was software that could display 80 columns on the C-64's hires screen by drawing skinny 4x8 pixel characters. I myself had a terminal program that had 80 columns. Was this technique ever used on Atari machines?
  11. That isn't a bug. That's how the TI video chip works. Most video chips from the time had some kind of limitation. The 5200 video couldn't produce more than 4 colors per scanline in any descent resolution. The NES couldn't have more than 4 colors per character (8x8 pixels), the Intellivision couldn't have more than 2 colors per character, etc. But of course many talented artist could get around those limitations and produce incredible graphics for any of those platforms (ok, maybe not for the Odyssey2). The TRS-80 Color Computer had a graphics mode with 40x200 resolution, without any particular limitations on color placement. This mode was sometimes used for colorful splash screens. The CoCo had more reasonable higher resolution modes, but with much more limited color. Any graphics mode, not matter how limited or screwy, had a use. Squeezing usefulness out of limited hardware is a lost art.
  12. I once had the controlers from the Kiosk, custom mounted in wooden boxes.
  13. There was a brief time when most console games were Atari ports, and many computer games were Apple ports, and you could recognize the source at a glance.
  14. Like the 2600 there are modern circuit boards and 8k/16k chips available to burn and solder to make new carts without having to destroy old ones. Are there also modern C-64 cartridge shells? Is there a stock shell that just happens to fit? Or are these custom resin shells from a garage shop?
  15. It's remeniscant of early games that were ported from 2600 to C-64; is this a port? The next step is to create a game that really takes advantage of the extra memory and graphics capability. How were the cartridges made? Did you find vintage cartridges with EEPROMS?
  16. The original VIC graphics chip was developed by Commodore's MOS division with the intent of it being licensed to a game maker to compete against 2600/Intelivision are machines. This didn't happen. Then came rumors of upcoming Japanese machines that would kill the American market, so Commodore quickly re-engineered their PET computer to use the cheap VIC chip to produce a low-end machine that would beat the Japanese in price. The Japanese machine never arrived. Then MOS's engineers went to work on another graphics chip. Two engineers compiled a list of all the features available in competitors' machines, and created a specification. The chip was the VIC-II, initially also intended for a game machine. This was combined with the SID sound chip, initially intended for a synthesizer, into a new machine with roots in the earlier VIC-20 and PET machines. The resultant Commodore 64 was compatible most VIC-20 peripherals, and had the same BASIC programming language, but outside of simple text-based BASIC programs, the graphics and sound were pretty much incompatible. Remember that old 8-bit machines had minimal OS's; maybe 16-k or so or ROM, and maybe a couple of kilobytes of disk-booted DOS (which the Commodore machines didn't even have). So graphics and sound functions in games were mainly accessed directly through the hardware chips, without any application program interface between the programmer and the hardware. To make these two machines compatible in regard to graphics and sound would have been near impossible at that time. Though I do recall one BASIC game, published in Compute magazine, that included some clever assembly language subroutines that simulated hardware sprites on the VIC-20 under special conditions to allow one game to run on both machines with minimal changes; an idea that could have changed everything but didn't take off.
  17. My buddy has one, brings it out when he has parties. Always impresses people.
  18. So waht was the story with Atarisoft? They released a VIC-20 version of Donkey Kong which is the version linked to above. I also recall several knockoff version of DK for VIC; I had Kongo Kong on Cassette, purchased from a tiny ad in the back of compute magazine; graphics bore little resemblance to the real Mario and Donkey Kong. I would consider the official Donkey Kong to be the most authentic looking port ever available on the VIC-20; well I guess that VIC Invaders was a pretty good too. The DK port used VIC-20's multi-color HiRes/Tile mode, which tended to be avoided for its blockiness, but worked pretty well in this case.
  19. Here's a nice video of the Intellivision version of Donkey Kong: http://ca.youtube.com/watch?v=4R115WkI9lI For comparison, the Colecovision version: http://ca.youtube.com/watch?v=0yDWuhkHHpw Don't hold all of the deficiencies of the port against Nintendo's programmers. The Intellivision had about half the graphics resolution of the Colecovision, and a quarter as many hardware sprites. I don't think that the Intellivision wasn't designed to display multicolored sprites (this could only be done through arcane raster synchronization tricks) so Mario is probably actually two overlapping sprites. I read somewhere that Intellivision's graphic ship was from the same maker as the Coleco's chip, and was a direct design predecessor; you can see the improvements made in just a couple of years. And finally: The 2600 Version: http://ca.youtube.com/watch?v=-SG_ILlNCEw Can someone find a cleaner video with game sound? The 2600 was designed with games like Breakout and Gunfight in mind. This probably really was about as good as could be done. At least Mario is recognizable as Mario, which probably could have been done on Intellivision if someone had taken the time.
  20. Coleco began as the Connecticut Leather Company. Maybe the machine is pronouncing it right.
  21. Has anyone else seen this? http://design4dev.wetpaint.com/page/TV+Computer?t=anon
  22. I just remembered another one. Hasbro secretly developed a system called NEMO, but cancelled the project when the game market crashed. NEMO stood for "Never Ever Mention Outside".
  23. If you want to see what the Colecovision could have done, look at Sega Master System games; both machines had the same graphics chip and the same CPU. As for the CoCo, Radio Shack's whole marketing system was its enemy; Independant stores couldn't sell the machine so they didn't carry the software, and Radio Shack stores carried the machine, but were not allowed to carry third-party software or hardware. There was third party stuff, but it was ghettoized into mail order through ads in CoCo magazine. Would have been cool to have seen this machines quirky hardware pushed to the limit. Was there ever a CoCo demo scene?
  • Create New...