Leaderboard

Hello, me and my friends are working on new big 1Mb cart modern adventure game for 8bit Atari XE (64kb, stereo). There are more than 50 screens by PG, more than 30 minutes of adaptive soundtrack and great post-apocalyptic story by Poison. Great code by Fandal. It is new age adventure with huge atmosphere and many story text to read? Prepare for new gameplay experience. ST Mouse supported ! Vortador Games (c) 2022. I hope game will be done in fall 2022. Game will be available as 1Mb rom/car file digital download and may be limited cart edition. https://www.youtube.com/watch?v=3oNEE1x5eaU

Having seen that this book was not present with a good scan anywhere, this has been done so, with the help of another enthusiast, Richard Porter (from UK), all 30 games contained in the book were also transcribed and published. All is downloadable following the link Hope you will appreciate the work. DOWNLOAD THE BOOK AND PROGRAMS

Hungry for something new? Ok, here's my 8-bit port of the 1982 Telesys 2600 game "Fast Food." Something other than Activision ports for a change... I just finished this up, and I think it's working pretty well. All testing appreciated... This was ported in an EXTREMELY direct way, using P/M sprites and nothing else, no DMA, no playfield, no fonts or anything beyond PMG. It uses my '48 Pixel Kernel' idea on the 8-bits for the score display and the vertical scrolling messages. I think it's the first and only 2600 game to be ported to the 8-bit machines in that way... Specifically, it uses the 4 "Player" sprites, and the "Missile" sprites combined as 5th, and then re-uses a precisely timed "Player 0" twice on the same scanline for a total of 6 8-bit-wide sprites. This re-creates the "48px" thing so common on the 2600... Almost 'racing the beam' style, sort of... NTSC 8K cartridge image only for now. This uses a lot of colors, so a PAL color version will probably come later. Please play-test and post if any problems or issues are found, thanks! Fast Food [NTSC].car

Not every game needs to be ARM-assisted. I think it is excellent as-is, personally.

Spotted your problem right here. After your stupid high TV and phone bills, you're down to about $200 a week to eat, get your meds, fuel your car, wipe your ass, drink/smoke/get high/whatever. There is zero room for expensive new toys in there. You buy, what, two of those cartridges, and that's half a week's living money gone right there. You planning on eating half as much the week you do that? You planning on taking half your meds, or walking to work, or not wiping your ass? No, what you'll end up doing is consuming just as much as you normally would, buy the toys you can't afford, and uh-oh; when the bills come due, we're off to the payday loan place again, and then yuck be back on here singing the blues hoping somebody bails you out again. You're essentially living off of the charity of others. I don't begrudge you getting it, but it's charity, and for you to take it, piss it away on nonsense, go around hat-in-hand wanting people to help you out, only to turn around and immediately plan the next nonsense to piss it away on shows no gratitude.

Hi, me and Zdenda just finished new demo called Dorgaster. It is music disc with my best mono CMC musics from years 2007 - 2022. Mono Atari and 64kb required There is special function RANDOM activated press Option key. Demo will play randomly every music for 2:30 minutes. Enjoy Dorgaster.xex

And just when I thought there wasn't anything left to add... I found some additional stuff. I knew it existed and I hadn't just dreamed about it, but I didn't expect to find it just now! So, here is the instruction manual (or should I say, leaflet) for the Aventuras D'Onofrio educational games, the sheet with specific installation instructions for the Atari 8-bit version, the SISTAP warranty card and registration, and a SISTAP catalog for further educational software... the .ZIP file just contains all these scans together. Time to go to sleep now. Good night! DonofrioManual.zip

ED99 1.7 I found a major flaw in my binary image generator in Camel99 Forth, that affects the reliability of this project. I don't expect many (any ) people use this editor but if you ever wanted to this version at least doesn't have a hidden bomb in it. There is a help file in the ZIP file with the key commands and command line commands. The source code is in the file ED99,FTH. In the version it is assumed that the ED99CONFIG file and fonts are kept on DSK2. The current features that are interesting: (maybe?) 5 simultaneous files open and 800 lines per file. hilight (^M) lines and extract (^X) or copy (^C) from file to clipboard Paste clipboard at cursor line (^Y) DIR and CAT commands resident LOC command to find a text string in a file. (Ctrl F to find next occurrence in the editor) PRINT command to any TI device string or CLIP in Classic99 Release notes contained in the README file: README for ED99 Editor V1.7 by Brian Fox Jun 4 2022 ED9940 is a MULTI-file text editor for the TI-99 HOME COMPUTER Release Notes: -------------- This version 1.7 fixes an error in the original binary files. The error was created by the SAVESYS library in Camel99 FORTH. The SAVESYS error has been corrected. V1.7 uses a new repeating key library which is faster and more reliable. A COLD command has been added that restarts the editor and reads ED99CONFIG. ED9940.zip

From the dev via Twitter on future leaderboard support, specific to the VCS version:

Hello Marco Antonio, Really sorry for not getting back to you, I was quite busy these past days and didn't want to rush my reply. Quite amazing you managed to dig up everything, thank you for resurrecting this game and giving so many details! I think this may be part of the reason the program wasn't uploaded to Atarimania, I may have had trouble with the disks and also wanted to make sure all the information we had was correct. I wasn't certain how the game was actually distributed. Thanks to the scans you uploaded, we now have proof that the program was a true commercial release and a pretty ambitious one! I'll be very happy to add all the material you provided to our page Do you happen to know more about the other SISTAP programs? Were all of them available on the Atari as well? I notice there are two Pronto programs but they don't seem to have proper titles...

Ok, on my own, I've just now coded up a 5200 version that might be OK. It seems to work fine in Altirra, but I have no real 5200 to test with... Someone PLEASE test this and tell me if it's OK (or not). Especially if two-player mode works. I'd really appreciate to know if it's working. Fast Food [5200].bin

I have spent, continue to spend, and plan on spending stupider-than-ever-before $$$ and Kim Kardashian has no inkling I exist either. Maybe if I order up that SR22 I've been eyeing for the last decade she might invite me to a party? This is not an unusual phenomenon. I've seen tens or even hundreds of examples of people doing that. It seems an extreme version of buying friends? In some way..maybe?? There you go. All natural and no makeup required except for nights on the town (which we do much less of than just 5 years ago) or special occasions. A little paint is fine. But implants and mods, tattoos, piercings, eye injections, brazilian butts .. just ugh! Neither of us believe in such things unless trauma & injury repair.

So, I'm attaching here two .ZIP files, the first one (SISTAP.ZIP) contains the old .DCM files and blurb files from the installation disks which I had uploaded to the UMich Archives back then in the 1990s, plus .ATR versions of them which I just made a few minutes ago (using nothing else than the sector copiers from a .DCM image of an old Copy Service Stuttgart disk I also had among my files, to duplicate each .DCM file in D1: into an .ATR one in D2:) and the various photos and scans I uploaded here earlier, plus the screengrab from the installation menu. The second one (DONOFRIO.ZIP) contains the .ATR images of the 3 playable disks, plus the screengrabs from the main menu and each of the four games I uploaded here earlier. Also, each file contains a new text file I typed (SISTAP.TXT and DONOFRIO.TXT, respectively) describing their contents. Enjoy! SISTAP.zip DONOFRIO.zip

Actually, the XB3 cartridge is very easy to obtain on an UberGROM board. Arcadeshopper sells them, as do I. I haven't ever built an UberGROM image for Extended BASIC II Plus, but that was more due to the fact that it turns up often enough that most folks who want one already have one than to any other limiting reason. Like Ciro, I have several of the Extended BASIC II Plus cartridges in my cartridge set. Don't discount Triton's Super Extended BASIC cartridge, RXB, Extended BASIC 2.7, or Extended BASIC 2.9 either. All of them have good things to offer--and all of them are currently available as UberGROM cartridges. You also have the option of running any of them on a FinalGROM cartridge, so there are good options if you wanted to use them. As to crazy cartridge finds, I found an original prototype for Parsec in a red TI case about 20 years ago at a thrift store, for the princely sum of fifty cents. . .it still has a place of honor in my collection.

X-Rally for Intellivision. There's still a lot to do (and fix), but it's been fun. https://www.youtube.com/watch?v=U_lX5lkHEN4

Here's a preview of something I've been working on recently. It's a dungeon adventure developed with the following parameters: Language: TI BASIC (no machine code jailbreak) Requirements: Unexpanded TI-99. Currently also loadable via disk, but this is not a requirement, and offers no advantage. Medium: TI BASIC via Cassette or Type-In. Currently also compatible with XB, but this is not a requirement, and is not well tested. 2022-06-01 20-28-08.mp4 Very unfinished. Still needs content development. But the engine's pretty much figured out. How dungeon level generation works, and all that. The intro, which is really an elaborate ruse to distract the player with shiny objects while it loads a huge pile of character patterns and colorsets and all that. But as I say, far from finished. I'll distribute code once I've cleaned it up, finished all the core content and made the comments coherent and what have you. Edit: Uploaded an updated gameplay video, due to a bugfix

You have a definite talent for these conversions. Maybe you can start signing them "Glurk the 2600 Man!" ?

I have four PEBs. Two were in regular use while the kids were home—last kid of seven left ~25 years ago. I have had one in more or less regular use until ten years ago or so. Since then, it has been mostly with nanoPEBs, when I use the TI at all—mostly for verification of fbForth cartridges and programs. These days I am constantly using Classic99 for all things TI-99/4A—mostly development or some programming challenge or other. ...lee

Yes, I mostly post updates on Twitter...

It's kind of fun (maybe masochistic) to program the 8-bit machines in that 'racing the beam' way, kind of like a glorified 2600. It worked out exceptionally well for this particular Telesys game. It wouldn't work so well for everything, of course. I find it rather cool, though, that it's even possible to do it at all, "painting the screen" like that. AFAIK the Atari machines are really the only systems that make the method possible...

Late to the party, but... Not so sure about that. The MAME pokey pulls the correct sequence coming out of reset, or else Tempest arcade wouldn't boot. So this likely won't be a problem with A7800. I think putting 6502 code somewhere in a hardware protected microcontroller would be better. The game would retrieve various bits of the purposeful 6502 code from the micro. Absolute addressing would be used with some particular RAM location, and the various routines would reuse that same location. Ideally the routines would be dynamic in some fashion, depending on some internal state in the microcontroller. (e.g. a call index counter) An attacker could tediously tickle the microcontroller into giving up all of the code, same as the game, but reassembling it all that into an unprotected rom would be a massive pain in the ass. To OP, I don't think 7800 emulator detection would be difficult, but I'm not giving clues out, because I have better things to do than work on making A7800 more realistic in unimportant ways. Plus, other than this DRM thing being a stimulating cat-and-mouse game to think about, I don't think application of DRM is a worthy use of homebrew dev time. Even if you value your time at minimum wage, you won't recoup any time you spend implementing DRM, I promise. The exception to my DRM feelings is for the hardware guys (flash carts, virtual soundchips) who spend their $$$ developing hobby gear and procuring inventory. They should throw in every reasonable monkey wrench they can, to avoid being cloned, since they have more skin in the game than us game devs ever will. While I'm still on the pulpit... I'll say the 7800 scene is blessed not only because the devs share their roms. It's much more than that. We have a functioning gift economy. Devs share their time, help, and code, with other 7800 devs. We genuinely cheer each other's successes. Music and art people give freely. QA dudes spent their time and effort going over the games in tedious ways to make sure they're bulletproof. Everybody's contributions are publicly acknowledged. In short, we have none of the zero-sum big-ego crap that sometimes shows up in other hobby spaces, which suits me just fine. I have zero tolerance for all that drama.

Great game. Online gaming works great with the 8 bit Hub ?

Here's an even better view.

Here are the source files of which my demo is comprised, as displayed above. They are relatively (but not entirely) uncommented. (I have commented versions of the standalone versions if interested in their inner workings). I've assembled them (option 3) with the EA Assembler (on Classic99). It's a bit of a mishmash, as these were originally stand-alone programs that I have squeezed together, modifying labels to avoid duplicates and modifying routines (such as the Brensenham routine DRAWXY) so they can be shared. A SuperCart or MiniMemory is required to run it on real hardware. I've AORGed the code so that non speed-sensitive data and initialization routines are placed on the SuperCart or MiniMemory while the main programs are in 16-bit expansion RAM (on my console). The entry point is MAINST. DEMOS is the main source file. At the end of DEMOS are four COPY directives that continue assembly through SMALLLS4, SMALLQ, SMALLM, and SMALLPP. Right now the COPY directives expect to find those files on DSK4 (which is where CLASSIC99 sees my source files on my TIPI.) If you put them elsewhere you'll have to change the device accordingly. At runtime the demo expects to find SDATA, SDATB, LDATA and LDATB (in post #4, above) on DSK2. If you put them elsewhere you will need to change the PAB entries (in DEMOS) for those files to live on a different DSK. The filenames are at lines 107 and 116 for SDATA and SDATB and lines 185 and 194 for LDATA and LDATB. A routine in DEMOS labeled as SEL (line 719) calls each of the programs in order. @SELNUM is used to pass a parameter that controls how long each segment runs. In most instances it specifies number of repetitions, although for the Pentominoes and Queens program it specifies the number of solutions to be found. Edited to add: assemble the file DEMOMM to work with both the MiniMemory and the SuperCart. DEMOS works only with the SuperCart. DEMOSSMALLPPSMALLQSMALLLS4 SMALLM DEMOMM

TI-LINES (UK) V4 N8 January 1988 Ready to print. TI-LINES (UK) V4 N8 January 1988.pdf

That was pretty easy. I only had to change 4 things. (edit: missed one operator. Has no impact on Runtime. ) Change the base address to a VDP location and replace the three four memory operators to VDP equivalent. So on my indirect threaded Forth, the one with the biggest interpreter, (3 instructions) I re-ran the regular sieve code on real iron this time. Time was 2:08 ( 128 seconds made with a stop-watch rounded up to seconds) Putting the 8K array in VDP RAM and used VDP operators to read/write VDP RAM and slowed it down to 2:27 (147) seconds. So a slow down of ~1.15X (15%) The Assembler program slowed down 2.8X. (176%) So the theory holds. The difference in using VDP memory is smaller once an interpreter is involved. Looks like the bigger the interpreter the smaller the difference as we see in BASIC with only a 5% slowdown.

The only i'nvestigation'work I ever carried out regarding Microprose work was to triple check Andrew now Jane Whittaker claims about working on various Amiga Flight Sims was rubbish as was the claim Whittaker was headhunted by Wild Bill and Sid Meier... This done to assist with a legal case between Whittaker and a third party.. Before that, Jaguar Gunship 2000,which one of the various folk i had been chatting with at the time, knew the Jaguar coder of the game and he'd said work was abandoned after early 3D modelling done. Over the years sadly an awful lot of industry folk have taken credit for titles they had no role on.. Kingsley from Rebellion claiming he'd done A8 Star Raiders, Whittaker has a list as long as your arm, Jr artist claiming credit for graphics Jim Sachs had actually done on Amiga Defender Of The Crown. Sad but that's the situation facing us. Others simply get confused over which versions they'd worked on.. The Tiertex Desert Strike G. G coder thinking he'd done the M. S version, which had been done by The Kremlin is a good example, nothing malious in his claims, just a hazy memory. For years people claimed only certain games had been in development for the Atari Panther, then a new round of research turned those claims on their head. I don't think you can ever write anything off, you simply exhaust your sources, try and reach as many sources as you can. Game manuals/instructions were often written at a point a publisher had plans for multiple versions and would include references to versions never started, they are much like magazine adverts, designed and produced months in advance. A8 Jackal shown on early Konami UK magazine ads, cut from later editions. You also never know what's still out there in private collections. So much source code has been lost as people didn't make back-ups, it was thrown out,as it wasn't seen as important at the time. I'm just grateful there are still people coming forward, sharing personal accounts in an effort to try and shed light on what might of been.

It sounds great, I don't think I'd worry about it. And the presentation is fantastic, it does not even need a "for TI BASIC" disclaimer. Had I actually typed this in back in the day, my jaw would have been on the floor. Definitely picked up a couple of techniques watching it run

Here is a zip of clean hi res TIF images scanned from: TI-LINES (UK) V4 N8 January 1988 from Peter Brooks in Oxford. For you to read, print, ocr, pdf, archive (on wht or anywhere else!). 32 pages, white paper, A5 size, two spine staples. Contents include: Programs that write programs-Jim Peterson-Parts 3,4,5 Computers use of "least significant" and "most significant" - Or why 0548 656C 7021 is (or could be) the same as 4805 6C65 2170. Or why the TI disk system appears odd. "The Teaching Computer" by Jim Peterson. and three reviews of US published 99/4a books. Connections and code to use the 99/4a as a full keyboard for a Decafax VP1 Viewdata (Prestel) terminal. This connection uses the 4A joystick port, and code is in c99 plus object code. Prestel was a UK invention that was available to the public in 1979- well before the Internet was offered domestically, but the CEO didn't see any future in domestic dwellings being connected to an information network...they never went past 100,000 subscribers, mostly businesses. In 1983 a home computer section opened (Micronet800), which reached 10,000 subscribers, and the TI99/4a had network pages available domestically in the early 1980s. tilines uk v4 n8 Jan 1988.zip

Thanks! I need to stop obsessing over the music subroutine. I've been messing around seeing what other instrumental effects I can provide for (within the constraints of TI BASIC's performance limitations, obviously). And it seems to me that in a perfect world, I would just treat the ASCII values in which my music is recorded as representing successive notes on the chromatic scale, and calculate their frequency based on distance (in semitones) from the lowest supported note. Which in this case would be G1, 49Hz, as this is roughly the lowest frequency which I feel I can acceptably reproduce with a mix of periodic noise and overtones from the tone generators. However, that extra work just slows things down too much. The alternative, in which the ASCII value is just multiplied by 2 to derive a frequency is a tad imprecise. But it's fast enough to work in TI BASIC. So I shall satisfy myself with it. Because making things work in BASIC is the point here, after all.

I received my sleeve today,so cool!!!? Now I just have to dig out my sealed Flashback... Thanks Intellivision Productions!?

This looks like another masterpiece. If you want to have it multi language and need help for German language... Feel free to send me the texts and infos about maximum length of strings.

Another data point on the question of the speed of access to VDP RAM versus CPU RAM. I've adapted my assembly version of the BYTE Sieve of Eratosthenes such that the 8192 byte data array is stored in VDP RAM. This is a task that, for the most part, can't utilize the auto-incrementing of VDP addresses because reads and writes are not to sequential addresses (an exception being the initialization of the array at the outset of each iteration, but that is a small percentage of the time required to complete the Sieve.) If I'm getting this right, the array is read/written to 313,810 times during 10 iterations of the Sieve (including initialization). The results: The unmodified Sieve (utilizing CPU RAM) executes in 6.4 seconds on my 16-bit console. On the same console, the Sieve takes 17.7 seconds* when accessing VDP RAM for the data array (as the stopwatch flies). It executes in 23.5 seconds on Classic99 with "normal" CPU throttling. *a couple optimizations got this down to 16.6 seconds.

Thanks guys. Next season should be a great one too. Will feature games that most of you guys chose.... ?

Ha, same!

Meh - my wife is four inches taller and not full of silicone and plastic surgeries making her face look like an alien. I wouldn't mind Cindy's bank account however. I'll take a natural brunette over a modified blonde any day

For a noob here, you spew attitude as well as the well established (old) folks like Zylon Bane. I tip my hat to you sir.

Actually, most of the GROM space on the p-Code card is being used as a GROM-disk holding a lot of the start-up data to initialize the p-System environment, there isn't much GPL code in there at all. I've seen the memory map that shows what is what in there, although I don't have it handy right now. I may have to go dig that out again. I think it is in the p-System specifications document. . .

For what it’s worth, I am certain I will still be playing my original unit even after the new one comes out.

I have pushed a fix to build Flying Shark using the latest xdt99. I changed aorg,n to bank n, added _6000 to the output filenames, and last but not least I forced it start at the right address (>a000 instead of >2000) by adding a branch at >2000. I haven't found out why updating xdt99 would cause it to start at the wrong address.

I dont wanna brag- but my Atari corner in my office be gettin' pimped.

I think you're missing my point. I'm more focused on just throwing ideas out there to improve THIS project. So the focus should be on how to get around the limitations of not having the full implementation of DPC+: hack and/or recompile what's provided with bBasic. I think the only real limitation with using bBasic is the lack of new kernel developments. I believe you may have actually done some work in that area with this project... if I'm remember correctly? But I also kinda remember you talking about hitting the limitations in that regard. So, ultimately, I'm not sure. Anyways, take what you will out of this... I'm just trying to push for the best!

Finally we have a hardware prototype, the writing of the code can start completely. I will face it with full courage.

They're ain't never a bad time for this

Maybe they should of started doing it. I seen them about to try once. Their not going to get away with it! Oops.

If anyone wants to use it / try it, here's the '48px kernel' adapted from the original code in the Telesys "Fast Food" game to work on the 8-bits. The code assumes that the pointers and HPOS positions of the sprites are pre-set. I'm using them set like: P0/P1/P2/P3/M3/M2/M1/M0/P0 from left to right. This code has been tested and does work, the timing works out correctly. WideSpriteDraw SUBROUTINE LDA #XPOS STA HPOSP0 sty tmpScanlineCounter lda (digitPTRs + 10),y sta tmpSpriteData sta WSYNC ;--------------------------------------- lda (digitPTRs),y sta GRAFP0 lda (digitPTRs + 2),y sta GRAFP1 lda (digitPTRs + 4),y sta GRAFP2 lda (digitPTRs + 6),y tax lda (digitPTRs + 8),y ldy tmpSpriteData stx GRAFP3 sta GRAFM LDX #XPOS + 40 STY GRAFP0 STX HPOSP0 ldy tmpScanlineCounter dey bpl WideSpriteDraw iny sta WSYNC ;--------------------------------------- sty GRAFP0 sty GRAFP1 STY GRAFP2 STY GRAFP3 STY GRAFM rts

"Did Gremlins destroy the 5200?" "Is there a curse of Spielberg movie tie-in games?"

Found the source code for the eprom. It is at Index of /source (whtech.com)

Hotrod Royalty. 65 colors. GS_HotrodRoyalty.xex

Here we go. Another Youtuber video advertisement. Anyway. They aren't rare games. Hell every EB and Gamestop had those as a $19.99 games towards the tail end of the DC life. Nobody wanted them. All the supposed Dreamcast fanboys were too busy playing their PS2's to bother.