sack-c0s

I'd been wondering if the fact that you can gain enough control over it would mean you could use the GPIO pins to code up a device emulator - I thought of trying a 1541 emulator, but if that's possible then maybe SIO would work out too. I know some folks say it's overkill dedicating a whole system like this to such a task, but I see it more as freely reusing something people have rather than explicitly going out to buy something new, regardless of how cheap that thing might be

somehow I'd imagined that SIO99 would be more concerned with the choice of BASIC dialect rather than spoken language...

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

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)

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

I believe the Mayans were saying that too...

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

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

still waiting for your game, Emkay...

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

suddenly the 6502 switching overhead doesn't seem quite so bad

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

but it's not HDR. Go back and read the wikipedia page on the subject and give it another go.

You can't really get any more oldschool than Hucknall - Ada Lovelace is buried there Oddly I grew up on the edge of Bulwell and didn't find that out until after I left - I must've passed that church hundreds of times

Would you care to explain to use what you understand by HDR in this context?

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

Nope - it's the trendy end of Nottingham (or for me 'the way to the old angel' for a recovery pint or two )

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...

I can't remember how I did it - I think I used the driver to find the load addresses for the ROMs and then just probed around the debugger

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.

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

This made me laugh a bit... 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...

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...

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...

wasn't so keen on unshaped (not so keen on that style of music really) - but the other 2 were pretty damn awesome