Jump to content

sack-c0s

Members
  • Content Count

    1,213
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by sack-c0s


  1.  

    About the quality, a machine in which the playing characters take on the same colour as the background does not bode well......

     

    That's looking at the issue in hindsight from a more privileged 'I can get hold of multiple 8-bit machines, so I'll just play it on the best platform for the job' point of view of today (or a really lucky bugger back in the day). For a massive amount of British kids there computer options were:

     

    1) ZX Spectrum

     

    2) Go without

     

    Making the humble Speccy the best option of the two. Of course it's not quite that simple, because that decision multiplied by a few hundred thousand people causes a critical mass of sales and the question then becomes 'what computer can I afford that allows me to swop C90s in the playground with friends?', which in some areas makes people choose the Speccy over the C64


  2. That C64 pic looks really nice. It is very cool how it can display a hi-res sprite over a med-res background.

     

    it's actually a hires sprite over a med-res colour sprite to give the illusion of multicolour. Bit of a pain in that you burn 2 sprites instead of 1, but given that the player sprite is your main focal point it's a fair enough trade to make...

     

    the fact you can mix highres and multicolour characters on the same screen is pretty neat though - you can give the impression of higher resolution that way if done carefully (IIRC the stars you collect are highres characters)

    • Like 1

  3. on the C64 you have a chunk of colour nybbles at $d800 - normally this will determine the colour of the characters in character mode, and another block of character memory, which can be relocated within certain constraints. In multicolour bitmap mode the colour can either come from the background colour, colour ram or the character memory.

     

    00 - background colour ($d021)

    01 - High nybble of character memory

    10 - low nybble of character memory

    11 - colour memory at $d800

     

    I might have the character memory nybbles the wrong way around though, so TMR will be along shortly to pull me up on that one if that's the case :)

     

    How that's stored in a file depends on how the coder felt at the time- it's pretty much going to be some sequential combination of those in a format that can just be dumped into the right bits of memory. A quick google shows for koala format it's:

     

    (relative to beginning of file)

     

    Bitmap: $0000-$1F3F

    Videoram: $1F40-$2327

    colourram: $2328-$270F

    Background: $2710

     

    http://www.editorix....ts__part_i.html seems to have a list of various file layouts


  4. Nope.

     

     

    Masses for classes? No!

     

    Some parts are very well. But, if you prefere megabytes instead of quality, I could preserve some megabytes of animations, or crude sounding digitized music..... filling 100s of disks. You like?

     

    I'm impressed with the size of your contribution actually - 0 bytes...

    • Like 4

  5. When using double speed, you need to call the rmt_play soubroutine twice per frame, 156 scanlines apart. ie at scanline 0 and 156. When you call it in VBI twice in a row, you "degraded it to 50Hz ". Or you can call it twice in VBI, but remove SetPokey call in rmt_play routine and do:

     

    jsr rmt_play
    jsr SetPokey
    jsr rmt_play
    

     

    and in middle of screen some interrupt to call SetPokey. Correctly you should call Setpokey first as the audio registers should be updated at exact time (just adding some copying of registers from here there and back) but as I'm musically deaf, I think I would not recognize the "jitter" caused by variable rmt_play routine time.

     

    People put a load of effort into adding that jitter and calling it 'humanising' anyway, so I wouldn't worry about it :)


  6. I think trying to force one to act like the other just drives you mad in the end - they're different and the best you can do is keep your game logic out of your machine specifics and suck up the extra work.

     

    That said as a compromise there ought to be an example bit of code that for a minimal machine setup that is as close to a commodore 64 (or plus4) as you can reasonably get that will get people up and running.

     

    Although in my mind all I can think of right now is something that loads at $0810 and sets up a 40x25 multicolour character screen at $0400


  7. I've read your post several times - it's still not HDR.

     

    Whilst I'm sure that you can process a floating point framebuffer in 6502, and tonemap result down to the colour depth that the target machine can handle I'm not really sure that's feasible unless you are willing to wait a good long while for each frame to come out.

     

    if anything it looks like an application of depth-based fog in that demo


  8. or just fill 2^n bytes with the numbers 0-18 (as evenly as possible). Then generate a random number, use an AND to mask down to the relevant number of bits and use that as an offset into your table.

     

    It won't be mathematically correct, but it should pick a reasonable distribution of screen co-ords if your initial random number generator is okay so it'll do


  9. Not really. There are some C-64 coders who dabble in A8 coding and hang out here a lot. Though anything resembling an A8 vs. C-64 discussion tends to quickly devolve into flaming and the mods will shut them down pretty quick now.

     

    I started on the C64 but think of myself as a fan of anything with interesting custom chips really. I was thinking 6502 fan, but then the Amiga, sega mastersystem, megadrive and other things caught my attention too.

     

    I think I just have a compulsive urge for hammering chipset registers in assembler...

    • Like 1

  10. That's true. But I wouldn't expect something like "Boogie Nights" by TMR (for example).

    We're talking in an Atari Forum, so it's not relevant how good they do their real job. It's about Atari. Simple as is.

     

    If people were to match my current pay I wouldn't have any problems writing Atari/C64/Amiga/whatever games for at least 7-8 hours a day, all week - and I guess I'm not the only person around here who would be happy to take up that offer. Seeing as that's a proposition that's never going to happen, combined with a whole selection of 8 and 16-bit machines out there I'd like to get acquainted with I'm just going to have to do the best I can with my limited time.


  11. I'm working my way around a Commodore 16 framework - I've got it up and running on the C64, but it seems to suffer from not having the colour choice that the C16 has, but I'm guessing that even though the colour placement isn't as good on the Atari people didn't monkey around with the colourRAM so much due to having to cram everything into 12k of RAM and it'll all balance out nicely.

     

    Once that's done I can have a 'new old' games running on the Atari. Failing that I've got a few 6502-based MAME ROMs in my sights. One pretty much loaded into the C64 and ran but the screen didn't quite fit, but I can push the screen out a bit on the Atari and it'll work I think


  12. I can't believe I posted this *four* years ago - time flies... some of my UK memories

     

    http://www.atariage....to#entry1439075

     

    This made me laugh a bit...

     

     

    More esoteric reminisences:

     

    - The man from Intoto in Nottingham allowing me to buy Artworx' Strip Poker at the age of, erm, 12 or 13, but telling me to wait until the other customers had left.

     

     

    IIRC Intoto (it was down Hockley wasn't it?) was owned by one of my dads mates, so I never tried that for obvious reasons :)

     

    How I miss those swopping sessions at the Nottingham Microcomputer Club...


  13.  

    much better support hardware - the SMS graphics chip isn't that different from the one in the MSX and has it's own memory pool to avoid contention and cycle-stealing from the CPU. The speccy basically has a 2bits per pixel framebuffer and colour RAM and that's it.

     

    okay - I ballsed this post up and nobody realised until after the edit deadline passed.

     

    I meant *1* BPP, giving *2* unique colours per 8x8 cell...

    • Like 1

  14. regardless of whatever your feelings are on people around here and your own pet subjects - can't you at least acknowledge that some threads are for people who are just trying to get a solid grounding with the intention of working their way up in the future?

     

    You wouldn't tell a kid wiring a bulb to a battery in his first ever electronics class that it's crap, he's wasting time and he should be working on cold fusion instead, would you?

     

    well - I wouldn't anyway...


  15. for fecks sake...

     

    A newcomer turned up looking for advice and what he got was this thread, mostly derailed by Emkay pushing his personal agenda (which he personally can't be bothered to code) again, causing confusion. If I were coming into this thread to check answers to my question because I'd gotten the urge to code something I'd think 'sod this' and go do something else instead.

     

    Don't you get it yet Emkay? This is counterproductive. Even if I were some kind of deranged C64 fanboy who wanted to use every trick in the book to prevent people writing anything new for the Atari I couldn't do *half* the damage that you do by taking these threads off at your own skewed tangent.

    • Like 4
×
×
  • Create New...