Jump to content

Search the Community

Showing results for tags 'gcc'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Atari Systems
    • Atari General
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Atari VCS
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
    • Atari Portfolio
  • Classic Consoles
    • Classic Console Discussion
    • ColecoVision / Adam
    • Intellivision / Aquarius
    • Bally Arcade/Astrocade
    • Odyssey 2 / Videopac
    • Vectrex
    • Nintendo Entertainment System (NES) / Famicom
    • Super Nintendo Entertainment System (SNES) / Super Famicom
    • Sega Genesis
    • 3DO Interactive Multiplayer
    • Dreamcast
    • SMS High Score Club
    • TG-16/PC Engine High Score Club
  • Classic Computing
    • Classic Computing Discussion
    • Apple II Computers
    • TI-99/4A Computers
    • Commodore 8-bit Computers
    • Commodore Amiga
    • Tandy Computers
  • Modern Consoles
    • Modern Gaming Discussion
    • Sony Playstation 5
    • Xbox Series S/X
    • Atari VCS (Redirect)
    • Nintendo Switch
    • Microsoft Xbox One
    • Sony PlayStation 4
    • Microsoft Xbox 360
    • Sony Playstation 3
    • Nintendo Wii / Wii U
  • Gaming General
    • Gaming General Discussion
    • Arcade and Pinball
    • Emulation
    • Hardware
    • Prototypes
    • Gaming Publications and Websites
    • International
  • Marketplace
    • Buy, Sell, and Trade
    • Auction Central
    • Wanted
    • Free Games and More
    • User Feedback Forum
  • Community
  • Community
    • Events
    • Show Us Your Collection!
    • Member Blogs
    • High Score Clubs
    • Poll Forum
    • Contests
    • User Groups
    • AtariAge News Discussion
    • User Submitted News
  • Game Programming
    • Homebrew Discussion
    • Programming
    • Hacks
  • Site
    • Announcements
    • Forum Questions and Answers
    • AtariAge Store Discussion
    • Site and Forum Feedback
    • Rarity Guide
    • Archived Forums
  • PC Gaming
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Arcade Gaming's Discussion
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's CDFJ
  • Harmony/Melody's DPC+
  • Harmony/Melody's BUS
  • Harmony/Melody's CDFJ+
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching
  • The Green Herb's Discussions
  • Robin Gravel's new blog's My blog
  • Robin Gravel's new blog's Games released
  • Robin Gravel's new blog's The Flintstones Comic Strip
  • Atari Video Club's Harmony Games
  • Atari Video Club's The Atari Gamer
  • Atari Video Club's Video Game Summit
  • Atari Video Club's Discsuuions
  • Star Wars - The Original Trilogy's Star Wars Talk
  • PlusCart User's Bug reports
  • PlusCart User's Discussion
  • DMGD Club's Incoming!
  • DASM's General
  • AtariVox's Topics
  • Gran Turismo's Gran Turismo
  • Gran Turismo's Misc.
  • Gran Turismo's Announcements
  • The Food Club's Food
  • The Food Club's Drinks
  • The Food Club's Read me first!
  • The (Not So) Official Arcade Archives Club's Rules (READ FIRST)
  • The (Not So) Official Arcade Archives Club's Feedback
  • The (Not So) Official Arcade Archives Club's Rumor Mill
  • The (Not So) Official Arcade Archives Club's Coming Soon
  • The (Not So) Official Arcade Archives Club's General Talk
  • The (Not So) Official Arcade Archives Club's High Score Arena
  • Adelaide South Australia Atari Chat's General Chat & Welcome
  • Adelaide South Australia Atari Chat's Meets
  • Adelaide South Australia Atari Chat's Trades & Swaps
  • KC-ACE Reboot's KC-ACE Reboot Forum
  • The Official Lost Gaming Club's Lost Gaming
  • The Official Lost Gaming Club's Undumped Games
  • The Official Lost Gaming Club's Tip Of My Tounge
  • The Official Lost Gaming Club's Lost Gaming Vault
  • The Official Lost Gaming Club's Club Info
  • GIMP Users's Discussion
  • The Homebrew Discussion's Topics
  • Hair Club for Men's Bald? BEGONE!

Blogs

  • DJTekid's Blog
  • craftsmanMIKE's Blog
  • BinaryGoddess' Blog
  • EG's code blog
  • gorf68's Blog
  • Albert's Blog
  • kiwilove's Blog
  • Gnuberubs Sojourn Dev Journal
  • MegaManFan's Blog
  • 8 Bit Addiction
  • B
  • Ed Siegler's Blog
  • Playing With History
  • iesposta's Blog
  • Mallard Games Development Blog
  • FireTiger's Blog
  • simonh's Blog
  • Cool 'n' Crispy: The Blog of Iceberg_Lettuce
  • Regaining an Obsession
  • Atari Rescue Group's Blog
  • Zereox's Blog
  • ahuffman's Blog
  • EricBall's Tech Projects
  • Draconland
  • Bergum's Thoughts Blog
  • Psi-5
  • liquid_sky's Blog
  • chris_lynx1989's Blog
  • marminer's Blog
  • Cybernoid's Blog
  • Phuzzed's Blog
  • BubsyFan101 n CO's Pile Of Game Picks
  • The Atari Journals
  • Lost Blog
  • 7800 NZ's Blog
  • I like to rant.
  • Herovania
  • shep's Blog
  • Gamera's Reviews: E.T Coming Soon!
  • Cleaning up my 2600
  • TBA
  • Trey's Blog
  • Iwan´s Irrational!
  • AnimaInCorpore's Blog
  • Boo
  • seemo's Blog
  • Space Centurion's Blog
  • Bluejay Records Co.
  • Kepone's Blog
  • The Eviscerator Series
  • Coleco Pacman Simulator (CPMS)
  • Running On Fumes
  • Beware of Kiwi
  • Noelio's Blog
  • ianoid's Blog
  • Mozartkügel's Midnight Retro Development
  • Fun in the beer mines
  • 480peeka's Blog
  • HLO projects
  • PacManPlus' Blog
  • For Next
  • Retro Junky Garage
  • Alcadon
  • Atari 8-bit Moria port
  • Take 'Em To The Woodshed
  • Sega Genesis/Mega Drive High Score Club
  • baktra
  • Tim's Blog
  • bankockor Blog
  • Prixel Derp
  • Flojomojo's Simple Mind
  • Mindfield's Chewy-Centered Blog
  • Kelp Entertainment
  • HuckleCat's Blog
  • MarkO
  • The Long Dark Teatime of the Soul
  • 2600 Fun Blogs
  • AtariVCS101's Blog
  • Lazydead's Loose Ends
  • TP's Blog
  • PinBlog
  • Tales from the Game Room's Blog
  • OldSchoolRetroGamer's Bloggy Nonsense
  • Adam Sessler's Brutally Honest Blog
  • IHATETHEBEARS' BLOG
  • VVHQ
  • Magmavision After Dark
  • Jimmy Plaidjacket's Compu-Sonic Baseball
  • Atari Fan made Documentary
  • Antichambre's Blog
  • My Homebrew Devlog
  • None
  • Flashjazzcat's Blog
  • REMOVED BY LAW AUTHORITY
  • BUBSY Blogs [blank]
  • THE 1 2 P's Demo/Import/Gaming Blog
  • Synthpop Universe
  • Too young for Atari, too old for XBox
  • Atarinvader's Blog
  • STGuy1040's Blog
  • Atari 5200 Joystick Controllers
  • KC-ACE Blog
  • Atari 8-bit archiving
  • enyalives' Blog
  • Top 10 Atari 2600 Games
  • Brunobits' Blog
  • Mirage1972's Blog
  • Is Atari Still Cool?
  • Brown Altitude Bar
  • ATARIeric's Blog
  • blogs_blog_286
  • Buying Atari on Ebay
  • Bubsy TV Pilot Wiki
  • wrenchien's Blog
  • The Word Of Ogma
  • matosimi's Blog
  • Poltergeist
  • Trade-N-Games' Blog
  • GC's blog
  • GadgetUK's Blog
  • Projektstunde
  • nanobug's monument of geekiness
  • The StarrLab
  • bluejay's corner of random shit
  • wapchimp's Blog
  • dogcorn's Blog
  • Scooter83 aka Atari 8 Bit Game Hunters' Blog
  • SpornyKun
  • Shared Words
  • I Can't Think of a Catchy Title
  • Buddpaul's Blog
  • alex_79's Blog
  • Bastard's Blog
  • please help and share story
  • TheGameCollector's Blog
  • homerwannabee's Blog
  • ivop's Blog
  • Gamming
  • Atari Label Reproduction/ Relabeling
  • Haydn Jones' Blog
  • what is the chicago basment
  • Centurion's Blog
  • Ephemeral
  • The World According To Yuppicide
  • Cheat Blog
  • GunsRs7's Blog
  • My opinion and story about Atari 2600
  • How I did It
  • zeropolis79's Blog
  • DPYushira's Entertainment Blog
  • Sony PlayStation 5/PS5™ Development Kit (Dev Kit) for SALE
  • Buck's Blog
  • My video game library
  • JHL's Blog
  • atwwong's Blog
  • the.golden.ax's "Oh my Blog"
  • Intellivision Pierce's Blog
  • Delete
  • 1
  • ValuGamer
  • Manoau2002 Game and Vinyl Blog
  • Superkitten
  • sandmountainslim's Blog
  • wolfpackmommy's Blog
  • Diamond in the Rough
  • Doublediwn
  • Atari Jaguar Projects + More
  • Z80GUY's Blog
  • Linky's Blog
  • Reindeer Flotilla
  • StanJr's Blog
  • jwierer's Blog
  • flashno1's Blog
  • Intellivision hacks (.cfg files)
  • Schmutzpuppe's Blog
  • kroogur's Korner
  • Atari 2600 Lab
  • My Experience Learning 68k Assembly
  • Bullitt's Blog
  • Verbal Compost
  • jennyjames' Blog
  • My Atari Projects
  • panda_racer's Blog
  • Frizo's Collecting Adventure!
  • scrottie's Blog
  • Writing is hard
  • Inky's Blog
  • Old School Gamer Review
  • Draven1087's Blog
  • My Atari 2600 Collection
  • Lauren's Place
  • ...
  • Omegamatrix's Blog
  • Jodi C. Kirby's blog
  • DanBoris' Tech Blog
  • Rybags' Blog
  • MegaData Manifesto
  • Power outage a few days ago
  • atariauctions' Blog
  • BDW's Blog
  • Selling Atari on Ebay.
  • Planet Bob
  • tweetmemory's Blog
  • Unfinished Bitness
  • CSIXTY4.com
  • toptenmaterial's Blog
  • TI-99/4A Stuff
  • Robin Gravel's Blog
  • grafix's Bit Mouse Playhouse
  • eshu's blog
  • lestergame
  • S1500's Blog
  • LaXDragon's Blog
  • Duke 4ever's Blog
  • hackerb9's blog
  • GozAtari8
  • Atari Haiku Blog
  • EricBall's Tech Projects (PRIVATE)
  • Bio's Blog of Randomness
  • An7ron
  • MagitekAngel's Blog
  • Out of the Pack
  • glitch's Blog
  • I created this second blog on accident and now I can't figure out how to delete it.
  • Paul Lay's Blog
  • Coleco-Atari Era
  • keilbaca's Blog
  • Make Atari 2600 games w/o programming!
  • Kenfused's Blog
  • TestBot4's Blog
  • Rudy's Blog
  • Ralph3's Blog
  • Old School Gamer Review
  • kenjennings' Blog
  • nester's one star gaming
  • The Mario Blog
  • The Game Pit
  • Halt and Catch Fire
  • PShunny's Blog
  • lizard's Blog
  • Ezeray's Blog
  • Laner's Classic Gaming Blog
  • GideonsDad's Blog
  • Atari 2600 game maps
  • Page 6
  • GideonsDad's Blog
  • Crazy Climber Metal
  • keilbaca's rants
  • GideonsDad's Blog
  • Keith Makes Games
  • SirWilliam's Blog
  • Horst's Blog
  • A virtual waste of virtual space
  • Sony PlayStation 5/PS5™ Development Kit (Dev Kit) for SALE
  • Birdie3's blog
  • JIMPACK's Blog
  • TheHoboInYourRoom's Blog
  • xNeoGeo1982Blogx
  • MattG/Snyper2099's Blog
  • Blogpocalypse
  • Msp Cheats Tips And Techniques To Create You A Better Gamer
  • The Ivory Tower Collections 7800s
  • madmjennifer's Blog
  • simonl's Blog
  • Tursi's Blog
  • Incognito Atari 800 step by step pictorial install tutorial/guide including ATR swap button mod
  • Ablogalypse Now
  • creeping insanity
  • F#READY's Blog
  • Cree's Stories
  • Endless Quest
  • Sonic R's Blog
  • bow830
  • Testing
  • Greenious' Blog
  • CebusCapucinis' Blog
  • Gernots A500 game reviews
  • NeonPeon's (Mark W's) Adventures in programming for Vectrex
  • wookie's Blog
  • Syntax Terror Games
  • Byte's Blog
  • Stories from the -: ITC :-
  • Justclaws' Blog
  • NCN's Blog
  • The Atari Strikes Back
  • Gameboy & dress up games
  • VTAtari's Blog
  • A Wandering Shadow's Travels
  • no code, only games now
  • BRP's random dev journaling
  • SID CROWE TESTING THE blog softwareeee
  • Arjak's Blog
  • wongojack's Blog
  • Dutchman2000's Blog
  • 2600Lives' Blog
  • Lost Dragon's Blog
  • Famicoman's Blog
  • 2600Lives' Blog
  • Musings of the White Lion
  • scogey's Blog
  • Kiwi's Blog
  • The Usotsuki Crunch
  • Retro Gaming Obscuria
  • Stephen's A8 Blog
  • Gunstar's Blogs
  • atarifan49's Blog
  • Zero One
  • Lesles12's Blog
  • Chronogamer
  • Troglodyte's Blog
  • Atari Randomness
  • flavoredthunder's Blog
  • Austin's Blog
  • OLD CS1's Blog
  • Shernand's Blog
  • Robert Hurst
  • waterMELONE's Blog
  • Robert M's Blog
  • This Is Reality Control
  • Flickertail's Blog
  • albaki's Blog
  • Animan's Blog Of Unusual Objectionalities
  • Dexter's Laboratory Blog
  • BTHOTU's Blog
  • Devbinks' Blog
  • ATASCI's Blog
  • Zach's Projects
  • a1t3r3g0's Blog
  • ATASCI's Blog
  • BuzzTron-451's Blog
  • The 7800 blog
  • --- Ω ---'s Blog
  • The Occasional Coder
  • 4Ks' Blog
  • Joystick Lunatic Software on AtariAge
  • carmel_andrews' Blog
  • mourifay's Blog
  • Zander's Blog
  • iratanam's Blog
  • Zsuttle's gaming adventures
  • The randomness that is Mr. 8-bit/16-bit.
  • junkmail's RDE&P Blog
  • Doctor Clu's Space Shows
  • bluetriforce's Blog
  • Lynxman's FlashCard Blog
  • TWO PRINTERS ONE ADAM
  • ubikuberalles' Blog
  • JagMX's Blog
  • Atari Jaguar Game Mascots
  • Worm Development Blog
  • The Wreckening
  • Learning fbForth 2.0
  • Eight Bit's Blog
  • roberto's Blog
  • splendidnut's Blog
  • mos6507's Blog
  • Incagold's Blog
  • The Atari Jaguar Game by Game Podcast
  • phaxda's Blog
  • lost blog
  • Syzygy's Story Blog
  • potatohead's Blog
  • kurtzzzz's Blog
  • Atarian Video Game Reviews
  • Mountain King's Blog
  • Guitarman's Blog
  • Caféman's Blog
  • The Southsider
  • IainGrimm's Blog
  • The World is Flat?
  • Robert @ AtariAge
  • player1"NOT"ready's Blog
  • brianwolters' Blog
  • otaku's Blog
  • Alexandru George's Blog
  • Bidouille's Blog
  • otaku's Blog
  • BraggProductions' Blog
  • Zybex/Atariware Blog
  • revolutionika's Blog
  • XDK.development present Microsoft Xbox One Development
  • JagDiesel's Palace 2
  • thund3r's Blog
  • Song I Wake Up To
  • Sega_master's Blog
  • edweird13's Blog
  • Jeffrey.Shamblin's Blog
  • Deep into the Mind Game
  • edweird13's Blog
  • Important people who shaped the TI 99/4A World
  • Bob's Blog
  • That's what she said.
  • My blog of stuff and things
  • Rockin' Kat's Blog
  • Hitachi's Blog
  • David Vella's Blog
  • Push Me, Pullman
  • The (hopefully) weekly rant
  • Osgeld's Blog
  • (Insert stupid Blog name here)
  • Goochman's Marketplace Blog
  • CyranoJ's ST Ports
  • dgob123's INTV Blog
  • Marc Oberhäuser's Blog
  • InnovaX5's Blog
  • Random Terrain's Tetraternarium
  • Masquane's AtariAge Blog
  • Star_Wars_Collector
  • Odyssey Development Corner
  • satan165's Dusty Video Game Museum
  • Alp's Art Blog
  • Pacmaniax
  • lazyhoboguy's Blog
  • Excali-blog
  • GPD Comics Blog
  • Retail hell (The EB years)
  • STGraves' Blog
  • sergiomario's Blog
  • Vectrexer's Blog
  • Retro VGS Coleco Chameleon Timeline
  • prorobb's Blog
  • Game Maker to Game Dev
  • Geoff Retro Gamer
  • Days Atari Events
  • Retro Gaming Corporation
  • Geoff1980's Blog
  • gamester1's Blog
  • Hulsie's Blog
  • Coleco Mini
  • Shannon's Blog
  • Tr3vor's Blog
  • Coleco Mini
  • Mord's Blog
  • Dryfter's Blog
  • 7399MGM's Blog
  • liquidcross.com - blog
  • Why Are You Even Reading This?
  • 7399MGM's Blog
  • MIPS HEAVY INDUSTRIES
  • Xuel's Blog
  • doubledragon77's Blog
  • MayDay Today
  • GamingMagz
  • Ballblogɀer
  • javiero's Blog
  • travelvietnam's Blog
  • pitfallharry95's Blog
  • Great Exploitations
  • pacmanplayer's Blog
  • BawesomeBurf's Blog
  • Monster Angriff's Blog
  • TheLunarFox's Blog
  • Fultonbot's Atari Blog
  • Draikar's Blog
  • caver's Blog
  • Dmitry's Blog
  • Random Acts of Randomness
  • Atari 2600 for sale with 7 games 2 controllers
  • Kaug Neatos Crash Bandicoot Bandwagon
  • TROGBlog
  • A Ramblin' Man
  • lexmar482's Blog
  • hex65000's Blog
  • toiletunes' Blog
  • vegathechosen's Blog
  • Being Of The Importance Of Shallow Musing.
  • Justin Payne's Blog
  • Atari 2600JS
  • daclmi's Blog
  • ebot
  • Doctor Clu's Dissertations
  • 2600 in 2006
  • Markvergeer's Blog
  • schmitzi's Blog
  • Sayton's Blog
  • GEOMETRY WARS ATARI 2600
  • BNE Jeff's Blog
  • For whom it may concern
  • LEW2600's Blog
  • AverageSoftware's Development Blog
  • Osbo's Blog
  • Pac-Man Vs Puck-Man's Blog
  • FireBlaze's Blog
  • ataridude81's Blog
  • Bri's House
  • Atarimuseum.nl
  • Wiesbaden Gaming Lab
  • Les Frères Baudrand's Blog
  • Vorticon's Blog
  • SpiceWare's Blog
  • Secure Your E-Commerce Business With ClickSSL.com
  • TurkVanGogH GameZ's Blog
  • The Upward Spiral
  • raskar42
  • bow830's Blog
  • Web-Frickin'-Log
  • The P3 Studio
  • Arcade Attack - Retro Gaming Blog
  • Starosti 8bitového grafika
  • Bydo's Blog
  • MrRetroGamer's Blog
  • WWW.BUYATARI.TK
  • defender666's Blog
  • GG's Game Dev, Homebrew Review, Etc. Log
  • commodore & atari :)'s Blog
  • TheSSLstore - SSL certificates Validity
  • dazza's arcade machine games
  • Dusk2600's Blog
  • Chuplayer's Blog
  • Alcor450's Blog
  • GAMEBOT
  • pacman100000's Blog
  • The Outback
  • Lynx 20 years
  • POKEY experiments
  • -^CroSBow^-'s Hardware Videos
  • Songbird Productions
  • JPjuice23's Blog
  • Captain's Blog
  • SpaceInvader's Blog
  • Gary Mc's Blog
  • Memoirs of a Novelty Account
  • Retro point of view
  • arkade kid's Blog
  • newcoleco's Random Blog
  • VampyricDreams666's Blog
  • MaXStaR's Blog
  • Second-Hand Shop
  • le geek's nonsense
  • SUB HUNTER in A8
  • Doctor Clu's BBS Trotter
  • Hardcore's Nostalgia
  • ScumSoft's Blog
  • Lunar eclipse of the mind
  • 4old-times-sake's Blog
  • The Social Gamer
  • simon2014's Blog
  • shadow460's Blog
  • Ping. Pong. Ping. Pong.
  • PhilipTheWhovian's Blog
  • AtariJr's Blog
  • kgenthe's Blog
  • Troff the Shelf
  • Memoirs of an X register
  • mapleleaves' Blog
  • jacobus Indev
  • maximebeauvais' Blog
  • Dallas' Blog
  • Pac & Pal for the Atari 2600 fan project
  • atari2600land's Blog
  • bfg.gamepassion's Blog
  • drawscreen then reset
  • .:maus:.
  • Esplonky's Blog
  • Retrogaming Ramblings
  • PAM1234's Blog
  • Fashion Jewellery's Blog
  • G-type's Blog
  • Nabuko's Den
  • Gabriel's Blog
  • Blog o' Buttons
  • Paranoid's Blog
  • CJ's Ramblings
  • DarQ Massacres' Atari 2600 collection
  • Culmins Development's Blog
  • Dastari Creel's Blog
  • FireStarW's Blog
  • Atari Joe's Flippin' Sweet Blog
  • dobidy's Blog
  • Bobbety_F's Blog
  • When Robots Attack
  • dragging through the retro streets at dawn
  • Rose-Tinted Recollections
  • Flack's Daily Smack
  • Please Delete - Created by Accident
  • Young Guy Experiencing Atari
  • Jboypacman's Blog
  • Nerdbloggers
  • Gray Defender's Blog
  • neonesmaster's Blog
  • Algus' Blog
  • atasciiview
  • Classic Stories
  • Jadedrakerider
  • 2600 games worse then E.t
  • Bruce Tomlin's Blog
  • Appliciousblog.com
  • ZippyRedPlumber's Blog
  • Beetle's Blog
  • frederick's Blog
  • game_escape's Blog
  • 5-11under's Blog
  • longleg's Blog
  • Jackel192's Blog
  • EricDeLee's Blog
  • Brain droppings...
  • The UAV Blog
  • TunnelRunner's Blog
  • Sandra's blog
  • MykGerard
  • jaymz887's Blog
  • Bastelbutze
  • OS9Dude's Blog
  • fojy-harakiri's Blog
  • polo
  • FPGA video game console
  • Shroo-man's Blog
  • VectorGamer's Blog
  • darryl1970's Blog
  • Ataria51's Blog
  • Maybe its a Terrible Tragedy
  • Funkmaster V's Gettin' Hip with tha Atari 7800
  • Mr. Pac-Man's Blog
  • Guru Meditation
  • AtariMI1978's Blog
  • JellE's Dwelling
  • - - - - - -
  • AtariMI1978's Blog
  • Gaming With Rogmeister
  • The 12 Turn Program: Board Game Addiction and You
  • vidak's Blog
  • Pengwin's Blog
  • Tezz's projects blog
  • 8-bit Computer System Colors in Food Coloring
  • neotokeo2001's Blog
  • chonglily's Blog
  • WebSiteRing
  • Arcade's Blog
  • masseo1's Blog
  • The Best Assembly Computer
  • R. Jones' Blog
  • DCUltrapro's Blog
  • As time goes by ...
  • payman84ce's Blog
  • Disjaukifa's Blog
  • Atari 2600 Collection Bulk Box/ Cartridge Sale
  • Awed Thoughts
  • Vic George 2K3's Blog
  • T.R.A.S.H Blog
  • super mario 64 level editor
  • Whoopdeedoo
  • goodlasers' Blog
  • Christos' Blog
  • ge.twik's Blog
  • GauntletKing2878's Blog
  • atari_collector's Blog
  • DJT's High Score Blog [Test]
  • My Inner Geek
  • imtron's Blog
  • Disjaukifa's Assembly Blog
  • A Raccoon's Retrocade Romp - AA Edition
  • My Vintage Game collection
  • GonzoGamer's Blog
  • homeboy's Blog
  • classicgamingguy's Blog
  • MartinP's Blog
  • ThatAtomCat's Blog
  • HP Atari King of Michigan's Blog
  • marshaz's Blog
  • Hawk's Blog
  • Unknown arcade titles from Fighter17
  • Pandora Jewelry's Blog
  • Bryan's Random Stuff
  • Ain't got time for no Jibbajaba
  • Blues76's Blog
  • Developing Atari Programs on the Atari 800
  • Wickeycolumbus' Blog
  • Adam24's AtariAge Blog!
  • Eltigro's Blog
  • Ramblings of a moron
  • w1k's Blog
  • Memories Limited to 640KB
  • HatNJ's Blog
  • 8-bit-dreams' Blog
  • my journey to completing the entire Atari libaray
  • BlogO
  • Computer Help
  • Roblox
  • ELEKTROTECK
  • Chris++'s Blog
  • Question for Homebrew publishers
  • bf2k+'s Blog
  • an atari story
  • zilog_z80a's Blog
  • ParaJVE's Blog
  • JDRose
  • Return of the Bobcat
  • Cody Rushton's blog
  • raz0red's Blog
  • deepthaw's Blog
  • It's my life!
  • The Forth Files
  • Little bit of this and little bit of that
  • Bakasama's Blog
  • The Forth Files
  • Shannon's Blog
  • Dennis V's Blog
  • A.L.L.'s Blog
  • DoctorSpuds Reviews Things
  • RaRoss' Blog
  • Frankodragon's Blog Stuffs
  • Atari Portfolio Page On Facebook
  • Collecting Demos
  • Partyhaus
  • azure's Blog
  • Dave Neuman's Blog
  • kankan313rd's Blog
  • The Atari Kid
  • Borntorun's Blog
  • n8littlefield's Blog
  • Alien Isolation Blog
  • warren798's Blog
  • joshuawins99's Blog
  • Atari_Ace's Blog
  • Tweety's Blog
  • ¡Viva Atari!
  • AtariAdventure's Blog
  • -^CB^-'s Game Reviews
  • FujiSkunk's Blog
  • AtariCrypt
  • seekingarobiejr's Blog
  • The hunt for the PAL Heavy Sixer
  • acsabo's Blog
  • revival studios
  • Liduario's Blog
  • Bioshock Text adventure
  • bust3dstr8's Blog
  • kakpu's Blog
  • AtariAdventure Reviews
  • Rom Hunter's Blog
  • HSC Experience
  • Infinite Warfare Specialist
  • Shark05's Blog
  • people to fix atari Blog
  • Karl's Blog
  • Lord Helmet's Blog
  • Gronka's Blog
  • Bjorkinator's Babbles
  • ryanez1's Blog
  • Joey Z's Atari Projects
  • DZ-Jay's Random Blog
  • kit's Blog
  • cncfreak's Blog
  • CX40Hero's Blog
  • Burma Rocks
  • Ariana585's Blog
  • Heroes & Shadows Dev Blog
  • Bubsy Bobcat Fan Blog
  • 8BitBites.com
  • No Delete Button
  • Habaki's Blog
  • BrutallyHonestGamer's Blog
  • GoldLeader's Blog
  • Dan's Road to 2600 nirvana
  • falcon_'s Blog
  • Adventures in CC65
  • wccw mark's Blog
  • lushgirl_80's Blog
  • CS2X C# on Atari
  • Hornpipe2's Blog
  • Lynx Links
  • pboland's Blog
  • Phantom's Blog
  • bomberpunk's Blog
  • Matts's Blog
  • Piggles' Blog
  • CorBlog
  • orrko8791's Blog
  • Dino Dash Derby
  • My Ideas/Rants
  • orrko8791's Blog
  • games_player's Blog
  • quetch's Blog
  • Revontuli's Blog
  • 1982VideoGames' Blog
  • jamvans game hunting blog
  • Not Steve's Blog
  • Cabbage Patch Kids! Lookin' Great!
  • CannibalCat's Blog
  • Not Steve's Blog
  • Confessions of an Aging Gamer...
  • jakeLearns' Blog
  • SPACE ROANOKE
  • theking21083's Blog
  • DSC927's Blog
  • My life
  • retrogeek's Blog
  • jetset's Blog
  • skycop's Blog
  • Liveinabin's scribbles
  • wibblebibble's Basic Blog
  • cessnaace's Blog
  • Cimerians' Blog
  • retrovideogamecollector's Blog
  • Omegasupreme's Blog
  • CollectorVision Blog
  • Sonny Rae's Blog
  • Atari 2600 A/V Mods Wiki
  • Ransom's Random Posts
  • The Golden Age Arcade Historian
  • Mike Harris' Blog
  • www.toyratt.com's Blog
  • dianefox's Blog
  • Skwrl63's Blog
  • RonPrice's Blog
  • DOMnation's Blog
  • s0c7's Blog
  • segagamer99's Blog
  • sometimes99er
  • doyman's Blog
  • RickR's Blog
  • IntellivisionRevolution's Blog
  • Atari BBS Gurus's News
  • On Duty's Blog
  • The official Robin Gravel's club's Archive
  • Bowling's Blog
  • Lawnmover's Blog
  • Cental Texas Retro Computer Society's Welcome
  • KC-ACE Reboot's KC-ACE Reboot Blog
  • Wizzy's Concept and Theme
  • Wizzy's Form
  • Wizzy's Moodboard
  • Wizzy's Space
  • Wizzy's Magical objects
  • Wizzy's Progress
  • Wizzy's At home
  • Wizzy's Halloween
  • Wizzy's Equipping
  • Wizzy's Mentor
  • Wizzy's World
  • Wizzy's Trials
  • Wizzy's Characters

Calendars

  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website


Facebook


Twitter


Instagram


YouTube


eBay


GitHub


Custom Status


Location


Interests


Currently Playing


Playing Next

Found 11 results

  1. I'm not sure how useful this is going to be to anyone out there, but thought I'd share nevertheless... For another project I'm working on (or rather, playing around with...), I kept running into the issue that there is no support for malloc(), free() and the likes when using tms9900-gcc. Of course, since we're all rockstar programmers, and we all know which memory is used in our programs at all times, we'd rather do it manually since that's going to be the most efficient. But sometimes it's just more convenient to have all of that automated, right? So I've written a reusable malloc implementation that tries to be very memory efficient (it only introduces 1 word of overhead to keep track of the heap) and I believe is quite feature complete. It does sacrifice speed for memory efficiency, but on our platform I think that is the probably the most logical choice anyway. I have not tested this much beyond my other project and the simple test program that comes with it, but it does seem to work reliably so far. Feel free to play around with it and let me know if there's anything you'd do differently. https://github.com/themole-ti/libmalloc99
  2. And this time so does everybody else!
  3. Hello, Since PLATOTERM is licensed under the GNU Public License, I have written a piece of accessory software that opens, and displays a copy of the GNU Public License 3.0 from a file. The TIPI version loads this from the web, courtesy of the PI.HTTP level 3 interface, which is very nifty. I do think that the dsr_xxxx functions here should be folded into libti99, but this is something that @tursillion may want to think about... Thanks to jedimatt42 for these functions, which I pulled from TIPICFG's source code. I have uploaded it to github, if you want to use it: https://github.com/tschak909/platoterm99-gpl You can run the program if you have a TIPI: CALL TIPI("PI.HTTP://TI99.IRATA.ONLINE/COPYING") And for the purposes of discussion, I am posting the code here, as well: #include <files.h> #include <string.h> #include <system.h> #include <conio.h> #define VPAB 0x3000 #define FBUF 0x3200 int force_quit=0; unsigned char dsr_openDV(struct PAB* pab, char* fname, int vdpbuffer, unsigned char flags); unsigned char dsr_close(struct PAB* pab); unsigned char dsr_read(struct PAB* pab, int recordNumber); void initPab(struct PAB* pab) { pab->OpCode = DSR_OPEN; pab->Status = DSR_TYPE_DISPLAY | DSR_TYPE_VARIABLE | DSR_TYPE_SEQUENTIAL | DSR_TYPE_INPUT; pab->RecordLength = 80; pab->RecordNumber = 0; pab->ScreenOffset = 0; pab->NameLength = 0; pab->CharCount = 0; } // Configures a PAB for filename and DV80, and opens the file unsigned char dsr_openDV(struct PAB* pab, char* fname, int vdpbuffer, unsigned char flags) { initPab(pab); pab->OpCode = DSR_OPEN; pab->Status = DSR_TYPE_DISPLAY | DSR_TYPE_VARIABLE | DSR_TYPE_SEQUENTIAL | flags; pab->RecordLength = 80; pab->pName = fname; pab->VDPBuffer = vdpbuffer; return dsrlnk(pab, VPAB); } unsigned char dsr_close(struct PAB* pab) { pab->OpCode = DSR_CLOSE; return dsrlnk(pab, VPAB); } // the data read is in FBUF, the length read in pab->CharCount // typically passing 0 in for record number will let the controller // auto-increment it. unsigned char dsr_read(struct PAB* pab, int recordNumber) { pab->OpCode = DSR_READ; pab->RecordNumber = recordNumber; pab->CharCount = 0; unsigned char result = dsrlnk(pab, VPAB); vdpmemread(VPAB + 5, (&pab->CharCount), 1); return result; } void main(void) { struct PAB pab; set_text(); charsetlc(); clrscr(); bgcolor(COLOR_CYAN); textcolor(COLOR_BLACK); gotoxy(0,0); unsigned char ferr = dsr_openDV(&pab,"PI.HTTP://TI99.IRATA.ONLINE/COPYING.TXT",FBUF,DSR_TYPE_INPUT); if (ferr) { cprintf("Could not open License from web."); for (; {} } int i=0; unsigned char ch; while (ferr == DSR_ERR_NONE) { unsigned char cbuf[81]; ferr = dsr_read(&pab,0); if (ferr == DSR_ERR_NONE) { vdpmemread(FBUF,cbuf,pab.CharCount); cbuf[pab.CharCount]=0; cprintf("%s",cbuf); } if (i>4) { i=0; cprintf(" \r\n"); cprintf(" -- PRESS ANY KEY TO CONTINUE -- "); ch=cgetc(); clrscr(); } else { i++; // Get next record. } } cprintf(" \r\n"); cprintf(" END OF LICENSE. PRESS ANY KEY TO QUIT. "); ch=cgetc(); ferr = dsr_close(&pab); } Hope it is useful. -Thom
  4. In trying to come up with a strategy to win back memory for Alex Kidd, I was thinking about stuffing some code in a cartridge, so I can win back some of that 32kb expansion memory. Given that I'm currently already at nearly 16k of executable code (including constants), and that I still need to add a good number of features, I need to find a way to create bank switching software with gcc. What follows is a write-up of my ideas, not everything has been tested, and I'm looking for a sanity check: will this work, am I missing something that could simplify things? 1. Multiple pieces of code at the same location The first thing we need to do when hacking support for banked memory (such as bank switched cartridges) in gcc, is to tell the compiler that specific pieces of code will run from the same physical address space. In the case of a program designed to run from cartridge, this would be 0x6000. By default, gcc will put all executable code into a section called .text, and you can tell the linker to position this code at any location in memory by using command line options (--section-start .text=0x6000), or by creating a bespoke linker script and adding a properly configured SECTIONS section: SECTIONS { . = 0x6000; .text : { *( .text ) } . = 0xa000; .data : { *( .data ) } .bss : { *( .bss ) } } (Note: the above example requires a system with 32k memory expansion installed, since it puts all variables in expanded memory. It also requires a crt0 implementation that copies the initialization values for variables in the .data segment from somewhere in ROM or from disk to 0xa000) Since all code is in the .text segment by default, the linker will just start filling up memory with code from 0x6000 onwards, blasting past 0x7fff if the code segment happens to be larger than 8k and in the process creating a useless image for our purposes. At the very least, we can define our memory layout in the linker script to get a warning when one of our blocks exceeds the maximum size. We can do this by adding a MEMORY section to the linker script (there's no command line equivalent of this), and changing the SECTIONS section accordingly: MEMORY { cart_rom (rx) : origin=0x6000, length=0x2000; /* cartridge ROM, read-only */ lower_exp (wx) : origin=0x2080, length=0x1F80; /* 8k - 128 bytes */ higher_exp (wx) : origin=0xa000, length=0x6000; scratchpad (wx) : origin=0x8320, length=0x00e0; /* 32b is for workspace */ } SECTIONS { . = >cart_rom; .text : { *( .text ) } . = >higher_exp; .data : { *( .data ) } .bss : { *( .bss ) } } Now, whenever the .text section exceeds 8k, the linker will throw an error and abort. At least we'll know our program is too big to fit in the 8k, but it would be even better if we could stuff more code in other parts of memory. Unfortunately, ld will not do this for us, and we'll need to explicitly assign code to different sections in our source files by adding attributes to the function definitions. Supposing we already have filled our 8k of cartridge ROM, we could for instance decide to put additional functions in the lower 8k of the 32k memory expansion. First we add the section attribute to each function we want to put in the lower memory expansion area: void somefunction(int somearg) __attribute__ ((section ( .moretext ))); void somefunction(int somearg) { // some code } We now have code that will get put in the .moretext section, so we need to tell the linker where to put this code (assuming the same MEMORY section as in the example above): SECTIONS { . = >cart_rom; .text : { *( .text ) } . = >lower_exp; .moretext : { *( .moretext ) } . = >higher_exp; .data : { *( .data ) } .bss : { *( .bss ) } } (Note: again we need to remember that the cart will need to load the contents of section .moretext from somewhere in ROM or from disk and copy it to the lower memory expansion at 0x2080) In theory, we could automate the annotation of functions by doing two compilation passes: one with all code in the standard .text segment to discover the size of each compiled symbol, and one that uses that info to assign individual functions to the two available sections. In practice, I imagine this is doable enough by hand for most programs. Also, on our platform gcc doesn't seem to support calculating the size of individual compiled symbols, so by hand it is. So now we are able to put code into two different physical locations in the TI's memory, but that still doesn't allow for bank switching. As we said at the very beginning, for that we need to tell the linker that two or more sections of code need to target the same memory area. Turns out that we can do this with the OVERLAY command: SECTIONS { OVERLAY >cart_rom : AT 0x0000 { .text { *( .text ) } .moretext { *( .moretext ) AT ALIGN(0x2000)} } OVERLAY >higher_exp : AT ALIGN(0x2000) { .data : { *( .data ) } } .bss : { *( .bss ) } } Running the linker with a script with the above SECTIONS section will give us a binary that contains three 8k banks: .text, .moretext and .data (we ignore .bss, because those are just zero-initialized variables and are taken care of by our crt0 implementation). The code in the first two banks will expect to run at 0x6000, and expects to find the initialized data from the .data section at 0xa000. Given all this, we should be able to generate binaries in the right format to support bank switching. 2. Actually switching banks in code That was the easy part, after all, it didn't require any coding . However, the trickiest part to bank switching is to write code that can cope with switching from one bank to another (and have that new code return). There are a couple of ways to do this (some more cumbersome than others), but they will all share a common requirement: you need to keep a "bank switching stack" (for lack of a better term). That is to say, when code in bank 1 calls a function in bank 2, we need to save the return bank "location" (i.e. what enables "bank 1") somewhere. If that function in bank 2 then in turn calls a function in bank 3, we need to do the same thing without overwriting the first return bank location. This is a recursive problem, so we need a stack. The idea location for the bank switching stack seems to be in scratchpad, since it will be relatively small and that part of memory is always available. By putting the pointers to this stack in a separate section, we can use the linker script to put it there (or wherever else is convenient). The management of the stack needs to be done right before calling a function in another bank, and right before returning to the calling bank at the end of a function. On a select number of platforms, GCC supports so-called 'far' and 'near' pointers and/or function attributes, which could be used to implement two different function prologues/epilogues depending on the type of function call that needs to be done. Unfortunately, the tms9900 platform implementation does not support these attributes. GCC also has support for instrumenting each function call and return via the -finstrument-functions command line option. You need to implement your prologue and epilogue code in the following two functions somewhere in your code: void __cyg_profile_func_enter (void *, void *) __attribute__((no_instrument_function)); void __cyg_profile_func_exit (void *, void *) __attribute__((no_instrument_function)); However, the call to and return from __cyg_profile_func_enter happens /before/ the call to the actual function, so it would take some serious wrestling with the C call stack to transparently implement bank switching in these functions. Our last option is to instrument individual functions and function calls. This is certainly the most cumbersome implementation of all, but it is the only one which does not need embedded support in the compiler implementation itself. Instrumentation of the function call is relatively easy, keeping in mind that all manipulation of the bank switching stack needs to be done from within the calling bank and the absolute last command needs to be the one that triggers the switch to the next bank. The following process could be a usable implementation: The caller (code runs in bank 1): Writes the address and bank location of the intended callee in two registers (e.g. r0 and r1) Invokes the trampoline The trampoline (code runs in scratchpad/expmem): Saves the current bank on the bank switching stack Loads the new bank Makes the call using the info in (e.g.) r0 and r1 The callee (code runs in bank 2): Does stuff Returns to the trampoline The trampoline (code runs in scratchpad/expmem): Loads the original bank (which is popped from the bank switching stack) Returns to the caller Or, in other words, every function call should be structured as follows: caller calls trampoline(), trampoline calls callee, callee returns to trampoline, trampoline returns to caller. Using this type of construct, the trampoline function needs to transparently pass on all arguments to the callee. The easiest way to accomplish this is the have a bespoke trampoline function for each "far" function we're looking to call (with a "far" function being any function that runs from a bank switchable piece of memory). Something like the following example: // Our "far" function, in bank 2 int far_somefunction(int someint) __attribute__ ((section ( .bank2 ))); int far_somefunction(int someint) { // do something return somevalue; } // Our trampoline function, in non bankable memory (e.g. scratchpad) int somefunction(int someint) __attribute__ ((section ( .nonbankable ))); int somefunction(int someint) { // Set to bank 2, and push caller's bank on the stack push_bank(2); // Call far function retval = far_somefunction(someint); // Set caller's bank pop_bank(); return retval; } Using this, we can safely call somefunction() (our trampoline function for far_somefunction()) from anywhere in our code, no matter which bank we're currently in and no matter where the calling code resides in memory. Furthermore, we can also still call far_somefunction() directly from within the same bank if we want to avoid the overhead of the bank switching and the trampoline function. The big downside of course is that we now have one trampoline function for every "far" function we want to call, all with nearly identical function bodies, eating at our available non-bankable memory. Not a big deal if you plan on banking code in big chunks, but problematic if you have lots of little functions that you need to call from everywhere in your program. We could opt to create one generic trampoline function, using variable argument lists and function pointers, if we're really strapped for memory. The downside is that it would create even more overhead for every "far" function call you're looking to make. Even with bespoke trampoline functions for each far function, it's a good idea to limit the number of bank switching calls you need to do, especially if you're writing an action game that needs to retain a high frame rate, given the fairly high overhead the bank switching introduces. If the compiler had support for naked functions (functions without prologue and epilogue), we could probably reduce the overhead to an absolute minimum, similar to what you'd get with pure assembly code, but unfortunately gcc doesn't support that attribute on our target. I think the above is a sound strategy?
  5. I wasn't sure whether I should post this under the existing GCC thread or start a new thread. I'm putzing around with GCC and I think I may have found another bug when doing multiplies. From what I can tell there have been fixes for other multiply bugs. This may or may not be related. My environment: Fedora 25 Linux GCC 4.4.0 with the tms9900 1.14 patches I recall having an issue when running Insomniac's installer - there were some directories that the install was expecting to be there but weren't... All I did was create those directories and ran the installer again. Everything seemed to work fine. I don't know if this is relevant to my issue, but just putting it out there. So on to the code. I have two versions of a function that does a simple calculation using some input parameters. The first takes all required params and uses them to perform the calculation. This version works just fine: unsigned int get_vdp_addr_inline(int width, int row, int col) { return row * width + col; } Code that calls the above: unsigned int addr_inline = get_vdp_addr_inline(32, 1, 0); And now onto the buggy version. In this version the width is stored in a struct. The pointer to the struct is passed into the function instead of the width: typedef struct { int width; int height; int foo; int bar; } test_rect; unsigned int get_vdp_addr_struct(test_rect* rect, int row, int col) { return row * rect->width + col; } Code that calls the above: test_rect rect; rect.width = 32; rect.height = 24; rect.foo = 0; rect.bar = 0; unsigned int addr_struct = get_vdp_addr_struct(&rect, 1, 0); Like I said this version doesn't give me the correct result. In debugging it with Tursi's classic 99, I see the following assembly generated for the second version of the function above. I added some comments about what it is doing. ; Some memory locations: ; *0000: 83 E0 00 24 83 C0 09 00 ...$.... ; *3FF2: 00 20 00 18 00 00 00 00 . ...... ; Initial conditions when the function is called: ; R1 (3FF2) is the pointer to "rect" ; R2 is "row" param ; R3 is "col" param ; R1 == 3FF2, R2 == 0001, R3 == 0000 61FA C042 mov R2,R1 ; R1 == 0001, R2 == 0001, R3 == 0000 ​ ; The above move instruction just blasted the "rect" pointer... this will not work. 61FC 3851 mpy *R1,R1 ; R1 == 0000, R2 == 83E0, R3 == 0000 ​ ; This multiply does not make sense. ​ ; Seems to be using the wrong registers. 61FE C042 mov R2,R1 ; R1 == 83E0, R2 == 83E0, R3 == 0000 6200 A043 a R3,R1 ; R1 == 83E0, R2 == 83E0, R3 == 0000 6202 045B b *R11 ; return to caller, INCORRECT result in R1 In case it's relevant, these are the GCC / Linker flags I am using: C_FLAGS=\ -O2 -std=c99 -s --save-temp -fno-builtin -Wall -Wstack-protector LDFLAGS=\ --section-start .text=6000 --section-start .data=2000 To me, it looks like a bug in the compiler output; however, it is possible it's some kind of user error. Hopefully Insomniac will see this at some point. I think my workaround for now is to hand code some assembly in place of the buggy function.
  6. Hi All, I've found some more time to work on my Alex Kidd port. I manually converted one of the original games' maps to a format that is compatible with my scrolling routines. Naturally, I lost quite a bit of detail, but the end-result isn't too bad. This is what the original looks like: And this is what the same map looks like on the TI: I had to move some blocks around, or remove some blocks to avoid color clash(can't have two different colored blocks directly next to each other), but all-in-all, most of the details are there. I also originally did a very nice conversion of the cave the old man is sitting in at the end, but I ran out of patterns and had to ditch both that and the clouds. I'm thinking of adding it in a static screen that gets tagged onto the end of the map, but those are details for later. Either way, I'm only using some of the original game maps to test playability and will probably design my own at some stage (so it'd be a sequel/prequel instead of a direct port), so I'm not sure how important those issues are. Next up, I started working on real collision detection and fine-tuning the physics to be a bit more in line with the original game. Seems to be working well, although I still need to add a collision check for the top of the sprite (you could jump into one of the blocks now and get stuck if you really try). Next up: finish the collision detection routines, find a way to make Alex face the other direction and implement punching. Also, add the jumping and punching sound effects. After that, I'll need to figure out how to make the blue blocks and the gold boxes destructable in the scrolling data... punching and destroying blocks is kinda the main mechanic of the game . It should be doable, but it will be quite convoluted as I have to decide which patterns to put in place depending on the object on the other side of the block. Finally, here's a video recorded in MESS. Normal caveats apply: youtube makes it a bit more choppy than the real thing, and of course the colors are a bit more washed out here. *edit* The latest work-in-progress version is attached to this post for those that are interested in trying it out. Latest version is from august 24th, 11pm CET. alexkidd.dsk
  7. Indeed. So which version do you prefer and why? And how would an optimal, "best of both worlds" version look like? The linked AtariProtos website already shows a nice comparison and list of difference details. And I can add more: The mushrooms in the GCC protos require only 3 shots to be eliminated. Atari's version and the arcade require 4. The controls in the GCC proto suck, because they are not responsive enough. While the GCC player looks nicer, its movement is much coarser than the Atari version ...what else...? BTW: Please ignore are technical flaws of the GCC prototypes, I am pretty sure those can be fixed.
  8. This started as an attempt to fix the major problems of the game before converting it to Trak-Ball controls. But it turned out, that those problems are not easy to fix (maybe one reason why this got abandoned?), so I decided to publish my results here and continue with something else. Maybe someone else eventually wants to pick up where I left... Millipede_GCC_004.zip
  9. Hello, For the people using the Windows environement, I've found a Perl script to fix an issue when working with GCC and Visual Studio (2013 Express in my case). The problem came from the format error reporting between GCC and VS, there are not compatible so we can see the error messages in the VS Output window but we cannot interact with them. So, you have to look manually for the line(s) and file(s) to see the errors. This script takes the output produced by a batch file and converts the error messages. The following line has to be added in the NMake section of your project configuration properties for the : Build, Rebuild All, and Clean Command Line. build.bat 2>&1 | c:\Perl\bin\perl.exe gccfilt.pl The Zip file contains the script and a screen capture from VS. I'm not the author of the script and the original link is here : http://www.codeproject.com/Articles/370890/GCCFilter-A-script-for-compiling-with-GCC-in-Visua Thanks, gccfilt.zip
  10. After seeing Rasmus's great work, I decided I wanted to start working on my own smooth scrolling games for our beloved TI. Initially, I was set on using the F18A for the scrolling functionality, but alas... since I don't have a hardware setup right now and no current emulator supports the thing's scrolling registers I'm stuck with the good ol' tms9918a (for now). Since I'm lazy by nature and I didn't feel like programming a whole game in assembly, I couldn't use Rasmus' excellent scrolling example code and had to re-implement it in C. I also didn't want to spend too much time transforming the assembly output from Magellan into something directly usable from C. I looked at adding a C exporter to Magellan, but the export .java source file alone was so daunting I decided to write my own tool to generate the scrolling patterns. Since I prefer to work in The Gimp to create the level, I wrote a simple command line program that takes a 16-color bitmap file that represents the scrolling map and generates a C header file with the pattern, color and nametable data (graphics mode only, for now). Maybe I'll look at turning this into a Gimp export filter at some point. For those that are interested, the simplest horizontal scrolling C application that uses the exported header file is only 100 lines of code and looks something like this: // Includes #include "libti99/vdp.h" // Tursi's libti99, VDP functions #include "tistdio.h" // Quick set of functions for keyboard scanning #include "level.h" // Generated header file containing map data #define SIT1 0x01 #define SIT2 0x03 #define CT 0xFF // copy 8 pattern tables into VDP RAM void init_patterntables() { int frame = 0; // Write 8 pattern tables to VDP memory vdpmemcpy(0x800 * frame, patt_frame0, 768); frame++; vdpmemcpy(0x800 * frame, patt_frame1, 768); frame++; vdpmemcpy(0x800 * frame, patt_frame2, 768); frame++; vdpmemcpy(0x800 * frame, patt_frame3, 768); frame++; vdpmemcpy(0x800 * frame, patt_frame4, 768); frame++; vdpmemcpy(0x800 * frame, patt_frame5, 768); frame++; vdpmemcpy(0x800 * frame, patt_frame6, 768); frame++; vdpmemcpy(0x800 * frame, patt_frame7, 768); } // Copy colortable to VDP RAM void init_colortable() { // Init the first two black, the third one gray vdpmemcpy((CT * 0x40), colortable, 13); } void init_nametable() { int x, y; for (x = 0; x < 32; x++) for (y = 0; y < 24; y++) vdpmemcpy((SIT1 * 0x400) + (x + (y * 32)), &(map[y][x]), 1); } void copy_pattern_block(int col, int frame, int backbuffer_sit) { int row = frame * 3; col++; vdpmemcpy((backbuffer_sit * 0x400) + (row * 32), &(map[row][col]), 32); row++; vdpmemcpy((backbuffer_sit * 0x400) + (row * 32), &(map[row][col]), 32); row++; vdpmemcpy((backbuffer_sit * 0x400) + (row * 32), &(map[row][col]), 32); } int main(int argc, char *argv[]) { int x, prev_x; int frame, backbuffer_sit; // Init graphics system x = set_graphics(1); VDP_SET_REGISTER(VDP_REG_MODE1, x); VDP_SET_REGISTER(VDP_REG_PDT, 0); VDP_SET_REGISTER(VDP_REG_CT, CT); VDP_SET_REGISTER(VDP_REG_SIT, SIT1); VDP_SET_REGISTER(VDP_REG_COL, 0xF1); init_patterntables(); init_colortable(); init_nametable(); prev_x = x = 0; backbuffer_sit = SIT2; while(1) { // Scan keys and do movement // scan_keys(); // UP/'E' pressed, move forward if (check_key(2,0x4000)) x++; frame = (x) % 8; if (x != prev_x) { // Move backbuffer to front and vice-versa if (frame == 0) { VDP_SET_REGISTER(VDP_REG_SIT, backbuffer_sit); backbuffer_sit = (backbuffer_sit == SIT1) ? SIT2 : SIT1; } // Advanced frame 1 pixel (aka move pattern descriptor table pointer one position up) VDP_SET_REGISTER(VDP_REG_PDT, frame); // Write 3 rows of the next full frame to the backbuffer // Depending on frame this is either 0-2 (frame 0), 3-5 (frame 1), 6-8 (frame 2), ... copy_pattern_block(x >> 3, frame, backbuffer_sit); if (x > 1016) x = 0; prev_x = x; } } return 0; } Project files, FIAD file and disk image attached for those who want to see it in action (EA#5, ALEXKIDD). The generated code is in level.h and is untouched, what you see is what the tool generated. I tried making a video, but the result looked anything but smooth. If you want to run it in an emulator, I suggest MESS as Classic99's timing is a bit off and makes it look a bit jittery. As you'll see, it runs quite fast as-is, but I'm sure there's room for improvement as this is completely unoptimized code. I'll make the tool available soon as well, but I need to clean it up a bit before it's fit for public consumption. I also need to add a binary file export function, 'cause the C header files are actually way too memory hungry for any practical use. In the future I hope to also add up-down and bitmap mode export functionality. Currently it just does what I needed it to do, and that's it. csmoothscrolling.zip
  11. I've scoured the web and the AA archives and I can't seem to find any schematics for the 7800 Maria. I'm referring to logic diagrams for the chip itself, not the 7800 motherboard. These do seem to exist for TIA but I can't find any for the Maria. Does anyone know if they even exist? Surely GCC must have had to conceptualize the internal logic of the chip at some point during development, right? The reason I ask is because I'm working on a hardware project for the 7800 and I've hit a point where I fear the only way to proceed forward will likely be to attempt to replace the Maria chip with an equivalent. This has already been done with TIA but I have yet to see this done with Maria. If anyone has any information at all, it would be greatly appreciated.
×
×
  • Create New...