UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Closed Thread
 
Thread Tools
Old 2nd Jul 2022, 9:05 am   #101
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Yet another MK14 tape interface (ESP32).

Quote:
Is there a more efficient way to decode these lines, ie 1 chip instead of 2.
I think we found that there is no need to involve the NRDS and NWDS signals directly in the decoding circuit, for example on the EPROM you can take NRDS Directly to OE on the EPROM rather than threading it through the decoder. That's assuming your PROM / EPROM device has both a CE and an OE pin.

The OE pin on the EPROM will be activated every time the CPU does a read-data from anywhere, but the chip will only respond if its CE pin is also taken low by the address decoder.

The address decoder only needs to focus on generating CE signals for the two memory devices within the correct memory ranges. This may help you to simplify your circuit.

As you have the ability to program memory devices you could also consider trying to use a fast EPROM as an address decoder using the D0 output as chip enable for the RAM and the D1 output as chip enable for the EPROM, that would allow you to create a custom address decoder with only one chip. I have never tested this idea because the response time of an EPROM (measured in the hundreds of nanoseconds) could be too slow, even on a very old system like this. Also, EPROMS are usually wide bodied devices so if your aim is to keep the circuit small, that's not so good. There are historical instances where BPROMs, with their response times in the tens of nanoseconds, were used as custom address decoders - in the NASCOMs for example.

Where this general method is used, the programmable device involved is nowadays more likely to be a GAL, but not so many people have the means of authoring and then programming a GAL, also GALs themselves are now rather old technology, meaning they are getting more expensive and hard to find.

Straightforward TTL probably remains the better bet for now.

Last edited by SiriusHardware; 2nd Jul 2022 at 9:13 am.
SiriusHardware is offline  
Old 2nd Jul 2022, 1:55 pm   #102
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Yet another MK14 tape interface (ESP32).

I remember the improved memory test from Slothie but, can't locate it at the moment. The one I used to visually check the extra RAM for Video is simple...

Code:
	.CR scmp
	.TF testmem.hex, INT
        .OR 0xF20

data	.EQ 0x200

start	ldi /data	Point P1 to data area
	xpah	1
	ldi #data
	xpal	1
	ldi 0
	st count
loop	ld char
	st @1(1)
	dld count
	jnz loop
	ild char
	jnz start
	xppc 3


count	.DB 0
char	.DB 0
;
; Bytes for loader
	.OR 0xFFFE
	.DB start>>8
	.DB start
	;.DW start
With a hex of:

Code:
:100F2000C40235C40031C400C80EC00DCD01B808DC
:090F30009CF8A8059CEA3F0000B2
:02FFFE000F20D2
:00000001FF
Timbucus is offline  
Old 9th Jul 2022, 8:27 pm   #103
coolsnaz2
Tetrode
 
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 86
Default Re: Yet another MK14 tape interface (ESP32).

All,

Thanks for all the answers to my questions.

Please find attached issue 2 of my ROM/RAM board, a little neater. As Mark1960 suggested I have used a 74LS156 with pull up resistors, thanks Mark.

I am thinking of trying to develop a VDU board for the MK14 using a Raspberry Pi Zero, unless you tell me it's been done before or it's not possible.
Attached Thumbnails
Click image for larger version

Name:	20220709_194359.jpg
Views:	55
Size:	107.4 KB
ID:	260682  
coolsnaz2 is offline  
Old 9th Jul 2022, 10:47 pm   #104
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Yet another MK14 tape interface (ESP32).

Even nicer than the first version.

Essentially the way the original VDU works is it tells the SC/MP to pause and remove itself from the system buses, then the VDU scans the 512 memory addresses it has been told to use as screen memory and renders the output to the video output in real time either as graphics or characters, then releases the buses and allows the SC/MP to carry on. It repeats this process for every TV frame. As the owner of an original VDU you will be better placed than most to know how a replica or emulator should behave.

Maybe a good starting point for using a Raspberry Pi Zero for this purpose would to look at the RGB2HDMI project, which takes standard definition RGB (colour) video in from a retro system and outputs it as an HDMI video signal.

https://github.com/hoglet67/RGBtoHDMI

If you have a good understanding of Microchip PIC assembly language you could also study how Karen Orton's code for Ortonview works - the code (including source code) was posted in the Mk14 vdu thread linked to a few posts ago.

There would be a decision to be made about whether to emulate the original SOC VDU so that the few 'legacy' programs written for the original VDU would work on yours as well, or whether to just go in a completely new direction and make something which is better / more usable. For example, the original VDU only has a limited set of characters (upper case only) and you might want yours to support the full standard ASCII character set instead.
SiriusHardware is offline  
Old 10th Jul 2022, 9:31 pm   #105
coolsnaz2
Tetrode
 
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 86
Default Re: Yet another MK14 tape interface (ESP32).

SiriusHardare.

Thanks for your post, I had a quick look at the RGB2HDMI project, don’t think this will help me. I am currently working my way through the 46 pages of the MK14 vdu thread, so my specification may change. Currently I intend to use IDT132SA100P as the memory between the MK14 and the Raspberry PI, this chip was mentioned in the vdu thread. I have never programed a PIC, but I will have look at the code from Karen Orton to see if it makes any sense to me.

Version 1 of the Raspberry Pi Zero MK14 VDU would emulate the original SOC VDU, with the following exceptions:-

VDU memory will be 512 bytes of memory at 0400.
The output will be via HDMI from the Raspberry Pi.
The screen will appear in a window on the raspberry pi desktop.
The MK14 will not be interrupted, so will run at full speed, and the MK14 crystal will not need to be changed.
Only the original character set will be implemented, followed shortly after by the original graphics mode.

The program on the Pi will be written in Python. I have mentioned the Raspberry Pi Zero, but any Pi with the 40 Pin header should work, but the Pi Zero could be mounted onto the same board as the additional memory.

Should I start a new thread for this project when I have got something that works?
coolsnaz2 is offline  
Old 10th Jul 2022, 11:51 pm   #106
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Yet another MK14 tape interface (ESP32).

Yes please, as the OP for this thread it is your prerogative to take it in whatever direction you want within reason, but it has come a long way from being about a tape transfer system so putting your VDU work in its own appropriately titled specific thread will make it easier for interested parties to find and follow.

You mentioned the IDT(7)132SA100P, I think I originally mentioned that (I have one here), it's a dual port RAM which if correctly inserted between the MK14 and the original VDU would allow the MK14 to run at full speed because the VDU would access the memory independently through the second access port.

You propose to map the Dual port RAM IC's primary port into the MK14 memory area at 0400 plus, and to use the Pi rather than a hardware VDU to read the screen memory contents out through the dual port RAM's second port and render it to the screen through the Pi's own HDMI video output. It will be interesting to see how you get on.
SiriusHardware is offline  
Old 22nd Jul 2022, 5:18 pm   #107
coolsnaz2
Tetrode
 
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 86
Default Re: Yet another MK14 tape interface (ESP32).

Progress so far.

Still waiting for the IDT132SA100P to arrive from china (5 ordered, £12).

So connected Raspberry Pi 3 to EEPROM, which has a copy of MK14 OS installed. The MK14 OS can be seen in the left window in the photos.

I have used a 74LVC245 8-bit Level Shifter to connect output of EEPROM to Raspberry Pi, Pi is not 5v tolerant.

See attached photos showing both Character and Graphics modes.

Currently the output is via the HDMI port on the Pi, but the Pi could present the screen as a web page. It would also be good if you could interact with the MK14 from a web browser.

Not sure how many FPS, the Pi could produce yet.

Also thinking that a MK14-Pi graphics card could incorporate my fast load routine, so back on topic.

When I have a working MK14-Pi graphics card I will create a new thread.
Attached Thumbnails
Click image for larger version

Name:	20220722_164208.jpg
Views:	53
Size:	148.9 KB
ID:	261347   Click image for larger version

Name:	20220722_164436.jpg
Views:	53
Size:	130.0 KB
ID:	261348  
coolsnaz2 is offline  
Old 22nd Jul 2022, 11:07 pm   #108
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Yet another MK14 tape interface (ESP32).

Haha, that's absolutely brilliant! How did you go about importing the SOC VDU font into your Python script? You could possibly have lifted it from Karen's Ortonview source code but I suspect you probably did it some other way.

As you say the max framerate using interpreted Python with its regime of altering or reading one GIO pin at a time remains to be seen. If the FPS is not too good then you may be able to claw back some speed by programming the Pi in 'C', or even ARM assembly language.

Anyway, superb work so far.
SiriusHardware is offline  
Old 22nd Jul 2022, 11:31 pm   #109
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Yet another MK14 tape interface (ESP32).

Running along parallel, different lines, the Pi has loads of memory doesn't it, so how about making the Pi 'look' like ordinary RAM as far as the MK14 is concerned.

Let's say you've decided that the address range of the 'screen' RAM will be 0400-05FF, you could program the Pi to monitor the MK14 address bus and databus and the NRDS and NWDS lines, and whenever it detects a write to screen memory in the range 0400-05FF the Pi will read the data and place it in, say, the appropriate location in a 512-byte array from which the Pi program continually renders the output to its 'VDU'.

It also needs to work the other way, so if the MK14 attempts a read from addresses in the range 0400-05FF the Pi should fetch the data from the 512 byte array and offer it to the MK14. There will sometimes be a need for software to be able to read the content of a screen location as well as write to it, for example collision detection in games.

Needless to say the Pi would have to be running very, very fast for this to work, possibly a job for assembly language, but the advantage would be that it would do away with the need for a physical dual-port RAM, as the Pi would be using some of its own RAM as the screen RAM instead. You could help the Pi out a bit by still having a TTL address decoder to advise the Pi that there is about to be a write to or read from one of its pseudo-RAM addresses.

The MK14 wouldn't be slowed down either, as far as it knew it would be writing to and reading from ordinary RAM.
SiriusHardware is offline  
Old 23rd Jul 2022, 3:34 pm   #110
coolsnaz2
Tetrode
 
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 86
Default Re: Yet another MK14 tape interface (ESP32).

SiriusHardware

IDT132SA100P chips arrived today.

Yes I used Karen's Ortonview source code for the MK14 VDU font, I will have to give her credit in any final version. I originally imported Karen's font code into excel and produced characters using conditional formatting, and produced gif file for a single letter. This worked but I decided to try and create a font file, I used fontstruct to create the MK14.ttf file, see attached zip file.

Current frame rates, Characters 19 FPS and Graphics 8 FPS. My 'C' programming skills are very limited, but may worth investigating converting parts of the code to 'C', there may even be code available on the web.

It would be interesting to see if the Pi can monitor the bus address at 0B00 and OF00, to mirror the contents and display the contents. By initially keeping the Pi as a read only the original memory will deal with read requests for collision detection.

I am also interested to see if the LED display can be copied to the VDU output without any modifications to the MK14.

As mentioned above dual port RAM arrived today, it is going to take me a few weeks to evaluate chip.
Attached Thumbnails
Click image for larger version

Name:	20220723_141917.jpg
Views:	52
Size:	111.4 KB
ID:	261374   Click image for larger version

Name:	20220723_141948.jpg
Views:	44
Size:	102.9 KB
ID:	261375  
Attached Files
File Type: zip mk14 (8).zip (6.8 KB, 30 views)
coolsnaz2 is offline  
Old 28th Jul 2022, 5:26 pm   #111
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Yet another MK14 tape interface (ESP32).

Quote:
It would be interesting to see if the Pi can monitor the bus address at 0B00 and OF00, to mirror the contents and display the contents. By initially keeping the Pi as a read only the original memory will deal with read requests for collision detection.
Realistically, the 128 bytes of I/O memory left over on a standard machine when 0F00-0FFF and 0B00-0FFF are used as screen memory is just not enough to do anything worthwhile in.

For any practical purpose the VDU needs RAM which is over and beyond the 640 bytes onboard maximum that the MK14 supports - so yes, you can add that (as you have) by mapping more hardware memory into the memory hole at 0200-07FF and then mirror that to the VDU, but if you are going to connect a Pi anyway (to let it 'be' the VDU) then why not let the Pi 'be' the 1.5K of RAM as well? Then you only have to add a Pi + level shifters.

As said, this would require the Pi to be running many times faster than the MK14 and I think it would have to be coded in something low level, maybe even baremetal programming of the Pi (as per the RGB2HDMI project, which is why I referred you to that originally, to give you an idea of how that's done).

High speed hardware emulation applications certainly have already been written in baremetal Pi- in a MAGPi magazine issue that I have here there is an article where someone has made a Pi hardware-emulate all of the 'Tube' co-processors which were available for the BBC model B micro - as far as the BBC B is concerned, it looks and works exactly like the real hardware. When you bear in mind that the Pi in question is not only communicating with the BBC B in real time, it is also emulating whichever co-processor is meant to be connected, that is quite a feat and shows the degree of speed which can be achieved by working at low level on the Pi.
SiriusHardware is offline  
Old 28th Jul 2022, 10:03 pm   #112
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Yet another MK14 tape interface (ESP32).

Quote:
0F00-0FFF and 0B00-0FFF
Sigh. caught by the Edit-Timeout-Of-Doom again.
SiriusHardware is offline  
Old 29th Jul 2022, 5:05 pm   #113
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Yet another MK14 tape interface (ESP32).

In order to watch the bus I know that Victor Trucco who helped create the Spectrum Next based the original PI0 interface on his earlier HDMI adapter and used ARM assembler.

Someone who built one has a good blog here with links to the original ARM assembler source.

https://8bithardware.wixsite.com/web...-victor-trucco

Perhaps the newer PI0(2) is fast enough but, may need a kernel real time patch to ensure no dropped bytes which started showing up on the Next (even with the ARM code) most obviously as incorrect attribute colours that got worse as the clock frequency increased.
Timbucus is offline  
Old 1st Aug 2022, 9:33 pm   #114
coolsnaz2
Tetrode
 
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 86
Default Re: Yet another MK14 tape interface (ESP32).

Thanks for all your comments, but some of the things you are suggesting are beyond my capabilities.

Please see attached my version 1 of the MK14-PI VDU card, also attached is the Raspberry PI Terminal screen showing the MK14 memory at 0200.

As mentioned before I will create a new thread for this project.

I still need to do some testing with moving graphics, Fallman and Minefield and any others you can suggest. Currently using Raspberry Pi 3, I will check if it will run on Pi Zero.

Currently Character and Graphics modes have to be selected within the python code, and the memory address to be displayed is also in the Python code (between 0200 to 07FF).
Attached Thumbnails
Click image for larger version

Name:	20220801_134354.jpg
Views:	47
Size:	73.4 KB
ID:	261961   Click image for larger version

Name:	20220801_210416.jpg
Views:	50
Size:	140.2 KB
ID:	261962  
coolsnaz2 is offline  
Old 1st Aug 2022, 9:53 pm   #115
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Yet another MK14 tape interface (ESP32).

Another very neat build.

I think maybe we are already at the point where this needs to be a thread in its own right. With the help of the endlessly patient mods, we might be able to split this thread from the point where it veered into VDU territory to a new thread 'Pi based MK14 VDU' so we have the whole process in one thread, from your initial idea to eventual outcome.
SiriusHardware is offline  
Old 21st Jan 2023, 10:16 pm   #116
coolsnaz2
Tetrode
 
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 86
Default Re: Yet another MK14 tape interface (ESP32).

Update on my ESP32 MK14 tape interface.

The M5StackC has been replaced with a standard ESP32 device, see attached photo.

The code has been updated to present a web interface and to allow HEX files to be uploaded to the MK14 via the ESP32 web interface.

Currently the ESP32 needs to connect to my Wi-Fi network. The upload speed has been slightly reduced to enable uploads to be completed while the VDU is enabled, but Invaders can still be loaded in 5 seconds.

The ESP32 web server was originally developed by David Bird.
Attached Thumbnails
Click image for larger version

Name:	20230121_203817.jpg
Views:	35
Size:	73.8 KB
ID:	271960   Click image for larger version

Name:	20230121_205421.jpg
Views:	39
Size:	73.2 KB
ID:	271961   Click image for larger version

Name:	20230121_205431.jpg
Views:	39
Size:	77.7 KB
ID:	271962   Click image for larger version

Name:	20230104_201102.jpg
Views:	53
Size:	155.8 KB
ID:	271963  
coolsnaz2 is offline  
Old 21st Jan 2023, 10:22 pm   #117
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,362
Default Re: Yet another MK14 tape interface (ESP32).

Oh nice now that is very cool...
Timbucus is offline  
Old 21st Jan 2023, 10:35 pm   #118
Realtime
Hexode
 
Join Date: Jan 2021
Location: Ashford, Kent, UK
Posts: 318
Default Re: Yet another MK14 tape interface (ESP32).

Yes, Very cool. Looking forward to trying that. Just added 3K EPROM to my set up so the hex loader will be resident in that as soon as it’s available.
Realtime is online now  
Old 21st Jan 2023, 10:38 pm   #119
Realtime
Hexode
 
Join Date: Jan 2021
Location: Ashford, Kent, UK
Posts: 318
Default Re: Yet another MK14 tape interface (ESP32).

…and a triplet of MK14s. Wow.
Realtime is online now  
Old 21st Jan 2023, 11:04 pm   #120
Phil__G
Octode
 
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,084
Default Re: Yet another MK14 tape interface (ESP32).

Quote:
Originally Posted by Realtime View Post
…and a triplet of MK14s. Wow.
and all with 8154's
Phil__G is online now  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 10:53 pm.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.