2nd Jul 2022, 9:05 am | #101 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,587
|
Re: Yet another MK14 tape interface (ESP32).
Quote:
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. |
|
2nd Jul 2022, 1:55 pm | #102 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
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 Code:
:100F2000C40235C40031C400C80EC00DCD01B808DC :090F30009CF8A8059CEA3F0000B2 :02FFFE000F20D2 :00000001FF |
9th Jul 2022, 8:27 pm | #103 |
Tetrode
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 87
|
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. |
9th Jul 2022, 10:47 pm | #104 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,587
|
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. |
10th Jul 2022, 9:31 pm | #105 |
Tetrode
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 87
|
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? |
10th Jul 2022, 11:51 pm | #106 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,587
|
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. |
22nd Jul 2022, 5:18 pm | #107 |
Tetrode
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 87
|
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. |
22nd Jul 2022, 11:07 pm | #108 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,587
|
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. |
22nd Jul 2022, 11:31 pm | #109 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,587
|
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. |
23rd Jul 2022, 3:34 pm | #110 |
Tetrode
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 87
|
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. |
28th Jul 2022, 5:26 pm | #111 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,587
|
Re: Yet another MK14 tape interface (ESP32).
Quote:
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. |
|
28th Jul 2022, 10:03 pm | #112 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,587
|
Re: Yet another MK14 tape interface (ESP32).
Quote:
|
|
29th Jul 2022, 5:05 pm | #113 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
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. |
1st Aug 2022, 9:33 pm | #114 |
Tetrode
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 87
|
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). |
1st Aug 2022, 9:53 pm | #115 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,587
|
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. |
21st Jan 2023, 10:16 pm | #116 |
Tetrode
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 87
|
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. |
21st Jan 2023, 10:22 pm | #117 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
Re: Yet another MK14 tape interface (ESP32).
Oh nice now that is very cool...
|
21st Jan 2023, 10:35 pm | #118 |
Hexode
Join Date: Jan 2021
Location: Ashford, Kent, UK
Posts: 318
|
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.
|
21st Jan 2023, 10:38 pm | #119 |
Hexode
Join Date: Jan 2021
Location: Ashford, Kent, UK
Posts: 318
|
Re: Yet another MK14 tape interface (ESP32).
…and a triplet of MK14s. Wow.
|
21st Jan 2023, 11:04 pm | #120 |
Octode
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,119
|
Re: Yet another MK14 tape interface (ESP32).
|