Re: Mk14 vdu
 

Do you mean the memory ICs are dual-port? I have here an IDT7132 IC which is a 2K dual-port RAM IC, (48 pin DIP!). That was my original ambition, to put that between the MK14 and the VDU so that the VDU could scan and display the RAM contents without stopping the MK14 system, which would therefore continue to run at normal speed.

https://www.idt.com/eu/en/document/dst/713242-datasheet

Re: Mk14 vdu
 

No, the 2102 only had 1 set of address and control lines, but separate data in and data out. I recall that 8 bit S-100 cards had separate data in and data out paths, so there must have been some good reason for it. Without looking into it too hard, I imagine the changes required to the circuit to use, say 2114 RAM would be to use a bidirectional buffer instead of the two unidirectional buffers.

Although I do like the idea of using dual port RAM on the SOC VDU, it would allow running the MK14 at "full" speed rather than 4mHz.

Re: Mk14 vdu
 

Should you want to build this and use 2102s I have, I think, 16 of them I bought many years ago for a project which never got built.

Keith

Re: Mk14 vdu
 

If you do come across them then PM me with a price. Don't feel you need to hurry as it'll be a while before I'm reunited with my soldering iron!

Re: Mk14 vdu
 

Will do.

Keith

Re: Mk14 vdu
 

A number of the high-speed (45ns or less access time) 1-bit wide bipolar RAMs had separate Data In and Data Out pins. I've just been working on a device that uses a couple of the Hitachi HM6147, for example (4K*1 bit).

As an aside, I once built a colour (TTL RGB output) video display board using 3 standard ICs, and which needs 2 TTL signals from the processor (bidirectional, open collector driven). While it wouldn't be compatible with the SoC VDU board, it could certainly be hung off an MK14, you might even be able to use the flag and sense pins on the processor. The ICs were :

74LS04 (6MHz clock oscillator and a bit of buffering)
6264 (RAM, actually all you need is 1K*8, but the 6264 is common enough)
SAA5243 (yes, the teletext IC. You can read/write the video memory over the I2C bus you see...)

Re: Mk14 vdu
 

A nice idea, I bet those TT ICs were made in such large quantities that there will still be a good few around today.

It might be easier to bit-bang I2C with the 8154 ports because I2C uses the same line for data in and out, therefore you ideally need a single pin which can be both input and output.

You can simulate the open-collector nature of an I2C driver by writing a '0' to the 8154 data output latch and then control the line by changing the direction of the port pin - in output mode it will drive the SDA line low, and in input mode it will release the SDA line, which is always pulled up by a resistor, high.

Re: Mk14 vdu
 

That's certainly interesting. I think I have a teletext chip somewhere, part of a lot of random ICs I got from eBay years ago. Could probably be knocked up on protoboard fairly quickly.

Re: Mk14 vdu
 

You need one of the later Philips 'Computer Controlled Teletext' ICs in the SAA5240 series. Those let you read/write the memory over the I2C bus. Doing it with the older SAA50x0 series chips is a lot of work!


Yes, it's easier to simulate the I2C bus using the 8154, but that chip is getting hard to find. You can get away with a couple of diodes (to turn totem pole outputs into open collector ones) and pull up resistors. From what I remember you don't need to sense the SCL signal (just drive it) in a simple application like this so you could use a couple of the SC/MP flag outputs to drive the lines (via the diodes) and monitor SDA using the Sense B input or something like that.

At one time Philips produced a user manual for the SAA5243 which included a lot of useful information not in the data sheet. I have no idea where you'd get it now.

Re: Mk14 vdu
 

Just looked around, the SAA5240 is available quite cheaply in some quarters, one supplier in Ireland has them at around £2.00 although I happen to know from experience that supplier has quite a high minimum-order threshold. Still, they are available.

Re: Mk14 vdu
 

I wonder if this might be the SAA series user manual Tony had in mind:-

https://heyrick.eu/software/ttx/eurocct.pdf

Re: Mk14 vdu
 

I don't know if it is but it's got loads of useful info. Saved :)

Re: Mk14 vdu
 

I'm not absolutely sure (I will have to find my paper copy) but if it's not the same document it's very similar and contains much the same information.

Re: Mk14 vdu
 

Same site has datasheet for SAA5243, which the site owner thinks is so close to the SAA5240 that it wasn't worth looking for the one for the 5240.

Under 'Ground Control Adaptor'...

https://heyrick.eu/software/winttx/datasheets.html

Re: Mk14 vdu
 

Well back to the real VDU - something to watch out for - in my pursuit of learning how to control the VDU from the 8154 I have somehow fried a bit of IC1 74L86 (Quad exclusive OR - the gate on pins 1,2,3) these control the ReversePages Input and TopPage Output. I bought this from Martin when I bought the PCB as it is NOT the same as the 74LS86 pinout - two of the gates have the output and one input reversed:

Attachment 207767

I have paid the LittleDiode premium to (hopefully) get a replacement in a few days - however, if anyone has a similar problem I just bent out Pin 3 which was grounding the TopPage Output line and tapped into Pin 2 from IC6 (Pin 15 on the 4040) - this means you cannot have the F00 at the top which is better as the first line is not visible. But, it will do to allow the whole of RAM to be visible for the moment.

Re: Mk14 vdu
 

This is beginning to sound quite dangerous. I'm wondering if it would be wise to have current limiting resistors (100R?) between each 8154 port pin and the corresponding VDU control input or status output.

Obviously if you were to inadvertently set 8154 PBO to output mode in direct opposition to VDU 'top page' no good would come of the resulting bit-battle, so separating them with a modest resistance would allow them to go to opposing states without damaging each other.

If you are jumping 'top page' across to one of the page select inputs to auto-switch between one 256-byte block and another, it follows that the 8154 pin connected to that page select input MUST be left in input mode so that it does not fight with the 'top page' signal.

I've put together my 'double sided stripboard' and grafted a DIN female connector onto one end, I've run the clock signal through from one side to the other and added the NRDS pullup, my edge connectors for the MK14 end are on order, hopefully they will arrive early next week and then I will be able to start to make progress on this.

In the light of your experience, maybe let's just all agree now that three out of four of b9-b12 (page selects) will be held in specific states by links, the remaining page select pin will be connected by a link to 'top page', inverse and reverse will stay linked for 'not inverse' and 'not reversed', Character/Graphics selection will be via Flag 2, and VDU enable / disable from Flag 1, possibly through a transistor inverter so that the VDU is off until otherwise informed.

The 8154 ports will arguably be much more useful for general I/O and should be disconnected from the VDU control lines and made available for connection to the outside world instead of tying them up for VDU functions.

The actual page select / top page combination will change (permanently, I think) when we all have extra memory mapped at 0200-07FF because it will make far more sense for the screen memory to be in a straight 512-byte run which is not used by the system for anything else.

Re: Mk14 vdu
 

I think that is how I fried the '86 as I used 0xFF to enable all of Port A as outputs - because stupidly I could not work out what was happening using 0x01 only to enable into 0x0822 - by the way when you do that PA7-PA4 end up as Outputs anyway ... I was very confused.

(Edit: to clarify of course I had used a clip lead to link the connections so when PA1 went output it did just what you describe. The connection on the VDU PCB has been pulled out and bent up now like I did for INTR etc...)

Still I have learned a lot so £12 is a cheap lesson I suppose.

Re: Mk14 vdu
 

... and yes I agree on the mapping solution - mostly. I had been toying with using your Opto isolator trick to allow the TopPage to be mapped to any of the four lines...

All this comes with risks which is why it is better I experience them not you - but, for safety I think a direct connect is probably not a good idea - after all software when it goes wrong can write all sorts of junk. We do not want to create our own HCF instruction (Half and Catch Fire) that literally does what a POKE was rumoured to do on early PETS (set a chip free running near a flammable material...).

Re: Mk14 vdu
 

I think I'd better read my (original, printed paper) 8154 datasheet again tomorrow. I thought that the DDR (Data Direction Register) for port A was at 0822 and writing '1' to a bit of the DDR made the corresponding port bit an output. Apologies if I turn out to have misread that.

Re: Mk14 vdu
 

No you are correct but, you need 0xFD to make em all except PA1 outputs... I just assumed that writing a 1 made the whole port an output - then when the penny dropped I quickly dropped 0xFF into there - and started messing while the obviously resilient £35 pound chip slogged it out with the £13 eventual loser...