|
Post by mrbombermillzy on Feb 9, 2016 19:24:11 GMT
Guys, I havent had a chance to play around with the 128 lately, but from the screenshots and looking at your little program, the dram refresh rate is not your problem here. The program you have shown is doing exatly what it is meant to!If we take the 81 character width example to save me repeating for all the screens, then what your program is doing is essentialy adding 1 character to each character row and you are NOT relocating the characters after you have done so. Hence for every row down you have to subtract 1 character position (meaning the character gets displaced to the left one column) from the display. So for example, row 11 is where you have the word"List" and it is 11 places behind where it is meant to be because the sucessive rows above have robbed one byte of memory from the line below accumulating to 11 by the time we get to the list statement. You will notice also that there are 25 characters at the bottom because your display is 25 characters high so it has pulled back these random trash characters from a part of the vdc ram which wasnt showing anything before your screen manipulations and hasnt been cleared by either you or the kernal, so is displaying random char/colour/attributes.I hope that I explained it well enough :-)
|
|
|
Post by mrbombermillzy on Feb 8, 2016 19:29:00 GMT
Ok, well, assuming that your hardware is not faulty, then perhaps you have not set up the vdc memory map properly?
At 640x200 the vdc is at default setting memory wise: the screen ram, colour ram and character definitions are all separate from eachother. When you start pushing the resolution up, you need more clear ram space for at least the screen if not colour,attribute and char ram. For example, if we were to set the resolution at around 800x300, which is where we are testing lately, the screen ram alone would overwrite the colour and character definition ram and display all sorts of rubbish. Look at my screen photos for an example. If thats whats happening then you want to spread out the screen colour and character base adresses so this wont happen.
Im not sure wether you have the xx63 or xx68 vdc so cant really elaborate on suggesting any memory locations. Also ive just catered for character mode instead of bitmap.
If you already know the above and its some sort of realtime colour swapping operation thats going wrong I will try to help if I can. Let me know
|
|
|
Post by mrbombermillzy on Feb 7, 2016 20:59:44 GMT
What do you mean by colour working sucessfully?
Do you mean running out of vdc ram as the resolution uses most of it up or something else?
|
|
|
Post by mrbombermillzy on Feb 7, 2016 17:16:33 GMT
And here are the results for the lowly bvm monitor which cant really do over 15khz: A reg/value setting at 1/102 2/111 6/37 35/105 This results in the following display: Which is a fairly respectable res of about 768x272 and a fairly safe resolution to use if you want to make a widely used program or game that others will be able to display on old 15khz monitors. Hope this goes some way to answering the original question :-)
|
|
|
Post by mrbombermillzy on Feb 7, 2016 13:23:46 GMT
Register 35 basically extends the right hand border so what we are looking at is a very bad fault on that particular monitor rather than any sort of programming trickery.
I was hoping that I had missed out some vital detail that we could investigate further. Case closed then... unless you have a 1901 of course then you can go round your A500 owning mates house and show him this trick while looking smug! Lol
|
|
|
Post by mrbombermillzy on Feb 7, 2016 13:14:36 GMT
Ok Im a bit fustrated that I did not write down my detailed observations with the sync width/positioning. I was doing these tests 6 months or more ago, so I cannot remember all the details for that side of things and I wasnt really expecting the monitor to break before I got to finalise and document my conclusions.
Anyhow, the highest resolution that I did manage to record was 832x304/608i on the ranger. This was using the following reg/values:
6/25 2/121 1/104 35/111
I also mucked around with the character sizing as follows (reg/value):
23/255 9/254
but Im not 100% sure that they helped or were even relevant to the values above.
Ive realized that pushing the max resolution would be very monitor dependant and impractical for early monitors, so Ive decided to look more into extra colour per cell and (due to the monitor killing madness explained elsewhere) Im currently looking into this as a viable enhancement. I will still push the resolution boundaries, but only when using a safe output display like an abundant 15" vga tft panel and when I have time to make an adapter for my rgbi to rgb lead which will interface to the panel using 15 pin din. (Then I would have to punch in the values 'blind' until I hit the low end sync rate that the monitor will accept as 99.9% of vga monitors wont go down to 15-28Khz needed for any custom res between 320 and 600ish h pixels).
I havent really tested hard on the Sony bvm as horizontal pixel count is only 600 or so dots so would be hard to obtain any interesting results.
|
|
|
Post by mrbombermillzy on Feb 5, 2016 19:30:35 GMT
Im away from my test data atm tokra, but it will be interesting to compare the difference between our register value limits on different monitors. When I mentioned about breaking the 800 pixel barrier I was talking about tweaking the sync pulse rather than changing reg 0 to as high as you can go and maxing out the display start/end registers to get the borders widened to the edge of the screen.
As for ega mode, I was under the impression that it was a better fit for vga output.Perhaps not then.
I will put up some data I took from the ranger monitor and some newer figures that I recorded from my Sony bvm once I get back home.
Its a shame though as the bvm has a max horizontal pixel count of 6/700 so I cant really investigate any more in this department.
|
|
|
Post by mrbombermillzy on Feb 4, 2016 20:11:06 GMT
Ha ha! I thought that title might have caught your attention! :-) Clickbait aside though, I thought that I might share with you a screen effect that was created by the user macbacon on the c128 vdc and posted on a German C= forum, just incase you are unaware of it. Here is the effect: Now my German isnt great, but what I can figure is that it relies on a fault that the C=1901 monitor exhibits and so is not practical as it may not work on other monitors. Those of you who are a bit more fluent in German could possibly elaborate on anything I may have missed. The reason ive posted in the programming board is to hopefully find out how this effect was achieved and perhaps discuss any variations that wont destroy any more of our beloved crts :-) Heres the original thread: link
|
|
|
Post by mrbombermillzy on Feb 4, 2016 6:29:08 GMT
Yeah i know! And them monitors are not exactly common. Infact, apart from a spec in the amiga hardware database and a scanned page from computer shopper magazine the only other mention of that monitor on the net and pictures are the ones i put up. This has really made me think twice about doing such testing on delicate hardware again, or not taking the screen size outside the monitors comfort zone. And the vdc can EASILY wreck a monitor (eg switch on ega flag whilst displaying on a C= rgbi input monitor) so I would be careful before letting others loose with any monitor wrecking code! :-)
|
|
|
Post by mrbombermillzy on Feb 3, 2016 22:24:30 GMT
The only code that I have created so far was the vdc test suite (see my reply in the max resolution thread started by mirkosoft) which apart from testing the resolution limits also killed my monitor! Its written in basic but you are welcome to it if it will help you. I have something a bit more advanced planned but it may take a while. :-)
|
|