BASIC Accelerator Card/Socket Possible?

[Tatwi]

Admirable as the speed improvement to BASIC is on the X16, it would be great if there were an option to run it at around the same speed as native machine code. Perhaps this could be accomplished using a socket or an expansion card that makes use of a Raspberry Pi Pico? I'm not an electrical engineer, so I don't know how hard this would be to achieve, but I thought it would be inexpensive, effective, and in keeping with the spirit of retro machines, as they often had such accelerator addons. Sure, the Pi Pico is "way more computer" than the X16, but if used only for this specific purpose it would look like any other DIP chip, if a heatsink were applied to the top, and it would be insanely cost effective (a whole $5). 

Quote

READY



BASIC++



ERROR: Accelerator not found



READY



BASIC-- 



?

Here the BASIC++ command changes subsequent RUN commands to copy the X16's BASIC RAM to the Pico, where the Pico then compiles BASIC into machine code, loads the result into the banked RAM of the X16, and then tells the X16 to execute code. The compiler would add code to handle the required bank switching, making it invisible to the user. This would allow the program to remain loaded in the normal BASIC RAM area so it's still there when exiting the program and returning to the READY prompt. Also, compiling such a small program on the Pico would likely appear instantaneous, meaning it wouldn't feel like there was a downside to running BASIC programs this way. Finally, the user needs only type BASIC-- to return normal functionality to the RUN command.

I suppose that makes the Pi Pico less a co-processor and more an unnaturally efficient compiler! But, I think this concept makes good use of the X16's capabilities, really putting them first - ultimately the program runs 100% on the X16.

[Edmond D]

Sounds like a novel approach. A hardware inside option would eventually need a test system (ie shipping X16 computer) for this project to be developed. But for now I think would be possible to develop on a more capable machine (desktop) as a cross-compiler, then moved to a stand alone pico creating files that could be loaded on the X16 via a SD card. These would be logical steps to progress to an internal X16 card. 



One advantage of this system is that a better basic could also be implemented in a cross compiler using this methodology. It would not be a 100% in X16 solution until hardware ships, but hopefully give a better than Basic V2 performance. The upper limit is that of the CPU executing machine code speed, the lower could be below the speed of the stock V2 Basic. 

Right now, I see that there is Basic, Assembly, Prog8, C & Forth all for the X16 today which doesn't require any additional hardware (anyone please speak up if I've missed a language.) I believe that 8BG's goals didn't include so many options for programming the system - it's been the community developing other solutions.  I'd certainly welcome another option. It certainly isn't out of place in the 8 bit era - the Super Pet had dual CPUs in one box (but they worked independently of each other.)

I've got no experience with the Pi platform, so I'm speculating it could be done.  



 

[Tatwi]

On 12/13/2021 at 1:19 PM, Edmond D said:

One advantage of this system is that a better basic could also be implemented in a cross compiler using this methodology. It would not be a 100% in X16 solution until hardware ships, but hopefully give a better than Basic V2 performance. The upper limit is that of the CPU executing machine code speed, the lower could be below the speed of the stock V2 Basic. 

I hadn't thought of that. I was focused on making the normal BASIC environment simply run the software faster. However, being able to use a more robust syntax with this method could work great, because the BASIC syntax just gets translated into 6502 machine code for X16, so it wouldn't really matter what syntax was used... neat! It could be implemented where the BASIC+ command causes the RUN command to tell the Pico to compile using BASIC 2.0 and the BASIC++ command would tell it to compile using BASIC 7 or 10 or some other community created version. 

It's important to me that this mod doesn't change any of the standard experience of using BASIC, beyond typing BASIC+ or BASIC++ once and having your software running way faster.

On 12/13/2021 at 1:19 PM, Edmond D said:

I've got no experience with the Pi platform, so I'm speculating it could be done.  

Me either, but there's a bare metal C library that could most likely be used to boot and use an existing cross compiler. Failing that, I could definitely hack together a way to use a standard Pi Zero running Linux to accomplish the automated compiling, but I don't know to handle read/writing data on the X16. I imagine some type of custom fast interconnect could be used between the X16's bus and the Pi's GPIO pins, but who knows man!

On 12/13/2021 at 1:19 PM, Edmond D said:

Right now, I see that there is Basic, Assembly, Prog8, C & Forth all for the X16 today which doesn't require any additional hardware (anyone please speak up if I've missed a language.) I believe that 8BG's goals didn't include so many options for programming the system - it's been the community developing other solutions.

For sure! This community is really great, especially considering the lack of an actual machine to use.

[Scott Robison]

It's funny, I want to do basically this with pi2iec, though over the IEC bus. A virtual device that can accept a saved file, automatically compile or assemble it, then you can run it. A little more typing but in essence the same thing.

[TomXP411]

It would be interesting to see whether a Pi device has the timing resolution needed to handle the 6502 bus, even running bare metal code. 

Assuming you're simply executing the BASIC interpreter directly in C/C++, there are some pretty precise timing considerations and the need for enough GPIO pins to make it happen. 

I get different answers from different sites, but the Pi generally has 24-28 GPIO pins available, depending on the software environment running. If you can address 28 pins individually, then you can pretty much fully control the system directly. Just pull the CPU's RDY pin down, talk to memory or I/O directly, and give the RDY pin back when the task is complete. Even if you can't get all 28 GPIO pins, you can either multiplex some pins (such as the high address bits) or simply limit access to a specific address range.

Another possibility would be to treat the BASIC interpreter as a terminal device and connect it to the User port. Something like Maximite BASIC is well suited to that environment, and you could upload code to the Pi, send the RUN command, and then run a terminal emulator to interact with the interpreter. 

Another possibility is to simply replace the CPU entirely with an FPGA core, running at 24 or 48MHz. I've done some playing around with the Ultimate 64 at 48 MHz... and while it's not quite as fast as machine language, BASIC programs can be very speedy running on the Ultimate. 

If I could have it any way I wanted, I'd go that route - an FPGA running an accelerated core. That would give us the benefits of a faster CPU, maybe a 65816 or 68030, while still being era-appropriate in terms of program code. 

[paulscottrobson]

On 12/14/2021 at 12:44 AM, Scott Robison said:

It's funny, I want to do basically this with pi2iec, though over the IEC bus. A virtual device that can accept a saved file, automatically compile or assemble it, then you can run it. A little more typing but in essence the same thing.

Still have the problem that a 6502 is a very poor compiler target for *anything*.

 

[Edmond D]

On 12/14/2021 at 1:24 AM, paulscottrobson said:

Still have the problem that a 6502 is a very poor compiler target for *anything*.

Perhaps you could elaborate? 

 

[Scott Robison]

On 12/14/2021 at 2:24 AM, paulscottrobson said:

Still have the problem that a 6502 is a very poor compiler target for *anything*.

I did say "or assemble". And even though the CPU doesn't have certain features used by most high level languages, that doesn't mean it can't be a benefit to write something in C, Pascal, or some other compiled vs interpreted BASIC. It all depends on what you're trying to accomplish. Or even compiled BASIC.

[Kalvan]

Frankly, the only hardware improvement one could make to the CommanderX16 to accelerate BASIC without completely reengineering the system would be to add an IEEE half-precision FPU (with 8 extra bits of spillover precision) to better handle the lone floating point numeric data type.

[Edmond D]

In the original post the idea was to send the basic code to a sub-system that would compile the code into machine code then store that output into a location followed by executing it. The subsystem suggested would fit into a stock X16 as a card. My understanding of the concept is that it might be possible to do so.

There are threads in the forum that cover some programming techniques to speed up the execution of a program. If the sub system could analyze the program as a whole and create output that did optimization at a program level rather than a line level, then there could be speed improvements. 

One item not mentioned is the duration of  sending the code to the board, the time to optimize/compile it to machine instructions and then transfer it back into high memory. There might be cases where the existing basic gets to running the program and executes it faster that the Basic ++ could. 

FPUs might also improve Basic speed execution if the application used floating point numbers. @Kalvan Would you suggest this be a co-processor that took over the bus or a I/O window interface? 

Of course, the assumption that faster is always better might not hold true. I've seen people optimize code for speed without thinking about the context of the purpose of the code. For example, checking the temperature of a room to control the air conditioning in a loop. Having thousands of of readings of the current room temperature (optimized loop) verse one reading a second (unoptimized) isn't really going to affect how quickly the room becomes cooler in practical terms.