Jump to content

TMR

Members
  • Content Count

    3,471
  • Joined

  • Last visited

  • Days Won

    2

TMR last won the day on April 20 2012

TMR had the most liked content!

Community Reputation

729 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

21,235 profile views
  1. No, I believe you're right at least with the 8-bits. The Plus/4 can get quite close for the colours but needs twice as much code and a whacking great table of timing values since there's no WSYNC.
  2. Guess who is back girls and boys! 😃 I’ve been online for a while now, but let’s make this "official", I’m still in the same bed at Jimmy’s that’s been my world for the last year and a bit and have a slow journey ahead physically with physiotherapy and speech issues (I have odd vocal cords it seems…?) but long Covid doesn’t appear to have touched my mind, something I’m grateful for considering te effect it had on Derek Draper – I’m an atheist but the most appropriate phrase I can think of is "there but for the grace of God go I". I’m not allowed food right now because my stomach has a problem and I’m having dialysis three times a week, in fact that’s going on as I "speak". I’ve got a cross assembly rig on this laptop too so have been tinkering with some 6502, resurrecting a couple of code doodles for rlease as part of my Monthly Demo series. The "grand return" after my long Covid hiatus is MD202104 on the C64, but MD202105 is already up and mostly working the way I want it to an ORA’d filler and a couple of DYCP scrolls done the "C64 way" on the A8 as a "comeback" to this side of the 8-bit demo scene. None of these are massive projects because I don’t know from day to day how much coding time I’ll get and don’t want to overstretch myself right now so I can hit the deadlines for release, but they’re enough to keep me occupied. So my reason for standing up so brazenly and announcing my return like this is because I want to say "thanks very much" to everyone who sent heart warming messages here, through PM and via the scroller on MD202006 with an extra nod to Mclaneinc; I stumbled over these messages on a day I was feeling pretty down so everyone’s positive posts really lifted my spirits and what you said was a fabulous cherry on an already lovely cake. I have a quite solitary and I suppose overly cynical view of the world and thought "they’re just online friends, nobody’ll care" so it’s been utterly brilliant to be proved so ridiculously wrong in that respect. So TL;DR version; long Covid 19 tried to feckin’ kill me (I had a heart attack!) and I’ve had a year away because of all that, but now I’m back because you lot made it so worth doing. Thankyou everyone for that. 😃
  3. TMR

    TMR

  4. 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...
  5. 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...? =-)
  6. 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... =-)
  7. 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? =-)
  8. 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. =-)
  9. 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.
  10. "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.
  11. 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.
  12. [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...?
  13. 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.
  14. 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...
×
×
  • Create New...