My latest kit designs

[Dean Netherton]

I have some new kits that i have been working on for a while now...

First one is a  a simple 6 slot green RCBus compatible backplane -- because these things need to be colour coordinated!  (https://www.dinoboards.com.au/green-6-slot-backplane)

The 2nd kit, is a linear (or flat) memory module for the eZ80 kit.  It allows the eZ80 to access upto to 2MB of directly addressable memory -- no banking needed. (https://www.dinoboards.com.au/2mb-linear-sram)

And finally, the FPGA HDMI video module for RC2014/RCBus.  Its based on the Tang Nano 20K FPGA - and emulates a full V9958 chip (with some extra extensions added by me).  Can optionally capture audio and send it through the HDMI channel as well.  And last but not least - has a 3 pin connector for adding an WS2812 LED strip - because  you can never have enough blinkin LEDs  (https://www.dinoboards.com.au/hdmi-for-rc)

Developing and getting the HDMI module working was quite an adventure -- I think I had fun do it ...  now with the distance of some time, I may have suppressed all the WTF moments.  

Never done any FPGA coding before - so there was a lot of learning.  The FPGA code is derived from the tn_vdp project -- that was itself was derived from two other projects - a VHDL implementation of the V9958 and a Verilog implementation of a HDMI driver (I think the HDMI driver is from the Tang Nano examples).  I converted the VHDL code to verilog and cleaned up the integration between the 2 components (reducing the hardware usage a little).  Then i was able to start playing and adding my custom extensions.

I would love to take this further, add other hardware emulation - such as audio chips - and look at implementing alternative Video emulation - Motorola 6845 perhaps?? ...

Dean

[Jeff Greer]

Wow! What a great project!

Certainly too good to resist.

Thank you, 

v/r Jeff

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/retro-comp/ce2337e5-1bd7-4dd4-b476-c82f034e9b9bn%40googlegroups.com.

[Dean Netherton]

Thanks Jeff.  Both for the compliment and the order.  

Cheers

Dean

[Mark Durham]

I couldn't resist either! Purchased the video module to have a play with on my RCBus 68000 system.

Thanks for the hard work Dean.

[Mark Cohen]

I tried. Said out of stock

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/20cbe667-aa35-4da7-af68-ae58466004e0n%40googlegroups.com.

[Dean Netherton]

Thanks Mark - appreciate the support.

Its been a popular module - sold out already - got new stock coming very soon.

Armm..... I have not tested with 68000 interface.  The module uses a standard Z80 interface (IORQ, RD, WR and with 8 bit address select) -  will that work in a 68K system?

Dean

[Mark Durham]

My RCBus 68000 system works fine with Sheila Dixons TMSEMU (TMS9918A emulator) as well as several of Steve Cousins boards. The TMSEMU also uses IORQ, RD, WR, 8-bit data as well as a couple of address lines. No Z80 specific signals like M1 are used so I think it'll be fine.

[Mark Cohen]

Hi Dean,

I received the HDMI for RC and put it together.

I am loading the Tand as I sourced my own.

Unfortunately, I can't get the same gowin as you as I do not see it on the vendor site.

I have the latest Gowin_V1.9.11.03_Education_x64_win and this does not seem to compile.

build.bat changed to C:\Gowin\Gowin_V1.9.11.03_Education_x64\IDE\bin\gw_sh.exe tn_vdp.tcl

Getting the below.

Any help would be appreciated.

Thanks.

WARN  (PA1001) : Dangling net 'DO[25]'(source:'line_buffer_line_buffer_0_0_s') in module 'VDP_SUPER_MID_RES' has no destination
WARN  (PA1001) : Dangling net 'DO[26]'(source:'line_buffer_line_buffer_0_0_s') in module 'VDP_SUPER_MID_RES' has no destination
WARN  (PA1001) : Dangling net 'DO[27]'(source:'line_buffer_line_buffer_0_0_s') in module 'VDP_SUPER_MID_RES' has no destination
WARN  (PA1001) : Dangling net 'DO[28]'(source:'line_buffer_line_buffer_0_0_s') in module 'VDP_SUPER_MID_RES' has no destination
WARN  (PA1001) : Dangling net 'DO[29]'(source:'line_buffer_line_buffer_0_0_s') in module 'VDP_SUPER_MID_RES' has no destination
WARN  (PA1001) : Dangling net 'DO[30]'(source:'line_buffer_line_buffer_0_0_s') in module 'VDP_SUPER_MID_RES' has no destination
WARN  (PA1001) : Dangling net 'DO[31]'(source:'line_buffer_line_buffer_0_0_s') in module 'VDP_SUPER_MID_RES' has no destination
Processing netlist completed
Reading constraint file: "C:\Users\markc\Downloads\V9958-Super-main\V9958-Super-main\src\v9958.cst"
ERROR  (CT1136) : Bank 7 vccio(3.3) is locked by other constraint or embedded port, conflicting BANK_VCCIO set by 'clk_ibuf' : IO_TYPE = LVCMOS18 in the same bank
Physical Constraint parsed completed with errors

    while executing
"run pnr"
    (file "tn_vdp.tcl" line 116)

C:\Users\markc\Downloads\V9958-Super-main\V9958-Super-main>

[Dean Netherton]

Hi Mark,

It is disappointing that Gowin do not seem to have the older releases of their code available.

I had recently updated my image to the 11.01 - and all was good -- no issues noticed.

But I just downloaded 11.03 --- running in windows - and get an error!  Great.  

I will investigate -- not sure how long it will take -- in the meantime, not sure if you are aware, I have previously built images available on my github repo's releases section: (https://github.com/dinoboards/V9958-Super/releases)

I have yet to test if the new Programmer also might have issues.   

Let me investigate... thanks

Cheers

Dean

[Dean Netherton]

I just identified that we can still download the previous version - not sure if it will stay there indefinitely, but I found this link still seems to work:

https://cdn.gowinsemi.com.cn/Gowin_V1.9.11.01_Education_x64_win.zip

I suspect though, before attempting to download this link, you need to have logged into their site first.

Dean

[Dean Netherton]

Fixed.  

Built and flashed my TN20K.  Ran suphdmi.com and seemed good.  But have not done exhaustive testing - the new release may chose a different routing optimisation and --- well --- I will need to test through all the graphics modes again.

Funny thing -- their HDMI example project (a basis for much of my project)  also now has the same error!

Dean.

[Mark Cohen]

Thanks for the info.

I am figuring out how to load an image.

Downloaded msys2 and going to run that openfpgaloader.

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/32f4258d-c425-4d7a-9ec8-ffdf18667f7en%40googlegroups.com.

[Mark Cohen]

Hi,

So I have this working.

Tang sourced from Amazon.

Used the Gowin_V1.9.11.01_Education_x64_win.

Built using build.bat under windows 11.

Used Gowin programmer to upload the bitstream as openFPGALoader does not seem to do anything.

openFPGALoader was taken from the git for mingw64 which I also installed from MSYS2. Since it doesn't work this is all not needed.

Gowin programmer needed the USB cable directly plugged into my laptop not a hub, otherwise it would hang.

Settings for the Gowin programmer look like:

This works on the SC 700 series.

I XMed the 2 test programs to the device.

Nice job!

This is my first experience doing FPGA. I have another Tang with a Nintendo emulator to start working with.

Guess I need to do the rest of MSX now.

Thanks,

Mark

[Dean Netherton]

Nice one!

Looks super!

The openFPGALoader issue you had, might be related to an incompatible/outdated 'firmware' on the programmer chip of the TN20K module.  I had some modules that also would not work with openFPGALoader until i had changed the firmware. Its not clear to me what revisions require what firmware - as I had updated another module, only to find it refused to work - until I reverted the firmware...  confusing...

If you are happy to keep using windows - then i'd recommend just keep doing that - but if you do want to get the loader working under linux - you need to update the 'debugger firmware' code on the module.  Sipeed have a page detailing the process here: https://wiki.sipeed.com/hardware/en/tang/common-doc/update_debugger.html.

(If you need to revert to an older firmware - I found them here: https://github.com/MiSTle-Dev/MiSTeryNano/tree/main/firmware/friend_20k)

Cheers

Dean

[Mark Cohen]

Thanks again for that info.

I'll keep it as is because it works fine.

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/fa7a1921-b4a0-44e6-8bde-ee5b278d8a01n%40googlegroups.com.

[7alken]

Hi Dean, I just read ALL your logs around "eZ80 for RC" project (so not only q3vm mod) - backwards, but will do it at least once again from scratch )) 
Its IMHO perfectly written, all quirks you had to solve cleanly described, all is very interesting, and I Iearned basics about eZ80 too. But its not

only about eZ80, I really want to recommend it to anybody curious not only about gluing 3V3 processor to RCBus - you are doing far better than me

as you are integrating it, I went slightly different way, but in fact, "DIP32+16" is something I want to try to apply also on your 2MB linear board, so

thanks for solving all issues we had with ordering - and your original V99x8 VDP board is something I never built yet, having here chips and drams,

so - its moving slowly here but, moving at least  ))
https://hackaday.io/project/196330-ez80-cpu-for-rc2014-and-other-backplanes

fact is, I noticed eZ80 after few years again; here are my fist questions, not sure how correct; I got far more datails later from your great logs, tnx
https://chatgpt.com/share/68ca5a8d-57cc-8000-a73e-728beddad921
Petr

[Bill McMullen]

Petr: While you may enjoy questioning ChatGPT, I would definitely NOT use it as a design reference.  Offhand I found a couple of MAJOR errors in your "conversation" about eZ80:

- The eZ80 does not have CBR, BBR or CBAR registers or Z180 style banking!  Depending on the variant, you can enable a 4KB or 8KB common bank at F000h / E000h but there is no low address common like on the Z180.  Moreover one has to be very careful of things like MADL and the interrupt vector location when changing MBASE.

- I would definitely NOT recommend 15ns SRAM for a 50MHz eZ80.  Excluding capacitance & similar delays, the access time needs to be 11 ns or less to meet Zilog's memory read specification.  20(Tclk) - 8.5(T1) - 0.5(T3) = 11 ns.  I'd recommend 10ns or 8ns SRAM.

My experience with real world benchmarks puts a 50 MHz zero wait eZ80 at a Z80 equivalent of about 170-195 MHz and I agree that it is code dependent.

FYI: I've built many dozens of eZ80 systems at 50MHz over the last five years (i.e. Min-eZ with eZ80F91) and have never had any timing issues with them or my many dozens of 18.432 MHz F92/83 systems.  I highly recommend using the manufacturer's data (i.e. PS0270 & UM0077) rather than AI.  My objective is to create reliable working designs, not to find and correct AI errors which could be quite costly in both time and dollars.

[7alken]

Sure, I am already well aware it makes also huge mistakes and wild hallucinations, and I don't treat anything returned from machine as definitive facts, no doubt. It mostly forces ME to think more and go for deeper study of datasheets etc ... in this case, I read entire Deans log on hackaday, very good for me. Also these mine quick questions were more in funnier style, I was really curious how eZ80 handles entire memory and perfect details was found in that Deans blog and scanning datasheets quickly. So thanks for noting below 10ns here... My entire endeavor is about ability to experiment and to change memories types quickly, and using smaller connectors and boards - this eZ80 is quite extreme for me, kudos for all your experienced work, that's clear :-)

btw, just now I found another mention of eZ80 extremes on RCBus; I am not sure what all inspired me to try to go to smaller connectors/boards and tigher coupling of cpu+memory AND decoupling peripherals but, but it was lot of info read here from real experts as you too: https://groups.google.com/g/retro-comp/c/e7R4HK-0jrE/m/my-Xn0jKAAAJ

So again, thanks for sharing :-)
Petr