BASIC Accelerator Card/Socket Possible?

[TomXP411]

On 12/14/2021 at 9:01 AM, Edmond D said:

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.

Probably not using the Pi Pico - at least not directly. I just don't expect that CPU to be able to keep up with the timing resolution needed to brute force the 6502 bus at 8MHz. When you look at the actual timing requirements, you're looking a minimum of 32MHz time slices, but possibly 64MHz. Even with a superscalar processor, you'd only get 2 to 4 machine code instructions per 6502 bus cycle, and you literally can't manipulate GPIO on the Amtel fast enough to manage the I/O in that amount of time. I could be wrong... maybe it's possible using DMA, but it just seems unlikely to be reliable. 

What you'd need to do is add some sort of UART to act as a bridge between the Pico and the CPU. It could be a parallel UART, like a CIA chip, or it could be a serial device like a 6551 ACIA. 

Of course, at this point - having it on a card is pointless. We already have two CIAs in the system, and if you wanted to build a 6551 VIA card, it makes sense to make that a more general purpose serial card with a TTL Serial or RS-232 connection to the outside world. 

It seems like a lot of discussion regarding things kind of thing keeps coming back to the same issue: we need a parallel device I/O implementation on the User port in the KERNAL, something fast and reliable, which can be accessed via a device number. Considering the speed of the 6502 based FAT implementation, I think we could build a faster external device than the built in SD card storage. 

Anyway - coming back to the original point. A device like this is possible, but the expansion bus is not the place for it. Either the IEC or User port is a good place for something like this. 

 

[Tatwi]

I was thinking a procedure like

1. 
   User issues the RUN command
   


2. 
   X16 kernel sets some trigger somewhere high
   


3. 
   Pico is triggered by line being high to copy X16's full BASIC RAM into its RAM
   


4. 
   Software on Pico extracts BASIC code from its memory
   


5. 
   Software on Pico uses BASIC to compile a 6502 program
   


6. 
   Software on Pico copies the program in to X16's High RAM
   


7. 
   Software of on Pico sets trigger line low again
   


8. 
   X16 kernel executes program at specific address once after trigger line becomes low. 
   

Or something to that effect. The Pico only needs to be able to read X16's memory, switch banks, write to the X16's high memory banks, and set some trigger somewhere that is monitored by both processors. As long as the ones and zeros can be moved quickly between the system, software on the Pico can brute force through the compilation in no time flat. We're talking less than 64KB of program here folks.

Again, not an electrical engineer.

[TomXP411]

On 12/14/2021 at 5:53 PM, Tatwi said:

I was thinking a procedure like

1. 
   User issues the RUN command
   


2. 
   X16 kernel sets some trigger somewhere high
   


3. 
   Pico is triggered by line being high to copy X16's full BASIC RAM into its RAM
   


4. 
   Software on Pico extracts BASIC code from its memory
   


5. 
   Software on Pico uses BASIC to compile a 6502 program
   


6. 
   Software on Pico copies the program in to X16's High RAM
   


7. 
   Software of on Pico sets trigger line low again
   


8. 
   X16 kernel executes program at specific address once after trigger line becomes low. 
   

Or something to that effect. The Pico only needs to be able to read X16's memory, switch banks, write to the X16's high memory banks, and set some trigger somewhere that is monitored by both processors. As long as the ones and zeros can be moved quickly between the system, software on the Pico can brute force through the compilation in no time flat. We're talking less than 64KB of program here folks.



Again, not an electrical engineer.

Again, still not possible with the Pico. 

It is possible to use a microcontroller as a co-processor, but it's going to have to interface through an intermediary of some sort. The Pico itself can't simply take over an 8MHz 6502 bus via its GPIO pins in the way you're thinking.

[Wavicle]

On 12/14/2021 at 9:53 PM, TomXP411 said:

Again, still not possible with the Pico. 



It is possible to use a microcontroller as a co-processor, but it's going to have to interface through an intermediary of some sort. The Pico itself can't simply take over an 8MHz 6502 bus via its GPIO pins in the way you're thinking.

When I prototyped my X16 wifi card, this is the approach I went with. It had an ESP32 + uSD that acted as a mass storage device. It allowed FTP file transfers on the wifi side and used an ancient Cyclone II FPGA that I had in my parts bin as an interface between the ESP32 and 6502 bus. The ESP32 would write responses to 6502 requests into a 32-entry circular FIFO on the FPGA which the 6502 could read without a bus timing violation. (It worked okay-ish; I don't have an X16 or VERA, so it was tested on a 6502 reference design.)

[TomXP411]

Now that's an interesting thought, building an FPGA that can drop in to the expansion slot. Even if it's fairly limited, a baseline code set could be provided for things like your ring buffer, a UART, a VIA, and a few other basic utility devices that would make it easier to connect external hardware. 

[paulscottrobson]

On 12/14/2021 at 12:48 PM, Edmond D said:

Perhaps you could elaborate? 



 

You have a choice between very slow (psuedocode) or long winded (think of the 6502 code to add two 16 bit integers). Have a look at the code compilers generate ; Action, C, anything that outputs 6502 code. FORTH doesn't work well particularly ; few registers, one stack. Though jmp ($xxxx,X) has made it better. The best way of deving for the 6502 is to write the slow bits in a fairly compact p-code and the fast bits in raw assembler.

[paulscottrobson]

On 12/14/2021 at 6:47 PM, TomXP411 said:

Probably not using the Pi Pico - at least not directly. I just don't expect that CPU to be able to keep up with the timing resolution needed to brute force the 6502 bus at 8MHz. When you look at the actual timing requirements, you're looking a minimum of 32MHz time slices, but possibly 64MHz.

The whole thing is utterly insane.

If you want an authentic retro experience, expect the retro problems. The machines aren't that quick and the graphics aren't that great.

There's a thing called the "Cerberus 2080". It's a twin 6502/Z80 machine that uses a couple of CPLDs to replace a wodge of TTL. Graphics are monochrome UDGs. If you want a kit, accessible hardware go for that sort of thing. Or one of the ZX81 or Spectrum clones maybe.

Or just say s*d it and go down the Commodore X8 type route and push the CPU up as fast as it will go.  Same route as the Spectrum Next, and the Mega 65. Something that's fairly technically close to the original idea, cheap to build and doesn't waste time on endless timing issues trying to glue things together.

Over engineered solutions to problems created by ridiculous design decisions. Why do we have to have a pretend Vic20 ; what happened to the concept of it being educational. I'm an ex-teacher who started in 1985 and I'd have avoided Microsoft BASIC *then*. Now it should be viewed as a form of child abuse.

It's *way* easier to rewrite the Kernel and BASIC than it is to continually try to hack it to get something vaguely acceptable. The code is awful, incomprehensible and chaotic. 

And we're still stuck with the bizarre filesystem concepts that originate in the old PET IEEE488 design, so presumably half a dozen ancient typeins will work.

[Edmond D]

On 12/14/2021 at 4:48 AM, Edmond D said:

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? 

 

On 12/18/2021 at 12:59 AM, paulscottrobson said:

You have a choice between very slow (psuedocode) or long winded (think of the 6502 code to add two 16 bit integers). Have a look at the code compilers generate ; Action, C, anything that outputs 6502 code. FORTH doesn't work well particularly ; few registers, one stack. Though jmp ($xxxx,X) has made it better. The best way of deving for the 6502 is to write the slow bits in a fairly compact p-code and the fast bits in raw assembler.

Thanks for explaining your view.  While the 6502 may not be the best target, there is lots to be said for optimizing complier output. Being able to write in a simple language (which BASIC was originally designed for) and have it potentially speed up significantly by a subsystem sounds like a win. It might take some very clever hardware design, a lot of work to build a compiler that can make the X16 run BASIC as fast as possible and some cash, but it still seems doable to me. Whether it's reasonable to do so is open to opinion.

While the 6502 is perhaps a very primitive processor compared to what's available today, it was created at a time where it was chip first and languages second. Modern development seems to consider programming goals to help define what the processor's design and features should be. The fact it's still in production suggests that it's enough for what the market wants in a CPU.

 

Overall, as a hobby platform, I think the X16 hits the mark. It allows those to program in BASIC and move onto many different languages. Hardware development is possible for people who want to go that route. Rewriting the kernel and the interpreter is open for those who have the time and skill. No computer is going to please everyone, but I think the design is going to be loved by those who invest into it. It may not be the best system ever, it does have some flaws that could be off-putting; I think people recognize that.  

 

[BruceMcF]

On 12/14/2021 at 8:53 PM, Tatwi said:

I was thinking a procedure like

1. 
   User issues the RUN command
   


2. 
   X16 kernel sets some trigger somewhere high
   


3. 
   Pico is triggered by line being high to copy X16's full BASIC RAM into its RAM
   


4. 
   Software on Pico extracts BASIC code from its memory
   


5. 
   Software on Pico uses BASIC to compile a 6502 program
   


6. 
   Software on Pico copies the program in to X16's High RAM
   


7. 
   Software of on Pico sets trigger line low again
   


8. 
   X16 kernel executes program at specific address once after trigger line becomes low. 
   

So you are suggesting using the Pico or some such as a Just In Time compiler for Basic code.

One potential bottleneck here is (5): if it's simple enough to compile quickly, it won't be that optimized, and if it's complex enough to optimize well, it could easily take as long to finish the optimization as it would have taken to just run the Basic program on the X16.

And if you are running the Basic program multiple times, you are doing that compilation each time, for the same result, at which point I wonder why not just have a Basic compiler run on the X16, develop the Basic code in the interpreter to make sure it runs (though slower than you want), and then compile it to get the speedup. That can include whatever runtime the compiled (or pseudo-compiled) code needs stored in high RAM, since making sure the runtime is loaded can be part of the start up for the compiled code.

 

[Tatwi]

On 12/19/2021 at 8:48 AM, BruceMcF said:

So you are suggesting using the Pico or some such as a Just In Time compiler for Basic code.

That is it, yes. I knew it there was a term for the concept.

On 12/19/2021 at 8:48 AM, BruceMcF said:

why not just have a Basic compiler run on the X16, develop the Basic code in the interpreter to make sure it runs (though slower than you want), and then compile it to get the speedup. 

I was just thinking it would be nice if BASIC programs could seamlessly run at close to machine language speed by simply typing the RUN command as usual, thus changing literally none of the experience of using BASIC and none of documentation, beside "type BASIC++ and your program will run faster".

There's no point in doing it if it's going to require the end user to do or learn something new/different, because there are already fifty bajillion other ways to do things...