Quote from: saehn on October 20, 2010, 01:01 AMIt's little more blocky, but I bet that wouldn't matter much in motion.

OT: As for blocky. I made a little FMV experiment for the C64 a few years ago. My goal was to have something streamed from floppy running at 25fps, so I picked a simple animation and didn't worry too much about the visual quality. In case you decide to check it out, you need to press fire button on port 1, not port 2. Silly mistake 

The C16 is the same as a Plus/4 but with only 16KB of RAM and no 3+1 software. Just go to the Plus4 settings in VICE and reduce the memory to 16K and you have a C16

Parallel cable now installed and working.

I decided it would be nice to add a parallel port to my 1571 (will be the socketed kind) and started taking it apart. First I noticed the mainboard looking like it has had some patches applied (a bunch of cables soldered between some of the chips etc). I then started looking for a 6526 chip, but there were none.

After removing the mechanism I got a better look at the mainboard and it said 1570... Also, the chip sitting where the 6526 is supposed to be is a 8520R3, which seems to be an Amiga CIA chip!?

I got it second hand, so I don't know its story, but atleast the case says 1571 and it works just fine with my C128 (and with opencbm)

Is it safe to assume the 8520R3 is similar enough to a 6526 to work with a parallel cable?

The IDE64 guy has schematics for a 12V DC to 9V AC converter here. I wonder why nobody with the required tools and knowledge offer something like that for sale. I would buy a bunch for sure, and I can't be the only one who have old PSU's which may fail at any time, killing the C64/C128... I know protovision used to sell modified PC PSU's for use with C64/C128, so they must have been using some kind of converter.

I think you are producing too many cool toys for us all to play with

OT: Any chance you could have a go at a SID cartridge for the Plus/4 and C16?

But neither the StereoINsid nor the SID2SID board can be bought fully assembled and ready to use AFAIK, making them useless for anyone who hasn't mastered the soldering iron yet (like myself).

Do you know if a 6582 could be used with the cartridge? And would it be possible to use one of your cartridge expanders with both the midi interface and stereo cartridge active at the same time? That would be really cool

Oooo, nice, me want one, or two

I have a stereo sid cartridge at home, the one which requires a 9V battery and is therefor almost never used.

BTW is there an easy way to tell the difference between the 9V and 12V version?

That cartridge expander looks nice too

I remember reading about the Flash8 in the early 90's, and was interested in one, but it apparently was delayed quite a bit and by the time it was available I was mainly using my A1200. The SuperCPU game Metal Dust started its life on the Flash8, but IIRC, the Flash8 wasn't very stable which slowed down development a lot, and in the end, a SuperCPU would be required.

Quote from: strandedinnzAmiDog : You the same guy who did/does that mpeg player for the Amiga ?  Hello again if you are, I sent you a test DVD ooooh way back in time when I was living in the UK... that project still on the go ?  Going to do an C128 port ? ;-)

That would be me, yes Not done any work on it for a few years though. A C128 "port" would be an interesting project...

Well, I have a dedicated room in the house for my toys (mainly Commodore and Amiga computers of all kinds) which I can fill with anything I want. And my better half doesn't care what I do with my money any more than I care what she does with hers (like buying books).

Have a look at the IDE64 News page, the last progress update on the new V4 is from August 01, 2007.

I will buy one as soon as it's released.

Well, there were some plans to use the REU to shuffle the graphics around in Pinball Dreams 64. That later change to linecrunching (and thus smaller playfield) as few people have REU's. I played around a little with such a routine myself, and used the REU RAM to store and scroll a really large image

The REU was also used in a demo to change the background color in each cycle, thus creating a nice effect in the border.

I think Cheap Threads might be what you are looking for. Topsy is a bit more advanced, but might be of interest...

I should probably try the demo with my TV (29" Sony CRT) some day...

Some more information. With the default settings of the demo, if I reverse the fields, I actually get an interlaced image, but with weird colors.

1. Feel free to quote them :-)
2&3. Ok, some more figures:

Odd as 298, 60, 3
Even reversed: 300, 21-26 (best: 23), 4
Even normal: 300, 44-48 (best: 46), 4

Odd as 299, 26, 4
Even normal: 300, 9-11 (best: 9), 3

Certain other cycle values will give an interlaced but very unsteady (shaking) image. The values above are the one giving a quite stable but still clearly interlaced image. For the first example, if I go further than cycle 26, the interlace effect fades away. It's almost like the cycle will decide the amount of interlace effect, from full (the "best" values) to non at all. Also, only certian cycle values will give the correct colors, most give some weird colors and a few a completely gray image.

Don't know if you've read this about PAL encoding and the Risen from Oblivion demo:

QuoteThe new colors work because of the PAL color encoding: The color carrier consists of U (blue-yellow color distance) and V (red-cyan color distance) which are simply added together, so C = U + V. Now, because a decoder needs to seperate U and V again, the inventors of PAL used a simple trick: They inverted the sign of V every 2nd rasterline, so you always have C = U + V followed by C = U - V. This way you can simply take the color carrier of the previous rasterline and add or subtract the current rasterline with it. If you add both carriers you get back U, and if you subtract you get V or -V. Now, if you skip an odd number of rasterlines, you get -V where normally would be +V and you get +V where normally would be -V. -> The red-cyan color distance gets inverted.

http://noname.c64.org/csdb/release/?id=2942

I've now managed to get my PAL C128 to display a true interlaced image on my 1084 monitor.

The default settings didn't work and just gave a flickering image with weird colors. Not the usual green, not gray, but some other annoying flickering mess Maybe something similar to the way Risen from Oblivion creates some completely new colors, but somewhat interlaced, producing some flickering mixed colors...

Anyway, I first decided to try to get the colors back to normal. I left the even field settings at the default and started changing the odd one. First increasing it without result, then decreasing it. These gave the usual green:

Raster: 298
Cycle: 60
Cut lines: 3

I then modified the even field settings until the circle started looking properly interlaced. I then tried to choose the values which gave the best possible image, and got these for the even field:

Raster: 300
Cycle: 48
Cut lines: 4

If I view the circle image with interlace disabled and switch between fields, it's obvious they both contain some lines one pixel from the upper and lower border. Enabling interlace and those become thinner and are clearly displayed on different lines. Hey, my C128 has got a 400 lines VIC display! Nice Reversing the odd/even fields make the circle look very "jagged", which again shows the interlace is working

Trying the 50 rows text screen. With interlace the 'e'-letters really look like 'e'-letters and are easy to read, without the interlace enabled, they just looks like some blobs

I also looked at the other images, and while the dither one flickers quite bad, it also clearly shows the interlace effect. The pixels get thinner when interlace is working properly and don't just flicker on/off as when it's not...

The "CMD SUPERCPU RAM EXPANSION & TIMING" (suprtime.pdf) document covers just about everything I think. It will still be quite a challenge getting everything correct and running at an acceptable speed. After all, each and every read/write to SuperRAM memory will require computing any delays (incl. halfcycle delays) caused by non-sequential accesses, row/col changes etc...

I wonder if this method could be used to add SuperCPU emulation as well. It would require a 65816 CPU core, but as everything but the SuperCPU itself should still run at 1MHz, this method does sound interesting. Would be a fun project I think

I have a PAL C128 ready to try some interlacing once the new demo is finished.