andym00

Don't ?

I guess the outcome was positive then, and that the digital DNA test proved you weren't in fact Oky2000, given you're still here But by god, I've missed this place for all of it's straw chewbacca objective lunacy

Lots of dillying & dallying meant this got put on hold.. eBay Auction -- Item Number: 200431525598

Bad form I know replying to oneself, but I finally found it... It's the N64 version on Namco Museum in case you were wondering I guess I should just have checked on Galaga Maniax first..

I'm trying to work out which version this is.. Just curious because of the style of the graphics, and would like to track them down Looks nice, although not the right aspect ratio, the sprites suit the screen size nicely even though they're bigger than you'd expect and appear to lack some of the sprite rotations of the arcade (maybe 16 instead of the 28 or so the arcade has), but looks good anyway.. To me at least I just can't see enough in the blur'o'vision of it to determine exactly which machine it might be.. Anyone got any clues ? Maybe the brown screen edges give it away to someone ? Edit: Found one image via google images, that matches the surround, since it's not the usual surround with double pointy bits, but still no closer to figuring out which platform it's from..

I'd head to MAME as your first port of call actually as that'll probably have most of what you want to get started, plus modifying the driver to add your own ROMs to it so you can test would probably be one of the few ways to do it.. Though I've no idea what the state of play is with other System 1 emulators.. It's easy to find your way around though, once you get the naming conventions clear.. Just get the thing loaded into Visual Studio, and it's childs play to navigate the source.. If you haven't got a meaty version of VS/VC or whatever then grab the Express version, which is free.. Anyway, that's only if you want a n easy life browsing the source, but I can't remember where the solutions came from, or if I just made my own last time I was playing inside Mame.. Drivers/atarisy1.c is the driver you'll be interested in It's got most of the registers 'documented' in it and of course you have the source to it so it's easy to figure out what the hardware is actually doing with registers and stuff.. The list of actual hardware dragged in is: #include "driver.h" #include "cpu/m68000/m68000.h" #include "cpu/m6502/m6502.h" #include "machine/atarigen.h" #include "machine/6522via.h" #include "includes/atarisy1.h" #include "sound/tms5220.h" #include "sound/2151intf.h" #include "sound/pokey.h" edit: Just went hunting, and managed to find an interesting little place.. http://www.alsarcade.com/Andy/arc/atari/ Specfically, he has the "SYSTEM 1 Hardware & Operating System description manual" available http://www.alsarcade.com/Andy/arc/atari/system1/system1_hardware_and_os_description.pdf Which might save some reading of source code..

Right, crystal clear now

You mean only when reset is hit right ? Not at any other time ? I mean, there's no system ROM code that I can't shut down, because of how the ROM interrupt and reset vectors work, that keeps checking this for a change is there ?

I'm hardly using Atari800WinPlus anymore.. Altirra is just a far more 'social' program to work with, and the debugger is just absolutely heaven to work with, even though it appears not quite complete in some ways.. I don't know now if I'm dare going to try for RAM under the cart.. I think if I go with a fixed bank, a switchable bank and a fixed 32K of RAM will have to do I guess, plus it'll still work on older 48K machines which'll be nice, though I'm loathing the idea of having my IRQs being vectored through ROM before I can get my code, but if I want to support the 48K machines I guess that's a price I'm going to have to pay, not that it's a deal-breaker at all, just a tad annoying losing those few cycles.. But if the fixed bank is going make life so much easier as it would appear, then that's a simple choice.. I've been thinking more and more about what Rybags wrote though.. And I really do like the idea of a one cart fits all game.. Currently 16K is a no go for this, but there's something else that would fit nicely on it, especially with the total rewrite of all the character mode sprites that happened yesterday by accident, for the umpteenth time now.. So much so, that I've been giving thought to possibly making that run on the 5200 as well.. Is it even possible to use a cart on a 5200 from an 8bit ? I mean as long as the code supports the different locations of GTIA and POKEY ? And whatever differences there might be.. I've had a quick look-see at DanBs site, and from a cursory glance it would seem that there's not much problem doing so.. From a purely programming point of view, and with a simple cartridge at least.. Out of curiosity though, what should the ideal expected behaviour of a cart being on Reset being hit ? I was thinking just let the cart restart ? After all in console land that's what I'd expect it to do.. Is there any reason not to do that ? The only other desirable option would be to maybe ignore it, as best possible anyway.. I think some reading of ROM disassemblies is in order to fully understand what's going on with all of these different beasties.. I understand the 5200 Reset process since that's nice and simple, and seems exactly how I'd expect it to be.. And now it's clear why making the cart diagnostic would be seemingly the way to go.. Are the same banking schemes available on the 5200 ? I mean the fixed bank, plus switchable ? I haven't read much on the 5200 specifics, but I am doing so now.. Hell, I guess I should start with, are they even physically compatible really.. edit: Well that last question was swiftly answered with some reading.. Oh well It was a nice idea

I didn't mean underneath in the sense of G2F, but in the game when it will be written.. For example, in the picture you posted above, there's the trees on the path going North West, and when the player walks there he goes behind the tree(s).. That's the bit I meant about going behind objects.. I was just wondering if it was usually only one 'thing' the player is behind or if there are possibly several 'things' in front of the players sprite ? But you're right, let the coder worry about that stuff, that's what they're paid for anyway I was just wondering because I found myself with silly masking ideas going through my head last night because of things I'd been working on, and wasn't sure if LN limits it too only one 'thing' at a time covering the player or if there are possibly many at one time

SparkFun Electronics is Temporarily Closed! SparkFun Electronics has been temporarily closed while necessary upgrades are installed and configured. Please be patient and check back soon. We're working tirelessly to make this down time as brief as possible. Not the page I was hoping for

Site appears to have completely collapsed under the hordes that have descended upon them.. Totally and utterly dead from over here.. Ah well.. Bang goes my plan of a nice cheap XMOS board

Finish LN1 first By the way.. I meant to ask, out of curiousity only, well really because I was thinking about this last night whilst I was falling asleep.. In LN1, though I'm interested in the others as well if you know the answer, do you happen to have any idea what the maximum number of objects that can overlap the player (or other characters) and hide them in the game is ? I mean at any one time ? For example, behind a fence, and with a tree overlapping in the foreground as well ? That kind of situation ? Don't suppose you've happened to notice this whilst you've been working though the screens ? I'm just curious

Whilst I'd like nothing better than to be able to plug it in and play on an original 400, really that'd be fecking awesome since the picture of a lonely 400 in front of a TV is somehow glued into my head from childhood, I'm afraid it's not going to happen with this.. There's no way this is going to work with 16K of RAM much as I would love to have it run on it.. But that's something I'll bear in mind for something else.. It would be cool to be able to still run it on the very minimum specced machines even after 30+ years

Oh, you mean the Corina Cart ? That one scares me... Too big not to be abused especially with all that RAM optionally available Though the EEPROM is a very attractive proposition and do love permanent high scores on carts.. The fixed bank is nice and simple granted, just a question of finding the right code that can sit there all the time and justify the expense from memory map point of view.. But I guess there's plenty that can go in there really.. edit: But if I'm right, with all of the ROM bank switching, there's no way I can access the RAM underneath whilst the carts are in ? I mean, not without cartridge specific support to switch the external ROMs out ? I did find some nice simple looking EPROM carts on Ebay from B&C, but they're limited to 64KB, but I might grab one anyway since they'd be nice to have a play with.. I'm no electrical wizard either, but that's pretty much exactly what I was thinking of doing Maybe it's time to get the soldering iron out and blow up my first A8

Since you'd be going for a crazy DLI'd/WSYNC'd up the wazzoo screen anyway (or a kernel, or mini-kernals maybe if it's going to be char mode) why not just pay the price and burn the additional 12 cycles per line and change the scroll colour PF at the right time, then that'd free you another colour without having to worry about the main display Anyway, I'll go away now because I know you hate this Just had to say it Does look good though, but for me at least, the brightness of the scrolls on the left and right keeps pulling my eyes away from the main screen to the point it's hard to focus on the actual play-area.. But maybe that's just my dodgy old eyes & brain

Right that's made it a bit clearer now.. Thanks Not mad about the idea of a fixed bank gobbling up valuable address space all the time especially if it can't be modified.. Perfect world would be no constant footprint at all, without the need to have the vectors spattered throughout the ROM banks.. But that's not happening I guess.. That stuff in AtariWin800++ looks like what I was searching for earlier, but since I've kind of stopped using that now and the only use Altirra, so I didn't think to look it's help stuff.. Next port of call was going to be the Altirra source code.. I was hoping there'd be a one fits all solution to this, but I guess there's more to it than appears, unless it really would be best and simplest to keep one bank fixed which would make life nice and simple anyway.. Hmmm.. I guess I'll just have to experiment and see which suits me more, the constant stuff in every bank, or one common bank paged in all the time.. Actually, writing that down, and I think I've already decided the answer to that in my head, and probably would go with having vectors in every bank, if only for simplicity, losing a tiny constant amount from each bank wouldn't be the end of the world for a nice simple solution that would be fairly bullet-proof and doesn't make life complicated.. Still need to run this all on a real machine and see what's what.. I don't suppose there's any off the shelf PCBs or carts available for the A8 that can take ~128/256KB eproms and have bankswitching on them ? Or am I getting my soldering iron out for that one ?

I was just trying to find an answer to a few questions I've got about how the A8s handles cartridges, and whilst it all looks fairly reasonable and simple to implement a nice simple bank switching method on a cartridge thanks to CCTL, I came across Sheddys post on his blog and his concerns regarding what happens with the various methods when the user presses Reset, and his mention of needing a little bit of code in each bank to support this.. So I'm having trouble finding the answer to this and not sure exactly is the issue ? I'm assuming pressing Reset causes a problem ? But what happens ? What ROMs are put back in place, and what vectors are called ? And surely if I've got the ROMs banked out in the top 8K and RAM there I can't see how there's anything that couldn't be trapped and handled by me ? The only sense I can make of it is that this is purely an issue on the old 800s without RAM in the top of memory under the ROMs and that you can't get control before the system starts processing the reset ? Is the bit of code something that you hide in the ROM space ($8000-$A000,$A000-$C000) that the Reset handling calls into, then you get control ? Just wondering, because it's bugging me now, and I've not got a cartridge that I can test this with on the real thing right now, though one's on it's way courtesy of Jetset And I'm loathe to try it on an emulator, for reasons I'm not entirely sure about myself, just one of those little voice in the head things.. And would I be right in assuming that at startup, the $d500 page is zeroed by the system code ? Ensuring that a known bank will be selected on startup ? Or is there some other mechanism at play for that, that ensures a consistent startup state on bank switched carts ? edit: Just found this thread which answers some of the questions.. BUt I'm still uncertain of why exactly such handling is needed ? Is it just because the bank select is uncertain at startup, in addition to the the top end not being bankable to RAM on the vanilla 800s, hence it's running the ROM vectors all the time ?

You should let Adobe know that.. I'm sure they'd be interested to know there's a very unique palette that breaks their colour reduction algorithms.. In the past I've found Adobe developers to be very helpful when there's a problem and if you provide them with the right information and without sounding like a loon too much, you'll likely end up having one of the programmers pop-up in your inbox in no time, wanting to fix it.. Anyway, please do let us know what he says

It's been progressing slowly in the back of my head on a low priority for a while, and it just needs a good old fashioned proof of concept doing for it, but it'll be good because it'll mean being able to move and render large blocks of vector rendered text around at high speed, only snaggle is the amount of memory it'd need, which at the moment would stand at a rather colossal 29K of RAM, and that's even without an imaginary font loaded But it would be mind bendingly fast for an 8-bitter

The Atari 'ST vs. Wall Switch' thread has my money for the next widow-maker I must admit, the recent mention again of the DTP stuff has got me wondering about how fast the puny 6502 could handle stuff like that whilst not looking totally rubbish, at least the A8 would be able to use its hires mode and wide screen stuff for something useful.. Not something I ever considered before, but I was thinking a lot a while back about vector fonts and things and rendering them in realtime, and had some ideas of how you could do it reasonably well.. Not that it progressed very far

I know.. That is a little bit of an unknown but, out of all the people playing with new modes and pushing the hires modes with sprite underlays, Algorithm is the one repeatedly pulling the magic out, and I've got a high confidence that it probably looks pretty damned nice on the real thing..

Deceptive stuff aside, C64 loses big with A8 on palette and ST is much closer call. Going by actual end results on screen rather than airy fairy hand waving, the A8 loses every-time in my book.. It's that simple, even though I've come to love the inards of this bucket of nuts and bolts.. Just so far it hasn't shown anything that can be considered truly remarkable in anyway, whereas the other two repeatedly have.. Doesn't mean I don't believe the old girls not got it in her.. At the moment, it's a bit like one of those dissapointing school reports that read along the lines of: "Has potential.. Must try harder.." Actually, quite the opposite, no bias at all.. Just the ability to use comon sense instead of digging a deep hole for oneself.. I love all of these machines in case you hadn't noticed.. So no tarring me with the fanboy or the bias feather please..

Wow - that's looks incredible. Details on the mode please (or a link). Stephen Anderson Not quite sure of the details of Algorithms latest low CPU overhead mode but I'm dying to know them! But: http://noname.c64.or...cid=72769#72817 You know as much as the rest of us now It sounds like it's like his regular really nice hires mode stuff with multicolour sprites as underlays, but making a larger palette though very clever interleaving of colour.. I'm literally wetting myself now to get a binary so I can see it on the real thing!