Jump to content

TMR

Members
  • Content Count

    3,469
  • Joined

  • Last visited

  • Days Won

    2

TMR last won the day on April 20 2012

TMR had the most liked content!

Community Reputation

684 Excellent

About TMR

  • Rank
    River Patroller

Contact / Social Media

Profile Information

  • Custom Status
    Beeping the horn on the data bus
  • Gender
    Male
  • Location
    Leeds, U.K.
  • Interests
    My Beloved, assorted 8-bit systems and y'don't want to know after that, believe me! =-)

Recent Profile Visitors

20,322 profile views
  1. TMR

    TMR

  2. There are a couple of different schemes yes, I think two are in use right now. RGCD is one source (it's more a "they" than a "he", there's a couple of people doing different jobs but James is the "front man"), Protovision another and there are a couple of one-or-two-person-bands brewing their own hardware for single releases, but I'm not aware of anyone putting out cartridges in the US at the moment. It looks like we're already on the way to losing at least one game that way, the developer of a C128 game sold it in small quantities on eBay so, despite the website having disappeared a few years ago, there are no copies archived. I think I know one person with an original disk and I hope he's at least backed it up...
  3. Said hardware doesn't currently exist so any "comparison" would be completely theoretical even to the point of having to guess about implementation... but nobody said it had to be an even playing field, did they? All we started out with was Faicuai's statement that "it will be impossible for the C64 to show 60fps video, like Avery's SIDE-to-6502-to-ANTIC player [...] with native chipset (no HW modifications of any kind, other than the cart)" (my emphasis in both cases) and, since he's also mentioned that it act as a demonstration of "the platforms' true engineering latitude", a stock C64 with a solution Turbo Chameleon perfectly valid. According to Faicuai there's apparently "NO WAY (none, zero, zippo, nul) to enable 60fps video if you do not have ample storage" so twenty something seconds of 60FPS video coming from a RAM expansion somehow isn't 60FPS video (I wonder how that works...?) but it still serves as a benchmark for transfer speeds. We still have to wander into the realms of "what if" after that point of course, but this hardware exists even if the firmware doesn't right now so no radical leaps of faith are being taken if we talk about custom firmware chucking data straight off the storage device down a DMA or even injecting the current frame directly into the RAM. That doesn't seem too far fetched...? =-)
  4. Yeah... probably should've stuck to that matra myself really, after letting myself be sidetracked by this thread and then falling ill again I'm nowhere near done for X... =-( I'm feeling a bit better today and want to try putting a little more work in over the weekend, but there's no major rush so I'm perhaps aiming for Compusphere since they take remote entries and the deadline is the 26th. So I should probably take your advice and make myself scarce... Kicking the 6510 off the bus is how the SuperCPU, CP/M cartridge, Turbo Chameleon and others work yeah, and the TC is already FPGA-based, with an Altera Cyclone 3 onboard. The default core takes over some of the C64's functions (that's how it gets a faster CPU clock without goofing up the VIC-II, they aren't using the same clock) and the results are funnleled back to the host machine whilst a copy is pushed out via VGA. There's even an audio jack on the side, I'm hoping someone adds OPL support alongside the second SID option, but they always seem busy and I don't want to be a nuisance. The TC has also got spaces available for loading other cores so, along with the option of writing your own for whatever nefarious purposes you have in mind, there's already a version of the MiniMig available along with other 8-bit systems including the Spectrum, MSX, PC Engine, Atari 2600 and Atari 8-bit, sadly without SIDE support at least right now... it'll be more than a little ironic if that goes in though, having a "stock" C64 running Avery's code... =-)
  5. The problem is that I disagree with the wording and see the cartridge as a modification to the system as a whole, adding new features like an IDE interface. Apparently people here don't feel that way however purely because the host machine is unmodified - which is a bit of an odd argument - but okeydokey then, we just have to apply the same definition evenly... I've also been talking about a completely unmodified C64 (well, it has a blue power LED) with a Turbo Chameleon cartridge, meaning it's also "no HW modifications of any kind, other than the cart" and can therefore be described as "stock". But here's the thing... that "stock" C64 has 20Mb of RAM (16Mb connected via DMA which can transfer at a byte per cycle, this is what I've been talking about so yeah, "stock" apparently), over 6MHz of CPU grunt and a slew of other features because all of that is provided by the cartridge. C64 upgrades like the RAM expansion I've been talking about aren't hardware modifications to the machine, they go in through the cartridge port... and now a "stock" C64 is over three times faster than an Atari 8-bit, right? =-)
  6. You only talked about doing 60FPS video originally, no other implications were stated... The same is true for the C64, the cartridge does the donkey work of chunking data around at speed so the standard I/O isn't in use after starting up (the boot program could be loaded from tape if needed, it'd be tiny and a good fastloader'll get that done in no time) and in both cases it doesn't work if you take the extra hardware in the cartridge away. The Atari player seems to be doing (assuming a cursory, headache-impaired search found the right variant) is presenting the ANTIC with data for it's DMA directly from the cartridge where the C64 code I was talking about just "loads" data into the RAM where the VIC-II is looking for it. Doing sampled audio at the same time is more tricky since that data transfer is intrusive on the C64 - the DMA halts the 6510 whilst working whilst the VIC-II "multitasks" and carries on regardless - so restarting the processor every X cycles to play a nybble of sample the "traditional" way is probably not viable with 60FPS playback. From what the devs say about the sample driver in Fantasmolytic (fast forward to 6:22) it'd be at least potentially doable that way I think...? If "stock" includes a whacking great IDE interface plugged into the cartridge port, then you're working with a very odd definition of the term there... but s'okay because a whacking great RAM expansion plugged into the C64 cartridge port counts as "stock" under that definition too. =-)
  7. That's doing I/O through the cartridge port I think...? If that's right, 10K a frame (a Koala format multicolour bitmap is 10,001 bytes of data for 160x200 in 16 colours but it could be pared down to 8,000 for just the bitmap data) at 60FPS is doable from a Commodore-style RAM expansion with some processing time left over, I've got prototypes that use a similar technique to completely rewrite the bitmap and colour RAM once per frame for fast scrolling. For animation that be a little over 600,000 bytes per second give or take and just shy of 28 seconds on a 16Mb RAM expansion (they're surprisingly common these days even if half the people who own them have never enabled the option!) or a smidgeon under 35 seconds just for bitmap.
  8. "Atari owners hate the C64, film at eleven!" If that's all this thread plans on being... why bother? Yes, we (as in the people who lean towards other platforms) get it but restating the "discussion" again won't change anything. Instead of posting, you could be creating something for your Atari instead, the chipset is a "programmable playground to be used in incredible and unexpected ways" after all so spend some time exploring. Or draw some graphics, compose music, learn to do one or more of the above, make stuff not war and show some software-powered love for your platform of choice. Sod it, make a demo about how much you hate the C64 if you really feel it's that important... And with that, we now return you to your scheduled programming.
  9. I'll probably regret this but... bugger it, my effect preset loader had an interesting "feature" that took an hour to find so I need a break! It does, but he said that the C64 had finer horizontal scrolling which is true. The C64 basically works at 320x200 all the time even when displaying 160x200 resolution graphics, that means the latter modes can be moved in half pixel steps where the Atari has to shift complete pixels. It might not sound much, but at lower scrolling speeds that restriction will become noticeable quite quickly and it can sometimes have an adverse effect on gameplay depending on how collision detection is being done. There's also the option on the C64 with the character-based mode used by Ghostbusters to mix between 8x8 and 4x8 pixel mode on a char by char basis; it isn't used to great effect in that particular example - the "Zuul" and "GHQ" text on the main playfield are high res amongst multicolour graphics without using sprites - but other games use this to far greater effect for spot detail on backgrounds.
  10. [Peers nervously into necrobumped thread with dodgy-looking title] Oh dear Rassilon...! Most of my week is going to be spent concentrating on C64 demo code for X'2018, why doesn't everyone just work as a group and put something together for Silly Venture rather than grind over the same, tired old ground for the Nth time...?
  11. That's down to a couple of things; the file browser uses the default upper case only font so "Sex Games.d64" has graphics characters for the first letter of each word which would become upper case if Shift/Commodore were pressed (I forget if the file browser allows that). And since ASCII and PETSCII aren't directly compatible, the character code for a Pi symbol in the latter is the same as whatever appears in the three "pitfall" filenames; it might be a tilde where the filename has been truncated (that'd be my guess based on what's in the list there) or an underscore but I'm not sure off the top of my head... There's nothing actually wrong as such because that's how it's supposed to work - it prods around disk images which may have directory art meant to be viewed in upper case so defaulting to that is sensible - but if you want it to look pretty then renaming of the files should sort things out; change things with caps in the filename like "Sex Games.d64" to "sex games.d64" and swap whatever the Pi symbol is out for spaces. Just don't make the filenames too long because, again if memory serves, it maxes out at the same length as regular C64 filenames.
  12. I've had a few crashes over the last couple of days on demos where the fastloader just hiccups and dies, 1991 by Booze is the first one that springs to mind if memory serves but there were a couple of others...
  13. I still don't know where their version sprang from really, presumably they had to pick up a new license to do a from scratch conversion of a coin-op with that was already three years old; that's pretty bizarre when they could've got something more current instead. One of the things I should still have somewhere in my "collection" is a budget version of Double Dragon but, due to a mastering error, it actually has Golden Axe on the tape... someone returned it to the shop despite the latter being a vastly superior game and still a full pricer at the time?! Well, by that point it was just a brand owned by Virgin if memory serves... by Double Dragon 2 they'd stopped using the name entirely I think? Chances are they just got a video tape of the game being played through, the original coin-op developers usually didn't provide anything - so no dumps of graphics or map data - and even Ocean (who did get coin-op boards to work with at least sometimes) tended to work in the same way from what I gather. I forget who it was, but remember an interview where one dev said they'd sometimes have to take a camcorder into the local arcade and film footage for themselves! Not really, been here for nearly seventeen years and still have the old accent... it's just not a Kentish one. =-)
  14. The publishers were Melbourne House but they farmed the development out to independents, Ash Routledge and Dave Saunders (Ash & Dave from t'demo scene) did the final game that was released but they only got six weeks to churn their version out after a previous attempt fell through. Ocean did produce a version of Double Dragon as well, but it was a few years later for release on cartridge.
×
×
  • Create New...