Raspberry pi

[Opry99er]

Here's something for ya!~

 

 

[Opry99er]

 

 

It's almost a shame to see this... but VERY cool at the same time. =)

[matthew180]

So my idea was to build a modern development platform using a real F18A with the rest of the TI emulated.

<snip>

The thing I don't have any clue about is what it would take to connect the F18A to the Raspberry Pi GPIO.

 

That's a cool idea!

 

You can write F18A GPU code on an emulator and compile it with any 9900 compiler, but yes, you have to use a real console to test it. I did a lot of CF card swapping during the testing phase, and I was wishing I had the serial-to-PC mod for my RS232 card. Then again, I did not have my PEB set up, so that would not have helped much either. Emulator support would be great, but that is asking a lot of the emulator authors, especially since I should write the reference code.

 

Mixing emulation with real hardware would be interesting, especially if the emulation had access to a modern file system of some sort. I don't know if any of the 99/4A emulators decouple the VDP interface enough to make swapping in a real interface feasible without a lot of rework. Maybe Mizapf or Tursi can chime in on that?

 

I have a pin-out on my website for the F18A, and you only need 12 I/O pins (CD0..7, MODE, #CSW, #CSR, #INT) if you include the interrupt output. Other than that, Vcc to 5V, Vss to ground, and reset can be pulled high (it is active low). CD0..7 should be stable before pulling #CSW or #CSR low, and only one of #CSW or #CSR can be low at any given time (#CSW == #CSR == 0V is an illegal state). All the inputs go through a buffer which provides the 5V to 3.3V translation for the FPGA. Are the Rpi or Arduino I/O 5V? I never checked in that much detail.

Edited May 1, 2013 by matthew180

[Manic1975]

My Mame cabinet is in reality HTPC. I build it myself. I use Windows 7 with media center. Media center can use my tv card for recording and watching DVB-T and DVB-S. For TV capturing I use WinTV-HVR-3300. To run Mame I use Gameex frontend. So I can watch TV and play all favorite mame games!

I will put TI 99/4a games soon too!

 

 

Here is picture of my HTPC.

Edited May 1, 2013 by Manic1975

[sometimes99er]

I’ve got PlayStation 2, Wii, VSmile, Sega Megadrive and a dedicated Thomas the Tank Engine under the main flat in the living room area. The PlayStation supported Linux though discontinued. Haven’t looked at the emulators on Wii (they’re already in the Wii Shop), homebrew channel etc. I would like MAME and MESS to be there somehow, I guess preferable on a PC like yours. GameEx looks nice.

[Manic1975]

Under Gameex you can put every emulator. I use 2 versions of mame emulator under gameex. Gameex is configured to start the right one. I will try to put mess and stella emulator under gameex. I think there will be no problem to start right one. There is configuration file to specify what emulator to use with specific file.

Does Raspberry pi emulate at 100% of speed like emulator on PC? Have someone try to compile mess or ti-99/sim and then try to use it on pie? Is emulation speed OK?

[slinkeey]

Ok, not to sound stupid, but what is it with this emulator speed??

 

Do these rasberry PIs really have so much garbage on them that a 700MHz CPU or whatever struggles to handle running something that emulates a 3.0MHz system?

[Manic1975]

Question is does Pie emulate at same speed like real TI 99/4a. 700Mhz CPU have power to emulate TI but I'am not shure if compiled emulator code is optimize for Pie. Please correct me if I was wrong. I know some emulators work on 233 Mhz Pentium processor just fine and I hope it will work on Pie.

[Vorticon]

Ok, not to sound stupid, but what is it with this emulator speed??

 

Do these rasberry PIs really have so much garbage on them that a 700MHz CPU or whatever struggles to handle running something that emulates a 3.0MHz system?

 

My Rpi is definitely slow when launching programs, which I assume is related to the fact that the OS is on an SD card. The Midori browser is also slow in the running. I have not run any emulators on it as of yet, but I may want to try MAME and see how that goes. It's certainly does not feel zippy, but then my base system is an Alienware Aurora R3, so my perceptions might be a bit skewed

[mizapf]

The pure MHz numbers are not a good indication about the performance of an emulation. For MESS I can say, since I've been working on its TI/Geneve part for some years now, the issue is that basically everything happens in a single thread. There are some ways to employ multithreading, but this mainly helps out on the display side (the docs of the configuation options say "this enables rendering and blitting on a separate thread").

 

So for a single cycle that you see in the 3 MHz TI, we have to do everything in serial that actually happens at this time in parallel, including the CPU activity, the selection of circuits out there on the board, the video processing, the sound processing, the speech processing, generation of wait states, decrementing timers etc.

 

Thus, different to hardware (as already mentioned here), when a line is set, I have to loop through all devices on that line to set the value. Every single time. This proved to be painful in the TI-99/8 when going through its large GROM library every time I access the GROM area. Hence, I rearranged the list so that the main GROMs are found first, but this is actually not a really good solution (because it defers the problem to the rarely used parts and does not solve it).

 

The situation got a bit more difficult when I rewrote the CPU cores to more closely emulate the microprogramming (we discussed that already ... I know this may be pretty different to the real hardware, but it is done in a way that I have to go for a pure non-parallel software solution) pushing up the CPU load. I can at least say that the emulation up to the 99/8 and the Geneve runs at full speed on a single core with about 2.6 GHz.

 

(Recently there were some issues with the C64 part in MESS, after they rewrote the 18 MHz floppy controller, which slowed the whole emulation down to 30% - note, on a QuadCore system! I have to check whether they actually solved that issue; did not check it recently.

 

valgrind is our friend for discovering hot spots in the code, and that is, we really need to use it.

[+Gemintronic]

The fail here is complete apathy in getting video acceleration in X going. Big mistake. The one dev that used to post his progress on hacking it himself gave various technical excuses and basically abandoned his efforts. The Pi people too seem to have no interest.

[+stephena]

The fail here is complete apathy in getting video acceleration in X going. Big mistake. The one dev that used to post his progress on hacking it himself gave various technical excuses and basically abandoned his efforts. The Pi people too seem to have no interest.

 

I can confirm this in my testing of Stella. If you start X and use Stella that way, it is terribly slow (I'd estimate only 50% speed). There's no acceleration being done in X at all. And since OpenGL isn't fully supported in X yet either, Stella can't use its GL renderer, which would make things much faster.

 

Now, it just so happens that Stella is based on SDL, and SDL is able to render to the framebuffer console (known as fbcon). When you start Stella that way, it runs much better, since it's (a) bypassing X, and (b) actually using some acceleration.

 

Stella is in the process of being ported to SDL2, and I'm hoping that eventually the GL issue will be worked out on the Pi, and that SDL2 will be optimized for it. When (if) that happens, it should be possible to launch within X and still get good performance.

[Tursi]

Without commenting on the rest of it, Classic99 mostly decouples the VDP - there's a wvdpbyte and rvdpbyte function that handles the interface to the VDP ports, implementing those to reach out through a hardware port would be enough. (You would need 8 bits of bidirectional data and 2 bits of mode select, IIRC).

 

Classic99 cheats on the VDP interrupt, though, the interrupt test is integrated into the main loop itself. Your options there are either allow it, in which case interrupts will not be in sync with the real VDP (and the F18's extra interrupts won't work), or feed another line back and replace the test in Classic99 with checking that bit.

 

With those two tweaks, everything in Classic99 -- including CPU overdrive -- should work on a real external VDP.

 

All that said, Classic99 won't run on a Raspberry Pi without x86 emulation being involved, because it is tied to the Windows APIs, so it's not really your first reach. Michael already talked about MESS, but that at least has ARM compatibility.

[matthew180]

Ok, not to sound stupid, but what is it with this emulator speed??

 

Do these rasberry PIs really have so much garbage on them that a 700MHz CPU or whatever struggles to handle running something that emulates a 3.0MHz system?

 

Trying to run an emulator on a pre-emptive, GUI-based, multi-tasking OS is going to cost you a *lot* of the CPU's and system's raw speed. OpenGL and modern graphics cards help *a little*, but the video subsystems on the emulated machines need to be emulated in code because the subsystems are custom or unique, so you are software-rendering to a pixel buffer anyway. Even if you render pixels as OpenGL quads for speed, you still have to generate the quads.

 

Also, "threads" are still mostly a software "thing". A multi-cpu / multi-core system can truly run multiple threads concurrently, but only as many threads as there are CPUs or cores. Compare that to the number of processes running on the multi-tasking system (and a process might have many threads launched), and you see that most applications are still being pre-empted and time-sliced by the kernel to get runtime on a CPU (or core). Do a "ps -xa" on your Rpi and you will see a *lot* more processes than there are cores on the CPU. You would need as many cores are there are processes to have true parallel execution all the time. The kernel has to tend to every one of those tasks, sleeping or not, a few thousand times a second. Pile on top of that the GUI, network subsystem, interrupts, etc. and you see why emulators have such a hard time. I'm amazed that the emulator authors get the emulators to run as well as they do! They have done a good job to say the least.

 

When you start talking about running an emulator on a more limited system like the Rpi, you need to start cutting the overhead. Ditch the OS and you will find a much nicer platform for writing an emulator. In essence, the emulator *becomes* the OS.

 

[+stephena]

When you start talking about running an emulator on a more limited system like the Rpi, you need to start cutting the overhead. Ditch the OS and you will find a much nicer platform for writing an emulator. In essence, the emulator *becomes* the OS.

 

Yep, that's kind of what happens when you run Stella in fbcon/DirectFB mode; it bypasses X entirely. Sort of like on older Windows 95/98 systems, where you drop back to a real DOS session to get more direct control over the computer.