|
Post by tokra on Feb 3, 2021 10:17:37 GMT
|
|
|
Post by tokra on Jan 22, 2021 16:28:55 GMT
Sounds interesting. Can you provide the link or demo-program? Nothing to see in the post above.
|
|
|
Post by tokra on Nov 30, 2020 12:16:13 GMT
Wow, the software-sprites look great.
But 160 pixel width with flexible colors would just be normal bitmap-mode (640 pixel wide) with 2 colors per char-block (char height of 2) where each color-pixel is 4 pixels wide. There was a Koala-picture converter for that mode in an old german "128er"-special issue (issue 76 page 39).
Or are you using text-mode and play around with reg 22?
|
|
|
Post by tokra on Nov 30, 2020 11:31:49 GMT
Please tell us more about VDC-MCM mode ;-)
|
|
|
Post by tokra on Nov 29, 2020 19:09:50 GMT
SRAM-replacement is the only known fix for the VSP-bug. I have a similar replacement-board in my C128D that has been a VSP-bug-superspreader (so to speak) and since the SRAM-replacement is VSP-safe.
|
|
|
Post by tokra on Oct 22, 2020 18:41:31 GMT
I've tried the mode you described in BASIC, but did not get better results than you did. By my thinking the mode you set up should have 192 bitmap-bytes (3 lines of 64 bytes) follwed by 64 attribute-bytes. But I don't even get that far, in fact using reg 27 in hires-mode seems to screw up the VDC. I've tried monochrome-mode and when I set reg 27 to $40 and try to write consecutive bytes they are duplicated in the picture (about 8 kilobytes later) and some bytes are even not written it seems. Totally unreliable results. I think reg 27 is only meant to be used in text-mode and the VDC can not handle it in hires.
|
|
|
Post by tokra on Oct 22, 2020 13:02:09 GMT
Interesting :-) Can you post a full test-program to try out? For testing I always set reg 36 to 0 to minimize side-effects because of that. You can always go up later. Otherwise this "should" work. Looks like work for willymanilly
|
|
|
Post by tokra on Oct 20, 2020 12:23:58 GMT
Interesting! Where do you got the source with Von Ertwine's notes from? I remember reading somewhere there was lots of code commented out that would make CP/M run in 2 Mhz more often and that (maybe due to time constraints) this was not followed through. Also: Do you know about this CP/M version: csdb.dk/release/?id=171699&show=summary#summaryThis seems to be a more recent optimization of the CP/M-system using ZPM as basis (Z80-optimized code instead of 8080-compatible). I'm not sure at the moment what would be the "best" CP/M-system to use for the C128: CPMFAST, ZPM3 or maybe your version? Would be interesting to compare or combine the three to make a "definitive" version.
|
|
|
Post by tokra on Sept 26, 2020 9:56:04 GMT
If the CMD-devices provide the RTC on the error channel you should first read this out and then use the extracted data to set the RTC. I have found the following to that can send commands over the serial port: www.herne.com/htk.htmMaybe that's a good starting point.
|
|
|
Post by tokra on Sept 21, 2020 8:40:10 GMT
Ah, now I get what you meant. NTSC is usually 525 (half)-lines and PAL 625. Home-computers usually only use the first field, so 262 lines (NTSC) or 312 lines (PAL). Within this area you need to deduct some lines for VBLANK which usually gets you 240 lines in NTSC and 288 in PAL. This would mean 30 text-lines in NTSC and 36 in PAL. You would just need to adjust register 6 accordingly (and register 7 to center the picture). Either way at this resolution you will most likely be in the overscan-area on most display devices. It's a good idea to let the user choose the best display-position (reg 7) at those resolutions.
|
|