| Posted By
Retroshire
on 2021-01-26
03:22:53
|  Jiffydos on C16/Plus 4 > black screen flashy
Is it common experience, that the black screen flashes, when loading with Jiffydos on a 264 machine?
|
|
Posted By
siz
on 2021-01-26
04:17:25
| Re: Jiffydos on C16/Plus 4 > black screen flashy
JiffyDOS for the plus/4 series is "not so polished", so this is normal. For some reason (to avoid badlines disrupting timing??) it writes to current raster vertical position ($ff1d) register.
I made a patch for myself to get rid of this because it was very annoying as my RetroTink2X lost sync every time I loaded something with JiffyDOS and also started talks with Jim Brain to include it as an official image but the conversion went to a halt at some point (on my part).
|
|
Posted By
gerliczer
on 2021-01-26
04:58:46
| Re: Jiffydos on C16/Plus 4 > black screen flashy
How did your patched version work compared to the official one? Was it perceivably slower or was there no throughput difference worth to mention? Why did you stop the talks?
|
|
Posted By
siz
on 2021-01-26
05:37:06
| Re: Jiffydos on C16/Plus 4 > black screen flashy
I haven't noticed anything unusual/slow down. The only difference is that the background color is not set to black and screen does not flash during load.
The talks stopped because Jim asked me why those code parts were in the original version at all and I didn't have the time to analyze it.
|
|
Posted By
Retroshire
on 2021-01-26
06:54:16
| Re: Jiffydos on C16/Plus 4 > black screen flashy
Is this the case with both PAL and NTSC systems?
Here is an extract of an 2006 discussion on the topic:
https://groups.google.com/g/comp.sys.cbm/c/3Sip7sQCdm8
Between 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.
The 64 can do this without blanking the screen because it only has
to avoid one bad raster line out of every 8. TED gets in the way
for 2 raster lines out of every 8.
Even with the screen blanked and at .894mhz, TED still causes
a problem, but this is what I was finally able to work around.
Early on, I was able to make the fastload routine work with the
screen displayed and only the clock speed slowed down. But the
fastload transfer times weren't acceptable due to having to avoid
the two bad raster lines. The time spent avoiding those lines
caused the disk drive to miss the next sector in the interleave
and it had to go around again. None of the fastloaders on Bo's
site are able to keep up with the interleave on the disks I've
been testing with. The VIC-20, 64, and 128 all keep up just fine.
So, to have the C-16 and PLUS/4 with JiffyDOS not be able to keep
up as well just wouldn't be acceptable.
To the end user, all he notices is the screen blanking just like
the 128 in 40 column mode. This I can live with. What's actually
going on underneath doesn't matter as far as the user is
concerned, he's just looking at a blank screen for a very, very
short time.
One of the test files I've been using is a game called "WU LUNG"
which I downloaded from Bo's site. I used this because it's
big enough and gives me enough time to listen to the drive while
it's loading. I can hear the stepper motor moving as it changes
tracks.
At 117 blocks long, this file loads in about 9 seconds on a 1541.
It only took just a little under 5 seconds on a 1581 with JiffyDOS.
This is due to the 1581 being able to load a whole half track
into it's own memory. The 1541 can only load 1 sector at a time.
Other fastloaders took 25-32 seconds on a 1541.
On a stock 1541, with no fastloader, it took 1 minute and 15 seconds.
From the above results, I think I succeeded and we can live with
a blank screen for the short time it takes to load a file. A 49
block file loads in just 3 seconds on the 1541.
|
|
Posted By
siz
on 2021-01-26
07:09:32
| Re: Jiffydos on C16/Plus 4 > black screen flashy
> Is this the case with both PAL and NTSC systems?
I'm not sure. I have access to PAL machines only. But tested with SD2IEC and 1541 and both of them seems to be perfectly reliable.
|
|
Posted By
Retroshire
on 2021-01-26
07:45:00
| Re: Jiffydos on C16/Plus 4 > black screen flashy
@Siz, you mean with your patch and without screen blanking?
Strange, Maurice refers to screen blanking as if there no flickering, just a smooth blank screen.
Wonder what is visible at the screen of the C128, who is also blanking the screen with Jiffy.
|
|
Posted By
siz
on 2021-01-29
16:24:01
| Re: Jiffydos on C16/Plus 4 > black screen flashy
Yes, I mean my patch. It DOES screen blanking but prevents flickering. I'm pretty sure it depends on the display used because it' barely noticable on my old CRT monitor.
Edit: I've created a KERNAL load test to check the stability of loads. and ran it on my plus/4 with my patched JiffyDOS version and an SD2IEC. (In fact it's still running behind me because I forgot to stop it). After 1.5 hours no load errors so far. So (at least for PAL systems) the screen flickering can be avoided.
|
|
Posted By
marcos64
on 2021-02-21
06:23:56
| Re: Jiffydos on C16/Plus 4 > black screen flashy
Is it possible to have a patch with only the code you have modified (not the entire ROM)?
My trinitron flickers like crazy 
|
|
Posted By
siz
on 2021-02-21
15:45:47
| Re: Jiffydos on C16/Plus 4 > black screen flashy
These are the differences between the original and my version (address, original byte, new byte):
0000E6D7 8D 2C
0000E704 8D 2C
0000E725 8D 2C
0000E728 AD 2C
0000E72D 8D 2C
0000E732 EC 2C
0000E73D 8D 2C
0000E76E 8D 2C
0000E771 8D 2C
0000E776 8D 2C
0000EB77 20 4A
0000EB78 20 49
0000EB79 20 46
0000EB7A 20 46
0000EB7B 20 59
0000EB7C 20 44
0000EB7D 4A 4F
0000EB7E 49 53
0000EB7F 46 20
0000EB80 46 56
0000EB81 59 36
0000EB82 44 2E
0000EB83 4F 30
0000EB84 53 31
0000EB85 20 42
0000EB86 56 20
0000EB87 36 28
0000EB88 2E 43
0000EB89 30 29
0000EB8A 31 20
0000EB8B 20 31
0000EB8C 28 39
0000EB8D 43 38
0000EB8E 29 39
0000EB8F 31 20
0000EB90 39 43
0000EB91 38 4D
0000EB92 39 44
0000EB94 43 20
0000EB95 4D 20
0000EB96 44 20
The main changes are the instructions replaced with bit $xxxx ($2c). The change from $eb77 is optional - I didn't like that JiffyDOS copyright message was centered while all other messages are left aligned. 
|
|
Posted By
marcos64
on 2021-02-22
03:23:07
| Re: Jiffydos on C16/Plus 4 > black screen flashy
Thanks!
Moving the Jiffydos message is a good idea, so it is easy to know witch version you are using.
Yesterday I misplaced the Compact Flash adapter I use on my old PC laptot and I burned the Compact Flash, so no EPROM burner nor XE1541 or M/PTAP at the moment. I have to wait to test it on the real hardware.
|
|
Posted By
BKP
on 2021-03-26
08:15:06
| Re: Jiffydos on C16/Plus 4 > black screen flashy
Hi. Where can I download JiffyDos ROM to C+4?
I made SD2IEC and now I would like to expand it further
|
|
|
|
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.
|
|
Posted By
BSZ
on 2024-04-03
15:05:39
| Re: Jiffydos on C16/Plus 4 > black screen flashy
@MMS: Sorry, I have no exact information on this, I don't have/use JiffyDOS (KERNAL).
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
