|  Post Your Message | |
| |
| | Previous Messages | |
|
Posted By
Gaia
on 2008-02-23
19:05:19
|  Re: plus4emu 1.2.5.1
Maybe making it a set of user definable parameters is a viable option? The problem with the Pepto palette is that it is partly a product of a guesswork and I also have the feeling that they were based on a composite picture and a bit too low on saturation. Well, the C64 guys never had a point of reference like our TED doc. Anyway, good news on the conversion code nevertheless.
|
|
Posted By
IstvanV
on 2008-02-23
17:40:44
| Re: plus4emu 1.2.5.1
I do not have a C64, so I used the tables from http://www.pepto.de/projects/colorvic/. The C64 screenshot was created with VICE 1.22. When mapping the hue values, I simply rounded to the nearest available Plus/4 color. On the other hand, I tried to make sure that colors that have a different luma on the C64 will also have different luma after the conversion (with the exception of 119,53125 and 127,5, I assumed these are close enough to be represented as the same level), even at the expense of not always using the nearest possible value.
I am not sure if the tables at pepto.de are correct, though, and the color mapping may change, but I do have working code for loading Koala Painter and Advanced Art Studio images now.
|
|
Posted By
Gaia
on 2008-02-23
15:55:33
| Re: plus4emu 1.2.5.1
It looks good on screenshot, though if you do not have a real C64 you may had to rely on an emulator. I assume you have done some analysis based on the luma and the hue, not just judging by eye, right? Anyway, "we" used to have a table where we approximated with our eyes and it can be found in the DATA lines of the following program:
http://plus4world.com/software/Kep-konvertalo
It's funny that most hues that are matched with yours are brighter in this table, and also that there are hues that are quite different.
I know Harry used a different table (at least 2 colours were different) and we compared them on some forum but I can not find it right now.
|
|
|
|
Posted By
IstvanV
on 2008-02-21
10:06:37
| Re: plus4emu 1.2.5.1
As requested by Litwr, the TED registers changed since the debugger window has been previously shown are now marked with asterisks.
|
|
Posted By
Bacon
on 2008-02-20
07:51:13
| Re: plus4emu 1.2.5.1
Been away from this board for some time, only to come back and discover there's a GPL:ed, Linux compatible Plus/4 emulator. Yay! Downloaded it yesterday and played around a little. First impression is very good.
The Plus/4 emulation in VICE sucks and while YAPE kinda works using WINE, a native app is always better, especially when it's as good as this one seems to be. Keep up the good work!
|
|
Posted By
Chronos
on 2008-02-18
02:20:34
 | Re: plus4emu 1.2.5.1
oh holy crap! its very informative.. something that dcd likes.. he crying all the time to get breakpoints, register states etc etc..
|
|
Posted By
Litwr
on 2008-02-18
00:43:45
| Re: plus4emu 1.2.5.1
The screenshot looks close to ideal for me.  I can only add that you may mark (by astersk?) changed TED registers since the last output. IMHO the mentioned problems are consequences of situation --- they are not artificial so the may be ignored.
|
|
Posted By
IstvanV
on 2008-02-17
06:35:27
| Re: plus4emu 1.2.5.1
Gaia: thanks for posting the link.
Litwr: is this changed debugger window OK ? http://www.sharemation.com/IstvanV/p4debug3.png
Note that the horizontal position is displayed in pixels, and both values are hexadecimal. Also, the vertical position is the internal latched value used by the TED, and the FF1C-FF1E registers are delayed by one cycle when read by the CPU. On a related note, the formats used for video position could be made more consistent in the debugger, since it is now different for each of the following cases:
- video breakpoints use a format similar to the one described above, but the horizontal position is in double clock cycles (4 pixels), and it is adjusted to be more consistent with the FF1E reads
- in trace files, the video position is simply what would be read from FF1C-FF1E in the first cycle of each opcode
Should these be changed to avoid confusion, and if so, how ?
|
|
Posted By
Litwr
on 2008-02-15
00:52:43
| Re: plus4emu 1.2.5.1
I didn't mention ALL TED registers. The horpos and verpos are only important. Some value may have timers information but it is much less important. IMHO The best way will be to show ver & hor positions + all changed during last step(s) TED registers.
|
|
|
|
Posted By
IstvanV
on 2008-02-14
15:25:34
| Re: plus4emu 1.2.5.1
Well, supporting both is probably not much more difficult than only one, since the formats seem to be very similar.
|
|
Posted By
Gaia
on 2008-02-14
12:55:43
| Re: plus4emu 1.2.5.1
Oops, I was again mixing up things a bit, it is actually Advanced Art Studio that I was referring to (I had to start it up to check for sure, last time I checked this was around 2003). Koala is also rather popular though, so if both could be supported that'd be terrific.
|
|
Posted By
IstvanV
on 2008-02-14
12:13:02
| Re: plus4emu 1.2.5.1
I have a preliminary (there may be bugs and the code is not very clean), but generally working FLI display routine for the next version of the converter. This has the following improvements:
- in multicolor mode, the background colors can be changed with higher resolution, particularly when not writing to the border (number of lines <= 200)
- allows any vertical size from 16 to 31 characters in half character steps
- the attribute and bitmap data can be independently interlaced or not interlaced
- lines can be made border colored for simple effects
- the true interlace effect uses less CPU time
The memory usage is somewhat higher, though. Here is the current display code and an example (it is converted from an image in the old format, so it does not actually take advantage of the possible better quality):
http://www.sharemation.com/IstvanV/flitest/new_fli_disp.s
http://www.sharemation.com/IstvanV/flitest/new_fli_test.prg
Now I only need to update the converter to support all these improvements and new features
|
|
Posted By
IstvanV
on 2008-02-14
11:53:55
| Re: plus4emu 1.2.5.1
Gaia: I will try adding support for the Koala painter format (is it the one described here ? http://en.wikipedia.org/wiki/KoalaPad#File_Format). I assume it should also be handled in a special way with regards to the scaling etc. so that the converted image is as close to being pixel exact as possible.
|
|
Posted By
IstvanV
on 2008-02-14
11:49:16
| Re: plus4emu 1.2.5.1
OK, I will add the TED register display to the debugger; can the - basically redundant - code hex dump display above the disassembler be removed to make space for the TED register info ?
By the way, I usually just scroll back the memory dump with the mouse wheel to see the TED registers, but having them displayed separately will be useful nevertheless.
|
|
Posted By
Litwr
on 2008-02-14
03:33:35
| Re: plus4emu 1.2.5.1
The debugger has become much better now. However it is very important to see values of TED registers $1c-1e (horizontal & vertical positions) after every step so it would be great improvement to add feature to see them. It would be also better to see these positions instead exact registers contents. IMHO It may be implemented by watches or at permanent basis.
|
|
Posted By
Gaia
on 2008-02-11
17:13:16
| Re: plus4emu 1.2.5.1
Yeah, this is good enough I guess. Anyway, a lossless conversion is of course theoretically impossible even with FLI, but here and there some cheating can be done and the result can be quite good. Again I was just wondering that the similarities between the two platforms need special treatment or not... Also, if your converter could import directly from Koala Painter format that'd be great. I know a plus/4 graphician (though not very prolific Coyote ) who actually prefers using that even for plus/4 graphics. Also, there's less chance for errors because an unnecessary step, namely "palettizing" those C64 images to PC format, does not take place.
|
|
Posted By
IstvanV
on 2008-02-11
14:22:52
| Re: plus4emu 1.2.5.1
Gaia: it is of course impossible to guarantee a lossless conversion of C64 multicolor graphics with any (even FLI) video mode on the Plus/4, but if the image is not too complex, it is possible to get acceptable results even with the current version of the converter. One major limitation is that there are not too many video modes that are currently supported, basically the choices are either 304x200 interlaced multicolor FLI (this can also be increased to up to 248 lines), or simple 160x200 multicolor graphics without FLI. The high resolution interlaced FLI converter, while great for many photo-realistic images, probably does not work very well for this purpose.
For good results, the input image should be resized to 608x400 when using the multicolor FLI mode, or 640x400 for the simple non-FLI mode, with no interpolation. This is because the converter first resizes the image to the above mentioned resolutions with sinc interpolation, and then to the actual output resolution with simple pixel averaging. Also, in the conversion parameters dialog, all scaling, color correction, dithering, etc. should be disabled, as shown on this screenshot: http://www.sharemation.com/IstvanV/flitest/fliconfig1.png
To see how well this works in practice, I have converted this random screenshot from a C64 multicolor image:
http://www.gfxzone.org/personal/mermaid/02/mermaid-jungle.html
The resulting PRG files are:
http://www.sharemation.com/IstvanV/flitest/mermaid-jungle.prg
http://www.sharemation.com/IstvanV/flitest/mermaid-jungle_fli.prg
Of course, the palette is different, so that is probably the difference that is easiest to notice.
Note that I manually modified the X shift table in the second program (using the 'sr' command of the plus4emu debugger) to remove the horizontal interlace effect, and it does still store the whole image twice. Obviously, a non-interlaced multicolor mode would be useful here. It also does not use the improved FLI code discusses with Dr. Death that is still to be implemented, so it would be possible to get better quality.
|
|
Posted By
Gaia
on 2008-02-11
13:54:40
| Re: plus4emu 1.2.5.1
Yeah it is. I was just wondering if special care should/could be taken for C64 bitmaps.
|
|
Posted By
Luca
on 2008-02-11
09:53:01
 | Re: plus4emu 1.2.5.1
Reading Gaia's answer, I find the case he pointed out is a subcase of a general colour clash reduction's stuff.
|
|
Posted By
Luca
on 2008-02-11
09:39:47
| Re: plus4emu 1.2.5.1
Just gave it a little attempt: though all the limitations you anticipated (FLI derivation is quite clear, looking at the weird first pixels'column  ), it's quite cool! dunno how to do for a colour clashes reduction yet...
|
|
Posted By
Gaia
on 2008-02-11
09:36:06
| Re: plus4emu 1.2.5.1
Istvan, I haven't had time to test the converter too much, but can it cope well with images that are similar in size to the plus/4 screen (say 320x200)? What I have in mind, is what was done in the early years, converting C64 graphics to the plus/4. The challenge here is that the C64 can have 3 independent colours per 8x8 character block in MCM graphics mode. If, say, the converter is not able to fit that into the plus/4's regular graphic mode, it could either degrade the quality somewhat or offer the aforementioned FLI one as an option... or something like that.
|
|
Posted By
IstvanV
on 2008-02-11
05:52:23
| Re: plus4emu 1.2.5.1
Luca: there is a new 1.2.5.2 update available now, which includes a preliminary implementation of conversion to the Multi Botticelli format. Currently, it has two main disadvantages: it is based on the multicolor FLI code, so it pre-dithers the image to 160x200/121 colors first, and then converts it to the Plus/4 format; this method works well for FLI because the error can be sufficiently low, but with this very limited format, finding an optimal palette first (with the subsequent dithering taken into account - that would be the difficult part), and then doing the conversion with dithering would be better. Another disadvantage is that since the search for optimal attributes is almost brute force, it can be very slow with some more complex images. However, both the speed and the quality are reasonably good when converting a greyscale image (by setting the color saturation to zero); this speedup can also be useful when finding the best image scale, offset, contrast, etc., before doing the final conversion with colors enabled.
To save a Botticelli compatible PRG file, enable the 'Write the raw FLI data only' option, and also make sure that compression is disabled.
|
|
|
|
Posted By
IstvanV
on 2008-02-08
11:33:52
| Re: plus4emu 1.2.5.1
It is because the CPU has three cycles before the DMA when it is allowed to write, but not to read (or, more precisely, the read does take place, but the result is discarded and the read cycle is repeated). The count of three cycles is because the largest number of write cycles in a row is three, and it happens when the PC and the status register are saved on the stack on an interrupt. Read-modify-write instructions like INC, DEC, etc. have two write cycles at the end, the first one just writes back the original value, and the second writes the correct result. Simple write instructions like STA have one write cycle at the end. So, with the proper timing, it is possible to get one or two write cycles to occur in the three special pre-DMA cycles, thus getting more than 22 cycles in a single line. Normally, these cycles are the ones when reading from FF1E would return CE, D2, or D6. In the following example, if the 'sty $FF16's were replaced with 'ldy $FF1E', they should return C2:
ldy #$??
sty $FF16
sta $FF14
ldy #$??
sty $FF07
ldy #$??
sty $FF15
ldy #$??
sty $FF16
stx $FF1D
ldy #$??
sty $FF07
ldy #$??
sty $FF15
ldy #$??
sty $FF16
inc $FF14
...
A useful reference on 6502 timing and other details is this document: http://www.viceteam.org/plain/64doc.txt
|
|
Posted By
Degauss
on 2008-02-08
10:56:12
| Re: plus4emu 1.2.5.1
ehm, wait a second: you said the last two cycles from that INC are for free. i never saw anything like that happen. did i get this right: with proper timing and the correct opcode theres more cycles than you would normally have on a badline? how come?
|
|
Posted By
Degauss
on 2008-02-08
09:27:03
| Re: plus4emu 1.2.5.1
argh! INC works... never would have expected that. neat trick!
|
|
Posted By
IstvanV
on 2008-02-08
08:12:40
| Re: plus4emu 1.2.5.1
Hi, sorry for the lack of any greetings, I did not intend to offend anyone, I am just not used to including them As far as the improved FLI routines are concerned, I will show my planned next version first (which has the same color resolution as your one), and then the theoretical full resolution non-overscan version. I did not test these yet, so there may be errors in the idea, but I think it should work. The following are just timing diagrams, and not actual assembler code, but the implementation should be obvious:
FF14 FF07 FF15
| | |
*****---************XXXXX
FF07/FF15
|
FF16 | FF1D FF16
| | | |
*****+--*****************
Each column is a CPU cycle, those marked with '*' are always available, '-' are cycles before DMA (when the BA line is pulled low by the TED) not used by the CPU, and '+' are the same but used by the CPU for writing. 'X' cycles are reserved (normally dummy) for the purpose of JMP instructions (when splitting the unrolled display code) and changing FF12 when needed (with the STA nnnn, X instruction which takes 5 cycles to execute). The FF1D value is a fixed 0A and is preloaded to register X. The FF12 value is also preloaded, to register A, before the beginning of the long unrolled code. The other writes (FF14, FF07, FF15, and FF16) just use LDY #nn, STY nnnn pairs. Before the last FF1D write, CA is loaded to the X register. The FF14 lines are the odd ones (with (FF06) = 3B), and the FF1D lines are even, taking advantage of the fact that most of the effects of FF1D writing only occur in the next line, since the register is internally latched by the TED. Using FF1D for FLI also implies an easier overscan effect.
Now the full resolution routine:
FF14
FF16 | FF07 FF15
| | | |
*****++-*****************
FF1D
|
FF16| FF07 FF15
| | | |
*****---*****************
Here the important change is the way in which FF14 is changed: the use of an INC instruction makes it possible to avoid 2 cycles for register loading, and the two extra cycles of the INC instruction are free, since they take place when BA is low. Incrementing FF14 advances to the next bank of video memory, since the lowest three bits are always forced to 1 by the TED. One of four FF14 writes is a simple 4-cycle STA instruction that writes a preloaded register value (i.e. the first bank of attributes).
There are some obvious problems that interfere with the implementation of overscan: first, the attribute banks must be placed sequentially in memory to make the INC $FF14 trick work. There is also no time left for inserting any JMP or STA $FF12 instructions, and all registers are already used. Additionally, there may be some minor issues with cleanly ending the display area.
I have an updated conversion that tries to fix the clipping/hue distortion problem, but still uses the old video mode: http://www.sharemation.com/IstvanV/tarnsman_m_2.prg. I have just started to implement the new code which uses the first described method, so I obviously do not have any example of that.
|
|
Posted By
Degauss
on 2008-02-08
07:04:05
| Re: plus4emu 1.2.5.1
Boy, many typos:
1. Did you find a way to modify all three registers in -->BOTH<-- lines? (Seems nobody likes it, but the FF07-trick helps a lot with error-reduction)
2. A more -->EXOTIC <-- "feature" is quite common from C64-FLI-Paint-Programs:
Sorry...
|
|
Posted By
Degauss
on 2008-02-08
06:12:11
| Re: plus4emu 1.2.5.1
Hi Istvan!
At the moment, i won't get fed up by your test-images. There's some interesting progress in there
In a post earlier you stated that it might be possible to modify x-scroll and bg/fg-colors for both lines. I didn't look at your code, but my display-kernel didn't allow this because i was running out of cycles. I could only set two registers in the second line where i would have needed three changes. I simply decided what register-change results in less errors.
My display kernel looks like this:
------------------------
LDA ??
STA FF14
LDA ??
STA FF06 ; DFLI-stuff completed
LDA ??
STA FF07 ; first x-scroll
LDA ??
STA FF16 ; fg-color
LDA ??
STA FF15 ; bg-color
NOP ; argh. this could be useful if it was LDX/LDY, but i didn't find a way
; would be HARD to manage anyway
LDA ??
STA FF16/FF07 ; either this...
LDA ??
STA FF15/FF07 ; ... or that STA *can* be rewired to FF07
------------------------
Due to the fact that the overscan-images forced me to scatter the display-code around in memory, i needed special lines that could JMP instead of the last STA (or: modify FF1D). These are situations where i couldn't even have a second register-change in the second line.
Did you find a way to modify all three registers in all three lines? (Seems nobody likes it, but the FF07-trick helps a lot with error-reduction)
Best Regards
Degauss/TEK
p.s.: You asked what features would probably be interesting. I have to second Luca that straight (Multi)-Boticelli and Charset conversions are very very valuable. A more "feature" is quite common from C64-FLI-Paint-Programs: Interlaced Pictures are allowed to use the same Videomatrices for the odd and even planes. Quite obvious: It saves a lot of memory!
p.p.s.: Don't take it personally, but i think you're the first poster in a forum who never uses salutations at the beginning of a post. Try "Hello!"
|
|
Posted By
IstvanV
on 2008-02-07
10:27:22
| Re: plus4emu 1.2.5.1
Increasing the resolution of the background colors could still be useful, although it would also mean slightly increased memory usage. On the other hand, with a rewritten display routine, it would be possible to have any number of lines that is an integer multiple of 4 between 168 and 248.
If you are not entirely fed up with my example images yet (), there is a new comparison of converted images (http://www.sharemation.com/IstvanV/p4imageconv2.zip), in which you can find an older demo by Larry and one of Dr. Death's excellent sample programs, as well as my conversions of the same (or at least very similar) images. This does show one problem to be fixed: the brightness/contrast changes should probably be made in the YUV colorspace, rather than RGB, which is why the background color in one of the images is wrong due to the RGB values being clipped.
If the multicolor mode is good enough, the multi Botticelli compatible non-FLI conversion can probably based on it. I am not so sure about what the best way is to implement the plain non-FLI hires mode: it can either be a stripped down version of the current hires interlace code, or I can use the approach from the multicolor conversion (i.e. converting to a temporary 121 color image first, and then trying to encode that as Plus/4 graphics with the least possible error).
|
|
Posted By
Luca
on 2008-02-04
18:14:46
| Re: plus4emu 1.2.5.1
Not very good? Oh no, I would mean absolutely the countrary instead! Tonight I played a bit with your converter, and I had several good results even with MCFLI 320x200.
|
|
Posted By
IstvanV
on 2008-02-04
16:45:15
| Re: plus4emu 1.2.5.1
Well, I assume that means it is not very good Perhaps I should try to remove the limitation of only changing the background colors for pairs of lines, rather than each line separately. Although with the X scroll optimization it still tends to look slightly better than DFliConv, which does have separate FF15/FF16 colors for every line, but only fixed scroll for the whole screen. It could be possible to have either two scroll values, two FF15, and one FF16 per two lines, or only one scroll but two of both background colors, but it is tricky when also writing to the border. With 200 lines only, it may even be possible to implement 2 scroll values and 2x2 background colors for every pair of lines.
|
|
Posted By
Luca
on 2008-02-04
11:37:47
| Re: plus4emu 1.2.5.1
MCFLI mode: no precise opinion at the moment, apart of "keep up the cool work"
|
|
Posted By
IstvanV
on 2008-02-04
10:09:26
| Re: plus4emu 1.2.5.1
The flickering effect at the bottom of the border is because the vertical blanking starts earlier by a half line in one of the interlaced fields; it is not a bug in the emulation. It usually cannot be seen on a TV, because a few percents of the display area are cut off, mainly for the purpose of hiding effects like this, which could also occur with normal TV broadcast signals. Although it might be possible to remove the effect by changing the timing in the interlace routine of the FLI display program.
I will try to add at least the Botticelli formats in the future versions, although they will of course not look quite as good as the FLI modes (which still need some improvement nevertheless). Is this description of the formats correct ?
Hires Botticelli:
7800-7FFF attributes
8000-9F3F bitmaps
Multi Botticelli:
same as above, but there is the string "MULT" at 7BFA, the FF16 color at 7BFE, and the FF15 color at 7BFF. The background colors are stored with the 4-bit nibbles swapped for some reason.
By the way, what do you think about the multicolor FLI mode (for example, suggested improvements) ?
|
|
Posted By
Luca
on 2008-02-04
09:22:02
| Re: plus4emu 1.2.5.1
About the converter, what would be very kewl to add (in the future, a "near" future will be much appreciated for sure ):
- plain MC with clashes reduction routine, exportable in Multi Botticelli format;
- plain HR with clashes reduction routine, exportable in Botticelli format;
- plain 2 colours only HR exportable in Multi Botticelli format;
- characterbank based 3+screen colours (screen can be changed by char and can beone of the first 8 colours) exportable in Logo Paint (plain, no FLI), Logo Editor V2.0 and Logomaker +40 (2 charsets)
About the emulator: what's that flickering in the border bottom when I run a converted image?
|
|
Posted By
Chronos
on 2008-02-04
06:08:11
| Re: plus4emu 1.2.5.1
thx, i'll test it!
|
|
Posted By
IstvanV
on 2008-02-03
19:23:50
| plus4emu 1.2.5.1
This release is a minor update only, although it does include the new image converter utility, which uses the emulator for displaying previews. Other than that, the Alt+W behavior has been changed as suggested by SVS, and some other small changes have been made. As usual, the source code, and binaries for 32 bit Linux and Windows, and 64 bit Linux can be downloaded from SourceForge:
http://sourceforge.net/project/showfiles.php?group_id=192837&package_id=226942&release_id=573717
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
