Mk14 vdu

[Timbucus]

Wow you were burning the midnight oil literally - I need to step up my game if I have any chance of catching up. Exciting stuff well done

[Slothie]

All this is making me want to try out PICs again. I think I'll try and upgrade the PIC14 firmware to add in some of the changes George made to implement the memory images. It looks to me that george has slightly different hardware than mine, because he has a free I/O port, whereas on Phil's board only 3 bits of port E are unused. One of these could be used to implement the 9800 baud serial output to allow me to get debug messages out and there seems to be some orphaned code in Karens source to do this. Then if I get ambitious I could port the code to a PIC16F18877 and make use of that extra memory to add the expansion RAM to the MK14 simulation. Just need to see if the PIC 16F18877 can be programmed with my ghetto programmer....

[SiriusHardware]

Well done Karen, you seemed to have gone a bit quiet, now we know why.

My connector is now fully wired (although I left it at work for the weekend) so if you are happy that the port pin allocations will still be as you stated in #187 I'll start connecting it up to my PIC on Monday. I've already built and attached the little video-buffer circuit.

[Karen O]

I've buzzed it through and tidied the rats nest. I'll buzz it through again after I've had a rest. I've built it on a Euro-size prototyping card - not my preference but it has pads for the a/b connector, making it possible for someone to use it on their Mk14 at some point in the future.

When I'm confident I've got the firmware right, I'll post it to Timbucus for distribution along with my SC/MP machines

[SiriusHardware]

I have several spare '44-pin demo' PIC boards of the type which came with some versions of the Pickit 2s and Pickit 3, so I'll probably build my 'final' version on one of those, using a SM-version of the 887 of course.

Tim has already remarked on the exquisite neatness and crafts(wo)manship of those items he has been privileged to see so far.

[Karen O]

That's neurosis, SH

And I like to put more into a project than is strictly needed to get a working result.

I've buzzed out the board again. Just got to fit the video out components, then I can get on with the firmware.

[Karen O]

Well here it is!

Time to get PIC code hacking now!

[SiriusHardware]

Magnificent effort as always Karen, but I hope you are allowing yourself some rest from time to time. From what you've written earlier in the thread, it sounds as though you have the code 90% written in your head anyway.

[Karen O]

Perhaps I should mention: my firmware will calculate the upper four bits of the address for both the top half of the display and the bottom half during frame blanking (where time is plentiful). It will also sample VDUON, INVERT, etc. at this time. This means that any tricks by which the control signals are changed mid-field (e.g. to make bottom half inverse video) will not work. The SC/MP will be unconscious anyway.

[SiriusHardware]

Although it's true that the SC/MP can not do anything to influence the control inputs while the screen is being rendered there is one other signal which can, and that is TOP PAGE, generated by the VDU.

Although primarily used for toggling between two different 256-byte blocks of screen memory, it can also be connected to any of the other control inputs as well to change whatever property they control half way through the screen.

For example, TOP PAGE can be taken to the Graphics/Character mode input to make the VDU display graphics in one half of the screen and characters in the other. This is quite a useful thing to be able to do.

[Timbucus]

Originally Posted by SiriusHardware

For example, TOP PAGE can be taken to the Graphics/Character mode input to make the VDU display graphics in one half of the screen and characters in the other. This is quite a useful thing to be able to do.

Yes I think if it is possible to have that option it should be simulated as it is likely to be used.

[Karen O]

Thank you for drawing attention to this subtle aspect of VDU behaviour (which I hadn't remotely considered).

I'm sure I can incorporate this: as well as working out the page number for the top and bottom halves, I will need to work out separate flags (e.g. inverse video).

One thing concerns me with this project. I make us of the serial port in synchronous mode in order to serialize the video. This is the first time I have done this where I change the bit rate dynamically. I am uncertain about the phase that the serial port will adopt following a change. Hopefully, switching the serial port off and on again (cue Roy) will sort it out but it's all a bit of an unknown at the moment.

One idea I'm mulling over is to treat graphics as two characters (i.e. a nibble in each) and avoid bit rate changes entirely.

[SiriusHardware]

I love that idea.

Of the various control inputs, the ones which might realistically be manipulated by TOP PAGE in real life are Graphics / Chars, certainly, Normal/Inverse possibly.

It wouldn't make logical sense for VDU enable / disable to be used in this way unless TOP PAGE continues to output its usual waveform even when the VDU is disabled. If it does I suppose you could use it to enable the VDU for only half of the screen (upper half or lower, would be determined by the state of SWAP PAGES).

Nor would it make sense for SWAP PAGES to be manipulated by TOP PAGE since doing so would only result in the same 256-byte page being repeated twice, an effect much more easily achieved by just applying a static upper 4 address bits to PS1-PS4.

So if you can get Graph / Char and Normal/Inverse to respond to a mid-screen change of state of TOP PAGE, that would probably be enough to satisfy any real-world need.

[SiriusHardware]

It has been a very long time since I really played with the VDU and did everything which could be done with it, so I thought I had better check that connecting TOP PAGE -> GRAPH/CHAR actually does work as I remembered it did.

This is an off screen shot of a mock-up (I stress, a mock-up) of a 'graphic' version of Moon Lander which would feature a changing 'view out of the porthole' on the upper half of the screen and the essential 'instrument' readouts as text on the lower half of the screen.

All I've done here is prepare a half screen of text data and a half screen image and loaded them into 0200-02FF and 0300-03FF respectively, then linked TOP PAGE to GRAPH/CHAR as well as the PS1 input which it was already connected to.

This is just to verify that the split graphics / text feature really does work on the original VDU.

[Slothie]

Looking forward to the finished game Sirius!

[SiriusHardware]

The sooner you write it, the sooner we can all play it.

While I had the VDU up and running I also looked (with a scope) for the answers to a couple of other questions:

Q: Does the VDU continue to output a video signal, albeit black / blank, when it is disabled (VDU_ON = 1)?

A: Yes it does. The video part of the signal vanishes but the sync / black level continues to be generated.

Q: Does the TOP PAGE signal continue to generate its output when VDU_ON=1?

A: Yes it does. The signal on TOP PAGE is exactly the same whether the VDU is enabled or not. However, the state of the TOP PAGE signal is a bit of a revelation - the LOW portion is steady low as expected but the HIGH state looks more like a fine toothed comb, high with a forest of very narrow low spikes which go all the way to 0V.

[Timbucus]

Funny enough I had thought once I had some memory expansion on it would be fun to do an illustrated Text Adventure with that split screen format but, a graphical lunar lander sounds much more fun...

[SiriusHardware]

I know you are The Man when it comes to text adventures but... no QWERTY keyboard...? I know, I know, there are enough rows and columns on the keypad edge connector to support a full alphabetic keyboard.

Let's say you store all the 'big data' for a text adventure (location and object descriptions and location graphics) in a serial EEPROM which you read from using the limited I/O of the SC/MP or some pins of the I/O port - do you reckon you could write a parser which would run in the maximum available RAM, including RAM at 0200-07FF? (Bearing in mind that 512 bytes of that would be screen RAM).

If you could, the sight of an MK14 running a playable graphical text adventure would be quite an eye opener at computer meets, etc.

[Timbucus]

A serial eeprom was exactly what I thought - in terms of the keyboard it could be a much simplified verb noun state - a bit like the Apollo guidance computer. I am sure if I implemented the very bare system it should be possible - indeed that is why I fancy the challenge...

Recently I completed typing in and running the Maze game which is 7 segment based from Complement and Add - I will try and put up a post with it running and a link to a video - it is quite a good game to play and that fits in a basic machine! It uses a very similar idea to the one Ken Reed proposed in 1980 but, pre dates it. I am sure I have mentioned before if I did this it would have to be called Prequill

[SiriusHardware]

Arghh, that was nearly quite good!

Another possible idea for a VDU game, A 2D look-down maze-escape game (with a maze twice the size of the screen, player always in the middle, maze shifts left / right / up / down as the player moves, maze walls revealed as the player explores).