Yet another MK14 vdu card

[Realtime]

The REVPGS signal is also available on the DIP switches so allows the two video pages to be correctly ordered.

[Realtime]

Originally Posted by Timbucus

No wow nice start - the only game we know of other than TANKS is Pong and we do not have a copy - I have asked a few times on the forum of the guy who wrote it but, it seems to fall on deaf ears.

Here's the MK14 pong game created by Milan Humpolik. I've modified the .asm to compile under SBASM and added a header to it to recognise the author. The zip file is mostly self explanatory, but there are 3 .wav files for loading into the MK14 using the standard tape interface. The load addresses are in the file names. Run the program from 0x400.

Here's a short video of it running. I was messing about with NENIN timing on my VDU card at the time and seem to have slowed the whole game down, but you get the idea!

Enjoy

[Timbucus]

Just saw that video on the Tube and had to jump on here to see if you had posted it - thanks for securing a copy. Having trouble at the moment with my hip so cant sit at computers but, will try it out as soon as I can.

[Timbucus]

Originally Posted by SiriusHardware

TOP PAGE also eventually needs to be able to be connected to SWAP PAGES in case you want to swap over which halves of the screen are inverse/normal or which halves of the screen are graphics / characters.

Experience has taught us that where there is the possibility of TOP PAGE being connected to an 8154 port pin which might get into output mode somehow and fight with TOP PAGE, it is a good idea to have a modest resistor in series with the TOP PAGE output so that any voltage difference arising can fall across the resistor, reducing the likelihood of damage to the TOP PAGE output or to the corresponding 8154 port pin.

I think Tim(bucus) managed to take out the original 74L86 in his SOC VDU replica that way, hence his earlier interest in a substitute / clone of that IC.

I have used the swap pages feature - it is handy on an unexpanded MK14.

And indeed I can confirm that was a hard way for me to learn the lesson. A similar event cost me one of my 8154's as well so the resistor against user stupidity is a must

[Realtime]

Originally Posted by Realtime

Here's the MK14 pong game created by Milan Humpolik. I've modified the .asm to compile under SBASM and added a header to it to recognise the author. The zip file is mostly self explanatory, but there are 3 .wav files for loading into the MK14 using the standard tape interface. The load addresses are in the file names. Run the program from 0x400.

Here's a short video of it running. I was messing about with NENIN timing on my VDU card at the time and seem to have slowed the whole game down, but you get the idea!

Enjoy

I've just learned something that surprised me. I had always thought that the TAPE I/F code in the monitor ROM was limited to transferring blocks of 256 Bytes. By accident I sent it the full 2 1/2 minute wav file for PONG (so about 600 bytes) and it loaded correctly across 3 consecutive blocks of memory. That feature, combined with a VDU interface, really does make it a proper computer

So here is an updated zip file with one long wav file instead of 3 shorter ones.

[SiriusHardware]

I had always thought that the TAPE I/F code in the monitor ROM was limited to transferring blocks of 256 Bytes.

Me too, and I think I have stated that as a 'fact' on more than one occasion, so thanks for pointing that out.

Of course it was never possible to notice that on an original MK14 with only the full 640 bytes of memory installed, because the three block of memory were never continuous.

[Realtime]

Hi, I've been a bit quiet recently as I've been multi-tasking on the VDU module and a new game. I mentioned some time back that I had started INVADERS for the MK14 and it's now ready to unveil. Got to say I'm pretty pleased with the end result.

- You have 5 lives
- When you clear all invaders from the screen a new set of invaders appear
- Hitting an invader gets you 1 point, up to a maximum 99 points
- The invaders are rotated around the screen (as opposed to zigzagging left/right). After 14 rotations the invaders drop down a row
- Key 1 to move shooter left
- Key 2 to shoot a bullet
- Key 3 to move shooter right
- Key GO to restart game once all lives are used
- Key ABORT to exit to monitor at any time
- All characters on screen are defined by constants, so easy to customise

The game requires continuous memory from 0x0200 to 0x07FF and also uses the MK14 base RAM. The memory map is:

0x200-0x2FF Video RAM top half of screen
0x300-0x3FF Video RAM lower half of screen
0x400-0x7FC Game code. Yes there are 4 bytes spare
0xF20-0xF36 Game variables

There is also control of the VDU module via the INS8154. For correct operation the VDU TOPPAGE signal needs to be wired to PS1 to properly display the 2 pages of video RAM.

It takes 4 minutes to load using the standard tape interface and about 4 seconds using Coolsnaz2's M5Stick-C based fast loader.

Attached are a couple of screen shots and here's a link to a short video. I just bought a USB video capture device so the screen shots and video are direct from the VDU module.

https://youtu.be/GBNdN9o6Emk?t=5

I will be making the assembly code and hex available shortly - just want to add a few more comments to the code. I'm sure there are areas that can be made more memory efficient but for now it fits and it works.

[SiriusHardware]

Well done, Ian. Looks like the MK14 VDU finally has a Killer App some 44 years after it originally arrived.

I'm sure Tim will be delighted to show that off at the forthcoming meet up at the Centre For Computing History if you can get a copy to him in time.

[Slothie]

Great work, its good to see the VDU getting a good application at last. Looks like you squeezed every byte out of the available memory!

[Realtime]

Attached is a Zip file containing:

Invaders.asm - written for SBASM
Invaders.lst - assembled code listing
Invaders.hex - Intel hex file
Invaders.bin - raw binary used to create Invaders.wav
Invaders.wav - 4 minute 20 wave file for the standard tape interface

Would love to hear that people have got it running on their MK14s and know what setup you're using, e.g SoC VDU module, Ortonview, PI based VDU card, etc.

Enjoy!

[SiriusHardware]

Nice to see that there has been so much interest in this already (eight views or downloads already, not including myself as I haven't grabbed it yet).

For your next trick, dare I suggest a 'demo' mode (ie, game starts playing itself if the controls are not touched for a minute or so). It would be a really good way of stress testing a complete MK14 + extra RAM +VDU setup, but I can't begin to imagine how difficult that would be given the remaining memory available.

I'll try to run this version up with these configurations later in the week:

issue VI + Homebrew extra RAM (0200-07FF) card + original SOC VDU

issue VI + Slothie-Ortonview which has onboard RAM at 0200-07FF.

[Timbucus]

Well despite feeling rough with another dose of the dreaded virus (arggg I hope I am clear by the weekend as it is the 40th Birthday Dragon Users Group meeting in Port Talbot next weekend and I really don't want to miss another show) I just had to try out the Invaders game on my:

Issue VI+Slothie-OrtonView with onboard RAM.

What a great game once I remembered to flick the switch to text mode (no INS control yet on mine). Managed to get to level 2 and score 25 - one of the invaders had glitched (unless on purpose) and was only / not \/ so close to impossible to hit - that's my excuse anyway.

This will go down a storm at Cambridge on Nov 5th/6th - Invaders is also the demo game I have for the Triton...

[SiriusHardware]

Sorry to hear you are battling illness again Tim - I am only just starting to throw off a cough that started on Sep 3rd. (Not Covid, but I did wonder for a while as it was the worst chest infection I've had for years).

Your glitch could be a manifestation of the Ortonview 'occasional corruption' bug - if it's easy for you to do so, try swapping in your replica SOC VDU (I will make the same comparison, Slothie-Ortonview vs. SOC VDU, when I get the chance).

[Realtime]

Thanks Tim for making the effort to test the game, especially when you’re not feeling great. The half-an-invader is not a graphics card issue, it’s a ‘feature’ . If a rotation of the invaders occurs just as the bullet is being moved it can sometimes erase one wing but not be seen as a hit. Even when crippled the invader will still bomb you though. It is possible to shoot them down, just needs a little more effort to predict when to shoot.

Regarding SiriusHardware’s suggestion of a demo mode. It might be possible if I used the remaining base ram at 0xF40 or the expansion at 0xB00. It would mean loading the game in 2 sections unless someone has come up with an Intel hex loader.

Right now I’m focussing on building a 3rd VDU module and 2 more DM8678 replacement modules, so I’ll put the sw to one side for a bit. If anyone is interested in the modules I’ll work out a price for them. Need to cover costs but not worried about making a profit as such.

[SiriusHardware]

It is an indication of your confidence / competence that you actually took my suggestion seriously - I said it with a 'straight face' but I didn't really expect you to leap into action and do it. (Nor do I).

The uploader I use actually only uses Intel Hex files, it works by reading the Intel hex code and converting it into the equivalent keystrokes by which a human operator would enter the code (there is a microcontroller, ie, Raspberry Pi or Arduino, connected to the keypad edge connector via two banks of optocouplers). It's not as blindingly fast as Coolsnaz2's asynchronous serial uploader, but still faster than loading from cassette or typing the code in and it does have the ability to upload across split memory areas.

So for me, code split across discrete memory blocks presents no problem but I understand that splitting the code across non-continuous memory would break your new found ability to load all of the code in in one go - therefore I would not ask you to do it.

I think it's fair to say that Tim and I, at a minimum, are both interested in getting our hands on one of your CPLD VDUs whenever you feel you (and they) are ready. Slothie and Mark may also be interested.

I am an electronics repair tech by trade and I work with SMD all the time so if you preferred to supply me with one in kit form that would not be a problem - as long as none of the devices are BGA (ball grid array) packages, as we don't have facilities for working with those. 100 pin or 144 pin fine pitch flat-pack ICs aren't a problem for me though.

[Realtime]

Originally Posted by SiriusHardware

I said it with a 'straight face' but I didn't really expect you to leap into action and do it. (Nor do I).

Haha, I must learn to relax. That said, a stand alone demo mode could be quite a good system tester and fit in the same memory footprint as the Game.

[SiriusHardware]

Well, don't let us stop you. Any sort of 'demo' which is quite graphics intensive and churns out continuous VDU activity over a wide area of the screen has potential as a system test. It wouldn't actually have to be a game, something like a kaleidoscope simulator (which admittedly might lose something in monochrome) would do.

I'm in the early stages of setting up to try to run MK14 Invaders on at least one of the configurations I mentioned earlier. (There, I've said it, so now I have to do it).

[Realtime]

Originally Posted by SiriusHardware

if you preferred to supply me with one in kit form that would not be a problem.

I‘d be happy to do that but the CPLD and a handful of components need to be fitted so it can be programmed and that’s half the job done.

In terms of connectors, I have 64 way connectors to mate with the gold fingers on the Rev V / Rev VI PCBs. I think Timbucus has used a DIN41612 64 way (?). I’ve built 2 modules with no connector fitted. I’ll test them as far as I can but if the connector can be supplied I could finish off the build. Let me know what you think, or if anyone needs a different connector.

[Timbucus]

Yes I would of course love one and I have used a DIN41612 female (the PCB straight mount type) soldered directly either side of the Issue VI fingers.

I then can use right angle or straight through Male ones on the peripherals. I adopted this method as the SOC VDU was shown in the advert with the male right angle unit fitted - which cried out for a mating one on the MK14 but, you do have to juggle some of the connectors around to make it usable. I will see if I have any in stock if not I will have to order one. Did you put the holes for a right angle Euro on the PCB or do I need a straight one to solder to PCB fingers?

I did try my Issue VI with home made RAM and SOC VDU Replica but, as the mapping for INS control was not the same as mine - I usually only use main RAM for screen it would not run and I do not feel up to doing a code mod at the moment.

[SiriusHardware]

Of course, I almost certainly don't have the means to programme the ICs myself.

I have a spare 'straight' 32+32 way edge connector which should fit into the holes you provided on the initial design, but if you have some yourself and can fit one to the finished article I don't mind if that is included in the cost because I use that 'spare' connector to connect lash-up interfaces to the issue VI.

As possibly mentioned earlier, the most flexible connection you could provide on any final version would be the same type of double sided edge connector with the same (mirrored) pinout as the issue VI edge connector, as that would allow almost any kind of 32+32 row connector to be slipped on over the edge and soldered to the contacts on the upper and lower side of the VDU PCB, then it would be up to the user to decide what sort of connector to use.

If you did them like that, you could still test them prior to dispatch yourself if you soldered two of your 32+32 way edge connectors back to back so you could connect the VDU board to your issue VI for test purposes.