As I recall, the video chip has what we called a "regen" buffer, which is a contiguous array of
words, with the upper byte being the attributes and the lower word being the offset into the
character generator table (usually ASCII). In the IBM-PC this was usually at segment 0xB800
and went on for 4000 bytes, that being 80*25*2.
So while the programmer may be thinking in row/column numbers, when it comes time to
update the screen, the offset into the regen buffer is
Note: row and col are zero relative
NUMCOLS = 80
regenoffset = (row*NUM COLS*2)+(col*2)
or even more efficiently
regenoffset = ((row*NUM_COLS)+col)*2
To the chip, it doesn't think about rows and columns other than when painting the screen,
it presents so many dots per line, and so on.
When the video BIOS is "positioning the cursor", it is really just calculating the new regen offset
and doing what it takes to display a cursor in the appropriate spot.
Regards,
Douglas
On Sep 28, 2012, at 3:07 PM, David Giles <vk...@internode.on.net> wrote:
Hello Douglas,
The comments in the source are merely documenting as I figure out how the hardware works. The only question I have about the software is that now it is using a 6545 rather than a 6845, is there a speed/code size advantage by using row/column addressing rather than straight binary? Considering the board has no graphics capability and plenty of video RAM, it may speed things up even more. Just a thought.
Regards
David
On 28/09/12 09:19, Douglas Goodall wrote:
David,
The VDU code you are working with was actually based on code that I wrote whileat DRI for the Olympia "PEOPLE" machine, which was a non-PC compatible builtby the Olympia typewriter company in Wilhelmshaven (not sure of the spelling) inGermany. The XIOS was implemented to support both VT52 codes for wordstar andalso a private set of escape sequences that were Olympia specific. Also supportedwere a set of escape sequences that allowed the programming of soft function keys.There was also a separate program called "function.a86" that had a gui and used thespecial escapes to alter the function table in memory. Being a European company,the 6845 initialization bytes were appropriate for the Olympia supplied monitor andother from the region.
If you have a question about the code, let me know.
Douglas
--
On Sep 27, 2012, at 3:02 PM, vk5dg <vk...@internode.on.net> wrote:
Hello Oscar,
I've recently got my VDU card running and have been adding comments to the source code as I discover new things about it. I can tell you that the firmware is set up for a PAL monitor - it works at 312 lines non-interlaced at 50 fields per second. Also the jumpers for the character clock must be set as K1 2-3 (pin 3 of the 74669 HI) and K2 1-2 (pin 4 of 74669 LO). This gives an output of 2 MHz for the CLK signal (pin 21 of the 6545-1). I'm using a 30 year old green screen monitor on my board and after some adjustment of the picture controls it has given a stable picture.
Hope this helps for a start.
Regards
David
On Thursday, 27 September 2012 18:28:41 UTC+9:30, oscarv wrote:Hi all,
I recently completed a whole set of N8VEM boards (VDU, Zilog Peripherals, Disk IO and the 6809 board) to expand my N8VEM.
I have one question on the VDU... this is quite an old board by now so I wonder if anyone still has answers!
The board works well with RomWBW 2.1 but the top line of the screen is always garbled. See the picture: the top line should just show 'dir'. Also, there is faint but unusual 'ghosting' below the 25th line (second picture).
![]()
I've read in the old postings that the 6545 CRT chip sometimes needs tweaking of screen parameters, but I doubt that is the problem here - I get the exact same picture on two monitors. Both are PAL monitors but both are supposed to be able to deal with NTSC (I don't think that is where I should look for a solution). One monitor actually developed a scary crackling noise after 10 minutes - but that may be unrelated, as it hasn't been used for more than an hour in this century.I'm not sure where to start my bug hunt - any suggestions are very welcome!
Regards,
Oscar.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To view this discussion on the web visit https://groups.google.com/d/msg/n8vem/-/JvHzszIZs5IJ.
To post to this group, send email to n8...@googlegroups.com.
To unsubscribe from this group, send email to n8vem+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/n8vem?hl=en.
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To post to this group, send email to n8...@googlegroups.com.
To unsubscribe from this group, send email to n8vem+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/n8vem?hl=en.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To post to this group, send email to n8...@googlegroups.com.
To unsubscribe from this group, send email to n8vem+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/n8vem?hl=en.
