Posted By
MMS
on 2024-04-02
19:15:44
 |  Re: Jiffydos on C16/Plus 4 > black screen flashy
So I bought the JiffyDOS ROMs to make some testing.
I bought PAL Plus/4 Jiffy, 1541 (16KB) Jiffy and 1581 Jiffy
(in fact I own two devices has JiffyDOS, and from MCes C16 Kernal with Jiffy, but I wanted to test 1581 too, but I do not have the drive (yet))
I tried the terribly slow, full multicolor picture loading "A Gyuruk Ura" BASIC game. I like this game from my childhood.
(this is a simple Fighting Fantasy clone like the books from Ian Livingstone)
Actually with my original setup (C16 64K + 1541/II) it was simply terribly slow.
But I repeatedly checked it as a kid as I really liked the full screen pictures (mainly stolen from somewhere else).
During emulation tests with 1551 it was just barely acceptable.
I was interested, what could be the JiffyDOS speed? (tested in Plus4emu)
1541 with Jiffy: each full screen picture (initial ones 40 blocks) loads in 5.5 secs
later split screens pics 24 blocks loads approx in 4 seconds
1581 with Jiffy: each 40 block picture loads in~2 seconds
later 28 blocks size pics loads in ~1 seconds
I have to mention, that I noticed both in Plus/4 emu and YAPE unstability of 1541 Jiffy, even with high 1541 accuracy timing, or no special timing. 2 of 10 Directory command crashed at the middle of the list. Sometimes reported "file not found" although the file was there, and second trial was OK.
The 1581 with Jiffy is even more impressive that I thought. Huge capacity and really really fast.
But the blanking of the picture... It is not nice.
It is told by Retroshine:
"Maurice Randall and Attila Grosz:
There's no way, believe me I tried. That's why I spent so much time
on this. Even with the screen blanked and the processor switched to
.894 mhz, TED got in the way. I was pulling what hair I had left.
But I finally figured it out yesterday.
It's only the fastload routine where the screen gets blanked. The
128 JiffyDOS in 40 column mode also blanks the screen during
fastload. All other transfers that use the kernal CHRIN, CHROUT,
CIOUT, and ACPTR routines are done without blanking the screen.
JiffyDOS needs about 88 clean clock cycles to get one byte loaded
in during the fastload routine on the C-16 and PLUS/4. And it has
to do this 254 times for each sector."
It is evident, that Maurice faced the same problem, as the C64 FLI VS Plus/4 DFLI, that there is not enough rastertime to execute the task with the color and luma attribute need an update. It is interesting, that he SLEW down the CPU instead of increasing the speed of it.
I am sure Maurice Randall is a great (I mean much better than me or Average Joe) programmer.
BUT
Reading though this, and comparing it to C128 he mentioned, something came into my mind: C128's CPU is NOT switched to 2MHz mode on the border, as the VIC-II would show some weird stuff on the borders, developers did not allow to happen. VIC is NOT prepared for a fast CPU. So the CPU of C128 stays in the 1Mhz mode, except it is swithed to FAST mode and no screen visible.
On the other hand, TED is prepared for that higher CPU speed, even more it switches the CPU to a faster speed (and back). So, I can say, C16 is faster on the border area than a C128, and it is valid AFAIK for the upper/lower border area too.
It is stated "JiffyDOS needs about 88 clean clock cycles to get one byte loaded".
We have a faster CPU on the upper/lower border area. It runs on 1.76 MHz, next to that, as Bubis stated:
"This is why you can only count 109 cycles even on the border."
I the VIC-II document by Christian Bauer stated that there are 312 raster lines, and 284 is visible on the screen.
so as Plus/4 has a very similar setup the 312- 200= 112 rasterlines of non screen area is there, but TED provides some cycles to 7501 to switch over, so the 109 cycles looks pretty exact.
So the question: why JiffyDOS NOT using the Upper/lower border area to load that 88 cycles data, if we have 109 CLEAN cycles without TED impact/interference?
I mean Jiffy could do the fastload WITHOUT switching off the screen, just by starting the load routine at the last visible rasterline, and can do the load at border area).
Or maybe we need load routines to happen on the screen area? And if yes, why?
Even more (if 1.76MHz does not provide enough "juice"), during that period our CPU could be switched to a higher clock mode, as per SVS Ultimate map, even 2.16MHz is possible. I've never done this, but if the CPU switched back in time (upper border) then there should no interference when TED switches back to the visible rasters and low FRQ.
Probably Maurice wanted to finetune the C64 Jiffy routine to our machine, but the lot of badlines prevented it. Swithcing off the screen is a kind of easy solution.
My suggestion is to load during the upper/lower border area, and we have all the clean raster cycles JiffyDOS really needs.
Certanly a sector loads needs this 254x, but I think 100 clean raster cycles is comparable to the 200 "not clean" cycle's CPU time, especially if Maurice stated 88 clean cycles needed. (one thing I do not get: why the C64 does not load on the border, too? Is there ANY benefit NOT loading on the border area?)
1581 with Jiffy is a beast, 1 full screen multicolor picture within 1.0 - 1.5 seconds? Crazy.
But a loading with screen ON would be a great improvement or achievement.
UPDATE
@BSZ, @SIZ : you also have no idea, if the JIFFY loading could be done with switched ON screen, if the JiffyDOS would only loads only the upper and bottoem border area?
I do not see why the TED would be a problem there. It is definitely not operating, giving the CPU an other FRQ.
|
