Use the Vectrex32 API via PIC32 assembly?

Started by RetroDawn, July 21, 2019, 01:49:51 PM

Previous topic - Next topic

RetroDawn

Hi!

I would love to buy a Vectrex32, but I am mostly interested in programming it via PIC32 (MIPS) assembly. This would be a great platform to develop Vectrex games on. If I am not mistaken, we should be able to get at least slightly higher refresh rates or more vectors and/or "scanlines" per frame by using Vectrex 32, since the 6809 can be dedicated to vectors, sound, and inputs.

I would be very interested in making calls to your API via assembly. It looks like a great API for Vectrex programming, and it's what makes Vectrex32 so ideal for assembly development, in my mind, if it can be accessed via assembly. Based on what I've read on Hackaday, I presume the implementation is a library developed with C++? I've never called into C++ libraries with ASM, but I know it's a lot harder than with C libraries (which I'm familiar with doing).

Would it be possible to take over the entire 512KB of RAM? I actually have one game in particular that I'm planning on developing, that will need *at least* that much space, but almost all of it is read-only data, so storing in the flash would be an option, but I believe I read before that you've got that all filled up. I think you were using one half of it, so as to always have a fallback, but were hoping to re-implement the fallback feature so as not to require one half of the space. Or maybe that was another project.... ;)

Thanks!

Vectrex32

Hi Retro,

I could understand wanting to write in C or C++. I'm not sure why you'd want to write in MIPS assembler.

To program the PIC32 directly, you'd need Microchip's MPLAB X, their hardware for programming, and a special third-party connector that I use (it's not expensive). I'd be happy to provide technical info on how to talk to the 6809.

But please consider trying BASIC first. Yeah, I know, BASIC is anathema to serious programmers. But I've packed a whole lot power into this implementation: live debugging, live screen updates during debugging, 2D sprites with scaling, rotation, and clipping, and a pretty nifty 3D graphics library (if I do say so myself :-) ). When you use those features, you're using my compiled C++ code and you're not paying any penalty for interpreting the BASIC code.

As for your large amount of read-only data: you can put it in a file and read it from BASIC code.

Even if you wanted your final version in C++, it might be worth prototyping it in BASIC.

Would you be willing to give some details on your project? We could do this over e-mail if you want to keep it quiet.

- Bob

RetroDawn

Quote from: Vectrex32 on July 21, 2019, 02:16:02 PM
Hi Retro,

I could understand wanting to write in C or C++. I'm not sure why you'd want to write in MIPS assembler.

...

Would you be willing to give some details on your project? We could do this over e-mail if you want to keep it quiet.

- Bob

Bob,

I have *very* good reasons for using MIPS ASM. ;) I'm more than happy to discuss this in email, with the caveat that this is a *very* hush-hush project, so I'd require you to treat it as if you've signed an NDA. I know that seems like overkill, but it won't when I explain the project to you. ;)

I'm send you an email now.

Best,
Jerri

RetroDawn

#3
Quote from: Vectrex32 on July 21, 2019, 02:16:02 PM
To program the PIC32 directly, you'd need Microchip's MPLAB X, their hardware for programming, and a special third-party connector that I use (it's not expensive). I'd be happy to provide technical info on how to talk to the 6809.

I have tool support for assembling and uploading the bin to a chipKIT Uno32 board without using MPIDE. I'm thinking that it should be possible to do the same with the PIC32 you're using, with the in-circuit debugger and the connector you use.

Do you have any thoughts on accessing your API via ASM? I assume you aren't thinking that will be an easy enough nut to crack, since you mentioned helping me talk directly to the 6809, which your library would do for me.

Thanks,
Jerri

RetroDawn

#4
From these examples for x86 and ARM, it doesn't seem to be any harder to call C++ from ASM than calling C from ASM. As long as there is a non-member function (or a wrapper for a member function) that can be called. Theoretically would be the same for the PIC32 C++ compiled code.

https://stackoverflow.com/questions/3911578/how-to-call-c-functions-in-my-assembly-code/3911792
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471g/CACEJCEF.html

For both, marking the C++ func with the extern "C" declaration is all that needs to be done on the C++ side. With ARM, you have to use the IMPORT directive when calling the C++ func.

The older ARM dev tools had some more requirements/restrictions for the C++ code:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471g/CACEJCEF.html

It will be interesting to see what is the case for PIC32 C++ code. I wasn't able to find any hits with Google.

Here's the info for writing wrappers, in case that's necessary, and you're open to adding them:
https://isocpp.org/wiki/faq/mixing-c-and-cpp#call-cpp

Thanks!
Jerri

RetroDawn

#5
Quote from: Vectrex32 on July 21, 2019, 02:16:02 PM
But please consider trying BASIC first. Yeah, I know, BASIC is anathema to serious programmers. But I've packed a whole lot power into this implementation: live debugging, live screen updates during debugging, 2D sprites with scaling, rotation, and clipping, and a pretty nifty 3D graphics library (if I do say so myself :-) ). When you use those features, you're using my compiled C++ code and you're not paying any penalty for interpreting the BASIC code.

As for your large amount of read-only data: you can put it in a file and read it from BASIC code.

Even if you wanted your final version in C++, it might be worth prototyping it in BASIC.

Oh, I absolutely intend on using your awesome BASIC dev env for doing some graphics-oriented prototyping. I think you've created a truly great tool, here. I just need to have ASM-level access to your API for my production version to be viable.

Providing access to your API via C and ASM would open it up to other projects/use cases and developers. And, it also provides a way for folks to develop for Vectrex32 without releasing the source code to the project, which some folks were concerned about. Although, maybe no one that declared such was actually going to develop a game--but there could be others who just never considered Vectrex32 for that reason. I intend to release my source under a GPL license, but not until I'm finished with the first pre-planned series of games I'm developing based on my engine.

Thanks!
Jerri