pouët.net

also enjoy the video

ryg the cpu isn't "significantly" faster.. i can port for instance the "ball" to c64 without major optimizations, and it will be equally as fast. the problem is that the ted slows the machine significantly down if not in the border.. we must switch to doubleslowness aswell because of the loader many times, (so it's slower than a c64 at many times). but ryg, great to hear youre alive! :)

Ok talked to krill again about his loaderport. It was my fault to say the loader slows something down.. it's the fastest irqloader on plus4 and consumes only the cylces we give to it.. so we finally have that cool loader for our machine.. Big thanks Krill!

First of all big thanks to Krill from me too. Krill is quite a beast: After he was done porting, I received one single version of the loader and it ran like a charm on emu and real-iron without the necissity of any further debugging. Prussian accuracy ;)

To clarify on the machine-speed-topic: In the display-area the cpu runs slightly below c64-speed and doubles the MhZ in the border-area. I don't remember the figures, but on a "normal" screenmode you get about 2000-4000 cycles/frame extra compared to a c64. Sounds like a big advantage but you also have twice the amount of DMA-Cycles (=badlines) than on c64, because the videomatrix is twice as big.

For example Mad's ball-part (which my wife correctly identified as the easter-egg) works on a special screenmode that requires even twice the amount of dma-cycles - compared to a normal screenmode. For other kinds of demo-effects you need to have two STA's to write to the videomatrix. So lots of times this "double-clock-rate-advantage" melts down to "nothing" at best. There are lots of occasions where you end up having less cycles than on c64.

In my understanding Krills Loader switches down to the single-clock-rate for mainly three reasons:

1. The Floppy runs at roughly 1MhZ and thus you won't have any advantages from "polling" the data at double-clock-rate.

2. Timing at double-clock-rate is annoyingly difficult and inherently instable because you still have 5 or so cycles per rasterline that run at single-speed. The horror...

3. It's an irq-loader that can be interrupted at any time. You simply can't put a detection of clock-speed-changes into a *fast*-loader in an efficient way.

Hope i wasn't talking too much bullshit here. Anyway: If it looks the loader slowed down something in the demo, its because i failed to integrate it properly ;)

@charlie: yeah, you really saved the day! thank you so much! ;)

WinVice for plus4 is suboptimal, you could try "yape" which does a better "mapping" of the plus4 hardware.