PiTrex 2019-09-22 - Problems and Solutions: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ P1 (Problem 1): When running under Linux, the suspension of the PiTrex software process during the start of a draw operation can cause a delay before the detection of the Low-to-High transition of the RDY signal from the PiTrex board, which indicates that the write to begin Timer 1 count-down has been completed. This causes the write to be repeated for the duration of the delay introduced by Linux. During this time, #RAMP is asserted, but the counter can not decrement, so this delay has the effect of randomly extending the length of some lines, or beam positioning movements, being made. When using relative positioning ("optimise" enabled in the Vector Drawing Library), this also affects the positioning of lines drawn afterwards until the beam is zeroed. P2: When running under Linux, the suspension of the PiTrex software process during the end of a draw operation can cause a delay before the detection of the Timer 1 interrupt flag in the Interrupt Flag Register (IFR), or the IRQ signal if it is enabled in the Interrupt Enable Register (IER). This may cause the beam to be visible (#BLANK disasserted) for some time after it has stopped moving (#RAMP disasserted), resulting in a bright spot at the end of lines appearing randomly. Similarly, additional time might be added to the DELAY_T1_OFF delay which ensures that the beam is not turned off too soon, and this would have the same effect. P3: Text drawing does not work using the method of the Vectrex BIOS because this relies on the speed of code execution to time the return of the vector beam location at the end of lines. Other emulated machines may have the same problem if they use a similar method of raster text display. ------------------------------------------ P1&P2S1 (First Solution to Problem 1 and Problem 2): Don't use Linux, with the bare-metal environment there are no competing processes so the transition of the RDY signal is always detected soon enough that the problem doesn't occour, and the Timer 1 interrupts are detected immediately. P1&P2S1P1 (First Problem with Solution 1 to Problem 1 and Problem 2): Harder to adapt existing software (particularly MAME) for the bare metal environment, as well as to implement support for USB, non-FAT filesystems, and Bluetooth (eg. for external sound). Unlikely for a web interface using WiFi to be practical. P1&P2S2: Write pitrexio-gpio and at least part of the vector drawing library as a Linux kernel module so that it runs as a kernel process and hopefully can't have execution suspended by any other processes/interrupts, or at least not as often. P1&P2S2P1: Someone has to figure out how Linux really works in order to write this. P1&P2S3: Use a Real-Time Linux kernel and modify the pitrexio-gpio and vector drawing library code, or otherwise configure the system, to make sure that execution can't be suspended by another process while at crucial points where timing is important. P1&P2S3P1: Someone has to figure out how Real-Time Linux really works in order to write this. P1&P2S3P2: Most existing Linux distros can't be used directly because their kernels will have to be rebuilt with a real-time kernel. P1&P2S3P2S1: There is at least one Raspberry Pi Linux distro using the real-time patch that is updated regularly. P1S1: Modify the PiTrex Discrete hardware so that write operations are only performed for one cycle after being initiated by the Pi0. Use a capacitor to feed a Low pulse from IC1a's Q output to the #RST input of IC1a and IC1b. Ensure that it has enough capacitance to pull down the connection to LATCH EN from the Pi via R2 (10K) for the maximum duration before the Pi is expected to react to the transition of RDY and pull LATCH EN Low. Ensure that this action is disabled for Read operations through connection with IC3b Q output. Exact circuit not yet determined, and may not be workable due to voltage drop over diodes. Modification to be performed by soldering through-hole components between pins of IC1 on the existing PiTrex boards. P1S1P1: Lots of work to modify existing boards, and requires early redesign of PCB. P1S1P2: May introduce issues with component variation, and limit the ability to add/change other features later. P1S1P3: Haven't managed to get it working so far. Latest attempt appears to cause more glitches than before, and messes up vector positioning. Also requires a high-current Schottky diode which is a bit impractical. A larger capacitor might help, but at some point this will introduce other problems. Further work to be done with this. P1S2: Redesign the PiTrex Discrete hardware with better designed version of the P1S1 approach, using a flip-flop instead of the capacitor it initiate the latched Reset action after the first write cycle. Again disabled when R/#W is High. It would be far too difficult to modify existing boards for this, the PCB would need to be redesigned. The exact circuit details have also not yet been determined for this, and initial testing would require more work than P1S1 before beginning on the PCB redesign. P1S2P1: Means waste of already assembled boards and existing PCB design/testing. Lots more time required to get a new revision to the point we're at now. P1S2P2: Likely to add to the size/cost of the boards, though probably not all that significantly. P2S1: Redesign the PiTrex Discrete hardware with P1S1 or P1S2 and also include an extension to the IRQ Latch feature that delays the automatic write following the detection of the IRQ signal by 12 (or 15?) cycles. Would need a counter chip added to do this reliably, though if rough enough is good enough a capacitive delay might do. P2S2: Use the IRQ Latch feature of the PiTrex Discrete design to perform the write that asserts #BLANK automatically once the Timer 1 interrupt flag is set, without requiring interaction from the Pi0. P2S2P1: This prevents the DELAY_AFTER_T1_END_VALUE delay from being used, so #BLANK will be asserted some cycles before #RAMP is disasserted and the beam position stops moving. As a result vectors will be drawn short P2S2P1S1: Modify the vector drawing library so that: (1 the scale factor is increased by the same number as DELAY_AFTER_T1_END_VALUE in vectrexInterface.h for visible lines so that their visible length is again as intended. (2a The X-Y settings are inverted after each visible line and #RAMP asserted for DELAY_AFTER_T1_END_VALUE so that it returns to its intended end position. (2b The integrators are zeroed after every visible line is drawn, then the beam location is repositioned using a scale factor without DELAY_AFTER_T1_END_VALUE added, so that it is in the correct location when the next line is drawn back at (1. This is equivalent to the behaviour of the vector drawing library when optimisations are disabled. Use of the IRQ Latch feature for vector drawing is partially implemented as the IRQ_OPTIMISED_DRAW modification to the vector drawing library (see pitrex.03.cnk.WIP). This does not yet include fixes for the lines being drawn short. P2S2P1S1P1: The vector drawing library currently zeros the vector beam before beginning a line draw whith optimisations disabled, and during this zeroing operation it loops waiting for sufficient time to have elapsed that the beam is in the centre position. This wastes additional Pi0 cycles compared to optimised operation. P2S2P1S1P1S1: The vector drawing library is modified to use the vectrexinterrupt functions in pitrexio-gpio to break back into the game/emulator code between initialising and ending the zeroing operation. P2S2P1S1P1S1P1: Game/emulator code has to call the beam positioning, line drawing, and zeroing functions separately, and ensure that other code execution is performed while they are happening in order for the performance optimisation to be acheived from using IRQ Latch and vectrexinterrupt to handle timing instead of busy waits. P1S3: Use the non-optimised mode of the vector drawing library so that glitches caused by Linux are much less visible because they don't affect any of the vectors drawn after them. P1S3P1: The IRQ_OPTIMISED_DRAW modification to the vector drawing library (see pitrex.03.cnk.WIP) can be used to enhance performance by allowing game/emulator code execution during a vector draw operation. This may make up for the performance penalty from having the Pi0 wait for zeroing to complete, not required as often when using relative positioning. Required for P2S2 anyway. P1S3P2: Harms performance as per P2S2P1. P1S3P2S1: See P2S2P1S1. P3S1: Use Malban's alternative method of vector drawing which does not require accurate timing of code execution. Already implemented in the vector drawing library. P3S1P1: The text drawing routines in the vector drawing library have to be called from emulators. These are designed to represent such features using normal vector plotting functions, equivalent to the outputs given to the DAC for the original vector display used by the emulated games. The text data being drawn is not normally available directly. P3S1P1S2: Identify the subroutine in the original ROMs where the text is plotted on the display and modify the emulator to skip the original routine, while passing the text data on to the text drawing function in the vector drawing library. P3S2: Modify the vector drawing routines in the original ROM image of games in order to have them use Malban's text drawing method natively. This is only likely to be practical with the Vectrex BIOS, where the instructions required for controlling the DAC are already known, and a commented disassembly of the ROM is available. Even then it will be difficult, and may introduce other bugs. P3S3: Ensure cycle-exact timed execution of the original emulated code, including delays introduced by the vector drawing library and PiTrex I/O code. P3S3P1: Not possible under Linux. P3S3P2: Requires exact planning of the interaction between the emulator and the vector drawing library. P3S3P3: Requires accurate synchronisation with the Vectrex clock. P3S3P3S1: This can be acheived most easily with the RDY signal, which is 1/2 the Vectrex clock frequency when LATCH EN is High. Alternatively, one of the Vectrex timer interrupt flags can be monitored at the IRQ input if it is enabled in the IER. ------------------------- Programmable Logic PiTrex ------------------------- P1S4: A solution for the programmable logic design equivalent to P1S2 could be implemented in the programmable logic IC without need for additional hardware. P2S3: A solution for the programmable logic design equivalent to P2S2 could be implemented in the programmable logic IC, but with the DELAY_AFTER_T1_END_VALUE delay added between the detection of the Timer 1 interrupt and the automatic write to assert #BLANK, so that the visible line ends where the beam stops moving. This avoids P2S2P1. P3S4: If the writes to the VIA from the text display routine are buffered, _maybe_ the drawing sequence could be handled by the programmable logic IC in sync with the Vectrex clock. P3S4P1: Needs additional co-ordination with the vector drawing library code so that it will fill the buffer and then wait for the text drawing operation to be complete before beginning another vector draw operation. This will also require emulator execution to be paused, at least after it begins a following operation requiring interaction with the Vectrex. Conclusions: ---------------- PiTrex Discrete: ---------------- With Linux: Software fix for P1&P2: P1&P2S2 + P1&P2S3 + P1S3 + P2S2 Hardware fix for P1&P2: P1S1 or P1S2 + P2S1 Software fix for P3: P3S1 or P3S2 Without Linux: P1&P2 solved as per P1&P2S1 P3 solved by: P3S1 or P3S2 or P3S3. Decision may depend on how many (or any) arcade machines affected. -------------------------- Programmable Logic PiTrex: -------------------------- With Linux: Software Fix for P1&P2: P1&P2S2 + P1&P2S3 + P1S3 + P2S2 (assuming equivalent hardware features to existing PiTrex Discrete design) Hardware fix for P1&P2: P1S4 + P2S3 Software fix for P3: P3S1 or P3S2 Software + Hardware fix for P3: P3S4 Without Linux: P1&P2 solved as per P1&P2S1 P3 solved by: P3S1 or P3S2 or P3S3 or P3S4