|
Post by tokra on Mar 30, 2016 13:29:47 GMT
Do you accept bribes? ;-)
|
|
|
Post by tokra on Mar 27, 2016 19:12:02 GMT
You should look at my VDC Mode Mania-demo which you can find on csdb.dk - there are 8x2 and 8x3 modes in there and the program is in BASIC mostly. If I remember correctly I commented the parts where the graphics-modes are set. Basically you use register 9 to set the char height to 2, but then you have to adjust the registers for vertical sync and height as well accordingly. This also works in text-mode, but only in bitmap-mode you can get background and foreground in an 8x2 area.
|
|
|
Post by tokra on Mar 10, 2016 8:55:46 GMT
The uIEC-hack firmware was done by hydrophilic some years back. I got an uIEC specifically to be able to use burst-mode on my C128. I agree that an update of this hack to the latest binary is kind of overdue. So, we can only try to persuade/bribe hydrophilic to try to apply this hack to the latest firmware, since it does not look like Burst-mode support will become part of the official firmware.
|
|
|
Post by tokra on Feb 13, 2016 17:06:14 GMT
For those of you fluent in german you can watch a 1 hour video from Humboldt University Berlin with Norbert Kehrer talking about his Asteroids emulator: www.youtube.com/watch?v=TPil9zsk75Q
|
|
|
Post by tokra on Feb 12, 2016 9:16:44 GMT
Norbert Kehrer's version is NOT a port of the Atari 800-version, but of the original arcade version! I quote from his website: "This program is an Asteroids emulator for the Commodore 64. The "emulation" of the arcade machine's CPU is done natively by the 6510 processor of the C64. The video and sound hardware is simulated by the Asteroids emulator program. In this way, the original arcade game program is executed and interpreted, and the original game play is (more or less) exactly reproduced." The version even makes use of the C128 in speeding it up about 30% to 2Mhz-mode in the border: csdb.dk/release/?id=116552&show=summary#summaryThe latest version however should be this one, apparantly there was a bug in the C128-speedup-code: csdb.dk/release/?id=116895&show=summary#summaryHe even did a PLUS/4-version of the emulator/game. So, to summarize: There IS a perfect Asteroids version out there
|
|
|
Post by tokra on Feb 9, 2016 19:59:49 GMT
mrbombermillzy: That is not what I meant. I know about the corruption at the bottom. Please take a look at the last image (with 84 characters per line). There please look at the top line where it is supposed to say "text that needs to be long enough" it says "text that needs vi be long enough". If you look further down where the "LIST" should be it just says "L T". You can see further down the same corruption. Actually what happens is that last characters of each char-line are printed at position 42 where they should not be displayed.
I suggest you just type SYS DEC("CDCC"),90,1 and try to type text yourself on screen that is long enough. You will see where the corruption happens.
|
|
|
Post by tokra on Feb 9, 2016 8:36:47 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?
|
|
|
Post by tokra on Feb 8, 2016 20:11:43 GMT
|
|
|
Post by tokra on Feb 7, 2016 21:27:51 GMT
No, actually color working correctly at resolutions larger than 640 pixels wide. They just do not work as supposed to. Some colors get doubled in the middle and so so on.
|
|
|
Post by tokra on Feb 7, 2016 20:28:51 GMT
Ok, I played around a little with my 1084-monitor. The widest I could get was about 832 which was only really stable if I set register 0 to 127. 832 was an edge case on reg 0=126 as was 840 on reg0=127. Either way those values prove no real practical value. I know the 1901-monitor cuts of left and right at about 750 pixels horizontal with no option to squeeze horizontally and the 1084 does not sync well above 600 lines. Most devices can't to either which leaves you at about 720x600 "compatible" resolution. As you mentioned at max resolutions the picture is either horizontally too wide or vertically too tall.
If you manage to get color working beyond 640 pixel width, please let me know. With all my tests the widest resolution for color to work successfully was always at 640 pixel (or maybe 648/656 but not higher).
|
|