|
Post by hydrophilic on Feb 11, 2016 9:02:12 GMT
Thanks for your post, hydrophilic. However text mode already fails at 83 chars width for me, which would be 664 pixels. Even changes to register 0 or turning off color do not help this. Please try yourself with the program in the screenshots above (it can be quickly typed in). For some reason the VDC screws up color/text RAM above 83 chars width. Even "Graphic Bosster" did not have color-resolutions wider than 640 pixels, only monochrome, so I think this is a general VDC-problem. However for 8x1-mode your calculation seems fine. The mode I use in VDC Mode Mania has a width of 480 pixels. Maybe 488 or 496 still work but I remember testing the limits back then and it was at about 480. Edit: I think hydrophilic's calculation is reversed. Shouldn't it be 80 fetches per char-row for screen-RAM and attribute-RAM each and then 80 bytes per raster-line for font data? And 6 bytes refersh per raster-line for DRAM-update as well? My theory posted above is based mainly of the limits I found while using 8x1 bitmap mode... then I extrapolated (err, applied) the theory to text mode. I'm glad we agree about the limits of 8x1 mode... also note my maximum (496) theory for 8x1 bitmap mode assumes you reduce both the DRAM refresh (register 36 [$24]) and H-Sync (register 3 low nibble) to minimum values. If you do not, a slightly lower limit (like 480) would result. I guess I didn't explain it well.... in bitmap mode (assuming 80 columns / 640 pixles) there is 80 fetches of attributes per row, plus 80*V bitmap fetches per row (where V = 8 rasters in 'standard' bitmap mode). And also 6*V DRAM refresh per row. Or to simplify, 80+V*(80+6)... where V=8 in 8x8 bitmap mode. In character mode, the equation is only slightly different. Memory fetches (cycles) = 80+80+V*(80+6)... I believe this is what you meant in the quoted text, Tokra. It is also what I meant in my previous, long-winded post. Sorry if my prior post was misleading... I only wish I had the talents of Jim Butterfield. Thanks tokra for shooting down my theory in text mode! There are two issues here, which I must now investigate on real hardware (instead of just tossing out theories based on past experience). I will list them for sake of transparency / exposition: - 82 characters is max (83 fails) -- according to my (broken) theory, 96 characters should be possible... grrr
- Disabling color (attributes) does not increase max characters -- my (broken) theory says it should... perhaps the VDC is stupid, and wastes time reading RAM it never uses?
Hopefully if we work together, we can find out the truth! So far, it seems my simple theory works in bitmap mode, but has MAJOR issues in character mode. I can only guess now (before I start real HW hacking), but it might be that character mode imposes some sort of limit / cut-off... such that you can never realize the full potential available in bitmap mode?
|
|
|
Post by mirkosoft on Mar 1, 2016 21:58:04 GMT
Hi boys!
I'm sad, this topic returned never for me notifications. I had lot of work and no time for hobby, now when it's near finish I'm here and see what you found. In all - since I posted Q, I found only this:
full usable PAL resolution of the VIC-II is 403x288 (with borders) ... and can it mean for VIC-IIe 403×576 real interlace? Really TED uses resolution from 320×248 up to 320×496 - but it's notrmal programmable area like VIC-II 320×200...
Thank you for replies.
Miro
|
|
|
Post by hydrophilic on Mar 2, 2016 11:28:21 GMT
Sorry I went off-topic about VDC in my last post... (I really want to investigate limits of VDC). Anyway, I have not played with "max resolution" of VIC-II(E), so I can not answer your question. Mirkosoft, you said "full usable PAL resolution of VIC-II is 403x288 (with borders)". Is that a typo? Did you mean *without* borders? I've played a bit with killing vertical borders (top and bottom), but never tried to kill the side borders... side-border kill requires precise timing for every visible raster!! Way too constrictive for general programming... (but cool effect in a demo). All I know for sure is that real-interlace will steal 2 or 3 rasters each field... so total rasters per frame (2 fields) will be - NTSC: 2*(262-2|3) = 524-[4~6] = 518~520
- PAL: 2*(312-2|3) = 624-[4~6] = 618~620
However, I do not know if the "cut" rasters are in the visible range. If they are/were visible (with no borders), then max resolution would be a little less... Of course if they are not visible, then there would be no change to maximum (visible/usable) screen area.
Ummm... I guess that doesn't really answer your question, and is probably a bit confusing! But I believe it is accurate and is something to think about for anyone interested in "Full-Size" VIC-IIE.
Anyway, thanks for interesting discussion, and let us know if you find something new/different!
|
|
|
Post by mirkosoft on Mar 31, 2016 21:11:40 GMT
I got new info about Commodore 900 also known as Z-Machine (CeBIT 1985), unreleased UNIX computer running Coherent OS which was in two models: Server and Workstation. Its CPU was Zilog Z8001 16-bit with 23-bit addressing RISC type at 10MHz with 512K RAM up to 2MB, 20MB HDD and 5,25" 1,2MB disk drive similar to SFD-1000/1001 using MFM disks. Only 2 models known working - one was sold at Ebay for $2800. Its graphic chip was MOS 8563!!!! MOS 8563 had 128K RAM, server variant had text mode only (80x25) but workstation Hires display resolution was 1024x800 monochrome (72Hz refresh monitor req'd). So, means it that VDC rev0/rev1 can display this resolution where is C128 limited by VDC-RAM and 2MHz clocking?
Miro
|
|
|
Post by hydrophilic on Apr 1, 2016 6:07:55 GMT
Wow, this C900 / Z-Machine is total news for me! And it has 8563 giving 1024 resolution?? Seems very unlikely... even if it were true, there is no way that the "world" could verify this, since there are only 2 known working units! Assuming it were true, then I think you have the right idea, mirkosoft... the VDC may be clocked faster than 16MHz (C128 standard)... (Also, thanks for reminding me to test real hardware... I *really* need to figure out the color/cell limits of C128!)
|
|
|
Post by mirkosoft on Apr 1, 2016 6:40:41 GMT
Later I'll post C900 advert scan, now I'm going away this weekend. Miro
|
|
|
Post by mirkosoft on Apr 1, 2016 11:23:51 GMT
Robert, if I remember correctly your C128 has 16K VDC-RAM, if you didn't upgrade.
I can provide you 2 color modes for 16K: 640x136 in 8x2 color cells 640x176 in 8x8 color cells Very nice can be if you implement colors into Basic 7.80... Miro
|
|
|
Post by mirkosoft on Apr 3, 2016 18:31:35 GMT
|
|
|
Post by hydrophilic on Apr 4, 2016 9:16:11 GMT
Hi, Miro... (thanks for info about C900) You said, "Very nice can be if you implement colors in Baisc 7.80..." My BASIC 7.80 already includes color (if you have 64K V-RAM). Do you mean color for 16K V-RAM? Or maybe you mean custom cells (8x2 for example) for 64K users? You also said, "I can provide... 16K... 640x136 [8x2]... (and) 640x176 [8x8]" So now it seems you really mean 16K color... I think I understand! Yes, I have played with color graphics on my low 16K machine... I remember testing 8x1 bitmap mode with tokra a few years ago... (8x1 is a pain!) ANYWAY... I think color with 16K V-RAM is a nice idea (assuming that is what you mean). The main reason there is no color for 16K users in BASIC 7.80 is there is no "standard" way to defined a reduced screen size... you *MUST* reduce screen size (for example, 640x176, like you say) to get color on 80-column bitmap if you only have 16K V-RAM... So the real questions is: how can BASIC language define custom bitmap? Here is crazy idea... everyone flame me, and tell me why it is wrong/bad! DEF GRAPHIC hp, vp [, hc, vc [, h1, v1] ] where: hp = horizontal pixels per cell (1~8... default 8) vp = vertical pixels per cell (1~8... default 8... minimum 2 because BASIC too slow for 8x1 cells) hc = horizontal cells per screen (1~80... default 80) vc = vertical cells per screen (1~??... default 25) h1 = delay for H-Sync (controls horizontal center) v1 = delay for V-Sync (controls vertical center) The last option, vertical cells, is very tricky. With standard (non-interlace) mode, you can only get about 28 rows with NTSC (most montiors), or possibly rows with PAL (I don't know).... Obviously the value would be x2 with interlace (assuming enough V-RAM). So umm... yeah, I have *thought* about color in BASIC 7.80 for people with only 16K V-RAM... but there is no standard way to do this. Is my example above good enough?? Please give me ideas... thanks everybody!
|
|
|
Post by gsteemso on Apr 4, 2016 14:00:24 GMT
Interesting syntax suggestion, though I am not totally sure I would choose that particular keyword pair (admittedly, nothing better immediately suggests itself). The only improvement I can suggest off the top of my head is that vertical pixels per cell can be pretty much any value between 2 and 32 as far as the VDC cares, without the user even needing to fiddle with exact register values to keep their monitor happy.
|
|