Bug Report

Expected Behavior

When attaching the USB to Windows 10, the VEXTREME MSC(Mass Storage Controller) should mount a couple seconds and show up in Explorer.

Observed Behavior

When attaching the USB to Windows 10, the VEXTREME MSC(Mass Storage Controller) does not mount for several minutes.

The USB MSC driver does load in a few seconds, but then nothing happens on the device for several more minutes.

Steps to Reproduce

• Remove the 2 pin jumper
• Make sure it's not powered already by the Vectrex
• Plug it into the USB port of a Windows 10 computer

Failed attempts to resolve the issue

• I tried reformatting as FAT and recopying the games from Windows, and that took the expected time. Copying and deleting single files is blazing fast for a cheap 16MB SPI flash chip.
• Uninstalling various drivers like USB MSC, Host Controller, etc.. and restarting the computer
• Running DriveCleanup 1.6.0 with VEXTREME removed, restart, etc..
• Disabling AutoPlay (physically turning it off completely in settings)

References

• As a point to note, it seems tons of people have this issue on Windows

Feature/Enhancement Request

one thing I'd be interested in seeing is emulation of the Maxim DS243x
1-wire eeprom used on various games to store high scores and
settings/options. The device is controlled through cart pin 35 (port B
bit 6 from PIA) code examples from Alex Herbert/Malban can be found in
the "include" file ds2431LowLevel.i that is in VIDE and other stuff.
The datasheet for the device describes way more functionality than
you'd need to implement the simple read/write that Vec games use.

https://datasheets.maximintegrated.com/en/ds/DS2431.pdf

thanks

Bug Report

Expected Behavior

It should just play normally

Observed Behavior

Polar Rescue crashes when the sub launches

Steps to Reproduce

Load up Polar Rescue with v0.2 and launch your sub... black screen.

Feature/Bug Fix

This is pretty straight forward and already has been compiled by @technobly and @rattboi, but there is an issue where the frame rate is slow and not consistent either. Also some lines appear to be out of place where they should be.

Should be smooth like this: https://www.youtube.com/watch?v=VuVnoqFF3II

Bug Report

Expected Behavior

A quick tap of reset will reset the current game.
A longer press of reset will reset to the VEXTREME menu.

Observed Behavior

The no-buzz Vectrex (UK models 31xxxxx and higher) seem to have a minimum 300ms reset pulse. The reset timer in v0.21 was approx 300ms, and it's not possible to reset the current game with a no-buzz Vectrex.

Steps to Reproduce

See above

References

See this FB thread: https://www.facebook.com/groups/vectrex/permalink/1262033124007062/?comment_id=1264366317107076

I'm currently using my Vextreme (btw, extremely happy with it!) without any casing and the only thing, which kind of annoys me, are the really bright leds facing upwards.

It would be a cool feature, to be able to reduce the led brightness, or turn it off completely!

Alternatively have a DIP switch on the pcb or another firmware, to turn them off?

Would like to be able to write code that runs on the STM32 and sends vector drawing commands to code running in RAM on the Vectrex's 6809, in order to have a mechanism to add new games, whether written from scratch in C or static binary translations of arcade games into C. Requires a new format of file to be recognised, a 6809 bootstrap to move code into Ram, and some drawing support code on both sides. It is not necessary to emulate memory while such a program is running, but there has to be a mechanism for resuming the memory emulation on exit from the STM-hosted code.

Hey technobly!

I recently sent you this issue via your e-mail, but since I think that you don't check it that often, I'll repost it here 😉 I hope that's ok!

Anyways, I'm having the following issue (from my e-mail):

I got my hands on a vextreme a few days ago, and now I've ran into an issue, that I have no idea how to fix...
I built and installed the firmware correctly, set up the menu successfully, after I had formatted the drive in windows with the correct settings. Everything seems to work just fine and I am also able to copy files onto the device.
However, i can't get anything other than the menu to work. I tried a lot of times in different ways, but the directory "roms" or any other never shows up in the menu. If I then press button 4 on the controller, the vectrex just crashes and if i reset the device, it goes to a buggy version of mine storm. What am I doing wrong? Could it be a fault on the pcb?

P.S. I had the cart plugged in the wrong way at first and the vectrex didn't boot at all, but after i flipped it everything worked fine (I hope that didn't do anything!) I also tried reformatting and cleaning the drive, creating a new partition and even reflashed the firmware, but to no avail. I'll put a video of me showing this problem as an attachment to this. Btw, I should also say, that I'm rocking a European Vectrex.

I hope that is something, that is easy to fix!

Since I'm not ably to upload mp4s here, I'm uploading it inside a zip-file.

issue.zip

Thanks in advance! 😄

Feature

Currently the addressable LEDs are bit-banged with software SPI. Ideally we'd like to support HW SPI2 so that we can do fancy things like DMA control of the LEDs. To enable that, we'll likely have to shuffle some pins around.

Notes:

• Move V-HALT and V-CE to different pins and fix SDAT and SCLK so they are on SPI2 for hardware control.
• V-CE might be optimized for MSB (seems like it is in romemu.S), so move to PA15 which bumps CSn to some other pin?
• CSn should likely be on SPI1_SS, but it might not matter (check). PB01 is used in an optimized way as well though.

Bug Report

Expected Behavior

For the most part, but totally silent.

Observed Behavior

The LEDs on VEXTREME v0.2 tend to oscillate/modulate at evil frequencies 666hz when the brightness is limited based on the color value 0x0 ~ 0xFF for each R,G,B. When it's not 0xFF, you'll hear this extra buzz.

If you have a no-buzz Vectrex, it will be more obvious. You can't have all 10 LEDs on at full brightness. It's too much current for the Vectrex.

Hardware filtering seems like an obvious solution, but it turns out that software is a better one.

Steps to Reproduce

Use a v0.2 VEXTREME to run the Test Cart rev.4 and set it to Deflection test. When the vectors turn off, you'll notice that there is this evil buzzing of bees.

Bug Report

Expected Behavior

Components should not be in the way of the enclosure bosses

Observed Behavior

• 5 pin debugging header pins are in the way (you can flush cut these pins as a workaround)
• D4 LED is in the way, but really it's so thin it doesn't matter much.

References

Feature

Add 128KB bankswitching (V-INT pin) support. We have the pin hooked up already, but need to implement the bankswitching firmware. Might require the STM32F412 or STM32F405 though. This is primarily for Malban's Vectorblade game.

Add design notes below please!

Enhancement

• Ignore all files for menu generation that are not .bin or .vec
• This allows things like README.txt files to be added to provide instructions or other notes
• Could simplify menu generation possibly by parsing the files once, and not iterating through several times.

Feature

Developer mode, allow the cart to stay plugged into a computer and appear as a RAMDISK

Here's an idea of how this might work:

1. Vectrex -> press 2 + 3 at any time
2. Vectrex -> call new rpc command to tell stm32 it's in dev mode
3. STM32 -> enter ramdisk mode (which could just be the same as usual, it's fast enough.. or later maybe use RAM for insta speeds)
4. STM32 -> write to SETTINGS struct indicating USB DEV WAIT mode is active (maybe SETTINGS will be saved in NVM at some point, but not necessary right now since USB will have power plugged in)
5. STM32 -> watch for new file w/ special name
6. STM32 -> figure out "done" (writes start and complete for filename called cart.bin)
7. STM32 -> write to SETTINGS struct indicating USB DEV RUN mode is active
   8a) STM32 -> reenter romemu booting up multicart.bin
   8b) Vectrex -> running multicart.bin read SETTINGS struct to know if we are in mode USB DEV: WAIT, RUN or DISABLED. If WAIT, jump to 2. If RUN, proceed to 9. If DISABLED jump to 11.
8. Vectrex -> read buttons first to know if we should exit USB DEV mode. If we see 2 + 3 held, set USB DEV DISABLED in SETTINGS, bail out and busy wait for them to be released so we don't re-enter USB DEV mode immediately.
9. Vectrex -> if no buttons held and USB DEV == RUN, set USB DEV == WAIT and call rpc command to load cart.bin
10. Vectrex -> otherwise if disabled just run the menu as usual.
11. STM32 -> if reset, jump back to 8 as usual and it should see USB DEV == WAIT getting us back to USB DEV mode.

[EDIT: ... it's way more complicated than this... and I dread updating this flowchart!]

Other considerations:

1. Messages on screen should not reach full brightness, and should move around in a screensaver like fashion to wear the screen evenly

Enhancement

Currently U3 is a quad 74HC32 with only one gate being used. This was chosen originally to keep the design choices Sprite_tm made for v0.1. It's a bit cheaper and requires less space to add a single gate version of this. Keep the package a reasonable size for hand assembly.

https://lcsc.com/product-detail/Gates-and-Inverters_Texas-Instruments_SN74LVC1G32DBVR_Texas-Instruments-Texas-Instruments-SN74LVC1G32DBVR_C10096.html

We'd like to have a way to save high scores for each game, in an easy to maintain sort of way. There are hooks for high score RAM location in the Vectrex BIOS that we can look at to see what the current high score is.

One way to attack this is to patch each game with the high score manager code, such that when the high score gets updated, the manager runs instead and allows for more custom things to be done. This is kind of tedious to maintain though, and is anyone really going to trust high scores from an Open Source Vectrex Multicart? :D haha...

So how about we make this simpler and just give the owner of the cart a nice simple way to store the High Scores like this:

• Enable the High Score feature in the Options menu
• Play whatever game you want
• Assuming the high score has updated, press reset quickly (long reset returns to VEXTREME menu)
• VEXTREME swaps the game with the High Score save interface, and associates your score with the game in a SAVES.txt file. Honor system here people!!
• There should also be a way to view High Scores for all games, within the interface... which could also be pulled up from the Options menu.

There are some games with the same title (like all FURY UNLIMITED games). These games all save/load under the same game name ("F U R Y" in this case).

Luch's Soft games come to mind as well although I'm not sure if it uses the standard score location. "LUCHS SOFT PRESENTS:"

There may be more games. Different versions of the same game could have this issue as well (alphas/betas/final release/etc) if anyone cares. (Rockaroids/Rockaroids Remix)

Is your enhancement request related to a problem? Please describe.
As a User I would like it to be clearer that there are further items/folders/files on subsequent pages so that I do not think the 4 items I can see are all that is there.

Describe the solution you'd like
A visual indicator that moving left or right will select subsequent pages of files. This could be an extra arrow or the ( < ) and ( > ) symbols could be lower intensity when not selectable and higher when they are.

Describe alternatives you've considered
Displaying more folders/files on a single screen
Having one page that scrolls down to see everything in that Folder/Area
Removing the VEXTREME text in vectors to allow for more test to be displayed.

Additional context
Add any other context or screenshots about the feature request here.

Bug Report

Expected Behavior

There should be no soldermask ink/LPI surrounding the PCB fingers

Observed Behavior

There is soldermask around the fingers, and when it's really thick it causes the contacts in the Vectrex connector to float above the PCB finger ever so slightly. Games glitch out at different times due to addressing issues or bad data.

References

Here's a great list of Vectrex carts that also have this issue (notice the original GCE carts pictured here DON'T have this issue but do have hard gold fingers as well...): http://vide.malban.de/collection-2/the-beauty-in-pcbs

See the issue and resolution here for v0.2: https://www.youtube.com/watch?v=sS-BKoMr4OM
The tool used in the video above is an exacto knife with the tip broken off on purpose :D

If you bought a VEXTREME from Game-Tech.us, it is a v0.2 with the soldermask problem (PLEASE READ)

Is your game glitching out at random times, or only Mine Storm showing up? Your problem is almost 100% because of the soldermask that surrounds the fingers on the cart. This is why I painstakingly removed it from all v0.2 VEXTREME's that I sold for $40 USD. Jason GameTechUS knows this is a problem and sold them to you without removing the soldermask, because they might have worked in his Vectrex... I don't know his testing process... but YMMV with different connectors and varying degrees of soldermask thickness. Not trying to throw anybody under a bus here... just real talk. I don't want VEXTREME (all caps btw) to get a bad name because a pre-production version not ready for the masses was sold in high numbers. Good luck all you new owners of open source hardware, I do hope you get to enjoy VEXTREME as I intended in creating this project. I hope Jason GameTechUS stands by his sale and helps you find a solution here.

Here's a way to test if it's the fingers causing an issue: take the cart out of the shell... plug it in, play a game, and gently and slowly wiggle the cart up and down and maybe even pull it 0.5 mm in and out of the cart slot. If the game glitches out on you... soldermask is likely the issue. Try this same procedure with any production Vectrex game, and you'll see it won't glitch out... and you can also see what the limits of pulling it in and out are.

You can also try that same procedure with the game in the shell, but it won't go up and down as easily. More so in and out, and it will be worse in the case because the case holds the PCB perpendicular to the cart edge connector, so all of the fingers of the Vectrex's connector tend to float on top of the soldermask at the leading edge of the PCB.

Is your feature request related to a problem? Please describe.

There's no way to see what version of software is running on the vextreme

Describe the solution you'd like

Should be able to see the software version in the multi menu

Describe alternatives you've considered

You could just not know, I guess...

Additional context
(na)

I'm not sure if this is really a bug report or an enhancement request;

Suggestion: use arm cycle count register for accurate short timings rather than timing loops which may be cache dependent.

mov   r6,#10                // <- Oscillator frequency dependent magic number here!!
waitdataloop:
subs  r6,#1
bne   waitdataloop

3.4.28. c15, Cycle Counter Register (CCNT)
The Cycle Counter Register counts the processor clock cycles. It is a 32-bit counter that can trigger an interrupt on overflow. You can use it in conjunction with the Performance Monitor Control Register and the two Counter Registers to provide a variety of useful metrics that enable you to optimize system performance.

You can access the Cycle Counter Register by reading or writing CP15 c15 with the Opcode_2 field set to 1:

MRC p15, 0, , c15, c12, 1 ; Read Cycle Counter Register
MCR p15, 0, , c15, c12, 1 ; Write Cycle Counter Register
The value in the Cycle Counter Register is Unpredictable at Reset. The counter can be set to zero by the Performance Monitor Control Register.

The Cycle Counter Register can be configured to count every 64th clock cycle by the Performance Monitor Control Register.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/BIHCGFCF.html

The BOM (veccart.csv) lists C13 as 47uF but the Digikey shared cart has C13 listed as a 0.047uF. Can you please confirm which is correct?

UPDATE, I can see the schematics say 47uF.

Enhancement

Add some nicely labeled test points for power rails:
+5V
+3.3V
Vectrex VCC
USB VUSB
GND

Enhancement

For proper mating of the PCB to Vectrex when PCB is installed in a reproduction Vectrex cartridge enclosure, the PCB fingers should be 18.0mm from the center of the 3.52mm mounting hole and 1.2mm from the PCB edge.

This 1.2mm distance just also happens to be a requirement for hard gold PCB finger 45° edge beveling: https://jlcpcb.com/quote/pcbOrderFaq/Gold%20Fingers

See Berzerk cart measurements:

Mounting holes should also all be 0.2mm larger than the posts (currently they are 0.1mm larger and it's perfect... but too perfect of a fit)

POST - HOLE

5.0 -> 5.2
4.0 -> 4.2
3.5 -> 3.7

Feature

Add cartridge RAM support (specifically for Animaction $2000-$27FF, but possibly for others as well).

Any downside to letting the entire 32K/64KB of emulated ROM to be considered as RAM and writable?

Enhancement

Currently the reset mechanism works like this:

• reset a counter when ROM emulation starts (menu is loaded of a game is requested to be loaded)
• increment a counter every time the cartridge is read from
• when you see the copyright symbol address 0x0004 being read, check if that counter is above a certain value
• if so, assume the game has been reset and the cart header is being read again and take action to bring the menu back up
• if not, just keep on reading and incrementing the counter

New Reset Heuristic

• We need a better heuristic for determining when the Vectrex has been reset.
• Games like Polar Rescue have bugs that end up causing the copyright header addresses to be read during the game causing false tripping
• Also this current time based + address detection heuristic is not that reliable... for example if a game had a really long intro music tune it would cause false tripping (I don't actually understand why long intro music causes the reset timer to show as expired, because the header is read before the music starts playing, but that is the observed result)

References

• #22
• Use open source tools to help figure this out. Two of these 16 channel logic analyzers: https://sigrok.org/wiki/Lcsoft_Mini_Board
• Can be read from at the same time and potentially have their captures stitched together to form a 32ch analyzer: https://sigrok.org/bugzilla/show_bug.cgi?id=1249

This is a suggestion to enhance the Vextreme for use as a program development/debugging aid.

The Vextreme could be used as a substitute for an expensive logic analyzer/data logger, by recording the program execution path and accesses to rom data, by having the Vextreme keep a cyclic buffer of the addresses that were fetched from, during program execution.

I'm assuming the hardware is not fast enough to log directly to flash on the fly, which is why I suggest the use of a cyclic buffer. If it were, that would be a preferable option as the size of the log could be much greater. Saving a rom access record using a cyclic buffer would look something like: Buff[Ptr] = fetch_addr; ptr = (ptr + 1) & buffsizemask; which should be low enough overhead that it can be done on every fetch.

Depending on RAM available it would also be useful to store an accurate timestamp by using the ARM internal cycle counter. If using a timestamp there would be no need for separate put/get pointers.

It would also be necessary to store the bank ID if the rom being emulated were bank-switched, which would need an extra byte per saved fetch record.

The utility of this would depend on how much free internal RAM is in the SOC, but even something as low as 30K 16-bit words ought to be enough to record all behaviour during a single vectrex drawing cycle.

Some mechanism would be necessary to trigger the Vextreme to save the cyclic buffer to permanent storage. Possible trigger mechanisms might include: 1) external signal to gpio pin 2) external signal via edge connector bus (eg nmi) 3) RPC call from 6809 4) trap on any access to a specific address 5) trap on any attempt to write to rom address space.

If the vextreme has sufficient memory available it would also be possible to implement an array which is the same size as the emulated rom memory, containing flags that could be used to trigger actions - eg trigger an action on read from any marked address, or have write protection at a byte address level in a writable cartridge, or trigger a 6809 interrupt on access to specific byte addresses.

The data logging of the execution path history would be extremely valuable to Vectrex developers because there is currently no other mechanism for tracing program execution that does not also interfere with that execution, whereas this would be like an external logic analyzer sniffing the bus and would not be visible from the 6809.

Feature

• Route all unused GPIO to a breakout header, for hacking!
• Might want to wait to do this until after the HW changes settle down

The serial port on VEXTREME is a HW UART already on the STM32F4, running at 115200 baud. It should be capable of being hooked up to DMA. The idea here is that you'd map it to portion of memory that gets filled with vector lists via USB Serial or HW Serial to start, and the STM32 would drive the VIA directly with that list of vectors.

It would be cool to implement a simple POC that could move a ball around the screen or something like that via UART commands just to get an idea of how much overhead in CPU and UART timings we have before moving onto the full blown MAME Terminal support.

Enhancement

USB-C D+/D-/CC1/CC2 connections need an ESD protection device added.

Tiny, but has 4 devices in one package
https://lcsc.com/product-detail/Diodes-ESD_Texas-Instruments_TPD4E05U06DQAR_Texas-Instruments-Texas-Instruments-TPD4E05U06DQAR_C138714.html

Dual device
https://www.ti.com/product/ESD122

Dual device, larger easily hand solderable (SOT-23-5)
https://lcsc.com/product-detail/Diodes-ESD_NXP_PESD3V3S2UT-215_PESD3V3S2UT-215_C84276.html

Enhancement

• Debugging header: Reduce 5 pin header to 3 pin header to reduce size?
• Debugging header: make it right-angle SMT?
• Programming header: Make 2-pin jumper a right angle switch instead of a jumper?

Feature

• Implement RPC Function for addressable LED control
• Create a led-test Vectrex app to show how to control the LEDs

Enhancement

Add hardware version support for pin definitions. This will help with maintaining compatibility between versions of firmware, i.e. future firmware can be built for older hardware more easily.

Bug Report

The components are in the correct place here:

Just the R4 and D3 reference designators need to be swapped.

So if you build v0.2 unmodified, make sure your components look like the picture.

Enhancement

Not much more to say other than 7mm spacing between all 7 LEDs is some kind of jackpot I think! 🎉 💰

UPDATE: After more testing, 4 LEDs can but turned up to full brightness instead of using 7 LEDs. Less cost, and same amount of light. Yeah we have less resolution for cool light shows, but... from what I can tell everyone want to cover up the LEDs with a cart of some sort anyway.

A the top level, with 3 items showing on the menu, move down so that the second or third item is highlighted. Then use the joystick to go right, to the last set of items at that level. If there is only one item on that final page, and you have not moved back up within the page, you can click to start the game thinking that the item is selected, when in fact it is an empty slot that is selected and starting it crashes the vectrex.

Bug Report

The addressable LEDs don't like to sit flat when reflowing because the pads in the 4 corners are larger than the center pads. Make all of the pads the same size, so the part snaps into place and doesn't require any touch up work or extra fiddling.

As a reminder:

Please connect Vectrex A15 to PC15 of the STM instead of PB6.
PB6 can be handled somewhere else...

As it is now, one can NOT write to VIA (or RAM) directly from the STM, and thus the programmable "HALT" makes pretty much no sense IMHO.

Enhancement/Bug

• Replacement for U4 (SN74LVC8T245DB) which is more generally available (at LCSC)
• I had tried this part SN74LVC4245A but despite it having the same pinout it doesn't work, the Vectrex ends up not being able to read anything.

A serial port connected to a terminal emulator on a PC is handy for debugging and allows interactive environments like Forth or BASIC to run.

I'd like a serial port to run something similar to my serial port handler that works on a VecFever (code below is in Forth):

HEX

\ VecFever UART serial port interface. VecFever provides buffering (256 bytes each way?)
7FFB EQU v4eTxStatReg \ Read, negative if transmit buffer is in use, positive otherwise
7FFB EQU v4eTxByteReg \ Write
7FFC EQU v4eRxStatReg \ Read, zero if no data received, otherwise != 0
7FFD EQU v4eRxByteReg \ Read, upon reading, 7FFC is automatically cleared
7FFE EQU v4eLEDReg \ LED Register, probably read/write?

CODE KEY? \ -- f return true if char waiting
6 # ( D) PSHS, CLRA, v4eRxStatReg LDB,
NE IF, -1 # LDB, THEN, NEXT ;C

CODE KEY \ -- c get char from serial port
6 # ( D) PSHS, BEGIN, v4eRxStatReg LDB, NE UNTIL,
v4eRxByteReg LDB, CLRA, NEXT ;C

CODE EMIT \ c -- output character to serial port
BEGIN, v4eTxStatReg LDA, MI UNTIL,
v4eTxByteReg STB, 6 # ( D) PULS, NEXT ;C

Describe alternatives you've considered
Other alternatives are available, but a VEXTREME is cheaper than the other alternatives and/or potentially provides a lot more functionally.

Bug Report

Everything except Monty on the Run and Robocop crash the Vextreme requiring reset.
The two songs that don't crash play the incorrect music and display the incorrect image.

Expected Behaviour

All songs play the correct music and display the correct image when selected

Observed Behaviour

Screen goes blank when most songs selected.
Monty and Robocop do not crash but play the incorrect tune

Steps to Reproduce

Vextreme 0.2

References

Links to a video, or more info

Bug Report

Expected Behavior

• Truncate filenames displayed to 16 characters
• Handle long filenames that don't exceed a 255 character path name without a problem
• Filenames that are in a path too long won't be displayed

Observed Behavior

• The menu tries to print more than 19 characters off the edge of the screen
• Menu repeats filenames when it finds a filename of 27 characters of more even if they are in a path less than 255
• Long filename paths probably bug out...

Steps to Reproduce

• Make some long filenames and paths and test

After leaving my vectrex powered up all day it occurred to me that the bright "VEXTREME" at the top of the screen might lead to burn in, in the long term. Perhaps after a period of inactivity, the default screen could fade out everything except the word VEXTREME, and have it bounce across the screen in a path that eventually covers all positions. Original screen to be restored on any joystick/button activity.