As there are a lot of members from UK here, the information is probably already known by most of you.
Sundown demoparty will place at the Budleigh Salterton town hall from the 6th-8th of September 2013.
Sundown 2013 | 6-8th September – Budleigh Salterton UK (http://sundowndemoparty.net/)
I may consider to go there.
Who's else will be there?
.
Quote from: eliot on 13:05, 19 July 13
I may consider to go there.
Who's else will be there?
I'm definitely going - already paid and booked my hotel! :)
It's a great, fun party and it's nice to be able to chill out on the beach if you've been spending too much time in a dark room... ;)
I'm thinking of sending a pic for the oldschool gfx compo. Will they have an actual CPC to display it, or will that piccy be "discarted" in favor of the usual C64 stuff? :P
In any case, knowing that a CPC scener will be there is an aditional factor for making the decision to participate with a remote entry.
rb
Quote from: rexbeng on 19:27, 23 July 13
I'm thinking of sending a pic for the oldschool gfx compo. Will they have an actual CPC to display it, or will that piccy be "discarted" in favor of the usual C64 stuff? :P
In any case, knowing that a CPC scener will be there is an aditional factor for making the decision to participate with a remote entry.
rb
A couple of things...
The compo rules as are currently on the website (Rules | Sundown 2013 (http://sundowndemoparty.net/rules/)) states:
QuoteUnless stated, you have to be present at the party to compete. If it is a group production, one member needs to be present, or if the production is from within the UK or Ireland we will consider allowing it upon our discretion.
That said, the home page seems more positive:
QuoteNo platform or generation is a second class citizen at Sundown – we aim to fully support all platforms old and new, so bring your productions! We also allow remote entries for those who can't make it on the day.
I'd suggest double checking with Ruairi as he's usually pretty accomodating (in fact I've just asked him about it in irc, but at the moment his timezone is very different so it might be a few hours before I'll hear back). Also, I know that the 2nd place entry for the oldschool competition last year was a remote entry. But it still might be worth checking before you spend time making the entry unless you plan to release it anyway... ;)
In terms of a real CPC output, I'll probably bring a real CPC even though I'm not currently planning on releasing a demo. However even with a real CPC there, it doesn't necessarily mean it'll be easy to get the output onto the big screen. I still haven't yet built an s-video output adaptor (maybe I should prioritise that!) and my emulator doesn't (yet) have HDMI output working nor do I have a composite output, and even if it did that's still not technically real hardware! So, it'd probably end up as a photo of the screen or as an image upconverted to 1920x1080.
But certainly, if Ruairi says it's OK to make a remote entry, it certainly won't be just discarded because it's not C64. Everybody loved my demo last year, in part because I was the guy with the "unusual" platform!
Oh, if I haven't mentioned it again, prod me in a week or two to remind me to be looking at video output options!
I've just noticed it's me in the bottom left of the last picture on the main page:
(http://www.slengpung.com/pics/Sundown%202012/23332.jpg) (http://www.slengpung.com/pics/Sundown%202012/23332.jpg)
CPC on the left, laptop in the middle, TV for my FPGA emulator behind that and a Dragon 32 on the right. :)
Well, I had read the frontpage so I thought it was pretty straightforward that remote entries are allowed.... hadn't read the rules tho.
Anyway, I'll get in touch with that Ruairi fellow. But I am pixeling for the fun of it in general, so it's not going to be a time spent without worth eitherway. :)
rb
Quote from: rexbeng on 20:50, 23 July 13
Well, I had read the frontpage so I thought it was pretty straightforward that remote entries are allowed.... hadn't read the rules tho.
Anyway, I'll get in touch with that Ruairi fellow. But I am pixeling for the fun of it in general, so it's not going to be a time spent without worth eitherway. :)
Not sure if you ever got in contact with him, but I spoke to him on irc the other day. Remote entries are definitely allowed... :)
Oh hi Ralf
Yes, I already have asked him. Thanks :)
rb
Quote from: rexbeng on 23:18, 06 August 13
Yes, I already have asked him. Thanks :)
Look forward to seeing your picture! :)
I've just booked my tickets, will be nice to see you there!
Quote from: Optimus on 15:23, 07 August 13
I've just booked my tickets, will be nice to see you there!
Definitely! Should be awesome!
I am flying tonight. See you there tomorrow!
Good to meet you earlier! Sorry I was a bit too in the zone finishing my demo to be very coherent...
Great to meet you too! Your fractalius fpga demo was nice!
I had a great time there, meeting new people and watching what everyone is working on!
Yeah, great to meet you!
For those interested, my demo is here: http://www.pouet.net/prod.php?which=61862 (http://www.pouet.net/prod.php?which=61862) (pouët page) and video:
Fractals all the way down (http://www.youtube.com/watch?v=krTd4oCPblk#)
This is done on the same hardware as my CPC emulator and features a tune by mr_lou!
Nice demo!
I can hear my track is missing some echo though, as if you've cut one of the channels.
That's what usually happens when you don't record from a real CPC.
Obviously you haven't cut a channel. It's just whatever emulator you're using that has volume set too low. Most emulators reproduce sound wrong.
It's a shame, even after all this time that it's still not accurate in most emulators.
That's a nice cpc demo :D
QuoteFractals all the way down
Reminds me of those japanese NEC "PC" in 640x200x8 video modes... :)
Gotta verify if this could be done on a PC1512 with mathematic co-processor... sure the 640x200x16 video mode could be fine.
But I suppose it needs a lot of calculus.
Mode1 on CPC is always like "I would need one more colour".
Frustrating.
if in 5 colours it could have been awesomer, but yeah, can't generate a 5 colours mode in bit/binary.
Still an 8 colour (3bit per pixel) would be great, but heavier.
1.5 x 1 pixel ratio ? ::)
Are there demos on Raspberry Pi ?
http://www.pouet.net/prodlist.php?platform%5B%5D=Raspberry+Pi&page=1 (http://www.pouet.net/prodlist.php?platform%5B%5D=Raspberry+Pi&page=1)
not a lot yet.
Quote from: MacDeath on 12:24, 14 September 13
Mode1 on CPC is always like "I would need one more colour".
Frustrating.
if in 5 colours it could have been awesomer, but yeah, can't generate a 5 colours mode in bit/binary.
Still an 8 colour (3bit per pixel) would be great, but heavier.
1.5 x 1 pixel ratio ? ::)
The pixel size in my demo is exactly the same as an overscan mode 1 screen sized at 39x26 characters. It's running at the exact same pixel clock speed of 8MHz. Where it differs from the CPC is that it's a byte per pixel, 3 bits for RGB colour and 5 for intensity/decay.
I'd have preferred running at a higher resolution, but my 8-bit SRAM only works at 16MHz, so to read and decay the intensity gives me a maximum pixel clock of 8MHz.
Quote from: MacDeath on 12:24, 14 September 13
Gotta verify if this could be done on a PC1512 with mathematic co-processor... sure the 640x200x16 video mode could be fine.
But I suppose it needs a lot of calculus.
Yeah, it'd probably be far too slow. This actually started life as a CPC demo and whilst it was quite quick for the CPC, it wasn't anywhere near fast enough for animating. You can take a look though - I've attached it to this post.
It doesn't need calculus though. It's very simple 2D maths (although I might try out a 3D version too).
Quote from: MacDeath on 12:24, 14 September 13
Are there demos on Raspberry Pi ?
http://www.pouet.net/prodlist.php?platform%5B%5D=Raspberry+Pi&page=1 (http://www.pouet.net/prodlist.php?platform%5B%5D=Raspberry+Pi&page=1)
not a lot yet.
Yes, there were at least 4 RPi demos last year at Sundown and gasman (under the guise of Wavesitter) this year (his was the demo that pipped mine to the 1st spot): http://www.pouet.net/prod.php?which=61845 (http://www.pouet.net/prod.php?which=61845)
Quote from: MacDeath on 12:24, 14 September 13
Still an 8 colour (3bit per pixel) would be great, but heavier.
1.5 x 1 pixel ratio ? ::)
Yeah, you need to balance the memory use, so you'd need a different mode (that the hardware in the CPC just doesn't support, and would require a lot of effort to support) to get an 8-colour screen in under 16KB that had a reasonable resolution. And if you consider an 8-colour video mode, how would that be arranged in the CPC RAM, given how cranky it is already? I.e., it wouldn't be AAABBBCC CDDDEEEF FFGGGHHH (encoding 8 pixels in 3 bytes), but ABCABCAB but you need to keep C and argh, horrible.
If that was worked around (i.e., the pixel encoding was fixed in the first place) then you would probably end up with a 224x192 screen resolution (that would be slightly wider on-monitor than the other screen modes) - still fairly rubbish for spectrum ports. And imaging the software graphics rendering code to support that graphics encoding.
The only way to really fix it would to have been to have a completely different graphics system, either bitplanes or some form of attribute layer. And that would be an entirely different computer!
A very nice demo! Congratulations!
Even the CPC program does look nice and has potential to be integrated into a bigger demo.
Quote from: Sykobee (Briggsy) on 10:14, 16 September 13
And if you consider an 8-colour video mode, how would that be arranged in the CPC RAM, given how cranky it is already? I.e., it wouldn't be AAABBBCC CDDDEEEF FFGGGHHH (encoding 8 pixels in 3 bytes), but ABCABCAB but you need to keep C and argh, horrible.
Actually, the CPC could be tweaked to 3-bit per pixel with relatively simple changes to the gate array, as it enforces a 4-clock cycle on the bus, 2 cycles are used for video RAM, 1 cycle for the Z80 and 1 is wasted.
The simplest solution would be to have 2 extra 8-bit latches and 3 shift registers and then have 3 bytes with 8 pixels in each (so separate R,G,B bytes). The current implementation is done with 1 shift register and some masking.
Quote from: ralferoo on 22:39, 16 September 13
Actually, the CPC could be tweaked to 3-bit per pixel with relatively simple changes to the gate array, as it enforces a 4-clock cycle on the bus, 2 cycles are used for video RAM, 1 cycle for the Z80 and 1 is wasted. (Don't forget the CPC was originally designed around a 6502, so it'd have been interleaved CPU and video accesses as originally designed.)
The simplest solution would be to have 2 extra 8-bit latches and 3 shift registers and then have 3 bytes with 8 pixels in each (so separate R,G,B bytes). The current implementation is done with 1 shift register and some masking.
Quote from: ralferoo on 22:39, 16 September 13
Actually, the CPC could be tweaked to 3-bit per pixel with relatively simple changes to the gate array, as it enforces a 4-clock cycle on the bus, 2 cycles are used for video RAM, 1 cycle for the Z80 and 1 is wasted.
Is this something you could demonstrate with your FGPA implementation?
Would be nice once it's finished to see a few 'what if' setups :)
Quote from: redbox on 23:16, 16 September 13
Is this something you could demonstrate with your FGPA implementation?
Would be nice once it's finished to see a few 'what if' setups :)
Yeah, but it's not a real CPC then... ;)
And I actually run at a 16MHz clock, so I have 13 unused cycles in the cycle of 16! But I was planning to allow them to be used for an optional turbo mode... :D
Quote from: ralferoo on 22:39, 16 September 13
Actually, the CPC could be tweaked to 3-bit per pixel with relatively simple changes to the gate array, as it enforces a 4-clock cycle on the bus, 2 cycles are used for video RAM, 1 cycle for the Z80 and 1 is wasted.
The simplest solution would be to have 2 extra 8-bit latches and 3 shift registers and then have 3 bytes with 8 pixels in each (so separate R,G,B bytes). The current implementation is done with 1 shift register and some masking.
Well, not RGB bytes but different bits of the palette index. This is more of an interleaved bitplane video memory representation - AAAAAAAABBBBBBBBCCCCCCCCaaaaaaaabbbbbbbbcccccccc...
MODE 1 would be the same but AAAAAAAABBBBBBBBaaaaaaaabbbbbbbb... and I see no reason to not allow a 1 bitplane MODE 1 (and 1,2,3,4 bitplane MODE 0s) as well if that would be possible with few changes.
I expect that would have required a bigger gate array, and thus extra cost, and thus wasn't considered. But that bigger gate array could have allowed for a bigger palette potentially.
It would be interesting to see an FPGA CPC with this mode implemented - but totally incompatible with all software (I guess the firmware can be patched for some compatibility, and MODE 2 stuff should be the same). Still, as part of a "Turbo-CPC" implementation it could be cool to play around with.
Ooh, this is actually pretty!
Quote from: Sykobee (Briggsy) on 08:51, 17 September 13
I expect that would have required a bigger gate array, and thus extra cost, and thus wasn't considered. But that bigger gate array could have allowed for a bigger palette potentially.
Yeah, interleaving the bytes requires more space in the gate array for latch/shift registers. The existing implementation is about as simple as you can make it: the register is latched with new video data at 2MHz and the register is shifted left every pixel clock (16MHz for mode 2, 8MHz for mode 1, 4MHz for mode 0). The index to the palette register is formed by reading bits 1,5,3,7 and masking to the size of the palette in that mode.
Interesting, the BBC micro takes the only option to simplify this further - omitting the palette mask, so for mode 2 (or as they call it mode 0), you have to set all the even palette registers to colour 0 and all the odd palette registers to colour 1.
The palette registers are by far the most expensive part of the gate array - 17 8-bit latches takes up quite a lot more silicon than the rest of the video logic in the gate array.
@ralferoo: I am sure your design is close to the original design.
Why 8-bit palette? 5 bits is enough for each, however, it may be more complex to do it this way.
I wonder if we could get the gate-array decapped and scanned like they have done for the visual 6502?
I do have one lying around I could donate.
The Visual6502 site features a donate site where they encourage people to send in their boards or chips.
visual6502.org HW Donation (http://www.visual6502.org/donate_hw.html)
Quote from: arnoldemu on 09:37, 19 September 13
@ralferoo: I am sure your design is close to the original design.
Why 8-bit palette? 5 bits is enough for each, however, it may be more complex to do it this way.
I wonder if we could get the gate-array decapped and scanned like they have done for the visual 6502?
I do have one lying around I could donate.
Sorry, my bad. They are 5-bits wide! I was still thinking about the latches needed for video memory! :)