andym00

I'm not either.. I had a pop at doing a Zarch floor on the 7800 some 10+ years back, and just handling handling the floor and translating and projecting all those points wasn't quick to say the least, and that was using MARIA to do the line fills, with me only having to scan convert the edges (with no clipping!) and with some seriously unrolled code in ROM as well, and some excessive tables, I think it was 128K ROM size I was working with.. Mind you I was aiming for 50Hz with it.. There's a lot of edges to rasterise in a normal scene from that.. Possibly with lego mode and 25Hz (or less) it might be doable.. Just it'll look crap at that resolution, unless you're stood 10 feet away and squinting.. And that'd be just the floor, before you've added any 3D objects on the surface, which will be nothing more than a few random pixels at that res.. Plus as Sack intimates, reading the mouse isn't exactly performance friendly on the A8.. As for playing it, I never played the Arch version, but I did love it on the Amiga in its Virus form.. Brilliant little game, though not particularly fast when compared to the Arch. version.. Also, as an side, I was just looking for a video of Conqueror (same graphics system), and stumbled across this side by side of the ST version of Virus Vs. the Arch version.. http://www.youtube.com/watch?v=TjVeZ9c9fLM&feature=related I love how the Archimedes just absolutely demolishes the ST framerate wise, even running at 256 colours I'd forgotten what a stunning little machine it really is.. /me heads off to fleaBay to buy one.. edit: Small world that it is, this video from the 80s came up on hackaday.com today, all about the ARM processor, complete with awesome 80s synth music

Just open the .rp file..

Yes, the same graphics chip in both, but the Z80 in the Spectrum was so fast that programmers opted not to use the hardware sprites or character modes since it was quicker to do everything in software

Don't know what you're looking at exactly, but nothing has changed for me with the upgrade[1]... Chrome under Windows7 everything is identical to how it was prior... Sure you've not accidentally hit ctrl+KeyPad Plus or ctrl+mouse wheel to zoom the font sizes in the browser ? [1] Bar the IPB app no longer works on my iPhone, but different kettle of water dwelling creatures entirely..

Before the upgrade I used to use the IPB app to read the forums on my iPhone and iPad.. Since the upgrade I'm only get the forums displayed as a regular webpage within it.. Has anyone any magic voodoo tips that might get me a sensible reading solution again ? edit: Okay, I've just gone to the Invision website for the IP.Board app and just checked I've got the latest version, and on trying to install it iTunes says it's not available in the UK!! Which is weird, because I've got it installed, except it doesn't work anymore.. What kind of madness is this ??

..Well that's what the article is called http://wosland.podga...m/fuck-the-c64/.. I figured some here would see find this amusing, and indeed learn some valuable lessons in how to translate pure rage into writing, as The Rev literally busts a blood-vessel over the EuroGamer article regarding the 64 vs Spectrum.. This one.. http://www.eurogamer...vs-commodore-64 It's a brilliant example of how to rage properly I love The Rev

Today's a good day for being wrong Out of some perverse kind of curiosity, I went looking for the old Personal Computer World BASIC benchmarks they used to use back in the early 80s as a means to convey some sort of performance figure to these fandangled contraptions.. I didn't expect to find this though.. http://www.geocities...ters/pcwbm.html It's all the Benchmark BASIC programs, plus a table of the results across a vast[1] array of machines.. I would post the table here, but 2 attempts so far have failed, so I give up... It seems the Atari BASIC, whichever one they're actually testing there, isn't relatively speaking that slow, in fact faster than the 64.. What's really interesting in that is just how slow the Spectrum BASIC actually is in those results, especially in relation to the ZX80... [1] Well, not really that vast actually, but vast enough in the context of this thread..

Adding an actual command wedge is possible of course, but it'd probably be easier (if uglier) just to have the code assembled in the 4K space at $c000 and pass it parameters at the end of the SYS command; like anything in programming, it'd probably be second nature for most programmers in no time. That means a line draw from BASIC will look something like SYS49152,x1,y1,x2,y2 =-) Actually, that's one thing the 64 makes pretty easy.. CHRGET = $0073 Initialise: lda #<OurBasicCommandHandler sta $0308 lda #>OurBasicCommandHandler sta $0309 rts OurBasicCommandHandler: jsr CHRGET cmp #"!" beq .newCommand jmp $A7E7 ; Pass control back to normal basic keyword parsing.. ; Use your favourite method of checking full command.. .newCommand: jsr CHRGET cmp #"L" ; L is for.. Line.. beq .line cmp #"C" ; C is for.... Circle.. beq .circle jmp ($0300) ; Error.. ; Scavenge internet and insert first line draw function you come across but don't understand.. .line: jmp $A7E4 ; As above - Scavenge internet and insert first circle algorithm we find but don't understand.. .circle: jmp $A7E4 Adding the line draw is trivial, but that's the least of your worries given the fact that the BASIC isn't designed for that kind of thing.. The bigger questions is just where you're going to put your bitmap screen and its interaction with BASIC and it's memory map, pissing about with video banks etc.. Brrrrrr... You'd end up writing Simons Basic by the time you've finished.. Out of curiosity, how easy is it to extend the BASIC commands on the Atari BASICs ? I guess it's even easier than those few simple instructions above ? Anyway, if in 2012 you're gauging how good a machine is by it's version of a BASIC that dates back to 1977 or earlier, you're definitely a few coconuts short of a shy.. Even the magazines quit all that stuff back in the day.. Though I do find humour in that despite the faster CPU and stuff, the A8 still managed to clock up the slowest basic in probably all of computing history Must be all those fancy commands eh

Not sure exactly if this is what you're referring too, but there's Mr.Sid's interview with him which I think refers to things they would have done differently had there been more time.. In particular is the fact the oscillators aren't multiplexed, so one possibility would have been more voices had that been the case.. edit: Or that freed space in the case of using multiplexed oscillators could used for oscillators tables as he mentions there wasn't enough room on the chip for wavetables..

I thought Stephen was referring to RastaConverter.. But maybe not then... In that case I'll shut up then.. I'd inferred from the posts here that the talk was of RastaConverter and that it was in C#, and that a C++ version was required to build a Mac version.. Obviously I've got totally the wrong end of the stick then, and something went amiss with my brain when I was following this thread! Good work though, loving the results you're getting from this brute-force approach

It's in .NET, maybe try MONO and see if that works. That will make Linux compatible builds. Given that he is using the .NET library's Task Parallel Library, it will not be easy to do a quick port to C or C++ without dropping it to single threaded code. Maybe that doesn't matter. I didn't even see any source code listed here, but if I'll have a pop at porting it to C++ if there's no takers ? And the multi-threading stuff shouldn't be an issue unless there's something very esoteric going on in there

I raise my glass (null)

Emkay, FYI: http://www.thefreedictionary.com/_/dict.aspx?word=baseless (null)

Contiki is a bit more than 'just' a TCP/IP stack, hence it's full name Contiki-OS.. Projects like uIP(micro IP) work in 4-5K of code space with RAM use measured in the hundreds of bytes.. And is also part of Contiki.. By the same guy, but whether or not it was the starting point of Contiki I don't know.. It used to be a seperate project, but now seems to link directly to Contiki, hence why I've linked to the old uIP Also projects like ip65 etc.. There's stacks of them out there, and there's no reason for them to be show-stopping in size, unless you want to write the worlds first 6502 Torrent client supporting 1000's of simultaneous connections

Everywhere that you've been posting usually And can you not destroy this thread please, it was actually interesting before you've turned up with your agenda in tow..

Lots of sprites is out of the box Granted on the 64, you pay a high price in the form of losing lots of cycles if you have all 8 on each line, but lots of sprites on the screen isn't impressive really, unless they're doing something different.. Looking back, when Rhaa Lovely II arrived with a full layer of hires sprites overlaying a screen, it was mind-popping because it hadn't been done before, at least not as elegantly as that.. But just covering the screen in sprites isn't pushing the machine.. You know what it's like on the 64, most of those demos are running kernels more akin to a 2600 display kernel, where as that's not the case with most A8 stuff is it ? As for rubber pictures, that's a great example, it's the standard example of being able to change the screen on any raster line.. Yet it can do so much more, stuff that really would make you go "how?" What I'd love to see from the A8 is the vertical textured rotators like in Edge of Disgrace, Deux Ex Machina and also some later demos that escape me right now, but did it better than those 2 I still think those would make for a great game, with a bunch of platform you scroll up and down, with the platform surface part of each layer being displayed in perspective, especially in something like Goat'Up or something like that, and it's something only the A8 could really pull off And it's exactly that kind of scanline deviancy that I haven't seen on the A8, yet it's something it should do very very very well and at 50hz, and without Lego sized pixels anywhere in sight The A8 could do that effect, full screen, and with more colours way better than the 64 can and with oodles of time left for other things.. You've got a machine that can horizontally split sprites, change the screen to be anywhere at a moments notice, more colours than you can shake a big box of crayons at, and much much more..

I've no idea what else, but I'm always hoping that some DL trickery is going to make some fantastic textured, scaled and shaded vertically textured things, which the A8 can do with it's eyes shut (which the 64 busts a nut trying to do) and looks spectacular, and has rather big game implications as well on the A8 (not on the c64 because it's unworkable), but I've not seen one yet I can't understand why not.. Beyond it being a major pain in the arse to arrange in memory Maybe it was all done in the 70s, 5 minutes after the A8 came out and I've just not looked back far enough.. But the stuff you mention isn't really machine cleverness is it.. The graphics modes are just a by product of the display system (most of) us use.. My sound stuff is nothing more than a simple bit of bit shuffling that's not machine specific at all.. The interlace stuff is cool for sure, but what to do with it when the A8 favourite pastime is to do everything at a lower resolution anyway ? And the VSCROLL stuff.. Sure, but it doesn't need to be used as much as on the 64 before you've got so many other ways of doing things.. lol, this is coming out negative, wasn't meant to be

I didn't mean quite literally the screen dimensions, but to me as someone that dallies with the A8 and understand how it works I don't quite see that it really has been pushed to it's limits at all.. It appears that most of the A8 stuff relies upon the CPU grunt in most cases and the out of the box features for stuff that's mostly a bit meh, rather than actually really properly bending the hardware out of shape and doing something that seems to all intents and purposes utterly impossible at first glance.. Which is perhaps how I should have said it first time around Point being mainly, I've not seen anything on the A8 that's stopped me in my tracks and made me question how on earth that is even possible.. Which is a fairly common experience on the side with less light

# You say that, but to be honest there's not a lot of demos I've seen on the A8 that actually exploit what it really could do from the point of bending the display seriously out of shape Either that, or everyone tried it all in 1970s and it's considered old hat by now

The colours certainly help, but there's still a massively claustrophobic feeling with GEM at that resolution..

I don't think the assumption was that the 6502 was not powerful enough was the problem, but I think from a comfort point of view 320x200 screen just didn't offer enough screen real-estate, not once the medium and high resolution displays arrived.. And to a lesser degree the small storage options available to the 8bits at the times, and the fact they traditionally had bugger all memory, and that display devices usually connected to these were awful things.. Of course there was GEOS in 1986, which I think is about as successful, commercially, as any 8Bit GUI could have been at the time and I think did an amazing job given the constraints.. Perhaps if the Apple2 version of GEOS with its higher resolution had arrived in 1986 instead of 1988 things might taken a different turn.. Hell, who knows where we'd be today if some guys in a garage had written a 6502 GUI in 1980 for some arbitrary 6502 based computer after a visit to the Xerox Parc

Which memory upgrade is this ? I rather like the sound of 1.5MB in an A8

I can't see a clever solution right out, but wouldn't a simple lookup table do the job ? Modify a following blit with the data you've just read in the first, then the next blit does the lookup and destination write ?

Everyday is April Fools in these threads (null)