Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/16/2020 in all areas

  1. Hi, I wanted to present to you my version of the Atari 7800 SD cartridge. What you can see in the photos is a prototype version on which I learn how to use. The cartridge will be operated using four buttons and the display, of course, it will be in the housing. For correct configuration, the cartridge uses .a78 files and the header. As of today, it supports 4k, 8k, 16k, 32k, 48k files - without banking, 64k, 128k, 256k, 512k with banking. In addition, 16k RAM for $ 4000 and POKEY for $ 4000 and $ 0450. Various combinations are possible. Also supports Absolute and Activision. Below is some evidence that I am writing the truth: Demo Multi-Lock On, 512k + Pokey $4000 Demo 1E78, 128k + RAM Double Dragon, 128k, Activision F18-Hornet, 128k, Absolute E.X.O, 256k + RAM Donkey Kong XM, 144k + POKEY $0450 Bentley Bear's Crystal Quest, 144k + POKEY $4000 or $0450 Rescue on Fractalus, 32k + RAM. Can you confirm that the graphics are displayed correctly? The lower bands are due to the fact that the game is NTSC and I run it in PAL. Ultimately, the cartridge will also have a USB connector that will allow you to load files directly from a computer. I've already tested it and it worked. I'll be back from vacation in two weeks, I'll spend a few more days testing with different files and designing the final version. If you have any suggestions or ideas, please write. And there is also a sticker on the cartridge, designed by a colleague of MotionRide:
    15 points
  2. I finally got around to cleaning up some of the WIP code that I had for a8rawconv and implementing some missing support for different disk geometries than 40 track single-sided. Attached is a8rawconv 0.94. There's a lot of changes under the hood for the multiple disk geometry support, so there may be bugs lurking, but the intent is to try to do the right thing by default -- default Atari decoding uses 40 track single-sided, decoding to ADF or VFD selects 80 track double-sided, etc. Changelog: Updated help file, now has a TOC. Windows 64-bit build included. Double-sided and 80-track formats are now supported (-g). Dumping up to 42 tracks at 48 TPI or 84 tracks at 96/135 TPI is supported (-g 84,2). New decoded format support: Atari XFD (read/write), Apple II 5.25" ProDOS order (read/write), Apple II / Mac 3.5" 400/800K DSK (write only), PC 160K-1.44M VFD/FLP (write only), Amiga 880K ADF (write only). Double-density ATR images and XF551-compatible double-sided encode/decode are now supported (-g 40,2). Sector interleave can be changed for encoding (-i). -i xf551-hs, for instance, will encode double-density disks with 9:1 interleave instead of 15:1, and -i none will use 1:1 interleave. Added support for high-density 2us FM / 1us MFM timing and high-density drive select (-H). 179X/279X MFM decoder now has relaxed sector size and side address field validation to better match FDC behavior. Address CRC errors are now encoded properly from ATX to raw flux. Added flux timing analyzer to display a histogram of flux transition spacing relative to expected (-analyze). ATX image handler supports enhanced density tracks and extended long sector size encodings, sectors outside of the normal range, and better compatibility for long sector error encodings. The creator ID is now set. SCP hardware handler now auto-handles COM ports above COM9, decodes hardware errors to readable messages, shuts off the drive on an error, and allows lowering revolutions for reading below 5 (-revs). When reading from an SCP directly, a8rawconv automatically switches to 8-bit flux timing encoding when the SCP hardware runs out of memory with the default 16-bit encoding. This can be required for unformatted tracks or for 5 revs on a 1.44M disk (200ms / 3us avg * 5 * 2 = ~660K > 512K). Add heuristics to try to detect the track data list layout of an SCP image to work around ambiguity in the file format spec. If this fails, the layout can be overridden with the -if switch, e.g. -if scp-ds40. SCP write format updated to latest 2.20 spec -- 84 tracks now supported, timestamp and footer added. Drive type is varied based on geometry to try to provide best compatibility depending on whether tracks are supposed to be physically spaced at 48 or 96/135 TPI. SCP images written from synthesized flux timings by encoding sector data are marked as normalized non-preservation. a8rawconv-0.94.zip
    9 points
  3. Making a status update. I have not had much time for hobbies in August. I have put a lot of effort into physical design, because I really wanted to. I made paper prototypes of the Front Panel where the common ports are. Some will finally migrate to the back, like VGA and printer ports, but SD slots, joysticks and PS/2 belong in the front. This is ready to get lasered out of wood, or acrylic (the intended final form) but Covid makes that a big deal to go do. (At Hackerspace, must wipe down computer, laser, and work area before and after use.) The "floor plane" is also paper prototyped and ready to laser. It holds 8 card rails (Bivar), the front panel PCB (including ATX power connector) and has ventilation slots for air to flow up between the cards. A laptop blower fan points into there. I have re-routed the CRU and BIOS boards a couple times with changes. The CRU has one master connector for I/O that goes to the front panel PCB. A riser from this PCB has the physical ports sticking out. The front panel PCB also has individual box headers for peripherals that follow PC97 standards like RS232, VGA, AC97 audio. So there is the alternative of plugging in PCI slot brackets, the kind that come with ribbon cables, if you want to put this in an ATX case. (If you bought an F18A, you are familiar with the VGA slot bracket with ribbon cable. That's what I'm talking about.) I have not found any standard PCI slot bracket pinout for PS/2, though. There will be a header for the GamePort bracket, to which you can hook up one of the 15-pin MIDI adaptors. I verified that you can still buy all these PCI slot brackets for cheap. (FWIW, the internal cards also have holes at the PCI spacing.) I had a neat idea. There are now two TMS9901 chips. One of them is mapped at >2000, privileged space. It handles the real interrupts and some peripherals like PS/2 and SPI for the BIOS. The other is mapped at >0000 for compatibility. Its pins are wired to the actual joystick pins and 4A keyboard (if you want one, there is a connector kit.) The 2 interrupt status bits are fed to it by the other 9901. The MDOS keyscan bit and others are connected, too. I am trying to achieve maximum compatibility with MDOS/GPL in real chips, while offering a new BIOS layer that uses all the interrupt levels of the 99105. The 9901 timer is also there for user access. The one at >2000 is reserved for the BIOS, which might use it to implement multitasking. I still need a way to spoof the 4A keyboard lines from the PS/2 keyboard-- I imagined the FPGA doing that--it should look like an 8-byte RAM. But now there is a real 9901 onboard, not a simulated one. The goal is maximum compatibility with games that directly read the keyboard, without introducing an I/O coprocessor. Audio/Video I'm not putting effort into this now (I want to get back to the 9958). But here is an idea I had. The audio card--packed with goodness--on its current PCB layout it has room for 6 more 1/8" jacks in front. A TL084 op-amp and a jack can be as cheap as 20 cents. It already has the AC97 connector for the standard LineIn/Mic/Headphone-LineOut. I had the idea of making each separate analog signal output on its own jack. (otherwise they get mixed digitally.) So you could take just the Speech output, pass it through your favorite sound effect module, and then route it back to LineIn. Then, in the digital mixer (Speech has both digital and analog) mute the Speech, and pass LineIn through. Another thing you could do is take any of the "dry" sound chip output channels and put them through your own reverb unit or mixer. Four months to go or I'll have to call this "2021".
    9 points
  4. Hi TI-99/4Aers! I am currently writing a text adventure, "Tristam Island", for retro (and some handheld) systems. I am aiming for about two dozen of different ports: Commodore 64, PET, VIC-20, Apple II, Amstrad CPC, TRS-80 CoCo, Atari 8-bit, Atari ST, Amiga, Spectrum, etc. (but also Dreamcast, Game Boy Color, Game Boy Advance, and Nintendo DS !). Today, I have exciting news to share with you: I will be releasing this text adventure for the TI-99/4A! As far as I know (correct me if I'm wrong), this will be the first text adventure that uses Infocom's tools to be released in 30odd years! If you recall, Barry Boone was the first to figure out how to reuse Infocom's interpreter with different game data; this was used to release post-1984 Infocom games like Ballyhoo or Leather Goddesses of Phobos, after Infocom stopped making official versions. Boone's interpreter also provided fixes, and compatibility with 80-column displays, and the Geneve. The tricky part was managing to massage the game file into the format chosen by Infocom (two D/F 255 files). With help from Boone himself, and from Shift838 (who helped me getting started with the TI-99/4A and hacked the disk image to load the correct things), I wrote a Python script that takes a ".z3" Z-Machine file, and outputs the two files needed by the TI-99/4A interpreter, in the correct format. I am happy to release this script for all to use, on my Github account. The simplest way to use it is to take an Infocom file (zork1.dsk for instance) and name your game ZRK1.z3; the Python script will give you 2 files that you can copy (using TI99dir) inside zork1.dsk, overwriting the Infocom game files. All that remains is hacking the other files to get it to display something else than "Zork" in the title menu; if you bug Shift838 enough, I am told he might consider building a user-friendly tool which does that hacking for you I hope you're as excited by this as I am! If you want more regular updates on the game, you should follow me on Twitter (@hlabrande); if you want to get notified of the release, you should follow me on itch.io! And of course, a big thank you to Barry Boone and Shift838
    8 points
  5. 8 points
  6. The Atari engineer who worked on the 1600 (cross between 8bits and PC) has posted some new pictures on Twitter. The keyboard seems to say "Toshiba" and look similar to the T200 one.
    7 points
  7. Ever want to beat Fathom for TI-99, but can't be bothered to locate all the stars? Or just want to see what the world looks like, as a whole? Here is a Fathom TI-99 worldmap which gives the locations of all stars for all nine levels, attached, for anyone who gets stuck at some particular level. Created this in the course of my recent Fathom deep dive. A complete playthrough for all levels is also available here. But probably it'd be more rewarding to just play it for yourself. I really, really like this game, and as far as ports go, prefer the TI-99 controls to the CV and INTV control design. Among other things, I really appreciate the attention to detail in having the seaweed patterns be continuous between screens, across the underwater map.
    7 points
  8. Manpupunyor rock pillars This scene looks like a science fiction illustration or an LP cover but is a real place in Troitsko-Pechorsky District of the Komi Republic, north Russia 34 colours drpeter_Komi.xex
    6 points
  9. Having the original cart always "feels" better to me, but if you dont have the original cart, the Harmony is DEFINITELY the best option. Well worth the money. It is a *must have*.
    6 points
  10. It only makes sense to me seeing as there are already a decent number of 2600 SD carts that have that covered.
    5 points
  11. I had a very solid Astrosmash score this spring. Worked very hard to get it submitted to Twin Galaxies but it fell apart. Their website security is broken and their volunteer staff are, well... volunteers. Couldn't get any traction. In Shark! Shark! news, I don't think I'm going to do much better than this.
    5 points
  12. I don’t really have any of the cool promo stuff you guys show here. I did however remember that I had this mail in item from my Commodore 64 days. The flyer has a small type in program to make your own Pitfall Harry on the C 64. This was actually mine from back in the day. I’m not sure if I’ve ever seen it in another collection.
    5 points
  13. Here is a complete set of source files that will assemble to the latest known version of MDM5. The assembly process in this zip archives uses the MDOS batch file "ASS" and the Link file "LINK1" to put the various modules together. The code is from the V1.29 codebase, but to differentiate this from any future versions, I numbered it as V1.60 should there ever be a question on its origin. If you have any questions, just ask. Beery MDM5-V129-V160.zip
    5 points
  14. Another week, another Penult demo. Demo 15 has been added to the first post. This version fixes a sloppy error that made the dungeon unplayable in the last demo (discovered by @MissCommand). Additionally, I've changed the death penalty again to be even less harsh. The game is challenging enough on its own without making death set the player too far back. So, with this version, getting killed will make you lose all of your gold, but you keep your armor, weapons, and equipment. We shall see if this works well, or if it goes too far on the lenient side. Hopefully this will be the last demo I release for a while. I'm making good progress on the main game. Right now I'm working on the endgame. That doesn't mean that everything else is complete - just that the endgame is the part of the game I'm working on now. Edit: Demo 16 added to fix minor restore issue.
    5 points
  15. Btw, I trust and recommend you as I have purchased a couple of your Lynx SD carts. Anyone unfamiliar with rj1307 should buy with confidence once this becomes available.?
    5 points
  16. Ripped-off from Inspired by Mytek's Transkey-II Stereo Interface, I created the Atari 400 multi-port doodad: This provides a ps/2 port for a Transkey-II keyboard, an S-Video port for the UAV, and a 3.5mm audio out for any of the various UAV Audio Companions (stereo/mono switchable via jumper). All the connecting wires fit out the hole for the RF cable because I didn't trust myself to modify my Atari 400 case. Here is the physical board, doing it's thing, with and without cables attached: These are the parts used: Custom board: OSH Park Mini-din 6-pin socket: Jameco 11945 Mini-din 4-pin socket: Jameco 140791 3.5mm audio jack: Jameco 2161553 straight single headers: Jameco 160882 (breakaway, only need 2 pins but who doesn't need more of these?) right angle double headers: Jameco 203932 (breakaway, makes two 5x2 right angle headers) shorting jumper: Jameco 19141 female crimp pins: Pololu 1930 crimp connector housing, 2x5 pin: Pololu 1913 crimping tool: Pololu 1928 26 AWG wire: Amazon It works! Future improvements could include a 3d printed case and maybe a shielded 9 wire cable instead of loose 26 AWG wires.
    4 points
  17. Cleaning up the file select screen. I have mostly pulled away the chonky text, added a delay for long filename fetch, and made the long filename more easily seen, as well as made the < > pagination keys more visible. (IGNORE THE MISSPELLED OPTION, I have to type inverse chars as hex!)
    4 points
  18. Its been a while but I'm happy to say that my SAMS 4M card is up and running (thank you Ksarul!). I had a bad DALLAS SRAM that was giving me intermittent fits so I switched to ZEROPOWER SRAM and now I'm showing the entire 4M and, it seems to be stable so far. I've paged and written to all 1024 pages several times successfully; I'll continue to work with it and use it as my main memory expansion card.
    4 points
  19. I don't have too much left to share but JayAre's Ice Hockey poster reminded me that I have a couple of them framed. I need to hang them but I'm out of wall space in my gameroom.
    4 points
  20. I can't resist. (Sorry) Forth Assembler Length of labels : 31 chars Speed : Single pass, pretty quick Max Lines : disk size Structured loops : YES Structured jumps : YES Linker : Forth is the linker Interactive : YES Macros : YES Source Available : YES We now return to our regularly scheduled program...
    4 points
  21. I am indeed the creator of this tool. I use it to make Pascal and Assembler programs in P-code. With this tool I also have a quick way to see the contents of a disk (and the files) and to move the files (by save them first to windows) to an other disk. I noticed now the error in the text files transferd from windows to the disk and i will fix it in version V2.2 I was not able to reproduce the right click error in the file-popup, but i notice that the last popup was still visible when i click om 'empty', i will fix this too. When there are other problems with this popup or with this program, let me please know. With version V2.1 you can edit a disk that is in use by the emulator, this was not possible in version V1.0. So you can ignore what is told about the need to swap the disks. With ReLoad and ReSave you can reload or resave the disk that is opened with 'Open Disk', it is a quick way to save and load, but I think, that I do not need to tell, that you have to use it with canniness ... ? When you click on ReLoad in stead of ReSave your changes are gone. Use ReLoad when you made changes on the disk in the emulator, that you want to see in the tool. Use ReSave when you want to save the changes, you made on the disk in the tool, to the disk-file. I did no see the benefit of building in a "are you sure" popup .... With 'Open Disk' you can open also some P-code disks that do not have the TI FDR, so you can read P-code disks from some other computers. The way i used this tool at the moment: 1. Open disk1 with 'Open Disk' 2. Open SYSTEM.WRK.TEXT at the disk in notepad with right-click 3. Make changes in the programfile 4. Save and close notepad 5. Click ReSave 6. Compile the program 7. When there are some errors I right-click on SYSTEM.WRK.TEXT and make the canges in notepad (at this moment there is no need for ReLoad) I repeat 5 till 7 until the program is ready
    4 points
  22. Found in Spain .... Intellivision console, American 2609A with 125/220 power supply for the Spanish market .... who knows why they haven't made a specific one for Spain as well as in other European countries?
    4 points
  23. Some progress... Rescue Terra I: 77850. This is a really fun game. Espial: 11880 Condor Attack: 17753
    4 points
  24. This makes me so sad. VBXE is not using a PC with an NVIDIA card. You're still bound to 6502, it's what Atari should have done in the early 80s, rather than sticking with 1978 technology through the EOL of the 8-bits in 1992. If you code for the VBXE you will see it as a natural extension of what should have happened. It has a display list. It is scanline based. Few more pixels per line, few more colours. Same overall feel. This shitty attitude towards only the VBXE kills me. 10+ years and it's treated as the red headed step child. Since the early 80s we accepted RAM upgrades. We accepted stereo pokeys. We accepted faster serial devices. We accepted parallel devices. We accepted CF cards not SCSI HDDs. Covox for 4-channel 8-bit audio. Atari released a garbage 80 column solution in the XEP-80. But god forbid, we have a device that gives us some better colours on screen. It's shunned as the worst thing ever. Why is this? Please - as an Atari user since the heavy-sixer of 1977 (which I still own) - why is the VBXE pretty much single handedly pointed out as the only 8-bit upgrade to get universally shit on? I implore you - try Sparta DOS X with Sparta Commander set up properly, and Last Word with VBXE drivers. It's still 8-bit Atari but "next generation".
    4 points
  25. Holy fuckin' shit! This is awesome!!! You are gonna sell a fuck ton of these if your plan is to share with the public.
    4 points
  26. Ladies and gentleman, the Pitfall Party (aka the Rumble in the Jungle)! In June of 1982, the summer CES was held in Chicago. To coincide with this event, and on the evening of June 7 at the Ritz-Carlton Hotel, Activision hosted the Pitfall Party to celebrate the release of the game. It took place in the hotel's grand ballroom and multiple adjacent ballrooms. There were three bands playing simultaneously, dozens of party-style midway games, several open bars, live animals in cages hanging from the ceiling and hundreds upon hundreds of attendees. It was rumored that Activision spent in excess of $250,000 on the party. Earlier in this thread, CPUWIZ posted a wonderful pic of the invitation package, which I'm reposting here. Attendees were given a safari jacket and an explorer's hat. Activision even printed Rumble in the Jungle matchbooks; attached is a picture of these three items. Activision employees also received the "Survival Kit" zippered pouch (pic attached). It contained a badge to get into the party, an Instamatic camera and coupons for the midway games. Thanks to Dan Kitchen for providing much of this information. By the way, Ken Uston, the infamous blackjack player, also attended the party. He wrote several books relating to blackjack and video games. I remember reading somewhere that he showed up with an exotic pet that he had. If I remember correctly, it was a pet monkey!
    3 points
  27. My advice would be to start with bite sized chunks of code. Pick a task or an action and the code that standalone. Understand how it works and experiment and then when you feel comfortable and have achieved your goal, add something else. Trying to create a magnum opus from the get go will be hard work. It's like picking up a paintbrush and deciding to paint the ceiling of the Sistine chapel without any previous paining experience - it's going to be a rough journey and will probably end up being overwhelming When I started learning 7800Basic, that was the approach that I took. I started figuring out concepts incrementally, each new little project or piece of code was to learn about a feature or element of the language. I started with things like sprites sprites and figuring out the limitations of banks and blocks. Then I moved the sprites, then I animated them, then I collided them, then I exploded them. Once I was happy I started the next learning chapter, maybe that's reading control inputs and combining that with moving a sprite, or maybe it's tiles and having sprite and tiles working together. Maybe that next part is learning about how logic works in the language, if..then..else, and..or etc and making decision in your code based on conditions. Eventually I strung those learning "chapters" together and started to make code that if you stood back 20 ft and squinted a bit, it looked a bit like a game. The concept here is this : start small and build. 7800Basic comes with a bunch of really good examples. Use them and tweak them until they break, figure out why and tweak them more. I learned a huge amount from the examples and experimenting with them.
    3 points
  28. I do find the smaller text actually easier to read.
    3 points
  29. Well I thought someone ought to do something like this? Put them up as a A3 sized poster - here's a first page of 72 pictures. I'll get around to doing another 3? pages as I have these images ready to be assembled. The order is probably not in any proper order because it's by filenames. It looks pretty good - don't recommend it in A4 - but who knows - it may still look OK? Thanks guys for the various images. Harvey
    3 points
  30. I only have two macrogroups: Group 1= the ones I own Group 2= the ones I don't own It makes life less complicated
    3 points
  31. I think we should start splitting the existing 97 games released in physical format (as of August 16, 2020) in macrogroups, like: 1. Originals Post 2000 AD (f.i. Maria, Old School, Ninja Odissey, Piggy Bank, the 2nd Sydney Hunter, Same Game & Robots, etc), 2. Hacks (f.i. Mystic Castle, Shark! Shark! 2, etc), 3. Unreleased Pre 2000 AD (f.i. Robot Rubble, Brickout, King of the Mountain, etc) and 4. Conversions of Classics (f.i. Missile Domination, Space Raid, Smurf, Minehunter, Ms. Pac-Man, Meteors, etc). We could do the same for the games released in ROM format only. After these preliminary operations, we could start making our own lists of favourites. Don't tell me I'm making it too complicated. Life is complicated
    3 points
  32. @TailChao Have you considered a Rikki & Vikki release for the EverCade handheld? — Perhaps if you struck a deal with other indie-developers, you could figure out a sort of collection of games to pack on a Cartridge, and still have revenue or get attention?
    3 points
  33. Funny, but something like that could work if you don't mind a possibly glitchy image until it gets figured out. My initial idea was to use a sprite with a logo for BUS, with one player as the object and one in the background behind the player. All collision registers are cleared before the graphic and on a working console, no collisions should be set afterward. Maybe with an audio cue and color change when testing passes. This could be done in multiple lines. Basically, it would try stuffing all bits low first. The sprite should be at least 8 lines high, and the background sprite would be something like this: .byte %10000000 .byte %01000000 .byte %00100000 .byte %00010000 .byte %00001000 .byte %00000100 .byte %00000010 .byte %00000001 The "main" sprite can be anything, as long as bits above are clear. Then, bus stuff the sprite for 8 lines and record collisions on each line. If any bits fail to stuff, collisions will be set and the failing bits can be recorded. For the main color, pick a high luminance, and a low luminance for the background sprite, but brighter than the background. The current BUS driver can stuff low or high on any bit. If stuffing low fails after a time, then you can try stuffing high. It would work like the above but with inverted graphics (could be transparent by swapping background and player colors.) Then, see if any of the low bits will work by stuffing high. The BUS driver can deal with up to two bits that fail to stuff so that alone should "pass" most consoles pretty quickly. To keep the driver simple, I will probably leave it up to the programmer to determine what bits to stuff low, what to stuff high, and what bits failed to stuff high or low. The bits failing to stuff, if any, would be specified in a mask register passed to the BUS driver so it can handle these bits in a different way. This way we can write the driver soon and let programmers sort out the best methods for stuffing detection later. Once the BUS driver is written, y'all can create these bit detection screens Shouldn't be too long...
    3 points
  34. I'd love an Atari 8/16 with an 65816 and VBXE in a classic style case like the Mega65. I'd buy it.
    3 points
  35. Nah. For me Next is pointless. Even VBXE or Rapidus. If want more colors or fast cpu, I have PC. If I want old computer, I have genuine old Atari. Even FPGA Atari seems pointless to me, PC emulators offer more features. I simply see no use for device like that.
    3 points
  36. In celebration of the lameness surrounding atari vcs I just ate plain tacos. A shell, minimal un-flavored beef, and a smattering of mild cheese. Nothing else!
    3 points
  37. Vocelli: 66626 Rescue Terra I: Thought I would like this one the most... but I don't. I have never been so angry at Mini-Saucers since Asteroids!!! Condor Attack: 6597 I enjoyed this one at the beginning... But the hit detection is unfair at times. I think I can beat this score. Espial: 15930 Enjoyed this one the most. 'OKAY one more time'... uttered these words many times today!
    3 points
  38. To hell with HSC. It will not be missed with such a robust offering of other features and abilities. This thing is awesome.
    3 points
  39. Apparently so, and certain shills are claiming this as some kind of awesome victory (happens when you've ran out of straws to grasp at).
    3 points
  40. So... let me get this straight... this guy's really impressed that a cheap PC can load an OS intended specifically for cheap PCs?
    3 points
  41. In case anyone's intelligence hasn't been insulted today, then I've got the article for you. It sounds like it was written by a bot that was forced to read through hours of posts on the VCS fan page.
    3 points
  42. As revealed on tonight's Zero Page Homebrew, Frantic has been reboot using CDFJ and now features speech using the AtariVox. Thanks to @Nathan Strum for his quick work on creating the AtariVox data for me, and thanks to @sramirez2008 for helping to playtest. Console Switches: TV Type = B&W, score display shows time remaining for Vertical Blank and Overscan. Time remaining has been significantly improved over the DPC+ version, which would jitter/roll the screen when there was lots of action. Left Difficulty A = Max Robot Stress Test. Score will be red and player does not lose a life (so can play forever). Right Difficulty A = Frenzy Special Room Test. Every room will be a special room. GAME RESET + GAME SELECT = Sound Tool. Frenzy Special Rooms are: Big Otto - will launch a swarm of Ottos if you shoot Otto Power Plant - shot it and robots stop moving. They can still shoot Central Computer - shoot it and the robots stop shooting, plus they'll move in random directions Factory - creates additional tank robots. Sound Tool: Phrase 0 is AtariVox "reset", so is silent Words 0, 23, and 24 are silent (0 = reset, 23 and 24 are different pause lengths) Pitch - adjusts pitch of both Phrase and Word Speed - adjust speed of both Phrase and Word. NOTE: some of the words are at, or close to, the max speed. Due to how the AtariVox works, if the speed is increased too much it wraps to a slower speed. Note: we missed a bug with Stealth mode that I'll fix next week. Note2: reflective walls mostly work, but at times a shot can get stuck in them. This occurs for the player's shots as well as the robots'. frantic_20200812.bin
    3 points
  43. It's not hard to ignore him at all; you and anyone else can simply add him to your list of "Ignored Users," which is exactly how that feature is intended to be used. If someone makes a comment in this thread or any other about the Amico, there's no rule which states that Tommy is not allowed to respond to it just because it was made outside of "his playground." We haven't singled out any other users here for that kind of unfair treatment. If the people in this thread don't want Tommy to come here to respond to comments about the Amico, keep the thread on topic and refrain from making comments about the Amico, and then he won't have a reason to do so. Seems simple enough to me.
    3 points
×
×
  • Create New...