** New Frontiers in VIC-Hires-Graphics, Part 10

tokra · Post by **tokra** » Sun Oct 24, 2010 1:35 pm

Unseen wrote:
tokra wrote:I suppose it's an incompatibility of the SD2IEC-software that doesn't work correctly with sequential file reading using GET# and such.
Hint: I usually don't fix bugs that I don't know about, so if people just complain about problems on random forums instead of sending me a mail those problems usually won't get fixed. This time tlr was nice enough to point me to this thread.

As said:

I'm not sure how to reach the SD2IEC-firmware coder(s) nor if they have a VIC-20 to test and debug this.

Upon further looking I now have found your contact in the README-file of the SD2IEC-firmware. However I was still gonna try this with a true Commodore IEC drive before contacting you directly to make sure it's really a bug in SD2IEC and not to waste your time otherwise

I appreciate all the hard work in SD2IEC and also the new GEOS driver for it!

Unseen · Post by **Unseen** » Sun Oct 24, 2010 3:01 pm

tokra wrote:Upon further looking I now have found your contact in the README-file of the SD2IEC-firmware.

I know, nobody reads the README...

I appreciate all the hard work in SD2IEC and also the new GEOS driver for it!

I'm starting to hate Wheels.

e5frog · Post by **e5frog** » Sun Oct 24, 2010 3:15 pm

It's because there's usually just crap in the readme:s that you don't need to know anyway - in all others that is - I haven't read yours...

Perhaps if you added a file called ErrorReport.txt or Feedback.txt it would help.

Unseen · Post by **Unseen** » Tue Oct 26, 2010 5:49 am

tokra wrote:However I was still gonna try this with a true Commodore IEC drive before contacting you directly to make sure it's really a bug in SD2IEC and not to waste your time otherwise ;-)

I just tried it both on a real machine with a OC118 (small, quiet, convenient ;) ) and in xvic with TDE enabled - fails on both.

With sd2iec I can see on the debug output that the drive saw an EOI when it expected a command byte, so your ISR is taking much too long - EOI detection works by waiting until either a 256 microsecond timer expires or the computer sends the signal to proceed.

BTW: I noticed in the debug output that the drive receives a steady stream of TALK/UNTALK requests for three different open files. Displaying the bitmap as it is loaded looks nice, but switching between the files all the time slows everything down a lot - even more so with JiffyDos.

nbla000 · Post by **nbla000** » Tue Oct 26, 2010 5:52 am

Unseen wrote:I know, nobody reads the README...

I read README too

tokra · Post by **tokra** » Tue Oct 26, 2010 11:43 am

Unseen wrote:I just tried it both on a real machine with a OC118 (small, quiet, convenient ) and in xvic with TDE enabled - fails on both.

[...]

Displaying the bitmap as it is loaded looks nice, but switching between the files all the time slows everything down a lot - even more so with JiffyDos.

Thanks for checking this, however it even failed to load correctly when I used the version that does *NOT* display the picture while being loaded (see 'bootfast.prg' and 'mainfast.prg'). This would be the standard VIC-20 routines with no further interrupt happening...

Mike · Post by **Mike** » Tue Oct 26, 2010 1:48 pm

Unseen wrote:I just tried it both on a real machine with a OC118 (small, quiet, convenient ) and in xvic with TDE enabled - fails on both.

With "it" I presume you just tested the original version of the display program which loads the picture as it displays it. The "fast" version which doesn't show the picture before all data has been loaded is run with the display ISR not activated:

With sd2iec I can see on the debug output that the drive saw an EOI when it expected a command byte, so your ISR is taking much too long -

... indeed, just a minuscule 256 x 64 µs, i.e. ~16 ms.

There's nothing one can do about the execution time of the interrupt service routine. It copies the colour RAM data in place on the fly, as the raster beam scans the screen. I.e. it will hog the CPU for that time, completely.

EOI detection works by waiting until either a 256 microsecond timer expires or the computer sends the signal to proceed.

Wouldn't that pose problems even as the standard interrupt routine performs a full keyboard scan? That one needs at least 10 raster lines, and thus more than 256 µs.

BTW: I noticed in the debug output that the drive receives a steady stream of TALK/UNTALK requests for three different open files. Displaying the bitmap as it is loaded looks nice, but switching between the files all the time slows everything down a lot - even more so with JiffyDos.

I quickly hacked the viewer program together to read the colour data from the 3 involved files simultaneously. Too bad the use of GET# ends up in a CHKIN/CHRIN/CLRCHN-fest for single bytes. Still, it is a perfectly legit method - CBM DOS allows either 5 SEQ files or 1 REL and 1 SEQ file on one drive be open at any time (for a 1541 ... with a 1581 or others those figures may be higher).

A production version surely will read the whole picture as single file, and copy all the data in place as the file has been completely loaded. And use bus routines, which can cope with being interrupted for a prolonged time.

tlr · Post by **tlr** » Wed Oct 27, 2010 12:29 am

Mike wrote:
Unseen wrote:EOI detection works by waiting until either a 256 microsecond timer expires or the computer sends the signal to proceed.
Wouldn't that pose problems even as the standard interrupt routine performs a full keyboard scan? That one needs at least 10 raster lines, and thus more than 256 µs.

Interrupts are disabled by the kernal during critical parts. Some interrupts will thus be missed during I/O.

You need a special loader protocol if you want to have interrupts during loading. I have written a loader supporting interrupts but it is not supported by sd2iec.

The GI-joe protocol is supported by sd2iec IIRC.

Mike · Post by **Mike** » Wed Oct 27, 2010 3:01 pm

tlr wrote:Interrupts are disabled by the kernal during critical parts. Some interrupts will thus be missed during I/O.

Of course, I'd like the display to have priority over drive access, so ...

You need a special loader protocol if you want to have interrupts during loading. I have written a loader supporting interrupts but it is not supported by sd2iec.

... something like a IRQ loader definitely is needed. But it should also support everything else in the same way as SJLOAD does - but it need not be a fast loader per se.

Does the standard IEC protocol guarantee maximum times for sending a byte, and reading a byte from a drive? In that case one could "just" instrument the standard routines, so they check for a certain range of rasterline values first, and if the transfer might get interrupted by the display code they enter a busy loop (with interrupts enabled, of course) until the "dangerous" range of rasterlines has passed.

tlr · Post by **tlr** » Thu Oct 28, 2010 10:50 am

Mike wrote:
tlr wrote:You need a special loader protocol if you want to have interrupts during loading. I have written a loader supporting interrupts but it is not supported by sd2iec.
... something like a IRQ loader definitely is needed. But it should also support everything else in the same way as SJLOAD does - but it need not be a fast loader per se.

The IEC protocol is so slow that it is pretty hard to avoid making a fastloader when doing a different protocol.

Mike wrote:Does the standard IEC protocol guarantee maximum times for sending a byte, and reading a byte from a drive? In that case one could "just" instrument the standard routines, so they check for a certain range of rasterline values first, and if the transfer might get interrupted by the display code they enter a busy loop (with interrupts enabled, of course) until the "dangerous" range of rasterlines has passed.

Hard to see the max time. Maybe it could be measured?

My guess is that you'll need to handle I/O bits during the raster code to make it work.

Mike · Post by **Mike** » Thu Oct 28, 2010 11:55 am

tlr wrote:The IEC protocol is so slow that it is pretty hard to avoid making a fastloader when doing a different protocol.

The only storage device available to me at the moment is the SD2IEC built into my FE3.

Unless I implement a fast loader that is recognized by the firmware, I'd lock out myself. One of my ideas rather was to retain the IEC protocol - as slow as it is - and avoid EOI's, etc. by using the raster time guaranteed available to the CPU in the remaining top and bottom border. That would work with all drives on the serial bus.

Furthermore, I'm not content with solely a loader compatible to the display routine - saving a file, and access via OPEN, ..., CLOSE should also work.

My guess is that you'll need to handle I/O bits during the raster code to make it work.

With the current FLI display routine - no way. It uses all available cycles in the 256 lines that are displayed. Tokra did the calculation in the OP of this thread.

Oh well, seems I'll have to put out a demonstrator for the 208x256 FLI mode first anyway. As I wrote above, it'll read the whole image as single file, and then switch on the graphics mode.

Unseen · Post by **Unseen** » Sat Oct 30, 2010 4:59 pm

Ok, found the problem in sd2iec:

The A marker in that picture is the point where the VIC20 sets the ATN line to low. Usually the CLOCK line is also set low at this point or slightly before, but for some reason (I'm currently too lazy to read the rom listing of the computer) this is sometimes delayed, in this case about 214 microseconds (B marker). I've seen this problem before, so there is a workaround in sd2iec that previously waited up to 100us (that plus some more processing -> the 124us low time on DATA) - increasing it to 250us seems to fix the VIC20FLI problems on my machine.

I'm not sure what the maximum value for this delay can be before a standard 1541 fails to read the command, but if someone loves counting cycles I can provide some hints where to start. ;)

The fixed release is 0.10.0pre5 which will be released later today (October 31st for me)

tokra · Post by **tokra** » Mon Nov 01, 2010 4:25 pm

Thanks a lot! This fixes the problem for me as well on my live-machine

Mike · Post by **Mike** » Thu Nov 18, 2010 4:03 pm

Mike wrote:I *do* have ideas for extending the horizontal width and still keeping 8x1 attributes, but they will work in other ways ...

... and which now have been implemented as shown in the thread 'Introducing VFLI for VIC-20: 208x256 pixels in 16 colours!'

As some of you already knew or might have guessed, this feat requires a hardware modification. The mod will be described in all details in said thread.

Greetings,

Michael

Mike · Post by **Mike** » Mon Jun 20, 2011 2:48 pm

Here's the updated version of fli_quant.exe in a *.zip archive (download), bundled with the displayer routine of the 72x256 FLI mode. The handling is the same: provide a 72x256 image as file named 'input.ppm' (resized to without keeping the aspect ratio from a picture with aspect ratio ~1:2 in PAL). Then the file 'result.ppm' gives a preview, and 'bitmap.prg', 'colour.bin', '900e.bin', and '900f.bin' are loaded by the displayer. Here's an example:

In VICE you should use 'mike.vpl' for correct display of the colours being dithered to.

Cheers,

Michael