Alex H

Must be connected horizontally of vertically - no diagonals.

The swirly fireball thingies destroy all connected bubbles of the same colour. Destroy 3 or more fireballs/bubbles and you'll chuck (or spill) random fireballs/bubbles into your opponent's playfield. The more you get rid of in one go, the more you throw at your opponent. After bubbles/fireballs have been removed, the remaining ones will float up to fill the empty spaces. This can be used to create chain reactions. In each stage of a chain reaction the bubbles become worth more in terms of how many are spilt onto the other player. If anything ends up below the black line (in the shaded area at the bottom) in your playfield, you lose. That's basically it. Similar game to Baku Baku and Super Puzzle Fighter.

Like the title says! See here. Sorry for the cross-posting, but I figured more people check here and I wouldn't want anyone to miss out.

After seeing a Protector Limited Edition (Vectrex) sell on eBay recently for GBP165.00 (roughly US$300 at the current exchange rate - see this thread), it got me thinking... Perhaps I should put that spare copy I have left on eBay? But then I remembered my good friends here at AtariAge and thought "No!" I had originally planned to run some sort of competition and offer it as the prize, but just never got round to it. So that's what I'm going to do now. So here's the deal. I produced 100 copies numbered from 00 to 99. All you have to do is guess the number of the copy that's up for grabs. The first person to pick the right number wins! The rules: 1. Each person may choose only one number. (One entry per member.) 2. Your AtariAge forum membership must have been registered before the date/time of this post. (Yep, that will prevent new users taking part, but I don't want people registering multiple accounts in order to circumvent Rule 1.) 3. Please post your chosen number here in this thread. Put the number on it's own, on the first line of your message. (Other text may follow if you like.) 4. You may not edit the message that contains your chosen number. 5. Anyone found breaking these rules will be disqualified. 6. In the event that two or more people choose the correct number, the person who's message appears first wins. 7. There is no fixed time limit on how long this competition will run. If after a while no one has guessed the correct answer, I may decided to allow everyone a second chance. 8. I reserve the right to cancel this competition at any time, change the rules at any time and my decision is final. (This is basically in case something goes horribly wrong, e.g. my house catching fire and the game being destroyed.) Ok, hopefully that covers everything. BTW, if you own a copy already, you are still free to enter. You may also post the number of the cartridge(s) you own to help narrow the odds for other members if you like, but please make it obvious that this isn't your entry for the competition. (My personal copy is number 00, so you can strike that off already!) *** UPDATE *** Ok, 47 numbers out and no one has chosen the correct number yet. So it's time to let you all have a second chance! Please post your second choice as before. Anyone who hasn't already taken part may choose 2 numbers. The numbers it can't be: 00 01 02 03 05 07 10 11 13 14 17 19 27 31 32 33 34 36 37 38 39 42 43 48 50 52 54 58 62 64 66 67 69 71 73 74 75 76 77 79 82 84 86 87 97 98 99 Good luck everyone! *** GAME OVER *** We have a winner!!! 8bitclassics guessed that it was cartridge #06 that was up for grabs. Congratulations 8bitclassics, commiserations to everyone else. Thanks for playing everybody!

This is not exact. They can work at the same time. They just cannot access the bus concurrently. Usually the CPU is accessing the bus all the time (at the very least once per instruction for the prefetch). So typically the CPU is pretty much halted if it cannot access the bus. However bus access is a fraction of the execution time for long shifts, multiplications and specially divisions. So in theory you might arrange code and blits in such a way that you can get quit some good Blitter/Cpu concurrency. But again, even if you could get perfect 100% concurrency, it won't be a significant boost for these games. 868301[/snapback] Oh, right, yes I get you. When the blitter grabs the bus, the CPU can still continue to execute the current instruction to the point at which it next needs to access the bus. So it makes sense to use the blitter whilst doing say a batch of matrix multiplications rather than when moving memory around with movem.l instructions. I'd never thought of that. Seems pretty obvious now. Seems like we've gone way beyond the subject of the original question, but cheers! Might come in handy one day if I start up ST programming again. (Stranger things have happened.)

Trying to remember the games that got played most... In no particular order... Llamatron Star Wars (superb port of the arcade game) Star Raiders (beautiful graphics for an early title) Sensible Soccer Arkanoid Bubble Bobble Rainbow Islands BombJack Space Harrier Super Sprint Buggy Boy Ikari Warriors Joust Time Bandit Oids Megaroids (very playable medium/hi-res Asteroids game) Lemmings The Pawn Xenon Xevious Jupiter Probe Hades Nebula Match-It Switchblade IK+ Mud Pies (crusty, bit I still enjoyed it) Major Motion (Spy Hunter - shoddy frame rate and sluggish controls but still got played a lot) Crack'ed (mouse control - much better than the 7800 version)

No no, I understood exactly where you were coming from and it's a very reasonable question. I've just scanned over some of my hardware docs to verify what I was saying (it's been a long time since I programmed the ST) and I was nearly right. In fact the blitter is only a partial hardware implementation of the line-A (not A-line) draw routines. The bottom line is that the blitter only does rectangles. I.e. it's great for filling rectangular areas of the screen and chucking big sprites around but is absolutely no benefit to drawing arbitrary polygons. One of the headaches for ST game programmers was the fact that the screen memory is aligned to 16-pixel chunks on the X-axis. To move a sprite in increments less that 16 pixels requires CPU shift instructions which really slow things down. The usual solution to this was to pre-shift the sprite data - making up to 16 copies of each sprite in RAM so the data is ready prepared to be copied straight to the screen. Whilst this is fast, memory disappears very quickly. The same problem also applies to backgrounds. Scrolling the screen horizontally requires that there are multiple copies of all background tiles in RAM, otherwise the frame rate is hideously slow. Any game wich scrolls the screen horizontally with non-repetative graphics at a decent frame rate is some achievement on the ST. Now the blitter is great because it takes care of all the shift opperations, but from a game programmer's point of view it does more to help with RAM usage than it does for performance. If a game needs to fit in a stock 520ST without blitter anyway, there seems little point in even checking for the blitter's presence. If the blitter had been built in from day one it would be a very different matter. (But still no help for 3D.) Just one final point - the blitter and CPU cannot function at the same time. When the blitter is drawing the CPU is halted. There is a mode where the blitter and CPU take it in turns every 64 clock cycles but this has the same net result as running the both chips at 4MHz - half speed. This all plays havoc with timing critical stuff like sampled sound playback and mid-screen colour palette changes and doesn't do much for performance. Anyway, sorry to ramble on. Hopefully I've explained a little better.

I doubt either game will have any speed improvement with a blitter but I don't know that for sure. The blitter is a hardware implementation of the very inefficient A-line draw routines built into the OS. (And is quite a different beast to the Amiga blitter.) Most games didn't use the A-line stuff and used their own much more efficient routines. In general, most games don't benefit from having a blitter installed (unless they're STe specific titles). GEM applications usually run much quicker with a blitter though. I think Elite might have come out before the blitter existed, making it even less likely.

I think you need to rename it BOOT.EXE. I wrote it on the Net Yaroze system so always loaded it from the PC via serial - don't think I ever made a bootable disk. Would be interested to hear if you get it working that way.

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewI...item=8193364813 Insane I tell thee!!!

Your wish is my command.

I've done this on the Vectrex. Check out VecLink Maze Demo on my site: www.herbs64.com. Not much info there, but a photo of it running. The problem with doing it on the VCS is that the 2 machines will not run at the exact same speed and will drift, so as one machine gets ahead you have to add an extra scanline every once in a while to bring them back in line. That might cause some display twitching. The Vectrex doesn't have this problem because the display is entirely under CPU control so it's easy to sync the two.

The “category” of a CPU or MPU, 8-bits, 16, 32, or 64-bits, is one thing and the bus size is another. The bus size is only one of the components that define the category. There cases that are not clear or controversial, but most cases are not. The 386 is a 32-bit processor. The fact that there is a smaller variant (38SX) with a smaller bus size doesn’t change this. The 68000 also had a little brother, the 68008 with an 8-bit bus size. That doesn’t make the 68000 an 8-bit (or 8/16) CPU. Comparing the 386, even the SX, with the 68000 is pointless. If you want, it is comparable with the 68030, but not with the ST 68000. Also, don’t confuse the processor with the computer. Many, perhaps most, PCs with an 386 had an ISA bus. The ISA bus is 16-bits but allows using older 8-bit cards. However there were 386 PCs with EISA bus which is 32-bits, and with 32-bits MCA bus. Anyway, that’s not the main system computer bus, it’s a peripheral I/O bus. The system bus, that connected the CPU to main memory and other system controllers, had the same size of the CPU. This means 32-bits for a 386DX. Something similar happens with the ST. The main data bus is 16-bits. But most peripherals are 8-bit (ACIA’s, MFP, FDC, PSG). Besides main memory, only the graphics (MMU, Shifter, etc) and the hard disk interface is 16-bits. From the point of view of speed, the architectural design of using main memory for video display is what made the big difference with contemporaneous PCs. 867190[/snapback] Yes, yes, I agree. Perhaps I worded that badly. I had a Sinclair QL (before moving onto the ST) which used the 68008. Sinclair advertised it as a 32-bit machine, which of course it wasn't really. Motorola describe the 68000 as a 16/32 bit processor (and likewise the 6809 as 8/16 bits). And of course, ST stands for Sixteen/Thirty-two. With processors like the 6502 it was easy - 8-bit data bus, 8-bit instruction word, 8-bit ALU. It's 8-bit! But with processors like the 68008 with 8-bit data bus, 16-bit instruction word and 32-bit ALU, the terminology got hijacked by marketing men. It gets really confusing with systems like the PlayStation2 - the GPU alone has 2 data busses to it's on-die memory which are 2048 and 512 bit. There was early marketing speak suggesting that it's 2560 bit! Crazy!!! Anyhow, we've got a bit off topic so I'll shut up now.

Hello! I wrote a game for the PlayStation1 a few years back and thought you lot might fancy a tinker. Binary here: superbub.zip It's best played on the real hardware with the proper controllers etc., but that might be a little tricky for most of you (plus it's PAL only). It runs ok in ePSXe 1.6.0 which can be found here: NGEMU (popup alert!) ePSXe requires plugins for the video/sound (also downloadable from NGEMU) - the ones that worked best for me are: Video Plugin: P.E.Op.S. Soft Driver 1.16. Audio Plugin: Eternal SPU 1.41 (crisper sounding than the others I tried). Since it's PAL only you'll need a PAL BIOS. The file you need is SCPH7502.BIN. Naturally I can't provide this - you'll just have to Google for it. Configuring DirectX to force 100Hz full-screen refresh gives the smoothest display. To execute the binary, select File>Run PS-EXE and then pick SuperBub.zip. It can take a while for the game to start up. (Don't forget to configure the plugins/BIOS/controller first.) Controls: Left/Right = move left/right. (Who'd have thunk it!) Square = rotate left. Circle = rotate right. X = Fire. Watch the demo and you'll get the gist of the game. Have fun!

Oh, forgot to say that I have some early Atari ST developer docs which say there were to be 2 models - 130ST and 260ST. I know some 260STs exist but was there ever really a 130ST? (I think GEM was too big to fit in 128K.)

Yes, this was the same in Europe - al least in the UK. And was also the first model to have the blitter. Although I understand that some later Megas don't have the blitter fitted? It also had room for an internal hard disk and an extra connector for graphic card. The STe also had the blitter, expanded the colour palette from 512 to 4096 colours, added hardware scrolling, DMA digital audio and extra controller ports. (To bring it more in line with the Amiga specs.) Oh, and IIRC, SIMM sockets for RAM. Yes. The 386DX was the full 32-bit version with 32-bit data bus, the 386SX had a 16-bit data bus.

I chose Gorf, just because I always wanted a home version with speech. Without wanting to sound negative, adding speech to existing games could be somewhat tricky. The driver code requires about 6-7 scanlines of CPU time, so if that isn't available in the vblank/overscan periods then it's not possible to communicate with the AtariVox. The PAL versions of games will probably have the required CPU time available because there are more than enough extra scalines in a PAL frame, but I wouldn't get your hopes up too high for the NTSC versions. I haven't actually examined the code for any of these games so I can't say for sure, but my guess would be that Star Wars is least likely. Shame 'cos the AtariVox does a great impression of R2-D2. (Not sure how "Red 5 standing by" and "Use the Force, Luke" would sound in a synthetic voice though. It might be better to convert games which had synth voice in the first place, rather than those which use real audio samples.) The AtariVox can also do a pretty good impersonation of Q*Bert - I know this because I made an error while coding the driver which scrambled the speech codes and it sounded just like him/it/whatever. So that would be my second choice. Shame I'm so poorly at the moment 'cos I'd love to examine the code for some of these and see what's possible. That would be after I finish MGD of course. Anyway, like I said, I don't want to be negative - it's fairly easy to include speech in new homebrews, providing the programmer allows for CPU time required. But once the CPU time is spent it's very hard to reclaim it. Now if someone wants to prove me wrong... Alex

Hello everyone, I thought it was about time I posted some sort of update. Basically, I've been unwell and haven't really been up to coding and stuff. Without going into too much detail, it's a problem that's affected me on/off for the past few years but in general hasn't impacted on my life too much. But this time it's perstistant and it's pretty much knocked me out of action for much of the past 3 months. Anyhow, I have hospital appointments next week so hopefully things will get fixed pretty soon and I can get back on with my life, and more importantly coding MGD! (You have no idea how much I'm itching to get on with it!) Sorry about the delay folks. I'll keep you all posted... Alex

Helloooooooo, Happy New Year everyone!!! Right, Christmas out of the way, back from trip to Amsterdam for new year , brain starting to function a bit more normally... We have a winner! Nathan Strum wins the Man Goes Down label contest with his newspaper design!!! (#10) It wasn't at all easy choosing a winner. (Sorry I took so long.) I'm totally honoured by the amount of time and effort you've all put into my little contest. Cheers everyone! Right, I'd better get the rest of the game done... Congratulations Nathan and thanks again to everyone for taking part. Alex

Ok people. I'm attaching a new version. I was really hoping I'd have it completely finished by now, but sadly not. (I must have been insane thinking I'd get it done at this time of year.) Anyhow, most stuff is in now. There's still some speech missing (stop sign, high score 3rd, 4th, 5th place and a couple of other odds and sods) and some of the level data is screwy/incomplete so we have an impossible blue section again - in the 2nd zone. The final game will have 9 zones. I'll leave it to you to work out what that's all about ) Merry Christmas, Alex mgd_201204.zip

I'm sorry for taking so long to answer, I thought I'd have more speech in by now. The ROM space available for it keeps shrinking/expanding each time I add stuff or clean up the code so I've been holding off putting the actual speech data in. It's almost finished now though... The burp is staying but is now occasional rather than every time a fruit is eaten. Other phrases I have so far: Game start: - "May the fruit be with you." - "Run, run, run!" Missed fruit, etc.: - "I hunger." - "Ah, missed it!" Near death experience: - "Phew, that was too close!" - "Are you insane?" Collect gravity (down arrow) - "Heavy, man." Collect skateboard: - "Awesome, dude!" Collect heli-pack: - "What a hero!" Collect bubble: - "I'm forever blowing bubbles." (Sung) Collect magic mushroom: - "I feel strange." Top score: - "The fruit is with you. " Low score: - "You suck!" Suggestions anyone? Yes the stop sign is still there but I think the only place it shows up (in the last binary) is in the blue section with the long platforms. They come in threes (like the gravity arrow) and halt the scrolling momentarily. I'm working on the last of the power-ups at the moment - the magic mushroom. Mushrooms blink colours (red/blue) and depending on what colour it is when you touch it, you'll either have a good or a bad trip. The bad effect is done and it's rather nasty. I'm not happy with how the good effect has turned out though. The benefit to the player isn't enough to risk having a bad trip so it's better to just avoid them, which kind of defeats the purpose. Need to have a rethink. There are 2 other special items, but I don't want to give away too much about these - want to leave some surprises. His real fetish is for vertical striped clothing but he only wears those on his day off. Anyway, enough of my sillyness. Thanks everyone for your entries so far - absolutely fantastic! There are already several here which I'd be more than happy to use. I think this is going to be a really hard decision. I apologise in advance to everyone who doesn't win. Keep 'em coming! Alex

Yes, that is a burp. The little speech that's in there so far is just for testing. I'll expand the speech and level data to fill whatever ROM space is left, so that's why I'm leaving it till last. You might want to grab the latest version of my AtariVox driver. Included is a little program vox_test.bin that plays speech triggered by the joystick. The source code is also included so you can edit and play with the speech. So what sort of game would you expect "The Descent of Man" to be? Would "The Fall Guy" be false advertising, because he don't look much like Lee Majors to me? How is "Man Goes Down" any less relevant to the gameplay? I understand why you're not so keen on the title and it's not that I thought "The Descent of Man" and "The Fall Guy" were bad suggestions - they're just not the title of my game. It's Man Goes Down to me and anyone else who's seen it, and I'm not about to change it just becuase some prude can't handle it! Try thinking of mangoes instead - perhaps that will help. (Hey, I'm just joking, incase that wasn't obvious.) Ah, now I get the MGD reference made in the AtariVox thread. (I am not familiar with said beverage.) Oops! I missed the "branch out of range" error when I assembled that. The CPU leaps for the bubble code, misses and plummets to it's death! I'll post a working version shortly. No, not a bad idea, but very hard to do now. Shortage of RAM for the 2nd player's variables is a problem. Besides, the AtariVox plugs in port 2. I think the format of Fall Down works better for 2 players anyway - the play area is wider and I like the way it's more of a race rather than just trying not to fall off the screen. If I have room for it and if I can come up with anything which sounds vaguely musical. The 2600 isn't exactly a natural when it comes to music, and I don't want to compromise other parts of the game just for the sake of fitting it in. I'm attaching a binary that has a tiny little segment of music. The data's fairly compact so maybe I could expand on it, but I'm not really sure it's the right style for MGD. Alex wscroll.zip

I seriously doubt there's any risk to the CC2 at all. It's the voltage regulator in the 7800 that's going to take all the load and that's attached to a heat sink just behind the cart slot, so that's where the warmth is coming from. I believe Richard has been doing all his testing using a CC2 so if there was a problem, I think he would have found out by now. Alex

No need - the AtariVox has an amp built in. (Same goes for the VecVox.) I'm just using the non-amplified 2nd speaker from a pair of old Altec Lansing PC speakers and it's plenty loud! Alex

Hope so! Sometimes this developer needs a good kick in the posterior to get things done. Bah, nothing wrong with the title. The Vec version was called Spike Goes Down, but this time it's not Spike - it's just some dude. Maybe I should give him a name. How about BJ? I've made some improvements based on earlier suggestions, so feel free. Having said that though, I'm quite far in now and have everything pretty much planned out, so it'd have to be a damn good suggestion if it requires big changes. I'm attaching a new binary 'cos the last one had bad EEPROM driver code. The footstep sounds have been improved slightly in this version but otherwise there's not much new to see. (Well, there is new stuff in there but you're not allowed that yet!) Alex mgd_151104.zip