*** M E M O R U M ***

Woooah! That black PCB looks swish!

So different FPGA again or did the problems with the other device get sorted?

gunrock wrote: ↑26 May 2024 10:06 So different FPGA again or did the problems with the other device get sorted?

Different, larger, FPGA its got enough ram to move everything that was located in the external ram to internal ram alogside the intenral tables etc and have space to spare. The resolution of the picture is too low to show it, but one of the silkscreen changes is the mention of the EP4CE10 FPGA board.

So...

Getting a cyclone 4 FPGA with enough memory to handle all of the video requirements internally also means getting a LOT more logic onboard as well.

The original Cyclone 2 had just over 4500 logic elements availale, and wasn't anywhere near full. The Cyclone board I'm currently testing** has over 10,000 so it makes sense to try and use some of that available logic space, as well as the ram.

The question is what to add ?

Looking at the ReMemotech code base for things we could "borrow":

• The z80 DART, would need level shifting extenally with something like a MAX3232 (or 2) , but might squeeze onto a daghterboard plugged in where the VRAM was.

• The floating point accelerator, that took about 5000 logic units when I tried (and rejected as being impossible to fit) it on the Cyclone 2 board so should fit the larger cyclone 4 with room to spare.

• Additional monitor output for VDP and 80 column output to VGA. Connection would have to be via the VRAM socket

Is any of that, or something else of intetest ??

I'm not saying it can be done, or will be done, but more, is it worth trying?



** I've a further FPGA Dev board with 182K ram and 50,000 Logic elements, but Dave's nixed that as an option on the grounds of cost!

Hi Martin,

This is an exciting prospect.

Ok, I have a laundry list of potential nice to have ideas, shoot down all the nonsense ones!

The ideas floated so far:

• The floating point stuff could be good, but apart from some nice 3d matrix math acceleration for vector graphics or a proof of concept Bitcoin miner, what else could it be used for?
• Z80 dart - so you would also have a RS232 connector somewhere on the end panel? Could be interesting and potentially useful for connectivity.

Of these two, I think the Z80 Dart gives the most bang-for-buck.

Some other ideas:

• F18A VDP - Matthew Haggerty's full TMS9918/9929 emulation. Extra graphics modes, 32 sprites on one line, hardware scrolling, multiple playfields with independent scrolling, DMA, full TMS9900 cpu as a GPU running at 100mhz and more. https://github.com/dnotq/f18a
• SID chip emulation - the sound chip on the MTX is probably the weakest component and what could be better than full cycle accurate SID emulation? Its in Lattice though, rather than Verilog. Of course, we'd need some audio out connectors. https://github.com/daglem/reDIP-SID

Other things I would like the MFX to support (that aren't necessarily FPGA related):

• Ethernet accessible from SDX Basic - I believe, from looking at the NFX implementation, Andy decided that it would only make sense to have the firmware drive the ethernet under CP/M. If it worked in SDX Basic, we could do things like have NET time synchronization of the internal clock (via a small program), for example. Or an FTP client in glorious 40 column mode.
• Debug stub for DeZog a Z80 debugger for VS code. This would allow me to debug my code, live on the machine. It has been modified to work with MSX emulators and works with actual ZX Spectrum NEXT hardware, so perhaps we could implement a remote that works without altering the MTX memory map, too much? Connectivity via Z80 Dart or Ethernet? https://github.com/maziac/DeZog
• Tube interface - BBC Model B-like tube interface for a second processor, maybe Z80, maybe 6502 or 6809? Not sure how easy it would be to add a second Z80 in the FPGA or even if there's enough room.

Anyway, just some food for thought. Feel free to disregard the impossible/idiotic/infuriatingly difficult stuff.

PS - Dave's a rotten spoilsport!

gunrock wrote: ↑21 Jun 2024 05:20 PS - Dave's a rotten spoilsport!

Well £150 for the FPGA alone might have made the final product a little too expensive. And to be honest, while 512 x 240 in 8 bits per pixel looks nice, it's a LOT of screen memory to update through I/O ports with a Z80. BIGGER is not always better. 32K screen ram may not do the bigger bitmaps, but it does meam all of Bill's added screens update in a reasonable period of time.

Technically you -can- use the Wiznet Ethernet interface from BASIC. It's connected to the Z80 through 4 I/O ports (#90 to #93). So in theory you can do everything Andy and Bill have done in C on CPM, with INP(x) and OUT x,y in BASIC. However while I manged to get the very first NFX prototype to ping the router from BASIC there was an awful lot of shuffling through the WIZ5100 data sheet and a lot of INP and OUT statements just to do that.

That's the point I put CPM on the ROM and gave the board to Andy, it needed a better programmer than me to make proper use of it! It might be possible to re-compile FTPD.COM as a RUN file, but that would need all the I/O code re-writing to use the ROM and not CPM.

The RS232 Idea is probably the only thing on the list that can be added for which support already exisits, anything else, screen modes, Ethernet, Floating point, needs someone to write some support for it.

The obvious place to put the RS232 connectors would be in the RS232 cutouts on the back of the case. They won't be in use, and the MFX and RS232 board can't physicaly coexist.

Rotten spoilsport here . . . . .

RS232 is likely doable, but to what end?

If there is a definite application for it, we could look at it, but "potential connectivity" isn't a convincing argument. However, I am open to being persuaded

If the FPGA pins previously used to connect to the external VRAM are re-purposed to connect to the remaining Z80 address and control lines then it might be possible to implement DMA transfer between the SD card and Z80 RAM, potentially speeding up I/O.

If I remember correctly, the FDX uses DMA to read / write floppy discs.

With a board redesign maybe.

I'm just looking for ideas to use up the extra FPGA resources, maybe with a small adaptor to plug into the VRAM socket.

A complete re-design is a step too far at this point.

Yes, the FDX used DMA, the SDX didn't, saving an awful lot of board space and ICs.

Martin A wrote: ↑21 Jun 2024 11:17 Technically you -can- use the Wiznet Ethernet interface from BASIC. It's connected to the Z80 through 4 I/O ports (#90 to #93). So in theory you can do everything Andy and Bill have done in C on CPM, with INP(x) and OUT x,y in BASIC. However while I manged to get the very first NFX prototype to ping the router from BASIC there was an awful lot of shuffling through the WIZ5100 data sheet and a lot of INP and OUT statements just to do that.

That's the point I put CPM on the ROM and gave the board to Andy, it needed a better programmer than me to make proper use of it! It might be possible to re-compile FTPD.COM as a RUN file, but that would need all the I/O code re-writing to use the ROM and not CPM.

Ah thanks, good to know! Not sure why I got the idea that CP/M was the only way to do it.

The RS232 Idea is probably the only thing on the list that can be added for which support already exisits, anything else, screen modes, Ethernet, Floating point, needs someone to write some support for it.

I get your point -why do all that work and still have nobody produce anything of note for the new features? I think that there are three things required to get folks to add new software titles to the MTX library:

• Skills
• Motivation
• Time

The first two are evident in a number of members of the community, i.e in all the folks who have produced working software to the MTX library, both back in the day and in recent years. I would assume that that the motivation is still there in active members of the boards here and on the Facebook group - everyone wants to see more software, right?

So, if we exclude the "faculty" (to me, that's you, Andy, Bill, Dave on hardware obviously, etc.) and people have the skills - I suspect the issue is the latter element, a lack of time.

In my own case, it's taken me over a month to reply to this thread - there's just too much going on at work and at home. Whether I have the skills is another question entirely - from my small aborted experiments with MTXLib, the answer is possibly not!

I guess the number of Memotech owners is just too small, thus the percentage of folks with all three qualities identified above, is too meagre to produce the prolific output of the C64, BBC and MSX communities. Even the CBM Plus 4 has a fairly vibrant scene (a lot of machines were sold into the Eastern Block after it failed to ignite in the West).

I can say though, that I very much appreciate the hardware and software that is produced by yourselves and the rest of the community. So, hats off to you all.