|
|
Post by Malban on Feb 13, 2020 17:51:54 GMT -5
Hi,
I realized that the few updates I have made "public" were either on facebook - or on YouTube. I'd just like to point out, that PiTrex is still alive, and I am documenting my own personal progress on my pages.
Here you find a link to the PiTrex Wiki by Kevin - which he also updates quite regular.
I also did a couple of diary entries, latest of which from today, also accessable from the above page.
I will not go into current "details" here in the post - but if interested in our (my) doings - feel free to visit the above page.
Cheers
Malban
|
|
|
|
Post by big10p on Feb 16, 2020 17:32:17 GMT -5
Wow, this sounds very exciting! I'm a new vectrex owner and a retro arcade game enthusiast, so to be able to play Asteroids etc. on the Vectrex would be amazing. Not to mention new games written for it! Been reading about people raving about the VecFever, which seems impossible or stupidly expensive to obtain, so I've given up on ever getting one.
Just watched a vid of your game VectorBlade, which looks great, too. Talented guy! Keep up the good work, and let us know when we can get our hands on a PiTrex. Can't wait!
|
|
|
|
Post by kokovec on Feb 20, 2020 13:07:17 GMT -5
Indeed, this is cool.
I wonder if adding Vectrex hardware control extensions to MAME would be worth exploring.
|
|
|
|
Post by Computer Nerd Kev on Feb 21, 2020 1:25:14 GMT -5
Indeed, this is cool. I wonder if adding Vectrex hardware control extensions to MAME would be worth exploring. It has been explored, though probably won't be realised until sometime later down the track. Technical details about porting MAME and other software this are on the PiTrex Wiki. |
|
|
|
Post by kokovec on Feb 21, 2020 12:40:11 GMT -5
After quickly reading through the wiki it seems that it would be best to roll a bare metal solution from scratch and provide a C SDK to game developers.
Leave timing to the kernel. Something like Pebble did for watch app developers.
|
|
|
|
Post by Computer Nerd Kev on Feb 24, 2020 1:20:17 GMT -5
After quickly reading through the wiki it seems that it would be best to roll a bare metal solution from scratch and provide a C SDK to game developers. Leave timing to the kernel. Something like Pebble did for watch app developers. Yes most of the recent work has been with bare-metal (no OS kernel, just running the game code directly), and Malban has put together a nice environment for working with that based on various other Raspberry Pi bare-metal projects. But with Linux you also get the wide range of drivers for things like Bluetooth devices and wireless networking (onboard features with the Raspberry Pi Zero W), which would be more difficult to integrate with bare-metal. It also means that a lot of the Linux software described on the Software_Ports page of the Wiki can be ported much more easily than if all of the OS-dependent features had to be replaced for bare-metal. MAME is one example where the complexity of the code has hindered us porting it to the bare-metal environment, though the Static Binary Translation method of emulating arcade games has its own advantages anyway. I've taken on the task of looking deeply into whether a Linux driver would be practical, which would require some modification to the existing routines for interfacing with the Vectrex. I'll start on that after I finish a system for translating Xlib-based Linux vector games for the PiTrex. Either way the bare-metal environment will probably be the suggested target for most developers writing new games for the PiTrex rather than porting existing Linux software. |
|
|
|
Post by kokovec on Feb 24, 2020 23:32:07 GMT -5
I suppose it would be nice to be able to run on top of an established and supported Linux port.
In my experience a multitasking OS makes for very sloppy timing. Especially when compared to an embedded solution.
Is there a decent RTOS for the Pi?
|
|
|
|
Post by D-Type on Feb 25, 2020 2:32:35 GMT -5
There are various Forths that run native on the RPi. ciForth I think has a native port, the low level primatives are written in C for portability. MPE VFX is a commercial Forth that is free for community non commercial use, it is fully featured with tcp/ip stack, usb etc. and has a Sockpuppet interface to C. www.mpeforth.com/software/forth-cross-compilers/forth-7-cross-compilers/github.com/rbsexton/sockpuppet/Many people in the Forth community use Gforth, but that's running on Linux. You could 'easily' write a downloader in Forth for compiled code, just like Atari did back in the day. Has anyone considered XPL0? I heard there is a RPi port. It's a sort of cross between C and Pascal - looks very cool. www.xpl0.org/rpi/index.html |
|
|
|
Post by Computer Nerd Kev on Feb 25, 2020 7:09:33 GMT -5
My hope is that the Linux kernel can respond to hardware interrupts (triggered by outputs from the PiTrex board) and call handlers from within a PiTrex kernel module fast and consistently enough that a Real-Time OS isn't required, but this is something that I'll just have to try and see. Alternatively there are various real-time patches for the Linux kernel. There is a distro available for the Pi with the popular PREEMPT_RT patch applied: guysoft.wordpress.com/2017/10/09/realtimepi/I haven't looked much into that, but hopefully it can provide a fall-back if a standard kernel module in Linux doesn't provide good enough performance. Or maybe if modifying our existing code to use interrupts doesn't work out. @d-Type: Supporting other programming languages is definately something we want to look at down the track, but everything is very much based in C for the moment. |
|
