Yes, remember the C64 (just like the VIC20) was designed to be used with a TV via RF connection. The C64 uses twice the video bandwidth, and that made single pixel vertical lines look bad under those conditions.
Posts by Tobias
Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.
Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.
Don't Panic. Please wash hands.
-
-
That has nothing to do with Chameleon Commodore "fixed" the charset for the 40 columns by making all vertical lines 2 pixel wide, and indeed the result is that a few of the PETSCII symbols are now the same. You could load the vic20 chargen ROM (find it on Zimmers.net or in the VICE data directory), then you get the original Symbols (and the mentioned ones will be different).
-
modify back porch and/or sync in the vertical timing, each step there is one line
-
now you gotta try what happens if you remove or add another line
-
It can be a little more or less, but not much. slightly less is probably better than slightly more
-
This kind of testing does not really help though. As said before, there is no right or wrong way to do a 720x576 mode, as there is no standard for it. What would help is when you use the timing from the mentioned modeline(s) and tweak it until you get a stable picture in a 720x576 mode at 50.2Hz
-
Quote
The need for a higher framerate is why you reduced vtotal from 625, yes?
no, i dont hand tune (i really prefer not to) - i just calculated a mode with UMC
-
The scandoubled signal _IS_ the 720x576 mode. Its not magically twice the amount of horizontal Pixels. The number of lines is doubled, no more no less.
QuoteIn last month's update thread I did post what I believe is a modeline matching the C16 core -
Modeline "720x576x50" 28.38 720 732 798 912 576 580 586 624 -HSync -VSync
You gotta translate this into the settings for the Indivision
this is how it works:
and then, since this mode is 49,something Hz and not 50,2Hz as we need, you gotta tweak the settings accordingly, perhaps remove some lines until the vertical frequency is 50.2Hz
-
You need to create a 720x576 mode *for the monitor*. all the messing around with the scaler is pointless for what we are trying to find out here.
-
Quote
The talk about 720x576@50Hz is about the resolution the monitor runs at.
In the first place it matters what the video producing device puts out - what your monitor detects and how it displays something comes second (and might be just wrong, or just match by chance). Hence the question what these 1472 pixels are about. To me it looks like you have basically created a 1440x576 mode, which for some reason your monitor detects at 720x576.
QuoteIn last month's update thread I did post what I believe is a modeline matching the C16 core -
Modeline "720x576x50" 28.38 720 732 798 912 576 580 586 624 -HSync -VSync
Ah yes, i remember this. And i remember i tried this and it did NOT work with my monitor - showing pretty much the symptoms turrican9 is describing with his now It doesnt seem to be 100% right though - because the C16 core works fine here. Also, we have another "problem" with Chameleon - the 50Hz modes have to be slightly faster than 50Hz (actually faster than 50.125Hz), else the "VIC-Sync" will not work (Thats why all the other 50Hz modes are actually 50.2Hz)
-
If those use a true 720x576 mode and that works for you, you should absolutely be able to reproduce it with the indivision
i wonder what the exact setup for those cores is (didnt i ask it before, i cant find it now...) robinsonb5 do you know? couldnt find it with a quick look at the sources (and i cant read verilog at all...)
-
Quote
Likewise, if you halve all the horizontal values as well as the pixel clock you should, in theory, end up with a true 720x576 mode that has exactly the same timings. If you can get that working stably, then you'll have useful settings for other people to refer to.
Indeed!
-
As said, its still not a standard mode (not VGA, nor VESA) so there is no "right" way to do this mode - which is one of the reasons for why i didnt add it before. That said, i am using "umc" to calculate the timings according to the official VESA specs (http://umc.sourceforge.net) - a monitor that conforms to those standards should be able to display it if the timings are in its supported range
Your screenshot irritates me for that matter, why does it say 1472 horizontal pixels?
-
Also note 720x576 is not a standard Mode, even less so at 50Hz or even with VIC sync enabled. This *will* not work on some (or even most) Monitors.
-
As you probably noticed more than one month passed since the last update - the last few months showed that switching between projects every few weeks is very inefficient, so we decided to switch our development strategy once again.
This update contains a lot of internal changes, i have been reworking the banking and shuffled code around to make room for more improvements. Some customers came up with good ideas on how to improve the menu system, which have been added to our "to do" list and which made this rework necessary. Some of these ideas have already been implemented for this update, most notable the 720x576 resolution and autostarting of G64 images.
The changes in detail:
Code- FPGA Core:
- - Added 720x576 resolutions
- Filebrowser:
- - G64 files can be autostarted by pressing RETURN on them in the file browser
- - D64 and G64 files can be autostarted by using CBM+E (execute) action, which
- is also available in the file-action menu (space)
- - enabled copying files into D64 images
- - (re)enabled "rename" in the file-action (space) menu in CDTV mode
- - BUGFIX: disabled "rename" and "delete" for the ".." entry in the file-action
- menu (space)
- - BUGFIX: "Browser starts with 2 Panels" settings did not work when a Panel
- was switched to full size when leaving the Browser
- - BUGFIX: Files with unknown extension were always recognized as .bin files,
- which made the common fallback action pointless. Now files without
- any extension are assumed to be binaries, all other files use the
- default fallback action.
- Monitor:
- - BUGFIX: fixed output of the "mc" command so it always shows character blocks
- aligned to 8 bytes. this also fixes the broken forward scrolling.
- Header:
- - Renamed VGAMODE and VGACTRL to VGAMOD and VGACFG to match the progmanual
- - Removed obsolete VGA related defines
As always get the update on the Chameleon wiki page.
-
I'm putting it into my notes... will have to check if it can be mangled into the input system without using too much logic
-
Just select the clear one in the shop and order it. Whatever is available in the shop will be shipped within a few days unless the description explicitly says something different.
-
Quote
I find that G64 files are a bit cumbersome to launch. I assume that the TC64 doesn't show the G64 directory because it is too complicated to read. But I wish that pressing the joystick button or 'Return' on a G64 file would launch the disk image: mount it, reset the C64, and do the equivalent of 'LOAD"*",8,1'.
I have that implemented now And it also works for D64s (that was a no brainer)
QuoteI wish the menu settings values wrapped around when you reach the end. Because they don't, you have to remember whether two-option settings like "PAL" and "NTSC" are the left or right key, which I always forget. It would be a bit more convenient if I could always hit the 'right' button to cycle/toggle through all the settings.
I looked at this and wondered how neither me nor you apparently noticed that it already does this Simply dont use left or right, but "return" or "fire", which will cycle through the options
-
have a look at this list in the wiki: http://wiki.icomp.de/wiki/DE-9_Mouse#C-64_2
for operation wolf, it looks like you need the right version of the game - the one made for the "NEOS" mouse will not work
-