Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Simon Thornington
    @sthornington
    Hmm editing not working, wanted to say “should I have been able to do all those things over US1?”
    emard
    @emard
    @sthornington if you have external ft2232 it is fastest and normally used as openocd jtag debugger for softcore cpus like litex or saxonsoc linux. Secondary US1 channel is possible and fully supported by openocd, but it will be unacceptably slow to transfer big files like kernel or root fs images. https://github.com/emard/ulx3s-jtagthru/blob/master/scripts/ft231x2.ocd here is some project that has openocd script to export secondard jtag channel to external pins but normally you can use it internally to soft-core too. See also the schematics for your board (v3.0.8) how FTDI is connected to FPGA
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab The address that is jumped to as soon as interrupts are enabled is $1140, which is the address that unused interrupt vectors are set to. So it is jumping to the wrong vector. I can't see why. The options seem to be that vpa_n is not set correctly, or the ipl pins are not set for long enough.
    Simon Thornington
    @sthornington
    @emard thanks, mostly what I want to get going is an on-board scope to dump traces, is there any particular recommended F2232 interface? Does that plug into the jtag header of the below the oled one?
    emard
    @emard
    any FT2232 breakout board or programmer is ok. It should connect to external pins GP/GN something, depends on where litex/saxonsoc expects them, usually pins 0-5 I guess. I does not plug to JTAG header, it doesn't need to program ECP5 but the CPU RISC5 done by FPGA. If you need onboard scope to display traces in realtime check hdl4fpga project, it has great scope for our boards.
    Simon Thornington
    @sthornington
    Yeah I saw that but is that not to make a scope for actual wires? I want a scope for on-chip/verilog wires
    Goran Mahovlic
    @goran-mahovlic
    As I know those wires are connected directly to FT2232 so you cannot scope then. @emard but maybe in future versions we could connect those two wires also on FPGA? So we could scope them? Maybe we can connect them over small jumpers, only for advanced users that would need two direct USB ports...
    Paul Ruiz
    @pnru_gitlab
    Having an onboard scope for fabric signals would be great, especially because in the Oberon cache I seem to have a hard to reconcile difference between simulated signals and observed behaviour. So far the only plan I could come up with was to route some signals to pins and use an external scope/analyzer. How fast could an on-board logic analyser be? For the problem at hand I'm looking at a ~100MHz signal.
    Paul Ruiz
    @pnru_gitlab

    @lawrie Yes, vpa_n could be the underlying issue. If the CPU does not recognise the autovector request, it would proceed as if a vector index was pushed on the databus -- which would be garbage in. Compare figure 5.6 and figure 6.4 in this doc: http://www.bitsavers.org/components/motorola/68000/MC68000_16-Bit_Microprocessor_Apr83.pdf

    However, I don't immediately see how your vpa_n code is wrong - so it may be something else still.

    Goran Mahovlic
    @goran-mahovlic
    For US2,US3,US4 you can scope USB signals - we are using ScopeIO for that
    But you cannot scope US1 as it is not connected directly to FPGA
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab @emard I think I have found the problem with interrupt processing with the Mac Plus. I had copied code from the QL which used a 68008 and had ipl0_n and ipl2_n tied together and not changed it. I will check if the SDRAM problem remains.
    emard
    @emard
    @sthornington @pnru_gitlab hdl4fpga/scopeio can scope any "wires" physical or internal. But it works only with diamond, vhdl usage is too advanced for ghdl. So your module to be debugged should be compiled with rest of hdl4fpga in order to be inspected. hdl4fpga is very small and efficient so compile time is very acceptable
    emard
    @emard
    Regarding clock rates to be scoped, it should run at SDRAM clock rate as the scopeio primary use was for debugging of RAM drivers :)
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab I have switched back to using SDRAM for low ram addresses, and it now seems to be working. It is possible that the error I thought I had was due to me misinterpreting my diagnostics.
    Paul Ruiz
    @pnru_gitlab
    @lawrie excellent!
    Rob S
    @rob-ng15

    Hi all. Have been doing some more playing around with Silice by @sylefeb, a relatively easy to use HDL https://github.com/sylefeb/Silice and have implemented a Risc-V RVIMC CPU and plugged it into the display/audio system that I created for my j1eforth project. It is easier to write code in C for me than it is in Forth, so I've been able to implement an asteroids style game to test what I have been doing. Bound to be mistakes in there, doesn't yet fully meet timing, I'm working on it.

    Code at: https://github.com/rob-ng15/Silice-Playground/tree/master/risc-ice-v

    Asteroids game at: https://github.com/rob-ng15/Silice-Playground/blob/master/risc-ice-v/ULX3S/BUILD_ulx3s/Risc-ICE-V-Asteroids.bit

    Happy to take any suggestions! Not formally tested, other than it runs the compiled by GCC asteroids game.

    Lawrie Griffiths
    @lawrie
    Did you write the Risc-V processor from scratch or is it based on any other implementation?
    Rob S
    @rob-ng15
    I looked at Ice-V by @sylefeb to see what was involved and for how to implement the register files in BRAM, but written from scratch.
    emard
    @emard
    I have tried asterioids and I can say its one of the best and most playable :). Only the gun could be better, to fire bullets more often
    Rob S
    @rob-ng15
    Thanks for that. Appreciated! I'll have to free up some sprites to have more bullets. I'll see if I can speed the bullets up so that more can be fired.
    emard
    @emard
    Ahaaaa, its sprite number limit. Maybe bullets can be only a line drawn by head pixel and deleted by tail pixel (like stars background) but ok it's a silly suggestion, game is good
    Rob S
    @rob-ng15
    Thank you! I should be able to speed up the bullet, I'll have a look tomorrow. It takes a while to build, yosys takes a while!
    Simon Thornington
    @sthornington
    @emard very cool that scopeio can do internal wires, that's what I want. I will try it, but I have never used the diamond toolchain so that will take some work. I guess it also is too much for vhdl2verilog ? is there a build of diamond for osx ?
    emard
    @emard
    I have ready linux scripts so you just set path to diamond tools and type make, but for osx first diamond must be either installed or running in some vm
    Goran Mahovlic
    @goran-mahovlic
    we already have different version of diamond that runs inside docker
    I am using emard diamond makefile
    and this sudo xhost local:root export ETHMAC=xx:xx:xx:xx:xx:xx docker run -it --env="DISPLAY" --volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" -v -v /localfolder/FPGA:/fpga -e LM_LICENSE_FILE=/fpga/license.dat --mac-address=$ETHMAC --privileged --ipc host -v /dev/bus/usb/:/dev/bus/usb/ dok3r/diamond:v3.7 export containerId=$(docker ps -l -q)
    xhost is only if I need GUI
    Goran Mahovlic
    @goran-mahovlic
    ETHMAC is MAC i have in dinamond license files that needs to be available
    Lawrie Griffiths
    @lawrie
    On my Mac Plus, it does not look too hard to get the keyboard working. I have hand-converted the Mister SystemVerilog PS/2 ketboard code that yosys did not handle. Getting the PS/2 mouse working looks a bit harder. Three of the mouse pins are connected to the VIA chip, and two to the Zilog SCC serial controller. I don't currently understand how it works. I am not that interested in implementing the serial ports yet, so I just want an SCC implementation that works for the mouse. However, I cannot use the keyboard and mouse until the OS is loaded, and I need floppy disk support for that.
    Lawrie Griffiths
    @lawrie
    On the Mac, the rom just contains start-up code and device drivers. On the QL, it contained the whole operating system. The biggest part of Mac Plus rom seems to be the file system implementation.
    emard
    @emard
    I had similar situation with ORAO, system works up to some point but no tape loading. Then I used emulator to create RAM image, patched ROM to restore registers and jump to image. Could get some early results maybe
    Rob S
    @rob-ng15
    @emard, I've made changes to the asteroids game for you, the bullets are faster now, but so are those from the UFO! Uploaded onto github.
    emard
    @emard
    @rob-ng15 That's it! bullets fly well now! Can you also make 12F version, it if fits?
    Rob S
    @rob-ng15
    I don't know what changes will be required, but it uses 96% of the block ram, so possibly too big?
    emard
    @emard
    OK, then it's too big, don't optimize. I thought only to replace 85F with 12F and try to compile and if it doesn't fit, that's the reason why 85F is better :)
    Rob S
    @rob-ng15
    Yeah the 640x480 bitmap is in block ram, admittedly only used for the Risc-V logo and the lives remaining in this game.
    I'll write up some documentation as there is quite a bit to the display stuff, including a basic GPU that can draw points, lines, rectangles, circles and triangles, the background layer, scrollable tilemap layer, two sprite layers with 13 sprites each, a character map, and a small terminal style overlay. Plus basic audio, UART, LEDs and button input. There is documentation in the j1eforth project it was developed in, but there are some changes now, especially to the sprite layer to move the bullets faster!
    emard
    @emard
    Great! 85F with code generators like silice, saxonsoc, nmigen etc has the luxury to make things this way. Using lot of BRAM is "cleaner" and more readable as source than SDRAM driver, which would surely provide any resolution and 200 sprites, but for asterioids game, it is fine how it is done with BRAM.
    Rob S
    @rob-ng15
    Yeah, I'm a novice at this, sdram is on my list of to-dos, along with sdcard. Then I can load programs into sdram from the sdcard.
    Paul Ruiz
    @pnru_gitlab

    @lawrie If you have a working implementation on Mister to guide you, maybe it is not all that difficult to add mouse and disk.

    The wikipedia page for the original Mac's describes the mouse, including its wiring across chips:
    https://en.wikipedia.org/wiki/Macintosh_128K/512K_technical_details#Mouse

    The disk hardware is essentially the same as the disk hardware on an Apple ][:
    https://en.wikipedia.org/wiki/Integrated_Woz_Machine
    http://www.brutaldeluxe.fr/documentation/iwm/apple2_IWM_Spec_Rev19_1982.pdf
    I think once the registers that the controller presents to the software are known, doing a verilog replacement can be similar to what you did for the QL.

    Paul Ruiz
    @pnru_gitlab

    On the Mac, the rom just contains start-up code and device drivers. On the QL, it contained the whole operating system. The biggest part of Mac Plus rom seems to be the file system implementation.

    I'm not sure that is correct. See below link for some details:
    https://macgui.com/news/article.php?t=493

    Lawrie Griffiths
    @lawrie
    Yes, that is the rom listing I am using.
    Lawrie Griffiths
    @lawrie
    The rom may have a bit more than I said, but all the control is from the System and Finder files on the system floppy disk.
    I might be able to move the mouse around the screen without the system disk, but there would be no menus and nothing to type into.
    That IWM spec is also the one I posted a link to above.
    It is all doable but the SCC is a bit complex, and the floppy control is even more complex.