Jump to content
  • 0
StinkerB06

Can the VERA's FPGA be reprogrammed?

Question

Is it possible to manually (not from software) re-program the VERA's on-board FPGA to perform different kinds of tasks? This can perhaps allow the video modes to be changed, or even allow a virtual 2nd CPU to be created if there's enough spare logic blocks. I might as well replace the default PSG/PCM audio with my own Amiga-like sampler, to be paired with the otherwise hard-coded YM2151 and SAA1099 audio.

I know users will be able to re-program the X16's flash ROM with their own software, to be paired with their custom VHDL/Verilog code if only @Frank van den Hoef makes this possible.

Share this post


Link to post
Share on other sites

Recommended Posts

  • 0
On 1/13/2021 at 8:29 PM, Sohl said:

New guy here!  I posted an intro in the Intro section, so I will jump right into my question.

@Frank van den Hoef if you have a moment, or perhaps others can answer too.  A question came up about adding math coprocessor functions to VERA in a YouTube comment to a Matt Heffernan assembly programming tutorial using the X-16 as a target platform. 

 

Back in 1981, Digital Acoustics DBA DTACK Grounded created a 68000 co-processor board for Apple II and Pet to give faster floating point to the host computers. This seems very similar to what Acorn was doing with the Tube. I would think that just plunking an ARM core on an expansion card would be a really cool way to do the same thing today, and much easier (and cheaper) than creating your own FPU in the VERA FPGA.

 

Share this post


Link to post
Share on other sites
  • 0
1 hour ago, Terrel Shumway said:

Back in 1981, Digital Acoustics DBA DTACK Grounded created a 68000 co-processor board for Apple II and Pet to give faster floating point to the host computers. This seems very similar to what Acorn was doing with the Tube. I would think that just plunking an ARM core on an expansion card would be a really cool way to do the same thing today, and much easier (and cheaper) than creating your own FPU in the VERA FPGA.

 

 

I wonder if you could just interface with an actual FPU on an expansion board. It would take work, but the Motorola 688882 math coprocessor was designed to work as a direct coprocessor for compatible Motorola MPU's and as a peripheral processor for other Motorola and non-Motorola MPU's.  That is, you can place it on an 8. 16. or 32 bit bus and treat it as a peripheral chip to be interfaced with like a 65C22 VIA or an ACIA.  The coprocessor and MPU do not have to have the same clock speed.  You would need glue logic.  You would need code on the assembly side to convert the data to and from the correct floating point format.  There are small quantities of used and NOS Motorola 688882 math coprocessors available from eBay and the like.  There are tens of thousands available from Rochester Electronics NOS, though Rochester tends to want about $250 for a minimum order of any product except if they've got less than $250 of a product remaining.

I was looking into the 68882 for a possible 65C816 homebrew computer project.  Certainly not for mass production like the crew here is doing with the X16, or some of the other projects out there like the Mega65 or the C256.  The more I think about, though, the more I'm considering making it into a second processor expansion for the Commander X16, akin to what could be done with the BBC Micro or the TRS-80 Model 16's Z-80 + 68000 default configuration.  I'll have to think more on this after I get past the breadboard stage of tinkering. 

Another FPU option would be a separate FPGA as math coprocessor - there are several options upon on OpenCores.org.  Again, some glue logic would be needed to integrate it with whatever expansion bus the Commander X16 ultimately offers.

A third thought would be interfacing with a Raspberry Pi Zero.  Alas, the Pi won't function as an SPI slave, which would be the obvious interface, but a bare metal Pi could be interfaced without the latency issues of Linux and still offer most of the hardware capabilities if you needed them: FPU, HDMI, USB, etc.  The circle project offers a C++ starting point for bare metal Pi programming, with plenty of examples.  You could make it work with a Pi running Linux, but there would likely be random latency problems because the OS has preempted your code.

Just throwing some more ideas out there.

Share this post


Link to post
Share on other sites
  • 0
1 hour ago, Sean said:

 

I wonder if you could just interface with an actual FPU on an expansion board. It would take work, but the Motorola 688882 math coprocessor was designed to work as a direct coprocessor for compatible Motorola MPU's and as a peripheral processor for other Motorola and non-Motorola MPU's.  That is, you can place it on an 8. 16. or 32 bit bus and treat it as a peripheral chip to be interfaced with like a 65C22 VIA or an ACIA.  The coprocessor and MPU do not have to have the same clock speed.  You would need glue logic.  You would need code on the assembly side to convert the data to and from the correct floating point format.  There are small quantities of used and NOS Motorola 688882 math coprocessors available from eBay and the like.  There are tens of thousands available from Rochester Electronics NOS, though Rochester tends to want about $250 for a minimum order of any product except if they've got less than $250 of a product remaining.

https://www.pjrc.com/store/teensy41.html

Teensy 4.1 has a FPU (and USB and ....) and costs less than $30... faster and more capable than any retro math coprocessor. DTACK Grounded did eventually support the 68882 and the National Semiconductor FPU as peripherals when the chips became available, but even the software FP stack running on a 68000 was way faster than the 6502.

Interfacing a modern ARM SOC to the X16 may seem like cheating and out of scope for David's vision, but DTACK Grounded was also out of scope for Apple's vision of the II series. It was an amazing tool for those who cared about crunching numbers.

By creating a "stuffer" card like the one D.G. created for the Apple II, the Kernal only needs one low-level driver to support whatever SCSI-like packet interface people want to throw on an expansion card (including Ethernet and USB). I think this was also the idea behind Acorn's "Tube": you can add whatever co-processor you want and you only need one software interface.

I don't think there is any need for an ACIA or VIA. A much cleaner interface can be created with any microcontroller that has enough (16-40?) GPIO pins.

 

1 hour ago, Sean said:

I was looking into the 68882 for a possible 65C816 homebrew computer project.  Certainly not for mass production like the crew here is doing with the X16, or some of the other projects out there like the Mega65 or the C256.  The more I think about, though, the more I'm considering making it into a second processor expansion for the Commander X16, akin to what could be done with the BBC Micro or the TRS-80 Model 16's Z-80 + 68000 default configuration.  I'll have to think more on this after I get past the breadboard stage of tinkering. 

Great idea. This is exactly what I am thinking.

1 hour ago, Sean said:

A third thought would be interfacing with a Raspberry Pi Zero.  Alas, the Pi won't function as an SPI slave, which would be the obvious interface, but a bare metal Pi could be interfaced without the latency issues of Linux and still offer most of the hardware capabilities if you needed them: FPU, HDMI, USB, etc.  The circle project offers a C++ starting point for bare metal Pi programming, with plenty of examples.  You could make it work with a Pi running Linux, but there would likely be random latency problems because the OS has preempted your code.

Does the X16 do SPI? That would be perfect.

 

Share this post


Link to post
Share on other sites
  • 0
24 minutes ago, Terrel Shumway said:

Does the X16 do SPI? That would be perfect.

The Commander X16 team have been rather sparse in detailing the hardware, but I haven't seen anything about SPI support in the posts that I have seen about it.  On the other hand, there are plenty of "generic" 6502 solutions for that, which I suspect will be compatible with what they have said about the expansion capability.  Bit-banging using a VIA is a common approach.  I think it can also be done with shift registers.  But there are also two common CPLD-based approaches I've seen for 6502 (and 65816) use.

65SPI using an Atmel ATF1504 CPLD: https://sbc.rictor.org/65spi2.html

65SPI/B or SPI65/B using a Xilinx 9572: http://www.6502.org/users/andre/spi65b/index.htmlhttp://www.6502.org/users/andre/spi65b/65SPI-B Datasheet V1.1.pdf

And if you're interested in a bus approach to connect multiple SPI devices, see http://forum.6502.org/viewtopic.php?p=10957

 

Most of the details I've seen so far regarding expansion is in this post: 

 

Share this post


Link to post
Share on other sites
  • 0
1 hour ago, Sean said:

The Commander X16 team have been rather sparse in detailing the hardware

The team have been fairly sparse in detailing the hardware that has been actively in flux, or with details that are completely irrelevant to programming the system, with the exception of the VERA. They've been highly forthcoming with the VERA, with all the information one could ever need to program for it. The only reason the VERA emulation isn't a reference-quality, 1-for-1 representation of the final hardware is because it is quite weighty to emulate its behavior at a pixel-perfect level, plus a small handful of bugs in certain unusual edge cases found their way in during the optimization process. The VERA emulation should still be very, very good, and to improve it further would require either rolling back some of the more important optimizations that were made, or else a total brain-dump from Frank (or the equivalent of that), or else having a final production VERA daughterboard so that the behavior can be studied in-depth.

Share this post


Link to post
Share on other sites
  • 0
On 2/15/2021 at 8:07 PM, Terrel Shumway said:

https://www.pjrc.com/store/teensy41.html

Teensy 4.1 has a FPU (and USB and ....) and costs less than $30... faster and more capable than any retro math coprocessor. DTACK Grounded did eventually support the 68882 and the National Semiconductor FPU as peripherals when the chips became available, but even the software FP stack running on a 68000 was way faster than the 6502.

Interfacing a modern ARM SOC to the X16 may seem like cheating and out of scope for David's vision, but DTACK Grounded was also out of scope for Apple's vision of the II series. It was an amazing tool for those who cared about crunching numbers.

By creating a "stuffer" card like the one D.G. created for the Apple II, the Kernal only needs one low-level driver to support whatever SCSI-like packet interface people want to throw on an expansion card (including Ethernet and USB). I think this was also the idea behind Acorn's "Tube": you can add whatever co-processor you want and you only need one software interface.

I don't think there is any need for an ACIA or VIA. A much cleaner interface can be created with any microcontroller that has enough (16-40?) GPIO pins.

 

Great idea. This is exactly what I am thinking.

Does the X16 do SPI? That would be perfect.

 

The perfect "retro" style solution to the FPU problem is using Am9511 - these are still quite abundant, interfacing is easy, and offer 10X speed up of all FP operations. Most run at 2MHz so some bus wait cycles would have to be included. Too bad the motherboard does not have an open socket for them but I am sure they could be added later on expansion card, and with Basic modified to use them it would be great speed boost. https://github.com/zpekic/am9511 

Share this post


Link to post
Share on other sites
  • 0
21 hours ago, zpekic said:

The perfect "retro" style solution to the FPU problem is using Am9511 - these are still quite abundant, interfacing is easy, and offer 10X speed up of all FP operations. Most run at 2MHz so some bus wait cycles would have to be included. Too bad the motherboard does not have an open socket for them but I am sure they could be added later on expansion card, and with Basic modified to use them it would be great speed boost. https://github.com/zpekic/am9511 

A while ago I managed to find 5 of what *might* be the 4MHz variant (AM9511A-4DC) - but haven't been able to test them yet. Maybe they're real, maybe they're only good for 2MHz or they're outright fakes.

Once I manage to find some time, I'll need to build a minimal system to test these, as my eventual goal is to build a math coprocessor card for the X16 - not because it'll be profitable, just to see if I can make it. I suspect it will be somewhat similar to the Arithmetic Processor AP-1 described here. Still, I first need to test the chips first.

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)
39 minutes ago, Jeff Pare said:

A while ago I managed to find 5 of what *might* be the 4MHz variant (AM9511A-4DC) - but haven't been able to test them yet. Maybe they're real, maybe they're only good for 2MHz or they're outright fakes.

Once I manage to find some time, I'll need to build a minimal system to test these, as my eventual goal is to build a math coprocessor card for the X16 - not because it'll be profitable, just to see if I can make it. I suspect it will be somewhat similar to the Arithmetic Processor AP-1 described here. Still, I first need to test the chips first.

That would be super cool! I know the original data sheet listed 4MHz versions I was never able to find them or see them - maybe they all ended up in some old cruise missile? 🙂 The best would be to have the socket on the M/B but I understand that ship has sailed, and besides there is only so much space on a tight board. But I think the critical part here is the software - X16 is still very much a Microsoft Basic computer, so to really utilize it (beyond Mandelbrot demos) is to have a version which replaces all "software FPU" routines with calls to Am9511. The storage of floating point variables in memory probably should still be 5-byte format (if I am not mistaken), so quite a bit of conversion. Or go for deep change and really use 4 bytes and save some memory. Or 4-bytes but real IEEE754 format - lots of dilemmas! Either way, the boost in Basic would be significant as lots of variables are by default FP. 

Btw, the code I shared could be used for simple test as it runs through lots of calculations. I generate the clock for Am9511 in software on the Propeller, so it is easy to test the upper limit. I have dismantled my test rig, but it could be replicated essentially with just a few wires on this board: https://www.parallax.com/product/propeller-activity-board-wx/ - the breadboard is already there. One just needs a 5V to 12V boost up voltage converter, or maybe not even that if the supply voltage is stable 12V because from what I see some pins make it available. The Propeller flip-chip will work too (cheaper!) but then you have to supply own breadboard.

 

 

Edited by zpekic
Forgot something
  • Like 1

Share this post


Link to post
Share on other sites
  • 0
On 1/13/2021 at 7:29 PM, Sohl said:

New guy here!  I posted an intro in the Intro section, so I will jump right into my question.

@Frank van den Hoef if you have a moment, or perhaps others can answer too.  A question came up about adding math coprocessor functions to VERA in a YouTube comment to a Matt Heffernan assembly programming tutorial using the X-16 as a target platform.  Anyway, I've only done a small amount of VHDL for FPGA on Xilinx Zynq but I know many FPGAs have several specialized multiplier/DSP cells that can be used in designs.  Is the VERA design close enough to complete now that you know which FPGA will be used for VERA and how many unallocated cells it will have that might support later added functions?  Post-launch, of course!

Hope this is not too prickly of a topic to raise again.  I've skimmed this thread and several others and I think I understand the motivation and intent of the X16 project to keep to a fairly pure 8-bit 80's experience.  I hope to support it myself with some programming work at least. Best wishes to all!

The dev team hasn't, to my knowledge, officially stated what the VERA's FPGA is, but the only device that seems to tick all the right boxes is the Lattice iCE40 UltraPlus. That product does have 4 or 8 DSP blocks (depending on whether it's a 3K or 5K part), but the blocks are fairly simple and, if I'm skim-reading the datasheet correctly, only has a 16x16 bit integer multiplier and 32 bit accumulator. Some (or all) of those may already be used by the PCM and PSG functions.

Share this post


Link to post
Share on other sites
  • 0
The dev team hasn't, to my knowledge, officially stated what the VERA's FPGA is, but the only device that seems to tick all the right boxes is the Lattice iCE40 UltraPlus. That product does have 4 or 8 DSP blocks (depending on whether it's a 3K or 5K part), but the blocks are fairly simple and, if I'm skim-reading the datasheet correctly, only has a 16x16 bit integer multiplier and 32 bit accumulator. Some (or all) of those may already be used by the PCM and PSG functions.

The FPGA is indeed a Lattice iCE40 UltraPlus 5K. If I remember correctly it is about 85% filled up. The VERA design has been finalized for about a year now. So yes, all the VERA specs are quite final.
  • Like 5

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use