26th Sep 2020, 1:11 pm | #221 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
I think thats a great idea - the 2111 rams have an access time of 500-1000 nS so you'd have to search hard to find a eprom thats too slow. program one 256 byte page with the 00-ff chars and pit in the images somewhere else and that will let you test graphics, characters and the select lines, inverse video.... The only potential hiccup is how long before accessing the RAM you need to assert NENIN. I would guess anything over 1uS would be ok, since as previously discussed it seems the SC/MP just gives over control and sorts it out later. I was trying to work out what the SOC vdu did by analysing the circuit but I couldnt get my head round it. I need to finish that logic simulator of mine....
|
26th Sep 2020, 11:50 pm | #222 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
Re: Mk14 vdu
I set out hand-editing a couple of 'Text Card' screens of data for character mode test purposes but it is quite tedious, especially due to the fact that the VDU character set is not standard ASCII.
I'm now blundering my way through something which will convert ASCII text to the nearest equivalent MK14 VDU text and save it as Intel Hex. |
28th Sep 2020, 11:21 am | #223 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
Hi Guys,
I'd appreciate some guidance on the lower limit of read access time when the VDU's NRDS goes low to bring in data from the Mk14 memory. The original hardware timing is quite relaxed (2 microseconds to process each character, 4 microseconds to process each row of eight graphics pixels). I have 256 instructions to play with in each 625 scan line, which sounds a lot, but I might find myself short of time nonetheless. What speed memory (read access time) can I assume? 500 nanoseconds? 750? A microsecond? Any help much appreciated. |
28th Sep 2020, 11:40 am | #224 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
The MM2111 data sheet specified an absolute max access time of 1000nS. The MM2111 came in 3 variants, 2111 (1000ns) 2111-1 (500nS) 2111-2 (650nS). Perhaps ppl with real MK14s can tell us which variant they have.
The oft used AM9111 has several versions with speeds 500nS - 250nS. For your info I have attached data sheets which I happen to have on this laptop! |
28th Sep 2020, 11:48 am | #225 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
Just looked at the MK14 manual and it says MM2111-1 which would be 500nS.
|
28th Sep 2020, 12:23 pm | #226 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
Re: Mk14 vdu
Mine are NEC uPD2111 (As originally supplied by SOC) but I don't remember the speed suffix - will look tonight.
|
28th Sep 2020, 12:51 pm | #227 |
Heptode
Join Date: Oct 2011
Location: Culcheth, Cheshire, UK.
Posts: 637
|
Re: Mk14 vdu
Mine, also MK14 SOC originals, are NEC D2111AL-4
|
28th Sep 2020, 1:18 pm | #228 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
I've just had to remind myself: I'm not constrained to the way the hardware works: My PIC code can cache an entire row of character or graphics data to avoid repeatedly fetching it.
With 512 bytes containing the whole display data, and 256 scan lines over which to display it, the PIC only needs to perform two memory accesses per scan line! I can make these very relaxed indeed, timing-wise. How's about 1 microsecond between NRDS going low and sampling of data from bus? That should cope with even the slowest memory of the era. |
28th Sep 2020, 1:34 pm | #229 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
Re: Mk14 vdu
I've just squinted at an old photo of mine somewhere in one of the MK14 threads here and I'm sure mine are exactly that type as well. Karen seems to have brainstormed her way through this particular issue now anyway - let's go with 1000nS /1mS as the worst case scenario.
|
28th Sep 2020, 2:18 pm | #230 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Mk14 vdu
That would be fine if it can be done. The NEC rams Buzby mentions are 450nS so youd probably be fine with 500nS if you needed it. It seems SoC specified 500nS rams.
|
28th Sep 2020, 2:38 pm | #231 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
Re: Mk14 vdu
Agreed, 500nS. Brain is running (more (slow)ly) than usual today.
|
28th Sep 2020, 2:57 pm | #232 |
Octode
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,264
|
Re: Mk14 vdu
Originals from my mk14 were AM9111BPC and also marked P2111A-4.
Date code of the originals was 78, so maybe at that time it was no cheaper to use slower parts and possibly not so easy to find slower parts. From the INS8060 datasheet the read access time was 800ns at 4MHz, but the original mk14 crystal is 4.433618 MHz, which is approx. 722ns. |
28th Sep 2020, 3:36 pm | #233 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
Re: Mk14 vdu
Yours is the only original MK14 I have ever come across which had AMD RAMs supplied in the kit - you're really sure those are the original parts?
|
28th Sep 2020, 4:24 pm | #234 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
I suppose there is only one question still left in my mind: when the VDU is disabled should it cease generating video entirely, or should it simply generate a blank screen?
|
28th Sep 2020, 4:49 pm | #235 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
Re: Mk14 vdu
Suggest generating a black screen or even 'test card' with syncs so that flatscreens do not try to 'readjust' to the new framerate / aspect / resolution on loss of signal. Better to keep them fed with a steady signal IMO.
The main thing is that the VDU has to disappear as far as the MK14 is concerned, so there is no system slowdown while the VDU is disabled. Otherwise the cassette interface, etc, which depend on software timing, won't work. |
28th Sep 2020, 6:49 pm | #236 |
Octode
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,264
|
Re: Mk14 vdu
Those were definitely the parts fitted when I acquired the mk14 in the early 80s, but it was already built by a previous owner, so I don’t know for certain they were from the original kit.
|
28th Sep 2020, 7:16 pm | #237 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
Re: Mk14 vdu
Interesting, maybe if all this activity around the MK14 continues to bring other owners out of the woodwork we may see whether yours is unique or whether SOC actually did supply AM9111s in the kits for a time. Buzby's machine and mine are both issue II, probably bought within a few months of each other at most so it's not surprising that our kits used the exact same RAM IC type.
I've cobbled together something in Python, which I seem to have to learn from scratch all over again every time I want to use it, to allow the composition of fixed text pages in plain text which is then translated to 'MK14 ASCII' and output as Intel Hex. I'll port a couple of pages over to my uploader later and from there to the Issue VI MK14 + VDU to see if they look right when loaded into the real thing. |
28th Sep 2020, 9:31 pm | #238 | |
Octode
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,264
|
Re: Mk14 vdu
Quote:
|
|
28th Sep 2020, 11:40 pm | #239 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
Re: Mk14 vdu
Indeed, I don't know when AMD started making their 2111 equivalent.
I've created several test pages of VDU-compatible text, I'll make a 2K hex code 'bundle' consisting of the two graphic images already uploaded to this thread separately plus two 512-byte chunks of text. I'll probably include this one, attached. It's basically the character set, repeated twice, and the main purpose of it is to show whether all characters are being rendered correctly with respect to their character codes and with all their pixels present and correct. You may notice that the second block of text does not look particularly inverted in this image. My SOC VDU is not modified in any way and it ignores bit 7 of any character code that it reads. However, bit 7 of all the character codes in the second 64-character group is set to '1', and I understand Karen proposes to use bit 7 high to signify a character which should be displayed in inverse, so the second block is specifically there for checking that feature, should she manage to include it. |
29th Sep 2020, 12:03 am | #240 |
Rest in Peace
Join Date: Jul 2011
Location: Bridgnorth, Shropshire, UK.
Posts: 787
|
Re: Mk14 vdu
Hi SH,
Actually, I plan to make the inverse video feature work as to original spec I.e. controlled exclusively by the /INVRSE input. My use of a spare bit to address normal/inverted font data is an internal thing that is completely hidden from you. My implementation, on the face of it, does seem to offer the opportunity to mix normal characters with inverse video characters. The problem then is: what state should the porches be? i.e. how do we decide the background around the edges of the display if we're mixing normal and inverse video? The problem goes away if I stick to original specification. |